Older blog entries for fejj (starting at number 147)

I just love being insulted by self-proclaimed usability experts. *sigh* wtf.

Alleyoop: Just downloaded and installed Valgrind 2.1.1 and finally Helgrind works for me, so the first thing I did was added it to Alleyoop. I also discovered that Valgrind 2.1.x has implemented one of my 2 major feature requests, being "Track open file descriptors". Three cheers for the Valgrind developers! Support for this setting is now also in Alleyoop CVS. I'll be releasing a new Alleyoop within the next few days (just want to give translators time to translate the new string I added).

The famous Cynthia: So apparently Cynthia read my blog entry and thought my "*not* from Red Hat" bit was cute ;-)

She also told me I could link to her orkut photo so as to make her even more famous.

And here it is, your moment of Zen

GNOME: Joined the GNOME 2.6 release party last night at John Harvards. Met up with the local Red Hat folks: Havoc, Jeremy Katz, Jonathan Blandford and his wife, and Nalin. Also met the famous Cynthia (uh, *not* from Red Hat).

Evolution: Thought it might be funny as an April fool's joke to post that the Evolution team has started porting to Qt but that'd probably not help the whole situation... especially since a lot of Slashdotters would probably believe it and start touting it as the truth (it wouldn't be the first time). We wouldn't want to feed the FUD wars any more than we need to (though you have to admit, reading slashdot is for pure entertainment value only - it's like comic relief in the long and serious play we call life).

Exercise: Too cold to go for a run this morning (I was a bit sore still anyway).

Slashdot: Wow, lots of FUD being spread about Novell and Qt. It's pretty funny reading through some of the forum comments on the various sites, especially the speculations about Evolution. No, Evolution is not being ported to Qt. No, Evolution development will not cease. At least not as far as I'm aware, and I think I'd know if either of those were really going to happen. Oh! and someone praised GMime's design and mentioned my new imap4 implementation (maybe, tho he could have been referring to NotZed's imapp implementation - it wasn't really clear).

Evolution: Optimised the current IMAP code slightly today (not really sure how much of a performance impact it really makes, and it probably depends on the IMAP server anyway) by reducing 2 STATUS queries per folder (to get total/unread counts) down to 1. It was pretty silly that we had 2 queries in the first place (with a big FIXME in the code). I think it was probably added temporarily when NotZed changed Camel to cache total counts in the CamelFolderInfo structs in addition to the unread count we already cached. This info will likely come in handy if/when we decide to show the total count in the folder tree.

Got a bunch more of the new imap4 implementation committed to Evolution CVS over the weekend and I'll probably hack a bit on it tonight after I finish blogging. I'm hoping to have something usable by the weekend if I get the time.

New People: Met Nicel today (one of the Novell Indian developers recently assigned to hack on Evolution (Exchange Connector?). Always good to match faces to irc nicknames ;-)

Yesterday was my first run of the season. The last few times I ran were when I was visiting my parents over the 3-week vacation I took over the Christmas holiday. Before that was the end of October or early November (whenever it was that it just got too cold to run).

Surprised myself with a ~10km run (~6 miles) along the Charles River. The extra energy came from all the beautiful BU coeds running/biking along with me (guys, you all know what I mean ;-)

This was the first time I had run along the Charles and I think that I'll continue to run along that path from now on. It's just so much more peaceful along that stretch than running down Sydney, from there to the BU bridge, and then up Brookline (a little less than 2 miles).

I think from now on I'll also be running 4+ miles (not sure I can do 6 miles *all* the time) rather than the 2 mile runs I had been doing this past fall. 2 miles just wasn't enough. The only reason I did them was because I was done in ~12 minutes which didn't delay my getting to the office.

Now all I need is a beautiful running mate... any interested ladies out there?

Just updated my primates hacking page with the beginnings of a port of my IMAP client implementation into the Evolution tree. I've also committed what I have to Evolution CVS under evolution/camel/providers/imap4/. Until I implement CamelIMAPFolder and CamelIMAPSummary classes, what's there will probably fail to build all the way, although CamelIMAPStream should build okay.

I've also got a lot of other experimental ideas on my local system for Camel (of which this IMAP plugin was a part of, which is why I need to port it to the current infrastructure)

Some of my other experimental changes include:

• Support for namespaces (eg. for IMAP's NAMESPACE command)
• CamelFolder::open() and CamelFolder::close() methods

  When ::open() gets called for the first time, it increments CamelFolder::open_count to 1 and loads cached CamelMessageInfo structures off disc. Addtional calls to ::open() will simply increment ::open_count. Conversly, when ::close() is caleld, the ::open_count will be decrememnted by 1 until the count reaches 0 at which point the folder is considered truly "closed"

  As a part of this change, I've also got an additional method on CamelFolderSummary called ::unload() which, funnily enough, unloads the CamelMessageInfo's from memory. This is better than simply unref'ing the summary object because it allows the folder to continue to have access to a few of the cached items such as unread count, deleted count, total count, (junk count?), etc.

• Moved a number of CamelStore methods to the CamelFolder class, such as: ::list(), ::lsub(), ::create(), ::delete(), ::rename(), ::subscribe(), and ::unsubscribe()
• READ-ONLY and READ-WRITE modes for CamelFolder (just an integer state variable) - mostly only useful for IMAP right now, but perhaps also useful for local mail archives located on a ROM in the future?
• The removal of CamelFolderInfo's. I did this by making each CamelFolder have a pointer to its parent folder (actually, this was needed for ::create(), ::delete() and ::rename() anyway). Unfortunately this idea hasn't been a total success story. Ideally, you'd be able to use a true tree structure of CamelFolders like we were able to with CamelFolderInfo, but that is quite a bit more complicated when dealing with actual CamelFolder objects due to having to keep the CamelFolder object tree in sync all the time (which is why my CamelFolder objects don't have child/sibling pointers).

Good stuff :-)

IMAP: Finally "finished" my new IMAP client implementation which seems to work rather well.

There's one problem I haven't figured out how to work around yet, tho... and that is:

...
received: * 8487 FETCH (UID 204829 FLAGS (\Seen))
received: * NO Cannot open message 8488
received: * 8489 FETCH (UID 204831 FLAGS ())
...

Because my FolderSummary class stores an array of message info's where each info MUST have a UID assigned to it, it can't handle the situation where we can't get summary information about a message in the middle of the list (if it's at the end of the list, it's no big deal - we can just pretend it doesn't exist)

I suppose I could create a placeholder summary info for any messages we don't get from the server, but how would I assign UIDs? In the above example, it's *obvious* that the UID of message 8488 is "204830" but what if message 8489 had a UID of, say, "204835"? I could still choose "204830" which would be guarenteed to not conflict with anything down the road, but if later message 8488 becomes readable and we end up getting envelope/uid info for it, then all hell could break loose because my summary array would be out of sync.

*sigh*

Looks like someone else (rzyjontko) has fallen into the Pit of Despair (otherwise known as mail client hacking).

rzyjontko: You should take a look at GMime (specifically the latest 2.1.3 release) and if you haven't, take a look at the JavaMail docs for a good start on designing a good backend API. Read them. Really. You'll thank me later.

I've also got plenty of other hints and tips (having been writing mail clients for the past 6 years or so).

Update: Just walked into the Ximian kitchen and who do I find? None other than the Linux kernel hacker, Marcelo. Seems like a very cool guy.

Speaking of meeting new people, last week I got the chance to meet jackson Harper, Todd Berman, Atsushi Enomoto, dick Porter (who I've worked with in the past on stuff like mono-mutex and other parts of the io-layer in Mono), Jordi Mas, and a number of other Mono hackers for the first time.

Also met up with lupus again, who is a really cool guy. He had an interesting idea about adding a way for Alleyoop to get symbol names for run-time generated P/Invoke calls within the Mono JIT (which would help the Mono guys debugging the JIT a bit). Anyways, I'm kind of excited about adding this functionality to Alleyoop.

Did a little hacking in c# yesterday after attending a few of the Mono Summit talks the past two days. Figured I'd start with something simple, like porting CamelURL over to c#, but alas... string parsing seems to be rather more complicated in c# than it is in c? either that or I'm just doing it all wrong. dunno. I'll have to get a book that discusses string manipulation in c# or something. To start, what's the difference between 'char[]' and 'string'? How do I access 'string' chars? Is there an equivalent to strndup()? Does 'str + 5' evaluate to the same thing it would in c? (assuming str is of type 'string'? how about if it is of type 'char[]'?)

I'm probably making this c# stuff out to be a lot more complicated than it really is.

well, back to c I go a crawling...