Aaron W. Hsu - ((λ (x) (x x)) (λ (x) (x x)))

Thursday, December 15, 2011 8:47:46 AM

Opera's blogging service has served me well, but I have wanted to migrate back onto my own server for some time now. I have done so. My new blog can be found at http://www.sacrideo.us/v5/blog

2 comments

Call Centric phone service and Ekiga

Wednesday, October 12, 2011 10:42:05 PM

ekiga, tech, callcentric

For a record for those who might wish to find this, we use CallCentric as our phone service, which works remarkably well. However, I sometimes have trouble getting Ekiga to work with it. I have to remember each time that you may have to disable the network recognition features of Ekiga in order to make it connect appropriately with Callcentric.

Just for the archives. :-)

No comments

Rapid Releases in Software

Wednesday, October 12, 2011 9:07:58 PM

Software, tech, release cycle

Today's software culture, especially in the Open-source world, seems to be about quick, rapid releases of software, whether it is stable or not. That's something I have mixed feelings about. It is really nice to be able to see the latest and greatest in development, but I've also seen companies and organizations get a bad name with unstable software that wasn't properly vetted.

There are two organizations I would like to highlight. Firstly, Opera has been doing something with their desktop team for a while, releasing development snapshots for the masses for a quite a while. It's quite nice, but they frequently contain very dangerous or harmful bugs, and some people don't seem to know the difference between development snapshots and the real stable releases of the software. So much so, that Opera has taken steps to brand the two different (Opera Next) in order to make sure that people know the difference.

Then take OpenBSD. They always provide snapshots of their software, but it's not that public, and honestly, it's not that necessary. Usually, folks following OpenBSD either run the latest snapshot or CVS, or they run the stable versions, but they don't normally run both in their machines. Remarkably, OpenBSD's CVS tends to be very stable most of the time, unlike Opera's Next releases. And then there are the frequent, consistent, regular six-month stable releases from the OpenBSD project.

As a third datapoint, take Bare Bones software on the Mac, I've rarely if ever seen them release a piece of software that wasn't remarkably stable, but then they started doing some pre-release versions on their mailing lists, and I was worried. Yes, some bugs were introduced during those times, but they are remarkably small changes, and overall, the software seems to have maintained its stability.

What's all this rambling for? Basically, I really value stable, working software, more so than I value rapid release points and new features. Am I in the complete minority here? I feel that some software groups make releases too fast just to make sure that they keep ahead of the times or stay in the news headlines. I can understand why this might make sense in some business plan, but if you decide to do that, surely you can keep stability a priority as well, right? There are companies that manage to do it, so I know it can be done; why do so many groups not prioritize traditional software values like stability these days?

3 comments

Fork-Join parallelism using Signals in APLX

Monday, October 10, 2011 4:47:48 AM

aplx, apl, concurrency, tech ...

In preparation for some research work I'm doing in parallelism, I finally managed to get some comprehension of tasks and multi-programming in APLX.

I came up with the following code, and I would appreciate any improvements or suggestions. It's fast in the case where you have significant amounts of stenciling to do (I used a multi-pass mean filter/blur stencil on an RGB Image). I managed nearly 100% CPU utilization throughout the computation.

∇Z←PBLUR IMG;F;R;G;B;T;TOV;INIT 
 0 0⍴1 ⎕WE 0 
 (R G B)←T←'⎕' ⎕NEW¨3⍴⊂'APL' 
 T.background←1 ⋄ T.wssize←400000000 
 T.∆M←⊂[2 3](3⍴256)⊤IMG ⋄ Z←0 ⋄ F←3⍴0 
 T.∆TOV←⊂0 ⎕OV ⎕BOX 'CONVOLUTE3 CONVOLVEMANY CHILD' 
 R.onSignal←'R.onSignal←"F[1]←1 ⋄ →(^/F)/XT" ⋄ 0 0⍴R.Signal' 
 G.onSignal←'G.onSignal←"F[2]←1 ⋄ →(^/F)/XT" ⋄ 0 0⍴G.Signal' 
 B.onSignal←'B.onSignal←"F[3]←1 ⋄ →(^/F)/XT" ⋄ 0 0⍴B.Signal' 
 INIT←'Sys←''⎕'' ⎕NEW ''System'' ⋄ 2 ⎕OV Sys.∆TOV ⋄ CHILD' 
 0 0⍴T.Open 
 0 0⍴R.Execute INIT 
 0 0⍴G.Execute INIT 
 0 0⍴B.Execute INIT 
 0 0⍴⎕WE ¯1 
 XT:Z←B.∆M+256×G.∆M+256×R.∆M 
 ∇ 

