[ANN] ECL 9.8.1 - comp.lang.lisp

Announcement of ECL v9.8.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. ECL 9.8.1: ========== * Important notes: - The GMP library had to be patched to build with latest versions of GCC. Since our patch only covers the main header and there might be some corners left, it is recommended to build ECL against a better maintained version of the library, such as MPIR or the versions supplied by your operating system. - ECL now builds properly on a large number of platforms, including Windows with and without Microsoft compilers. However, not always are all the configuration options available or well supported. The fault is not always ECL's, but also the libraries it depends on. Some of these problems are detailed below, some are to be found. As a guide, the minimally supported flags for each platform are those use for the automated testing process http://ecls.sourceforge.net/logs.html * Ports: - The Windows/MSVC port now boots also when built without support for Unicode. - The Windows/mingw32 port builds without threads. For multithreading, the user will have to build version 7.2-alpha2 of the garbage collector manually and build ECL with it. - The NetBSD port builds with default values using the garbage collector in the pkgsrc distribution. - The Solaris port (Intel and Sparc) now builds with the given libraries (GMP and Boehm). * Compiler: - The compiler now understands FFI types :[u]int{8,16,32,64}-t. - The FFI code emitted to convert from a lisp type to :uint or :unsigned-int rejected bignum inputs, even if they were in the range from 0 to UINT_MAX. Similar problem with :int * Visible changes: - New functions ecl_make_[u]int(), ecl_make_[u]long(), ecl_to_[u]int (), ecl_to_[u]long(), ecl_to_bool(), ecl_make_bool(), convert between C types and cl_object. - The C structures ecl_array, ecl_vector, ecl_base_string and ecl_string have changed. Instead of using bitfields for hasfillp and adjustable we now use a single integer field, and handle the bits manually. See the new macros ECL_ADJUSTABLE_ARRAY_P and ECL_ARRAY_HAS_FILL_POINTER_P. - Four new command-line arguments, --encoding, --input-encoding, --output-encoding and --error-encoding, allow the user to change the external formats of the default streams. - For places defined with the simple form of DEFSETF, SETF now produces a simpler expansion, without a surrounding LET* form. - The dynamic FFI is now implemented using libffi. This extends the portability and removes the previous, error prone implementation. - A new function, (SI:SAFE-EVAL form env &optional error-value), can be used to evaluate lisp forms in a safe way. If supplied three values, when an error happens, it returns ERROR-VALUE; otherwise it will invoke a debugger. - Two new functions, ecl_read_from_cstring(s) and ecl_read_from_cstring_safe(s,v) read an object from a C string (char *). The first one is unsafe and will enter a debugger when there is a syntax error. The second one will return V when an error happens. - Modules which are loaded with REQUIRE, but which belong to ECL, are now registered with ASDF and can be used in dependencies. * Bugs fixed: - SI:GET-LIBRARY-PATHNAME did not work properly in Windows. - STEP did not work properly because the bytecompiler introduced an extra opcode after STEPCALL. - --enable-slow-config works again. - EXT:CHDIR was broken when using Unicode.

Juanjo wrote: > Announcement of ECL v9.8.1 > ========================== I've tried to download the archive at http://downloads.sourceforge.net/project/ecls/ecls/9.8/ecl-9.8.1.tgz and different mirrors, but the archive is corrupt. Both WinRar and Cygwin tar says: ecl-9.8.1/src/gmp/mpn/sparc32/README ecl-9.8.1/src/gmp/mpn/sparc32/rshift.asm ecl-9.8.1/src/gmp/mpn/sparc32/sparc-defs.m4 ecl-9.8.1/src/gmp/mpn/sparc32/sub_n.asm ecl-9.8.1/src/gmp/mpn/sparc32/submul_1.asm : stdin: unexpected end of file ecl-9.8.1/src/gmp/mpn/sparc32/udiv.asm ecl-9.8.1/src/gmp/mpn/sparc32/udiv_nfp.asm .... ecl-9.8.1/src/gmp/mpn/sparc32/v9/README ecl-9.8.1/src/gmp/mpn/sparc32/v9/sqr_diagonal. tar: Unexpected EOF in archive tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now File info: $ sha1sum ecl-9.8.1.tgz 9cf2d0b77f355a7bf90be4d8e85fd483d38e8f96 *ecl-9.8.1.tgz File size: 4800506 bytes. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de

