The student application period for Google's Summer of Code is now open. If you are a student interested in applying for an SBCL-related project, great! There's an application template at the SBCL organization page: at the very least any application must include all the requested information.

When applying, it's worth realizing that both SBCL mentors and Google SoC administrators have a say in whether students are accepted onto the programme. I can't really say anything about what SoC administrators are looking for, but SBCL mentors are likely to be positively disposed towards applications which demonstrate:

• clear understanding of the proposed project: well-articulated final goal, detailed descriptions of intermediate deliverables;
  
• understanding of the project context: a description of how the wider SBCL user and developer community will benefit from the project;
  
• applicant engagement: evidence that the period leading up to application has been put to good use in interacting with the SBCL community.
  

There is still time for any prospective applicants to work to provide the basis for these demonstrations: applications to the SoC programme close on Friday 3rd May.

Members of some of the other, longer-participating projects in Summer of Code have also posted on the subject of student applications; they are perhaps worth reading for any prospective applicants. I've seen a blog post from a Debian mentor and the Clojure guidelines; there are probably others, saying similar things: communicate, demonstrate, self-motivate.

In case a single cryptic twitter post isn't clear enough: SBCL got accepted as a mentoring organization to Google Summer of Code for 2013. Our hastily-constructed organization profile page is available, and anyone who is interested in mentoring students on SBCL-related projects (and has a few hours to spare a week over the summer months) is welcome to sign up to the site and request mentor status.

We also have an indicative list of potential projects, mostly constructed with extreme speed just before the application deadline by Paul Khuong. I say “indicative” because I think the most important factor in successful student projects is intrinsic motivation, which must (of course) come from the student themselves. So I'd suggest that any potential student applicant should use those ideas as a guide, rather than a finished application: feel free to mix and match goals.

I think it's also worth emphasizing that it's unlikely that SBCL will be allocated more than a handful of student slots: the guidelines do say that organizations new to the programme are likely to be given relatively few to see how they cope; although I've mentored for the program before it's not clear whether that experience, with LispNYC, will carry forward into this new organizational setup. So students keen to work on SBCL would be well advised to engage early, and demonstrate that they can at least begin to work with the codebase (a trivial typo-fix patch, with correctly-formatted commit message, would be a great start, for example). It's also worth saying that Google, not the SBCL organization, has the last word on which students are accepted.

