From: Dave (from the UK)
Subject: Very Bugy GNU Common Lisp
Date:
Message-ID: <448658f3@212.67.96.135>
I tried to build GNU Common Lisp 2.6.7 (I've call it GCL from now on),
using a Sun Ultra 80 workstation which runs Solaris 10. The aim was to
run Maxima
http://maxima.sourceforge.net/
which is a computer algebra system.
But GCL seems to have a really buggy configure/make system, which is one
of the worst I have ever come across.
1) I tried to build with Sun's C compiler cc(1) and set both CC and
CFLAGS to suitable values.
sparrow /tmp/gcl-2.6.7 % printenv CC
/opt/SUNWspro/bin/cc
sparrow /tmp/gcl-2.6.7 % printenv CFLAGS
-fast -fsimple=1
But whilst it takes note of my CC, the configure script decides to add
loads of its own gcc specific compiler flags, totally ignoring my CFLAGS.
So
-fast -fsimple=1 get converted to:
-fast -fsimple=1 -Wall -DVOL=volatile -fsigned-char -O3 -fomit-frame-pointer
which was not what I asked for. The Sun compiler will not accept -Wall
so aborts. I doubt it will accept most of the others too.
After giving up with cc(1) and using gcc(1), renaming my awk, getting
around various other bugs (not so damm stupid as the compiler flags
one), but many seem very basic, I got as far as trying to link GCL.
But then the compiler finds I don't have the BFD library. Correct me if
I am wrong, but that sort of thing should be picked up in the configure
script - it should attempt to link a program with that library and check
it links and gives sensible output.
If a library can't be found, the configure script should abort, perhaps
print a URL where it can be downloaded from - not create makefiles.
Within half an hour of trying to build GCL, I have uncovered at least 4
bugs. At that point I decided I'd not bother any more. I have reported
the bugs.
http://savannah.gnu.org/bugs/?func=detailitem&item_id=16700
http://savannah.gnu.org/bugs/?func=detailitem&item_id=16699
http://savannah.gnu.org/bugs/?func=detailitem&item_id=16697
http://savannah.gnu.org/bugs/?func=detailitem&item_id=16696
All are still open, with nobody assigned to them.
Any suggestions of a better alternative, that will build Maxima?
--
Dave K MCSE.
MCSE = Minefield Consultant and Solitaire Expert.
Please note my email address changes periodically to avoid spam.
It is always of the form: ··········@domain. Hitting reply will work
for a couple of months only. Later set it manually.
http://witm.sourceforge.net/ (Web based Mathematica frontend)
Dave (from the UK) wrote:
> I tried to build GNU Common Lisp 2.6.7 (I've call it GCL from now on),
> using a Sun Ultra 80 workstation which runs Solaris 10. The aim was to
> run Maxima
>
> http://maxima.sourceforge.net/
>
> which is a computer algebra system.
>
> But GCL seems to have a really buggy configure/make system, which is one
> of the worst I have ever come across.
>
> 1) I tried to build with Sun's C compiler cc(1) and set both CC and
> CFLAGS to suitable values.
>
> sparrow /tmp/gcl-2.6.7 % printenv CC
> /opt/SUNWspro/bin/cc
> sparrow /tmp/gcl-2.6.7 % printenv CFLAGS
> -fast -fsimple=1
>
> But whilst it takes note of my CC, the configure script decides to add
> loads of its own gcc specific compiler flags, totally ignoring my CFLAGS.
>
> So
>
> -fast -fsimple=1 get converted to:
>
> -fast -fsimple=1 -Wall -DVOL=volatile -fsigned-char -O3 -fomit-frame-pointer
>
> which was not what I asked for. The Sun compiler will not accept -Wall
> so aborts. I doubt it will accept most of the others too.
>
> After giving up with cc(1) and using gcc(1), renaming my awk, getting
> around various other bugs (not so damm stupid as the compiler flags
> one), but many seem very basic, I got as far as trying to link GCL.
>
> But then the compiler finds I don't have the BFD library. Correct me if
> I am wrong, but that sort of thing should be picked up in the configure
> script - it should attempt to link a program with that library and check
> it links and gives sensible output.
>
> If a library can't be found, the configure script should abort, perhaps
> print a URL where it can be downloaded from - not create makefiles.
>
> Within half an hour of trying to build GCL, I have uncovered at least 4
> bugs. At that point I decided I'd not bother any more. I have reported
> the bugs.
>
> http://savannah.gnu.org/bugs/?func=detailitem&item_id=16700
> http://savannah.gnu.org/bugs/?func=detailitem&item_id=16699
> http://savannah.gnu.org/bugs/?func=detailitem&item_id=16697
> http://savannah.gnu.org/bugs/?func=detailitem&item_id=16696
>
> All are still open, with nobody assigned to them.
>
> Any suggestions of a better alternative, that will build Maxima?
I have also had problems building GCL. Though I have managed to build
it on Linux from sources by adjustment of makefiles etc.
Although GCL was orignally made for any *nix system it doesn't appear
intended to work on any *nix anymore. The README and install
information is now very old. I think the author intends GCL to really
be for Debian. On Debian GCL is capable of supporting close to ANSI
Common Lisp.
You should not have a problem with BFD though, since this is included
in the GCL distribution and should be built at GCL build time.
And BTW, generally you don't want to use Solaris awk, AFAICR it's
ancient from the 80s.
Also specifying very high optimization flags for GCC when compiling
Lisp code automatically generated into C code will often reveal GCC
bugs.
Dave (from the UK) wrote:
> I tried to build GNU Common Lisp 2.6.7 (I've call it GCL from now on),
> using a Sun Ultra 80 workstation which runs Solaris 10. The aim was to
> run Maxima
>
> http://maxima.sourceforge.net/
>
> which is a computer algebra system.
>
> But GCL seems to have a really buggy configure/make system, which is one
> of the worst I have ever come across.
>
> 1) I tried to build with Sun's C compiler cc(1) and set both CC and
> CFLAGS to suitable values.
>
> sparrow /tmp/gcl-2.6.7 % printenv CC
> /opt/SUNWspro/bin/cc
> sparrow /tmp/gcl-2.6.7 % printenv CFLAGS
> -fast -fsimple=1
>
> But whilst it takes note of my CC, the configure script decides to add
> loads of its own gcc specific compiler flags, totally ignoring my CFLAGS.
>
> So
>
> -fast -fsimple=1 get converted to:
>
> -fast -fsimple=1 -Wall -DVOL=volatile -fsigned-char -O3 -fomit-frame-pointer
>
> which was not what I asked for. The Sun compiler will not accept -Wall
> so aborts. I doubt it will accept most of the others too.
>
> After giving up with cc(1) and using gcc(1), renaming my awk, getting
> around various other bugs (not so damm stupid as the compiler flags
> one), but many seem very basic, I got as far as trying to link GCL.
>
> But then the compiler finds I don't have the BFD library. Correct me if
> I am wrong, but that sort of thing should be picked up in the configure
> script - it should attempt to link a program with that library and check
> it links and gives sensible output.
>
> If a library can't be found, the configure script should abort, perhaps
> print a URL where it can be downloaded from - not create makefiles.
>
> Within half an hour of trying to build GCL, I have uncovered at least 4
> bugs. At that point I decided I'd not bother any more. I have reported
> the bugs.
>
> http://savannah.gnu.org/bugs/?func=detailitem&item_id=16700
> http://savannah.gnu.org/bugs/?func=detailitem&item_id=16699
> http://savannah.gnu.org/bugs/?func=detailitem&item_id=16697
> http://savannah.gnu.org/bugs/?func=detailitem&item_id=16696
>
> All are still open, with nobody assigned to them.
>
> Any suggestions of a better alternative, that will build Maxima?
>
> --
> Dave K MCSE.
>
> MCSE = Minefield Consultant and Solitaire Expert.
>
> Please note my email address changes periodically to avoid spam.
> It is always of the form: ··········@domain. Hitting reply will work
> for a couple of months only. Later set it manually.
>
> http://witm.sourceforge.net/ (Web based Mathematica frontend)
Axiom uses GCL as its common lisp system.
Axiom builds GCL as part of the system build.
GCL seems to build fine on linux systems.
The same can't be said for Macs but Unix is not linux.
I have not tried to build it on Solaris but I suspect it
suffers the fate of all C programs. C programs are not
portable due to include/library/architecture issues.
Half of my career seems to have involved porting
"portable" C programs.
Camm Maguire, the GCL lead, is very responsive to
requests for support and bug reports. However, he might
not have access to Solaris.
Tim Daly
Axiom Lead Developer
From: Giorgos Keramidas
Subject: Re: Very Bugy GNU Common Lisp
Date:
Message-ID: <86y7w9vvuj.fsf@gothmog.pc>
On 7 Jun 2006 06:51:08 -0700, ····@axiom-developer.org wrote:
> Dave (from the UK) wrote:
>> I tried to build GNU Common Lisp 2.6.7 (I've call it GCL from
>> now on), using a Sun Ultra 80 workstation which runs Solaris
>> 10. The aim was to run Maxima
>>
>> http://maxima.sourceforge.net/
>>
>> which is a computer algebra system.
>>
>> But GCL seems to have a really buggy configure/make system,
>> which is one of the worst I have ever come across.
[...]
> Axiom uses GCL as its common lisp system.
> Axiom builds GCL as part of the system build.
> GCL seems to build fine on linux systems.
> The same can't be said for Macs but Unix is not linux.
> I have not tried to build it on Solaris but I suspect it
> suffers the fate of all C programs. C programs are not
> portable due to include/library/architecture issues.
> Half of my career seems to have involved porting
> "portable" C programs.
>
> Camm Maguire, the GCL lead, is very responsive to
> requests for support and bug reports. However, he might
> not have access to Solaris.
This is very good to know. I have access to Solaris systems. If
Camm Maguire or Dave have patches for GCL that want to test, feel
free to let me know.
Currently, I don't have the time to try fixing the GCL problems
reported by Dave above on the Solaris systems I use daily, but I
can allocate the necessary time slices for testing patches.
- Giorgos
From: Dave (from the UK)
Subject: Re: Very Bugy GNU Common Lisp
Date:
Message-ID: <448712df@212.67.96.135>
····@axiom-developer.org wrote:
> Axiom uses GCL as its common lisp system.
> Axiom builds GCL as part of the system build.
> GCL seems to build fine on linux systems.
Yes, that does not surprise me.
> The same can't be said for Macs but Unix is not linux.
Well, I'd put it the other way around, as Linux came about well after UNIX!
> I have not tried to build it on Solaris but I suspect it
> suffers the fate of all C programs. C programs are not
> portable due to include/library/architecture issues.
I really don't feel it should be like that. I am the developer of
http://atlc.sourceforge.net/
and know it has been build on tru64, HP-UX, Solaris, various flavors of
Linux, IRIX, UNICOS (Cray), UNIXWARE, NetBSD, OpenBSD and FreeBSD. The
cray even has sizeof(short)==8, but with a bit of effort one can work
around that, so it builds on the Cray easily.
> Half of my career seems to have involved porting
> "portable" C programs.
The autoconf/automake system cuts a lot of the work out, but one does
need to write the configuration files properly.
> Camm Maguire, the GCL lead, is very responsive to
> requests for support and bug reports. However, he might
> not have access to Solaris.
I've asked Sun before if they would provide public access Suns for
testing, but I think their attitude is that Solaris is a free download
for both SPARC and x86, so anyone can install it. But if the developer
needs Solaris, I am quite willing to provide access to a Solaris box.
But some of the issues, like the compiler adding in -Wall, can be tested
on any system. Even if you have gcc, I don't believe -Wall should be
added if the user has set CFLAGS and chose not to add it. Likewise
adding -O3 is dangerous, since that breaks compilations some times.
> Tim Daly
> Axiom Lead Developer
>
Thanks for you comments. I assume you have the email for the developer
of GCL. If so, feel free to let him know of this post and if he wants I
can make a Solaris box available. The configure.in seems to have loads
of stuff that I doubt is necessary, since it seems to be copied from
another package and just modified where necessary. But without knowing
the how GCL is supposed to be built, it is not really practical for me
to hack it. The best I can do is hack the makefiles, which does not give
a long-term solution.
--
Dave K MCSE.
MCSE = Minefield Consultant and Solitaire Expert.
Please note my email address changes periodically to avoid spam.
It is always of the form: ··········@domain. Hitting reply will work
for a couple of months only. Later set it manually.
http://witm.sourceforge.net/ (Web based Mathematica front end)
> Thanks for you comments. I assume you have the email for the developer
> of GCL. If so, feel free to let him know of this post and if he wants I
> can make a Solaris box available. The configure.in seems to have loads
> of stuff that I doubt is necessary, since it seems to be copied from
> another package and just modified where necessary. But without knowing
> the how GCL is supposed to be built, it is not really practical for me
> to hack it. The best I can do is hack the makefiles, which does not give
> a long-term solution.
I know you're going to hate this comment but I have to make it anyway.
There are a lot of open source projects that have very few active
developers.
That implies that all of the work to make code run, to add changes, to
track
moving standards, to innovate, document, manage servers, mailing lists,
bug lists, feature requests, and all the other myriad tasks of project
management are done by one or two people.
The theory is that when someone in the world needs something fixed they
report the bug and include a documented patch to the system which they
have tested against the other dozen platforms to make sure they didn't
break any other system.
The fact is that people download the code, type configure, make, and
then
are surprised when a bug occurs on their non-linux-mainstream setup.
The usual response is a blog complaint, the next most frequent is a
complaint to the project mailing list lacking precise information
showing
the nature of the bug. On rare occasions the developer gets access to
the
failing system to investigate the bug (in a strange environment over an
ssh
link lacking all of his tools). I have never seen a fully documented
and tested
patch submitted to any of the many projects I'm associated with.
Consider what you are suggesting. You are suggesting that Camm should
download Solaris isos, dedicate the time and effort to set up a whole
system
with all of the required development tools (does solaris have a
yum-like tool?).
That assumes that solaris has the drivers for his hardware which it
doesn't.
Then he has to learn the where solaris hides things (/mnt,
/usr/local/bin, etc).
Then he has to do the "simple job" (there is no such thing as a simple
job)
of "fixing the makefiles" (likely a non-gnu make is the default on
solaris).
Alternatively he can work as a user over a razor-blade-thin connection
to
reach a system that lacks his development tool chain, familiar command
set, and requiring special knowledge. Then he needs to hack
system-level
tools which he has no permission to install or modify. I've seen Camm
do
this so I know he can but it would seem "over the top" to suggest that
you
try to do the same in order to satisfy my need for your code.
You want to install a relatively small piece of code and find it hard
to set up.
But you expect Camm to download a whole operating system and tool chain
(configured the way your system is set up which might be nonstandard)
just
to simplify your life.
If you paid for such a service it would require a highly skilled
consultant
charging well over $100 per hour and taking well over a week of work
due
to the steep learning curve. So this is at least a $4000 "request".
I know this is going to look like a usenet "flame" but it's not
intended as one.
I'm simply pointing out the facts and the expectations.
Wouldn't it be "the right thing to do" and "in the spirit of open
source" and
all that motherhood to fix the code so it runs and send a patch? Your
patch might not work on other systems so Camm still has work to do
testing it and integrating it. That seems to use your skill and his
skills
in the best possible mix.
Google search for "Maguire GCL" gives his email address as the first
hit.
Be sure to copy the mailing list which is gcl-devel at gnu.org
Tim (the curmudgeon) Daly
From: Dave (from the UK)
Subject: Re: Very Bugy GNU Common Lisp
Date:
Message-ID: <448c9954@212.67.96.135>
····@axiom-developer.org wrote:
> I know you're going to hate this comment but I have to make it anyway.
No problem.
> There are a lot of open source projects that have very few active
> developers.
Yep, I have a few myself.
http://atlc.sourceforge.net/
http://witm.sourceforge.net/
http://hp8970.sourceforge.net/
and several more. Some have contributed code to the first, but not a lot.
> The fact is that people download the code, type configure, make, and
> then
> are surprised when a bug occurs on their non-linux-mainstream setup.
No, we are not surprised. We have a term for it - GNUism, or Linuxism.
This is quite common, but unnecessary.
We Just feel developers could take a bit more care. There are plenty of
ways for someone to test their code on "non-Linux-mainstream" setups,
without them buying the hardware themselves.
1) There's the Sourceforge compile farm
http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1
where developers of projects on Sourceforge can test their code.
2) Then there's the HP testdrive
http://www.testdrive.hp.com/
where people can test their code on multiple UNIX platforms, as well as
OpenVMS.
3) There's also an open-access Cray,
http://www.cray-cyber.org/general/start.php
which I found useful, as while it (I used the X-MP) is desperately slow
for non-vector code, the fact sizeof(short)==8 caused me a problem on
'atlc' - but one that I managed to work around.
4) Ask around - someone will probably let you have some access to a
machine.
There really is not an excuse for some of the problems I see in GNU
Lisp, like configure scripts adding non-gcc options. I strongly suspect
that could be tested on any non Linux/GNU platform. HP, Intel, Cray or
other non-gcc compiler would no doubt balk at that too.
> The usual response is a blog complaint, the next most frequent is a
> complaint to the project mailing list lacking precise information
> showing
> the nature of the bug.
I have put the bug in the bug database. At this point, it has not been
assigned to anyone. I believe the information provided is useful.
> On rare occasions the developer gets access to
> the
> failing system to investigate the bug (in a strange environment over an
> ssh
> link lacking all of his tools).
Well, ssh access can be useful. And the fact it lacks his tools can be
an *advantage*, as he sees how others might build it. Should he/she find
that one of his tools is needed, they can changed the documentation to
reflect this.
> Consider what you are suggesting. You are suggesting that Camm should
> download Solaris isos, dedicate the time and effort to set up a whole
> system
> with all of the required development tools (does solaris have a
> yum-like tool?).
Or log onto the sourceforge compile farm.
> That assumes that solaris has the drivers for his hardware which it
> doesn't.
Same point.
> Then he has to learn the where solaris hides things (/mnt,
> /usr/local/bin, etc).
Which will help him make his code portable.
> Then he has to do the "simple job" (there is no such thing as a simple
> job)
> of "fixing the makefiles" (likely a non-gnu make is the default on
> solaris).
Yes, Sun's make is not very good, although GNU make will be installed
under the name 'gmake' on later releases.
So why not suggest someone install gnu make, or abort the configure
script if there is no gnu make present?
I think it is generally unreasonable to suggest the installation of gcc
(not that it solves the problem in this case), since gcc is not a very
fast compiler on some platforms.
Obviously, if Lisp gets recompiled with Lisp, perhaps the speed of the
original compiler does not matter to the overall speed of Lisp.
> Alternatively he can work as a user over a razor-blade-thin connection
> to
> reach a system that lacks his development tool chain, familiar command
> set, and requiring special knowledge. Then he needs to hack
> system-level
> tools which he has no permission to install or modify.
As I say, this information is useful to know. And I've worked on places
where I can't add system files. gcc and friends can always be installed
under $HOME.
> I've seen Camm
> do
> this so I know he can but it would seem "over the top" to suggest that
> you
> try to do the same in order to satisfy my need for your code.
I'm not asking, just offering. I'm quite happy to look at another LISP.
GNU Common Lisp is not the only Lisp. Given its installation program
seems seriously broken to me, I'll look elsewhere.
My *guess* is that too much of the configure script has been copied from
somewhere else, without actually understanding it. The following two
lines in configure.in possibly indicate that.
# some parts of this configure script are taken from the tcl configure.in
<snip out loads>
TCFLAGS="-Wall -DVOL=volatile -fsigned-char"
Whether tcl needs -DVOL=volatile -fsigned-char, whether GNU Lisp needs
it, is anyones guess - there are no comments to indicate why any of
these falgs are added.
But I'm not even sure if the configure script was built from that, as
there is a configure.ac-new (or similar) too.
> You want to install a relatively small piece of code and find it hard
> to set up.
> But you expect Camm to download a whole operating system and tool chain
> (configured the way your system is set up which might be nonstandard)
> just
> to simplify your life.
NO NO NO. I feel someone developing open-source UNIX software should
make some effort to test on a variety of systems.
There are exceptions of course. One of my programs, which is pretty
basic, relies on having a National Instruments GPIB board. I can't test
that on lots of cards, as I don't have them and getting access to
machines with them is not easy. But getting access to HP boxes is pretty
easy and they would have no doubt found the problems here.
And by the way, I have contributed to code other than my own - such as
to SAGE
http://modular.math.washington.edu/sage/ack.html
"David Kirkby: Compilation of SAGE on Solaris; much help on general SAGE
build process"
> If you paid for such a service it would require a highly skilled
> consultant
> charging well over $100 per hour and taking well over a week of work
> due
> to the steep learning curve. So this is at least a $4000 "request".
True. But I feel someone should make some effort before releasing
open-source software unless it is alpha/beta stuff. It is not that hard
to do.
In my experience also, getting software running on multiple platforms
also shows up other bugs in coding. I've seen things fail on AIX that
worked perfectly on Solaris, Linux and others. Careful checking revealed
a bug in the algorithm and the fact it never showed on Linux and Solaris
was just luck.
> I know this is going to look like a usenet "flame" but it's not
> intended as one.
No, I see your point. But see mine too - there are other Lisps, and this
one seems to have been written in a way that portability is not really
addressed.
> I'm simply pointing out the facts and the expectations.
>
> Wouldn't it be "the right thing to do" and "in the spirit of open
> source" and
> all that motherhood to fix the code so it runs and send a patch?
If I felt the originator had tried to make it portable, I'd certainly
have a go at finding the bugs. But there seems to be a lot of very basic
ones that I really don't have time/inclination to solve.
> Your
> patch might not work on other systems so Camm still has work to do
> testing it and integrating it. That seems to use your skill and his
> skills
> in the best possible mix.
To me, the best thing is likely to be clean up the configure script.
Removing what is not necessary. The originator is probably in the best
position to do that.
> Google search for "Maguire GCL" gives his email address as the first
> hit.
> Be sure to copy the mailing list which is gcl-devel at gnu.org
I'll drop him an email.
> Tim (the curmudgeon) Daly
>
--
Dave K MCSE.
MCSE = Minefield Consultant and Solitaire Expert.
Please note my email address changes periodically to avoid spam.
It is always of the form: ··········@domain. Hitting reply will work
for a couple of months only. Later set it manually.
http://witm.sourceforge.net/ (Web based Mathematica frontend)
Dear Dave,
as far as I know, maxima also builds with CLISP and CMUCL. In any case, I
believe you should ask this sort of questions on ······@math.utexas.edu.
Martin
>>>>> "Dave" == Dave <(from the UK)" <················@southminster-branch-line.org.uk>> writes:
Dave> I tried to build GNU Common Lisp 2.6.7 (I've call it GCL from now
Dave> on), using a Sun Ultra 80 workstation which runs Solaris 10. The aim
Dave> was to run Maxima
I have succeeded in compiling gcl 2.6.7 on solaris, but it required
some hacking of the configure script and the generated makefile. It
was not easy.
But if you want to run maxima, you can also use clisp, cmucl, or sbcl
on Solaris. Clisp usually compiles on solaris without too much
problem. For cmucl and sbcl, I'd just grab the available binaries.
I'd grab the clisp binary too if it exists.
Ray
From: Dave (from the UK)
Subject: Re: Very Bugy GNU Common Lisp
Date:
Message-ID: <44873d2b@212.67.96.135>
Raymond Toy wrote:
> I have succeeded in compiling gcl 2.6.7 on solaris, but it required
> some hacking of the configure script and the generated makefile. It
> was not easy.
Thanks. I must admit I'd lost interest after finding so many obviously
basic bugs quite quickly.
> But if you want to run maxima, you can also use clisp, cmucl, or sbcl
> on Solaris. Clisp usually compiles on solaris without too much
> problem. For cmucl and sbcl, I'd just grab the available binaries.
> I'd grab the clisp binary too if it exists.
Cheers. I'm just downloading the clisp sources - I generally prefer to
compile myself.
> Ray
--
Dave K MCSE.
MCSE = Minefield Consultant and Solitaire Expert.
Please note my email address changes periodically to avoid spam.
It is always of the form: ··········@domain. Hitting reply will work
for a couple of months only. Later set it manually.
http://witm.sourceforge.net/ (Web based Mathematica front end)
Dave (from the UK) wrote:
> Raymond Toy wrote:
>
> > I have succeeded in compiling gcl 2.6.7 on solaris, but it required
> > some hacking of the configure script and the generated makefile. It
> > was not easy.
>
> Thanks. I must admit I'd lost interest after finding so many obviously
> basic bugs quite quickly.
>
> > But if you want to run maxima, you can also use clisp, cmucl, or sbcl
> > on Solaris. Clisp usually compiles on solaris without too much
> > problem. For cmucl and sbcl, I'd just grab the available binaries.
> > I'd grab the clisp binary too if it exists.
>
> Cheers. I'm just downloading the clisp sources - I generally prefer to
> compile myself.
I can see why you would, but I avoid doing this for lisps. Clisp and
GCL use enough C that they can be bootstrapped with a C compiler. The
other free lisps though such as, CMUCL and SBCL are written mainly in
lisp. SBCL needs a common lisp compiler to build it and CMUCL needs a
binary CMUCL to build it.
Since lisps tend to be binary blobs there is little real improvement in
the reliability with which they interface to other libraries or
accuracy of build configuration. As there sometimes is when building C
programs from scratch.
"Rob Thorpe" <·············@antenova.com> writes:
> Dave (from the UK) wrote:
>> Raymond Toy wrote:
>>
>> > I have succeeded in compiling gcl 2.6.7 on solaris, but it required
>> > some hacking of the configure script and the generated makefile. It
>> > was not easy.
>>
>> Thanks. I must admit I'd lost interest after finding so many obviously
>> basic bugs quite quickly.
>>
>> > But if you want to run maxima, you can also use clisp, cmucl, or sbcl
>> > on Solaris. Clisp usually compiles on solaris without too much
>> > problem. For cmucl and sbcl, I'd just grab the available binaries.
>> > I'd grab the clisp binary too if it exists.
>>
>> Cheers. I'm just downloading the clisp sources - I generally prefer to
>> compile myself.
>
> I can see why you would, but I avoid doing this for lisps. Clisp and
> GCL use enough C that they can be bootstrapped with a C compiler. The
> other free lisps though such as, CMUCL and SBCL are written mainly in
> lisp. SBCL needs a common lisp compiler to build it and CMUCL needs a
> binary CMUCL to build it.
Well, YMMV, but on my systems, there are more lisp compilers installed
than C compilers...
> Since lisps tend to be binary blobs there is little real improvement in
> the reliability with which they interface to other libraries or
> accuracy of build configuration. As there sometimes is when building C
> programs from scratch.
Some implementations still aer quote modular and configurable.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Our users will know fear and cower before our software! Ship it!
Ship it and let them flee like the dogs they are!"
Pascal Bourguignon wrote:
> "Rob Thorpe" <·············@antenova.com> writes:
>
> > Dave (from the UK) wrote:
> >> Raymond Toy wrote:
> >>
> >> > I have succeeded in compiling gcl 2.6.7 on solaris, but it required
> >> > some hacking of the configure script and the generated makefile. It
> >> > was not easy.
> >>
> >> Thanks. I must admit I'd lost interest after finding so many obviously
> >> basic bugs quite quickly.
> >>
> >> > But if you want to run maxima, you can also use clisp, cmucl, or sbcl
> >> > on Solaris. Clisp usually compiles on solaris without too much
> >> > problem. For cmucl and sbcl, I'd just grab the available binaries.
> >> > I'd grab the clisp binary too if it exists.
> >>
> >> Cheers. I'm just downloading the clisp sources - I generally prefer to
> >> compile myself.
> >
> > I can see why you would, but I avoid doing this for lisps. Clisp and
> > GCL use enough C that they can be bootstrapped with a C compiler. The
> > other free lisps though such as, CMUCL and SBCL are written mainly in
> > lisp. SBCL needs a common lisp compiler to build it and CMUCL needs a
> > binary CMUCL to build it.
>
> Well, YMMV, but on my systems, there are more lisp compilers installed
> than C compilers...
Yes, there are on mine too. This doesn't often help in building them
though. I think SBCL is the only CL that is written in CL. The others
are written in the language they implement themselves which is slightly
different.
> > Since lisps tend to be binary blobs there is little real improvement in
> > the reliability with which they interface to other libraries or
> > accuracy of build configuration. As there sometimes is when building C
> > programs from scratch.
>
> Some implementations still aer quote modular and configurable.
Yes, at build time. But generally once built all that remains are
~20MB image files containing everything.
C programs tend to link to many shared libraries. This often gives
building from source an advantage over binaries, because the configure
script is often more able to withstand libraries of slightly different
versions than an executable is. CL implementations don't normally have
this problem.
"Dave (from the UK)" writes:
> Thanks. I must admit I'd lost interest after finding so many obviously
> basic bugs quite quickly.
To me this is an often observed of a user trying out software. Many
times I face the same situation, I managed to crash programs within
minutes. My attempt at an explanation is that newbies use software in
a way that frequent users (and maintainers) have long been trained not
to do. So newbies hit crashes much more often than the regular users,
using paths across the program that don't come to the mind of the
others.
Better explanations are welcome!
>I have reported the bugs.
Excellent.
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
Joerg Hoehle <······@users.sourceforge.net> wrote:
+---------------
| To me this is an often observed of a user trying out software. Many
| times I face the same situation, I managed to crash programs within
| minutes. My attempt at an explanation is that newbies use software in
| a way that frequent users (and maintainers) have long been trained not
| to do. So newbies hit crashes much more often than the regular users,
| using paths across the program that don't come to the mind of the others.
+---------------
It's not just newbies! Some of us old-timers [o.k., so I'm
still "only a nymph" w.r.t. CL] just seem to have that knack:
A friend: "Hey, look at this neat thing I just wrote!"
Me: "O.k. (*clicky*) (*clicky*) (*CRASH!!*) Uh... Is it
*supposed* to do that?"
Former friend: ··@^%$!#^!%$#"
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Dave (from the UK)
Subject: Re: Very Bugy GNU Common Lisp
Date:
Message-ID: <448e0270@212.67.96.135>
Joerg Hoehle wrote:
> "Dave (from the UK)" writes:
>
>>Thanks. I must admit I'd lost interest after finding so many obviously
>>basic bugs quite quickly.
>
>
> To me this is an often observed of a user trying out software.
It depends on how much you want the software, and what else is available
to do the job. If you want a text editor and try one and find problems,
you are likely to try another.
If the program is unique, and you really need it, you will probably
stick at it a bit more.
> Many
> times I face the same situation, I managed to crash programs within
> minutes. My attempt at an explanation is that newbies use software in
> a way that frequent users (and maintainers) have long been trained not
> to do.
Personally I don't think that is the much of the problem. Perhaps you
can explain what newbies do that causes these crashes.
To me, it is usually bad coding. Few seem to RTFW for autoconf/automake.
Those tools can yield pretty good results if used properly, but are a
nightmare if not used properly.
> So newbies hit crashes much more often than the regular users,
> using paths across the program that don't come to the mind of the
> others.
>
> Better explanations are welcome!
I don't think it is necessary a newbie issue - but of course experience
is helpful, as it always is.
I think the problem with a lot of open-source developers is that they
only test on 32-bit little endian Linux platforms with gcc and other GNU
tools. Trying things like a big-endian system, 64-bit compiles, not
using gcc will often throw up lots of problems.
It is totally pointless to use things like automake/autoconf, then
hardcode in compiler options which get applied whatever compiler is used.
You will often see something like
#ifdef __linux__
what people should be doing is not trying to make compilation work on
Linux or any other platform, but use sensible tests so things work on
all platforms.
--
Dave K MCSE.
MCSE = Minefield Consultant and Solitaire Expert.
Please note my email address changes periodically to avoid spam.
It is always of the form: ··········@domain. Hitting reply will work
for a couple of months only. Later set it manually.
http://witm.sourceforge.net/ (Web based Mathematica frontend)
From: Dave (from the UK)
Subject: Re: Very Bugy GNU Common Lisp
Date:
Message-ID: <4487dfbc@212.67.96.135>
Raymond Toy wrote:
>
> I have succeeded in compiling gcl 2.6.7 on solaris, but it required
> some hacking of the configure script and the generated makefile. It
> was not easy.
>
> But if you want to run maxima, you can also use clisp, cmucl, or sbcl
> on Solaris. Clisp usually compiles on solaris without too much
> problem. For cmucl and sbcl, I'd just grab the available binaries.
> I'd grab the clisp binary too if it exists.
>
> Ray
Did you build and test the libsigsegv library before installing clisp?
The docs say it is highly desirable, but whilst it builds OK (no
compiler warnings), it fails 2 of 4 tests if built with gcc and 3 of 4
tests if built with Sun's cc.
I understand Maxima has not been ported to Solaris, but I'll have a go
if it is possible.
--
Dave K MCSE.
MCSE = Minefield Consultant and Solitaire Expert.
Please note my email address changes periodically to avoid spam.
It is always of the form: ··········@domain. Hitting reply will work
for a couple of months only. Later set it manually.
http://witm.sourceforge.net/ (Web based Mathematica fronted)
>>>>> "Dave" == Dave <(from the UK)" <················@southminster-branch-line.org.uk>> writes:
Dave> Raymond Toy wrote:
>> I have succeeded in compiling gcl 2.6.7 on solaris, but it required
>> some hacking of the configure script and the generated makefile. It
>> was not easy.
>> But if you want to run maxima, you can also use clisp, cmucl, or sbcl
>> on Solaris. Clisp usually compiles on solaris without too much
>> problem. For cmucl and sbcl, I'd just grab the available binaries.
>> I'd grab the clisp binary too if it exists.
>> Ray
Dave> Did you build and test the libsigsegv library before installing clisp?
Probably. I haven't built clisp in quite a while. I don't need to be
on the bleeding edge. :-)
Dave> I understand Maxima has not been ported to Solaris, but I'll have a go
Dave> if it is possible.
I run Maxima on Solaris all the time. There's nothing to port. :-)
Ray
You get what you pay for...
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
jacob navia <·····@jacob.remcomp.fr> writes:
> You get what you pay for...
Did you ever read the warranties given by Mathematica/Maple/MuPAD/... ?
Martin
L I M I T E D WARRANTY
WRI warrants that the Product shall be free from defects in the physical media
for a period of ninety days following date of purchase when used under normal
conditions. THE FOREGOING WARRANTY IS IN LIEU OF ALL OTHER WARRANTIES, EXPRESS
OR IMPLIED. WRI DOES NOT WARRANT THAT THE SOFTWARE IS FREE FROM ALL BUGS AND
OMISSIONS; THE PRODUCT IS SOLD AS IS. WRI MAKES NO REPRESENTATIONS, EXPRESS OR
IMPLIED, WITH RESPECT TO THE PRODUCT OR THE SOFTWARE CONTAINED IN THE PRODUCT,
INCLUDING WITHOUT LIMITATIONS, ANY IMPLIED WARRANTIES OF MERCHANTABILITY,
INTEROPERABILITY, OR FITNESS FOR A PARTICULAR PURPOSE, ALL OF WHICH IS
EXPRESSLY DISCLAIMED. WRI DOES NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE
PROGRAM WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE PROGRAM WILL
BE UNINTERRUPTED OR ERROR FREE. IN ADDITION TO THE FOREGOING, YOU SHOULD
RECOGNIZE THAT ALL COMPLEX SOFTWARE SYSTEMS AND THEIR DOCUMENTATION CONTAIN
ERRORS AND OMISSIONS. WRI, ITS DISTRIBUTORS AND DEALERS SHALL NOT BE
RESPONSIBLE UNDER ANY CIRCUMSTANCES FOR PROVIDING INFORMATION ON OR CORRECTIONS
TO ERRORS AND OMISSIONS DISCOVERED AT ANY TIME IN THE PRODUCT, WHETHER OR NOT
THEY ARE AWARE OF THE ERRORS OR OMISSIONS. WRI DOES NOT RECOMMEND THE USE OF
THE SOFTWARE FOR APPLICATIONS IN WHICH ERRORS OR OMISSIONS COULD THREATEN LIFE,
INJURY OR SIGNIFICANT LOSS. SOME STATES DO NOT ALLOW THE EXCLUSION OF IMPLIED
WARRANTIES, SO THIS MAY NOT APPLY TO YOU. THIS WARRANTY GIVES YOU SPECIFIC
LEGAL RIGHTS, AND YOU MAY ALSO HAVE OTHER RIGHTS WHICH VARY FROM STATE TO
STATE. This License Agreement shall be construed under the laws of the State of
Illinois.
>
>
> NO WARRANTY
>
> 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
> FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
> OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
> PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
> OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
> TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
> PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
> REPAIR OR CORRECTION.