[ANN] ECL v9.10.1

Discussion of Common Lisp

[ANN] ECL v9.10.1

Postby jjgarcia » Thu Oct 08, 2009 3:00 am

Announcement of ECL v9.10.1

ECL stands for Embeddable Common-Lisp. The ECL project aims to produce an
implementation of the Common-Lisp language which complies to the ANSI X3J13
definition of the language.

The term embeddable refers to the fact that ECL includes a lisp to C compiler,
which produces libraries (static or dynamic) that can be called from C
programs. Furthermore, ECL can produce standalone executables from your lisp
code and can itself be linked to your programs as a shared library.

ECL supports the operating systems Linux, FreeBSD, NetBSD, OpenBSD, Solaris (at
least v. 9), Microsoft Windows and OSX, running on top of the Intel, Sparc,
Alpha and PowerPC processors. Porting to other architectures should be rather

ECL is currently hosted at Common-Lisp.net and SourceForge. The home page of
the project is http://ecls.sourceforge.net, and in it you will find source code
releases, a CVS tree and some useful documentation.

Known issues

This release features a new model for handling signals, which is a bit more
compatible with both POSIX and Windows' expectations. This involves changes
for instance in the toplevel, regarding how Ctrl-C (SIGINT) is handled: this
event is captured by a separate thread and, if more than one thread is present,
it will enter the debugger and give the user a choice on which thread to
interrupt. However, as all improvements, this may need polishing, rounding a
few corners, etc. Feedback and bug reports are welcome.

ECL is also aggressively moving towards supporting threads everywhere. However
this support is not entirely possible with older releases of the garbage collector.
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)

Changes since last release

See file src/CHANGELOG or browse it online

http://ecls.cvs.sourceforge.net/viewvc/ ... iew=markup
Posts: 38
Joined: Mon Oct 13, 2008 2:48 pm

[ANN] ECL v9.10.2

Postby jjgarcia » Fri Oct 09, 2009 11:20 am

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.

ECL 9.10.2:

* Bugs fixed:

- 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.
Posts: 38
Joined: Mon Oct 13, 2008 2:48 pm

Return to Common Lisp

Who is online

Users browsing this forum: No registered users and 5 guests