FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups 
 ProfileProfile   PreferencesPreferences   Log in to check your private messagesLog in to check your private messages   Log inLog in 
Forum index » Science and Technology » Math » Symbolic
Very Bugy GNU Common Lisp
Post new topic   Reply to topic Page 1 of 2 [22 Posts] View previous topic :: View next topic
Goto page:  1, 2 Next
Author Message
Craig Carey
science forum beginner


Joined: 18 Jun 2005
Posts: 41

PostPosted: Wed Jun 14, 2006 2:26 am    Post subject: Re: Very Bugy GNU Common Lisp Reply with quote

TYhe option to debug the scripts outside of Debian and in Solaris,
might not happen at the core.

Rather than me write worthlessly and uninteresting, for persons
taking Solaris seriously, some text by the former eliminated chief,
Scott McNealy is quoted



| Received: from mh.sunmicrosystemsinc.m0.net (mh.sunmicrosystemsinc.m0.net [209.11.164.54])
| by stewie.iconz.co.nz (Postfix) with ESMTP id EE8BB2B0686
| for <***@ijs.co.nz>; Wed, 31 May 2006 16:04:10 +1200 (NZST)
| Received: from mail.communications.sun.com (209.11.138.147)
| by mh.sunmicrosystemsinc.m0.net with ESMTP; 30 May 2006 21:04:09 -0700
| Message-ID: <2308350.1149048249181.JavaMail.root@fac1107>
| Date: Tue, 30 May 2006 21:04:09 -0700 (PDT)
| From: Sun Microsystems <sun.program@mail.communications.sun.com>
| Reply-To: sun.program@mail.communications.sun.com
| To: research@ijs.co.nz
| Subject: Message from Scott McNealy
| Errors-To: sun.program@mail.communications.sun.com
| Mime-Version: 1.0
| Content-Type: text/plain; charset="UTF-8" [...]
|
| [...] prominently on our Web site: http://www.sun.com/privacy [...]
|
|
| Dear - -,
|
| By now, you have likely heard that I am passing responsibilities as CEO
| to Jonathan Schwartz who, on April 24, became President and CEO of Sun
| Microsystems, Inc. If you already know Jonathan I am sure you agree that
| he is the right person to take the helm of the company.
|
| While I may be handing over the reigns, my job isn't done and neither am
| I. As Sun's Chairman of the Board I will continue to support Jonathan
| and Sun's people across the world, spending as much time as I can with
| our customers. In addition, I will remain a key voice and supporter of
| our 'open source' initiatives and continue to promote my long-standing
| mission of enabling global participation through the Network.
|
| Jonathan is someone I identified early on as a potential successor, and
| one with whom I have worked closely in preparation for this role during
| the past two years. With Sun for more than a decade, Jonathan has been
| instrumental in streamlining operations, creating a world-class product
| line and advancing our overall competitive positioning. He has been
| instrumental in securing a number of our key acquisitions, and has
| cultivated a crystal clear vision for the future of Sun.
|
| The road ahead is exciting for Sun's customers. We offer the best
| product line up in our 24-year history, have the right leadership in
| place, and are committed to investment in R&D to ensure that you will
| always benefit from choice and value that innovation brings. The open
| sourcing and subsequent massive adoption of Solaris 10 is testament to
| the wisdom of Sun's approach.
|
| In the meantime, I trust you will continue to look to Sun to bring you
| value through our commitment to choice and innovation. Our recent
| Network Computing Event (
| http://sun.r.delivery.net/r?1.1.3J1.2U2.11NZXE.Byoz70...CvuY.1UCS.3RLHBl
| ) in Washington, D.C. on May 2, followed by our JavaOne Conference (
| http://sun.r.delivery.net/r?1.1.3J1.2U2.11NZXE.Byoz70...Cvua.1UCS.3SlHBt
| ) May 16 - 19 in San Francisco, were opportunities for us to share with
| you the exciting progress that results through the union of technology
| and open communities.
|
| On behalf of Jonathan, the Board and the entire management team at Sun,
| we appreciate your support and will continue to work hard to earn it.
| Contact me at cbs_anz@sun.com if you have any questions.
|
| Thank you for your continued support of Sun.
|
|
| Best regards,
|
| Scott McNealy
| Chairman, Sun Microsystems, Inc.
|
| ===========================================
|
| (c) 2006 Sun Microsystems, Inc. All rights reserved. For information
| on Sun's trademarks see: [] http://www.sun.com/suntrademarks
|
| To unsubscribe from this list, reply to this message with "Unsubscribe"
| in the subject line or use this link:
| http://sun.r.delivery.net/r?1.1.3J1.2U2.11NZXE.Byoz70...Cvug.1UCS.3TonBz
|
| To manage your Sun subscriptions, visit the Subscription Center:
| http://sun.r.delivery.net/r?1.1.3J1.2U2.11NZXE.Byoz70...Cvuc.1UCS.3T5nBv
|
|
| Sun Microsystems Australia, Private Bag 10, GORDON NSW 2072 AUSTRALIA.