On 8 Aug., 11:05, Frank Buss <f...@frank-buss.de> wrote: > Juanjo wrote: > > Announcement of ECL v9.8.1 > > ========================== > > I've tried to download the archive at > > http://downloads.sourceforge.net/project/ecls/ecls/9.8/ecl-9.8.1.tgz > > and different mirrors, but the archive is corrupt. Both WinRar and Cygwin > tar says: > > ecl-9.8.1/src/gmp/mpn/sparc32/README > ecl-9.8.1/src/gmp/mpn/sparc32/rshift.asm > ecl-9.8.1/src/gmp/mpn/sparc32/sparc-defs.m4 > ecl-9.8.1/src/gmp/mpn/sparc32/sub_n.asm > > ecl-9.8.1/src/gmp/mpn/sparc32/submul_1.asm > : stdin: unexpected end of file > ecl-9.8.1/src/gmp/mpn/sparc32/udiv.asm > ecl-9.8.1/src/gmp/mpn/sparc32/udiv_nfp.asm > ... > ecl-9.8.1/src/gmp/mpn/sparc32/v9/README > ecl-9.8.1/src/gmp/mpn/sparc32/v9/sqr_diagonal. > tar: Unexpected EOF in archive > tar: Unexpected EOF in archive > tar: Error is not recoverable: exiting now > > File info: > > $ sha1sum ecl-9.8.1.tgz > 9cf2d0b77f355a7bf90be4d8e85fd483d38e8f96 *ecl-9.8.1.tgz > > File size: 4800506 bytes. > yes, same here. Check out of CVS worked, though.

On Aug 8, 11:44=A0am, Rainer Joswig <jos...@lisp.de> wrote: > On 8 Aug., 11:05, Frank Buss <f...@frank-buss.de> wrote: > > Juanjo wrote: > > > Announcement of ECL v9.8.1 > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > > I've tried to download the archive at > > >http://downloads.sourceforge.net/project/ecls/ecls/9.8/ecl-9.8.1.tgz > > > and different mirrors, but the archive is corrupt. Both WinRar and Cygw= in > > tar says: > > > File size: 4800506 bytes. > > yes, same here. Check out of CVS worked, though. Sorry, I am away from home and working with a cell phone, so I could not check the status of the file. I have uploaded a new version of the file and verified that it worked from another computer. Juanjo

On Aug 8, 11:05=A0am, Frank Buss <f...@frank-buss.de> wrote: > > File info: > > $ sha1sum ecl-9.8.1.tgz > 9cf2d0b77f355a7bf90be4d8e85fd483d38e8f96 *ecl-9.8.1.tgz > > File size: 4800506 bytes. These are the right values $ sha1sum ecl-9.8.1.tgz dd267cfffe14b1d4f6d9e69884d479cbe4b64c6e ecl-9.8.1.tgz $ ls -l ecl-9.8.1.tgz -rw-rw-r-- 1 jjgarcia jjgarcia 5732115 Aug 8 15:15 ecl-9.8.1.tgz

Juanjo wrote: > These are the right values > > $ sha1sum ecl-9.8.1.tgz > dd267cfffe14b1d4f6d9e69884d479cbe4b64c6e ecl-9.8.1.tgz > $ ls -l ecl-9.8.1.tgz > -rw-rw-r-- 1 jjgarcia jjgarcia 5732115 Aug 8 15:15 ecl-9.8.1.tgz Thanks, now it works. And even Visual Studio 2008 compiles it without crashing :-) -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de

