Gnus, IMAP and Exchange 2007

My workplace upgraded its Exchange installation to Exchange 2007 over the weekend. As usual when Exchange is upgraded, the new and improved version also has a new and "improved" relationship to whatever standards it pretends to support.

In this case it was IMAP that broke.

First problem: During startup of Gnus, my echo area would be spammed with messages saying BAD The specified message set is invalid. Some googling later I had set the variable imap-enable-exchange-bug-workaround to t, which does pretty much what it says on the tin.

So far, so good. But then I opened my inbox. Hm. Weren't there LOTS more mails here on Friday? Did the upgrade blat my mail? Hang on - didn't I see some junk in the echo area while Gnus worked. Let me try that again.

Yes; lots of messages about In imap-parse-body 2. So I have a look at that function; all 90-odd lines of it. Apparently, something Exchange was sending made it fail an assertion.

Unfortunately, the original function was hard to fix, not least because it was hard to tell what was failing. But isn't it really just reading a Lisp list? What if we let the reader help us?

Some hacking later I ended up with this:

(defun imap-parse-body ()
  (when (eq (char-after) ?\()
    (nsubst nil 'NIL
            (imap-normalize-body-sexp (read (current-buffer))))))

(defun imap-normalize-body-sexp (body-sexp)
  (dolist (m (imap-find-message-rfc822-parts body-sexp))
    (setf (nth 7 m) (apply 'vector (nth 7 m))))
  body-sexp)

(defun imap-find-message-rfc822-parts (body)
  (flet ((rfc822-p (body)
                   (and (stringp (car body))
                        (string= "message" (car body))
                        (string= "rfc822" (car (cdr body)))
                        body)))
    (cond ((and (consp body) (atom (car body)))
           (rfc822-p body))
          ((consp body)
           (remove nil (mapcar 'imap-find-message-rfc822-parts body))))))

The imap-normalize-body-sexp stuff isn't really necessary - all it does is turn a list into a vector, and since that vector is accessed using elt it works with a list, too. A vector is just more efficient.

This code, simplistic as it may be, works for me (so far). If it works for you too, good; if it doesn't, there is no warranty.

More puzzling behaviour

Still in the spirit of Java Puzzlers; can you provide declarations for i and j to make this statement fail at runtime?

i = j;

I spent quite some time debugging this, once...

Puzzling behaviour

In the spirit of Java Puzzlers, what does this program print (if anything)?

public class java
{
    static lang lang = new lang();
    
    static class lang
    {
        static Long Short = new Long();
        
        static class Short
        {
        }

        static class Long
            extends Short
        {
        }
    }
    
    public static void main(String[] args) {
        System.out.println(java.lang.Short.class.getSimpleName());
    }
}

Git == good

git-stash and git-commit --amend. Killer features.

Add to that excellent support for named branches, and git-cherry-pick, and you've got yourself one wonderful DVCS.

Telling Skype which browser to use on Ubuntu

Skype (as the only thing on the planet, it seems) uses the x-www-browser alternative to open links. Fix that, and you're good to go.

Fun on the bleeding edge

My pet project jde-mvn depends on bleeding-edge snapshots of Maven 3.0. The reason is simple: MvnServer needs maven-embedder, which pre-3.0 is only available in a buggy and frankly unusable version 2.0.4.

Mostly this is not a problem; however, the recent work Shane Isbell has done on the POM model breaks some existing POMs. Among them, unfortunately, is the CXF parent POM; this means that jde-mvn will choke on any project that depends on CXF (or any other POM that triggers the underlying bug).

I've reported this issue as MNG-3838; no word yet on when it will be fixed (although "sometime before 3.0 goes final" is a safe bet).

Since some of the things I work on in my day job use CXF, I've made my own nastyhack version of Maven and created a "release" of jde-mvn that embeds it; read more about this "release" on the BitBucket site.

More fun with JDEE

With jde-mvn having reached a more-or-less stable point, I've played with some other ideas to make JDEE an even better environment.

One of these ideas is jde-refactor, which has now gotten far enough to unleash upon the unsuspecting masses. Er. Maybe there is one other person in the world who might find this useful?