Sunday, November 19, 2006

my McCLIM restart

After realizing I had tried to absorb too much too fast in terms of McCLIM and backend implementation, and after taking a break from it, this weekend I pressed the Reset button. Not that I've thrown any code away, but rather, I'm going to spend some time working with McCLIM in its natural habitat -- that is to say, via SBCL on Linux and the CLX backend (maybe I'll experiment with gtkairo too, we'll see). I'll get some practical experience with it in an environment where it works, then return to my Win32 backend implementation.

[Update: well, my Gentoo install is old enough that GTK+ 2.8.19 fails to build. So it's back to CLX on Win32 after all. I really should upgrade my Linux, though.]

Friday, November 17, 2006

releases rant follow-up

I can't seem to add a reply to either of Greg's blog entries concerning my "releases" rant (or else there will be duplicate comments showing up, oops!) so I'll respond here and hope that he sees it.

As Dave mentioned in his comment on your blog, and after considering your more recent ideas, I suspect you're still tackling a different problem (and that's OK, I acknowledge that you may have a different perspective). I think you're assuming a certain state of mind that translates into critical thinking about what exactly a release tag corresponds to, whereas my concern is with developers who have been explicit about their decision not to spend mental energy on that. The result is that I can't justify adding their code as a dependency for my users.

Wednesday, November 15, 2006

"we don't do releases"

I have encountered several CL libraries whose dev teams are either indifferent about doing official releases or have an explicit statement on their project website(s) notifying the world that they don't plan to spend time on such activities. One project in particular observes that formal releases are a lot of work and they can be troublesome, and hey installation is as easy as typing `darcs get blah...'

What these developers fail to recognize (or maybe don't care about) is that this attitude puts the next developer down the foodchain in a difficult position. Here's my perspective -- every dependency of my project is automatically a dependency for my users. When the current source control version doesn't work or whose API/behavior is changing dramatically from day to day, this becomes my problem. I am in a much better position to debug such an issue or look for a substitute, so I don't think it's fair to ask my users to do it. Obviously, I prefer to have some control over the situation, such as being able to say "the version of foobar I have tested for use with my project is 0.x.y patchlevel z". But when a project's release procedure consists of telling people to check out the latest from source control, I have little or no control over which version my users actually get.

So when I see a library that looks useful but doesn't do official releases, I have to decide amongst three choices: a) move on in the hopes of finding an equal or better alternative, b) bundle a snapshot of the library inside my own project, or c) nag the developers to make snapshots available that others can depend on being available (for some useful amount of time). None of those are good choices, frankly.

One last comment...I'm not complaining about brand new projects whose websites are barely a week old. In cases like that, one generally either sees a statement like 'this stuff is brand new and we haven't done any release yet' or it's just easy to tell. Every project has to start somewhere. My beef is with projects that have been around and whose developers really ought to know better -- this is basic configuration management.

Sunday, November 12, 2006

12 Nov 2006

The last two weeks have been a disaster as far as productivity goes. I've had some distractions (of the good kind) and I guess have been feeling somewhat burned out. But forward progress has not completely ground to a halt, and so here is what I've been up to lately.

I haven't made much progress on a McCLIM backend work since those first few days after I announced the start of that project. This is not due to lack of interest! I think I was pushing a little too hard in my efforts to simultaneously understand the CLIM spec, and the existing codebase, and write backend code at the same time. This resulted in signficant burnout, so I decided to put this aside for a bit.

I was embarrassed to discover basic problems with loading the Graphic-Forms system, which I briefly mentioned in my previous blog entry. Who knows how many folks downloaded recent releases and gave up because of this. Well, at least there are fixes available (posted to the mailing list and checked in). Serves me right for not actually using the documented procedure myself. That too has been fixed.

My research into broader layout management functionality has continued. I have spent significant time investigating MiG Layout, which is a monster all-encompassing layout engine in Java. I don't intend to clone that thing, I'll just use it as a rich source of ideas to go along with the many other layout managers that are out there (in different languages). In a related vein, I've always recognized the importance of constraint-based layouts, so I've been on the lookout for constraint engines. A new project called computed-class has caught my eye. The project page advertises simplicity relative to some of the competition.

As for actual coding, I've been working on something called border-layout, which organizes a container window into 5 regions, each of which may be assigned a child component. I anticipate finishing coding and testing of this new layout class within the next several days.

Wednesday, November 1, 2006

note to self: when releasing software, test the build process

Please see the following posting to graphic-forms-devel concerning fixes for loading Graphic-Forms:

http://common-lisp.net/pipermail/graphic-forms-devel/2006-November/000022.html