I recently signed up for the local Java Users’s Group, as a way to poke my nose in something new, and maybe get a few locals interested in Hecl.

They just announced their upcoming meeting, at 9 AM on Saturday the 19th. When I read that, the first thing that went through my head is “Paul Graham is right, these guys are not hackers!”.

I don’t think I’ve ever been to any kind of Linux event that wasn’t an evening affair, perhaps with a meal and/or beer involved. Conferences occasionally start at that time of day, but that’s because people are paying to be there, want to fit as much stuff in as possible, and they last all day in any case. But choosing to meet at 9 AM on a Saturday is I think one of the clearest signs that this community is a bit different from others in which I take part. Not to put these guys down – a couple of them seem to be quite bright, but… perhaps they just aren’t hackers.

A couple of random considerations on web applications versus the more traditional sort:

• No one seems to get quite so uptight about closed-source web applications, like google. The same people (this includes me too, to some degree:-) who get uptight about basing any of their infrastructure on closed source stuff like Java have no qualms about google and gmail. Maybe it doesn’t feel as intrusive because it’s not installed on your computer. This is sort of a strange phenomenon, because I think most of the ‘purists’ realize perfectly well that Google et al. are not free software, but don’t seem very vocal about it.

• In the form of google adsense, you have a ready-made revenue stream. It might not be the optimal way of making money off of your application, but you can get started very easily without having to dedicate much thought to it. Later, if you have clever, better ideas, you can always implement them, but in the meantime, at least you’ve got something to work with.

• They’re easier to upgrade, but that’s pretty obvious.

I had a look at this:

http://www.jadetower.org/muses/archives/000416.html

and thought to myself… hey, I could do that in Tcl in half the code. And it could also handle more than one connection:

proc DoLine {channel} {
    gets $channel line
    puts $channel $line
    flush $channel
}

proc Server {channel clientaddr clientport} {
    fileevent $channel readable [list DoLine $channel]
}

set sk [socket -server Server 6200]
fconfigure $sk -buffering line
fconfigure $sk -blocking 0
vwait forever

I find it more readable as well.

Ruby may well have some good stuff – Rails is very impressive, for instance, and I’m sure Ruby has got lots of other things going for it (like libraries, as the article mentions), but Tcl at its best does things very much the way I like them – simply and elegantly, but without taking away the possibility of doing fancier things should the need arise. Kind of like Rails:-)

lcdui is the ‘GUI’ that is provided with j2me for environments like cell phones. The second version of the API, MIDP2.0, has been cleaned up some with respect to MIDP1.0, but since I want to target as wide a range of devices as possible, I need to make Hecl work as well as possible within the limitations of MIDP1.0.

The latest problem I have encountered is the differences between the List and ChoiceGroup widgets. These are supposed to provide radio buttons or checkboxes, depending on which attributes you specify, with List being the “full screen” version, and ChoiceGroup being an Item that can be included as one component of a form. Form items can register for callbacks via itemStateListener, which is called when the form item’s state changes. Lists do not have this capability though, so you have no way to register callbacks when a List item is selected or deselected.

To remedy this, I decided that I’d just make my own ‘full screen list’ by creating a form with one ChoiceGroup, which works something like this:

public class ListBox extends Form {
    public ChoiceGroup cg = null;

    public ListBox(String title, int choicetype, String []choices) {
        super(title);
        cg = new ChoiceGroup("", choicetype, choices, null);
        this.append(cg);
    }

    public int append(String item) {
        return cg.append(item, null);
    }
}

some details ommitted, but that’s the idea. So far, it seems to be working exactly as I needed – I was able to define a callback that performs an action when all checkboxes were checked.

The only thing I can think of that I’d need an actual List for is to define some sort of menu that performs some action when an entry is selected, via the IMPLICIT Choice type.

Apparently, this problem with List’s has been fixed in MIDP2.0, but… there are a lot of phones on sale that still ship 1.0, so it’s going to be with us for a while yet.

Rivet has been seeing some increased visibility these days, but it seems that people are encountering a great deal of difficulty installing it due to problems with autotools.

This is extremely frustrating to me, because the code itself works fine. It’s all the installation crap that always seems to have problems, on all major platforms. I built and tested the latest version on Ubuntu, and everything was working fine. But there have been problem reports for Fedora, MacOS X (although that’s not an autotools error – Karl Lehenbauer wasn’t even able to make autotools work for MacOSX, so we switched back to the Tcl based build system) and Windows.

I really want this stuff to work, and people aren’t going to use it if they can’t build and install it. On the other hand, people need to help out on the platforms they are knowledgeable with because I’m limited in what I can do on certain platforms.

On the whole, it’s all quite frustrating and leaves me even more unhappy with autotools than I was before. The Rivet code is good, and we’re happy with it, but we find ourselves with something that feels like a …barrier…between us and our users.

Update

Problems are getting cleared up, but it’s still frustrating. As everyone who’s worked with auto* knows, debugging these things is sometimes a black art.

I just upgraded to the latest stable Ubuntu release, and I continue to be impressed by this distribution. It has all the positive aspects of Debian, it’s free software, and it has a very high “just works” factor. If you plotted the Desktop Linux “just works” factor over the last five years, I think you could safely predict that Linux is going places based on the slope of that curve – its rate of improvement is dramatic.

One of the things that makes Ubuntu “better” than Debian is that they have made choices. Where Debian has gone to a lot of work to make it possible to use alternate software packages, Ubuntu in many cases has selected one (while not eliminating the ability to choose another one if you’re really set on it) that they feel is the best.

I like this as a design philosophy: give people the obvious choice without making them select between all the choices, but let them chose if they need to.

Tcl’s sockets work that way for instance:

set sk [socket www.foo.bar 80]

nice and simple – let the computer worry about looking up host names and such, and give people a line-buffered blocking socket that they can configure to be buffered differently or non-blocking, or any number of other options.

See Scaling Down

I had some time to hack on Hecl today, and cranked out a few more widget bindings.

I added the gauge, choicegroup, alert commands. They work pretty much
like you’d expect. I also tweaked the ‘listbox’ command to work like this:

listbox label foo list {"choice 1" "choice 2" apples oranges}

With that, an initial version of all widgets in the ‘high level’ portion
of the gui is pretty much there, modulo some bits and pieces. Canvas
and Images are going to go into a separate package, so that those who
don’t require them don’t incur the size penalty. I’m not sure I’m ready
to tackle those right away though.

Also to be considered is an implementation of ItemStateListener so that the GUI can react to changes not brought on by commands.

After that comes an implementation of “RMS” so that Hecl can store
things on cell phones.

A few weeks ago, I updated the programming language popularity statistics I originally ran a year ago. The article is here:

http://www.dedasys.com/articles/language_popularity.html

It was fun to utilize Hecl for something ‘real’ and of course it shook out some more bugs and things I needed to do with it.

After some fiddling with Pyblosxom, I am trying out “typo”, which seems to be a very nice, professional system. I’m quite pleased so far.

In any case, I decided to add a journal to my site in order to better communicate with the world at large about “computer stuff” (a broad field indeed!).