Work here never ends.

Adaptation. Given my extreme negative reaction to Being John Malkovich (a movie that pushed many of my buttons), I went to see this with some trepidation. In the end I found I didn't enjoy it very much; Malkovich, while personally disturbing, was more expertly made on every level. I found the self-referential quality of Adaptation more irritating than clever. There were interesting parts, but it didn't live up to the hype I'd heard.

Revolution OS. This is playing in town now. I went to see it at a film festival and was disappointed. It has no emotional hook.

Someone leaked a Sun memo about the pitfalls of Java. I read bits of it. It was interesting, though I see it largely as a condemnation of one particular implementation.

Lately I've been looking into bytecode verification again. It turns out that the libgcj verifier has some bugs (and the gcj verifier has rather more). I've been wondering how I could ever have confidence in a verifier implementation. A large-enough test suite would help, but it would hardly be definitive. Maybe someone can write a proof for a program like this. That would be genuinely interesting.

mharris: Interesting diary entry, thanks. It reminded me a bit of the reasons for the egcs fork, way back when. Basically, a limited set of maintainers who were unresponsive in some ways, with processes that didn't scale, and no real interest in changing.

Forking worked great for gcc in this situation. gcc probably has an order of magnitude more developers now than it did then. Bug tracking has improved, patch tracking has improved, and the compiler has a whole has seen much important evolution which would have been greatly slowed under the old model. So the culture of openness has really helped. I wish you good luck if this is the course you decide on.

Work proceeds. Today rmathew got his copyright assignment approved, so there are some patches to check in. Plus I need to get started on setting up test builds on various platforms.

Nothing recently, but I wanted to welcome bje to Advo.

I survived another holiday.

Work proceeds. As usual, a ton of patches have been waiting for the final stage of the release process. So now I'm spending a lot of time on gcj again. On the one hand this bodes ill for quality. On the other hand, we're pretty careful to test the patches we put in, and these days we have a large (but by no means comprehensive) test suite.

It's nice to see Anthony and rmathew here; both gcj hackers.

I've thought a little about my hacking goals for the new year. Many revolve around gcj 3.4. In particular I'd like to get AWT working this year (probably achievable) get serialization working (or at least escalated to "don't break this" for patches), and pre-compile Eclipse ("stretch goal").

I also plan to do some work on the build tool. Ideally we'd have our first release this year. Whether that is possible depends on whether other people help out.

Perhaps this year I'll finally get started on the free software movie. It has been stalled since the funding didn't work out a couple years ago. These days I'm planning a different, low-cost approach: film it myself on DV, edit it myself with software I write (or find, though the state of video editing in the free software world is not that great). Most likely I'll start by working on my script and plans, and then interviewing local free software folks. There are other film possibilities, but that seems like a practical approach, given that it is readily broken down into smaller parts.

Ben got subversion running -- major progress! I bugged him about it yesterday, but it turns out that he has been making progress all along, and I just didn't know. And now the egg is on my face since I'm going out of town and won't have much chance to do anything.

The trunk unfroze yesterday, so today I checked in a bunch of pending bug fixes. I've also fixed a few bugs and worked out some of the remaining issues. There's a status page.

Lately I've been dealing with a lot of libgcj patches. I write one, test it, back it out, and move on to the next. It would be convenient if, once I was satisfied that the patch was correct, I could submit it to some program that would apply it to a pristine copy of the trunk and the 3.3 branch, run the tests I'm interested in, and then send me the results. That is, automate all the annoying stuff I have to do for every patch.

Release season is upon us again, and with it the attendant stress and second-guessing. Have I done enough? Can I fix these last bugs? Should I do one last merge against Classpath? The holidays play into this situation in an unfortunate way.

This time I really don't know where I'm going to find the time to do all the things that need to be done. For 3.1 I basically spent several weeks working on the release full-time. This time around, though, I actually have other tasks I have to attend to. My current plan is to push work onto other, possibly less willing, people.

gcj 3.3 is shaping up to be the best gcj release ever. More platforms, more classes, more bug fixes, etc.