Planet Lisp

Quicklisp newsProjects on the bubble

· 11 days ago
This month there are a number of projects that may be dropped from Quicklisp. They are hosted by Google Code and SourceForge, and the projects no longer check out properly. They are:
Each of these projects was downloaded between 4 and 6 times in the month of September. (No project in the entire dist was downloaded fewer than 4 times.)

I'm going to do some build-testing and see how widely this will impact other projects. If the damage is minimal, they will simply be dropped.

If you maintain (or want to maintain) one of these projects and want to see it remain in Quicklisp, please update its hosting and then get in touch.

ABCL DevABCL 1.4.0

· 15 days ago
With a decided chill noticeable in the Northern Hemisphere, the Bear has finally sloughed off a long-needed release of ABCL.

With abcl-1.4.0, CFFI now works reliably allowing cross-platform linkage to native libraries to be initiated dynamically at runtime.  Examples of using CL-CUDA to follow as their authors have time to publish.

Considerable work and testing led by Elias Pipping with contributions from Olof-Joachim Frahm has led to a reasonable basis for UIOP/RUN-PROGRAM compatibility.

We have taken the time to learn enough of Maven to publish binary artifacts for both abcl.jar and abcl-contrib.jar that allow developers everywhere to more easily incorporate the Bear into their local Java build tool chains.

And we have tentatively surrendered to the current fashion by establishing GIT bridges to the ABCL source at and to more easily facilitate contributions from the community.

Version 1.4.0



* Consolidated RUN-PROGRAM fixes (ferada, pipping)

* Upstream consolidated patchset (ferada)

** [r14857] Support `FILE-POSITION` on string streams.
** [r14859] Add multiple disassembler selector.
** [r14860] Add EXTERNAL-ONLY option to APROPOS.
** [r14861] Fix nested classes from JARs not visible with JSS.

* [r14840-2] (Scott L. Burson) Introduced "time of time" semantics for
  {encode,decode}-universal time.

* EXTENSIONS:MAKE-TEMP-FILE now takes keyword arguments to specify
  values of the prefix and suffix strings to the underlying JVM
  implementation of

* [r14849] EXT:OS-{UNIX,WINDOWS}-P now provide a pre-ASDF runtime check on hosting platform


* [r14863] RandomCharacterFile et. al.

* [r14839] (JSS) Ensure the interpolation of Java symbol names as strings (alan ruttenberg)

* [r14889] Fix ANSI-TEST SXHASH.8 (dmiles)


* asdf-

* jna-4.2.2


* [r14885] ASDF-INSTALL was removed

CL Test Gridquicklisp 2016-09-29

· 20 days ago
Test results for quicklisp 2016-09-29 comparing to the previous release are coming here.

If you need help reproducing or understanding particular failure, email or comment.

McCLIMProgress report #2

· 20 days ago

Dear Community,

During this iteration my main focus was targeted towards refactoring font implementation for McCLIM. Major changes were applied to both the CLX backend and the TrueType extension - fixing issues and improving functionality. A brief description of the TrueType extension is added in the corresponding system mcclim-fonts/truetype (in the form of file).

The branch with mentioned changes waits for a peer review and will be hopefully merged soon. Since it is a vast change any critical feedback is very welcome:

In the meantime I've worked a bit on issue #55 (without great success), answered questions on IRC, responded to reported issues and merged some pull requests. I'm very pleased that we have a modest, yet constant stream of contributions - many thanks to all contributors.

Posted bounties have not been claimed yet and unfortunately we haven't found a second developer for the agreed price so far.

A detailed report is available at:

