From: Gregory W Bennett
Subject: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <fimor5$dr6$1@rumours.uwaterloo.ca>
A group of us has a project which originated on Lisp Machines but has since
been ported to MacLisp and Allegro. We deal with data analysis in a broad
sense, so there is a lot of statistical stuff and the emphasis is on
graphical displays to match numerical work. The project is heavily object-
oriented so a fast CLOS is all but essential as is a fast graphics package.
We would like to move this to the Linux world and a non-commercial implementation
so we have followed the recent discussion of CLISP and/vs other free
implementations with interest. We would be interested to hear views on graphics
packages for static and dynamic graphics - scatter plots, rotating plots,
projections, text wrapping, font selection etc.. We have access to a Linux box
running Ubuntu7.10 if that information is significant to the discussion.
Thanks for any and all info.
From: Maciej Katafiasz
Subject: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <fimtve$flr$1@news.net.uni-c.dk>
Den Thu, 29 Nov 2007 16:19:49 +0000 skrev Gregory W Bennett:
> A group of us has a project which originated on Lisp Machines but has
> since been ported to MacLisp and Allegro.
Just a nitpick, but are you sure you ported _to_ Maclisp? That would be
most surprising if it were the case.
Cheers,
Maciej
In article <············@news.net.uni-c.dk>,
Maciej Katafiasz <········@gmail.com> wrote:
> Den Thu, 29 Nov 2007 16:19:49 +0000 skrev Gregory W Bennett:
>
> > A group of us has a project which originated on Lisp Machines but has
> > since been ported to MacLisp and Allegro.
>
> Just a nitpick, but are you sure you ported _to_ Maclisp? That would be
> most surprising if it were the case.
Maybe he actually means MCL.
--
Barry Margolin
Arlington, MA
From: Greg Bennett
Subject: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <47506f6e$1@news.sentex.net>
Barry Margolin wrote:
> In article <············@news.net.uni-c.dk>,
> Maciej Katafiasz <········@gmail.com> wrote:
>
>> Den Thu, 29 Nov 2007 16:19:49 +0000 skrev Gregory W Bennett:
>>
>>> A group of us has a project which originated on Lisp Machines but has
>>> since been ported to MacLisp and Allegro.
>> Just a nitpick, but are you sure you ported _to_ Maclisp? That would be
>> most surprising if it were the case.
>
> Maybe he actually means MCL.
++ He does; sorry for the slip.
++ Any opinions on the queries themselves, perchance ?
/GB
Gregory W Bennett <········@likelihood.math.uwaterloo.ca> wrote:
+---------------
| A group of us has a project which originated on Lisp Machines
| but has since been ported to MacLisp and Allegro. ... emphasis
| is on graphical displays ... The project is heavily object-oriented
| so a fast CLOS is all but essential as is a fast graphics package.
|
| We would like to move this to the Linux world and a non-commercial
| implementation so we have followed the recent discussion of CLISP
| and/vs other free implementations with interest. We would be interested
| to hear views on graphics packages for static and dynamic graphics...
+---------------
1. My first coding in CL[1] was for a database-backed web app,
and I initially used both CLISP & CMUCL, for quite a while,
but then settled on CMUCL because the compiled code for my
app was just *so* much faster, and also because the green
threads in CMUCL[2] were a very good match to my app. All
the initial development was done on FreeBSD 2.2.6, but was
later moved to FreeBSD 4.3, 4.6, 4.10, and now 6.2 with no
problems whatsoever.[3] Furthermore, the porting of the app
to Linux 2.4.21-40.EL (RH) was nearly as seamless, as was moving
to Linux 2.6.7 and then 2.6.20, and it's still running on all
those platforms. [Well, except FBSD 2.2.26 -- that machine died.]
So I clearly like CMUCL, on x86 platforms at least.
2. If you going to be doing lots of motion graphics, some GUI
that binds to OpenGL at the bottom would be nice, such as
Ken Tilton's "Cello" over GLUT [Google for it], which also
would get you "Cells" [ditto] included, for dynamic constraint
programming.
In any case, there are *lot* of CL implementations that run on
Linux these days and *lots* of GUI packages available. Start here:
http://www.cliki.net/Common%20Lisp%20implementation
http://www.cliki.net/Graphics%20Toolkit
http://www.cliki.net/Graphics%20Library
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Maciej Katafiasz
Subject: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <fir27p$vl0$2@news.net.uni-c.dk>
Den Fri, 30 Nov 2007 21:24:20 -0600 skrev Rob Warnock:
> 1. My first coding in CL[1] was for a database-backed web app,
Did something eat your footnotes, or am I misunderstanding the notation?
Cheers,
Maciej
Maciej Katafiasz <········@gmail.com> wrote:
+---------------
| Rob Warnock:
| > 1. My first coding in CL[1] was for a database-backed web app,
|
| Did something eat your footnotes, or am I misunderstanding the notation?
+---------------
*Yikes!* Yes, "something" (my absentmindedness) ate my footnotes.
Let me try that portion again:
1. My first coding in CL[1] was for a database-backed web app,
and I initially used both CLISP & CMUCL, for quite a while,
but then settled on CMUCL because the compiled code for my
app was just *so* much faster, and also because the green
threads in CMUCL[2] were a very good match to my app. All
the initial development was done on FreeBSD 2.2.6, but was
later moved to FreeBSD 4.3, 4.6, 4.10, and now 6.2 with no
problems whatsoever.[3] Furthermore, the porting of the app
to Linux 2.4.21-40.EL (RH) was nearly as seamless, as was moving
to Linux 2.6.7 and then 2.6.20, and it's still running on all
those platforms. [Well, except FBSD 2.2.26 -- that machine died.]
So I clearly like CMUCL, on x86 platforms at least.
...
-Rob
[1] I had been doing serious coding in Scheme for ~10 years before
that, including some CGI apps that did HTML generation in Scheme,
so I hit the ground running with CL. [Yes, Kenny, I still owe
you all an RTL page...]
[2] CMUCL confusingly calls the package "MULTIPROCESSING", but it's
really multiprogramming, that is, "green" threads (co-routines)
within a single Unix/Linux process. But since CMUCL's threads
are very nicely integrated with its I/O so that by default *all*
I/O uses "select()", starting a new thread per HTTP request works
out extremely nicely. Some threads can block [waiting for a slow
input or output file descriptor to become usable] without blocking
others for which I/O is ready. The thread doesn't have to do
anything special to make this work, just use normal CL stream I/O.
[3] A warning for CMUCL users thinking of switching to FreeBSD 7.0:
Unlike FreeBSD 4.x, 5.x, and 6.x, which will happily run a CMUCL
that has been compiled on some earlier version of FreeBSD, via
the appropriate "compatN" libraries, the FreeBSD 7.0 beta changes
the signal handling [specifically, SIGBUS vs. SIGSEGV] in a way
that breaks CMUCL's GC. One of the CMUCL developers is currently
communicating with FreeBSD developers to try to resolve this issue.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
>
> [3] A warning for CMUCL users thinking of switching to FreeBSD 7.0:
> Unlike FreeBSD 4.x, 5.x, and 6.x, which will happily run a CMUCL
> that has been compiled on some earlier version of FreeBSD, via
> the appropriate "compatN" libraries, the FreeBSD 7.0 beta changes
> the signal handling [specifically, SIGBUS vs. SIGSEGV] in a way
> that breaks CMUCL's GC. One of the CMUCL developers is currently
> communicating with FreeBSD developers to try to resolve this issue.
Hopefully, the issue will be resolved soon, i.e, before 7.0 is
released. Actually, I stop receiving the feedback from the originator
exactly after submitting patch that could be a final solution.