I would expect Scott McNeally to try again, and do another departing
statement. That one above is undated which a deliberate mistake
impersonally authorizing the hinted at by the topic of having a manager
seem to competently represent the nameless committe expelling. But
there is a cure: the "Event". There is competition at this thread since
I almost wrote of the non-Hubbellian physical Big Bang that created
3d geomery.



On Sun, 11 Jun 2006 23:29:38 +0100, "Dave (from the UK)" wrote:
....
Quote:
1) There's the Sourceforge compile farm
http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1
....
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.

Direction setting aims permitting better inevitable progress when
setbacks are being harassing.

Here I provide two comments from Mr Camm Maguire that conflict and so
I expect Mr Daly to write to Mr Maguire.


| From: Camm Maguire - view profile
| Date: Fri, May 6 2005 7:25 am
| Email: Camm Maguire <c...@enhanced.com>
| Groups: comp.lang.lisp
|
| Greetings, and thanks for your interest!
|
| In summary, GCL already has an interface to gmp, the highly optimized
| external library for multiple-precision integer computations. It is a
| simple task, and on our todo list, to extend this to bring forward the
| floating point calls as well, which has now been branched into a
| separate library, mfpr. If you have a specific need with real code,
| we will bump the priority on this. It is not difficult. Open source
| projects take higher priority in GCL development, so if your code is
| open source, you'll get more attention from us!
|
| The other poster is correct, though, the main performance issue with
| multi-precision stuff is due to garbage collection. GCL has a multi
| layer model, with different types of objects segregated of different
| page types, and in some cases gc'd differently. By default, GCL uses
| a fast copying collector on bignums which are stored on relocatable
| pages. This is quite robust now having been thoroughly tested in a
| number of computer algebra systems such as axiom making heavy use of
| this functionality. The user can switch to a slower immovable type of
| allocation at runtime, but this is really an obsolete option at this
| point.
|
| GCL has also recently implemented a memory balancing algorithm that
| has significantly reduced gc times in a number of large applications.
| acl2 comes to mind, where now gcl is the fastest lisp as measured in
| their regression suite times among their handful of supported
| options.
|


| From: Camm Maguire - view profile
| Date: Sat, Aug 7 2004 11:00 am
| Email: Camm Maguire <c...@enhanced.com>
| Groups: comp.lang.lisp
|
| Greetings! My apologies -- I did not realize this might be a
| controversial statement. In fact, I suppose the 'official' adjective
| wrt the GNU project might be somewhat ill-defined. I based my
| statement primarily on two items:
|
| 1) The name (GNU Common Lisp)
|
| 2) The fact that when Dr. Schelter died, RMS took ownership of the
| process of finding another maintainer. In my discussions with him
| at the time, I suggested simply letting GCL go and using CLISP as
| the common lisp for GNU, but he did not want to do that. In spite
| of my not knowing anything about lisp at the time and my
| professions of incompetence, he 'officially' appointed me as the
| new maintainer as I was basically the only one willing to try to
| preserve Dr. Schelter's work. I made an inference from his
| personal involvement, but I can see that it is not completely
| justified.
|
| 3) As we both know, GPL licensing and being part of the GNU project
| are two different things. I had no idea until this moment that
| CLISP was also part of the GNU project. In keeping with what you
| state, both CLISP and GCL are on the 'official' GNU cd. My
| question is if this is the case, why are we not merging the
| projects Smile? Duplication of effort is so wasteful.
|