Frank Buss <fb@frank-buss.de> writes: > Juanjo wrote: > >> These are the right values >> >> $ sha1sum ecl-9.8.1.tgz >> dd267cfffe14b1d4f6d9e69884d479cbe4b64c6e ecl-9.8.1.tgz >> $ ls -l ecl-9.8.1.tgz >> -rw-rw-r-- 1 jjgarcia jjgarcia 5732115 Aug 8 15:15 ecl-9.8.1.tgz > > Thanks, now it works. And even Visual Studio 2008 compiles it without > crashing :-) It seems that when installed in a non-standard place on MacOSX, it doesn't work well... [pjb@galatea :0.0 ecl-9.8.1]$ cd [pjb@galatea :0.0 ~]$ /opt/ecl-9.8.1/bin/ecl dyld: Library not loaded: libecl.9.8.dylib Referenced from: /opt/ecl-9.8.1/bin/ecl Reason: image not found Trace/BPT trap [pjb@galatea :0.0 ~]$ history|tail -8 783 sudo mkdir /opt/ecl-9.8.1 784 sudo chown pjb:pjbgroup /opt/ecl-9.8.1 785 ./configure --prefix=/opt/ecl-9.8.1 786 make 787 make install 788 cd 789 /opt/ecl-9.8.1/bin/ecl 790 history|tail -10 [pjb@galatea :0.0 ~]$ LD_LIBRARY_PATH=/opt/ecl-9.8.1/lib /opt/ecl-9.8.1/bin/ecl dyld: Library not loaded: libecl.9.8.dylib Referenced from: /opt/ecl-9.8.1/bin/ecl Reason: image not found Trace/BPT trap [pjb@galatea :0.0 ~]$ -- __Pascal Bourguignon__

Pascal J. Bourguignon wrote: > It seems that when installed in a non-standard place on MacOSX, it > doesn't work well... .... > [pjb@galatea :0.0 ~]$ LD_LIBRARY_PATH=/opt/ecl-9.8.1/lib /opt/ecl-9.8.1/bin/ecl > dyld: Library not loaded: libecl.9.8.dylib > Referenced from: /opt/ecl-9.8.1/bin/ecl I read something about old versions of ECL using an RPATH in the executable to point to libecl but newer versions dropping this controversial feature. Try adding /opt/ecl-9.8.1/lib to DYLIB_LIBRARY_PATH and loading ecl again. - Daniel

On Aug 8, 8:31 pm, D Herring <dherr...@at.tentpost.dot.com> wrote: > Pascal J. Bourguignon wrote: > > It seems that when installed in a non-standard place on MacOSX, it > > doesn't work well... > ... > > [pjb@galatea :0.0 ~]$ LD_LIBRARY_PATH=/opt/ecl-9.8.1/lib /opt/ecl-9.8.1/bin/ecl > > dyld: Library not loaded: libecl.9.8.dylib > > Referenced from: /opt/ecl-9.8.1/bin/ecl > > I read something about old versions ofECLusing an RPATH in the > executable to point to libecl but newer versions dropping this > controversial feature. Try adding /opt/ecl-9.8.1/lib to > DYLIB_LIBRARY_PATH and loadingeclagain. Indeed, we stopped using -rpath for security reasons because I was constantly pestered by Linux distribution maintainers and other people about this. But in the last time users are becomming so annoying (sorry, annoyed ;-) about this that I may reintroduce the flag again. Seems it is impossible to keep everybody happy, hehe Juanjo

On Aug 8, 6:39=A0pm, p...@informatimago.com (Pascal J. Bourguignon) wrote: > [pjb@galatea :0.0 ~]$ LD_LIBRARY_PATH=3D/opt/ecl-9.8.1/lib =A0/opt/ecl-9.= 8.1/bin/ecl > dyld: Library not loaded: libecl.9.8.dylib > =A0 Referenced from: /opt/ecl-9.8.1/bin/ecl > =A0 Reason: image not found For some reason (hystorical?) OS X uses DYLD_LIBRARY_PATH instead of LD_LIBRARY_PATH to find the libraries. As I said in a different message, I will probably create the next release with flags to hard- code the library location. Juanjo

