Older blog entries for fejj (starting at number 89)

20 Jul 2002 (updated 20 Jul 2002 at 04:47 UTC) »

GNOME Summit: Whoohoo, god did not strike me down today! I actually made it, though I did get lost in the tangle of corridors between building 77 and building 33. Apparently I was supposed to go through doors marked "DO NOT OPEN! THIS IS A FIRE EXIT AND ALARMS WILL GO OFF" :-)

Luckily I met up with ettore, lewing and Anna Dirks and we went out for lunch/sight seeing before heading back around 2pm for more talks.

Plan9's 'plumber': Niiiice. For those that didn't attend the Plan9 talk, Rob Pike talked about his plumber library which originally started out as the Acme shell-type thing. You can check out some documenation at http://plan9.bell-labs.com/sys/doc/plumb.html. Someone else explained it in their diary entry, but from their description, it doesn't sound all that great - sounds like just a hyperlink. You really need to read the docs to get a feel for the awesomeness of it.

Afterwards I went up to the hacking lounge and was assaulted with questions/pokes/prods/etc by a number of people. I might even use the word "pelted". Keith Packard wanted more than 5 "Labels" which is a new feature in Evolution. "Why hard code to only 5? What's the point in that?" I dunno! I swear! I just copied Mozilla's interface! I figured if Mozilla felt 5 was good then it was good enough for me (not to mention everyone who begged me for this feature pointed me to Mozilla's implementation). Anyways, shouldn't be too hard to expand this to use a linked list of labels.

A few thoughts on the Plan9 plumber:

First, what to do if there are multiple viewers for something listening on the socket? Which window does the info go to? Obviously this'd be a problem in the Real World that Robe Pike's implementation doesn't seem to solve (although his implementation seems to be more a proof-of-concept rather than the final solution).

On second thought, maybe it doesn't really matter? If plumb only allowed one "connection" per destination socket then the locking problem is solved too.

Secondly, ...I sem to have lost my train of thought.

19 Jul 2002 (updated 19 Jul 2002 at 05:51 UTC) »

GNOME Summit: Well, I didn't actually make it to today's summit. To make a long story short, I locked myself out of my appartment and had to wait a while for the locksmith. Cost me $140 (I feel a bit ripped off, I wish I got payed that kind of money for a 30 second job). By that time I just felt I might as well just go to work to get some work done. Didn't get much work done, but ah well.

Anyways, I did get to meet gman and jdub so that was cool ;-)

14 Jul 2002 (updated 14 Jul 2002 at 20:27 UTC) »

PlayStation2: Bought a new game, Aggressive-Inline which is a rollerblading game. I've found that I prefer the sports type games over most others as they don't involve as much time. I have a hard time getting into games which you need to save every few hours just so you can come back tomorrow and play another round (this especially means role-playing games like Final Fantasy and other games such as Tomb Raider or Spiderman - all of which I like and think are cool, but I don't have the patience for them). With sports games, I can play for a half hour to blow off some steam and if I want to quit, great - I won't lose anything if/when I come back to it days or weeks later.

GMime: Fixed a bug in 1.0.2 for some guys at PennState (apparently they are using GMime in psu.edu's webmail system which they tell me handles 12,000+ users/day). For those who don't know, PennState is the original University that I attended, so it was kinda cool to find out they were using my stuff :-)

Spruce: As I mentioned in a recent diary entry, I've been sorta working on a C implementation of the JavaMail API. I have most of the abstract classes defined and mostly-implemented. I've just implemented the java.mail.Store and java.mail.Folder classes for mbox which turned out to be a fair bit of work. Ugh. There's still a lot of FIXME's stating that I still need to do this or that, but the core of it is written (fetching messages, appending them, expunging, saving flags, etc).

A stray glance reveals you
A light strikes a spark in your eyes
Making me thirsty with desire
For your blood, your soul
Nonchalant, I come cloaked in night
Immortal you become
7 Jul 2002 (updated 7 Jul 2002 at 21:07 UTC) »

Thought this was kinda funny...

The wise man said,
"Patience is a virtue,
Sometimes ends justify their means"
I, not be as wise,
And being annoyed at the pizza delivery boy, replied,
"Forgiveness is divine,
But never pay full price for late pizza."
"For time is money," he added.

<shaver> truth is a cruel fraud, but _calculated_facades_of_casual_dismissal_ will set you free

For some reason I find this funny:

--> dvhart (~dvhart@cs6625202-7.austin.rr.com) has joined
<dvhart> can anyone tell me where evolution is pulling my
calendar info from?  I delete the entire evolution folder,
start it up again and all my appointments are there.  I want
them all to go away!

you can stab it with your steely knives but you just can't kill the beast

16 Jun 2002 (updated 17 Jun 2002 at 04:36 UTC) »

to hell with what you're thinking and to hell with your petty mind, you're so distracted from the real thing you should leave your life behind

Foolishly I've begun hacking on Spruce again.

This time around, though, I'm using the JavaMail API as a reference for designing the new backend architecture for Spruce. However, since Spruce uses the Gtk+ toolkit (please disreguard the redundancy), the backend will have to block because Gtk+ is not a very pthread-friendly toolkit (which is how JavaMail achieves it's 'async' behavior). This is obviously unacceptable to users.