What action is Maxima (Fateman et al) intending to take ?


[bang] Carey
Back to top
Joerg Hoehle
science forum beginner


Joined: 12 Jun 2006
Posts: 1

PostPosted: Mon Jun 12, 2006 9:08 am    Post subject: Re: Very Bugy GNU Common Lisp Reply with quote

"Dave (from the UK)" writes:
Quote:
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!

Quote:
I have reported the bugs.
Excellent.


Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
Back to top
Dave (from the UK)
science forum addict


Joined: 12 Jan 2006
Posts: 76

PostPosted: Sun Jun 11, 2006 10:29 pm    Post subject: Re: Very Bugy GNU Common Lisp Reply with quote

daly@axiom-developer.org wrote:

Quote:
I know you're going to hate this comment but I have to make it anyway.

No problem.

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

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

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

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

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

Quote:
That assumes that solaris has the drivers for his hardware which it
doesn't.

Same point.

Quote:
Then he has to learn the where solaris hides things (/mnt,
/usr/local/bin, etc).

Which will help him make his code portable.

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

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

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

Quote:
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"


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

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

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

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

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

Quote:
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: month-year@domain. Hitting reply will work
for a couple of months only. Later set it manually.

http://witm.sourceforge.net/ (Web based Mathematica frontend)
Back to top
Craig Carey
science forum beginner


Joined: 18 Jun 2005
Posts: 41

PostPosted: Sun Jun 11, 2006 3:13 am    Post subject: Re: Very Bugy GNU Common Lisp Reply with quote

I fix a sentence up.

On Sun, 11 Jun 2006 14:44:36 +1200, Craig Carey wrote:
Quote:
On 8 Jun 2006 07:09:31 -0700, daly@axiom-developer.org wrote:
...
and their "configure" scripts running. It could be in part due to the
startling, evolving (unconsciously ... into buggy build scripts) and
the lack of diagnostics.

By startling and evolving, the way the failure to explain:

* wrong early decisions

* obscurations; eg. after that public ought contribute public becomes
too unacceptable since the public would spot it as false, then can
be compliance with standards; reminders of the buildup of
non-modifiability.

Hereditary is a new test: maybe the 'first few seconds' supply the
constraints.


>Craig Carey
Back to top
Craig Carey
science forum beginner


Joined: 18 Jun 2005
Posts: 41

PostPosted: Sun Jun 11, 2006 2:44 am    Post subject: Re: Very Bugy GNU Common Lisp Reply with quote

On 8 Jun 2006 07:09:31 -0700, daly@axiom-developer.org wrote:
....
Quote:
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.
....


Rather than debugged patches, end-user proficiency in estimating the
*early* stage aims/intents of the developers, can be a materializing
objective product replacing that debugged patch.

For example, a usual problem is that users can't get their "Makefile"s
and their "configure" scripts running. It could be in part due to the
startling, evolving (unconsciously ... into buggy build scripts) and
the lack of diagnostics.

Let's start with the early decision to not have any helpful diagnostics
that make debugging be swift.

Quote:
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".

An FSF GPL-compatible idea seems to have been offered by Mr Daly:
identify what is inside and is not: in this case, of Solaris or not of.

Neat.

Craig Carey
Back to top
Raymond Toy
science forum beginner


Joined: 27 May 2005
Posts: 19

PostPosted: Thu Jun 08, 2006 4:22 pm    Post subject: Re: Very Bugy GNU Common Lisp Reply with quote

Quote:
"Dave" == Dave <(from the UK)" <see-my-signature@southminster-branch-line.org.uk>> writes:

Dave> Raymond Toy wrote:

Quote:
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
Back to top
daly@axiom-developer.org1
science forum beginner


Joined: 10 Nov 2005
Posts: 12

PostPosted: Thu Jun 08, 2006 2:09 pm    Post subject: Re: Very Bugy GNU Common Lisp Reply with quote

Quote:
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
Back to top
Rob Thorpe
science forum beginner


Joined: 07 Jun 2006
Posts: 3

PostPosted: Thu Jun 08, 2006 12:43 pm    Post subject: Re: Very Bugy GNU Common Lisp Reply with quote

Pascal Bourguignon wrote:
Quote:
"Rob Thorpe" <robert.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.

