Recent changes to news

Stumpwm can be built with ECL

Juan Jose Garcia Ripoll — Thu, 17 Jan 2013 22:36:21 -0000

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

CLX requires recursive locks, but ECL now makes non-recursive the default. I fixed CLX in ECL.
Stumpwm uses the old ASDF-ECL building routines instead of the new and improved ASDF-BUNDLE which is standard and supported by ASDF (Faré).
Stumpwm's RELOAD kept a reference to ASDF which should not be there for standalone programs, since ASDF is not used in that case.

The patches are here https://dl.dropbox.com/u/23177754/stumpwm.patches

ECL 12.12.1 released

Juan Jose Garcia Ripoll — Fri, 07 Dec 2012 21:54:47 -0000

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 http://ecls.cvs.sourceforge.net/viewvc/ecls/ecl/src/CHANGELOG?view=markup PS: If you read ECL news through Planet Lisp, please follow the links to the original page, https://sourceforge.net/p/ecls/news , because SF's news feed breaks all the beautiful formatting of its markup code.

Involvement in ECL

Juan Jose Garcia Ripoll — Thu, 29 Nov 2012 09:06:45 -0000

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 http://ecls.sourceforge.net/reports-generated/ecl/index.html and here http://ecls.sourceforge.net/pictures/index_js.html , you may now see in real time what problems are left to be solved in terms both of compatibility and performance. Usually, the things to be corrected are small details, like a core function that does not have an optimised inline expansion (SEARCH, FIND, etc), or some tiny mismatch between the expectations of library developers and what I, as an implementor of ECL, understood as standard. Many of those bugs or performance regressions are also easy to debug (*). If you wish to contribute, please do so through the appropriate channels, which include the ECL mailing list or, most notably, the bug/patch/feature/support reporting database in Sourceforge (https://sourceforge.net/p/ecls/news/new) Cheers, Juanjo (*) If you just want to optimise the compilation of certain functions, performance of CLOS, etc, etc, this can be done knowing only Common Lisp, for the Lisp->C compiler is based entirely on Common Lisp functions and relies on compiler macros for optimisations. For other tasks, some C skills and acquaintance with a C debugger is needed.

Zombie news

Juan Jose Garcia Ripoll — Wed, 01 Aug 2012 07:50:40 -0000

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.

ECL repositories changed

Juan Jose Garcia Ripoll — Thu, 26 Jul 2012 14:25:55 -0000

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://git.code.sf.net/p/ecls/ecl ecl # ECL source code git clone git://git.code.sf.net/p/ecls/ecl-doc ecl-doc # ECL documentation Go to http://www.sf.net/p/ecls to see the new project interface and the two GIT repositories, or simply check the new addresses in our downloads page http://ecls.sourceforge.net/download.html

ECL 10.3.1 released

Juan Jose Garcia Ripoll — Wed, 25 Jul 2012 18:43:46 -0000

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

ECL 9.10.2 released... Ufff

Juan Jose Garcia Ripoll — Wed, 25 Jul 2012 18:43:46 -0000

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.

ECL 9.10.1 released

Juan Jose Garcia Ripoll — Wed, 25 Jul 2012 18:43:46 -0000

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.

ECL supports libffi

Juan Jose Garcia Ripoll — Wed, 25 Jul 2012 18:43:45 -0000

ECL's foreign function interface now builds also with libffi, a library to dynamically build function calls and callbacks (http://sourceware.org/libffi/) This enlarge the list of platforms and processors for which ECL can potentially use a dynamic foreign function interface even without the C compiler. The code is currently available in our git and CVS repositories. Help and feedback is welcome in debugging or improving this implementation.

ECL git repositories changed

Juan Jose Garcia Ripoll — Wed, 25 Jul 2012 18:43:45 -0000

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.