Help save net neutrality! Learn more.

Embeddable Common-Lisp / News: Recent posts

ECL 16.0.0 release

Hello! Since we don't have a proper rss feed yet (I'll work on it in the upcoming weeks and post link here, when done), I'm informing here, that the new ECL release is available. Enjoy!


PS This is the last post on this channel (except pointer to new rss feed), since we've moved from SF to above-mentioned address.

Posted by jackdaniel 2015-08-28

ECL Quarterly - Volume I

Posted by jackdaniel 2015-05-01 Labels: ecl-quarterly

ECL 15.3.7 released

My deep apologies to all Windows users for misfortunate unicode character at top screen, which caused an exception at the very start of ECL startup. Version 15.2.21 was released little prematurely. Proper fix is released a week after problem was noticed, because we did want to test it first, and to fix a few regressions between 13.5.1 and 15.2.21.

This release is at least as good as 15.2.21. Enchantments include:... read more

Posted by jackdaniel 2015-03-07 Labels: release migration

ECL 15.2.21 released, new maintainer found

New release, which is mainly current state of git HEAD (plus a few fixes). Contains numerous bug-fixes in comparison to 13.5.1 and is last, which follows date-based version convention. It's time to finally release ECL 1.0 ;-).

Development moves to gitorious (, same as wiki (previous content is inaccessible now, but once subscription is renewed, I'll start to migrate content from there). In GIT topic - current permissions will be preserved. Just drop me a line with gitorious login, and I'll add person on corresponding permission level to project.... read more

Posted by jackdaniel 2015-02-21

New maintainer sought

Posted by Juan Jose Garcia Ripoll 2013-10-09

ECL 13.5.1

Known issues

  • Cygwin's library is still broken: fork/exec fails to reload the cygwin library, or ECL's compiled libraries in a completely random fashion. For this reason we recommend using ext:system instead of ext:run-program in that platform.
  • In Windows ECL comes with bytecodes compiler by default, because C compilers are normally not avaiable. Unfortunately several libraries out there are not prepared for this. If you plan to use quicklisp and have a C compiler accessible to ECL, you may use (ext:install-c-compiler) to switch back to the Lisp-to-C compiler. ... read more
Posted by Juan Jose Garcia Ripoll 2013-05-28

Stumpwm can be built with ECL

For those complaining about this, I finally found time and there were only three small bugs:

  1. CLX requires recursive locks, but ECL now makes non-recursive the default. I fixed CLX in ECL.

  2. Stumpwm uses the old ASDF-ECL building routines instead of the new and improved ASDF-BUNDLE which is standard and supported by ASDF (Faré).

  3. Stumpwm's RELOAD kept a reference to ASDF which should not be there for standalone programs, since ASDF is not used in that case.... read more

Posted by Juan Jose Garcia Ripoll 2013-01-17

ECL 12.12.1 released

Some highlights of this release are:

  • Lots of bugs fixed.
  • The MOP has been fixed to work with the upcoming release of Closer-MOP
  • ECL now produces a much more readable C code, with indentation and more explicit declarations of variables.

See file src/CHANGELOG or browse it online

PS: If you read ECL news through Planet Lisp, please follow the links to the original page, , because SF's news feed breaks all the beautiful formatting of its markup code.

Posted by Juan Jose Garcia Ripoll 2012-12-07

Involvement in ECL

Would you like to get acquainted with a Common Lisp implementation? Do you have free time and would like to start by some small tasks?

ECL is currently offering a simple way for you to do so. Thanks to Anton Vodonosov's cl-test-grid and Eric Marsden's benchmark collection, which are offered here and here , you may now see in real time what problems are left to be solved in terms both of compatibility and performance.... read more

Posted by Juan Jose Garcia Ripoll 2012-11-29

Zombie news

I just saw a bunch of old news resurrected both in my news reader and in Planet Lisp. This was probably due to the software upgrade in Sourceforge: ECL is now using the new development platform that Sourceforge provides and during the migration several unexpected events took place (lost git repositories, this issue with the news, etc). Fortunately this new platform is easier to use, it provides http access to git, CVS is still there, bug reporting is much nicer and I can kill spam comments in bug reports, which is great. Please make the best use of it and accept once more my apologies for the zombie news.

Posted by Juan Jose Garcia Ripoll 2012-08-01

ECL repositories changed

ECL has been upgraded to the newest version of Sourceforge. Unfortunately this has lead to the loss of the code repositories, which had to be recreated and now have different addresses:

git clone git:// ecl # ECL source code
git clone git:// ecl-doc # ECL documentation

Go to to see the new project interface and the two GIT repositories, or simply check the new addresses in our downloads page

Posted by Juan Jose Garcia Ripoll 2012-07-26

ECL 12.7.1 released

Sorry for the multiple posting -- I had some problems with SourceForge news submission today.

Known issues

This release is the first one with the new multithreading library,
which no longer relies on the POSIX mutexes, condition variables and
semaphores. Instead, ECL makes use of libatomic-ops to implement
userspace routines for process communication (mailboxes), resource
sharing (locks, condition variables, counting semaphores) and fast
spinlocks.... read more

Posted by Juan Jose Garcia Ripoll 2012-07-24

ECL 12.7.1 released

  • Lots and lots of fixes.

See file src/CHANGELOG or browse it online

Posted by Juan Jose Garcia Ripoll 2012-07-24

A pleasant surprise + a bonus

It seems that Windows now implements a kind of input history for any application that uses the console. This is nice, because it allows ECL users that directly work on a terminal window to recall previous commands, using just the arrow keys -- a limited form of what "readline" does for you --.

On a side note, the next release of ECL will ship with a small script to install quicklisp in the installation directory. It will be as simple as using (require :ecl-quicklisp) from the Common Lisp prompt. ECL will download the installation file and run it for you with the appropriate paths.

Posted by Juan Jose Garcia Ripoll 2012-07-08

News on the manual

ECL's manual, which is found here is being updated on two fronts. The most important part is to document features that were long present but were not explained in the documentation. This includes for instance character types, support for Unicode or external formats, which were erroneously absent from the manual for several years.

The second set of improvements consists on the documentation of its C/C++ API. The manual now lists the C equivalents of almost all Standard Common Lisp functions and types, and in the following days we will add also the functions and macros which are proper just to the C part, such as conversion from all C types to Lisp and back, memory allocation, etc.

Posted by Juan Jose Garcia Ripoll 2012-06-21

Multithreading is now on by default

Today or tomorrow I will upload a set of changes that will make ECL build with support for threads by default. If you want a single-threaded ECL, use "--disable-threads" when configuring it.

On a completely different matter, thanks to user contributed patches, ECL now seems to build in 64 bit mode using Visual Studio C++ (express) or Microsoft's SDK for Windows v7.1 (free).

Posted by Juan Jose Garcia Ripoll 2012-05-30

Experimenting: Windows console

Not long ago a user reported problems with ECL when running under Windows with the Chinese codepage 936. I was really surprised to verify that indeed, ECL was aborting on any multibyte character... but only when typed in a terminal window (the so called Windows console).

A bit of investigation revealed that the Microsoft C runtime is quite broken ( or at least not very POSIX / ANSI conformant. Roughly, some versions of the runtime act differently when the standard input or output of a program is connected to a console. In this case they try to be very clever and translate the Unicode input/output generated by the console into the selected codepage. This also leads the CRT to reject multibyte characters because read() demands a buffer with as many bytes as a whole character needs. For instance, if a character with codes F7 8C is input at the console, read(0, buffer, 1), instead of returning F7, will abort. Or put some other way: characters cannot be read one by one.... read more

Posted by Juan Jose Garcia Ripoll 2012-05-22

Bug reports: please do them!

I am sorry. Really, I am. I cannot follow you all in all your usual communication channels: comp.lang.lisp, the ecl forum, #lisp irc channel... But please consider this:

First of all, ECL is maintained in free time. In this sense, it is more beneficial for you if the maintainers spend more time coding than trolling about lisp.

Second, an IRC channel is not a place to look for support. Sourceforge offers you a bug reporting facility (, a feature request database (, a mailing list ( read more

Posted by Juan Jose Garcia Ripoll 2012-05-09

Ha! We beat iconv!

Seems ECL supports more codepages than iconv on certain platforms

;;; Testing ISO-2022-JP-1
iconv: conversion from ISO-2022-JP-1' is not supported Tryiconv --help' or `iconv --usage' for more information.
(From regressions in )

This is so in some not too old Linuxes, OpenBSD, NetBSD, etc.

Posted by Juan Jose Garcia Ripoll 2012-05-05

Periodic reports: multithreading & tests

Probably nobody cares about this, but there has been some activity in ECL in various fronts. I periodically report that to the ECL mailing list, but this seems to lead other people to think the project is silent or dead. From now on, expect a little bit more noise through the ECL news RSS.

The biggest change ECL will suffer with the upcoming release is the multithreading library. So far we were relying on the POSIX primitives for that (pthread_mutex_lock, condition variables, etc), but this has proven to be a nightmare to maintain. The primitives are not interruptible and they do not interact well with mp:process-interrupt, a feature unfortunately everybody expects in a Lisp implementation.... read more

Posted by Juan Jose Garcia Ripoll 2012-05-05

ECL is not orphaned

Just in case someone got confused by the latest announcement.

ECL is not an orphaned project. ECL was hosted at for some time, in a period in which Sourceforge experienced frequent outages. At some point it was more favorable for us to return to SF and so the page was emptied and redirected. With the new change of servers the redirects stopped working. Besides this, for some reason I had forgotten to change the email address at and I did not learn about this.... read more

Posted by Juan Jose Garcia Ripoll 2011-05-17

ECL 11.1.1

With a funny release number, and quite a number of improvements, I introduce to you the latest release of ECL

Note that this time, as an experiment, we are also distributing a self-installing executable for Windows. It works on 32-bits and does not need a C compiler, as it comes with a bytecodes compiler activated by default.

Posted by Juan Jose Garcia Ripoll 2011-01-17

ECL in Apache: mod_ecl

Louis Höfler has created a very interesting project: a module that allows you to execute Common Lisp in your Apache web server, much like PHP and perl modules I assume

The first version of the module is available here

It uses ECL as embedded Common Lisp in a very simple way. I would encourage people interested in this project to research things like security and multithreading.

Posted by Juan Jose Garcia Ripoll 2010-07-09

About the myth of slow starting

I am tired of reading complaints about how slow ECL is at being launched. Things are constantly improving but the current boot times are reasonable enough. A stupid way to test them is to do something like "ecl -norc -eval '(quit)'" or the equivalent for SBCL and CLISP.

Here are the findings

ECL: 0.060 s (git/CVS)
SBCL: 0.038 s (
CLISP: 0.021 s (v. 2.44.1)

Notice that the whole difference arises because ECL has to reconstruct the data that forms the program (constants, functions, etc) reading them from a text representation. Is it really that large a difference?

Posted by Juan Jose Garcia Ripoll 2010-06-05

EQL - Embedded Qt Lisp

Cut&past from the mailing list, here comes an exciting announcement!!!

OK, so we already have very nice Qt bindings for CL (CommonQt, cl-smoke). But what about an ECL embedded solution, with exactly 0 dependencies?

  • most of QtGui (+ overriding virtuals)
  • interactive SLIME (needs a small patch, but no threads)
  • unicode
  • internationalization
  • dynamically loadable UIs
  • cross-platform

  • no CLOS

  • no GC (not a real problem, see notes in documentation)... read more
Posted by Juan Jose Garcia Ripoll 2010-06-04