Announcement of ECL v9.4.0
==========================
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
easy.
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.
Notes for this release
======================
This release is the first one with a new design of ECL, which includes
changes
in the way streams are implemented, support for full Unicode character
set,
safety against C interrupts and serious performance improvements.
Known issues:
+ Threads and Unicode currently do not work in the Windows port.
There may be some other rough corners left.
Please submit bug reports about them.
Changes since 8.12.0
====================
See file src/CHANGELOG or browse it online
http://common-lisp.net/cgi-bin/viewcvs.cgi/ecl/src/CHANGELOG?root=ecl&view=markup
On 3 ÁÐÒ, 22:07, Juanjo <·····················@googlemail.com> wrote:
> Announcement of ECL v9.4.0
> ==========================
>
> 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
> easy.
>
> ECL is currently hosted at Common-Lisp.net and SourceForge. The home
> page of
> the project ishttp://ecls.sourceforge.net, and in it you will find
> source code
> releases, a CVS tree and some useful documentation.
>
> Notes for this release
> ======================
>
> This release is the first one with a new design of ECL, which includes
> changes
> in the way streams are implemented, support for full Unicode character
> set,
> safety against C interrupts and serious performance improvements.
>
> Known issues:
>
> + Threads and Unicode currently do not work in the Windows port.
>
> There may be some other rough corners left.
> Please submit bug reports about them.
>
> Changes since 8.12.0
> ====================
>
> See file src/CHANGELOG or browse it online
>
> http://common-lisp.net/cgi-bin/viewcvs.cgi/ecl/src/CHANGELOG?root=ecl...
As for me, it is very interresting. I don't know where it is intended
to be used, though. Maby in Pocket-PC's?
On 3 Apr, 20:55, ···········@gmail.com wrote:
> As for me, it is very interresting. I don't know where it is intended
> to be used, though. Maby in Pocket-PC's?
It depends on the size of your pocket...
As of today (and excluding explicitly all of Parallel Universes),
quite any electronic computing machine is designed upon some C
operating system, so it should do well quite everywhere...
On 4 ÁÐÒ, 01:21, ········@gmail.com wrote:
> On 3 Apr, 20:55, ···········@gmail.com wrote:
>
> > As for me, it is very interresting. I don't know where it is intended
> > to be used, though. Maby in Pocket-PC's?
>
> It depends on the size of your pocket...
>
> As of today (and excluding explicitly all of Parallel Universes),
> quite any electronic computing machine is designed upon some C
> operating system, so it should do well quite everywhere...
I just wonder, if the purpose of such implementations is to make
something like FFI (Foreign function interface) other way, so that you
can just call lisp functions from C. Or, maybe the aim is to make
machines, which never can have any Lisp interpreter (i don't know,
maybe PLCs - programmable logic controllers), to make them
programmable in lisp.
I am reading some comments that either reflect a lack of precision in
how we present ECL or a lack of knowledge from the public about the
Common Lisp implementation landscape and history.
The first implementation of the Common Lisp "standard" (at that time
it was not yet a standard) was KCL, an implementation that shipped an
interpreter of the language together with a compiler that used C as
intermediate representation. This implementation evolved into AKCL,
GCL and its brother ECL.
ECL is a full implementation of the Common Lisp language that does NOT
have as objective to be a toy implementation, a toy interpreter or a
implementation only for small systems.
Instead it is an implementation with clear objectives:
- Build a library with the Common Lisp standard.
- Use of C and standard libraries for universal portability.
- Good isolation of the Lisp environment, that allows playing well
with other C libraries.
- Extensibility, stability, scalability from small to large systems.
The design choices in particular allow:
- Compiling Lisp code to C, for greater speed.
- Embedding ECL in larger applications as scripting language.
- Build standalone applications that mix ECL with other libraries.
- Easy FFI to C libraries.
- Running ECL anywhere where a C library and a minimal operating
system exists.
ECL has been so ported to different varieties of Unix operating
systems, but also to other platforms, such as Windows, and more
recently a user has been able to build ECL for the iPhone (now that I
upgraded the garbage collector library it should be easier for him to
produce a step-by-step guide).
The future is bright for this implementation as well. Errors are being
fixed, rough corners are being polished, and the implementation allows
for future experimentation. In particular we want to improve the
compilation strategy, merging the code for the bytecodes and C
compiler into a more extensible architecture (see http://tream.dreamhosters.com/)
Hope the motivations of this project are clearer now.
Juanjo
Juanjo <·····················@googlemail.com> writes:
- Embedding ECL in larger applications as scripting
language.
So it can be used for roughly what Guile is designed for.
Is it relatively simple to retro-fit a C application with
ECL? Could it be used as a scripting language for, eg. GNU
Emacs :-)
I recently saw that someone had gotten it attached to
Autohotkeys (an MS-Windows-based global keybinding and
macros program) but it was unclear to me how to make use of
it. Something like that might be useful, though.
On 4 abr, 18:49, Evans Winner <······@timbral.net> wrote:
> Juanjo <·····················@googlemail.com> writes:
>
> - Embedding ECL in larger applications as scripting
> language.
>
> So it can be used for roughly what Guile is designed for.
> Is it relatively simple to retro-fit a C application with
> ECL? Could it be used as a scripting language for, eg. GNU
> Emacs :-)
Here is an example:
http://www.progmatism.com/software/kamen/index.php
>
> I recently saw that someone had gotten it attached to
> Autohotkeys (an MS-Windows-based global keybinding and
> macros program) but it was unclear to me how to make use of
> it. Something like that might be useful, though.
SLIME seems to be still non-functional with ECL. Is that correct?
Also, ecl-readline seems not to be working. It gives me a a REPL with
no prompt. Then hitting control-c results in a stack overflow.
But now I can't remember if it ever worked.
Neil
On Apr 5, 7:21 pm, Neil Baylis <···········@gmail.com> wrote:
> SLIME seems to be still non-functional withECL. Is that correct?
SLIME was ported to ECL long time ago. Since then, changes have been
committed to both SLIME and ECL and there might have been some
temporary incompatibilities among them. But right now none of the
SLIME users that post to our mailing lists have complained.
> Also,ecl-readline seems not to be working. It gives me a a REPL with
> no prompt. Then hitting control-c results in a stack overflow.
> But now I can't remember if it ever worked.
I sent some fixes to the maintainer long ago, and he produced a new
version, but this one has become obsolete. There is as of today a new
patch release of ECL that solves a problem (ecl-readline needs to
redefine peek-char, while the Gray streams interface does not allow
it) and I have posted the appropriate fixes to ecl-readline to our
mailing list. You may download them from the mailing list archive
(https://sourceforge.net/mailarchive/forum.php?forum_name=ecls-list)
when they show up, or wait for the maintainer to incorporate them.
Juanjo
On Apr 6, 9:12 am, Juanjo <·····················@googlemail.com>
wrote:
> On Apr 5, 7:21 pm, Neil Baylis <···········@gmail.com> wrote:
>
> > SLIME seems to be still non-functional withECL. Is that correct?
>
> SLIME was ported to ECL long time ago. Since then, changes have been
> committed to both SLIME and ECL and there might have been some
> temporary incompatibilities among them. But right now none of the
> SLIME users that post to our mailing lists have complained.
"Being a Slime user means living in a house inhabited by a family of
crazed carpenters. When you wake up, the house is different. Maybe
there is a new turret, or some walls have moved, or perhaps someone
has removed the floor under your bed."
The slime maintainers don't seem to have ever appreciated the virtues
of stable releases to which other projects can code.
>
> > On Apr 5, 7:21 pm, Neil Baylis <···········@gmail.com> wrote:
>
> > > SLIME seems to be still non-functional withECL. Is that correct?
>
> > SLIME was ported to ECL long time ago. Since then, changes have been
> > committed to both SLIME and ECL and there might have been some
> > temporary incompatibilities among them. But right now none of the
> > SLIME users that post to our mailing lists have complained.
>
Maybe there's something wrong with my setup, although it works fine
for sbcl and ccl (actually, clojure as well). With ECL I get a
segfault:
(progn (load "/Users/neil/lisp/slime/swank-loader.lisp" :verbose t)
(funcall (read-from-string "swank-loader:init")) (funcall (read-from-
string "swank:start-server") "/var/folders/f4/f4fsPC+8HjWzxJvofGJDB+++
+TI/-Tmp-/slime.5460" :coding-system "iso-latin-1-unix"))
;;; Loading #P"/usr/local/lib/ecl-9.4.0/ASDF.fas"
;;; Loading #P"/usr/local/lib/ecl-9.4.0/CMP.fas"
;;; Loading #P"/usr/local/lib/ecl-9.4.0/sysfun.lsp"
ECL (Embeddable Common-Lisp) 9.4.0
Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya
Copyright (C) 1993 Giuseppe Attardi
Copyright (C) 2000 Juan J. Garcia-Ripoll
ECL is free software, and you are welcome to redistribute it
under certain conditions; see file 'Copyright' for details.
Type :h for Help. Top level.
>
;;; Loading "/Users/neil/lisp/slime/swank-loader.lisp"
;;; Warning: No architecture feature found in (POWERPC PPC X86 X86-64
AMD64
I686 I586 I486 PC386
IAPX386
SPARC64 SPARC HPPA64
HPPA).
;;; Loading "/Users/neil/lisp/slime/swank-backend.lisp"
;;; Loading "/Users/neil/lisp/slime/swank-source-path-parser.lisp"
;;; Loading "/Users/neil/lisp/slime/swank-source-file-cache.lisp"
;;; Loading "/Users/neil/lisp/slime/swank-ecl.lisp"
;;; Loading #P"/usr/local/lib/ecl-9.4.0/SOCKETS.fas"
;;; Loading "/Users/neil/lisp/slime/swank-gray.lisp"
;;; Loading "/Users/neil/lisp/slime/swank.lisp"
;;; Warning: These Swank interfaces are unimplemented:
(ACTIVATE-STEPPING ADD-FD-HANDLER ADD-SIGIO-HANDLER ALL-THREADS CALLS-
WHO
INTERRUPT-THREAD LIST-CALLEES LIST-CALLERS PROFILE PROFILE-PACKAGE
PROFILE-REPORT PROFILE-RESET PROFILED-FUNCTIONS RECEIVE-IF REMOVE-FD-
HANDLERS
REMOVE-SIGIO-HANDLERS RESTART-FRAME RETURN-FROM-FRAME SAVE-IMAGE
SEND
SLDB-BREAK-AT-START SLDB-BREAK-ON-RETURN SLDB-STEP-INTO SLDB-STEP-
NEXT
SLDB-STEP-OUT SPAWN TOGGLE-TRACE UNPROFILE WHO-BINDS WHO-CALLS
WHO-MACROEXPANDS WHO-REFERENCES WHO-SETS WHO-SPECIALIZES)
;; Swank started at port: 62618.
CL-USER>
Internal or unrecoverable error in:
SIGSEGV without handler to jump to.
[2: No such file or directory]
Process inferior-lisp abort trap
On Apr 6, 5:05 pm, Neil Baylis <···········@gmail.com> wrote:
> > > On Apr 5, 7:21 pm, Neil Baylis <···········@gmail.com> wrote:
>
> > > > SLIME seems to be still non-functional withECL. Is that correct?
This fails for me as well in the 9.4.0 release but works fine in the
patch release of today (9.4.1)
Karsten
On Apr 6, 1:58 pm, ·············@gmail.com wrote:
> On Apr 6, 5:05 pm, Neil Baylis <···········@gmail.com> wrote:> > > On Apr 5, 7:21 pm, Neil Baylis <···········@gmail.com> wrote:
>
> > > > > SLIME seems to be still non-functional withECL. Is that correct?
>
> This fails for me as well in the 9.4.0 release but works fine in the
> patch release of today (9.4.1)
>
> Karsten
Yes, 9.4.1 fixes whatever the problem was. Thanks.