Reasons here: http://article.gmane.org/gmane.lisp.ecl.general/10264
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.... read more
Some highlights of this release are:
See file src/CHANGELOG or browse it online
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.
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.... read more
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 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
Sorry for the multiple posting -- I had some problems with SourceForge news submission today.
This release is the first one with the new multithreading library,
which no longer relies on the POSIX mutexes, condition variables and
semaphores. Instead, ECL makes use of libatomic-ops to implement
userspace routines for process communication (mailboxes), resource
sharing (locks, condition variables, counting semaphores) and fast
spinlocks.... read more
See file src/CHANGELOG or browse it online
It seems that Windows now implements a kind of input history for any application that uses the console. This is nice, because it allows ECL users that directly work on a terminal window to recall previous commands, using just the arrow keys -- a limited form of what "readline" does for you --.
On a side note, the next release of ECL will ship with a small script to install quicklisp in the installation directory. It will be as simple as using (require :ecl-quicklisp) from the Common Lisp prompt. ECL will download the installation file and run it for you with the appropriate paths.
ECL's manual, which is found here http://ecls.sourceforge.net/new-manual/ is being updated on two fronts. The most important part is to document features that were long present but were not explained in the documentation. This includes for instance character types, support for Unicode or external formats, which were erroneously absent from the manual for several years.
The second set of improvements consists on the documentation of its C/C++ API. The manual now lists the C equivalents of almost all Standard Common Lisp functions and types, and in the following days we will add also the functions and macros which are proper just to the C part, such as conversion from all C types to Lisp and back, memory allocation, etc.
Today or tomorrow I will upload a set of changes that will make ECL build with support for threads by default. If you want a single-threaded ECL, use "--disable-threads" when configuring it.
On a completely different matter, thanks to user contributed patches, ECL now seems to build in 64 bit mode using Visual Studio C++ (express) or Microsoft's SDK for Windows v7.1 (free).
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
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
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
ECL: 0.060 s (git/CVS)
SBCL: 0.038 s (22.214.171.124)
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?
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
Downloading ECL: http://ecls.sf.net/download.html
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.... read more
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:
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.