Possible solutions?

(I've been told that GObject is "thread-safe" by sopwith but seem to recall being told the opposite by owen. I'm going to assume that they are both "right" for the purpose of this little problem solving exercise. Here's what I think we can assume: GObject can be thread-safe supposing that you do proper locking, but the signal system is not.)

  1. My first thought was to use pthreads but avoid signals in the backend and instead write a Listener class that emulates signals by communicating with the main thread via a socket. The main thread could register an idle-handler for each Listener object and read whatever is on the socket and do whatever is the appropriate action. This sounds rather hackish so I think I'll probably avoid it.

  2. My second idea was to make the backend one big state machine. This makes design a bit more complex, but I think you can achieve a much more elegant design/API this way. This can be done in multiple ways, but here is my current idea for implementing this:

    All operations that can require file or network I/O should return a SpruceAsyncHandle object:

    abstract class SpruceAsyncHandle {
    	GObject object;
    	void *state;
    	void begin (handle, object, state);

    public: int step (handle, object, state); int cancel (handle, object, state);

    signals: void finished (handle, object, user_data); void cancelled (handle, object, user_data); };

    /* client API */ int spruce_async_handle_step (handle); int spruce_async_handle_cancel (handle);

    All methods returning a SpruceAsyncHandle object will immediately call the begin method to initialise the state and then call it's parent implementation. The abstract class implementation will simply register the ::step() in an idle-handler. When either the async operation is completed or cancelled, the abstract AsyncHandler class will also take responsibility for de-registering itself from any idle handlers.

    Unfortunately this means I'll have to write a ton more code, simply because I'll now have to write AsyncHandler's for each and every method that can possibly block. Ugh.

I've got a picture in my head. In my head. It's you and me, we are in bed. We are in bed.

GMime: Finally made the 1.0.0 release tonight. I should probably make a pre-release of GMime 2.0 shortly.

Mozilla party tonight, but I didn't go... something about a Goth club didn't exactly excite me. I bet I find out the party was great and I missed out, yada yada. Oh well...

I've got a picture in my room. In my room. I will return there I presume. Should be soon.

12 Jun 2002 (updated 12 Jun 2002 at 05:33 UTC) »

bdodson: ouch, that sucks. I would have to say that a lot of Freshmeat projects are Linux-specific, so only allowing "Unix" applications sounds like BS to me.

GMime: Wow, someone actually found a bug in GMime 0.9.0 today. If you feed a non-seekable stream to the parser, the resultant GMimeMessage or GMimePart object would contain an invalid stream object as its content so writing it out would cause it to segfault.

The fix was to make the parser check to see if the stream was seekable when parsing mime part contents into the GMimePart objects and cache the content in a memory buffer if the source stream is not seekable. This had actually been on my TODO list, but I had forgotten that I had any non-seekable streams. My TODO had actually been to move the seek/tell methods into a new abstract stream class or else find some other way of defining whether or not a stream was seekable. Currently the best you can do is see if g_mime_stream_tell() returns -1, but as you may have guessed - this could just mean there was an error. Of course, I suppose that as far as the parser cares, if tell() fails but read()s work, then the stream should be considered non-seekable and just go on with parsing anyway - so this mostly just works out. Maybe I don't need a GMimeSeekableStream abstraction afterall...

80 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!