Quote:
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.
Back to top
Pascal Bourguignon
science forum beginner


Joined: 07 Feb 2006
Posts: 4

PostPosted: Thu Jun 08, 2006 10:15 am    Post subject: Re: Very Bugy GNU Common Lisp Reply with quote

"Rob Thorpe" <robert.thorpe@antenova.com> writes:

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


Quote:
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!"
Back to top
Rob Thorpe
science forum beginner


Joined: 07 Jun 2006
Posts: 3

PostPosted: Thu Jun 08, 2006 9:00 am    Post subject: Re: Very Bugy GNU Common Lisp Reply with quote

Dave (from the UK) wrote:
Quote:
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.
Back to top
Dave (from the UK)
science forum addict


Joined: 12 Jan 2006
Posts: 76

PostPosted: Thu Jun 08, 2006 8:28 am    Post subject: Re: Very Bugy GNU Common Lisp Reply with quote

Raymond Toy wrote:

Quote:

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: month-year@domain. Hitting reply will work
for a couple of months only. Later set it manually.

http://witm.sourceforge.net/ (Web based Mathematica fronted)
Back to top
Dave (from the UK)
science forum addict


Joined: 12 Jan 2006
Posts: 76

PostPosted: Wed Jun 07, 2006 8:55 pm    Post subject: Re: Very Bugy GNU Common Lisp Reply with quote

Raymond Toy wrote:

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

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


Quote:
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: month-year@domain. Hitting reply will work
for a couple of months only. Later set it manually.

http://witm.sourceforge.net/ (Web based Mathematica front end)
Back to top
jacob navia
science forum beginner


Joined: 06 Jul 2005
Posts: 30

PostPosted: Wed Jun 07, 2006 6:16 pm    Post subject: Re: Very Bugy GNU Common Lisp Reply with quote

Martin Rubey a écrit :
Quote:
jacob navia <jacob@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.




Well, with those guys you don't even get what you pay for!!!

:-)

I did not know that their license agreements were that limited.
Back to top
Dave (from the UK)
science forum addict


Joined: 12 Jan 2006
Posts: 76

PostPosted: Wed Jun 07, 2006 5:54 pm    Post subject: Re: Very Bugy GNU Common Lisp Reply with quote

daly@axiom-developer.org wrote:

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

Quote:
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!

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

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

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

Quote:
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: month-year@domain. Hitting reply will work
for a couple of months only. Later set it manually.

http://witm.sourceforge.net/ (Web based Mathematica front end)
Back to top
Raymond Toy
science forum beginner


Joined: 27 May 2005
Posts: 19

PostPosted: Wed Jun 07, 2006 2:42 pm    Post subject: Re: Very Bugy GNU Common Lisp Reply with quote

Quote:
"Dave" == Dave <(from the UK)" <see-my-signature@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
Back to top
Google

Back to top
Display posts from previous:   
Post new topic   Reply to topic Page 1 of 2 [22 Posts] Goto page:  1, 2 Next
View previous topic :: View next topic
The time now is Thu Jun 22, 2017 2:19 pm | All times are GMT
Forum index » Science and Technology » Math » Symbolic
Jump to:  

Similar Topics
Topic Author Forum Replies Last Post
No new posts IUPAC Naming for Common Names? xoflram@gmail.com Chem 9 Fri Jul 07, 2006 5:52 pm
No new posts Common tangents -marko- Math 4 Fri Jun 30, 2006 5:10 pm
No new posts Spectra of common light sources (updated) Ioannis Chem 6 Thu Jun 15, 2006 10:05 pm
No new posts recompiling Maxima with ABCL (Lisp implemented in Java) robert.dodier@gmail.com Symbolic 3 Wed Jun 14, 2006 6:02 am
No new posts Common sense, checking of math "proofs" jstevh@msn.com Math 12 Sat Jun 03, 2006 3:47 pm

Copyright © 2004-2005 DeniX Solutions SRL
Other DeniX Solutions sites: Electronics forum |  Medicine forum |  Unix/Linux blog |  Unix/Linux documentation |  Unix/Linux forums  |  send newsletters
 


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.2428s ][ Queries: 16 (0.1923s) ][ GZIP on - Debug on ]