Hi folks,
I've been going through a common lisp phase again, after a long period of
struggling with C++ and other langauges. I'm seduced by the power of
macros and the general expressivity of CL.
I'm a cheap, starving student, however, with odd notions of open
source idealism. I would like to be able to write Clever Things in
either common lisp or in something very much like it, in such a way
that it's easily distributable to others.
Does anyone know of a good way for me to do this? I've been toying
with the idea of writing a small compiler for a subset of CL, but the
more sane portions of my mind call that sheer craziness. However, a
compiler would let me specially target any computationally intensive
portions of my code (such as numerics), hopefully getting some speed
that way. CLISP is too slow for numerics; CMUCL is fast enough, but
it is such a large package that I don't want to require it for others
to use my code.
I've glanced a bit at ECLS, which claims to be small, but which (in
practice) seems rather large; perhaps there is a way to whittle it
down to a minimal subset, but I have not figured that out yet. It
claims to have the same goals that I'm striving towards.
To make everything more complicated, I'd like to run this on Macintosh
OS X, which eliminates CMUCL directly. I'd like to be able to port
things to Solaris and Linux, but I'm trying to transition myself to OS
X, so that takes priority.
In short, I'd like something which is fast for numerics, small to
distribute (or can easily perform a "tree shake" to make itself
small), and which runs on both Linux and Macintosh. Is there such a
beast?
I'm thinking about directly purchasing MCL, but am afraid that would
make any Macintosh applications I write require a large download in
order to do anything. Does anyone here know how large a distributable
binary of a MCL application must be?
Thanks,
--Johann
--
Johann Hibschman ······@physics.berkeley.edu
In article <··············@astron.berkeley.edu>,
······@physics.berkeley.edu wrote:
> that way. CLISP is too slow for numerics; CMUCL is fast enough, but
> it is such a large package that I don't want to require it for others
> to use my code.
SBCL is another version of CMU CL.
> To make everything more complicated, I'd like to run this on Macintosh
> OS X, which eliminates CMUCL directly. I'd like to be able to port
> things to Solaris and Linux, but I'm trying to transition myself to OS
> X, so that takes priority.
Hmm, I'm currently only using MacOS and Genera so take
my advice with a grain of salt. I intent to switch
to MacOS X once it supports enough functionality
and MCL runs on it.
I think if people are using Unix in some flavor (and MacOS X
is one), the best free implementations are CLisp and CMUCL.
CMUCL is a relatively ambitious beast and I suggest
that Lisp developers wanting to improve the state
of a larger free (CMUCL is really "free") Lisp implementation
with an optimizing native code compiler should swarm out
and support the CMUCL maintainers.
IF somebody wants to use DARWIN (the "Open Source" OS
from Apple, http://www.publicsource.apple.com/ , which
has been ported to x86) or MacOS X (based on Darwin) - a port
of CMUCL might be interesting.
To quote marketing speak about Mac OS X:
"Mac OS X is Unix-savvy
Mac OS X supports POSIX file system semantics and
NFS file sharing, as well as standard services like
telnet and FTP, allowing easy operability with UNIX
systems and applications. The system�s kernel � the
part that does the heavy lifting � is based on Mach
3.0 from Carnegie-Mellon University and FreeBSD
3.2 (derived from the University of California at
Berkeley�s BSD 4.4-Lite), the most highly regarded
core technologies from two of the most widely
acclaimed OS projects of the modern era. We also
took the famous Apache web server � which runs
over half the websites on the Internet � and made it
friendly enough to use on your desktop for personal
file sharing."
As of now CMUCL does not run on PowerPC (Linux, MacOS X,
AIX, or whatever) - but this could be
changed by some Lisp developers, iff they would be
really interested.
A guess: other Unix-based Lisp vendors will port their
Lisp to MacOS X if there is enough interest.
Digitool has said that they are bringing MCL to MacOS X.
But this doesn't mean that MCL/X will support
the various Unix/BSD/NextOS/DARWIN/MacOSX/... features
available. Supporting the new environment (Quartz, ...)
might be a huge task.
> In short, I'd like something which is fast for numerics, small to
> distribute (or can easily perform a "tree shake" to make itself
> small), and which runs on both Linux and Macintosh. Is there such a
> beast?
I don't think so. Atleast no Common Lisp I know of.
> I'm thinking about directly purchasing MCL, but am afraid that would
> make any Macintosh applications I write require a large download in
> order to do anything. Does anyone here know how large a distributable
> binary of a MCL application must be?
Actually MCL is one of the smaller Common Lisp implementations.
Typically one has two choices: 1) create an all-in-one application
or 2) with extra shared libraries. The latter has the advantage
that the shared libraries can be shared by your various MCL
applications - as the name implies - for this purpose they
have to be in the extensions folder in the system folder.
Size for the development version:
"MCL" application 1.6 MB
"MCL library" shared library 3.1 MB
"MCL compiler" shared library 0.45 MB
"MCL kernel" shared library 0.16 MB
I don't have the numbers for a complete minimum application handy,
but it should be the size of an usual MP3 song. ;-)
Rainer Joswig
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
On 18 Sep 2000 00:39:14 -0700, Johann Hibschman
<······@physics.berkeley.edu> wrote:
>In short, I'd like something which is fast for numerics, small to
>distribute (or can easily perform a "tree shake" to make itself
>small), and which runs on both Linux and Macintosh. Is there such a
>beast?
>
Have a look at xlispstat. It has quite some support for numerics, but
has only a bytecode compiler. It works on most platforms. There are
extensions to link foreign functions.
There is also: http://www.arrakis.es/~worm/schelab.html.
and
http://www.math.purdue.edu/~lucier/615/
succes,
Marc
--
------------------------------------------------------------------------------
email: marc dot hoffmann at users dot whh dot wau dot nl
------------------------------------------------------------------------------
In article <··············@astron.berkeley.edu>,
······@physics.berkeley.edu wrote:
> In short, I'd like something which is fast for numerics, small to
> distribute (or can easily perform a "tree shake" to make itself
> small), and which runs on both Linux and Macintosh. Is there such a
> beast?
I am going to be heretic here. My daily work is numerics and I have
found that an interpreted environment which supports a superset of
APL's operations suits my needs. Such a beast exists and it is called
Yorick. In this environment one may do things like
a = array(1.0,100,100,100);
b = array(2.0,100);
c = a+b;
...
The funny thing is that Yorick interprets a C-like language in an
efficient engine with a lot of lispy influence: good ones are symbols,
lists, structures, bad thing is dynamical scope and total lack of
modules. Yorick is great and works in many platforms including MacOS,
Win and most unices, and it is extremely small (<= 700K)
Influenced by my experience I decided that the right thing would
be to work with the same tools in a better language: i.e. Common Lisp.
Hence I designed an sketch of a library that provides all useful
mathematical operations with a lispy syntax. For instance
(array-foldl 0.0d0 #'+ a); sums the elements of A
(array-map a #'+ b c)
The good thing is that CL already provides most of what one needs
(arrays, complex numbers, floats, special functions...) and very
little is required to extend it.
I implemented this library within CMUCL and the code it generates is
as good as my best fortran loops, but integration with other routines,
such as FFTW has proven to be tricky and for now this project is
sleeping on a corner of my HD.
Next I also wondered about embedding the tensor array operations
in CLISP, but some implementation limits discouraged me.
One day I arrived to ECoLisp and the simplicity of its implementation
seduced me. Now, while I keep working with Yorick, I dedicate my spare
time to build a cleaned up version of ECoLisp which is destined to be
a better back-end for Yorick.
> I've glanced a bit at ECLS, which claims to be small, but which (in
> practice) seems rather large; perhaps there is a way to whittle it
> down to a minimal subset, but I have not figured that out yet. It
> claims to have the same goals that I'm striving towards.
I think that ECLS is not that big. The core
interpreter is 240k. Until I remove calls to "sprintf" and the like,
the C library has to be linked in statically which gives about 250k
extra.
+ CL basic + GMP -> 240k
+ C library -> 250k
Then there is extra code to complete the library:
+ Lisp code for CL -> 400k
+ Lisp code for CLOS -> 200k
+ Compiler -> 700k
Since 0.0g it is possible to build customized ECLS executables
without a compiler and with or without user supplied code. For instance
(compiler:build-ecls "ecls-bare")
gives an executable with the minimal code size which is (sum above)
1.2Mb
Of this size, about 200Kb are initialization strings which get quickly
swapped out of memory right after startup. Hopefully at some point I
will be able to replace this initialization data with an image of the
heap, so that startup and executable size are further reduced.
I am also implementing some other functions in C, and there is a lot of
space for improvement in the CLOS library, which should get a
slimmer implementation, but that takes time.
Juanjo
Sent via Deja.com http://www.deja.com/
Before you buy.
worm writes:
> I am going to be heretic here. My daily work is numerics and I have
> found that an interpreted environment which supports a superset of
> APL's operations suits my needs. Such a beast exists and it is called
> Yorick.
Hm. I've tried Yorick, but I've been using Python with for those
types of tasks right now. It seems like the LLNL people who were
responsible for Yorick in the first place are not migrating to
Python. (Or at least their plasma physics division is.)
> Influenced by my experience I decided that the right thing would
> be to work with the same tools in a better language: i.e. Common Lisp.
> Hence I designed an sketch of a library that provides all useful
> mathematical operations with a lispy syntax. For instance
I would like to see this. Do you have it available anywhere on the
web?
> I think that ECLS is not that big. The core
> interpreter is 240k. Until I remove calls to "sprintf" and the like,
> the C library has to be linked in statically which gives about 250k
> extra.
That isn't that bad; I will have to take another look at the package.
--Johann
--
Johann Hibschman ······@physics.berkeley.edu
In article <··············@astron.berkeley.edu>,
······@physics.berkeley.edu wrote:
> worm writes:
> Hm. I've tried Yorick, but I've been using Python with for those
> types of tasks right now. It seems like the LLNL people who were
> responsible for Yorick in the first place are not migrating to
> Python. (Or at least their plasma physics division is.)
I did not appreciate any migration. Indeed Yorick-2 is under
development and an excerpt will appear in Yorick-1.5. Regarding
NumPython, I find it a copy of Yorick which adds nothing new
and lacks too many things.
> > Influenced by my experience I decided that the right thing would
> > be to work with the same tools in a better language: i.e. Common Lisp.
> > Hence I designed an sketch of a library that provides all useful
> > mathematical operations with a lispy syntax. For instance
>
> I would like to see this. Do you have it available anywhere on the
> web?
I could not find a more recent version around so I put this on the
web: http://est202.ind-cr.uclm.es/jjgarcia/aplcl.tgz
The design of the library is based on a set of macros for elementwise
operations plus a set of generic functions on top of it. Under
'minim-3d' there is code for simulating a partial derivatives
equation from Quantum Mechanics (the so-called nonlinear Schroedinger
equation) It even has a 2d false-color plotter in `math-lib' :)
I must say the performance of the code was excellent but
from time to time a SIGSEG fault would break the simulations so
I returned to Yorick --I think it was due to a flaw in my use of
the FFI :(
Juanjo
--
Juan Jose Garcia Ripoll www: http://www.arrakis.es/~worm/index.html
Dpto. de Matematicas job: ········@ind-cr.uclm.es
E.T.S.I. Industriales home: ····@arrakis.es
Univ. de Castilla-La Mancha, Ciudad Real E-13071 (Spain)
Sent via Deja.com http://www.deja.com/
Before you buy.