Juanjo wrote: > On Aug 8, 8:31 pm, D Herring <dherr...@at.tentpost.dot.com> wrote: >> Pascal J. Bourguignon wrote: >>> It seems that when installed in a non-standard place on MacOSX, it >>> doesn't work well... >> ... >>> [pjb@galatea :0.0 ~]$ LD_LIBRARY_PATH=/opt/ecl-9.8.1/lib /opt/ecl-9.8.1/bin/ecl >>> dyld: Library not loaded: libecl.9.8.dylib >>> Referenced from: /opt/ecl-9.8.1/bin/ecl >> I read something about old versions ofECLusing an RPATH in the >> executable to point to libecl but newer versions dropping this >> controversial feature. Try adding /opt/ecl-9.8.1/lib to >> DYLIB_LIBRARY_PATH and loadingeclagain. > > Indeed, we stopped using -rpath for security reasons because I was > constantly pestered by Linux distribution maintainers and other people > about this. But in the last time users are becomming so annoying > (sorry, annoyed ;-) about this that I may reintroduce the flag again. > Seems it is impossible to keep everybody happy, hehe Maybe configure could take an --enable-rpath option? - Daniel

D Herring <dherring@at.tentpost.dot.com> writes: > Pascal J. Bourguignon wrote: > >> It seems that when installed in a non-standard place on MacOSX, it >> doesn't work well... > ... >> [pjb@galatea :0.0 ~]$ LD_LIBRARY_PATH=/opt/ecl-9.8.1/lib /opt/ecl-9.8.1/bin/ecl >> dyld: Library not loaded: libecl.9.8.dylib >> Referenced from: /opt/ecl-9.8.1/bin/ecl > > I read something about old versions of ECL using an RPATH in the > executable to point to libecl but newer versions dropping this > controversial feature. Try adding /opt/ecl-9.8.1/lib to > DYLIB_LIBRARY_PATH and loading ecl again. Thanks, with DYLD_LIBRARY_PATH=/opt/ecl-9.8.1/lib /opt/ecl-9.8.1/bin/ecl it works well. That must be a MacOSX thing, I guess. -- __Pascal Bourguignon__

Juanjo <juanjose.garciaripoll@googlemail.com> writes: > On Aug 8, 8:31 pm, D Herring <dherr...@at.tentpost.dot.com> wrote: >> Pascal J. Bourguignon wrote: >> > It seems that when installed in a non-standard place on MacOSX, it >> > doesn't work well... >> ... >> > [pjb@galatea :0.0 ~]$ LD_LIBRARY_PATH=/opt/ecl-9.8.1/lib /opt/ecl-9.8.1/bin/ecl >> > dyld: Library not loaded: libecl.9.8.dylib >> > Referenced from: /opt/ecl-9.8.1/bin/ecl >> >> I read something about old versions ofECLusing an RPATH in the >> executable to point to libecl but newer versions dropping this >> controversial feature. Try adding /opt/ecl-9.8.1/lib to >> DYLIB_LIBRARY_PATH and loadingeclagain. > > Indeed, we stopped using -rpath for security reasons because I was > constantly pestered by Linux distribution maintainers and other people > about this. But in the last time users are becomming so annoying > (sorry, annoyed ;-) about this that I may reintroduce the flag again. > Seems it is impossible to keep everybody happy, hehe It should be enough to add a message and documentation for MacOSX users: if [ -n "${prefix}" -a "$(uname)" = "Darwin" ] ; then echo "You will have to put ${prefix}/lib on DYLD_LIBRARY_PATH to be able to run ${prefix}/bin/ecl" fi -- __Pascal Bourguignon__