Embeddable Common-Lisp / News: Recent posts

Hello! Since we don't have a proper rss feed yet (I'll work on it in the upcoming weeks and post link here, when done), I'm informing here, that the new ECL release is available. Enjoy!

https://common-lisp.net/project/ecl

Regards,
Daniel

PS This is the last post on this channel (except pointer to new rss feed), since we've moved from SF to above-mentioned address.

Table of Contents

• 1. ECL Quarterly - Volume I
  • 1.1. Preface
  • 1.2. Changes and development status
  • 1.3. Contributing to ECL
    • 1.3.1. Documentation, tutorials, wiki, others
    • 1.3.2. Source code contributions

... read more

My deep apologies to all Windows users for misfortunate unicode character at top screen, which caused an exception at the very start of ECL startup. Version 15.2.21 was released little prematurely. Proper fix is released a week after problem was noticed, because we did want to test it first, and to fix a few regressions between 13.5.1 and 15.2.21.

This release is at least as good as 15.2.21. Enchantments include:... read more

New release, which is mainly current state of git HEAD (plus a few fixes). Contains numerous bug-fixes in comparison to 13.5.1 and is last, which follows date-based version convention. It's time to finally release ECL 1.0 ;-).

Development moves to gitorious (https://gitorious.org/embeddable-common-lisp), same as wiki (previous content is inaccessible now, but once subscription is renewed, I'll start to migrate content from there). In GIT topic - current permissions will be preserved. Just drop me a line with gitorious login, and I'll add person on corresponding permission level to project.... read more

Reasons here: http://article.gmane.org/gmane.lisp.ecl.general/10264

Known issues

• Cygwin's library is still broken: fork/exec fails to reload the cygwin library, or ECL's compiled libraries in a completely random fashion. For this reason we recommend using ext:system instead of ext:run-program in that platform.
• In Windows ECL comes with bytecodes compiler by default, because C compilers are normally not avaiable. Unfortunately several libraries out there are not prepared for this. If you plan to use quicklisp and have a C compiler accessible to ECL, you may use (ext:install-c-compiler) to switch back to the Lisp-to-C compiler. ... read more

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

1. CLX requires recursive locks, but ECL now makes non-recursive the default. I fixed CLX in ECL.

2. Stumpwm uses the old ASDF-ECL building routines instead of the new and improved ASDF-BUNDLE which is standard and supported by ASDF (Faré).

3. 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:

• 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.

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

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

Sorry for the multiple posting -- I had some problems with SourceForge news submission today.

Known issues

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

• Lots and lots of fixes.

See file src/CHANGELOG or browse it online

http://ecls.cvs.sourceforge.net/viewvc/ecls/ecl/src/CHANGELOG?view=markup

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
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.

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.

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 (1.0.29.11)
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?

• most of QtGui (+ overriding virtuals)
• interactive SLIME (needs a small patch, but no threads)
• unicode
• internationalization
• dynamically loadable UIs

• cross-platform

• no CLOS

• no GC (not a real problem, see notes in documentation)... read more