∇Z←S CONVOLUTE3 IMG;M;W;H;PW;PH;I;SR;SS;R;X 
 ⍝ 
 ⍝ Morten contributed optimizations to the original form. 
 ⍝ 
 ⍝ Determine size and row size of the stencil. 
 SR←↑⍴S ⋄ SS←×/⍴S 
 ⍝ 
 ⍝ Pad the incoming matrix with zeros around the edge. 
 (PH PW)←(2×R←⌊SR÷2)+(H W)←⍴IMG 
 M←(-R)⌽(-R)⊖PH PW↑IMG 
 ⍝ 
 ⍝ Generate the template column for a region of the matrix. 
 I←(+\PW×(SR⍴0),(SS-SR)⍴1,(¯1+SR)⍴0)+SS⍴⍳SR 
 ⍝ 
 ⍝ Generate all the other region columns. 
 I←I∘.+(X⍴(W⍴1),(2×R)⍴0)/0,⍳¯1+X←(PH×PW)-(2×R×PW)+2×R 
 ⍝ 
 ⍝ Compute the stencil 
 Z←⌊0.5+H W⍴(,S)+.×(,M)[I] 
 ∇ 

∇Z←S CONVOLVEMANY IMG;I 
 I←0 ⋄ Z←IMG 
 LP:→(10<I←I+1)/0 ⋄ Z←S CONVOLUTE3 Z ⋄ →LP 
 ∇

∇CHILD;S
S←3 3⍴÷9
Sys.onSignal←'Sys.∆M←S CONVOLVEMANY Sys.∆M ⋄ Sys.Signal ⋄ →XT'
Sys.Signal
0 0⍴⎕WE ¯1
∇XT:⍎')OFF'

No comments

Self-documenting Code

Sunday, October 2, 2011 2:34:57 AM

self-documenting, scheme, literate programming, tech ...

There are a lot of people who follow the school of self-documenting code, some of whom I respect as some of the best programmers I have ever met. On the other hand, in my practice, I have found that self-documenting code doesn't exist in my little world. Moreover, I can't help but think, if people really can write self-documenting code, then why do we have papers where people talk about their code, or why do we have developer documentation at all? Why do we have API documentation? Why do we have blog posts about our code? To me, if we really have self-documenting code, then we should be expecting to see blog posts of nothing but code, and that should be sufficient for us. Is it? I've certainly not seen an effective blog post, paper, or program that was entirely, completely, without comment or prose. Usually it is always associated at some point with comments. More commonly, the code is almost secondary, and the prose takes a front seat. If code can really be written in such a self-documentary manner, then shouldn't we have code-blogs? Why are we writing in English?

To me, this gets at the heart of documentation. I just don't buy self-documenting code. I do buy clear, concise, and self-evident code, but that is different. There are so many contextual elements about a program that a program can't tell us, and that's why we have papers about that code, and blog posts, and the like. We have natural language for a reason, and we should use it to its best effect when using code. However, we should not rely on prose where the programming language is the better way to communicate an idea.

The union of prose and code makes more sense to me than having one or the other. Maybe that's why I like literate programming so much.

3 comments

ChezWEB 2.0 Nearing Release (Sneak Peek)

Thursday, September 29, 2011 3:39:27 AM

scheme, chezweb, literate programming, web ...

Over the past two days, I've made 24 commits to my alpha branch of ChezWEB. For me, that's a whole lot. ChezWEB has come together really nicely for this first release, and I'm really happy with where the features are going.

A Beta version of 2.0 is almost ready. There is one feature (external file includes) that still needs to be implemented. The system also needs a lot more documentation, but the developer level documentation of the system is actually quite complete. Some more diagrams in some places would help, but that is something that can be improved upon after the Beta is released. I'm hoping to have some more user documentation finished so that at least there is no empty section in the woven version of ChezWEB.

However, since ChezWEB doesn't even really use the file include feature in its own code, I wanted to share a sneak peek at what to expect in version 2.0. Specifically, I have a woven version of ChezWEB as it stands right now (yes, ChezWEB weaves itself).

http://www.sacrideo.us/~arcfide/tmp/chezweb.pdf

The above link may not last past the Beta release, but if you want to see the cool output, you should check that document out. Especially, see the back of the document for the neat indexing features.

Here's the set of features from the previous roadmap that are going to make it into version 2.0:

CWEB style syntax (no more double backslashes)
Cleaner hygiene that handles threading automatically
No need to explicitly thread identifiers at the chunk reference site
Better support for cross-referencing and indexing (explicit indexing and fully automatic cross referencing)
Improved support for hierarchical document layouts.
Chunks can be extended and concatenated
A single WEB can generate multiple output files (CWEB style)

That means that these are the only features that haven't made it into the 2.0 version:

Scribble Syntax support
Non-hygienic chunks a la CWEB
A proper Scheme pretty printer
Automatic indexing of identifiers and code

Questions, comments, and critiques are welcome! I'll be presenting ChezWEB and specifically, more about the lessons I have learned from implementing the ChezWEB runtime at the Scheme Workshop in Portland this year.

No comments

ChezWEB tangling ChezWEB

Tuesday, September 20, 2011 1:16:31 AM

web, scheme, chezweb, literate programming ...

For those of you who don't know, I have been working on the next major version of ChezWEB (2.0), which is a complete rewrite of the old system, preserving the good things about the old system, while dropping and removing things that made life difficult or inconvenient. Some features have been added, and some have been removed.

The big news today is that ChezWEB is now tangling itself. With a bootstrap file, I can get the tangled file, and then that tangled source is now capable of tangling its own source. Things are looking up in the ChezWEB world!

If you are interested, here is a roadmap of version 2: