Older blog entries for fejj (starting at number 142)

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...

Had to move desks today, and with it came a new phone extension. My new extension is, rather appropriately, 2060. My previous extension was 2048. I get all the cool phone extensions :-)

/nick'd back from fejj_sleep to fejj on irc yesterday morning and someone asked if I meant to /nick ffej (which would be the true reversal of my real name). So, to humour this person I /nick'd to ffej and this person got all excited and was like "it really is you!" I replied saying "no, I really am just fejj" seeing now my mistake. Obviously this person thought I was ffej and not what I originally understood as just making fun of the spelling of my nick. But wait, it gets better...

Next thing I know, this person is asking me if I remember them. I told her no and that I think she had the wrong guy. She would hear nothing of it. She was sure I was who I said I wasn't. She sasked me "don't you remember me? we had sex a bunch of times". Once again, I denied knowing her, so she says to me "Don't you remember handcuffing me to my bed one time?"

Basically, it went on like this for a few more minutes. She also started asking me if I was the jeff that used to live in/near Jersey and went to community college there and drove a Hyundai and all this... which fits me pretty closely.

As you may well have guessed, I got a little freaked out and started to doubt my own sanity. Was I this kinky linux hacker type that she was talking about and just not remember? Or do I have an evil twin that must get a lot more excitement than I?

Clearly I must stop listening to the little angel that sits on my shoulder. The little devil on my other shoulder has surely led my evil twin down the more exciting path. I want some too, damnit!

I'm feeling pretty fucking useless these days hacking on evolution. seems everything I write lately is crap and has to be rewritten, or worse, completely redesigned. take the folder-tree for example. utter supreme crap.

I think what I need is a break from evolution hacking.

I'm just so frustrated... *sigh*

FATAL ERROR:
Out of memory allocating 4098 qwords
../engine/ps2pkt.cpp 2327

Hmmm, what have I done since my last diary entry? Well, as far as the ELF stuff goes, I've written code to parse the .debug_pubnames section (not that it was all that hard, so whoopie). Started looking at .debug_lines but it doesn't look like it holds anything I care about. Actually, turns out... none of it has anything I care about. Did a little digging the other day and discovered that the only way to get full paths to the source files (which was the whole point of me digging into Dwarf2) is to change the way I build the packages. Basically, gcc uses whatever path/filename you pass it on the command-line as the filename in the debugging symbols even if that filename string is a relative pathname (ie "../../src/foo.c" or "foo.c"). How to fix? Call the configure script (or autogen.sh) using a full path, such as /cvs/package/configure --prefix=/opt rather than ./configure --prefix=/opt. Yes, it's that simple. Now the question is: will Valgrind output the full pathname? or will it just output the basename? If it outputs the full pathname then I'm done, otherwise I still have to write some Dwarf2 parser action so that Alleyoop can get at this lovely tidbit of info.

What else? Well, I booted WindowsXP for once in the past year (or two?) to pick up where I left off in NeverWinter Nights and spent most of Saturday (or was it Sunday?) playing it. Still in Chapter 2, but I did get a fair bit farther at least.

Then, last night I installed a bunch of other games I had like Diablo 2 (plus the Lord of Destruction expansion pack) and my personal favourite first-person shooter, Quake 3 Arena. I also have this game for Linux, tho the last time I installed it about 6 months ago on Red Hat 7.2, it was so dog slow it was unplayable. Bloody graphics accelerator is pretty shite under Linux unfortunately. I think maybe it works a little better under Red Hat 9 which is what I am running now, but I'm not <google>Feeling Lucky</google>. To be honest, I don't even think my laptop's ATI Radeon 9000 is fast enough under Linux to play Quake 3 under, and that's a fair bit faster than my desktop's ATI Radeon 7500. Something like 10x faster. Ah well.