* trash...@david-steuber.com (David Steuber "The Interloper") | Can clisp create a binary executable that can be distributed without | relying on lisp being on the other machine?
no. (the same is true for all other languages, incidentally. C just happens to have its run-time system pre-shipped with many systems.)
what is the problem with shipping a file to be loaded into CLISP?
| cmu doesn't seem to be available for Linux. Am I blind, or is this true?
can't say you aren't blind, but CMUCL is available for Linux.
> cmu doesn't seem to be available for Linux. Am I blind, or is this > true?
Look at www.cons.org/cmucl. You'll find rpms and tar files of a fairly recent version. If not, I can let you have mine.
> While not on topic, should I get GARNET? It is no longer being > maintained by cmu. Never the less, it is still tempting to get it.
Of all of the GUI I've tried (CLUE, CLIO, XIT, Picasso), Garnet was the only one with usable documentation and examples. I like it, and there are a few people still interested in it and some fixes have come out recently.
Ray
-- --------------------------------------------------------------------------- ----> Raymond Toy r...@mindspring.com http://www.mindspring.com/~rtoy
On 05 Oct 1998 10:50:12 +0000, Erik Naggum <e...@naggum.no> claimed or asked:
% * trash...@david-steuber.com (David Steuber "The Interloper") % | Can clisp create a binary executable that can be distributed without % | relying on lisp being on the other machine? % % no. (the same is true for all other languages, incidentally. C just % happens to have its run-time system pre-shipped with many systems.)
In the windows world, C or C++ can be compiled into a single executable image. There is no need to rely on a C/C++ compiler or run time environment to run the program.
% what is the problem with shipping a file to be loaded into CLISP?
I don't want to rely on the pre-existance of CLISP (or any other lisp) on another machine. I also want the code to compile into machine code, not some byte interpreted code. It is the paradigm I am used to.
% | cmu doesn't seem to be available for Linux. Am I blind, or is this true? % % can't say you aren't blind, but CMUCL is available for Linux. % % #:Erik
trash...@david-steuber.com (David Steuber "The Interloper") writes:
< In the windows world, C or C++ can be compiled into a single < executable image. There is no need to rely on a C/C++ compiler or run < time environment to run the program. < < % what is the problem with shipping a file to be loaded into CLISP? < < I don't want to rely on the pre-existance of CLISP (or any other lisp) < on another machine. I also want the code to compile into machine < code, not some byte interpreted code. It is the paradigm I am used < to.
CMUCL and acl for linux compile to machine code. You can get the sources for cmucl - it's neat to see the register and instruction handling but it's a real pain to compile (there are many circular dependencies). I know acl will let you dump a single binary without the compiler and debugger. I'm not as familiar with cmucl (actually I don't know much about dumping lisps in general).
Native compilation will usually result in faster applications and you shouldn't get penalized for abstractions either (this is probably obvious though).
You can play with the pseudo-register code in acl by setting COMP::*HACK-COMPILER-OUTPUT* to a list of functions (was just mentioned on cll not too long ago). It seems pretty realistic to me; whenever I changed the code things began to break - very much like my assembly programs (x86 assembly is just too complicated for me).
In acl5.0 you can write your own main function and link it to the lisp stuff. Dunno if that's easier to use or not - never tried it. It's all documented in the manual.
* trash...@david-steuber.com (David Steuber "The Interloper") | In the windows world, C or C++ can be compiled into a single | executable image. There is no need to rely on a C/C++ compiler or run | time environment to run the program.
well, in that case, you can dump a Lisp world into a new image, too.
the image my current client runs on Allegro CL 5.0 has pre-dumped over 300 patches and new functions and advice and such. when the application is ready to be run directly (it's loaded from a concatenated FASL file now), it'd be a piece of cake to load it before dumping yet another image.
| I don't want to rely on the pre-existance of CLISP (or any other lisp) | on another machine. I also want the code to compile into machine | code, not some byte interpreted code.
only Emacs Lisp and CLISP of the commonly supported Lisps produce byte code. all others produce machine code. _that_ should be the least of your worries, actually.
trash...@david-steuber.com wrote: > In the windows world, C or C++ can be compiled into a single > executable image. There is no need to rely on a C/C++ compiler or run > time environment to run the program.
Same for Macintosh Common Lisp. Double Click in the application and it starts...
> In the windows world, C or C++ can be compiled into a single > executable image. There is no need to rely on a C/C++ compiler or run > time environment to run the program.
Actually I suspect that you usually depend on a fair amount of shared library code, unless you do whatever the Windows equivalent of linking statically is. However, you can typically dump lisp images too, and they then don't rely on anything but themselves and the OS. They tend to be bigger than the equivalent C, for small programs (this may not be true on windows -- how large is a typical completely-static binary for Windows, and is that even well-defined (for instance does Windows have a reasonably-small `primitive system-call' level like Unix does)?). However for large programs the zero-point cost imposed by dumping a Lisp image becomes less significant, both because the program gets bigger, and because it uses more of the other stuff that gets dumped in the image.
> On 05 Oct 1998 10:50:12 +0000, Erik Naggum <e...@naggum.no> claimed or > asked:
> % * trash...@david-steuber.com (David Steuber "The Interloper") > % | Can clisp create a binary executable that can be distributed without > % | relying on lisp being on the other machine? > % > % no. (the same is true for all other languages, incidentally. C just > % happens to have its run-time system pre-shipped with many systems.)
> In the windows world, C or C++ can be compiled into a single > executable image. There is no need to rely on a C/C++ compiler or run > time environment to run the program.
> % what is the problem with shipping a file to be loaded into CLISP?
> I don't want to rely on the pre-existance of CLISP (or any other lisp) > on another machine. I also want the code to compile into machine > code, not some byte interpreted code. It is the paradigm I am used > to.
I think I recall that you originally were asking about free Lisps. However, Eclipse ($500) does support the classic C paradigm:
1. COMPILE-FILE generates human readable C. 2. Use your favorite C compiler on that, and any handwritten C code you want. 3. Use your favorite linker to combine this and the Eclipse library to produce a stand-alone executable. (Most such executables can then be distributed freely, without royalties or other runtime requirements.)
Furthermore, the generated C functions can be called directly by hand-written C code, and can call C functions directly.
If you are very used to C, it might also be nice to be able to "see what's going on" in Lisp by looking at the generated C code for some arbitrary Lisp code.
On 6 Oct 1998 05:48:35 GMT, Steve Gonedes <jgone...@worldnet.att.net> wrote:
>< % what is the problem with shipping a file to be loaded into CLISP? >< >< I don't want to rely on the pre-existance of CLISP (or any other lisp) >< on another machine. I also want the code to compile into machine >< code, not some byte interpreted code. It is the paradigm I am used >< to.
>CMUCL and acl for linux compile to machine code. You can get the >sources for cmucl - it's neat to see the register and instruction >handling but it's a real pain to compile (there are many circular >dependencies). I know acl will let you dump a single binary without >the compiler and debugger. I'm not as familiar with cmucl (actually I >don't know much about dumping lisps in general).
It can be done, it's actually a stage in the recompilation: you first generate a image without compiler (kernel.core) and then you load the compiler.
You could modify this to only load the stuff you want, but be aware that the compiler is needed for a lot of things, even for calling CLOS methods...
Actually the best way is to convert clisp into a netscape plug-in and call it a multimedia extention :-).
Groetjes, Peter
-- It's logic Jim, but not as we know it. pvane...@debian.org, pvane...@inthan.be Look in keyservers for PGP key.
trash...@david-steuber.com (David Steuber "The Interloper") writes:
> I still have to boot over to Linux to see if cmucl was included in my > distribution. The cmu web site mentioned "python" as a new cmu cl > compiler. I've heard references to it before and thought it was a > programming language. Is python possibly a synonym for cmu cl?
There are two pythons. One is the name for the CMUCL compiler, which does all sorts of useful type inference. (So, in a sense, that python is a synonym for CMUCL.) The other is a programming language, of comp.lang.python fame. I like both.
> Is cmu cl a better lisp than clisp? I would prefer to stick with just > one lisp for a while, and I would like it to be the Common Lisp that > is considered the most suitable for creating X windows applications.
CMU CL will compile to machine code and is (I believe) more ANSI CL compliant than clisp. So, if you had to pick one, I'd go with CMU CL. I use clisp for small projects because CMU CL is a little too resource-intensive for my old, tired laptop.
Sadly, I don't know anything about threading and GUI programming, so I can't recommend either lisp for that. (I'm a numeric kinda guy...)
On 06 Oct 1998 11:58:15 +0000, Erik Naggum <e...@naggum.no> claimed or asked:
% only Emacs Lisp and CLISP of the commonly supported Lisps produce byte % code. all others produce machine code. _that_ should be the least of % your worries, actually.
Actually, it is fairly low on my list. However, it would be something of a show stopper for me if Lisp couldn't create stand alone applications the way C can. It would make it less than general purpose.
I still have to boot over to Linux to see if cmucl was included in my distribution. The cmu web site mentioned "python" as a new cmu cl compiler. I've heard references to it before and thought it was a programming language. Is python possibly a synonym for cmu cl?
Is cmu cl a better lisp than clisp? I would prefer to stick with just one lisp for a while, and I would like it to be the Common Lisp that is considered the most suitable for creating X windows applications.
On Mon, 05 Oct 1998 23:43:51 -0400, "R. Toy" <r...@mindspring.com> claimed or asked:
% Of all of the GUI I've tried (CLUE, CLIO, XIT, Picasso), Garnet was the % only one with usable documentation and examples. I like it, and there % are a few people still interested in it and some fixes have come out % recently.
Thanks for the pointer! BTW, have you tried CLIM? I saw that listed as a GUI library for cmucl which also supported threading.
On Tue, 06 Oct 1998 10:38:00 -0500, "Howard R. Stearns" <how...@elwood.com> claimed or asked:
% Furthermore, the generated C functions can be called directly by % hand-written C code, and can call C functions directly. % % If you are very used to C, it might also be nice to be able to "see % what's going on" in Lisp by looking at the generated C code for some % arbitrary Lisp code. % % See http://www.elwood.com/eclipse-info
I am choosing between free alternatives at this time. However, I did see a CL to C compiler on the cmu site. I didn't pull it down though. If it is complete, I will probably go for that. I imagine who ever wrote it did a better job of it than I could.
* trash...@david-steuber.com (David Steuber "The Interloper") | However, it would be something of a show stopper for me if Lisp couldn't | create stand alone applications the way C can. It would make it less | than general purpose.
I really don't understand this argument. when you start up a C program, a _lot_ of stuff happens that it is impossible _not_ to refer to as a "run-time environment". C programs are not "stand-alone" for any reasonable meaning of that concept. in fact, _nothing_ is stand-alone, anymore, except for operating systems and certain embedded systems. the rest of the interesting applications are interdependent in massive ways.
for all the evil and fraudulent marketing and business practices that Bill Gates and Microsoft have tried to get away with, the well-deserved lawsuits against them are annoyingly shallow and even stupid. I hate it when bad people get off the hook just because their opponents are dumb. relevant to this case is that their browser _is_ part of their operating system and vice versa, as is all the rest of the shitware they hoist onto innocent Intel processors everywhere, but the coupling is no more or less hard than any other operating system or major application environment. the problem is that it is not documented, even though it _is_ exported. IBM was forced to release documentation for their subsystem interconnect cables as part of their antitrust lawsuits, allowing Amdahl to produce "plug-compatible" systems and hardware. something like this has to be done with software, as well, and then we can start to _rely_ on and exploit the environment instead of being held hostage by it. and perhaps in 50 years' time, even C programmers will start to understand that they are _frightfully_ dependent on the services of the operating system and lots and lots of supporting software elsewhere in the system.
"stand-alone" is a red herring. what do you _really_ want? why is your outdated understanding of "stand-alone" the only answer to your question, to the exclusion of every other answer?
if you want an application that can be shipped elsewhere and it needs a Common Lisp environment, ship the Common Lisp environment. like, duh. those who object to this are merely ignorant of the fact that they were willing to install an operating system before your application, too, and perhaps had to acquire several components from several disparate vendors to build a complete system. you offer them the _benefit_ of shipping the environment they need. if you are frightened of the prospect, _you_ will be the cause of your loss in sales or whatever, not any inherent aspects of the Common Lisp environment you refused to ship.
(note, however, that commercial distribution of either run-time versions or development systems may require you to share with their vendor. if this is what you don't like, try a tax strike first; it's just a futile, but at least it has a better moral foundation.)
| I still have to boot over to Linux to see if cmucl was included in my | distribution. The cmu web site mentioned "python" as a new cmu cl | compiler. I've heard references to it before and thought it was a | programming language. Is python possibly a synonym for cmu cl?
PYTHON is the name of the compiler in CMU CL. PYTHON is also the name of a programming language. they are not related _except_ by name.
| Is cmu cl a better lisp than clisp?
yes, most definitely.
| I would prefer to stick with just one lisp for a while, and I would like | it to be the Common Lisp that is considered the most suitable for | creating X windows applications.
well, if CLISP has it, you got the source. just compile the relevant parts in CMU CL, instead, and off you go. (if it doesn't compile, as I suspect is the case, that's why you shouldn't use CLISP.)
>>>>> "David" == David Steuber "The Interloper" <trash...@david-steuber.com> writes:
David> On Mon, 05 Oct 1998 23:43:51 -0400, "R. Toy" <r...@mindspring.com> David> claimed or asked:
David> % Of all of the GUI I've tried (CLUE, CLIO, XIT, Picasso), Garnet was the David> % only one with usable documentation and examples. I like it, and there David> % are a few people still interested in it and some fixes have come out David> % recently.
I also want to say that I don't think CLUE or CLIO or XIT or Picasso are bad---I was just too stupid to figure out how to do something interesting with the available documentation and examples.
David> Thanks for the pointer! BTW, have you tried CLIM? I saw that listed David> as a GUI library for cmucl which also supported threading.
I don't think there's any CLIM except the commercial version, so CMUCL can't run it. :-( CMUCL on Linux and Freebsd supports threading so all of the Lisp GUIs could to. I believe there are some patches for Garnet that make it multi-threaded for CMUCL.
On 07 Oct 1998 19:02:22 +0000, Erik Naggum <e...@naggum.no> claimed or asked:
% "stand-alone" is a red herring. what do you _really_ want? why is your % outdated understanding of "stand-alone" the only answer to your question, % to the exclusion of every other answer?
What I really want is easy deployment. If the runtime is required, it should be buried in the executable file so that its presence is transparent to the end user and to myself. Like you said with C programs, they rely on OS services. I know I can't get away from that. What I do want to get away from is shipping some other piece like a <cough!> VB programmer has to.
I seem to be very unclear on what I mean by "stan-alone". I guess I've had my head buried in Windblows for so long that run time support means something different than what I thought. I hope with some experience with Lisp, my ideas can clean themselves up and I can make better distinctions between my application, the run time support, and the OS.
Maybe I just want to choose to distribute my code with or without source.
trash...@david-steuber.com (David Steuber "The Interloper") writes:
> What I really want is easy deployment. If the runtime is required, it > should be buried in the executable file so that its presence is > transparent to the end user and to myself. Like you said with C > programs, they rely on OS services. I know I can't get away from > that. What I do want to get away from is shipping some other piece > like a <cough!> VB programmer has to.
You will have to ship more files than your executable anyways (=> Documentation, sample files, ...)! And IIRC with CMU CL the only thing that is needed besides your dumped image is the driver (around 80KB), and a little script like this:
#!/bin/sh exec ./lisp -core NewESIM.core
With around 800KB of compiled code, I get a dumped image around 20MB of size, which can be gzipped (-9) to around 7MB, which makes a little over 7MB in total in 3 files for deployment as a .tar.gz or .zip file, and nothing has to be installed in a "system" directory, or can create conflicts with existing runtime libraries, like VB or Java-apps often do...
To deploy a Java application, you need to deploy the JDK, which is more than 15MB in size, and if it uses Swing (which seems to be getting common these days), you need another 15MB. Of course, most distributors of Java Apps leave it to the user to get and install these themselves... :-( (Sorry, but the whole world _doesn't_ have, or even want Java, and as a user I don't want to know what runtime the application uses, either).
> Maybe I just want to choose to distribute my code with or without > source.
This issues is wholly unrelated to the run-time issue. Since every current CL implementation I know of has a (non NOP) compiler, you can just distribute the compiled files, and no source leaves your system. And with a native-code compiler like CMU CL's, decompiling these files to reverse-engineer the source code seems highly unlikely.
Regs, Pierre.
-- Pierre Mai <d...@cs.tu-berlin.de> http://home.pages.de/~trillian/ "Such is life." -- Fiona in "Four Weddings and a Funeral" (UK/1994)
On 08 Oct 1998 14:03:57 +0200, Pierre Mai <p...@acm.org> claimed or asked:
% With around 800KB of compiled code, I get a dumped image around 20MB % of size, which can be gzipped (-9) to around 7MB, which makes a little % over 7MB in total in 3 files for deployment as a .tar.gz or .zip file, % and nothing has to be installed in a "system" directory, or can create % conflicts with existing runtime libraries, like VB or Java-apps often % do...
A single .tar.gz file is certainly a satisfactory distribution method.
Why don't I think about these things a little more? Oh yeah. I've had my head up windblows for too long. Where's Install Shield?
Imagine installing a web browser and not having to reboot the system for it to work. Imagine? Why would you have to reboot? Installing the web browser upgraded all your system files? Why did it do that? Why should that require a reboot?
CMUCL (at least in the old 17f version) had also a byte compiler, whose main concern was to produce smaller object code. -- Marco Antoniotti =========================================== PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY tel. +39 - (0)6 - 68 10 03 16, fax. +39 - (0)6 - 68 80 79 26 http://www.parades.rm.cnr.it
On 11 Oct 1998 16:27:32 -0400, Sam Steingold <s...@goems.com> claimed or asked:
% That having said, I use both - CLISP for most of the development, CMUCL % for actually running FPU-intesive stuff (CMUCL is about 8x faster than % CLISP in that, while CLISP is about 4x faster with bignums and about % 2-10x faster with i/o).
Look, I've already made up my mind to use CMUCL. Why do have to come along and confuse me with some facts? How did you do the benchmarking? Is there some standard Lisp benchmark program that can be run?
Having said that, I think FPU will be pretty important to me.
CMUCL is apparently written entirely in Lisp. I don't know if CLISP is as well. If there are still missing ANSI features in CMUCL, can't they be dropped in from CLISP code? There is a group of people maintaining CMUCL at www.cons.org. They are moving in the direction of ANSI compliance from what I can see.
trash...@david-steuber.com (David Steuber "The Interloper") writes:
> CMUCL is apparently written entirely in Lisp. I don't know if CLISP > is as well. If there are still missing ANSI features in CMUCL, can't > they be dropped in from CLISP code? There is a group of people > maintaining CMUCL at www.cons.org. They are moving in the direction > of ANSI compliance from what I can see.
Contrary to what Sam has stated, CLISP is IMHO more removed from ANSI compliant behaviour in a number of cases than CMUCL is, and in some of these cases the primary author of CLISP has publicly stated that he prefers the behaviour of CLISP as is over the ANSI-mandated behaviour and thus will not change CLISP to make it conformant.
CMUCL OTOH is constantly being made more ANSI-compliant in those regions where it is needed.
Just noticed that CLISP still starts up in a package named USER which is different from CL-USER (i.e. COMMON-LISP-USER), which IMHO is not ANSI-compliant, and confused me for a couple of secs ;)
WRT the comments that CLISP is faster on I/O and bignums: For most programs neither bignums nor I/O is the bottle-neck (for your program too, I'd imagine), but CMUCL is faster in a number of other regions, and it's numeric optimiziation and type-inference mechanisms probably will prove very important.
I just checked, and the following procedure takes around 4.3 secs on CLISP and CMUCL for a 50000 line file (size ca. 2.5 MB), so CLISP isn't any faster for read-line I/O:
(defun testme2 (name) (with-open-file (stream name) (loop for line = (read-line stream nil nil) while line)))
And if I also split the read lines into fields I get times of less than 10 secs for CMUCL, but I need > 60 secs in CLISP...
Just some datapoints. But you should probably just take a look at CLISP yourself...
Regs, Pierre.
-- Pierre Mai <d...@cs.tu-berlin.de> http://home.pages.de/~trillian/ "Such is life." -- Fiona in "Four Weddings and a Funeral" (UK/1994)
