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 (http://alfps.wordpress.com/2011/12/08/unicode-part-2-utf-8-stream-mode/) 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

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 (https://sourceforge.net/tracker/?group_id=30035), a feature request database (https://sourceforge.net/tracker/?group_id=30035&atid=398056), a mailing list (http://news.gmane.org/gmane.lisp.ecl.general/)...... read more

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 http://ecls.sourceforge.net/logs.html )

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

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

Just in case someone got confused by the latest common-lisp.net announcement.

ECL is not an orphaned project. ECL was hosted at common-lisp.net 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 common-lisp.net 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 common-lisp.net and I did not learn about this.... read more

With a funny release number, and quite a number of improvements, I introduce to you the latest release of ECL
https://sourceforge.net/projects/ecls/files/ecls/11.1/

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.

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
https://sourceforge.net/projects/mod-ecl/files/

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.

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

Ubuntu/x64
ECL: 0.060 s (git/CVS)
SBCL: 0.038 s (1.0.29.11)
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?

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

This release has three important focuses: performance improvements in various fronts (garbage collection and hash tables), extending the run-process function and important fixes to let ECL work better with Slime. Note however that now at least Slime from last week's CVS is needed and that future versions of Slime will require at least this version of ECL to work.

See file src/CHANGELOG or browse it online
http://ecls.cvs.sourceforge.net/viewvc/ecls/ecl/src/CHANGELOG?view=markup
Downloading ECL: http://ecls.sf.net/download.html