CMUCL version 19a will be released at the end of July. We would
appreciate help in testing the prerelease binaries that are available
for various platforms. Here's how you can help test:
- download the pre3 binaries for your platform
- read the release notes
- try to compile and run your favorite applications (note that FASL
files from this release are binary-incompatible with previous
CMUCL releases; you will need to recompile all source files)
- report any problems you encounter to the cmucl-help mailing list
(see <URL:http://www.cons.org/cmucl/support.html> for details of our
mailing lists)
This release will include a number of significant changes from CMUCL 18e,
that are detailed in the release notes:
- significant improvements to the CLOS implementation
- a package locking mechanism has been added
- overflows of the lisp control stack are detected
- a precise generational garbage collector for SPARC
- compile-time format-string checking
- modular arithmetic on x86 and SPARC
- many ANSI compliance problems identified by Paul Dietz's test suite
have been fixed
Prerelease binaries for x86/Linux, x86/FreeBSD and SPARC/Solaris can
be downloaded from the following URLs (the "pre3" binaries are the
ones you want). Documentation for this new release is also available
in the same directory, in the file "cmu-user.pdf".
<URL:ftp://ftp.common-lisp.net/pub/project/cmucl/release/19a/>
<URL:ftp://ftp.tepus.com/pub/project/cmucl/release/19a/>
=== Things to test
Some aspects of CMUCL are platform-dependent, so would be particularly
useful to test:
- try loading shared object files and ".o" object files using the
function EXT:LOAD-FOREIGN, and check that you can resolve symbols
in these libraries and call the corresponding functions. For
example:
,----
| CL-USER> (ext:load-foreign "/usr/lib/libcrypt.so")
| ;;; Opening shared library /usr/lib/libcrypt.so ...
| ;;; Done.
| nil
| CL-USER> (alien:alien-funcall
| (alien:extern-alien "crypt"
| (function c-call:c-string c-call:c-string c-call:c-string))
| "key" "salt")
| ; Compiling lambda (#:g1469 #:g1470 #:g1471):
| ; Compiling Top-Level Form:
| "sacA7YLUSAodg"
`----
- try dumping an customized CMUCL image (using the function
EXT:SAVE-LISP) and restarting it.
If you have installed the "extra" tarball for your platform, you can
help test the CLX support, the Motif interface and the Hemlock editor.
- try connecting to your X11 display:
,----
| CL-USER> (require :clx)
| ; Loading #p"/opt/cmucl-19a-pre3/lib/cmucl/lib/subsystems/clx-library.x86f".
| t
| CL-USER> (ext:open-clx-display)
| #<xlib:display localhost:10 (The XFree86 Project, Inc R40300001)>
| #<xlib:screen localhost:10.0 1152x864x15 true-color>
`----
- try using the Motif debugger and inspector:
,----
| CL-USER> (require :clm)
| ; Loading #p"/opt/cmucl-19a-pre3/lib/cmucl/lib/subsystems/clm-library.x86f".
| t
| CL-USER> (inspect *package*)
`----
- try using the Hemlock editor:
,----
| CL-USER> (require :hemlock)
| CL-USER> (ed)
`----
Thanks for your help!
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
Hello!
Eric Marsden <········@laas.fr> wrote:
>CMUCL version 19a will be released at the end of July. We would
>appreciate help in testing the prerelease binaries that are available
>for various platforms. Here's how you can help test:
>[...]
Will there be OpenBSD (x86) binaries some time again?
Kind regards,
Just an interested Hannah.
Hannah Schroeter wrote:
>
> Will there be OpenBSD (x86) binaries some time again?
>
Unfortunately, it seems unlikely since it seems none of the main
developers has an OpenBSD system. We will have to depend on volunteers
to provide that support.
Ray
Hello!
Raymond Toy <····@earthlink.net> wrote:
>Hannah Schroeter wrote:
>> Will there be OpenBSD (x86) binaries some time again?
>Unfortunately, it seems unlikely since it seems none of the main
>developers has an OpenBSD system. We will have to depend on volunteers
>to provide that support.
OK, it isn't *so* important, and I don't think I'd be up to doing
that stuff myself.
It'd just be interesting if more than one (clisp) CL implementation
would be available for OpenBSD too.
Kind regards,
Hannah.
>>>>> "Hannah" == Hannah Schroeter <······@schlund.de> writes:
Hannah> Hello!
Hannah> Raymond Toy <····@earthlink.net> wrote:
>> Hannah Schroeter wrote:
>>> Will there be OpenBSD (x86) binaries some time again?
>> Unfortunately, it seems unlikely since it seems none of the main
>> developers has an OpenBSD system. We will have to depend on volunteers
>> to provide that support.
Hannah> OK, it isn't *so* important, and I don't think I'd be up to doing
Hannah> that stuff myself.
Hannah> It'd just be interesting if more than one (clisp) CL implementation
Hannah> would be available for OpenBSD too.
If you're willing to do a little bit of work, an OpenBSD build could
probably be made. It would require you to be able to compile cmucl,
but the hairy stuff could be done by someone else to cross-compile the
current version from, say, Linux or FreeBSD to OpenBSD. You'd take
the results and load them up on your OpenBSD system.
I haven't done a cross-compile between 2 different systems in years,
unfortunately.
Alternatively, get sbcl, as Nikodemus says.
Ray
From: ·········@random-state.net
Subject: Re: please help test the CMUCL 19a prerelease
Date:
Message-ID: <ccjoju$21rr6$1@midnight.cs.hut.fi>
Hannah Schroeter <······@schlund.de> wrote:
> It'd just be interesting if more than one (clisp) CL implementation
> would be available for OpenBSD too.
SBCL <http://www.sbcl.org> should work on OpenBSD x86 at least. IIRC you
just need to hitch up the ulimits to build it.
Cheers,
-- Nikodemus "Not as clumsy or random as a C++ or Java.
An elegant weapon for a more civilized time."
"Hannah Schroeter" wrote in message ·················@c3po.use.schlund.de...
> It'd just be interesting if more than one (clisp) CL implementation
> would be available for OpenBSD too.
Hi Hannah.
GNU Common Lisp builds on both OpenBSD and FreeBSD (with GNU make). I
recently did it myself just to see, although I usually work on Windows.
Check out the latest stable source (version 2.6.2) at:
ftp://ftp.gnu.org/gnu/gcl/
and the web site and mailing list (CCed in this reply) if you run into
trouble:
http://savannah.gnu.org/projects/gcl/
http://lists.gnu.org/mailman/listinfo/gcl-devel
I expect that CVS HEAD would normally build on those platforms too, but of
course that will depend on what day it is, and we are about to make some
major changes there. The advantage of the HEAD is that it is more ANSI
compatible than 2.6.2 and is continually moving further in that direction.
Cheers
Mike Thomas
Eric Marsden wrote:
> CMUCL version 19a will be released at the end of July. We would
> appreciate help in testing the prerelease binaries that are available
> for various platforms. Here's how you can help test:
[...]
I'd be very interested in running some of my test programs on the OSX
binaries, if those are prepared. Is Pierre Mai still building them?
mikel wrote:
> Eric Marsden wrote:
>
>> CMUCL version 19a will be released at the end of July. We would
>> appreciate help in testing the prerelease binaries that are available
>> for various platforms. Here's how you can help test:
>
>
> [...]
>
> I'd be very interested in running some of my test programs on the OSX
> binaries, if those are prepared. Is Pierre Mai still building them?
Unfortunately, the 19a release will not include OSX support because the
sources for the OSX version was not available in time.
However, the sources should soon be incorporated, and the monthly
snapshots should include OSX.
Ray
Eric Marsden <········@laas.fr> wrote:
+---------------
| CMUCL version 19a will be released at the end of July. We would
| appreciate help in testing the prerelease binaries that are available
| for various platforms. Here's how you can help test:
| - download the pre3 binaries for your platform
| - read the release notes
| - try to compile and run your favorite applications ...
+---------------
By the way, thank you *VERY* much for the extremely fortuitous timing!!
Due to security issues [don't ask], a Linux web server that had been
running an application server I had written in CMUCL (the usual thing,
sitting between Apache and PostgreSQL) had to be replaced by a different
server that was running a later version of Linux. The old site ran a
Linux 2.4.3 kernel with glibc-2.2.4-32, which ran the precompiled
CMUCL-18e Linux binaries just fine.
Unfortunately, the new site is running RedHat Fedora 2 with a 2.6.5+
kernel and glibc-2.3.3-27 [no, I *didn't* have any say in that!], and
no matter what I try, CMUCL-18e dumps core with a "Segmentation Fault"
at startup. [I'm a FreeBSD guy myself, so all those ever-changing and
incompatible Linux "glibc"s are a complete mystery to me!]
Fortunately, CMUCL-19a-pre3 runs on the new system right out of the box!!!
*THANK YOU!* *THANK YOU!* *THANK YOU!* *THANK YOU!*
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
>>>>> "Rob" == Rob Warnock <····@rpw3.org> writes:
Rob> Unfortunately, the new site is running RedHat Fedora 2 with a 2.6.5+
Rob> kernel and glibc-2.3.3-27 [no, I *didn't* have any say in that!], and
Rob> no matter what I try, CMUCL-18e dumps core with a "Segmentation Fault"
Rob> at startup. [I'm a FreeBSD guy myself, so all those ever-changing and
Rob> incompatible Linux "glibc"s are a complete mystery to me!]
Rob> Fortunately, CMUCL-19a-pre3 runs on the new system right out of the box!!!
Rob> *THANK YOU!* *THANK YOU!* *THANK YOU!* *THANK YOU!*
You're welcome, but that it works is, unfortunately, coincidental, I
think. :-( There have been reports that it doesn't work with Fedora
2, but other reports, like yours, that says it does. There's even an
experimental build for Fedora 2 with a very different lisp memory map.
Nobody seems to know what the difference is. Something having to do
with the memory map used in Fedora2.
Ray
In article <···············@edgedsp4.rtp.ericsson.se>,
Raymond Toy <···········@ericsson.com> wrote:
> You're welcome, but that it works is, unfortunately, coincidental, I
> think. :-( There have been reports that it doesn't work with Fedora
> 2, but other reports, like yours, that says it does. There's even an
> experimental build for Fedora 2 with a very different lisp memory map.
>
> Nobody seems to know what the difference is. Something having to do
> with the memory map used in Fedora2.
Reports are that the Fedora exec-shield disaster randomizes the mapping
of libraries, which could mean that on one startup libc will be mapped
into a Lisp space, and on another startup it will be fine.
If exec-shield could be disabled on the system (either globally or only
for Lisp processes, if that's possible) the results will probably at
least be consistent.
(Examine /proc/<pid>/maps to see what a process's mappings are, and to
see if they are random and/or mapped where where Lisp wants its spaces.)
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
--=-=-=
Content-Type: text/plain
On 8804 day of my life Rob Warnock wrote:
> Unfortunately, the new site is running RedHat Fedora 2 with a 2.6.5+
> kernel and glibc-2.3.3-27 [no, I *didn't* have any say in that!], and
> no matter what I try, CMUCL-18e dumps core with a "Segmentation Fault"
> at startup. [I'm a FreeBSD guy myself, so all those ever-changing and
> incompatible Linux "glibc"s are a complete mystery to me!]
I have Mandrake Linux 10.0, kernel 2.6.3, glibc 2.3.3. CMUCL-18e
works fine. So, it is not glibc's or kernel's fault, but Red
Bullshit's problem.
--
Ivan Boldyrev
Onions have layers. Unix has layers too.
--=-=-=
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.6 (GNU/Linux)
iD8DBQBA9Lgp4rmsj66VbhcRAq9yAJ9n9ynFZll/rF6gpFYqCx7MKPvoNACfTyd+
JZXxv9WlzpmFXuacEVWw6Z4=
=iiOE
-----END PGP SIGNATURE-----
--=-=-=--
Eric Marsden wrote:
> CMUCL version 19a will be released at the end of July. We would
> appreciate help in testing the prerelease binaries that are available
> for various platforms. Here's how you can help test:
>
> - download the pre3 binaries for your platform
> - read the release notes
> - try to compile and run your favorite applications (note that FASL
> files from this release are binary-incompatible with previous
> CMUCL releases; you will need to recompile all source files)
> - report any problems you encounter to the cmucl-help mailing list
> (see <URL:http://www.cons.org/cmucl/support.html> for details of our
> mailing lists)
>
> This release will include a number of significant changes from CMUCL 18e,
> that are detailed in the release notes:
>
> - significant improvements to the CLOS implementation
> - a package locking mechanism has been added
> - overflows of the lisp control stack are detected
> - a precise generational garbage collector for SPARC
> - compile-time format-string checking
> - modular arithmetic on x86 and SPARC
> - many ANSI compliance problems identified by Paul Dietz's test suite
> have been fixed
Hello Erik, je voulais savoir si je pouvais avoir quelques instants de
ton temps pour m'expliquer deux ou trois truc. En fait je viens de
recompiler eclipse avec la 19a pour voir si pas de probleme (d'un cote
comme de l'autre) et mis � part quelques bugs de mon cot� tout semble
fonctionner.
Mais, je suis intrigu� par le comportement de deftype qui maintenant
produit plein de notes lors de la compilation. Une id�e ?
par exemple:
; In: DEFTYPE CARD-32
; (DEFTYPE CARD-32 () '(UNSIGNED-BYTE 32))
; --> EVAL-WHEN LISP::%DEFTYPE LISP::%DEFTYPE FUNCTION BLOCK LET* UNLESS
COND
; --> IF NOT IF <=
; --> (LAMBDA (#:G3 #:G2 #:G1) (IF (> #:G3 #:G2) NIL (IF # NIL T)))
; --> LISP::DOTTED-LIST-LENGTH BLOCK LOOP BLOCK LET LET
ANSI-LOOP::LOOP-BODY
; --> TAGBODY WHEN COND IF PROGN
; ==>
; (SETQ #:G4 (1+ #:G4))
; Note: Doing signed word to integer coercion (cost 20), for:
; The first argument of CHECK-FIXNUM.
;
idem avec defsetf:
; In: DEFSETF NET-SUPPORTED
; (DEFSETF NET-SUPPORTED (WINDOW &KEY #)
; (PROTOCOLS)
; `(SET-ATOMS-PROPERTY ,WINDOW ,PROTOCOLS :_NET_SUPPORTED :MODE ...))
; --> EVAL-WHEN LISP::%DEFINE-SETF-MACRO LISP::%DEFINE-SETF-MACRO FUNCTION
; --> LISP::%DEFSETF FUNCTION BLOCK LET* UNLESS COND IF NOT IF <=
; --> (LAMBDA (#:G11 #:G10 #:G9) (IF (> #:G11 #:G10) NIL (IF # NIL T)))
; --> LISP::DOTTED-LIST-LENGTH BLOCK LOOP BLOCK LET LET
ANSI-LOOP::LOOP-BODY
; --> TAGBODY WHEN COND IF PROGN
; ==>
; (SETQ #:G12 (1+ #:G12))
; Note: Doing signed word to integer coercion (cost 20), for:
; The first argument of CHECK-FIXNUM.
;
; --> EVAL-WHEN LISP::%DEFINE-SETF-MACRO LISP::%DEFINE-SETF-MACRO FUNCTION
; --> LISP::%DEFSETF FUNCTION BLOCK LET* UNLESS COND IF NOT IF <= IF >
; --> LISP::DOTTED-LIST-LENGTH BLOCK LOOP BLOCK LET LET
ANSI-LOOP::LOOP-BODY
; --> TAGBODY WHEN COND IF PROGN
; ==>
; (SETQ #:G21 (1+ #:G21))
; Note: Doing signed word to integer coercion (cost 20), for:
; The first argument of CHECK-FIXNUM.
;
Si tu as un peu plus de temps que moi cet an ci je serai tr�s interress�
si tu pouvais compiler eclipse et me dire un peu ce que pourai faire
pour netoyer un certain nombre de notes de compilation. (Je ne cherche
pas � les supprimer mais � les corriger). Mais si tu n'as pas de temps
je comprendrai aussi :).
Amit�,
Iban.
Translation follows (original text at the bottom, top posting seems
appropriate here). I don't know what to think of this. On one hand,
usenet isn't email, and one should strive to use English, except in
especially marked groups, but on the other hand, i suppose this is
better than nothing at all or a babelfish-mangled translation.
Hi Erik, i want to know if i could have some of your time to have a
couple things explained. I just recompiled eclipse with 19a to see if
there were any problem (from either sides), and, apart from a few bugs
on my side, everything seem to be working.
However, i'm intrigued by the behaviour of deftype, which now spews
tons of compilation notes. Any idea?
for example:
; In: DEFTYPE CARD-32
; (DEFTYPE CARD-32 () '(UNSIGNED-BYTE 32))
; --> EVAL-WHEN LISP::%DEFTYPE LISP::%DEFTYPE FUNCTION BLOCK LET*
UNLESS
COND
; --> IF NOT IF <=
; --> (LAMBDA (#:G3 #:G2 #:G1) (IF (> #:G3 #:G2) NIL (IF # NIL T)))
; --> LISP::DOTTED-LIST-LENGTH BLOCK LOOP BLOCK LET LET
ANSI-LOOP::LOOP-BODY
; --> TAGBODY WHEN COND IF PROGN
; ==>
; (SETQ #:G4 (1+ #:G4))
; Note: Doing signed word to integer coercion (cost 20), for:
; The first argument of CHECK-FIXNUM.
;
idem with defsetf:
; In: DEFSETF NET-SUPPORTED
; (DEFSETF NET-SUPPORTED (WINDOW &KEY #)
; (PROTOCOLS)
; `(SET-ATOMS-PROPERTY ,WINDOW ,PROTOCOLS :_NET_SUPPORTED :MODE
...))
; --> EVAL-WHEN LISP::%DEFINE-SETF-MACRO LISP::%DEFINE-SETF-MACRO
FUNCTION
; --> LISP::%DEFSETF FUNCTION BLOCK LET* UNLESS COND IF NOT IF <=
; --> (LAMBDA (#:G11 #:G10 #:G9) (IF (> #:G11 #:G10) NIL (IF # NIL
T)))
; --> LISP::DOTTED-LIST-LENGTH BLOCK LOOP BLOCK LET LET
ANSI-LOOP::LOOP-BODY
; --> TAGBODY WHEN COND IF PROGN
; ==>
; (SETQ #:G12 (1+ #:G12))
; Note: Doing signed word to integer coercion (cost 20), for:
; The first argument of CHECK-FIXNUM.
;
; --> EVAL-WHEN LISP::%DEFINE-SETF-MACRO LISP::%DEFINE-SETF-MACRO
FUNCTION
; --> LISP::%DEFSETF FUNCTION BLOCK LET* UNLESS COND IF NOT IF <= IF >
; --> LISP::DOTTED-LIST-LENGTH BLOCK LOOP BLOCK LET LET
ANSI-LOOP::LOOP-BODY
; --> TAGBODY WHEN COND IF PROGN
; ==>
; (SETQ #:G21 (1+ #:G21))
; Note: Doing signed word to integer coercion (cost 20), for:
; The first argument of CHECK-FIXNUM.
;
If you have more free time than me these days, i'd be very interested
if you could compile eclipse and tell me what i should do to clean up
some of these copilation notes (i don't want to mute them, but to
correct them). If you don't, I'll understand :)
Iban <········@yahoo.fr> wrote in message news:<············@news-reader4.wanadoo.fr>...
> Hello Erik, je voulais savoir si je pouvais avoir quelques instants de
> ton temps pour m'expliquer deux ou trois truc. En fait je viens de
> recompiler eclipse avec la 19a pour voir si pas de probleme (d'un cote
> comme de l'autre) et mis � part quelques bugs de mon cot� tout semble
> fonctionner.
>
> Mais, je suis intrigu� par le comportement de deftype qui maintenant
> produit plein de notes lors de la compilation. Une id�e ?
>
> par exemple:
>
> ; In: DEFTYPE CARD-32
>
> ; (DEFTYPE CARD-32 () '(UNSIGNED-BYTE 32))
> ; --> EVAL-WHEN LISP::%DEFTYPE LISP::%DEFTYPE FUNCTION BLOCK LET* UNLESS
> COND
> ; --> IF NOT IF <=
> ; --> (LAMBDA (#:G3 #:G2 #:G1) (IF (> #:G3 #:G2) NIL (IF # NIL T)))
> ; --> LISP::DOTTED-LIST-LENGTH BLOCK LOOP BLOCK LET LET
> ANSI-LOOP::LOOP-BODY
> ; --> TAGBODY WHEN COND IF PROGN
> ; ==>
> ; (SETQ #:G4 (1+ #:G4))
> ; Note: Doing signed word to integer coercion (cost 20), for:
> ; The first argument of CHECK-FIXNUM.
> ;
>
>
> idem avec defsetf:
>
> ; In: DEFSETF NET-SUPPORTED
>
> ; (DEFSETF NET-SUPPORTED (WINDOW &KEY #)
> ; (PROTOCOLS)
> ; `(SET-ATOMS-PROPERTY ,WINDOW ,PROTOCOLS :_NET_SUPPORTED :MODE ...))
> ; --> EVAL-WHEN LISP::%DEFINE-SETF-MACRO LISP::%DEFINE-SETF-MACRO FUNCTION
> ; --> LISP::%DEFSETF FUNCTION BLOCK LET* UNLESS COND IF NOT IF <=
> ; --> (LAMBDA (#:G11 #:G10 #:G9) (IF (> #:G11 #:G10) NIL (IF # NIL T)))
> ; --> LISP::DOTTED-LIST-LENGTH BLOCK LOOP BLOCK LET LET
> ANSI-LOOP::LOOP-BODY
> ; --> TAGBODY WHEN COND IF PROGN
> ; ==>
> ; (SETQ #:G12 (1+ #:G12))
> ; Note: Doing signed word to integer coercion (cost 20), for:
> ; The first argument of CHECK-FIXNUM.
> ;
> ; --> EVAL-WHEN LISP::%DEFINE-SETF-MACRO LISP::%DEFINE-SETF-MACRO FUNCTION
> ; --> LISP::%DEFSETF FUNCTION BLOCK LET* UNLESS COND IF NOT IF <= IF >
> ; --> LISP::DOTTED-LIST-LENGTH BLOCK LOOP BLOCK LET LET
> ANSI-LOOP::LOOP-BODY
> ; --> TAGBODY WHEN COND IF PROGN
> ; ==>
> ; (SETQ #:G21 (1+ #:G21))
> ; Note: Doing signed word to integer coercion (cost 20), for:
> ; The first argument of CHECK-FIXNUM.
> ;
>
> Si tu as un peu plus de temps que moi cet an ci je serai tr�s interress�
> si tu pouvais compiler eclipse et me dire un peu ce que pourai faire
> pour netoyer un certain nombre de notes de compilation. (Je ne cherche
> pas � les supprimer mais � les corriger). Mais si tu n'as pas de temps
> je comprendrai aussi :).
>
> Amit�,
> Iban.
>>>>> "pvk" == pkhuong <··········@pvk.ca> writes:
pvk> Translation follows (original text at the bottom, top posting seems
pvk> appropriate here). I don't know what to think of this. On one hand,
pvk> usenet isn't email, and one should strive to use English, except in
pvk> especially marked groups, but on the other hand, i suppose this is
pvk> better than nothing at all or a babelfish-mangled translation.
I think that Iban intended to send this to me as private email (we
have met before, so he knows that I speak French). Still, thanks for
translating!
pvk> However, i'm intrigued by the behaviour of deftype, which now spews
pvk> tons of compilation notes. Any idea?
regarding the original problem (spurious efficiency notes when
compiling DEFTYPE forms under high optimization), I have a one-line
fix for CMUCL, but given that it's not a serious bug, I don't know
whether the release manager (Raymond Toy) will integrate it in the
final release.
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>