Concern

With my latest checkin, I’m now able to run Azureus 2.5.0.0, unmodified, on jamvm running on Ubuntu, using the epoll selector I recently wrote.

I don’t know if it’s the performance of epoll, but it seems really fast. It’s just a simple Java interpreter, but I can barely notice the difference between it and an app running on Hotspot.

Edit: the kqueue selector works on Mac OS X. There are some odd bugs still left (like, kevent is returning events for fd’s that should have been deleted), but it is running, and running well

I’ve been working on a java.nio.channels.Selector for GNU Classpath based on the epoll event notification mechanism, which is available on the 2.6 kernels. David was kind enough to point out that on 2.4 kernels with a newer libc, the sys/epoll.h header, as well as all the epoll functions, all exist, and all do nothing except return ENOSYS.

That’s a stellar failure mode there, guys. Thanks a pantload for that.

You quickly realize that this makes writing autoconf tests for epoll completely impossible: nothing you can test for will give you a real hint at whether or not the function is, in fact, supported. Oh sure, you could run a test program that tries to open an epoll file descriptor (eeech), but that won’t help out people who are cross-compiling, will it?

Oh, well, why not just add a configure switch that lets the user disable it by hand, you ask? Yeah, that’s a swell solution. Let’s introduce more configuration options for the poor user to guess the right values for.

Sub-rant ahoy!

What’s the deal with configure help output? The convention seems to be that you write:

• –enable-FOO if FOO is not normally enabled,
• –disable-FOO if FOO is normally enabled.

Of course, no-one follows this bogus convention anyway, and in the help output you’ll see a line saying “–enable-FOO … (default: yes)”. It’s even better when the help output is “–disable-FOO … (default: yes)”. Does the “yes” mean it’s disabled by default, or not?

Edit, FYI: this is not a debate, I think this behavior is completely stupid, and you have not convinced me otherwise.

Edit: toned down this post. I don’t mind being harsh, and it’s partly a joke, but I don’t want you to think I regard the glibc guys that lowly. I don’t, but they do say some goofy ass things sometimes.

Tor is surprisingly easy to use on OS X. It could hardly get any simpler: download it, run it, point your browser at it. The only thing that could make it any easier is if it configured your browser for you, with all you having to do is flip an on/off switch. But there’s that impenetrable wall of XUL.

The site is blocked by the great Seawall, so it’s automatically one of the better things on the Internet. I’ll need to see how usable it is behind that wall next week.

I spent some time hacking this together: Voop, short for “video loop,” is a screen saver for Mac OS X that scrapes your computer using Spotlight, and plays any videos it finds.

It’s kind of buggy right now, so it may steal your desktop from you and not give it back. It also only will play Quicktime and MPEG-4 files (I haven’t figured out what video formats Quicktime can actually handle).

I have to say that I now kind of “get” what Apple is trying to do with Spotlight. It does make sense to the programmer, who may indeed want a simple way to get a catalog of files of a particular type, and Spotlight (actually, NSMetadataQuery) makes that incredibly easy. And this was really easy to put together; it’s really just some glue between QTKit and NSMetadataQuery, and a panel to configure the thing. Fast, easy prototyping is a Good Thing.

Happy hacking

I’ve just merged the contents of my branch of Classpath that I was doing the SSL/NIO work in back into the generics branch. This completes three of the four objectives I set out for my Summer of Code project, with the fourth being optional. These objectives were:

1. That the SSL library in GNU Classpath be rewritten to use the NIO model of the JSSE (that is, to write an implementation of the SSLEngine class).
2. That the blocking-IO SSL classes in GNU Classpath be rewritten to use the NIO classes.
3. That a complete unit test suite be written, which exercises the library with both partial and complete sample SSL connections. These tests should be integrated into the Mauve test suite (see http://sourceware.org/mauve/).
4. (Optional, if there is time) That we augment a free Java servlet container (such as GNU Gumdrop) as a test-bed for this library, set up such an instance on a public web server, and run some performance and scalability tests on this server.

The last on the list will have to wait, because Classpath’s non-blocking IO is not in good enough shape to handle a project like this, in my opinion. I’m going to be working on fixing that when I get a chance.

This is good enough to satisfy me for this project. All things considered, it went remarkably well. One major factor in it all coming together so well is the environment that I did my coding in: when I wrote the original version of Jessie, I was unemployed, just out of college (undergrad), and typing on a laptop on my mom’s couch. For the Summer of Code, I took a month of vacation off of work, and sat on my mom’s couch again and coded on my (now much faster, and with a keyboard and battery that works) laptop. The comfort and total lack of distraction really helped, and I was able to finish the bulk of the work in only a few weeks.

I’m pretty satisfied with how the code turned out. A big problem with the original implementation was that it did a lot of work in one class, meaning that class was thousands of lines long, and hard to understand. Now, that work is split between a server and a client class, and it does this inside a switch statement, so it’s pretty easy to tell what block of code is doing what.

This was a lot of fun, and I hope I’ll do it again next year!