End the War on Freedom

The local grocery store has a big bin of used books for $1. After seeing a 1983 computer dictionary's description of LISP, I knew I had to buy it: It says: LISP acronym for LIST PROCESSING a high-level programming language use primarily for list processing, symbol manipulation, and recursive operations: it can handle many different data types, treat programs as data, and provide for the self-modification of the program as it is executing: generally considered a difficult language to learn (Emphasis mine.)

In the way of achieving a healthy software development environment, a lot of projects fall in one of these two DON'Ts: irresponsibility and territoriality. Irresponsibility is when there is no one in charge of making things right (with respect to a whole category of problems). Territoriality is when there is someone in charge, and he won't let anyone else touch the code without him. They may sound opposite to one another, but often irresponsibility is a result of territoriality, where the person in charge just isn't interested in the kind of problem you're experiencing, and so any consideration for such problems gets disregarded in favor of whatever fits the interests of the maintainer. As a notorious example of irresponsible software design, I will cite PHP, whose maintainer has repeatedly claimed he was never interested in designing a good programming language. It shows. But I'm sure you'll find plenty of familiar examples in your own experience, from the irresponsive provider of some proprietary software you've been locked into using, to maybe someone from some other department of your company that you've had to deal with, and perhaps even to yourself with respect to your own users. Of course, it is always possible to start a new project to replace the software you're dissatisfied with. But the costs associated to such endeavour are often huge. You will have to reimplement not just the parts that the replaced software did wrong, but also the parts it did right. While by assumption you can clearly see parts of the design that are wrong and do better with respect to those parts, you may be lacking the proficiency, time and interest to do as well on these other parts. Last but not least, the community around the original software, that made it valuable, will not switch to the new one for merely small gains, and the transition from the old system to the new system may impose demanding constraints of backwards compatibility. Free Software can drastically reduce the cost of starting a new project, by allowing you to fork the existing code base, copy large chunks of it, or at the very least read the code of what you may have to be compatible with. It does make the cost go down to zero, however. There again, cruft that made the original software bad enough that you felt like changing it will be a heavy burden upon you if you keep it, and a huge setback to reimplement if you decide to throw it away. And even in the world of free software, some licenses can incur a higher cost to forking than others: for instance, licenses that force you to distribute the code as source, that prevent you from making any adaptation and keep the name, or otherwise put hurdles in the way of forkers. In the world of Common Lisp, an interesting case of not-so-responsible software is ASDF. Yeah, some of you might be tempted to sneer, is he going to blame the problem with ASDF on the original author who is long gone, and the current maintainer who isn't committing enough energy and availability to making the project go forward? No, not at all. Dan Barlow actually did a great job while he was there, and if no one is stepping up to offer more than Gary King provides, it's certainly not Gary who's to blame; he is getting blatant bugs fixed and accepting consensual patches, and at this point forking would be trivial to fork the git repo if anyone were dissatisfied with Gary's performance. Rather, I'll argue that any problem with ASDF is a symptom of the way responsibilities are distributed with respect to its update, and propose a small technical change that can hopefully improve things a lot. When Dan Barlow wrote ASDF in 2001, he only wanted a build system that he could use on top of SBCL for his own projects, something that would be more declarative than the previous best alternative, MK:DEFSYSTEM; in developing ASDF, he loosely followed the better design principles once proposed by Kent Pitman for an extensible CL build system. Moreover, ASDF was easily ported to other Lisp implementations, etc. In all those objectives, ASDF was a tremendous success, and CL users should all be grateful to Dan was his achievement. However, as usual the problem lies with issues he didn't try to tackle. Problems with ASDF include the painful way you have to configure it, deficient support for documentation or testing, broken support for conditional compilation, missing support for generated files, its weird TRAVERSE algorithm, etc. Unlike the issue of deterministic incremental compilation that prompted me to start XCVB, none of the above issues is unsolvable in itself. But the constraints within which ASDF is developed make it hard to solve them. Happily, some of these constraints can be removed with a little bit of hackery. Unhappily, others are intrinsic to the problem. Indeed, ASDF has a distribution bootstrap problem: it specifies how to load other systems, but nothing specifies how ASDF itself is loaded into your system. That problem is left to whoever writes the Lisp implementation, distributes the Lisp package, or maintains a larger project within which ASDF is used. And in the world of Common Lisp, there are tens of different implementations, many of them packaged in various ways. To make the problem tractable, ASDF follows the constraint that it comes as a single file that may be loaded independently of its location, and doesn't depend on any third party library beside what is included by each supported implementation. This means that the provider of libraries that use ASDF must rely on the least common denominator of ASDF features, unless he wants to force his users to make sure they upgrade their ASDF. Upgrading the current ASDF could conceivably be easy, but is actually hard, because of the inability to hot-upgrade a loaded ASDF. It is still possible to remove an old ASDF and replace it, and XCVB does it in an ugly way (see how xcvb/no-asdf deletes the ASDF package and anything that uses it); however, files compiled against the old ASDF may not work with the new one and vice versa (I've had "interesting" issues that way while using xcvb-master in slightly different setups). This inability to upgrade further makes the pre-packaging of a Lisp implementation with a given version ASDF a bit of a damned if you do, damned if you don't proposition to Lisp implementers and distributors. Happily, implementers have the option of only providing ASDF when REQUIRE'd; distributors may not have this option inasmuch as there is no standard mechanism to hook into REQUIRE. An example of a failed attempt at distributing Common Lisp with ASDF is common-lisp-controller. It tried to provide a way to make sure there is always a configured ASDF, but their solution only works if everyone uses debian, and if the debian maintainers keep up with all the common-lisp software that one may want to use; two hypotheses that have been disproved in practice. To step back to the problem of responsibility, the current constraints of ASDF are such that a consistent upgrade of ASDF requires action on the part of tens of people, each in his own territory: implementers, distributors. If only one implementer alone decides to upgrade ASDF, he has to incur the cost of the associated work and the risk that this will introduce incompatibilities, for little overall progress in terms of what users may rely upon unless the tens of other people also do the same. Thus, the costs of adoption are high, the benefits of development are low, development is slow, and a cycle of stagnation continues. If someone cares about the future of ASDF, I recommend they should address the upgradability bug, which will itself unlock a big hurdle on the way of further evolution of ASDF. Note that this upgradability includes both the technical ability to load a new ASDF on top of an old one, but probably also the proper configuration of ASDF, to load systems from a series of configured paths declared in user and system preference files. Personally, I'd rather work on XCVB, and invite people interested in build systems to work on it instead of ASDF. But if XCVB is to prevail, it may as well prevail against the best ASDF that ASDF can be. XCVB tries to avoid all the problems of ASDF by stepping back from the assumption that everything happens in a one Lisp world that has already been setup. Instead, XCVB will manage many Lisp worlds that it will help you setup. It doesn't live inside your Lisp image, and thus doesn't depend on Lisp implementers or distributors to provide it for you; it can therefore evolve fast without any issue due to slow distribution. It is also liberated from the constraint ASDF has of itself having no dependencies, because these dependencies would either make bootstrap more difficult or interfere with other versions of same software as part of the software being built. XCVB thus reuses plenty of libraries and is richer in features, and will use even more libraries in the future. All this in addition to its original essential feature of providing deterministic incremental compilation. XCVB isn't complete yet, but I believe that on supported implementations (currently only SBCL, CCL, CLISP, but I could add more on demand, or you could do it yourself), it is already better than ASDF. If you care for CL build systems, please fix ASDF; but please give XCVB a try, too. Even if you don't care for CL build systems, organize your software developments so that every upgrade step can be done by the single maintainer of a single project, without requiring the coordination between many people in many different projects. This lesson should be particularly dear to those who dream of making a Standard for Lisp, Scheme, Javascript, Java or any other language or piece of software: if you need to agree on something that will require future coordination between plenty of people, it is almost sure to fail to evolve fast enough to remain relevant, even though one or two iterations might make it live (see e.g. R6RS and its current attempted successor). Instead, you should offer software that already runs with a free software reference implementation that others can trivially adapt to their systems if needed (also in Scheme, compare the SRFI process). After your code has become de facto standard, you might not care for it being any kind of de jure standard anymore. Whereas if there's going to be a de jure standard, it will be blood and conflict as long as there's anything to disagree about. The same idea also accounts for Conway's Law: if you divide your software project between many teams, each team will build its own code base, and the structure of the software will end up following the structure of the teams that build it. Parts of the software where the ownership is not clearly assigned but where authority is divided will be the scene for conflict, slow evolution, bad design (if design at all), etc. Vertical disintegration, where independent teams manage layers of the software and its life-cycle, will in particular lead to a multiplication of such dysfunctional interfaces between entrenched overlapping code bases the global architecture of which cannot be refactored. Happily, solving the problem of irresponsible software is much easier than solving the problem of irresponsible government.

On November 17, I gave a presentation to the Montreal Scheme/Lisp User Group about developing high-performance network servers in Lisp. I looked at the lessons to be learned from existing Common Lisp web servers, notably Antiweb and TPD2, tried out some of the ideas in my own new under-development web server HTTP DOHC along with some new ideas about threading and concurrency, and put the results of my findings into the presentation.If you're interested in the topic, you should also watch John Fremlin's TPD2 presentation to the Shibuya Lisp user's group.I plan on making HTTP DOHC a full-featured Common Lisp web server with an interface that's somewhat compatible with Hunchentoot 1.0.In other news, I now have time available for contract work. Get in touch at vsedach@gmail.com.

Inspired by the previous TC Lispers meeting and spurred on by the probable topic of the next TC Lispers meeting, I have spent the little bit of coding time I’ve had over the past two weeks on making a GUI layer using Sheeple atop CL-OpenGL and employing ZPB-TTF for font-loading. I have dubbed this project Woolly (because it’s made from Sheeple and because Woolly sounds sorta like GUI). I spent about half of my coding time so far getting the basic framework in place (proven through clickable buttons with labels). I am trying to keep it cleanly separated between generic GUI stuff and the CL-OpenGL specifics in the event that someone would like to port it to some other I/O spec. The other half of my coding time was spent getting the font-rendering to be anti-aliased. I promise to write more about how I accomplished the font-rendering in a future post so that if you’re ever stuck rendering fonts in OpenGL, you won’t be stuck with pixelated blockiness or resorting to rendering to a texture-map and letting the mipmapper figure it out. For this post, however, I’ll just show you the code that sets up the interface depicted here. 1234567891011121314151617181920212223242526(require :asdf) (asdf:operate 'asdf:load-op 'woolly-gl :verbose nil) ;; make it easier to change renderer/controller later (rename-package 'woolly-gl 'toolkit) (defun test ()   (let ((font (sheeple:object :parents toolkit:=font=                               :em-size 48                               :pathname "okolaks/okolaksRegular.ttf")))     (let ((app (sheeple:object :parents toolkit:=app=))           (win (sheeple:object :parents toolkit:=window=                                :title "Woolly Window 1"                                :width 640                                :height 480))           (but (sheeple:object :parents toolkit:=button=                                :offset-x 40                                :offset-y 40                                :width 300                                :height 100                                :font font                                :label "Button")))       (woolly:display-window win)       (woolly:add win but)       (woolly:main-loop app)       (woolly:destroy-window win)))) Next up on my agenda is to make the background and button prettier. It should be easy enough to do with GL_LIGHTING and some vertex-coloring for gradations. After that, it’s on to more controls like labels, panels, checkboxes, drop-downs, borders, and (my dread) text input boxes. Then, it’s on to a layout manager. Edit: Here’s the same GUI a day later. I’m using a simple lighting scheme and rendering the button in 3D. I haven’t yet hooked in the bit to render it depressed when the button is pressed. I’ve tested the code that draws it the other way, but I haven’t hooked it into the mouse handlers yet. Edit #2: Actually, it only took a few minutes for me to hook in the rendering it pressed vs. unpressed. When I did it though, it looked like the label was sliding around because the effect of the contrast between the light and dark edges of the button was so great that you perceive the whole button sliding when it’s pressed. So, I added a little bit in there to actually slide the text by an amount close to what is perceived. So, now… it looks pretty spiffy.

A while ago now, Nikodemus Siivola moved bug information for SBCL from a flat text file to Launchpad. Historically I have had almost nothing but displeasure working with the "standard" or "industrial" bug trackers; I have found Bugzilla horrible to work with, both as a bug reporter and as an administrator; lighter-weight solutions such as Trac are just about tolerable, but basically anything that requires me to have a Web Browser seems to end up confusing and distracting me. An honourable mention at this point goes to debbugs: being able to report, manipulate, update and close bugs by e-mail is close to my idea of Nirvana. So, Launchpad. Initially, I was dismayed, because there doesn't seem to be a way of getting notifications of bug updates over RSS, which would be a second-best to getting updates by e-mail. I managed to ignore all SBCL bug reports for a while, but eventually I bit the bullet and signed up (having refused to do so a good long while ago, when shortly after I used Ubuntu's bugzilla to report a bug they closed the bugzilla in favour of launchpad without managing to transfer accounts across.) A large motivation for signing up was the discovery that launchpad does, in fact, have an email interface to the bug tracker; as long as you can emit GPG-signed mail (which I can), it seems to have all the required functionality for doing things without needing to go near a web browser; I can now receive bug reports and reply to them, and in at least some cases the References: headers in the mail I receive allows my client to thread the discussion properly (I haven't really stress-tested this yet, but it works at least well enough for now.) If that were all, this would not be news (and not even worthy of a blog post). But now I get to demonstrate my Emacs lisp “scripting” ability, in much the same way as Dan Barlow did for me many years ago: SBCL has a mailing list for reporting bugs, for people who are unsure as to whether their problem is a bug or not, or for people who don't want to go to the trouble to get a launchpad account just to report a bug. When such a report does describe a new bug that we should be tracking, that report needs to make its way to launchpad. Without too much further ado, I present sbcl-bugs-mail-forward, which constructs a message (almost) ready to be sent: (defun sbcl-bugs-mail-forward () (interactive) (let ((message-forward-ignored-headers "") from subject) (gnus-summary-mail-forward 4) (message-goto-to) (insert "new@bugs.launchpad.net") (message-goto-subject) (message-beginning-of-line) (re-search-forward "\\[\\(.*\\)\\].*\\[\\(.*\\)\\] \\(.*\\)$") (setq from (match-string 1) subject (match-string 3)) (message-beginning-of-line) (let ((kill-whole-line nil)) (kill-line)) (insert subject) (message-goto-body) (insert "Report from " from "\n\n") (insert " affects sbcl\n status confirmed\n importance ") (save-excursion (insert "\n tag \n done\n\n") (message-goto-body) (re-search-forward "^\\(-\\)+ Start of forwarded message \\(-\\)+$") (beginning-of-line) (let ((kill-whole-line t)) (kill-line)) (re-search-forward "^\\(-\\)+$") (beginning-of-line) (end-of-buffer) (kill-region (mark) (point))) (mml-secure-message-sign-pgpmime))) You can tell it's scripting, really: it's an odd mixture of plausible and dubious ways of getting things done: regular expressions to extract the original sender of the report, and to remove the forwarded message information (and the dull advert inserted in the footer by SourceForge's mailing list system). On the other hand, that function, coupled with something along the lines of (setq gnus-parameters '(("nnml\\+private:list.sbcl-bugs" (gnus-summary-prepared-hook '(lambda () (local-set-key (kbd "C-c C-f") 'sbcl-bugs-mail-forward) (local-set-key (kbd "S o m") 'sbcl-bugs-mail-forward)))))) gives me exactly what I think I want: a simple way of creating, tagging and classifying an entry in the bug tracker from a mail report. I couldn't find any convenient emacs/launchpad interfaces (or any at all, in fact); I'm not sure this counts as one either, but by all means use, adapt and improve on the above for your purposes – I'll happily take criticism of and improvements to this hack.

Earlier this month Google released Closure Templates, a new templating library intended for generating HTML. Who cares? I personally dislike HTML templating, and avoid it whenever possible in lieu of s-expression based generation tools like CL-WHO. At first look, Closure Templates didn't seem to be anything new or useful.The one thing that makes Closure Templates somewhat interesting is that the library works in both Java and JavaScript, so you get client and server-side templates in one place. I did a similar thing with uri-template by having the URI template expand into code that executed in both Common Lisp and JavaScript via Parenscript (here I have to state that despite being an author of a templating library, I still dislike templating libraries and even find my own creation annoying at times).About a week after Closure Templates was released, Andrey Moskvitin (archimag) wrote an implementation in Common Lisp (interesting note: it took him only five days and 1/15 the number of lines of code as the original). The resulting system, cl-closure-template, similarly generates JavaScript via Parenscript.I still didn't understand the motivation. Yesterday, Andrey was kind enough to explain it. Those pampered by web development in Common Lisp using s-expression HTML generation tools simply don't encounter the problem of trying to fit HTML templating onto the paradigm of incremental page updating via AJAX. So if you want to build an AJAX web application and use HTML templating, give cl-closure-template a try.[Blog metanote: if you're reading this blog through its feed, you will shortly see this post show up in Russian. a CONS is an object which cares is now syndicated on Russian Lisp Planet, and I'm going to be writing Lisp-related posts in Russian as well as English. All such posts will be tagged 'lisp-ru'. Filter out that tag if you don't want the Russian version of the posts to show up in your feed reader.]

As mentioned earlier: the 2010 European Lisp Symposium invites your contributions. Unfortunately, the website for the 2010 event is not set up yet; you can get an impression of what the event is like by looking at last year's website, which in the fullness of time (soon, I hope) will be updated with ELS2010 information. In the meantime, here's the Call for Contributions: we would welcome both papers describing original work, not published elsewhere, and submissions for tutorial sessions. Submission will be through EasyChair's conference management system. 3rd European Lisp Symposium May 6-7, 2010, Fundação Calouste Gulbenkian, Lisbon, Portugal Important Dates

• Submission Deadline: January 29, 2010
• Author Notification: March 1, 2010
• Final Paper Due: March 26, 2010
• Symposium: May 6-7, 2010

Authors of accepted research contributions will be invited to submit an extended version of their papers to a special issue of the Journal of Universal Computer Science (J.UCS). Scope The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp dialects. We encourage everyone interested in Lisp to participate. The European Lisp Symposium 2010 invites high quality papers about novel research results, insights and lessons learned from practical applications, and educational perspectives, all involving Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, and so on. Topics include, but are not limited to:

• Language design and implementation
• Language integration, interoperation and deployment
• Development methodologies, support and environments
• Reflection, protocols and meta-level architectures
• Lisp in Education
• Parallel, distributed and scientific computing
• Large and ultra-large-scale systems
• Hardware, virtual machine and embedded applications
• Domain-oriented programming
• Lisp pearls
• Experience reports and case studies

We invite submissions in two categories: original contributions and tutorials.

• Original contributions should neither have been published previously nor be under review in any other refereed events or publication. Research papers should describe work that advances the current state of the art, or presents old results from a new perspective. Experience papers should be of broad interest and should describe insights gained from substantive practical applications. The programme committee will evaluate each contributed paper based on its relevance, significance, clarity, and originality.
• Tutorial submissions should be extended abstracts of up to four pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. The programme committee will evaluate tutorial proposals based on the likely interest in the topic matter, the clarity of the presentation in the extended abstract, and the scope for interactive participation.

The tutorials will run during the symposium on May 6, 2010. Programme Chair Christophe Rhodes, Goldsmiths, University of London, UK Local Chair António Leitão, Technical University of Lisbon, Portugal Programme Committee

• Marco Antoniotti, Università Milano Bicocca, Italy
• Giuseppe Attardi, Università di Pisa, Italy
• Pascal Costanza, Vrije Universiteit Brussel, Belgium
• Irène Anne Durand, Université Bordeaux I, France
• Marc Feeley, Université de Montréal, Canada
• Ron Garret, Amalgamated Widgets Unlimited, USA
• Gregor Kiczales, University of British Columbia, Canada
• Nick Levine, Ravenbrook Ltd, UK
• Scott McKay, ITA Software, Inc., USA
• Peter Norvig, Google Inc., USA
• Kent Pitman, PTC, USA
• Christian Queinnec, Université Pierre et Marie Curie, France
• Robert Strandh, Université Bordeaux I, France
• Didier Verna, EPITA Research and Development Laboratory, France
• Barry Wilkes, Citi, UK
• Taiichi Yuasa, Kyoto University, Japan

Today, I submitted a patch (the first free software lisp one in months for me!) to the Hunchentoot project, and it got accepted. Yay! Some backstory: Hunchentoot’s 1.0.0 release dropped a lot of implementation-dependent features, among them functionality to invoke the debugger if an error happens while handling a request. While workarounds exist, none of them were obvious to new users or users who recently upgraded. The patch I sent should fix this, hopefully. It adds a rudimentary error handling protocol to Hunchentoot, and provides two generic functions whose behavior can be adapted to your error handling needs. You can see for yourself in Hunchentoot’s svn repository. If you’re a Hunchentoot user, I urge you to test this (in both development mode using debuggable-acceptor and running with the default settings). The sooner you find bugs, the sooner they can be fixed, the sooner a release can be pushed out. And if you don’t find bugs at all, that’s cool, too (-:

Having struggled with the build system at work lately, I have decided to force myself to learn another build system at home: I am using XCVB for my UNIVAC emulator project. I was intrigued by XCVB when I read about it in ILC'09. ASDF has always felt unfinished, even though it's a vast improvement over loading files manually (or using customized system definitions). However, I've run into problems with ASDF and I'm not against other options. Some thoughts I had during the building, installation and use of XCVB:

• The name needs to change. Is it possible to pick a name that is not some strained acronym? Ant. Maven. Make. These are reasonable (if not goofy) names. XCVB (and for that matter, ASDF) is just alphabet soup. Pick a word and go with it.
• cl-launch feels like a whole lot of magic, but I've seen a whole lot of other magic work before.
• The process of building your own systems is a bit awkward right now. xcvb make-makefile --build foo when in the directory with the build file for foo is excessive specification. Building the system is even more awkward: make -f xcvb.mk obj/foo.image. Something akin to make foo would be much nicer.
• The idea of introducing metadata into a source file to indicate its dependencies doesn't sit well with some people. Personally, I like information about dependencies being close at hand; whether it comes from textual information or system queries doesn't matter. I'm content with textual information at the level of a file for now, but I suspect maintaining that information will become a pain. On the other hand, I found maintaining ASDF system definition files to be a pain (especially with refactoring and reorganization). As much as I would prefer to not use files in a Lisp system, files are a reality. I think starting with file-level meta-information is a good place to start in order find out what works and what doesn't.

Hopefully I get some time to try and help out with the project since I think it's ambitious enough to work.

Inspired by Nathan, I decided to put some of my not-hosted-anywhere things up on Github. This includes raylisp and sb-cga. Neither is released or supported in any shape or form, but since it turns out my yesterday's snapshot was broken on x86, this is easier than making new snapshots and less embarassing than letting people play with known-broken snapshots...

I've opened an account at github and opened repositories for two libraries: Ironclad and binascii. binascii is a library for doing “ASCII-armoring” of data (base64 and similar); I've been working on it for the past two weeks and am pleased with the results so far, both in the elegance of the code and the (untuned) performance. I do plan on making my other libraries available there as well; Ironclad was the most-requested library for DVCS visibility, so I thought I'd start with that.

Update 2009-11-14: since the snapshot linked below turned out to be broken on x86, you may be better off with the git repos instead. My first ever Common Lisp project was a raytracer. Unsurprisingly, it wasn't too great. Over time I started thinking about how I would make one that was more lispy, and during last couple of years I've been hacking on one every once and a while. It's called Raylisp, and while I'm not planning on ever properly releasing it -- this is purely a personal toy project -- I figured I might still make a snapshop available: it may prove useful to someone wanting to do something like this in earnest. The tarball contains:

• Snapshop of another work-in-progress: SB-CGA, a computer graphics algebra library for SBCL -- most suited for x86-64, since there it implements things like matrix multiplication using SIMD instructions. Raylisp uses it, but unlike Raylisp this one may even see a release some day...
• Raylisp itself, including:
  • reasonably efficient KD-tree construction and traversal code
  • very very hacky code for reading subsets of .ply and .obj files
  • basic raytracing stuff
  • a simple CLIM frontend on top of the raytracing library

In addition to the KD-tree code, which may be worth stealing and polishing off, I'm putting this up to demonstrate some techniques which may be non-obvious to new-but-performance-conscious Lisp hackers: stack allocation (all over the place), using CLOS objects for the parts that need flexibility and closures for the parts that need to be fast (rendering protocol), and packing data into specialized vectors to avoid GC overhead (KD tree construction.) (Last time I touched this code was in August, so all the details are not too fresh on my mind -- hence the vague tone in this post. I had inteded to do this then, but didn't get around to it until now.) All the code is under MIT-style license, as usual.

Qualys, Inc. is looking for a Policy Compliance Engineer who can research and write new capabilities in the form of LISP/QScheme functions to support signature development efforts.

Last Tuesday, I gave short talk about a library I have been writing on: Sequence Iterators.The library is perhaps a bit misnamed because at the moment, it's really a convenience layer on top of iterators. It's supposed to provide tools to make writing functions that operate on sequences convenient, and yet not blatantly inefficient.I'd be very much interested in feedback regarding rough corners if you find a case to apply the library. If you want to give it a shot, there's a file "more-sequence-functions.lisp" which contain prototypes of useful sequence function for which I haven't yet had the time to write them.Please notice that the library is still work in progress.

Last spring, the Maxima challenge for ABCL was to get it to complete its test suite. We've mastered that bit of Maxima for some months now. However, as turned out soon after that, Maxima runs rather slow on ABCL. To some extent - being limited by the JVM - that's to be expected. The performance observed was way off base though: much too slow.Through analysis, the cause was established to be the fact that Maxima declares lots of symbols to be special [and that ABCL doesn't offer a way to remove that specialness].Last summer we found that allowing Maxima to undeclare specials increases ABCL performance immensely (roughly 35%). However, the final goal for Maxima is to make more sparingly use of specials and declaring unspecial or undeclaring special isn't defined in the spec. Because of the two reasons it felt not right to implement the solution at the time: it would have been a very Maxima specific one to a problem Maxima intends to fix in the long run.Peter Graves noted that he converted the special bindings storage in XCL to use the same scheme as in SBCL/CCL, using an array with active bindings instead of a linked list of bindings. He observed a performance gain of 10% in his tests.Last weekend, I implemented the same scheme in ABCL and although the general speed up doesn't show 10% in our tests [which may very well differ from Peter's], we observed roughly 40% performance gain on Maxima's test suite!

There has been a great response to my casual mention of the CL-USER map yesterday. Almost 50 new people have been added in the past 24 hours. I think it shows interesting patterns and I hope it can be used for Lispers to find each other for user group meetings, Lisp jobs, etc. A few people have been confused about how to add themselves to the map. There are a few steps:

• Log in to your Google account
• Go to the map and click the "Edit" button:
• Find your location and click on the pin icon to drop a pin and enter your details:

I should also mention that I didn't create this map. Mirko Vukovic set it up initially and all the people who added their info to it have made it interesting. I just hope more people see it and get some value from it, so I've added it more prominently to Planet Lisp. Enjoy!

In the past few days I've made a number of updates and changes to Planet Lisp. If you normally read the Planet via a feed, you will need to visit the site to see some of them.

• Added upcoming Lisp meetings in the sidebar; easily find Lisp meetings!
• Added embedded version of the CL-USER Google map in the sidebar; easily find Lisp users!
• Changed the appearance somewhat to get rid of big horizontal rectangles and lines
• Removed a number of feeds that had not updated in more than a year; that included some important past contributors like Juho Snellman (last updated in December of 2007) and Kevin Rosenberg.

As always, if you have a blog that's at least partly about Common Lisp, please send me a link so I can consider it for Planet Lisp.

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.17.0 release.This release features - among lots of other things - performance improvements, a fix for unexpected thread termination due to uncaught exceptions and example code for running ABCL on Google App Engine. Please refer to the release notes for the full list.If you have questions regarding use or licensing, or you find issues, please report back to the development list:armedbear-devel at common-lisp dot netSource distribution archives can be downloaded in ZIP (zip signature file) or gzipped tar (tar signature file) format. In addition, a ZIP binary (bin-zip sig file) and gzipped tar binary (bin-tar sig file) are available.

I've been maintaining a Google Calendar for upcoming Lisp-related user meetings. In the past month, several people have said it helped them find meetings, so I'd like to make it a little more visible. To that end, I've added a sidebar to Planet Lisp that shows a list of meetings scheduled in the next 30 days. It's updated daily. I've also created a new twitter account, @lispmeetings, that will post a tweet about a meeting the day before it happens. If you want to see an upcoming Lisp meeting on the calendar, please email me and I'll put it up.

Mikel Evins has released Apis, a sample Common Lisp Cocoa application using CCL's Cocoa bridge. Obligatory screenshot: For what it's worth, Mikel also provides Atta, which is a similar project but based on Gambit Scheme.