I’ve uploaded a new status.el. This update rationalizes the API a little bit. I’ve also uploaded erc-status.el, which enables notification area functionality for ERC. With this enabled, if someone says your name in a channel, the notification area icon will blink. And, if your connection is disrupted, you will get a notice.
Mark suggested I upload my Emacs hack, so here is status.el.
You will need to build your own zenity with my patch applied. And, you will need to hack a couple of path names in status.el in order for it to work on your machine.
The doc strings in the code explain how to use it. There aren’t any interactive functions, just things that are usable from elisp.
I’d forgotten how fun it is to hack on Emacs.
I’ve occasionally wanted Emacs to be able to put an icon into the status area, so that I can set it up to notify me when interesting things happen; say, when a compilation finishes. I’ve also been thinking of moving my calendar into Emacs, and I didn’t want to lose out on Evolution’s nice appointment notification feature.
So, tonight I hacked up zenity to add a little more functionality to its notification mode. In particular I changed it so that left click will print some (user-specified) text, and so that a right-click menu can be set up as well.
After that it was pretty simple to write some Emacs code to wrap up zenity in a nicer API.
Now all that remains is to hook this up to things inside Emacs. I’ve got my compilation mode hook set already; next I suppose I’ll investigate the calendar, or perhaps erc. Send me email if you want the lisp (my zenity patch is in Gnome bugzilla).
In this long-awaited final episode in the Smoke trilogy, Harvey Keitel reprises his role as Auggie Wren, and Roberto Benigni joins the cast as the failed carnival clown Oliver Banjo. Together with a miniature — and perhaps imaginary — elephant, the two enter an epic but doomed quest to win the world series of poker.
The statement about a switch statement performing repeated compares seems bogus. A dense switch like this will be a table jump, I’d imagine. But, whatever… plain switch-based interpreters are well-known to be slow.
I took my first glance through Hotspot recently. I’m vaguely curious to see what it would take to port it to PowerPC, not because I have a particular love for that architecture, but because it is important for switching Fedora and RHEL from GCJ to OpenJDK. Also, I’m spending a bit of time researching what I want to work on next, and I think OpenJDK is one of the available options.
Hotspot seems like pretty nice C++ code, overall. The structure is easy to navigate. There are comments pretty much where I expect them.
So far I’ve only looked at simple bits. In particular I tried to read the code that corresponds to code in libgcj with which I am very familiar — the interpreter and the verifier.
The Hotspot verifier is a bit more “C++-y” than mine. Stuff is spread out a bit more and a little more abstract, so I find it somewhat harder to read. But, that’s to be expected. I didn’t try to delve into the deeper things (how do they really handle
jsr), since I was only looking at this while waiting for a build today. Some other time.
There seem to be two bytecode interpreters in Hotspot. First, a simple C-ish one, roughly like the libgcj interpreter before I added direct threading. This one is not the default, I suppose it is probably only used when bootstrapping on a new platform or something like that.
The other interpreter is trickier and implements something which is sort of like early Kaffe JITs. The idea is that most bytecodes have an associated function that generates bits of machine code. Before executing a method, a very simple form of JITting is applied where these functions are called to compile code, naively, into a buffer which is then executed.
Well, I hope that is what happens… I’m not trusting myself much this week and the code is fairly convoluted.
I haven’t made much progress on my goal of seeing how hard a port is. The existing ports look pretty small… from 28 KLOC (amd64) to 36 KLOC (sparc).
Roman writes disparagingly of proposals to add properties to Java.
Properties seemed cool when I first heard about them. They seem like a nice tool for maintaining source compatibility — for allowing local refactorings between fields and methods, without requiring massive changes to the rest of the code. In gcjx, I used something a bit like properties (I think you can emulate them in C++, with some work, but I picked something a bit simpler) for just this reason.
But upon further reflection I don’t really see the point of adding them to Java. Java is more concerned with binary compatibility. And, for properties to be binary compatible, they have to be implemented as functions from the beginning (or as a new VM feature — but that seems like overkill). And if you are doing that, you might as well consider that your IDE can generate the methods for you already.
Regardless of what happens here, I think it is interesting that the Java language debates have moved to the blogs. There are several influential Java people blogging about these topics on a regular basis. We’re also starting to see language experimentation being done in the OpenJDK javac.
My friend David is a big fan of Haruki Murakami, so when I was at the library I picked up In the Miso Soup — a book by a completely different person who happens to share the same last name. If this were a movie I would describe it as Lost in Translation meets Henry: Portrait of a Serial Killer; the whole time I was reading it I kept thinking “I didn’t realize David was into such bleak, dark stuff”. I got all the way through and started writing a blog entry about this before Wikipedia and Amazon clued me in to my mistake.
Now I’m reading a book by the author I intended to read the first time. I suppose there’s some lesson about books and covers in here somewhere.