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

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.2a)

Changes since last release
==========================

See file src/CHANGELOG or browse it online

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

In article 
<4faca701-e931-473f-bca5-8371c090e915@g6g2000vbr.googlegroups.com>,
 Juanjo <juanjose.garciaripoll@googlemail.com> wrote:

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


Mac OS X 10.6.1

../configure
make

....


if test -f ../CROSS-DPP ; then ../CROSS-DPP /Lisp/Implementations/ecl/ecl-9.10.1/src/c/unixint.d tmp.c ; else ./dpp /Lisp/Implementations/ecl/ecl-9.10.1/src/c/unixint.d tmp.c ; fi
dpp: /Lisp/Implementations/ecl/ecl-9.10.1/src/c/unixint.d -> tmp.c

Unknown symbol: mp::interrupt-process
gcc -DECLDIR="\"/usr/local/lib/ecl-9.10.1\"" -I. -I/Lisp/Implementations/ecl/ecl-9.10.1/build -I/Lisp/Implementations/ecl/ecl-9.10.1/src/c -I../ecl/gc -DECL_API -DECL_NO_LEGACY -g -O2 -fPIC -fno-common  -Ddarwin -c  -o unixint.o tmp.c
/Lisp/Implementations/ecl/ecl-9.10.1/src/c/unixint.d: In function �unblock_signal�:
/Lisp/Implementations/ecl/ecl-9.10.1/src/c/unixint.d:367: error: �struct cl_core_struct� has no member named �default_sigmaks�
/Lisp/Implementations/ecl/ecl-9.10.1/src/c/unixint.d: In function �si_catch_signal�:
/Lisp/Implementations/ecl/ecl-9.10.1/src/c/unixint.d:681: warning: passing argument 2 of �mysignal� from incompatible pointer type
make[2]: *** [unixint.o] Error 1
make[1]: *** [libeclmin.a] Error 2
make: *** [all] Error 2

-- 
http://lispm.dyndns.org/

When ECL is built with threads on Ubuntu Jaunty X86_64:

  (require :clx)

fails with a missing make-process-lock function.  This has been
true for at least the last few releases.

Is this the problem?

diff --git a/src/clx/dependent.lisp b/src/clx/dependent.lisp
index cb33f3e..2608c24 100644
--- a/src/clx/dependent.lisp
+++ b/src/clx/dependent.lisp
@@ -893,7 +893,7 @@
   (sb-thread:make-mutex :name name))

 #+(and ecl threads)
-(defun make-lock (name)
+(defun make-process-lock (name)
   (mp:make-lock :name name))

 ;;; HOLDING-LOCK: Execute a body of code with a lock held.

-- 
Barry Fishman

On Oct 8, 6:55=A0pm, Barry Fishman <barry_fish...@acm.org> wrote:
> WhenECLis built with threads on Ubuntu Jaunty X86_64:
>
> =A0 (require :clx)
>
> fails with a missing make-process-lock function. =A0This has been
> true for at least the last few releases.

I did not know this. I do not regularly test CLX on all builds. A fix
for this will be produced tomorrow.

Juanjo