posted on 2012-05
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.
The upcoming library will be based on a combination of hardware-coded atomic operations (via libatomic-ops) with a new waiting queue that makes clever use of the operating system facilities. The result should be a library that is fair (different threads have equal opportunities), it recognizes fast paths (when a synchronization object is free it is quickly acquired), and in the worst case it is not CPU consuming (relies on sigsuspend or SleepEx to really sleep a waiting thread).
Everything is right now in git/CVS (http://ecls.sourceforge.net/download.html) and under heavy testing with new dedicated tests. Help is welcome from anybody who is interesting in ensuring stability.
Another side effect is that "make check" now works in ECL. I have abandoned the development of "ecl-tests" and instead the tests are now integral part of ECL. In order to save space, the ANSI test suite is not shipped with ECL but rather automatically downloaded thanks to ECL's new components: ecl-curl and ecl-minitar. The test suite also allows downloading of quicklisp and automated testing of selected libraries.
In the end this was the last missing ingredient to resucitate our compiler farm, which is now up and running again: http://ecls.sourceforge.net/logs.html
Expect a new release soon, and also a few more posts on other upcoming features.
P.S.: I would like to thank the ELS organizers and steering committee for a wonderful meeting in Zadar. Great location, amazing food, and even better discussions.
posted on 2011-05
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.
So, the summary is that ECL is still alive, even if the maintainer is going through a very busy phase that should finish some time around June.
posted on 2011-01
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.
posted on 2010-07
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.
posted on 2010-06
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 (126.96.36.199) 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 on 2010-06
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)
dynamically loadable UIs
no GC (not a real problem, see notes in documentation)
Tested (with SLIME) in Linux, OSX, WinXP + VS 2008 Express: * ECL 10.4.1 (unicode) * Qt 4.6.2. * SLIME from CVS (2010-06-01)
Sources (LGPL) + screenshot: http://password-taxi.at/EQL
BTW, you do NOT want to test this with ECL from CVS/git because it is right now evolving very fast and in a probably unstable state. Use the last stable release instead (Juanjo)
posted on 2010-03
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
posted on 2009-10
Among other novelties, it includes support for OS X 10.6 or Snow Leopard, full support for the latest versions of Solaris, weak pointers, and a new model for handling signals.
However, until we transition to the upcoming release of the Boehm-Weiser library, the following problems persist:
NetBSD and Open only work in single-threaded mode because 1) the version of the garbage collector shipped with it does not support GC_register_my_thread and 2) the version of the garbage collector shipped with ECL fails to build (it gets locked when looking for a working fork())
The mingw32 port only builds in multithreaded mode when using the unstable release of the garbage collector (v7.2)
As usual, refer to http://ecls.sourceforge.net for downloading, reading the manual, or browsing unstable versions.
posted on 2009-10
When the moment of producing a release approaches, there is always the inherent feeling that everything will go wrong. But sometimes it goes even worse.
In this case I have been waiting several days to produce a stable release of ECL, watching at our compiler farm and feeling very happy about the results (http://ecls.sf.net/logs.html). What I had not realized is that, first, our CVS repository had gotten out of sync with the GIT repository. That is bad by itself. But second, the testing farm had been running obsolete executables for several days.
It was quite embarrasing to get several emails complaining that ECL did not build in Linux, OS X and other platforms. But I think I have managed to solve most problems (see below).
The status remains as follows:
NetBSD, OpenBSD and Mingw/Windows do not support threads unless you use the unstable version of the Boehm-Weiser garbage collector.
To build any Windows port (including Mingw), you need now a multithreaded environment. This means in practice that Mingw by default is broken, unless, as I said before, you use the alpha release of the garbage collector.
Support for building ECL with a C++ compiler is momentarily broken.
Apart from these, all the improvements that I mention in the full CHANGELOG remain.
Fixed typo in src/c/unixint.d that affected single-threaded builds
The GMP library did not build in OS X Snow Leopard in 64-bits mode.
The package MP is needed also in single-threaded versions (for fake mp:with-lock, which is used in CLX).
In CLX, there were a couple of typos in the code related to locks and ECL. These typos only revealed in multithreaded builds of the CLX library.
In Linux there is a problem with handlers for SIGFPE being totally ignored by the system. The problem seems to be solved by avoiding the use of feenableexcept() and restricting to C99 exception tests. That is bad because we can not reliably and cheaply detect underflow exceptions.
Under OS X, --enable-rpath works again. It was broken for about a year due to my misunderstanding of how -install_name works and the differences between that and -rpath.
posted on 2009-07
As usual, available at the project homepage http://ecls.sourceforge.net See http://ecls.cvs.sourceforge.net/viewvc/ecls/ecl/src/CHANGELOG?view=markup for the list of changes.
View content from 2017-12, 2017-07, 2016-12, 2016-11, 2016-06, 2016-04, 2016-03, 2016-02, 2015-11, 2015-09, 2015-05, 2015-03, 2015-02, 2013-10, 2013-05, 2013-01, 2012-12, 2012-11, 2012-08, 2012-07, 2012-06, 2012-05, 2011-05, 2011-01, 2010-07, 2010-06, 2010-03, 2009-10, 2009-07, 2009-06, 2009-04, 2008-12, 2008-10, 2008-08, 2008-04, 2007-12, 2007-05, 2007-01, 2006-09, 2006-06, 2006-04, 2006-03, 2006-01, 2005-12, 2005-11, 2005-10, 2005-08, 2005-07, 2005-06, 2005-05