(Thanks to the Common Lisp Foundation for agreeing at very short notice to handle the financial-related side of SBCL's participation.)

Before I forget: I was at what called itself the very first Emacs conference last weekend. The first thing to say is that I had a lot of fun!

I experimented with semi-live-tweeting the thing -- indeed, it was noticed by an external viewer that I was the only live-tweeter on #emacsconf using an emacs-based twitter client. I'm not sure about whether this is a good thing to do or not; certainly, in lectures that I'm giving, it's irritating (and distracting) if students are glued to their ludicrously expensive phones rather than to my perfectly-crafted narrative, but I accept that it happens – and if any of my undergraduate lecturers is reading this: I apologize profusely for reading the newspaper and trying to do the Inquisitor crossword during the Saturday lectures (but I wasn't the only one...). In this instance, I aimed not to create any disturbance, and mostly managed to tweet during breaks rather than during the actual talks.

The actual talks? This had something of the feel of a European Common Lisp Meeting (or its precursors) from about a decade ago: several times I heard the expression of surprise along the lines of “Who would have thought there were so many of us?” Particularly so many who were willing to turn up on the Saturday of an extended weekend to be cooped away from the sunshine all da... no, wait, being in the warm was a bonus. (It snowed on me at lunchtime). The actual talks were a good part of the draw: I had admired Sacha Chua's posts about using org-mode for, well, everything, back when I was picking it up for GTD (Gah, I am a long way off the wagon!) and John Wiegley is a name that has popped up in many a place that I have investigated (emacs obviously, but also Common Lisp and personal accounting), so the fact that they were doing a double-act for the keynote was a great draw (and it made a great start to the day).

The other talks were all interesting, though some were more relevant to me as an emacs outsider than others: highlights for me were the insanity of embedding a gtk-emacs inside another emacs (memories of McCLIM craziness) using Joakim Verona's oddly-named XWidgets; a call to arms on EmacsWiki from Nick Ferrier; Sam Aaron's emacs-based music/live coding system; and John Wiegley's rapid tour through emacs and emacs-lisp productivity enhancers (made me feel like a complete newbie). There was a lot about packaging systems for emacs lisp libraries and applications, about which I expressed a certain amount of skepticism, and Luke Gorrie gave a talk about SLIME, from (almost) the opposite perspective of the talk he gave at ECLM in 2005. (I have got this far without mentioning them, but I can't leave the subject without linking to Sacha Chua's talk sketchnotes; the keynote was excellent, and these notes are icing.)

The conversations between talks were good too; I ducked out of some lunch ones to visit Camden Lock market, but there was plenty of time to socialize. Possibly the weirdest moment for me came when Reuben Thomas showed up between Easter weekend services; I had last seen Reuben in a crazy performance of Handel's Giulio Cesare many, many years ago, and the context-switch that I think both of us had to go through to place the other was lengthy and extended. Small world.

I feel very lucky to have been able to participate. Thanks from me to the organizers, Aleksandar Simic for doing what seemed to be a lot of the heavy lifting and Forward for hosting. And I'll idle a bit more strongly on the emacs IRC channel and attempt to discover more of the London-based hacking community, time permitting...

I released SBCL 1.1.6 before the weekend, after the customary one-week period of code freeze and request for testing. Unfortunately, it turns out that the release contains a bug which affects a substantial number of quicklisp libraries: the compiler's transformation of svref was sped up, but unfortunately without sufficient generality, so code doing svref on a symbol-macro fails to compile.

This bug has been fixed in the master branch; this post is somewhat in the vein of a public service announcement: don't use SBCL 1.1.6 if your code or anything it depends on does svref on a symbol-macro. (If it does, a quick workaround is to replace the svrefs with arefs). As well as the public service announcement, though, I have a question for the wider community: how can we encourage testing the code and clearly communicating the results just before the release happens rather than just after? It's somewhat frustrating to have a week-long code freeze, then bug reports of serious issues a few hours after the release is made... and unfortunately answers of the form “just test everything yourself during the freeze period” aren't currently practical. Maybe someday.

In the last episode, we discovered some things about the implementation of discriminating functions in SBCL's CLOS, and also I discovered that I had actually documented some of it many years ago in the SBCL Internals manual: as well as the how to make slot-value tolerably efficient. And so I sent Faré the functions for precompiling generic functions, and congratulated myself on a job well done.

And inevitably I got a reply, by return: “it looks like this doesn't work with eql-specializers.” Also “our generic functions have 417 eql-specializers between them.” Ah.

Faré is quite right, the code in the previous diary entry will signal an error on finding a method with eql specializers – and even if it were fixed to not have that problem, the underlying (cacheing) mechanism for efficient method calls, based on looking at the identity of the class-of each argument, fails to work when there are applicable methods with eql specializers (because the set of applicable methods for arguments of a class will vary on whether the argument matches an eql-specializer or not).

So, it is perhaps not surprising that there is an alternative optimized discriminating function mechanism which comes into play if a generic function has a substantial number of methods with eql-specializers: instead of a cacheing discriminating function, we generate and use a dispatching discriminating function, which generates a network of type tests to distinguish between all the possible cases of applicable methods, based on the actual types of the arguments – and importantly in this context, those types can include eql types.

The same sort of support exists in SBCL for constructing a dispatching discriminating function in advance as I presented for constructing a cacheing discriminating function. Something like the following:

I suppose that would make a noticeable difference to application startup times. Next up, unless I've made further oversights which need correction: automating this process, and some incidental thoughts.