If you have any questions, doubts or suggestions - please contact me either with email ( or on IRC (my nick is jackdaniel).

Sincerely yours,
Daniel Kochmański

Quicklisp newsSeptember 2016 Quicklisp dist update now available

· 23 days ago
New projects:
  • 3d-matrices — A utility library implementing 2x2, 3x3, 4x4, and NxN matrix functionality. — Artistic
  • a-cl-logger — A logger that sends to multiple destinations in multiple formats. Based on arnesi logger — BSD
  • alexa — A lexical analyzer generator — BSD 3-clause (See LICENSE.txt)
  • beast — Basic Entity/Aspect/System Toolkit — MIT/X11
  • cl-ascii-art — Ascii Art generating routines. — GPLv3
  • cl-bootstrap — Twitter Bootstrap widget library for Common Lisp — MIT
  • cl-cuda — Cl-cuda is a library to use NVIDIA CUDA in Common Lisp programs. — LLGPL
  • cl-kanren — A minikanren implementation — BSD
  • easy-audio — A pack of audio decoders for FLAC, WavPack and other formats — 2-clause BSD
  • fxml — Fork of CXML. — LLGPL
  • infix-math — An extensible infix syntax for math in Common Lisp. — MIT
  • mgl-mat — MAT is library for working with multi-dimensional arrays which supports efficient interfacing to foreign and CUDA code. BLAS and CUBLAS bindings are available. — MIT
  • parachute — An extensible and cross-compatible testing framework. — Artistic
  • scalpl — market maker + APIs to several Bitcoin exchanges — public domain
  • trivial-mmap — A library providing an easy-to-use API for working with memory-mapped files. — Public Domain
  • utility-arguments — Utility to handle command-line arguments. — ICS
Updated projects3d-vectorsacclimationarchitecture.service-providerarray-utilsarrow-macrosbknr-datastorecarriercaveman2-widgetscellschanlchirpcl-anacl-bloomcl-coroutinecl-freeimagecl-gamepadcl-glfw3cl-inotifycl-interpolcl-ixfcl-lexcl-monitorscl-mpg123cl-mtgnetcl-neovimcl-oclapicl-openglcl-out123cl-packcl-rabbitclackclfswmclipclobbercloser-mopclssclxcodexcoleslawcolleencroatoancrypto-shortcutsdeedsdeferreddexadordissectdocumentation-utilsesrapfare-scriptsfile-typesflareforform-fiddlegbbopengendlgenevahu.dwim.bluezhu.dwim.sdlhumblerinferior-shellinlined-generic-functionkenzolacklakelambda-fiddlelasslegitlisp-invocationlquerymaxpcmcclimmitomito-authmodularizemodularize-hooksmodularize-interfacesmore-conditionsmpcpathname-utilspgloaderpipingplumpplump-bundleplump-sexppostmodernptesterpurlqlotqt-libsqtoolsqtools-uiqueen.lispquriracerrandom-stateratifyredirect-streamrtg-mathrutilsserapeumsha3simple-inferiorssimple-taskssnoozesoftdrinksouthspinneretstaplestatic-vectorsstumpwmswap-bytestriviatrivial-argumentstrivial-benchmarktrivial-indenttrivial-main-threadtrivial-mimestrivial-rfc-1123trivial-thumbnailubiquitousutilities.binary-dumputilities.print-itemsverboseweblocksweblocks-prototype-jswith-cached-reader-conditionalswoozenekindarl.

Removed projects: agm, ax.tga, cl-ecs, cl-marklogic, com.informatimago.

To get this update, use (ql:update-dist "quicklisp").


Zach BeaneCorman Lisp updates

· 23 days ago

Artem Boldarev has made some nice updates to Corman Lisp, fixing the Windows 64-bit FFI issue Roger Corman described as “difficult” when Corman Lisp was released under the MIT license. There are a number of other fixes, too, so go check it out if you have any interest in Corman Lisp.

Hans Hübner

· 28 days ago

Berlin Lispers Meetup: Tuesday September 27th, 2016, 8.00pm

You are kindly invited to the next "Berlin Lispers Meetup", an informal gathering for anyone interested in Lisp, beer or coffee:

Berlin Lispers Meetup
Tuesday, September 27th, 2016
8 pm onwards

St Oberholz, Rosenthaler Straße 72, 10119 Berlin
U-Bahn Rosenthaler Platz

We will try to occupy a large table on the first floor, but in case you don't see us,
please contact Christian: 0157 87 05 16 14.

Please join for another evening of parentheses!

Nicolas HafnerLudum Dare 36 & Lisp Application Programming - Confession 68

· 53 days ago

With just about one hour and a half to spare we managed to submit our entry for Ludum Dare 36. Ludum Dare is a regularly occurring, fairly well-known game jam the idea of which is to create a game from scratch in 48 hours by yourself or 72 hours in a team. Given that, unlike last time we tried to participate we actually managed to finish making something that resembles a game, I think it's worth noting what my experience was as well as my general thoughts on game programming in Lisp.

On the first day, I actually still had a university exam to partake in, so I couldn't start in the morning right away and I didn't have much time at all to prepare anything. This in turn lead to several hours being squandered on the first day trying to get collision detection working and fixing other graphical bugs. Most of that time was spent looking through hundreds of completely useless tutorials and code samples on the web. In general I find the quality of material in the game and engine areas to be absolutely atrocious. Most of the things you can find are either too sweeping, badly written, or assume some ridiculous game framework that makes the code very hard to decipher even if it were applicable as a general, decoupled algorithm. I'm not sure why this field in particular is so bad, or if I'm just searching wrong. Either way, it seems that every time I stumble upon a problem in that domain I have to invest a lot of time in finding the right material- not a very productive experience as you might guess.

All difficulties aside, after the first day we had a running game that let you interact with objects and pick things up into an inventory and so forth. Pretty much all of the progress you see here is my doing. My partner-in-crime was busy working on a random map generator using perlin noise maps, which only got integrated later. Naturally, the reason why we could move on to working on actual game related features much sooner than on our previous attempt at a Ludum Dare is that our engine, Trial, has advanced a lot since then and is much more ready for use. But it is still not there yet by a long shot. Especially a general collision detection and resolution system is a vital aspect that we just did not have the time and energy to incorporate yet. Collision is one of those notorious game development aspects because there's so many ways in which to get it slightly wrong, not to mention that depending on your geometry it can get quite complex quite quickly, not only in terms of performance, but also in terms of the necessary algorithms involved. We've set up a trello board now that should allow us to more easily track ideas we have for Trial and keep things organised.

I'm also thinking of focusing future Ludum Dares on one particular core component of the engine. For example next time we could work on a general dialogue tree system and an adventure or visual novel would lend itself very well to that. Or we could start working on a more powerful animation system with something like a puzzle game, and so forth. Another thing we need to get into is sound and music design. Just before the jam I was heavily focused on getting sound support incorporated, but especially the mixer part was giving me a lot of unprecedented design issues that I could not satisfactorily resolve in the small amount of time I had available to myself with exams still going strong. I hope to return to that and finish it off soon though. That should lay the path to adding sound to our games. Unfortunately it won't actually help with teaching how to make effects and music. I expect that despite my 8 years of violin and 3 years of saxophone practise I won't actually have much of a clue at all on how to compose music. Either way, there always has to be a start somewhere to get onto the road.

By the end of the second day we had finally gotten in some good work on the game aspects, having shed pretty much all of the engine troubles. Random map generation worked, you could place items and interact, and there were even some, albeit flowery-looking, mice running around. Things were much more smooth-sailing now thanks to Common Lisp and Trial's incremental and dynamic development capabilities. We did uncover some more issues with the underlying engine system that proved rather "interesting". I'll have to investigate solutions over the coming days. Most prominently one problem is that of accessing important structures such as the scene when it isn't explicitly passed as a parameter. Currently depending on where you are you can reach this through a special variable or through the global window registry. Both approaches feel not so great and I'd like to see if I can come up with a cleaner solution. We also found some problems in other libraries in the ecosystem such as qtools and flare. It's really great to get some good use out of these libraries and get an opportunity to improve them.

And then the third day marched on. We got some pretty good last-minute features in, namely actually being able to pick up the mice, cook them, and eat them to fill your stomach. Things were getting pretty tight on time towards the end as we were rushing to fix problems in the map generation and gameplay mechanics. Fortunately enough I planned in a lot of buffer time (~6 hours) for the deployment of the game too, as that actually proved to be a lot more problematic than I had anticipated. Not even a single platform was able to deploy right away and it took me until 2 in the morning to figure everything out. One of the mechanisms that Qtools offers in order to tie in custom libraries into the automated deploy process was not coded right and never tested fully, so that bug only showed up now. On Windows we had some access violation problems that were probably caused by Trial's asset tracking system constructing Qt objects before dumping. Fortunately I had anticipated such a thing and with a simple (push :trial-optimize-pool-watching *features*) before compilation that disabled itself and things worked smoothly from there.

On Linux the issues were much more curious. Running it from SLIME worked fine. Deploying worked fine. Launching the binary from my host worked fine. But as soon as I tried to launch it from my VM, it would complain about not finding despite the file sitting right there next to the binary, the system using an absolute path to it that was correctly constructed, and other libraries before it being loaded the same way actually working. I'm still not sure why that exactly happened, but I finally remembered that qt-libs augments your LD_LIBRARY_PATH in order to ensure that, should a library want to automatically load another for some dumb reason -despite the load order being already exactly and properly done in-code- it would still resolve to our own custom files first. However, since environment variables aren't saved when the binary is dumped, this did not carry over to when it was resumed, so I had to make sure that Qtools automatically corrects those on warm boot. And as if by magic, now everything did indeed work!

And so I sleep-deprivedly submitted our entry and went off to sleep. Today I then finally got to catch up with some other things that had started to pile up because I didn't have any time to spare at all over the weekend and now I'm here writing this entry. A riveting recount of a tale, to be sure.

Now I want to take some time to talk about my general impression on writing games -or applications in general- in Common Lisp. This is going to be rough and you might hate me for what I'll say. That's fine. Hatred is a good emotion if you can divert its energy into something productive. So put your passion to it and go ahead, brave reader.

I'll start with my biggest gripe: libraries. While there's plenty of libraries around in terms of numbers, some areas are just severely lacking, and a lot of things are missing. Sure, for games there's bindings to SDL, but if you don't want to use that you're already pretty much out of luck. There wasn't any library to handle gamepad input, monitor resolution managing, 3d model file loading, or complex audio mixing until I added them all recently and that's not accounting for all the features that I got "for free" by using Qt. There's still so much more missing. Font loading and rendering is one current example that's bothering me in specific. We're using Qt for that right now but it sucks. It sucks big time. I want something that works. Some times there is one or some libraries around, but they're not a candidate to me because they're just not usable.

Now, I think it's worth noting what it takes for a library to become usable to me, so let me explain. First and foremost, it must have a non-viral license that allows me to use it freely, and potentially commercially, without repercussion. I don't intend on selling my crap any time soon, but someone might want to that might want to use my software to do it. I cannot accept something that would restrict them from doing so. Second, it must work natively cross-platform on at the very least Linux, Windows, and OS X. If you cannot deploy your application to all of those platforms you can forget about it- it might be a nice toy for your personal use, but don't have any illusions that everyone is using Linux or that people would bother to switch operating systems just for your program. Third, it must be easy to deploy. This includes but is not limited to minimal C dependencies. Deploying C dependencies is a bloody nightmare and the version mismatches will ruin your life. Sometimes C dependencies are unavoidable, but anything that creates a gigantic dependency tree is practically impossible to deploy on Linux across distributions without requiring people to install and potentially compile packages on their own system, which is such a ludicrous suggestion that you should feel ashamed for even considering it. End-users will often not know, nor care about how to do that, and certainly won't go through the trouble of finding out just to use your thing. Finally, it should have a nice interface for me, the programmer. I don't want to use a library that is just a bare-bones CFFI wrapper, or merely some magic "run" function and nothing else. If it's something like that I can probably write it better myself and quicker at that than it would take me to figure out how to use that library.

Libraries aside, Common Lisp is not a magic bullet. Most of the problems are still the exact same as in any other environment. The algorithms are the same, the implementations are roughly the same, the problems are about equivalent. Sure, Lisp is different and it is really cool, but again, don't make yourself any illusions of grandeur about it. Being such a small community there's just all the more pressure on everyone to put as much into it as possible to bring it up to par with the rest of the world. Just because Lisp has many convenient features that ease coding a lot doesn't remedy the fact that it is dwarfed utterly in man-power. I know man-power isn't everything but pretending the effects of thousands upon thousands of people working on things all over the world just aren't there is just as insane as expecting your productivity to increase hundred-fold if you add a hundred people to a project. So please, stay open and accepting about the issues that Lisp still has as an ecosystem. The easiest way to start would be by making sure that libraries have adequate documentation.

If you're fine with Lisp staying small, then that's absolutely alright by me. After all, I'm fine with that too, and actually don't really care about it growing either. What I do care about is the idiocy of pretending that somehow Lisp's advantages can trump the size of other ecosystems. That is plain lunacy. No matter how high the convenience, writing any amount of code is going to take time.

I really like Lisp, I have probably around a hundred projects written in it by now and I have not touched any other language for personal projects in years. But I don't merely want to like Lisp, I want to be able to tell other people about it with a good conscience. I want to be able to tell them "yeah sure, you can do that no problemo!" without having to fall into the Turing tar pit. I want to be able to show them my projects and tell them "man, that was fun!", not "man, I had to write like twenty libraries to get here, and I'm now finally done after many weeks of hard work, but it was kinda fun I guess."

As mentioned in the other article linked above I really don't want to come off as pushy. I don't want to tell anyone what to do. You do what you like. This is merely me venting my frustration about some of the attitudes I've seen around the place, and some of the problems I seem to be constantly dealing with when working on my projects. I don't like being frustrated, and that's why I'm writing about it. But that's all there is to it; I definitely wouldn't expect this to change anyone's mind or force them to do anything different. It's just another voice in the wind.

So how about mentioning some good aspects? Well, they were already buried in the above, I'd say. Incremental development is awesome, especially for games where a lot of small tweaks and extensive, interactive testing are necessary. Lisp is a very pretty language and I like it a lot more than anything else I've ever worked with so far. It has the potential to be fantastic... but it isn't there yet.

Now I think I'll go back to thinking on how to get it just a sliver more in that direction. Ludum Dare gave me a lot to think about and there's exciting changes ahead. Who knows what'll be possible by the time the next Ludum Dare comes around.

By the way, in case you'd like to talk to us and discuss problems, potential features, and generally just chat around about all things code, consider yourself encouraged to hop on by our IRC channel #shirakumo on

McCLIMProgress report #1

· 54 days ago

Dear Supporters,

I'm publishing a progress report for month August with detailed timelog and brief description of undertakings performed each day. This file also contains report for the previous iteration sponsored by Professor Robert Strandh.

The most important achievement was securing funds for a few months of work with the Bountysource crowdfunding campaign. We've created some bounties to attract new developers. #clim channel on Freenode is active and we seem to regain the user base what results in interesting discussions, knowledge sharing and increased awareness about the project among non-clim users.

We have also gained valuable feedback about user expectations regarding the further development and issues which are the most inconvenient for them. We've added a new section on the website which addresses some common questions and doubts and we have created a wiki on GitHub (not very useful yet

During this time we are constantly working on identifying and fixing issues, cleaning up the code base and thinking about potential improvements. Curious reader may consult the git repository log, IRC log and read the logbook.

As a side note, I've exceeded time meant for this iteration by four hours, but I'm treating it as my free time. Additionally people may have noticed that I did some works on CLX not specifically related to McCLIM - this development was done on my own time as well.

Also, to address a few questions regarding our agenda - our roadmap is listed here: That means among other things, that we are concentrated on finishing and polishing the CLX backend and we are currently not working on any other backends.

If you have any questions, doubts or suggestions - please contact me either with email ( or on IRC (my nick is jackdaniel).

Sincerely yours,
Daniel Kochmański

Quicklisp newsAugust 2016 Quicklisp dist update now available

· 57 days ago
New projects:
  • assoc-utils — Utilities for manipulating association lists — Public Domain
  • caveman2-widgets-bootstrap — An extension to caveman2-widgets which enables the simple usage of Twitter Bootstrap. — LLGPL
  • cells — A Common Lisp implementation of the dataflow programming paradigm — LLGPL
  • cl-mpg123 — Bindings to libmpg123, providing cross-platform, fast MPG1/2/3 decoding. — Artistic
  • cl-neovim — Common Lisp client for Neovim — MIT
  • cl-out123 — Bindings to libout123, providing cross-platform audio output. — Artistic
  • cl-soil — A thin binding over which allows easy loading of images — BSD 2 Clause
  • cl-sxml — SXML parsing for Common Lisp — GNU General Public License
  • clump — Library for operations on different kinds of trees — FreeBSD, see file LICENSE.text
  • dirt — A front-end for cl-soil which loads images straight to cepl:c-arrays and cepl:textures — BSD 2 Clause
  • ext-blog — A BLOG engine which supports custom theme — BSD
  • for — An extensible iteration macro library. — Artistic
  • git-file-history — Retrieve a file's commit history in Git. — MIT
  • illogical-pathnames — Mostly filesystem-position-independent pathnames. — BSD 3-clause (See illogical-pathnames.lisp)
  • maxpc — Max's Parser Combinators: a simple and pragmatic library for writing parsers and lexers based on combinatory parsing. — GNU Affero General Public License
  • parse-front-matter — Parse front matter. — MIT
  • path-string — A path utility library — MIT
  • pseudonyms — Relative package nicknames through macros — FreeBSD (BSD 2-clause)
  • — Common Lisp implementation of Graham Cormode and S. Muthukrishnan's Effective Computation of Biased Quantiles over Data Streams in ICDE'05 — MIT
  • queen.lisp — Chess utilities for Common Lisp — MIT
  • read-number — Definitions for reading numbers from an input stream. — Modified BSD License
  • simple-gui — A declarative GUI definition tool for Common Lisp — BSD
  • slack-client — Slack Real Time Messaging API Client — Apache-2.0
  • trivial-rfc-1123 — minimal parsing of rfc-1123 date-time strings — MIT
  • with-cached-reader-conditionals — Read whilst collection reader conditionals — BSD 2 Clause
Updated projects3bmd3d-vectorsagmalexandriabinfixburgled-batteriescavemancaveman2-widgetsceplcepl.cameracepl.devilcepl.sdl2cepl.skitterceramicchirpcity-hashcl-anacl-asynccl-azurecl-conspackcl-ecscl-fadcl-gamepadcl-gracecl-influxdbcl-jpegcl-libuvcl-messagepackcl-messagepack-rpccl-mpicl-mtgnetcl-oclapicl-openglcl-openstack-clientcl-packcl-quickcheckcl-rediscl-rethinkdbcl-scancl-sdl2cl-smtpcl-stringscl-tokyo-cabinetcl-unificationcl-yaclyamlcl-yamlclackclassimpclmlclos-fixturescloser-mopclxclx-truetypecoleslawcollectorscorona,croatoandbusdendritedexadordissectdjulaeazy-gnuplotesrapexscribeexternal-programfare-memoizationfare-scriptsfiveamflarefngendlgenevaglkitglsl-specgslliteratejson-mopkenzo,lacklambda-fiddlelisp-namespacelispbuilderlparallelmcclimmel-baseneo4cloclclopticlosicatprometheus.clproveqlotqt-libsqtoolsqtools-uiquickapprandom-staterclremote-jsrestasrtg-mathserapeumsip-hashskitterspinneretsquirlstumpwmtreedbtriviatrivial-documentationtrivial-nntptrivial-open-browsertrivial-wstrivialib.type-unifyubiquitousugly-tiny-infix-macro,utilities.print-itemsutilities.print-treevarjovgplotvomweblocksweblocks-utilswoowu-sugar.

Removed projects: scalpl.

Zach BeaneDinosaur and Lisp

· 59 days ago

Dinosaur and Lisp has a nice hack for automating the Chrome dinosaur game with Common Lisp and CLX.

LispjobsSoftware Developer, Shareablee, New York, NY

· 67 days ago


Shareablee engineers grapple with some of the hardest challenges in social media analytics and big data. We are involved in every aspect of the product development process from brainstorming to coding and deployment. Products that we create drive decision-making at some of the world's most influential brands such as NFL, ESPN, Facebook, HBO, Ebay, Subway and Samsung.


  • Build features and modules that our customers fall in love with
  • Work on high volume data collection, storage, and transformation
  • Develop reusable code and libraries for future use
  • Optimize various processes for maximum speed and scalability
  • Develop and maintain data collectors and aggregators
  • Collaborate with product managers and team leads to build the right thing
  • Collaborate with directors and senior developers to build things the right way


  • 2+ years of work experience as a software developer.
  • A degree in computer science or a related field.
  • Proficiency in one or more of the following:
    • Clojure, and/or another functional language
    • Clojurescript and/or Javascript 
    • Python or a similar high-level general purpose language
  • Experience with (or very strong interest to learn) the following frameworks and tools: Storm, Hadoop, Cassandra, PostgreSQL, Redis, RabbitMQ, Kafka, Django, Elasticsearch
  • Basic understanding of distributed computing paradigms
  • Experience with Amazon Web Services, Big Data processing and Map/Reduce
  • Integration of multiple data sources and databases into one system
  • Data migration, transformation, and scripting
  • Implement automated testing platforms and unit tests
  • Proficiency with code versioning tools such as Git
  • The ability to map continuous learning to every aspect of your life
  • Humble confidence

Please send resumes and cover letter to

McCLIMFundraiser success

· 68 days ago

Dear Lispers,

We are delighted and overwhelmed by the support that many of you have shown for our effort to crowdfund the maintenance and continued development of McCLIM. Never in our wildest dreams had we imagined that we would reach our highest monthly goal of 2000 USD in only a few days.

In addition to our regular maintenance and programmed improvements, at this level of funding, we will be able to post so-called "bounties", i.e., specific sums of cash for solving specific problems. Once posted, they will be available at this URL:

Like we mentioned in our initial appeal for contributions, this campaign has an important side-effect, beyond that of providing a budget for improvements, namely that of creating new excitement around McCLIM. This excitement will ultimately result in contributions in the form of code, thereby multiplying the importance of the direct monetary support.

In order to make our work on this project as transparent as possible, we will do our utmost to provide monthly reports on our progress, and we will provide details on how the cash was put to work.

We sincerely hope to make sufficient progress, sufficiently fast, that you will consider additional contributions, in the form of cash or code, in the future.


Robert Strandh and Daniel Kochmański

McCLIMCrowdfunding McCLIM maintenance and development

· 72 days ago

McCLIM is currently the only free native toolkit for developing GUI applications in Common Lisp. A while ago, I took over the maintenance, because I did not want to see McCLIM abandoned.

But since I have many other projects going, I decided to hire Daniel Kochmański part time (25%) to do some of the urgent work. This experience turned out so well that I would like for him to continue this work. Not only am I very pleased with the quality of Daniel's work, but I was also very surprised about the additional excitement that his work generated.

While I could continue funding Daniel myself for a while, I can not do so indefinitely. For that reason, I decided that we should try crowdfunding. Steady funding at the 25% level for a year or more would allow us to address some of the issues that often come up, such as the numerous remaining defects, the lack of modern visual appearance, and more.

If you are interested in seeing this happen, I strongly urge you to consider contributing to this project. Our target is modest. We would like to obtain at least 600 USD per month for at least one year. Even a small monthly contribution from a significant number of people can make this happen.

To contribute, please visit and follow the instructions.


Robert Strandh

McCLIMCLIM, the galaxy's most advanced graphics toolkit

· 73 days ago

Setting up the basic environment

We assume that you already have configured the Common Lisp environment (including Quicklisp) and that you know the basics of the Common Lisp programming. The necessary systems to load are mcclim and clim-listener, you may load them with the Quicklisp. After that launch the listener in a separate thread:

(ql:quickload '(mcclim clim-listener))
(clim-listener:run-listener :new-process t)


Finding your way around CLIM

CLIM is the global minimum in graphics toolkits. Geometry, and means of abstracting it. Switch the listener into the CLIM-INTERNALS package to get started. Type (in-package climi) in the Listener REPL.


Evaluate the 4 following forms in Slime REPL, then call (cos-animation) in the Listener REPL to demonstrate CLIM's animation capabilities. You cannot evaluate (cos-animation) in the Slime REPL, as *standard-output* is bound to the its output stream which isn't a sheet, and thus cannot be drawn on.

(in-package climi)

(defparameter *scale-multiplier* 150
  "try modifying me while running!")

(defparameter *sleep-time* 0.0001
  "modify and eval to speed or slow the animation, set to `nil' to stop")

(defun cos-animation ()
  (let* ((range (loop for k from 0 to (* 2 pi) by 0.1 collect k)) ; length of 62
         (idx 0)
          (updating-output (*standard-output*)
            (loop for x from (nth idx range) to (+ (nth idx range) (* 2 pi)) by 0.01
               with y-offset = 150
               for x-offset = (- 10 (* *scale-multiplier* (nth idx range)))
               for y-value = (+ y-offset (* *scale-multiplier* (cos x)))
               for x-value = (+ x-offset (* *scale-multiplier* x))
               do (draw-point* *standard-output*
                               :ink +green+
                               :line-thickness 3)))))
    (loop while *sleep-time*
       do (progn (sleep *sleep-time*)
                 (if (= 61 idx) (setq idx 0) (incf idx))
                 (redisplay record *standard-output*)))))

If you want to stop the animation, issue in the Slime REPL:

(setf *sleep-time* nil)

If it wasn't already obvious, you can plot w/e.

 #'tanh :min-x (- 0 pi pi) :max-x pi :min-y -1.1 :max-y 1.5 :ink +blue+)

Drawning class hierarchy

Type ,clear output history in the Listener REPL and RET to clear the screen.

"," indicates that you are activating a command. Try typing comma, then C-/ to activate completion. C-c C-c to dismiss.

Children of the class CLIMI::SHEET can be drawn on using arbitrary geometry. Try (clim-listener::com-show-class-subclasses 'sheet) in the Listener REPL to view the subclasses of it.

Commands and presentations

The name COM-whatever indicates that the function in question is a clim command, which you can define in the Slime REPL like so,

(in-package clim-listener)

;;; Runme! We will need these in a moment.
(dolist (image-name '("mp-avatar.png"
  (uiop:run-program (format nil "curl --output /tmp/~A" 
                            image-name image-name)))

(define-listener-command (com-ls :name t)
  ((path 'string))
  (clim-listener::com-show-directory path))

try ,ls /tmp/ -- then ,display image <SPACE> and click on one of the displayed paths to supply it as an argument. At the core of CLIM is the notion of a presentation. Objects have presentation methods, ie, some arbitrary rendering geometry, and when PRESENT'd on the screen CLIM remembers the type. Thus one can supply objects of the appropriate types as arguments to a command simply by clicking on them. Read about CLIMI::DEFINE-COMMAND in the specification to learn more. Let's define our first presentation method.

Intermixing S-expressions with the presentation types

Evaluate the forms below in the Slime REPL:

(in-package climi)

(defvar lords '("mircea_popescu" "asciilifeform" "ben_vulpes"))

(defclass wot-identity ()
  ((name :accessor name :initarg :name :initform nil)
   (avatar :accessor avatar :initarg :avatar :initform nil)))

(defmethod lord? ((i wot-identity))
  (member (name i) lords  :test #'string=))

(define-presentation-type wot-identity ())

(defun make-identity (name avatar-pathname)
  (make-instance 'wot-identity
         :name name
         :avatar avatar-pathname))

(defparameter *identities*
  (mapcar (lambda (l) (apply #'make-identity l))
          '(("mircea_popescu" #P"/tmp/mp-avatar.png")
        ("ben_vulpes" #P"/tmp/vulpes-avatar.png")
        ("asciilifeform" #P"/tmp/stas-avatar.png")
        ("Suit" #P"/tmp/suit-avatar.png")
        ("RainbowDash" #P"/tmp/rainbow-dash-avatar.png")
        ("ChaosLord" #P"/tmp/chaos-lord-avatar.png"))))

(define-presentation-method present (object (type wot-identity)
                                            (view textual-view)
                                            &key acceptably)
  (declare (ignorable acceptably))
  (multiple-value-bind (x y)
      (stream-cursor-position stream)
    (with-slots (name avatar) object      
      (draw-pattern* stream
                     (climi::make-pattern-from-bitmap-file avatar :format :png)
                     (+ 150 x)
                     (+ 30 y))
      (draw-text* stream name (+ 153 x) (+ 167 y)
                  :ink +black+
                  :text-size 20)
      (draw-text* stream name (+ 152 x) (+ 166 y)
                  :ink (if (lord? object)
                  :text-size 20))
    (setf (stream-cursor-position stream)
          (values x (+ 200 y)))

(defun eval-and-then-call-me-in-the-listener ()
  (let* ((n 8)
         (sheet *standard-output*))
    (labels ((gen (i)
                (let* ((out-and-start '(f x)))
                   for k from 0 to i
                   do (setq out-and-start 
                            (apply #'append
                                    (lambda (s)
                                      (case s
                                        ;; (x '(y f + f f + + x)) 
                                        ;; (y '(y f + f f x - - f f x))
                                        (x '(+ y f + f f + y y +))
                                        (y '(f - y f f x f f))
                                        )) out-and-start))))
                  (remove-if (lambda (sym)
                               (member sym '(x y) :test 'eq))

      (let* ((x 300) (y 300) (new-x x) (new-y y) (a 1) (step 15))
         for r in (gen n)
         do (progn (cond ((= a 1) (setq new-y (+ step y)))
                         ((= a 2) (setq new-x (- x step)))
                         ((= a 3) (setq new-y (- y step)))
                         ((= a 4) (setq new-x (+ step x))))
                   (case r
                     (f (clim:draw-line* sheet x y new-x new-y
                                         :ink clim:+blue+
                                         :line-thickness 6
                                         :line-cap-shape :round)
                        (setq x new-x y new-y))
                     (- (setq a (if (= 1 a) 4 (1- a))))
                     (+ (setq a (if (= 4 a) 1 (1+ a))))
                     (t nil)))))
      (let* ((x 300) (y 300) (new-x x) (new-y y) (a 1) (step 15))
         for r in (gen n)
         do (progn (cond ((= a 1) (setq new-y (+ step y)))
                         ((= a 2) (setq new-x (- x step)))
                         ((= a 3) (setq new-y (- y step)))
                         ((= a 4) (setq new-x (+ step x))))
                   (case r
                     (f (clim:draw-line* sheet x y new-x new-y
                                         :ink clim:+white+
                                         :line-thickness 2
                                         :line-cap-shape :round)
                        (setq x new-x y new-y))
                     (- (setq a (if (= 1 a) 4 (1- a))))
                     (+ (setq a (if (= 4 a) 1 (1+ a))))
                     (t nil))))))))

Now type (dolist (i *identities*) (present i)) at the CLIM Listener.

Try typing (lord? at the listener and then clicking on one of the identities. Add a closing paren and RET. Notice how objects can be seamlessly intermixed with S-expressions. If this example fails for you it may be that you have not recent enough version of McCLIM.


Unripe fruits. The future isn't what it used to be - some assembly required.

  • (CLIM-DEMO::DEMODEMO) (available with system clim-examples)

  • The essential machinery of a 'live' GUI builder

  • Navigator (essentially an extended `apropos')

Marco AntoniottiCL-UNIFICATION bug fixing

· 96 days ago

Thanks to Masayuki Takagi, a not-so-obvious bug was fixed in the basic unification machinery of CL-UNIFICATION.  This led to the addition of a couple of new utility functions and some other cleanups (hopefully).

The result should be in Quicklisp in the next round.  Otherwise you can always clone/update/pull from the main repository.


Nicolas HafnerGo FORth - Confession 66

· 103 days ago

As part of yet another yak-shaving quest I've come to write a library that I only now realise I've been missing for a while: an extensible and generic iteration macro.

Now, you might be familiar with the Iterate library that is supposed to fill some of the same niches as For does. Despite being available for a very long time, Iterate is not very commonplace as far as I've been able to tell. Most people still use the Common Lisp standard loop, do* or map* variants- I do too.

I've tried to get into iterate multiple times, but I never really was able to get along with it, especially when it came to figuring out how to extend it for further constructs. Now, naturally this may just be my problem, but nevertheless I'm bold enough to consider that enough justification for me to go ahead and write my own attempt at a solution for the problem. I won't elaborate why I don't like iterate here as I believe there isn't much constructive or useful input to be gained from doing so.

Instead I will try to illustrate what For does, why it does it, and how it does it. A good part of that is already covered in the documentation but I will allow myself to be a bit more prosaic rather than declarative here. So let's dive in and have a look at the most simple of loops- an infinite one!

(for ())

Absolutely breathtaking.

The main idea behind For in contrast to Loop and Iterate is to mirror the structure of let. As such we always have a list of bindings and a body. Unlike let however, every variable is followed by a symbol that describes what kind of binding it is- how it is initialised, stepped, how if at all it terminates the loop, and whether it delivers a return value. So let's take a look at something a bit more sophisticated.

(for ((i ranging 1 10))
  (print i))

Here we see an actual binding in action. We bind a variable i using the ranging type with the arguments 1 and 10. As probably expected this will go through the numbers 1 to 10 and print each of them. Bindings can accept any number and kind of argument they want to:

(for ((i ranging 1 10 :by 2))
  (print i))

And now it will step by twos. Stunning.

Similar to Loop, For can of course also iterate over various sequences and other objects. Out of the box iteration bindings for lists, vectors, hash-tables, and packages is provided. Also just like loop we can accumulate values in various ways. Here too we support the same things as Loop does, namely collecting, appending, nconcing, counting, summing, maximising, minimising.

Additionally however, For provides a generic iterator mechanism for the cases where you do not really know or care what type your sequence is. This can also be used to update the sequence in-place if doing so makes sense. Let's see a practical example of converting a generic kind of sequence into a list:

(for ((item over my-sequence)
      (list collecting item)))

This will function without any work required from you for lists, vectors, arrays, streams, wild pathnames, packages, and hash-tables. It can also be extended to be able to iterate over any kind of sequence you might want by writing a new iterator class and the implementation for three simple methods.

Sometimes it's also necessary to terminate the loop according to some condition, and a binding does not seem like the correct place to put this kind of constraint. This is why in addition to bindings we have clauses that can appear in the body of the For.

(for ((i from 0))
  (while (< i 10))
  (print i))

This is nice and can easily be implemented by a macrolet. At least that's what I went for until I started trying to wrap my brain around the problem of return values. Some clauses like thereis would like to return a value- in this case whether the test has succeeded at all.

In the case of bindings where we have full control over the expressions and literals we can easily transform them however we want. This allows bindings to establish forms that wrap around the For body, add return values, and so on. However, in the case of clauses implemented through a macrolet the expansion happens within the body and at a different time. It is thus impossible¹ for the clause macro to communicate that it would like to hook into the mechanism surrounding the body. We could do it at run-time of course, but that would mean run-time consing and unnecessary tests every iteration- way too costly.

So, unfortunately I had to retract that idea and instead go for a minimal code-walking. It is so minimal that I don't know if it can even really be called that. What For now does is look through each item in its body, test whether it is a cons with a symbol in its car that refers to a clause, and if so call the clause expander function for that. This allows us to give clauses the same amount of power as bindings have and fixes the issues we had before. As you can see however there is a cost associated with it. In order to avoid full-blown code-walking (something understandably frowned upon) we can only recognise literal top-level For body expressions as clauses.

Nevertheless I think this is a small price to pay. The amount of times I would want to use a clause within another form seems very minimal to me at this point in time. Who knows though, I may come to eat my words at a later date.

Another thing worth mentioning I think is the actual extension mechanism of For itself. As per usual for my systems there's varying levels of support to help you, but you can always ignore them and just get full control so you can define exactly what's going on how.

So- the lowest we can go is defining a clause or binding function directly. We can define the above while clause like that simply enough. After all, all it needs to do is expand to a test that ends the loop if passed instead of the clause form.

(define-direct-clause while (form)
  (values NIL `(unless ,form (end-for)))

Generally if we think about what an iteration is about, we can distinguish three sections: an initialisation that introduces some values and initialises them, a body section that is executed on every step, and an end section that determines a return value. This is reflected in the three values that a binding or clause function must return- a form to wrap around the rest of the For block, a form to evaluate every step, and an optional form to evaluate as a return value if we think we have data that would be useful to return. To illustrate the return value we'll also look at the returning clause, which is useful if we have a non-standard value we'd like to give back, or if we want to force the primary value to something else.

(define-direct-clause returning (form)
  (values NIL NIL form))

All return values from bindings and clauses are gathered together into a single values form at the end of the For. This allows us to have multiple collect bindings or combine an accumulation with a clause and things like that. In general it's just convenient to allow the loop to return multiple values.

Most bindings and clauses outside of the most primitive ones will want to establish some kind of helper variables around the loop to keep, say, the head and tail of the list being accumulated. In order to provide this conveniently the &aux arguments in the lambda-list of the next definition macros are rewritten such that their value inside the definition body is a gensym and it automatically expands to a let that binds the gensym to the specified value. Thus writing our collecting binding becomes very simple:

(define-form-binding collecting (var form &aux (head (cons NIL NIL)) (tail head))
  `(setf ,tail (setf (cdr ,tail) (cons ,form NIL))
         ,var (cdr ,head)))

The head and tail are bound to fresh gensyms in the body, so they insert gensyms into our backquote expression. Simultaneously the definition takes care of the first return value for us by constructing an appropriate let* form that binds the gensym contained in head and tail to (cons NIL NIL) and head respectively. This form is then wrapped around the rest of the For so that the variables are available within the body.

Finally, often times we also know that all of the arguments passed to the binding need to only be evaluated once before the loop. To make this convenient we have define-value-binding which treats the actual binding arguments similar to how the &aux arguments work. Using this, defining something like across becomes trivial as well:

(define-value-binding across (var vector &aux (i -1) (length (length vector)))
  `(if (= ,length (incf ,i))
       (update ,var (aref ,vector ,i))))

But just as mentioned before, if you don't trust the system to do this for you or simply don't like it, you can always return to the low-level definition macros and do the plumbing yourself.

Given that For allows you to both expand into body forms, surrounding forms, and return value forms, I think it is safe to say that pretty much every feature you might need to express in an iterator can be done and without much to write either. Take a look at the definitions of the standard bindings and clauses to get a feel for it.

Finally I'd like to take a look at the previously mentioned iterator system that For bundles with it. As stated, there's very little you need to do to add support for a new data type. Subclass iterator, add methods for has-more, next, and make-iterator and you're done. With that in place, you can directly go ahead and use the over binding to go through your sequence. If it makes sense you can also add support for (setf current), enabling you to use the updating binding which permits setting the current element in the sequence as well.

All in all I hope that I've figured out some good solutions to the problems presented by an extensible looping construct. Since the system is still very young, I don't really have too much experience with it myself yet and can't make any grand claims like this being the "be all end all iteration macro" or whatever. But it doesn't have to be that either. It solves the problem that drove me into this direction, as well as a few other ones on top of that, so I'm fine with it being what it is. If I've managed to convince you to look at For to see if it fits into your toolbelt, then I would already have achieved much more than I initially set out to do.

[1] This is not quite true, as pointed out to me by Mark Cox. It is indeed possible to make macros communicate with a bit of ingenuity. Relevant to this are the COMPILER-LET-CONFUSION Issue in the CLHS, and an example he was kind enough to write up to illustrate it.

Luís OliveiraRe: Querying plists

· 104 days ago
Zach's Querying plists blog post showcases a neat little querying DSL for plists. I couldn't shake the feeling that it looked an awful lot like pattern matching. I've often been impressed by optima, but I barely get to use it, so I thought I should try and see what querying plists looked like using pattern matching.

Here's what I came up with. Zach's example
(query-plists '(:and (:= :first-name "Zach") (:= :state "ME")
                     (:not (:= :last-name "Beane")))
(remove-if-not (lambda-match ((plist :first-name "Zach" :state "ME"
                                     :last-name (not "Beane")) t))

It turned out more succinct than I initially expected! Also, it's trivially adaptable to other kinds of objects. E.g., given the following class:
(defclass person ()
  ((first-name :initarg :first-name)
   (last-name  :initarg :last-name)
   (state      :initarg :state)))
all we have to do is swap plist with the class name person and we're all set:
(remove-if-not (lambda-match ((person :first-name "Zach" :state "ME"
                                      :last-name (not "Beane")) t))

We can't quite define something exactly like Zach's query-plists because, AFAICT, optima's patterns are not first-class objects but perhaps we can cheat a little bit.
;; naming things is hard. :-/
(defmacro matchp (pattern) `(lambda-match (,pattern t)))
(defun filter (predicate list) (remove-if-not predicate list))

(filter (matchp (plist :first-name "Zach" :state "ME"
                       :last-name (not "Beane")))

Making this equally succinct when the query criteria are not constant is a challenge for another day and makes it clear that matchp is a lousy abstraction. ;-)

Zach BeaneQuerying plists

· 108 days ago

For normal, “serious” data, I like to stick things in a database and uses its query system to full effect. But sometimes I have a temporary need to work on a bunch of temporary data in plist form, and want to easily poke through it. Here’s the latest version of something I find myself doing pretty often for that:

(defun compile-plist-query (query)
  (labels ((callfun (object)
             (lambda (fun)
               (funcall fun object)))
           (compile-= (keyword value)
             (lambda (plist)
               (equal (getf plist keyword) value)))
           (compile-and (funs)
             (lambda (plist)
               (every (callfun plist) funs)))
           (compile-or (funs)
             (lambda (plist)
               (some (callfun plist) funs)))
           (compile-not (fun)
             (lambda (plist)
               (not (funcall fun plist)))))
    (let ((operator (first query))
          (operands (rest query)))
      (ecase operator
         (compile-= (first operands) (second operands)))
         (compile-and (mapcar #'compile-plist-query operands)))
         (compile-or (mapcar #'compile-plist-query operands)))
         (compile-not (compile-plist-query (first operands))))))))

(defun query-plists (query plists)
  (remove-if-not (compile-plist-query query) plists))

With the definitions above, I can use any combination of logic for querying the plists for particular property values:

(query-plists '(:and (:= :first-name "Zach") (:= :state "ME")
                     (:not (:= :last-name "Beane")))

This is similar to the MP3 query system described in Practical Common Lisp, but a little simpler and self-contained, suitable for random-ish plist structure.

Zach BeaneCCL "office hours"

· 112 days ago

Nice idea from Matt Emerson:

I don’t know if anyone will find it useful, but as an experiment, I’ve decided to try holding IRC “office hours” on #ccl on

So, on Tuesday, July 5, from 10:00 am to 11:00 am and 4:00 pm to 5:00 pm Eastern time (that’s 14:00 to 15:00 and 20:00 to 21:00 UTC), I’ll be available in the channel to talk about whatever you want, as long as it relates to CCL somehow.

If you don’t have an IRC client, you can use Enter your preferred nickname (I use “rme” for myself, for example) in the nickname field, and use “#ccl” for the channels field. Leave the “Auth to services” checkbox unchecked.

Clozure CL BlogCustomizing the listener prompt

· 115 days ago

Clozure CL’s default prompt is “? “.  You can customize this by setting ccl:*listener-prompt-format* to a format control of your choice.

Note that a format control “string” can be a function.  Here’s an example that makes the prompt contain the current package name.

(defun prompt-formatter (stream break-level)
  (princ (package-name *package*) stream)
  (if (plusp break-level)
    (format stream " ~d > " break-level)
    (write-string "> " stream)))

To start using this, do

(setq ccl:*listener-prompt-format* #'prompt-formatter)

Quicklisp newsJune 2016 Quicklisp dist update now available

· 116 days ago
New projects:
  • cl-libfarmhash — Common Lisp Binding for Google's Farmhash. — MIT
  • cl-libhoedown — Common Lisp Binding for Hoedown. — MIT
  • cl-sat — Common Lisp API to Boolean SAT Solvers — LLGPL
  • cl-sat.glucose — CL-SAT instance to Glucose state-of-the-art SAT solver. This downloads the later 2014 version (2nd in the 2014 SAT competition). — LLGPL
  • cl-sat.minisat — Common Lisp API to minisat — LLGPL
  • floating-point-contractions — Numerically stable contractions of floating-point operations. — MIT
  • metering — Portable Code Profiling Tool — Public Domain
  • neo4cl — Basic library for interacting with Neo4J — MIT license
  • network-addresses — A network addresses manipulation library. — MIT
  • ugly-tiny-infix-macro — A tiny and simple macro to allow writing binary operations in infix notation — Apache License, Version 2.0
Updated projects3d-vectorsacclimationarchitecture.service-providercaveman2-widgetscity-hashcl-anacl-asynccl-autowrapcl-conspackcl-hash-utilcl-htmlpragcl-i18ncl-messagepack-rpccl-monitorscl-mysqlcl-oclapicl-odecl-rediscl-scancl-sdl2clackclack-static-asset-middlewareclinchcloser-mopcopy-directorycss-selectorsdeedsdefpackage-plusdjulaeazy-projectepigraphesrap-liquidexscribefast-iofixedglkitglsl-specgsllhash-setinlined-generic-functionlegitlocal-timelquerymap-setmcclimminheapmontezumaoclclprometheus.clqt-libsrestasscribblesdl2kitserapeumsmart-bufferspinneretsquirltriviatrivial-nntptrivial-openstacktrivial-wstrivial-yencubiquitousutilities.binary-dumputilities.print-treeverbosevomweblocksweblocks-utilswoowookiewu-sugarzs3.

Removed projectsbackportsext-blogstp-query, and stringprep have all been abandoned by their author and deleted from github. cells no longer builds on SBCL, and ext-blog no longer builds at all.

To get this update, use (ql:update-dist "quicklisp").

The big Quicklisp fundraiser is still in limbo. Until it happens, if you want to contribute a little every month, see the (unfortunately PayPal-only) donations page.

ECL NewsECL Quarterly Volume IV

· 130 days ago

1 Preface


I've managed to assemble the fourth volume of the ECL Quarterly. As always a bit off schedule but I hope you'll find it interesting.

This issue will revovle around ECL news, some current undertakings and plans. Additionally we'll talk about Common Lisp implementations in general and the portability layers. I believe it is important to keep things portable. Why? Keep reading!

Lately we're working with David O'Toole on making support for ECL on Android better. He wants to distribute his games on this platform and was kind enough to write an article for ECL Quarterly. Thanks to his work we've discovered various rough edges and bugs in ECL and gained some invaluable insight into the cross compilation problems of Common Lisp applications.

As the final remark - I've found some time to establish a proper RSS subscription feed for ECL and ECL Quarterly. I hope that this issue will finally land on the Planet Lisp - a well known Lisp-related blog posts aggregator maintained by Zach Beane.

I want to thank for the valuable feedback and proofreading to many people, especially Antoni Grzymała, Javier Olaechea, Michał Posta, Ilya Khaprov and David O'Toole.

Have a nice lecture,

Daniel Kochmański ;; aka jackdaniel | TurtleWare
Poznań, Poland
June 2016

2 ECL's "what's going on"

I've added a milestone with a deadline for the ECL 16.1.3 release with the bugs I want to fix. You may find it here. I'm very happy to receive a lot of positive feedback, merge requests and awesome bug reports. Thank you for that! :-)

Backporting CLOS changes from CLASP was successful but we won't incorporate them in the main branch. The recently resurrected cl-bench has shown that these changes impact performance and consing negatively (check benchmarks). If you are curious about the changes, you may checkout the branch feature-improve-clos in the repository.

I'm slowly working on the new documentation. This is very mundane task which I'm not sure I'll be able to finish. Rewriting DocBook to TexInfo and filling the missing parts is hard. I'm considering giving up and improving the DocBook instead.

In the near future I plan to make a crowdfunding campaign to improve support for cross-compilation, Android and Java interoperability in order to boost development. More details will be probably covered in the next Quarterly issue.

3 Porting Lisp Games to Android with Embeddable Common Lisp, Part 1

3.1 Introduction

Recently I ported my Common Lisp game engine "Xelf" to the Android operating system using Embeddable Common Lisp.

Some work remains to be done before I can do a proper beta test release, but ECL Quarterly provides a good opportunity to pause and share the results thus far. This is the first part of a two-part article. The focus of Part 2 will be on performance optimization, testing, and user interface concerns.

Special thanks to Daniel Kochmański, 3-B, oGMo, and the rest of the Lisp Games crew for their inspiration and assistance.

3.1.1 About the software

Xelf is a simple 2-D game engine written in Common Lisp. It is the basis of all the games I have released since 2008, and can currently be used with SBCL to deliver optimized standalone game executables for GNU/Linux, MS Windows, and Mac OSX.

I've also published a Git repository with all the work-in-progress scripts, patches, and libraries needed to compile Xelf for Android with Embeddable Common Lisp, OpenGL, and SDL.

Please note that this is a pre-alpha release and is mainly intended for Common Lisp developers looking to get a head start in building an Android game. Use with caution.

Xelf is not required; you can substitute your own Lisp libraries and applications and just use the repo as a springboard.

I would like to add support for CL-SDL2 as well, both as a prelude to porting Xelf to SDL 2.0, and as a way to help the majority who use SDL 2.0 for current projects.

3.2 Problems

3.2.1 Choosing an implementation

As I use only Free Software for my projects, I did not consider any proprietary Lisps.

Steel Bank Common Lisp now runs on Android, but SBCL as a whole cannot yet be loaded as a dynamic shared library. This is a show-stopper because Android requires the entry point of a native application to be in a shared library specially embedded in the app.

Xelf works very well with Clozure Common Lisp, but CCL's Android support is not fully functional at present. So I've been quite happy to discover Embeddable Common Lisp. Its technique of translating Common Lisp into plain C has made integration with the Android NDK toolchain relatively simple.

3.2.2 Cross-compilation

For performance reasons the Lisp stack (meaning LISPBUILDER-SDL, CL-OPENGL, CFFI, Xelf, the game, and all their dependencies) must be compiled to native ARM machine code and loaded as shared libraries.

There is a complication in this task as regards ECL. The latter produces native code by translating Common Lisp into plain C, and then invoking the C compiler. But the C compiler toolchain is not typically present on Android, and building one that is properly configured for this task has proved difficult so far.

Therefore we must cross-compile the entire Lisp stack. ECL's Android build procedure already cross-compiles the Lisp contained in ECL, but there were additional difficulties in compiling Lisp libraries which I'll cover below in the "Solutions" section.

3.2.3 Legacy code

Xelf has improved a lot over time and gained new features, but is now outdated in some respects. When I first wrote Xelf in the 2006-2007 period SDL 1.2 was current and OpenGL Immediate mode had not yet been officially deprecated. This hasn't been a terrible problem in practical terms, given that both are still widely supported on PC platforms. But porting to Android would mean I could not procrastinate any longer on updating Xelf's SDL and OpenGL support.

3.3 Solutions

3.3.1 CommanderGenius to the rescue

Help arrived for my SDL woes in the form of Sergii Pylypenko's "CommanderGenius", a fancy port of SDL 1.2/2.0 to Android. I can utilize the existing LISPBUILDER-SDL bindings for SDL, SDL-MIXER, SDL-TTF, SDL-IMAGE, and SDL-GFX. Not only that, there are extra features such as gamepad support, floating virtual joysticks, access to touchscreen gesture data and Android system events, support for the Android TV standard, and much more.

CommanderGenius is actually designed from the start to rebuild existing SDL 1.2 / 2.0 / OpenGL projects as Android applications, and includes dozens of examples to work with. So in mid-May this year I set about splicing together Daniel Kochmański's ECL-ANDROID Java wrapper and startup code (which together load ECL as a shared object from within the app) into the CommanderGenius SDL application code and build procedures.

The result is a fullscreen SDL/OpenGL application with Embeddable Common Lisp, optionally running Swank. There's even a configurable splash screen!

3.3.2 Do a little dance with ASDF

ECL can compile an entire system into one FASL file, but I ran into a snag with the ASDF-based build procedure. The typical way is to compile each Lisp file and then load the resulting compiled file. But on the cross-compiler,

(load (compile-file "myfile.lisp"))

fails because the output of COMPILE-FILE is a binary for the wrong architecture. Likewise, alien shared libraries cannot be loaded during Lisp compilation, which broke CL-OPENGL and LISPBUILDER-SDL.

My temporary solution was to redefine the function ASDF:PERFORM-LISP-LOAD-FASL in my build script. My modified version does something like this instead:

(compile-file "myfile.lisp")
(load "myfile.lisp")

I then invoke ECL's system builder, which spits out a big binary FASB file containing the whole system. But thanks to the LOAD statements, each Lisp file has had access to the macros and other definitions that preceded it in compilation.

I'm sure this is really wrong, but it works, and the resulting FASBs load very quickly. (App startup time went from over 30 seconds when loading byte-compiled FASCs, to about 3.5 seconds.)

In the end, it was simple to deal with CL-OPENGL and LISPBUILDER-SDL wanting to open shared libraries during compilation. I used Grep to find and then comment out calls to CFFI:USE-FOREIGN-LIBRARY, leaving the DEFINE-FOREIGN-LIBRARY definitions intact. This allows cross-compilation to proceed normally.

Then on Android, after the FASBs are loaded I invoke USE-FOREIGN-LIBRARY on each of the required definitions.

So tricking ASDF works. But aside from being a hack, it's not enough for some of the things I'd like to do. The INLINED-GENERIC-FUNCTION technique looks like a highly promising way to increase performance, but my cross-compilation trick led in this case to invalid FASB's with embedded FASC bytecodes. Indeed, to work with ECL in this situation would require actually loading the ARM-architecture compiled INLINED-GENERIC-FUNCTION binary before compiling systems that use inlining—which as mentioned above cannot be done during cross-compilation.

I'm exploring other potential solutions, such as installing a GNU/Linux container on my Android development unit in order to give ECL access to a native C compiler toolchain (see below). I may even attempt to write a custom cross-compilation procedure using Clang and LLVM. But this is less urgent for now, because tweaking ASDF is sufficient to produce a working application.

3.3.3 Use OpenGL ESv1 with CL-OPENGL

Luckily the the path of least resistance could prevail here. OpenGL ES version 1 is widely supported on Android devices, and is easier to port to from Immediate mode than is GLESv2. CL-OPENGL supports it right out of the box. (I'd like to thank 3-B and oGMo for their help in bridging the gap with my own code.)

Some tasks remain to be done here but most of Xelf's drawing functions are now working, including TrueType fonts and vertex coloring.

I've also written some code to partially emulate vertex coloring as a way of increasing render performance, and this will be covered in the forthcoming Part 2 of this article.

3.3.4 ProTip: Use the byte-compiler

One issue has gone unmentioned. How do I interactively redefine functions and set variables in order to develop the running game via SLIME/Swank, if everything must be cross-compiled on an X86 system?

The answer is that ECL's built-in bytecode compiler is used in these cases, and the bytecoded definitions replace the originals. I can freely use COMPILE-FILE, LOAD, and even ASDF:LOAD-SYSTEM during "live" development; under normal circumstances the only real difference is execution speed of the resulting code. The final game app will ship without Swank, of course, and with a fully native Lisp stack.

Now you have a new problem, which is how to edit the Lisp files on your Android device so that Swank can compile and load them.

3.3.5 ProTip: Use Emacs TRAMP with ADB

To make this useful you need a rooted android device.

(add-to-list 'tramp-default-user-alist '("adb" nil "root"))
(find-file "/adb::/")

This can integrate with Emacs' "bookmarks" and "desktop" features for even more convenience.

3.3.6 ProTip: Use Emacs to inspect your APK package

They're just zip files. Missing libraries or assets? Check the APK by opening it as a file in GNU Emacs.

3.3.7 ProTip: Use a GNU/Linux container for SSH and native Emacs with X11!

You can actually install a GNU/Linux "container" with Debian, Ubuntu, or some other distribution on your Android development system in order run the Secure Shell daemon and many other applications. I use it to run a graphical Emacs on the Android box, with Emacs' X11 connection forwarded through SSH so that its windows open on my desktop GNU/Linux PC's X server—right alongside my native Emacs. I use different color themes to avoid mixing them up.

This gives me full access to everything on both systems from a single mouse/keyboard/monitor, and I can cut and paste text freely between applications.

Setting up such a container is beyond the scope of this article, but I highly recommend it. It was pretty easy on a rooted device, and works very well.

3.4 Conclusion

In less than a month we went from "let's do it" to "wow, it works!" What more can you ask for?

This concludes Part 1 of my article on building Lisp games for Android with Embeddable Common Lisp. To read my running commentary and see news and test results as they are posted, you can visit the project README:

More details and all scripts and configurations can be found in that repository.

Thanks for reading,

David O'Toole (
11 June, 2016

4 Common Lisp implementations

Some time ago I've created with the help of many kind people (most notably from Rainer Joswig and Fare Rideau) a graph presenting Common Lisp implementations and the relations between them. This version is improved over drafts presented on twitter and linkedin. If you find any errors, please contact me.


It is worth noting that LispWorks and VAX share the code with Spice Lisp which later evolved into Common Lisp implementation CMUCL. Striped lines lead to CMUCL, because I didn't want to add pre-CL implementations.

There is also suspicion that Lucid shares code with Spice Lisp and/or VAX, but I couldn't confirm that, so I'm leaving it as is.

"JavaScript Lisp Implementations" classifies some lisps as CL, but I've added only Acheron and parenscript to the list, because rest is just CL-ish, not even being a subset.

Resources I've found on the internet: CMU FAQ, ALU list, CLiki overview, Wikipedia article, JavaScript Lisp Implementations.

5 Building various implementations

I've built various lisps to perform some benchmarks and to have some material for comparison. Ultimately I've decided to polish it a little and publish. I had some problems with Clasp and Mezzano so I've decided to not include them and leave building these as an exercise for the reader ;-). Also, if you feel adventurous, you may try to build Poplog, which has Common Lisp as one of the supported languages.

If you want to read about various implementations, please consult Daniel's Weinreb Common Lisp Implementations: A Survey (material from 2010, definitely worth reading).

First we create a directory for the lisp implementations (we'll build as an ordinary user) and download the sources. Each implementation has a list of building prerequisites, but it may be not comprehensive.

export LISPS_DIR=${HOME}/lisps
mkdir -p ${LISPS_DIR}/{src,bin}
pushd ${LISPS_DIR}/src

# Obtain sources
svn co abcl
# git clone
svn co ccl
hg clone clisp
git clone cmucl
git clone ecl
git clone git:// gcl
git clone jscl
# git clone
git clone mkcl
git clone git:// sbcl
git clone wcl
git clone

5.0.1 ABCL (Armed Bear Common Lisp)

jdk, ant
pushd abcl
cp abcl ${LISPS_DIR}/bin/abcl-dev

5.0.2 CCL (Clozure Common Lisp)

gcc, m4, gnumake
pushd ccl
echo '(ccl:rebuild-ccl :full t)' | ./lx86cl64 -n -Q -b

# installation script is inspired by the AUR's PKGBUILD
mkdir -p ${LISPS_DIR}/ccl-dev
cp -a compiler contrib level-* lib* lisp-kernel objc-bridge \
   tools x86-headers64 xdump lx86cl64* examples doc \

find ${LISPS_DIR}/ccl-dev -type d -name .svn -exec rm -rf '{}' +
find ${LISPS_DIR}/ccl-dev -name '*.o' -exec rm -f '{}' +
find ${LISPS_DIR}/ccl-dev -name '*.*fsl' -exec rm -f '{}' +

cat <<EOF > ${LISPS_DIR}/bin/ccl-dev
exec ${LISPS_DIR}/ccl-dev/lx86cl64 "\$@"
chmod +x ${LISPS_DIR}/bin/ccl-dev

5.0.3 CLISP

gcc, make
don't build with ASDF (it's old and broken)
pushd clisp
./configure --prefix=${LISPS_DIR}/clisp-dev/ \
            --with-threads=POSIX_THREADS \
cd build
make && make install
ln -s ${LISPS_DIR}/clisp-dev/bin/clisp ${LISPS_DIR}/bin/clisp-dev

5.0.4 CMUCL (CMU Common Lisp)

cmucl binary, gcc, make, openmotif
it needs another CMUCL to bootstrap (release 21a)
pushd cmucl
mkdir -p prebuilt
pushd prebuilt
wget \
mkdir ${LISPS_DIR}/cmucl-21a
tar -xf cmucl-21a-x86-linux.tar.bz2 -C ${LISPS_DIR}/cmucl-21a/
tar -xf cmucl-21a-x86-linux.extra.tar.bz2 -C ${LISPS_DIR}/cmucl-21a/
cat <<EOF > ${LISPS_DIR}/bin/cmucl-21a
exec ${LISPS_DIR}/cmucl-21a/bin/lisp "\$@"
chmod +x ${LISPS_DIR}/bin/cmucl-21a
# Note, that this is already a fully functional lisp now
bin/ -C "" -o "cmucl-21a"
bin/ -I ${LISPS_DIR}/cmucl-dev/ linux-4/
cat <<EOF > ${LISPS_DIR}/bin/cmucl-dev
exec ${LISPS_DIR}/cmucl-dev/bin/lisp "\$@"
chmod +x ${LISPS_DIR}/bin/cmucl-dev

5.0.5 ECL (Embeddable Common Lisp)

gcc, make
./configure --prefix=${LISPS_DIR}/ecl-dev/
make && make install
ln -s $LISPS_DIR/ecl-dev/bin/ecl ${LISPS_DIR}/bin/ecl-dev

5.0.6 JSCL (Java Script Common Lisp)

Conforming CL implementation, web browser, nodejs
Doesn't provide LOAD yet (no filesystem), but author confirmed that this will be implemented (virtual filesystem on the browser and the physical one on the nodejs).
mkdir ${LISPS_DIR}/jscl-dev
pushd jscl

# Run in the console (node-repl)
cp jscl.js repl-node.js ${LISPS_DIR}/bin/jscl-dev
cat <<EOF > ${LISPS_DIR}/bin/jscl-dev
exec node ${LISPS_DIR}/jscl-dev/repl-node.js
chmod +x ${LISPS_DIR}/bin/jscl-dev

# Run in the web browser (optional)
cp jscl.js repl-web.js jquery.js jqconsole.min.js jscl.html style.css \
# replace surf with your favourite browser supporting JS
cat <<EOF > ${LISPS_DIR}/bin/jscl-dev-browser
exec surf ${LISPS_DIR}/jscl-dev/jscl.html
chmod +x ${LISPS_DIR}/bin/jscl-dev-browser


5.0.7 GCL (GNU Common Lisp)

gcc, make
# Doesn't work both with head and the release, luckily it works with
# the next pre-release branch
git checkout Version_2_6_13pre
./configure --prefix=${LISPS_DIR}/gcl-2.6.13-pre
make && make install
ln -s ${LISPS_DIR}/gcl-2.6.13-pre/bin/gcl ${LISPS_DIR}/bin/gcl-2.6.13-pre

5.0.8 MKCL (Man-Kai Common Lisp)

gcc, make
pushd mkcl
./configure --prefix=${LISPS_DIR}/mkcl-dev
make && make install
ln -s ${LISPS_DIR}/mkcl-dev/bin/mkcl ${LISPS_DIR}/bin/mkcl-dev

5.0.9 SBCL (Steel Bank Common Lisp)

ANSI-compliant CL implementation
  • Lisp has to close on EOF in top-level (CMUCL doesn't do that),
  • ECL has some bug regarding Lisp-to-C compiler apparently triggered by the SBCL compilation - don't use it here,
  • we could use precompiled SBCL like with the CMUCL, but let's exploit the fact, that we can compile from the C-bootstrapped implementation (we'll use already built clisp-dev),
  • it is advised to run the script in fast terminal (like xterm) or in the terminal multiplexer and to detach it - SBCL compilation process is very verbose,
  • if you build SBCL on Windows, consider using MinGW to preserve POSIX compatibility.
pushd sbcl
export GNUMAKE=make
./ "clisp"
cat <<EOF > ${LISPS_DIR}/bin/sbcl-dev
SBCL_HOME=${LISPS_DIR}/sbcl-dev/lib/sbcl exec ${LISPS_DIR}/sbcl-dev/bin/sbcl "\$@"
chmod +x ${LISPS_DIR}/bin/sbcl-dev

5.0.10 WCL

tcsh, gcc, git
very incomplete implementation
pushd wcl
REV=`git rev-parse HEAD`
sed -i -e "s/WCL_VERSION = \"3.0.*$/WCL_VERSION = \"3.0-dev (git-${REV})\"/" CONFIGURATION
LD_LIBRARY_PATH=`pwd`/lib make rebuild
mkdir ${LISPS_DIR}/wcl-dev
cp -a bin/ lib/ doc/ ${LISPS_DIR}/wcl-dev/
cat <<EOF > ${LISPS_DIR}/bin/wcl-dev
LD_LIBRARY_PATH=${LISPS_DIR}/wcl-dev/lib exec ${LISPS_DIR}/wcl-dev/bin/wcl "\$@"
chmod +x ${LISPS_DIR}/bin/wcl-dev

5.0.11 XCL

last commit in 2011
pushd xcl
mkdir ${LISPS_DIR}/xcl-dev
XCL_HOME=${LISPS_DIR}/xcl-dev make
cp -a clos compiler lisp COPYING README xcl ${LISPS_DIR}/xcl-dev
# This will build in XCL_HOME, even if run in source directory
./xcl <<EOF

ln -s ${LISPS_DIR}/xcl-dev/xcl ${LISPS_DIR}/bin/xcl-dev

6 Portability libraries

It is important to know the difference between the language standard, implementation-specific extensions and the portability libraries. The language standard is something you can depend on in any conforming implementation.

Sometimes it's just not enough. You may want to do ** serializethreading*, or to *data, which is very hard to express (or even impossible) in the language provided by the standard. That's where the implementation-specific extensions kick in. Why are they called "implementation-specific"? Because the API may be different between implementations - reaching consensus is a hard thing1.

The most straightforward approach I can imagine is to reach for the documentation of the Common Lisp implementation you are currently using and to use the API provided by this implementation. I dare you not to do that! It's definitely the easiest thing to do at first, but mind the consequences. You lock yourself, and your users in the implementation you prefer. What if you want to run it on the JVM or to make it a shared library? Nope, you're locked-in.

"What can I do then?" - you may ask. Before I answer this question, I'll tell you how many people do it (or did it in the past) - they used read-time conditionals directly in the code. Something like the following:

(defun my-baz ()
  #+sbcl                        (sb-foo:do-baz-thing 'quux)
  #+ccl                         (ccl:baz-thing       'quux)
  #+(and ecl :baz-thing)        (ext:baz             'quux)
  #+abcl                        (ext:baz             'quux)
  #+(and clisp :built-with-baz) (ext:baz-thingie     'quux)
  #-(or sbcl ccl ecl abcl clisp)
  (error "Your implementation isn't supported. Fix me!"))

If the creator felt more fancy and had some extra time, they put it in the package my-app-compat. It's all great, now your application works on all supported implementations. If somebody wants theirs implementation to work, send the creator a patch, who incorporates it into the code and voila, everything works as desired.

We have one problem however. Libraries tend to depend on one another. There is also a lot of software which uses features beyond the ANSI specification (it's all good, programmers need these!). Do you see code duplication everywhere? How many times does a snippet above have to be copy-pasted, or rewritten from scratch? It's not black magic after all. APIs between ad-hoc implementations don't exactly match, covered CL implementations differ…

So you quickload your favorite library which depends on 10 other libraries which implement BAZ functionality in theirs own unique way, with a slightly different API on the unsupported implementation - that's why we have my-baz abstraction after all, right? Now, to make it work, a user has to:

  1. Find which of the ten libraries don't work (not trivial!),
  2. find and clone the repositories (we want to use git for patches),
  3. fix each one of them (grep helps!) and commit the changes,
  4. push the changes to your own forked repository and create a pull request (or send a diff to the mailing list) - *ten times*,
  5. voila, you're done, profit, get rich, grab a beer.

It's a lot of work which the user probably won't bothered to do. They will just drop the task, choose another implementation or hack their own code creating the Yet Another Baz Library for the implementations he cares for reinventing the wheel once more. It's a hacker's mortal sin.

I'm going to tell you now what is the Right Thing™ here. Of course you are free to disagree. When you feel that there is a functionality you need which isn't covered by the standard you should

  1. Look if there is a library which provides it.

    You may ask on IRC, the project's mailing list, check out the CLiki, do some research on the web. Names sometimes start with trivial-*, but it's not a rule. In other words: do your homework.

  2. If you can't find such a library, create one.

    And by creating such a library I mean comparing the API proposed by at least two CL implementations (three would be optimal IMHO), carefully designing your own API which covers the functionality (if it's trivial, this should be easy) and implementing it in your library.

    Preferably (if possible) add a fallback implementation for implementations not covered (with the appropriate warning, that it may be inefficient or not complete in one way or another).

    It may be worth reading the Maintaining Portable Lisp Programs paper written by Christophe Rhodes.

  3. Write beautiful documentation.

    A CL implementation docs may be very rough. It takes time to write them and programmers tend to prioritize code over the documentation. It's really bad, but it's very common for the documentation to be incomplete or outdated.

    Document your library, describe what it does, how to use it. Don't be afraid of the greatness! People will praise you, success will come, world will be a better place. And most importantly, your library will be useful to others.

  4. Publish the library.
  5. Make that library your project's dependency.

I know it's not easy, but in the long term it's beneficial. I guarantee you that. That's how the ecosystem grows. Less duplication, more cooperation - pure benefit.

Some people don't follow this path. They didn't think it through, or maybe they did and decided that keeping the dependency list minimal is essential to their project, or were simply lazy and hacked their own solution. There are also some old projects which exported a number of features being a very big portability library and an application at the same time (ACL-compat, McCLIM and others). What to do then?

If it's a conscious decision of the developer (who doesn't want to depend on /anything/), you can do nothing but provide a patch adding your own implementation to the supported list. It's their project, their choice, we have to respect that.

But before doing that you may simply ask if they have something against plugging these hacks with the proper portability library. If they don't - do it, everybody will benefit.

There are a few additional benefits of the presented portability library approach for the implementations itself. Having these internal details in one place makes it more probable that your implementation is already supported. If the library has a bug it's easier to fix it in one place. Also, if the CL implementation changes it's API, it's easy to propagate changes to the corresponding portability libraries. New CL implementation creators have a simplified task of making their work usable with existing libraries.

It is worth noting, that creating such library paves the way to the new quasi-standard functionalities. For instance Bordeaux Threads has added recently CONDITION-WAIT function, which isn't implemented on all implementations. It is a very good stimulus to add it. This is how library creators may have real impact on the implementation creators decisions about what to implement next.

6.1 Portability layer highlights

Here are some great projects helping CL implementations be part of a more usable ecosystem. Many of these are considered being part of the de-facto standard:

Provides thread primitives, locks and conditionals
Serializing and deserializing CL objects from streams
Foreign function interface (accessing foreign libraries)
Meta-object protocol - provides it's own closer-common-lisp-user package (redefines for instance defmethod)
TCP/IP and UDP/IP socket interface.
Osicat is a lightweight operating system interface for Common Lisp on POSIX-like systems, including Windows
Portable pathname library
trivial-garbage provides a portable API to finalizers, weak hash-tables and weak pointers
trivial-features ensures consistent *FEATURES* across multiple Common Lisp implementations
trivial-gray-streams system provides an extremely thin compatibility layer for gray streams
external-program enables running programs outside the Lisp process

There are many other very good libraries which span multiple implementations. Some of them have some drawbacks though.

For instance IOlib is a great library, but piggy-backs heavily on UN*X - if you develop for many platforms you may want to consider other alternatives..

UIOP is also a very nice set of utilities, but isn't documented well, does too many things at once and tries to deprecate other actively maintained projects - that is counterproductive and socially wrong. I'd discourage using it.

There are a few arguments supporting UIOP's state - it is a direct dependency of ASDF, so it can't (or doesn't want to) depend on other libraries, but many utilities are needed by this commonly used system definition library. My reasoning here is as follows: UIOP goes beyond ASDF's requirements and tries to make actively maintained projects obsolete. Additionally it works only on supported implementations even for features which may be implemented portably.

6.2 UIOP discussion

I'm aware that my opinion regarding UIOP may be a bit controversial. I've asked the library author and a few other people for feedback which I'm very grateful for. I'm publishing it here to keep opinions balanced.

6.2.1 Fare Rideau

Dear Daniel,

while there is a variety of valid opinions based on different interests and preferences, I believe your judgment of UIOP is based on incorrect premises.

First, I object to calling UIOP "not well documented". While UIOP isn't the best documented project around, all its exported functions and variables have pretty decent DOCSTRINGs, and there is at least one automatic document extractor, HEΛP, that can deal with the fact that UIOP is made of many packages, and extract the docstrings into a set of web pages, with a public heλp site listed in the UIOP The fact that some popular docstring extractors such as quickdocs can't deal with the many packages that UIOP creates with its own uiop:define-package doesn't mean that UIOP is less documented than other projects on which these extractors work well, it's a bug in these extractors.

Second, regarding the deprecation of other projects: yes, UIOP does try to deprecate other projects, but (a) it's a good thing, and (b) I don't know that any of the projects being deprecated is "actively maintained". It's a good thing to try to deprecate other lesser libraries, as I've argued in my article Consolidating Common Lisp libraries: whoever writes any library should work hard so it will deprecate all its rivals, or so that a better library will deprecate his and all rivals (such as optima deprecating my fare-matcher). That's what being serious about a library is all about. As for the quality of the libraries I'm deprecating, one widely-used project the functionality of which is completely covered by UIOP is cl-fad. cl-fad was a great improvement in its day, but some of its API is plain broken (e.g. the :directories argument to its walk-directory function has values with bogus names, while its many pathname manipulation functions get things subtly wrong in corner cases), and its implementation not quite as portable as UIOP (that works on all known actively used implementations). There is no reason whatsoever to ever choose cl-fad over UIOP for a new project. Another project is trivial-backtrace. I reproduced most of its functionality, except in a more stable, more portable way (to every single CL implementation). The only interface I didn't reproduce from it is map-backtrace, which is actually not portable in trivial-backtrace (only for SBCL and CCL), whereas serious portable backtrace users will want to use SLIME's or SLY's API, anyway. As for external-program, a good thing it has for it is some support for asynchronous execution of subprocesses; but it fails to abstract much over the discrepancies between implementations and operating systems, and is much less portable than uiop:run-program (as for trivial-shell, it just doesn't compete).

UIOP is also ubiquitous in a way that other libraries aren't: all implementations will let you (require "asdf") out of the box at which point you have UIOP available (exception: mostly dead implementations like Corman Lisp, GCL, Genera, SCL, XCL, may require you to install ASDF 3 on top of their code; still they are all supported by UIOP, whereas most portability libraries don't even bother with any of them). This ubiquity is important when writing scripts. Indeed, all the functionality in UIOP is so basic that ASDF needed it at some point — there is nothing in UIOP that wasn't itself required by some of ASDF's functionality, contrary to your claim that "UIOP goes beyond ASDF's requirements" (exception: I added one function or two to match the functionality in cl-fad, such as delete-directory-tree which BTW has an important safeguard argument :validate; but even those functions are used if not by ASDF itself, at least by the scripts used to release ASDF itself). I never decided "hey, let's make a better portability library, for the heck of it". Instead, I started making ASDF portable and robust, and at some point the portability code became a large chunk of ASDF and I made it into its own library, and because ASDF is targetting 16 different implementations and has to actually work on them, this library soon became much more portable, much more complete and much more robust than any other portability library, and I worked hard to achieve feature parity with all the libraries I was thereby deprecating.

Finally, a lot of the functionality that UIOP offers is just not offered by any other library, much less with any pretense of universal portability.

6.2.2 David Gu

For the documentation thing, I really think Quickdocs could do a better job. The bug #24 stated that problem, however, it's remain to be solved. I will check this out if I have free time recently.

I use UIOP a lot in my previous company, the reason is simple and maybe a little naive: my manager didn't want to involve too many add-ons in the software. UIOP is shipped together with ASDF, it's really "convenient", and its robustness is the final reason why I will stick to it. If people understand how UIOP came out in the history from ASDF2 to ASDF3, I think people will understand why it's acting like deprecating several other projects – that's not the original idea of it.

But anyway, I really learned a lot from this post and also the comments. In my opinion, avoid reinventing the wheels is the right idea and directions for this community. So from that perspective, I support @fare's idea "It's a good thing to try to deprecate other lesser libraries". Including this article and along with Maintaining Portable Lisp Programs and @fare's Consolidating Common Lisp Libraries, we should let more people involved in this topic.



If you are Common Lisp implementer and plan to add a feature beyond ANSI specification, please consider writing a proposal and submitting it to Common Lisp Document Repository. It will make everybody's life easier.

Michael MalisBuilding Fizzbuzz in Fractran from the Bottom Up

· 133 days ago

In this post, I am going to show you how to write Fizzbuzz in the programming language Fractran. If you don’t know, Fractran is an esoteric programming language. That means it is extraordinary difficult to write any program in Fractran. To mitigate this difficultly, instead of writing Fizzbuzz in raw Fractran, what we are going to do is build a language that compiles to Fractran, and then write Fizzbuzz in that language.

This post is broken up into three parts. The first part covers what Fractran is and a way of understanding what a Fractran program does. Part 2 will go over the foundation of the language we will build and how it will map to Fractran. Finally, in Part 3, we will keep adding new features to the language until it becomes easy to write Fizzbuzz in it.

Part 1: Understanding Fractran

Before we can start writing programs in Fractran, we have to first understand what Fractran is. A Fractran program is represented as just a list of fractions. To execute a Fractran program, you start with a variable N=2. You then go through the list of fractions until you find a fraction F, such that N*F is an integer. You then set N=N*F and go back to the beginning of the list of fractions. You keep repeating this process until there is no fraction F such that N*F is an integer.

Since there is no way to print anything with the regular Fractran rules, we are going to add one additional rule on top of the ordinary ones. In addition to the list of fractions, each program will have a mapping from numbers to characters representing the “alphabet” of the program. After multiplying N by F, whenever the new N is a multiple of one of the numbers in the alphabet, that will “print” the character that the number maps to. I have written a function, run-fractran, which implements this version of Fractran and included it here. It takes a list of fractions and an alphabet as an alist and executes the program.

Let’s walk through a simple example. Let’s say we have the following Fractran program:

9/2, 1/5, 5/3

with the alphabet 5->’a’. To run this program, we start with N=2. We then go through the list fractions until we find a fraction F such that N*F is an integer. On this first step, F becomes 9/2, since N*F = 2 * 9/2 = 9 which is an integer. We then set N to N*F so that N now becomes 9. Repeating this process again, we get F=5/3 and N=N*F=15. Since the number 5 is in the alphabet, and N is now a multiple of 5, we output the character that 5 maps to, ‘a’. If we keep repeating these steps, we eventually reach a point where N=1 and we have outputted the string “aa”. Since 1 times any of the fractions does not result in an integer, the program terminates with the output “aa”.

At this point, you may be thinking that writing any program in Fractran is nearly impossible. The truth is that there is a simple trick you can use that makes it much easier program Fractran. All you need to do is look at the prime factorization of all of the numbers. Let’s see what the above Fractran program looks like if we convert every number into a tuple (a,b,c) where a is the how many times 2 divides the number, b is how many times 3 does, and c is how many times 5 does. The program then becomes:

(0, 2, 0) / (1, 0, 0)
(0, 0, 0) / (0, 0, 1)
(0, 0, 1) / (0, 1, 0)

We also have the tuple (0,0,1) mapping to ‘a’ for our alphabet. We start with N = (1,0,0). If you don’t know, multiplying two numbers is the same as adding the counts of each prime factors, and division is the same as subtracting the counts. For example, 2 * 6 = (1,0,0) + (1,1,0) = (2,1,0) = 12. With this way of looking at the program, finding a fraction F such that N*F is an integer becomes finding a “fraction” F such that each element in the tuple N is greater than or equal to the corresponding element in the tuple in the denominator of F. Once we find such F, instead of multiplying N by it, you subtract from each element of N the corresponding value in the denominator of F (equivalent to dividing by the denominator), and add the corresponding value in the numerator (equivalent to multiplying by the numerator). Executing the program with this interpretation proceeds as follows.

We start with N = (1,0,0). Since every value in N is greater than or equal to their corresponding values in the denominator of the first fraction, we subtract every value in the first denominator and then add every value in the numerator to get N = (1,0,0) – (1,0,0) + (0,2,0) = (0,2,0). Repeating this again, F becomes the third fraction. Subtracting the denominator and adding the numerator gets us N = (0,1,1). Then since every value in N is greater than or equal to their corresponding element in (0,0,1), we print ‘a’. The program continues, just like it did for the original Fractran program.

Basically we can think of every prime number as having a “register” which can take on non-negative integer values. Each fraction is an instruction that operates on some of the registers. You can interpret a fraction as saying if the current value of each register is greater than or equal to the the value specified by the denominator (the number of times the prime for that register divides the denominator), you subtract from the registers all of the values in the denominator, add all the values specified in the numerator (the number of times the prime for each register divides the numerator), and then jump back to the first instruction. Otherwise, if any register is less than the value specified in the denominator, continue to the next fraction. For example, the fraction 9/2 can be translated into the following pseudocode:

;; If the register corresponding to the prime number 2 
;; is greater or equal to 1
if reg[2] >= 1
  ;; Decrement it by 1 and increment the register 
  ;; corresponding to 3 by 2. 
  reg[2] = reg[2] - 1
  reg[3] = reg[3] + 2
  goto the beginning of the program
;; Otherwise continue with the rest of the program.

Although programming Fractran is still difficult, this technique suddenly makes writing Fizzbuzz in Fractran tractable.

Part 2: Compiling to Fractran

For our compiler, we are going to need to generate a lot of primes. To do so, we will use a function, new-prime, which will generate a different prime each time it is called.1

(defun prime (n)
  "Is N a prime number?"
  (loop for i from 2 to (isqrt n)
        never (multiple n i)))

(defparameter *next-new-prime* nil)

(defun new-prime ()
  "Returns a new prime we haven't used yet."
  (prog1 *next-new-prime*
    (setf *next-new-prime*
          (loop for i from (+ *next-new-prime* 1)
                if (prime i)
                  return i))))

So now that we’ve got new-prime, we’ve we can start figuring out how we are going to compile to Fractran. The first detail we will need to figure out is how to express control flow in Fractran.  In other words, we need a way to specify which fractions will execute after each other fractions. This is a problem because after a fraction executes, you always jump back to the first fraction.

Expressing control flow actually winds up being surprisingly easy. For each fraction we can designate a register. Then, we only execute a fraction if its register is set. It is easy to have a fraction conditionally execute depending on whether its register is set by using the trick we are using to interpret a Fractran program. All we need to do is multiply the denominator of each fraction by the prime for the register of that fraction. This way, we will pass over a fraction unless its register is set. Also, all we need to do to specify which fraction should execute after a given fraction is to multiply the numerator of the given fraction by the prime of the register for the next fraction. By doing this, after a fraction executes, it will set the register of the next fraction.

In order to keep track of the primes for the current fraction and for the next fraction, we will have two global variables. The first will be the prime number for the current instruction, and the second will be the prime number for the next instruction:

(defparameter *cur-inst-prime* nil)
(defparameter *next-inst-prime* nil)

We will also need a function advance which will advance the values of the variables once we move on to the next instruction.

(defun advance ()
  (setf *cur-inst-prime* *next-inst-prime*
        *next-inst-prime* (new-prime)))

Now that we’ve got a way of expressing control flow, we can start planning out what the language we will build will look like. From this point on, I am going to call the language we are building, Lisptran. An easy way we represent a Lisptran program is as just a list of expressions. We can have several different kinds of expressions each of which does something different.

The simplest kind of expression we will want is an inline fraction. If a Lisptran expression is just a fraction, we can just add that fraction to the Fractran program being generated.

Another kind of expression that would be useful are labels. Whenever a Lisptran expression is a Lisp symbol, we can interpret that as a label. Each label will be converted into that fraction that is the prime of the next instruction after the label divided by the prime of the label. This way we can jump to the instruction after the label by setting the register for the label. In order to make keeping track of the primes of labels easy, we are going to keep a hash-table, *lisptran-labels*, mapping from labels to the primes for those labels. We will also have a function prime-for-label, which will lookup the prime for a label or assign a new prime if one hasn’t been assigned yet:

(defparameter *lisptran-labels* nil)

(defun prime-for-label (label)
  (or (gethash label *lisptran-labels*)
      (setf (gethash label *lisptran-labels*)

One last kind of expression that will be useful are macro calls. A macro call will be a list whose first element is the name of a macro followed by a list of arbitrary Lisp expressions (The expressions don’t have to be Fractran expressions. They can be interpreted however the macro wants them to be.). In order to compile a macro call, we will lookup the function associated with the macro, and call it on the expressions in the rest of the macro call. That function should then return a list of Lisptran expressions which will then be compiled in place of the macro call. After that we just continue compiling the new code generated by the macro expansion.

To keep track of the definitions of macros, we will keep a hash-table *lisptran-macros*, which will map from the name of the macro to the function for that macro. In order to make defining Lisptran macros easy, we can create a Lisp macro deftran, that works in a similar way to defmacro. When defining a macro with deftran, you are really just defining a function which will take the expressions in the macro call, and return a list of Lisptran instructions to be compiled in its place. Here is the definition for deftran:

(defparameter *lisptran-macros* (make-hash-table))

(defmacro deftran (name args &body body)
  "Define a Lisptran macro."
  `(setf (gethash ',name *lisptran-macros*)
         (lambda ,args ,@body)))

And that’s all of the different kinds of expressions we will need in Lisptran.

Although we now have all of the expressions we need, there are a few more pieces of the compiler we need to figure out. For example, we still haven’t figured out how we are going to represent variables yet. Ultimately this is trivial. We can just assign a register to every variable and keep a mapping from variable names to primes in the same way we have the mapping for labels:

(defparameter *lisptran-vars* nil)

(defun prime-for-var (var)
  (or (gethash var *lisptran-vars*)
      (setf (gethash var *lisptran-vars*)

One last piece of the compiler we need to figure out is how we are going to represent the alphabet of the program. One way we can do this is just represent the characters in our alphabet as variables. The alphabet of a program could just be all of the variables that have characters for names and the primes of the registers for those variables. By doing it this way, we can print a character by just incrementing and then immediately decrementing a variable! Here is code that can be used to obtain the alphabet from *lisptran-vars*:

(defun alphabet (vars)
  "Given a hash-table of the Lisptran variables to primes, 
   returns an alist representing the alphabet."
  (loop for var being the hash-keys in vars 
        using (hash-value prime)
        if (characterp var)
          collect (cons var prime)))

Now that we can express control flow, variables, and macros, we have everything we need to write the actual Lisptran to Fractran compiler:

(defun assemble (insts)
  "Compile the given Lisptran program into Fractran. 
   Returns two values. The first is the Fractran program 
   and the second is the alphabet of the program."
  (let* ((*cur-prime* 2)
         (*cur-inst-prime* (new-prime))
         (*next-inst-prime* (new-prime))
         (*lisptran-labels* (make-hash-table))
         (*lisptran-vars* (make-hash-table)))
    (values (assemble-helper insts)
            (alphabet *lisptran-vars*))))

(defun assemble-helper (exprs)
  (if (null insts)
      (let ((expr (car exprs))
            (rest (cdr exprs)))
          ;; If it's a number, we just add it to the 
          ;; Fractran  program and compile the rest 
          ;; of the Lisptran program
          ((numberp expr)
           (cons expr (assemble-helper rest)))

          ;; If it's a symbol, we divide the prime for 
          ;; the next instruction by the prime for the 
          ;; label.
          ((symbolp expr)
           (cons (/ *cur-inst-prime* 
                    (prime-for-label expr))
                 (assemble-helper rest)))

          ;; Otherwise it's a macro call. We look up the 
          ;; macro named by the first symbol in the 
          ;; expression and call it on the rest of the 
          ;; rest of the expressions in the macro call. 
          ;; We then append all of the instructions 
          ;; returned by it to the rest of the program 
          ;; and compile that.
            (let ((macrofn (gethash (car inst)
              (assemble-helper (append (apply macrofn
                                              (cdr inst))

The function assemble takes a Lisptran program and returns two values. It returns the generated Fractran program and the alphabet of that program. assemble first initializes all of the global variables for the program and then goes to assemble-helper which recursively processes the Lisptran program according to the specification above. Using the function run-fractran that I mentioned above, we can write a function that will execute a given Lisptran program as follows:

(defun run-lisptran (insts)
  "Run the given Lisptran program."
  (multiple-value-call #'run-fractran (assemble insts)))

Part 3: Building Lisptran

Now that we’ve completed the core compiler, we can start adding actual features to it. From here on out, we will not touch the core compiler. All we are going to do is define a couple Lisptran macros. Eventually we will have enough macros such that programming Lisptran seems like programming a high level assembly language.

The first operations we are going should define are basic arithmetic operations. For example, addition. In order to add addition to Lisptran, we can define a macro addi, which stands for add immediate. Immediate just means that we know what number we are adding at compile time. The macro addi will take a variable and a number, and will expand into a fraction which will add the given number to the register for the variable. In this case, the denominator for the fraction will just be the prime for the current instruction (execute this instruction when that register is set) and the numerator will be the prime for the next instruction (execute the next instruction after this one) times the prime for the variable raised to the power of the number we are adding (add the immediate to the register). Here is what the definition for addi looks like:

(deftran addi (x y)
  (prog1 (list (/ (* *next* (expt (prime-for-var x) y))

With are also going to want an operation that performs subtraction. It’s a bit tricky, but we can implement a macro subi (subtract immediate) in terms of addi, since adding a number is the same as adding the negative of that number:2

(deftran subi (x y) `((addi x ,(- y))))

Now that we’ve got some macros for performing basic arithmetic, we can start focusing on macros that allow us to express control flow. The first control flow macro we will implement is >=i (jump if greater than or equal to immediate). In order to implement >=i, we will have it expand into three fractions. The first fraction will test if the variable is greater or equal to the immediate. If the test succeeds, we will then advance to the second fraction which will restore the variable (since when a test succeeds, all of the values from the denominator are decremented from the corresponding registers), and then jump to the label passed in to >=i. If the test fails, we will fall through to the third fraction which will just continue onto the next fraction after that.

The denominator of the first fraction will be the prime for current instruction (execute the instruction if that register is set) times the prime for the register raised to the power of the constant (how we test that the register is greater than or equal to the immediate) and the numerator will be the prime for the second instruction (so we go to the second instruction if the test succeeds). The second fraction is just the prime for the label passed into >=i (so we jump to wherever the label designates) divided the prime for that instruction. Lastly, the denominator of the third fraction is the prime for the current instruction (so we fall through to it if the test in the first fraction fails), and the numerator is just the prime for the next instruction so that we continue to that if the test fails:

(deftran >=i (var val label)
  (prog1 (let ((restore (new-prime)))
           (list (/ restore
                    (expt (prime-for-var var) val)
                 (/ (* (prime-for-label label)
                       (expt (prime-for-var var) val))
                 (/ *next-inst-prime* *cur-inst-prime*)))

Believe it or not, but after this point, we won’t need to even think about fractions anymore. Lisptran now has enough of a foundation that all of the further macros we will need can be expressed in terms of addisubi and >=i. The only two functions that actually need to be implemented in terms of Fractran are addi and >=i. That means no more thinking about Fractran. From here on out, all we have is Lisptran!

We can easily define unconditional goto in terms of >=i. Since all of the registers start at 0, we can implement goto as greater than or equal to zero. We use the Lisp function gensym to generate a variable without a name so that the variable doesn’t conflict with any other Lisptran variables:

(deftran goto (label) `((>=i ,(gensym) 0 ,label)))

Then through a combination of >=i and goto, we can define <=i:

(deftran <=i (var val label)
  (let ((gskip (gensym))) 
    `((>=i ,var (+ ,val 1) ,gskip)
      (goto ,label)

Now that we have several macros for doing control flow, we can start building some utilities for printing. As mentioned previously printing a character is the same as incrementing the variable with the character as its name and then immediately decrementing it:

(deftran print-char (char)
  `((addi ,char 1)
    (subi ,char 1)))

Then if we want to write a macro that prints a string, it can just expand into a series of calls to print-char, each of which prints a single character in the string:

(deftran print-string (str)
  (loop for char across str
        collect `(print-char ,char)))

We are also going to need a function to print a number. Writing this with the current state of Lisptran is fairly difficult since we haven’t implemented several utilities such as mod yet, but we can start by implementing a macro print-digit that prints the value of a variable that is between 0 and 9. We can implement it, by having it expand into a series of conditions. The first one will check if the variable is less than or equal to zero. If so it will print the character zero and jump past the rest of the conditions. Otherwise it falls through to the next condition which tests if the variable is less than or equal to one and so on. We don’t have to manually write the code for print-digit because we can use Lisp to generate the code for us:

(deftran print-digit (var)
  (loop with gend = (gensym)
        for i from 0 to 9
        for gprint = (gensym)
        for gskip = (gensym)
        append `((<=i ,var ,i ,gprint)
                 (goto ,gskip)
                 (print-char ,(digit-char i))
                 (goto ,gend)
        into result
        finally (return `(,@result ,gend))))

At this point, now that we have macros for performing basic arithmetic, basic control flow, and printing, we can start writing some recognizable programs. For example here is a program that prints the numbers from zero to nine:

 (>=i x 10 end)
 (print-digit x)
 (print-char #\newline)
 (addi x 1)
 (goto start)

If you are curious I have included the Fractran program generated by this Lisptran program here. It’s hard to believe that the above Lisptran program and the Fractran program are equivalent. They look completely different!

Now that we have a bunch of low level operations, we can start building some higher level ones. You may not have thought of it, but instructions don’t need to just have flat structure. For example, now that we have goto, we can use it to define while loops (just like in Loops in Lisp):

(deftran while (test &rest body)
  (let ((gstart (gensym))
        (gend (gensym)))
    `((goto ,gend)
      (,@test ,gstart))))

In order to implement while, we are assuming that all predicates take labels as their last argument which is where they will jump to if the predicate succeeds. Now that we have while loops, we can start writing some much more powerful macros around manipulating variables. Here’s two useful ones, one that sets a variable to zero, and one that copies the value in one variable to another:

(deftran zero (var)
  `((while (>=i ,var 1)
      (subi ,var 1))))

(deftran move (to from)
  (let ((gtemp (gensym)))
    `((zero ,to)
      (while (>=i ,from 1)
        (addi ,gtemp 1)
        (subi ,from 1))
      (while (>=i ,gtemp 1)
        (addi ,to 1)
        (addi ,from 1)
        (subi ,gvar 1)))))

For move, we first have to decrement the number we are moving from and increment a temporary variable. Than we restore both the original variable and the variable we are moving the value to at the same time.

With all of these macros, we can finally start focusing on macros that are actually relevant to Fizzbuzz. One operation that is absolutely going to be necessary for Fizzbuzz is mod. We can implement a macro modi by repeatedly subtracting the immediate until the variable is less than the immediate.

(deftran modi (var val)
  `((while (>=i ,var ,val)
      (subi ,var ,val))))

We only need one more real feature before we can start writing Fizzbuzz. We are going to need a way of printing numbers. In order to print an arbitrary number, we are going to need a way of doing integer division. We can implement a macro divi by repeatedly subtracting the immediate until the variable is less than the immediate and keeping track of the number of times we’ve subtracted the immediate.

(deftran divi (x y)
  (let ((gresult (gensym)))
    `((zero ,gresult)
      (while (>=i ,x ,y)
        (addi ,gresult 1)
        (subi ,x ,y))
      (move ,x ,gresult))))

Now for the final macro we will need. A macro for printing numbers. Actually, we are going to cheat a little. Printing numbers winds up being pretty difficult since you have to print the digits from left to right, but you can only look at the lowest digit at a time. To make things easier, we are only to write a macro that is able to print two digit numbers. We won’t need to print 100 since “buzz” will be printed instead.

(deftran print-number (var)
  (let ((gtemp (gensym))
        (gskip (gensym)))
    `((move ,gtemp ,var)
      (divi ,gtemp 10)
      (>=i ,gtemp 0 ,gskip)
      (print-digit ,gtemp)
      (move ,gtemp ,var)
      (modi ,gtemp 10)
      (print-digit ,gtemp)
      (print-char #\newline))))

Now our language is sufficiently high enough that Fizzbuzz is going to be practically as easy as it will get. Here is an implementation of Fizzbuzz in Fractran.

((move x 1)
 (while (<=i x 100)
   (move rem x)
   (modi rem 15)
   (<=i rem 0 fizzbuzz)

   (move rem x)
   (modi rem 3)
   (<=i rem 0 fizz)

   (move rem x)
   (modi rem 5)
   (<=i rem 0 buzz)

   (print-number x)
   (goto end)

   (print-string "fizzbuzz")
   (goto end)

   (print-string "fizz")
   (goto end)

   (print-string "buzz")
   (goto end)

   (addi x 1)))

I’ve also included the generated Fractran program here and included all of the full source code for this blog post here.

I find it absolutely amazing that we were able to build a pretty decent language by repeatedly adding more and more features on top of what we already had. To recap, we implemented a basic arithmetic operation (addi) in terms of raw Fractran and then defined a second (subi) in terms of that. From there we defined three macros for doing control flow (>=igoto<=i), with the second two being defined in terms of the first. Then we were then able to define macros for printing (print-charprint-stringprint-digit). At this point we had all of the low level operations we needed so we could start implement while loops (while), a high level control flow construct. With while loops, we were able to define several macros for manipulating variables (zeromove). With these new utilities for manipulating variables we could define more advanced arithmetic operations (modidivi). Then with these new operations we were able to define a way to print an arbitrary two digit number (print-number). Finally, using everything we had up to this point, we were able to write Fizzbuzz. It’s just incredible that we could make a language by always making slight abstractions on top of the operations we already had.

The post Building Fizzbuzz in Fractran from the Bottom Up appeared first on Macrology.

CL Test Gridquicklisp 2016-05-31

· 135 days ago
The difference between this and previous months:

Grouped by lisp implementation first and then by library:

Grouped by library first and then by lisp impl:

(Both reports show the same data, just arranged differently)

This time the diff is smaller than the past month. There are some regressions, some improvements.

If you're interested in some particular failure or need help investigating something, just ask in the comments or on the mailing list.

Wimpie NortjeDaemonizing Common Lisp services.

· 137 days ago

Update (2016-06-09):

During a discussion on Reddit I realised that the issues discussed in this post are not relevant to the systemd init system.

At the time of writing my servers run Ubuntu 14.04 which uses Upstart as the init system. Upstart detaches the tty of the started services. That is the cause of the issues discussed below.

Most Linux distributions seem to migrate to systemd as the init system. systemd does not detach the tty, it binds stdin to /dev/null and stdout and stderr to a logging stream.

If your OS uses systemd you can turn a foreground application into a service without using GNU Screen or the daemon package.

Deploying a Common Lisp server application in production requires that it runs as a daemon.

A Unix init system like Upstart or systemd can be used to ensure that the service is always running. In this case the application can daemonize itself or it can run in the foreground and let the init system take care of daemonization.

It is usually easier to create an init script for a self-daemonizing application but then the source code gets more complicated.

When the application runs in the foreground the init script is slightly more tricky but the application is easier to debug.


The procedure to daemonize an application is well documented but most of these documentation is focused on C. To implement the complete procedure in Common Lisp can become a mission in itself because it involves forking and opening and closing standard IO stream at the right times.

The daemon package implements all the necessary steps and provides a trivial API for daemonizing a program.

Though daemon is easy to use, all the forking makes it difficult to get backtraces when something goes wrong. The application then appears to be hanging while it is actually waiting in the debugger for input but the debugger can't be used because standard IO is closed.

When a service daemonizes itself it is advisable to devise some method to interact with the application while it is waiting in the debugger. One of the swank libraries could be useful.

Run in foreground

Foreground applications can be used as-is for a service but it can not be used as the main application instantiated by the init system.

During the daemonizing process the init system closes all the standard IO streams. This causes the REPL to exit and the application to end.

GNU Screen can be used to keep the standard IO open for a daemonized service. However, when an error occurs one is in much the same situation as with a self-daemonizing application. The application appears to hang because it is waiting in the debugger but the debugger can't easily be reached.

Screen has options to log standard IO to a file. Debugging then consists of killing the service and working through the logged backtrace. This is not ideal but it has the advantage of not introducing any code complexity in order to make a daemon.

Like in the self-daemonizing case, a swank library can be used to get live debugging back.

Comparing the options

Self-daemonizing Foreground
Daemonizing responsibility Common Lisp code Unix init system
Tool daemon library GNU Screen
Init script complexity Less complex More complex
Code complexity Increased complexity Same complexity as normal program
Debugging options Embedded swank server Logged data or embbeded swank server

Zach BeaneLisp stuff on YouTube

· 138 days ago

If you want to see some neat videos, subscribe to dto, Baggers, and WarWeasle on YouTube. They all regularly post neat graphical stuff done in Common Lisp.

If you know any more people I should follow on YouTube, let me know.

LispjobsSecure Outcomes, Contract Common Lisp programmer

· 142 days ago

Secure Outcomes builds and provides digital livescan fingerprinting systems for use by law enforcement, military, airports, schools, Fortune 500s, etc.

All of our systems are constructed in Common Lisp.

We are looking for a contract CL developer located anywhere in the world that can build software for us.

Strong CL/LW background, of course, but also knowledge of foreign function interfacing etc needed.

Work full or part time.

See what we do at

Resumes to No calls please.

Timofei ShatrovAll you need is PROGV

· 142 days ago

I have never seen PROGV in useErik Naggum

Common Lisp is very, very old. Tagbody and progv, anyone? – Hacker News user pwnstigator

I haven't written anything on this blog lately, mostly because of lack of time to work on side projects and consequently the lack of Lisp things to talk about. However recently I've been working on various improvements to my Ichiran project, and here's the story of how I came to use the much maligned (or rather, extremely obscure) special operator PROGV for the first time.

Ichiran is basically a glorified Japanese dictionary (used as the backend for the web app and it heavily depends on a Postgres database that contains all the words, definitions and so on. The database is based on a dump of an open JMdict dictionary, which is constantly updated based on the users' submissions.

Well, the last time I generated the database from this dump was almost a year ago, and I wanted to update the definitions for a while. However this tends to break the accuracy of my word segmenting algorithm. For this reason I want to keep the old and the new database at the same time and be able to run the whatever code with either of the databases.

I'm using Postmodern to access the database, which has a useful macro named with-connection. If I have a special variable *connection* and consistently use (with-connection *connection* ...) in my database-accessing functions then I can later call

(let ((*connection* '("foo" "bar" "baz" "quux")))

and it will use connection ("foo" "bar" "baz" "quux") instead of the default one. I can even encapsulate it as a macro

(defmacro with-db (dbid &body body)
  `(let ((*connection* (get-spec ,dbid)))
     (with-connection *connection*

(dbid and get-spec are just more convenience features, so that I can refer to the connection by a single keyword instead of a list of 4 elements).

So far so good, but there’s a flaw with this approach. For performance reasons, some of the data from the database is stored in certain global variables. For example I have a variable *suffix-cache* that contains a mapping between various word suffixes and objects in the database that represent these suffixes. Obviously if I run something with a different connection, I want to use *suffix-cache* that’s actually suitable for this connection.

I created a simple wrapper macro around defvar that looks like this:

(defvar *conn-vars* nil)

(defmacro def-conn-var (name initial-value &rest args)
     (defvar ,name ,initial-value ,@args)
     (pushnew (cons ',name ,initial-value) *conn-vars* :key 'car)))

Now with-db can potentially add new dynamic variable bindings together with *connection* based on the contents of *conn-vars*. It’s pretty trivial to add the new bindings at the macro expansion time. However that poses another problem: now all the conn-vars need to be defined before with-db is expanded. Moreover, if I introduce a new conn-var, all instances of with-db macro must be recompiled. This might be not a problem for something like a desktop app, but my web app usually runs for months without being restarted, with new code being hot-swapped into the running image. I certainly don’t need the extra hassle of having to recompile everything in a specific order.

Meanwhile I had the definition of let opened in the Hyperspec, and there was a link to progv at the bottom. I had no idea what it does, and thinking that my Lisp has gotten rusty, clicked through to refresh my memory. Imagine my surprise when I found that 1) I have never used this feature before and 2) it was exactly what I needed. Indeed, if I can bind dynamic variables at runtime, then I don’t need to re-expand the macro every time the set of these variables changes.

The final code ended up being pretty messy, but it worked:

(defvar *conn-var-cache* (make-hash-table :test #'equal))

(defmacro with-db (dbid &body body)
  (alexandria:with-gensyms (pv-pairs var vars val vals iv key exists)
    `(let* ((*connection* (get-spec ,dbid))
            (,pv-pairs (when ,dbid
                         (loop for (,var . ,iv) in *conn-vars*
                            for ,key = (cons ,var *connection*)
                            for (,val ,exists) = (multiple-value-list (gethash ,key *conn-var-cache*))
                            collect ,var into ,vars
                            if ,exists collect ,val into ,vals
                            else collect ,iv into ,vals
                            finally (return (cons ,vars ,vals))))))
       (progv (car ,pv-pairs) (cdr ,pv-pairs)
              (with-connection *connection*
           (loop for ,var in (car ,pv-pairs)
              for ,key = (cons ,var *connection*)
              do (setf (gethash ,key *conn-var-cache*) (symbol-value ,var))))))))

Basically the loop creates a pair of list of variables and list of their values (no idea why progv couldn’t have accepted an alist or something). The values are taken from *conn-var-cache* which takes the pairing of variable name and connection spec as the key. Then I also add an unwind-protect to save the values of the variables that might have changed within the body back into the cache. Note that this makes nested with-db’s unreliable! The fix is possible, and left as an exercise to the reader. Another problem is that dynamic variables bindings don’t get passed into new threads, so no threads should be spawned within the with-db macro.

And this is how I ended up using progv in production. This probably dethrones displaced array strings as the most obscure feature in my codebase. Hopefully I’ll have more things to write about in the future. Until next time!

Quicklisp newsMay 2016 Quicklisp dist update now available

· 144 days ago
New projects:
  • cl-ecs — An implementation of the Entity-Component-System pattern mostly used in game development. — MIT
  • cl-htmlprag — A port of Neil Van Dyke's famous HTMLPrag library to Common Lisp. — LGPL 2.1
  • cl-messagepack-rpc — A Common Lisp implementation of the MessagePack-RPC specification, which uses MessagePack serialization format to achieve efficient remote procedure calls (RPCs). — MIT
  • cl-monitors — Bindings to libmonitors, allowing the handling of monitors querying and resolution changing. — Artistic
  • cl-oclapi — Yet another OpenCL API bindings for Common Lisp. — MIT
  • cl-pack — Perl compatible binary pack() and unpack() library — BSD-3-Clause
  • cl-scan — port scanner. — ISC
  • cl-scsu — An implementation of 'Standard Compression Scheme for Unicode'. — MIT
  • clack-static-asset-middleware — A cache busting static file middleware for the clack web framework. — MIT
  • easing — Easing functions. — MIT
  • fare-scripts — Various small programs that I write in CL in lieu of shell scripts — MIT
  • fixed — A fixed-point number type. — MIT
  • focus — Customizable FORMAT strings and directives — BSD
  • glsl-spec — The GLSL Spec as a datastructure — The Unlicense
  • injection — Dependency injection for Common Lisp — GPLv3
  • json-mop — A metaclass for bridging CLOS and JSON — LGPLv3+
  • leveldb — LevelDB bindings for Common Lisp. — BSD
  • moira — Monitor and restart background threads. — MIT
  • recursive-restart — Restarts that can invoke themselves. — MIT
  • trivial-nntp — Simple tools for interfacing to NNTP servers — MIT
  • trivial-openstack — A simple Common Lisp OpenStack REST client. — MIT
  • trivial-yenc — Decode yenc file to a binary file — MIT
  • weblocks-prototype-js — Weblocks JavaScript backend for PrototypeJs — LLGPL
Updated projects3d-vectorsbackportsbinfixbit-smasherblackbirdcaveman2-widgetsceplcepl.cameracepl.devilcl-anacl-autowrapcl-bloomcl-cairo2cl-charmscl-dotcl-erlang-termcl-gamepadcl-geometrycl-hash-table-destructuringcl-html5-parsercl-i18ncl-jpegcl-liballegrocl-libssh2cl-mediawikicl-mongocl-mpicl-ohmcl-pangocl-projectcl-qrencodecl-rediscl-sdl2cl-seleniumcl-storeclackcloser-mopcoleslawcroatoandeedsdissectdjula,esrapexscribefemlispfiascofirephpflareform-fiddleglkitglopgraphhalftonehelambdaphl7-parserhu.dwim.partial-evalhu.dwim.quasi-quotehu.dwim.utilkenzolegitlisp-interface-librarylisp-namespacelisp-unit2mcclimoclcl,pathname-utilspzmqqt-libsqtoolsqtools-uiquery-fsqueuesrclrestasrtg-mathrutilsscalplsdl2kitserapeumsimple-taskssketchskitterslimesnakesstp-querystringprepstumpwmtemporal-functionstriviatrivial-backtracetrivial-benchmarktrivial-string-templatetrivialib.bddubiquitousutilities.print-treevarjoverbosevgplotweblocksweblocks-storesxhtmlambdazs3.

To get this update, use: (ql:update-dist "quicklisp")

You didn't miss it -- there wasn't a fundraiser in April. Or May, either. I've got my fingers crossed to see one soon, but I'm not sure exactly when it might happen. Stay tuned!

For older items, see the Planet Lisp Archives.

Last updated: 2016-10-12 15:53