Go away. I'm busy.

I used to not be busy. I used to be in school. Things were easy then. I could blow off classes and just hang out in the the computer lab, coding.

Now I work all day, almost every day, at Netscape. I (with the help of about 12 other people) do the unix front end. I'm a mail/news person but I touch just about everything dealing with unix. Also, I'm entirely to blame for the fact that you can write mail and news filters in javascript.

But, the fact that I'm wasting away my arms typing all day for money doesn't lessen my need to write my own code -- stuff that I can call my own, and give away. So, I've been working on several projects here at home, on my days off or when I get home and don't feel like sleeping.

• A java runtime: Seth, Luke (although neither of them seem to want to touch the code anymore...) and I designed and implemented a runtime. It had one notable difference from any of the runtimes out there - it had no native threads. The java threads were implemented in a fairly straightforward way, with the context switching being done by the interpreter itself. When a native call was made, all scheduling was turned off until the call returned. You may say to yourself, "That's a stupid way to do things" but it's really quite nice because we never had to worry about race conditions dealing with class initialization, blah blah blah. The only thing that sucked is that infinite while() loops in native code would hang the entire runtime, not just that thread. This code is getting a bit moldy... haven't touched it in a long, long time...

• A java CVS client: Snpf and I designed the UI for a CVS front end that we're writing. I'm doing all the non-UI work, and am implemented a textual frontend (called jcvs) which will look just like the normal Unix CVS client. Once snpf gets some time away from real work, she'll start working on a front end using IFC. I'm also going to at some point in the future build a front end using LFC (The Lighthouse Foundation Classes), upon which the backend of the client is based.

• The Y Window System: Don't laugh. This is fairly ambitious but I'm completely serious in saying that this project is poised to replace X windows. It uses a number of simplifying assumptions (such as: interactions dealing with color are 24bit, and the underlying libraries do dithering and colormap handling for you)

  Another thing that makes Y a much better (in my opinion) solution is that clients running on the same machine as the server (or in Y, the "microserver") do all the drawing themselves. All necessary window state is kept in shared memory and clients make calls through various vtables that end up dealing with the display memory itself, after locking the appropriate window-level semaphore. So, you don't have to worry about all the context switches and serialization of drawing requests imposed on you by the X server.

  The Display, Window, and GC object currently have two vtables available to them. One is the local vtable (which corresponds to a client rendering directly to the hardware) and one is the network vtable, which packages up stuff and ships it across the net to the network server, which is itself another Y client, but one that uses the local vtable.

  Oh, and it's not pronounced "why", it's pronounced "oo". It's not actually an english character at all. It's cyrillic (but I don't have a cyrillic font)...

I'm probably going to start putting up work-in-progress type tar files up on the hungry site (and actually make web pages for these things), but until then if you're interested (or on the offchance you'd like to help) just send me mail and I'll tar up my tree and ship it off to you.