12 Oct 2016

feedPlanet Lisp

Quicklisp news: Projects on the bubble

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.

12 Oct 2016 3:53pm GMT

08 Oct 2016

feedPlanet Lisp

ABCL Dev: ABCL 1.4.0

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 https://gitlab.common-lisp.net/abcl/abcl and https://github.com/easye/abcl 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 java.io.File.createTempFile().

* [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

08 Oct 2016 5:57pm GMT

03 Oct 2016

feedPlanet Lisp

CL Test Grid: quicklisp 2016-09-29

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.

03 Oct 2016 2:45am GMT

McCLIM: Progress report #2

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 README.md 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 (daniel@turtleware.eu) or on IRC (my nick is jackdaniel).

Sincerely yours,
Daniel Kochmański

03 Oct 2016 1:00am GMT

30 Sep 2016

feedPlanet Lisp

Quicklisp news: September 2016 Quicklisp dist update now available

New projects:

Updated projects: 3d-vectors, acclimation, architecture.service-provider, array-utils, arrow-macros, bknr-datastore, carrier, caveman2-widgets, cells, chanl, chirp, cl-ana, cl-bloom, cl-coroutine, cl-freeimage, cl-gamepad, cl-glfw3, cl-inotify, cl-interpol, cl-ixf, cl-lex, cl-monitors, cl-mpg123, cl-mtgnet, cl-neovim, cl-oclapi, cl-opengl, cl-out123, cl-pack, cl-rabbit, clack, clfswm, clip, clobber, closer-mop, clss, clx, codex, coleslaw, colleen, croatoan, crypto-shortcuts, deeds, deferred, dexador, dissect, documentation-utils, esrap, fare-scripts, file-types, flare, for, form-fiddle, gbbopen, gendl, geneva, hu.dwim.bluez, hu.dwim.sdl, humbler, inferior-shell, inlined-generic-function, kenzo, lack, lake, lambda-fiddle, lass, legit, lisp-invocation, lquery, maxpc, mcclim, mito, mito-auth, modularize, modularize-hooks, modularize-interfaces, more-conditions, mpc, pathname-utils, pgloader, piping, plump, plump-bundle, plump-sexp, postmodern, ptester, purl, qlot, qt-libs, qtools, qtools-ui, queen.lisp, quri, racer, random-state, ratify, redirect-stream, rtg-math, rutils, serapeum, sha3, simple-inferiors, simple-tasks, snooze, softdrink, south, spinneret, staple, static-vectors, stumpwm, swap-bytes, trivia, trivial-arguments, trivial-benchmark, trivial-indent, trivial-main-thread, trivial-mimes, trivial-rfc-1123, trivial-thumbnail, ubiquitous, utilities.binary-dump, utilities.print-items, verbose, weblocks, weblocks-prototype-js, with-cached-reader-conditionals, woo, zenekindarl.

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

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


30 Sep 2016 4:05pm GMT

Zach Beane: Corman Lisp updates

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.

30 Sep 2016 12:38pm GMT

24 Sep 2016

feedPlanet Lisp

Hans Hübner

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!

24 Sep 2016 8:56pm GMT

30 Aug 2016

feedPlanet Lisp

Nicolas Hafner: Ludum Dare 36 & Lisp Application Programming - Confession 68

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 libsmokebase.so 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 irc.freenode.net.

30 Aug 2016 10:53pm GMT

McCLIM: Progress report #1

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 https://common-lisp.net/project/mcclim/involve which addresses some common questions and doubts and we have created a wiki on GitHub (not very useful yet https://github.com/robert-strandh/McCLIM/wiki).

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: https://common-lisp.net/project/mcclim/involve. 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 (daniel@turtleware.eu) or on IRC (my nick is jackdaniel).

Sincerely yours,
Daniel Kochmański

30 Aug 2016 1:00am GMT

27 Aug 2016

feedPlanet Lisp

Quicklisp news: August 2016 Quicklisp dist update now available

New projects:

Updated projects: 3bmd, 3d-vectors, agm, alexandria, binfix, burgled-batteries, caveman, caveman2-widgets, cepl, cepl.camera, cepl.devil, cepl.sdl2, cepl.skitter, ceramic, chirp, city-hash, cl-ana, cl-async, cl-azure, cl-conspack, cl-ecs, cl-fad, cl-gamepad, cl-grace, cl-influxdb, cl-jpeg, cl-libuv, cl-messagepack, cl-messagepack-rpc, cl-mpi, cl-mtgnet, cl-oclapi, cl-opengl, cl-openstack-client, cl-pack, cl-quickcheck, cl-redis, cl-rethinkdb, cl-scan, cl-sdl2, cl-smtp, cl-strings, cl-tokyo-cabinet, cl-unification, cl-yaclyaml, cl-yaml, clack, classimp, clml, clos-fixtures, closer-mop, clx, clx-truetype, coleslaw, collectors, corona,croatoan, dbus, dendrite, dexador, dissect, djula, eazy-gnuplot, esrap, exscribe, external-program, fare-memoization, fare-scripts, fiveam, flare, fn, gendl, geneva, glkit, glsl-spec, gsll, iterate, json-mop, kenzo,lack, lambda-fiddle, lisp-namespace, lispbuilder, lparallel, mcclim, mel-base, neo4cl, oclcl, opticl, osicat, prometheus.cl, prove, qlot, qt-libs, qtools, qtools-ui, quickapp, random-state, rcl, remote-js, restas, rtg-math, serapeum, sip-hash, skitter, spinneret, squirl, stumpwm, treedb, trivia, trivial-documentation, trivial-nntp, trivial-open-browser, trivial-ws, trivialib.type-unify, ubiquitous, ugly-tiny-infix-macro,utilities.print-items, utilities.print-tree, varjo, vgplot, vom, weblocks, weblocks-utils, woo, wu-sugar.

Removed projects: scalpl.

27 Aug 2016 2:16pm GMT