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 (18.104.22.168) 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.
posted on 2009-07
Sourceforge.net now supports GIT repositories. This is great because now we do not need to keep our GIT mirrors together with the web pages, but rather host them where they should be.
There is more information at webpage http://ecls.sourceforge.net/download.html including the new addresses of the mirrors, how to browse source code, etc. Please update your copies or clone the repositories again. The old repos are being discontinued.
Please note that due to a limitation in Sourceforge.net, a project can in principle have only one repository. We are currently violating this restriction, having three repos, ecl, ecl-doc and ecl-test, for the project, the documentation and the regression tests. The only problem with this is that the list of repos is empty in the "official" project page, and that in order to browse the repositories you have to use the addresses we provide at the downloads page.
View content from 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