Free common lisp for linux RedHat 6.0 with dumplisp capability
Ken Kubota
I am looking for a free common lisp implementation runnung on linux
RedHat 6.0 with 'dumplisp' capability (function excl:dumplisp).
The trial edition of Franz Lisp does not have the dumplisp capability,
and all the others (CMU CL, AKCL, GCL, etc.) I could not get compiled on
linux (RedHat 6.0) because of the major changes of linux within the last
years (esp. the interrupt handling did not compile).
Thanks for any hint.
Ken Kubota
Erik Naggum
| I am looking for a free common lisp implementation runnung on linux
| RedHat 6.0 with 'dumplisp' capability (function excl:dumplisp).
EXCL is the package name for Franz Inc's Extended Common Lisp, one of the
packages in Allegro CL. a function with similar use and purpose probably
exists in most other full-featured Common Lisps, but it's not useful to
refer to it by the name in Allegro CL.
that said, for what purpose do you need DUMPLISP? perhaps your needs can
be accomodated without using that particular technique.
the reason DUMPLISP is not in the Trial Edition is that Franz Inc sells a
product that offers it and there's gotta be some features that are
missing in a free version, right? why not approach them and ask about
how to accomplish whatever you want to do? seems to me like mail to
in...@franz.com would be a good first shot at this.
#:Erik
Pierre R. Mai
> I am looking for a free common lisp implementation runnung on linux
> RedHat 6.0 with 'dumplisp' capability (function excl:dumplisp).
>
> The trial edition of Franz Lisp does not have the dumplisp capability,
> and all the others (CMU CL, AKCL, GCL, etc.) I could not get compiled on
> linux (RedHat 6.0) because of the major changes of linux within the last
> years (esp. the interrupt handling did not compile).
In addition to Erik's suggestion, CMU CL should work on RedHat 6.0, but
you cannot compile CMU CL yourself unless you already have a working
binary with which to do the compilation.
Normally your best course of action is to take the Debian packages for
cmucl (those in stable if you have a glibc 2.0 based system, and those in
unstable if you have glibc 2.1, see http://www.debian.org/), and convert
them to rpms using alien.
Alas someone reported that the current unstable packages (2.4.17)
don't convert with alien. OTOH the contents of the debian packages is
really simple, so that only extracting them should work instead. (It
helps to know that *.deb packages are nothing but ar archives which
contain two tar.gz archives (and a version file), one with the pure
files, and one with the control files. So extracting the contents of
a *.deb package would work with
ar p blabla.deb data.tar.gz | tar xzfC - /
as root (beware that this installs directly into your normal file
system).
Both CMU CL (see http://www.cons.org/cmucl/) and CLISP (see
http://clisp.cons.org/) should work on RedHat 6.0 and provide you with
dumping capabilities.
Regs, Pierre.
--
Pierre Mai <pm...@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Clemens Heitzinger
> Hello,
>
> I am looking for a free common lisp implementation runnung on linux
> RedHat 6.0 with 'dumplisp' capability (function excl:dumplisp).
>
> The trial edition of Franz Lisp does not have the dumplisp capability,
> and all the others (CMU CL, AKCL, GCL, etc.) I could not get compiled on
> linux (RedHat 6.0) because of the major changes of linux within the last
> years (esp. the interrupt handling did not compile).
There is a working version of CMUCL for current Linux, but you probably
don't want to recompile it. Another implementation is clisp:
http://www.cons.org
http://clisp.cons.org
Forget AKCL, and as for GCL... it's not ANSI compliant.
--
Clemens Heitzinger
http://ag.or.at:8000/~clemens (Lisp related material)
Jason Trenouth
> * Ken Kubota <kub...@virtualphotonics.com>
> | I am looking for a free common lisp implementation runnung on linux
> | RedHat 6.0 with 'dumplisp' capability (function excl:dumplisp).
>
> EXCL is the package name for Franz Inc's Extended Common Lisp, one of the
> packages in Allegro CL. a function with similar use and purpose probably
> exists in most other full-featured Common Lisps, but it's not useful to
> refer to it by the name in Allegro CL.
>
> that said, for what purpose do you need DUMPLISP? perhaps your needs can
> be accomodated without using that particular technique.
>
> the reason DUMPLISP is not in the Trial Edition is that Franz Inc sells a
> product that offers it and there's gotta be some features that are
> missing in a free version, right? why not approach them and ask about
> how to accomplish whatever you want to do? seems to me like mail to
> in...@franz.com would be a good first shot at this.
FTR the equivalent functionality (HCL:SAVE-IMAGE) is also disabled in
Harlequin's LispWorks for Linux, Personal Edition.
__Jason
Fernando D. Mato Mira
> Alas someone reported that the current unstable packages (2.4.17)
> don't convert with alien. OTOH the contents of the debian packages is
> really simple, so that only extracting them should work instead. (It
> helps to know that *.deb packages are nothing but ar archives which
> contain two tar.gz archives (and a version file), one with the pure
> files, and one with the control files. So extracting the contents of
> a *.deb package would work with
>
> ar p blabla.deb data.tar.gz | tar xzfC - /
>
> as root (beware that this installs directly into your normal file
> system).
Thanks a lot for the info. Still:
gentoo:/tmp # lisp
Error in allocating memory, please do "echo 1 > /proc/sys/vm/overcommit_memory"
or get more memory+swap.
mmap: Cannot allocate memory
ensure_space: Failed to validate 1879048192 bytes at 0x48000000
gentoo:/tmp # echo 1 > /proc/sys/vm/overcommit_memory
gentoo:/tmp # lisp
Error in allocating memory, please do "echo 1 > /proc/sys/vm/overcommit_memory"
or get more memory+swap.
mmap: Cannot allocate memory
ensure_space: Failed to validate 1879048192 bytes at 0x48000000
gentoo:/tmp # uname -a
Linux gentoo 2.2.10 #6 Thu Nov 25 19:59:12 CET 1999 i686 unknown
gentoo:/tmp # rpm -q lx_suse
lx_suse-2.2.10.SuSE-5
(i.e, even after a little 2.2.10 -> 2.2.10 upgrading)
--
((( DANGER )) LISP BIGOT (( DANGER )) LISP BIGOT (( DANGER )))
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
Tim Bradshaw
> gentoo:/tmp # lisp
> Error in allocating memory, please do "echo 1 > /proc/sys/vm/overcommit_memory"
> or get more memory+swap.
> mmap: Cannot allocate memory
> ensure_space: Failed to validate 1879048192 bytes at 0x48000000
That's 1.7Gb, which looks extraordinarily like a bug to me. I can't
actually get my one to complain about this now but I'm sure it never
wants to allocate anything *like* that much (this is on sparc /
solaris not Linux though).
--tim
Erik Naggum
| That's 1.7Gb, which looks extraordinarily like a bug to me.
it looks like an mmap problem to me. strace should report useful values.
#:Erik
Ken Kubota
> > RedHat 6.0 with 'dumplisp' capability (function excl:dumplisp).
> >
> > and all the others (CMU CL, AKCL, GCL, etc.) I could not get compiled on
> > linux (RedHat 6.0) because of the major changes of linux within the last
> > years (esp. the interrupt handling did not compile).
>
> There is a working version of CMUCL for current Linux, but you probably
> don't want to recompile it. Another implementation is clisp:
I do not mind recompiling CMU CL for Linux, but it did not work. (The
CMU CL version I tried supported only glibc2.)
If there is a newer version available on the internet, please send me a
link.
Ken
Daniel Barlow
> Normally your best course of action is to take the Debian packages for
> cmucl (those in stable if you have a glibc 2.0 based system, and those in
> unstable if you have glibc 2.1, see http://www.debian.org/), and convert
> them to rpms using alien.
>
> don't convert with alien. OTOH the contents of the debian packages is
There is a corrupted version of cmucl_2.4.17.deb on some Debian mirror
sites, which would have caused that error from alien, but as of this
morning ftping directly from ftp.debian.org works fine. I've just upgraded.
$ md5sum cmucl_2.4.17.deb # the broken one
2f9a041fe4b6878e675042c499b123e5 cmucl_2.4.17.deb
$ md5sum cmucl_2.4.17.deb # the fixed one
e87adc9d50e9f356a86368e316f06822 cmucl_2.4.17.deb
I sent a note to the maintainers of mirror.ac.uk (my normal mirror for
just-about-anything) alerting them to this problem, so I hope they'll
be able to correct it on their site at least.
There's a handy[1] list of links to the debian pages for each bit of
CMUCL at http://www.telent.net/lisp/howto.html#you_will_need
-dan
[1] Well, I find it so anyway
Rudolf Schlatte
> Thanks a lot for the info. Still:
[cmucl 2.4.17 dies with memory allocation error]
Same here. I tried to upgrade from Debian version 2.4.15, and
the 'echo 1 >/proc/sys/vm/overcommit_memory' trick stopped working.
Package changelog says:
* moved to a new memorymap that gives us a bit more space: 1.75 GB.
Could this be the cause?
While I'm here, let me just add that it always warms my heart seeing
Lisp-related announcements on freshmeat and new packages popping up
in Debian unstable. You're doing a great job there, Peter.
Clemens Heitzinger
This was recently discussed on the CMUCL implementation mailing list.
As far as I understand, it actually tries to overcommit that much memory
which wasn't a problem on earlier Linux kernels. Allowing
overcommitting with "echo 1 >..." (the status of earlier Linux kernels)
is supposed to work, however.
Pierre R. Mai
> > There is a working version of CMUCL for current Linux, but you probably
> > don't want to recompile it. Another implementation is clisp:
>
> I do not mind recompiling CMU CL for Linux, but it did not work. (The
> CMU CL version I tried supported only glibc2.)
> If there is a newer version available on the internet, please send me a
> link.
You _do_ mind recompiling CMU CL, believe me, especially since you
need a working recent CMU CL to recompile CMU CL! ;)
What libc version do you have? If it's not at least glibc 2.0
(a.k.a. libc6), I'd suggest thinking about upgrading, since support
for non-glibc Linux is generally dwindling rapidly, IMHO. You might
take a look at the FTP repositories linked from
http://www.cons.org/cmucl/ to see if you can find an older version of
CMU CL that still works with libc5, though I doubt it (there have also
been many improvements to CMU CL since libc5 days you'd miss out on).
If you have glibc2.1 then the glibc2 versions might be causing
problems because glibc2.1 is not completely ABI compatible with
glibc2.0 in some low-level areas.
Since the current Debian version for glibc2.1 (2.4.17) seems to be
causing problems for many, I'd suggest getting 2.4.15. Try a
search with your favourite search-engine for cmucl_2.4.15.deb and
cmucl-safe_2.4.15.deb or cmucl-small_2.4.15.deb, since the Debian
archives only have the up-to-date versions in unstable.
Fernando D. Mato Mira
> Since the current Debian version for glibc2.1 (2.4.17) seems to be
> causing problems for many, I'd suggest getting 2.4.15. Try a
> search with your favourite search-engine for cmucl_2.4.15.deb and
> cmucl-safe_2.4.15.deb or cmucl-small_2.4.15.deb, since the Debian
> archives only have the up-to-date versions in unstable.
Well, I've bitten the bullet. I grabbed the 2.4.17 sources (just untrarred, I
could not figure out how to get
the dpkg stuff to work), and make make-new seems to be working OK:
[Building Initial Core File (version 23112294) in file
"target:lisp/kernel.core":
Writing 4096 bytes [1 page] from :READ-ONLY space
Writing 4096 bytes [1 page] from :STATIC space
Writing 9150464 bytes [2234 pages] from :DYNAMIC space
done]
echo -e \
'(in-package :common-lisp-user)(load "finish")\n'"release x86-linux 2.4.17
`date "+%e %B %Y"` build `cat build`"'\n' | \
./x86/lisp/lisp -core x86/lisp/kernel.core
Error in allocating memory, please do "echo 1 > /proc/sys/vm/overcommit_memory"
or get more memory+swap.
mmap: Cannot allocate memory
ensure_space: Failed to validate 1879048192 bytes at 0x48000000
make: *** [make-new] Error 1
Is there a parameter to change this?
[BTW, http://www2.cons.org/maillists/ is not accessible]
Meanwhile, cmucl_2.4.15.deb seems to have vanished froom the face of the
Earth..
Fernando D. Mato Mira
> Is there a parameter to change this?
x86-validate.h :
#define DYNAMIC_SPACE_SIZE (0x70000000) /* 1.75 GB */
William Deakin
> Allowing overcommitting with "echo 1 >..." (the status of earlier Linux
> kernels) is supposed to work, however.
I would say that it does work.
Cheers,
:) will
Fernando D. Mato Mira
Well, as I showed, before, it doesn't here. Is your kernel configured to
support upto 4GB RAM?
William Deakin
> William Deakin wrote:
>
> > I would say that it does work.
>
> Well, as I showed, before, it doesn't here. Is your kernel configured to
> support upto 4GB RAM?
Uhhh, yeah....why?
:) will
Hannu Koivisto
| Well, as I showed, before, it doesn't here. Is your kernel configured to
| support upto 4GB RAM?
It works here with 2.2.14pre7, configured to support up to 1GB RAM
(choices are 1GB and 2GB for standard 2.2.x kernels; I don't know
what you mean by 4GB). I copied CMUCL 2.4.17 to another machine
that still has 2.2.10 kernel and CMUCL 2.4.15. 2.4.17 didn't work
there, but 2.4.15 that has smaller vm requirements did. When I
boot 2.2.14pre8/9 to that machine I'll see if the kernel or installed
RAM+swap differences are the cause (well, I guess the slightly
different libc6 versions /could/ affect too, but I don't think so).
I just can't do it right now because that machine is our company's
router :)
--
Hannu
William Deakin
downloaded and installed cmucl-2.17 last night and had no problems once "echo
1 > /proc/vm...." was executed.
Best Regards,
:) will
Martin Cracauer
>'(in-package :common-lisp-user)(load "finish")\n'"release x86-linux 2.4.17
>`date "+%e %B %Y"` build `cat build`"'\n' | \
> ./x86/lisp/lisp -core x86/lisp/kernel.core
>Error in allocating memory, please do "echo 1 > /proc/sys/vm/overcommit_memory"
>or get more memory+swap.
>mmap: Cannot allocate memory
>ensure_space: Failed to validate 1879048192 bytes at 0x48000000
>make: *** [make-new] Error 1
> Is there a parameter to change this?
Follow the instructions. Either add more paging space or switch to
overcommit paging policy (as was the default in earlier versions of
the Linux kernel). Or switch to FreeBSD, where changes like this
aren't announced by letting the changed behaviour be the default (not
so shameless plug. Why do we have one such issue after another with
Linux?).
>[BTW, http://www2.cons.org/maillists/ is not accessible]
It's not as easy to recover. Still working on it (and have been on
vacation).
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <crac...@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
"Where do you want to do today?" Hard to tell running your calendar
program on a junk operating system, eh?
Erik Naggum
| Either add more paging space or switch to overcommit paging policy (as
| was the default in earlier versions of the Linux kernel).
whatever do you guys need 1.7G of memory _for_? putting persistent myths
about Lisp's resource-intensive flaws to death does not seem to be a goal.
| Or switch to FreeBSD, where changes like this aren't announced by letting
| the changed behaviour be the default (not so shameless plug. Why do we
| have one such issue after another with Linux?).
perhaps it's because you're doing unreasonable things that make
reasonable stuff harder to do, and Linux is more optimized towards
letting people do reasonable things?
| >[BTW, http://www2.cons.org/maillists/ is not accessible]
|
| It's not as easy to recover. Still working on it (and have been on
| vacation).
well, my guess by now is that it's hard to run FreeBSD... <snicker>
#:Erik
Martin Cracauer
>* Martin Cracauer
>| Either add more paging space or switch to overcommit paging policy (as
>| was the default in earlier versions of the Linux kernel).
> whatever do you guys need 1.7G of memory _for_? putting persistent myths
> about Lisp's resource-intensive flaws to death does not seem to be a goal.
The current CMUCL runtime allocates all space it may ever use at
startup. The space may not be extended later (including the space that
Alien/C code allocates).
This is of course a serious flaw in a number of ways:
- People who don't want overcommit memory get into trouble (those who
have small Lisp programs that would fit otherwise).
- People like me who need even more space and have to recompile the
CMUCL runtime with a new memory layout.
- Alien/C code that gets into the way of the allocated spaces, which
usually needs to be hand-adjusted.
It's not as simple as sbrk(2)'ing memory on demand, since we have more
than one area which need to be continuous. We probably would mmap() on
demand and while we're at it dlsym(3)'ing all the symbols we need from
the platform below us (instead of parsing the outout of nm(1) as we do
now).
The problem here is that the current static scheme (both for space and
for symbols) was the only one that ran on all platforms that CMUCL was
initially targeted to (with exots as early Mach, the PC/RT
architecture) where mmap() and dlopen/dlsym were no portable
solutions. Since then, noone touched it except that the Linux version
already took some steps.
The people who work on CMUCL have all specific regions they're
interested in and are capable of, and most target on improving
correctness, speed of compiled code or like me on distributing the
thing. Even areas such as ANSI conformance aren't currently attacked
and those are even more important than to change the runtime's
internals which works for most people and can easily be fixed for the
others by loading new C libraries or flip a switch in their kernel.
>| Or switch to FreeBSD, where changes like this aren't announced by letting
>| the changed behaviour be the default (not so shameless plug. Why do we
>| have one such issue after another with Linux?).
> perhaps it's because you're doing unreasonable things that make
> reasonable stuff harder to do, and Linux is more optimized towards
> letting people do reasonable things?
I don't say Linux doesn't do this, but I would prefer that it didn't
break things as often as it does.
In the past we had the different distribution formats which caused
people to use outdated material (rpm vs. deb), libc vs glibc, which
was at least guarded by proper error messages, the FPU control word
issue, which wasn't, the RedHat kernel, which is heavily modified and
doesn't announce this, which is bad since it messes with memory
allocation and therefore clashes with the third problem I listed above
with our static memory allocation and now a default change to
non-overcommit.
Linux has long overtaken SunOS-5 as our most problematic platform, and
it did so out of its own, as compared to Solaris which was CMUCL's
fault. Since Linux had a much better starting position (both with
regards to availiable people and technically), that is an achievement.
I'm disappointed and I don't see a reason not to name the reasons.
>| >[BTW, http://www2.cons.org/maillists/ is not accessible]
>|
>| It's not as easy to recover. Still working on it (and have been on
>| vacation).
> well, my guess by now is that it's hard to run FreeBSD... <snicker>
On Quantum harddisks :-)
The simple problem here is that noone of us lives near to a location
where Internet access is cheap enough for the main distribution
machine to make complete backups. I'm rebuilding the machine so that
recovering without real backup is easier next time and that takes some
time for the mailing lists. For starters, since the mailing lists
moved over machines as the main one was broken, the archives are now
scattered over a number of places and plain text files isn't the
preferred way of reading mail archives on the WWW.
Fernando Mato Mira
Sorry. I was thinking about the 4GB support implemented by Siemens/SuSE.
I never looked at the other entry on that menu. I thought it selected 4,
not 2. [You actually need 2.3 for that patch, but I didn't know that
either]
Anyway, 2.2.13 w/2GB support didn't work. Neither did applying the pre9
patch (trick works, but dumps core). Worse, 2.4.8 and the `longfloat'
and `threads' release dump core, too.
2.4.5 does work out of the box on 2.2.14pre9. And incidentally, 2.4.5
compiles SERIES w/o problems (although the tests break at 290), while
2.4.8 breaks while compiling GATHERING
[That's why I got involved in this mess in the first place].
I'm now compiling 2.2.13/1GB. Peter said 2.4.17 did work for him, so
I'll check it out here.
BTW, I think the newbie/lightweight/occassional user CMUCL release
should map 256MB.
128MB RAM is pretty much a standard config for new PCs these days, and
1x128MB swap partition is a standard linux setup (none of the 6 machines
running Linux here has been set up with anything more than that).
--
Fernando D. Mato Mira
Jan Vroonhof
> Anyway, 2.2.13 w/2GB support didn't work.
And it is fairly obvious why too. The Linux 2GB support works by
simply making the window the kernel has to map memory 2GB. As a result
the address space available to user space is reduced, so it is not
surprising an 1.7GB window won't fit any more.
Jan
Fernando Mato Mira
Ah. Indeed, 2.4.17 _does_ work on vanilla 2.2.13/1GB.
On the other hand, it fails at GATHERING in the compilation of SERIES,
so apparently something broke on the road from 2.4.5 to 2.4.8 and stayed
that way.
Thanks to everybody,
-- fdmm
Peter Van Eynde
>Fernando D. Mato Mira <mato...@iname.com> wrote:
>
>> Thanks a lot for the info. Still:
>[cmucl 2.4.17 dies with memory allocation error]
>
>Same here. I tried to upgrade from Debian version 2.4.15, and
>the 'echo 1 >/proc/sys/vm/overcommit_memory' trick stopped working.
>
>Package changelog says:
>
> * moved to a new memorymap that gives us a bit more space: 1.75 GB.
>
>Could this be the cause?
Yes.
I've now found out that
- the new version doesn't work on 2.2.10, but does on 2.2.13
- it also doesn't work if you compile for 2GB of ram, but does if
you compile for 1GB of ram. (the division between kernel and user
memory-space changes because of this)
2.3.XX and the future 2.4 have some new mechanism for large-memory
machines, and I'll try to find out if this also creates problems.
_If_ I can replicate the problem on my machine... This might be a
pentium-II/III solution only...
>While I'm here, let me just add that it always warms my heart seeing
>Lisp-related announcements on freshmeat and new packages popping up
>in Debian unstable. You're doing a great job there, Peter.
Thanks!
Groetjes, Peter
--
It's logic Jim, but not as we know it. | pvan...@debian.org for pleasure,
"God, root, what is difference?" - Pitr| pvan...@inthan.be for more pleasure!
"God is more forgiving." - Dave Aronson| http://cvs2.cons.org/~pvaneynd