need help with lispworks

Hi all,

I've installed LispWorks personal edition and I'm trying to figure out how to compile a working program... There are two windows "listener" and "editor" in the GUI where I can type some commands and write a source code respectively.

I can not find any way to create an *.exe file though (I'm working under Win XP).
All I have is Compile and Load options in the menu and when I compile my source code it creates an *.ofasl file on the disk and this is as far as I can go.

I can not load any of these two files into "listener" or "editor" windows as it produce the following error:
"End of file while reading stream #<Concatenated Stream, Streams = ()>."

Can anyone explain me please how to make a program work inside LispWorks, what's the procedure for it or how to make a stand alone *.exe file?

If you are using the personal license for LispWorks then that is probably why you cannot create executables. Clozure CL and CLISP can create Win32 executables and have no artificial limitations (as far as I know).

Are you new to Common Lisp?

alikim wrote:Can anyone explain me please how to make a program work inside LispWorks, what's the procedure for it or how to make a stand alone *.exe file?

Is this a distribution requirement, or habit? I ask because many people get hung up on the way they did things in C, and you seem like you may be new to Lisp.

Thanks, as my post had been delayed by the moderator for two days before publishing I already dug a bit into it and found out that you can't create execs with that license as it's crippleware and deleted LispWorks. Now I'm giving a try to CLISP..

Yes, I'm new to LISP so all I want to have is some LISP environment where I could create console and window applications under XP and also I need this LISP program to be compiled for running under a Unix like OS as I might need to make it work like a CGI.. not sure if this is possible though..

As to the question about my habits - I want to make a stand alone program running on any PC under (at least) XP so it has to be an executable file, do you have other habits?

I think usually they're not in the habit of making executables.
Anyways, you have some options. If you know the sbcl, clisp, or whatever is going to be on the computer, you can use cl-launch
. "CL-Launch will create a shell script that, when invoked, will evaluate the specified Lisp software with an appropriate Common Lisp implementation.

A suggested short-hand name for cl-launch is cl (you may create a symlink if it isn't included in your operating system's cl-launch package). " Not quite an exe, but then you could create a bat to invoke the shell script. I'm sure you could also create an exe program using c which also invokes the shell program. The creation of the c program and compiling could be easily automated in lisp. Could be a good task for a newcomer.

You're other options are creating clisp/sbcl executables. However, these executables are packed with the whole clisp.sbcl system. Thus, a small program will eb around 25 mb. It doesn't scale up, the clisp.sbcl system (around 25 mb) is only included once, but still...

There is also the option of ecl. Ecl takes a different approach and compmiles lisp to c programs. I haven't used it, so don't know how stable it is. I have compiled version 9.4.1, but since then some newer ones have come out, though i'm not sure if they're compatable with windows yet. With ecl, you can also produce dlls in addition to exes and the size will be in accordance with the program size (well, atleast i think. the ecl runtime which is probably included is much smaller?) You should check this out.

That's about all i know....

Oh, and i know that cusp, an eclipse plugin for lisp, can automatically create sbcl exes. But, then again, its not exactly hard, so might not be worth the trouble of downloading...

EDIT: reading cl-launch, it says
"Fully supported, including standalone executables:
sbcl: SBCL 1.0 (1.0.21.24 needed for standalone executable)
clisp: GNU CLISP 2.44 (no standalone exec before 2.48, broken before 2.36)
ecl: ECL 0.9l (Beware! cache needs be cleared before to dump asd images)

"

alikim wrote:Thanks, as my post had been delayed by the moderator for two days before publishing I already dug a bit into it and found out that you can't create execs with that license as it's crippleware and deleted LispWorks. Now I'm giving a try to CLISP..

Yes, I'm new to LISP so all I want to have is some LISP environment where I could create console and window applications under XP and also I need this LISP program to be compiled for running under a Unix like OS as I might need to make it work like a CGI.. not sure if this is possible though..

Yes, it is.

As to the question about my habits - I want to make a stand alone program running on any PC under (at least) XP so it has to be an executable file, do you have other habits?

Not necessarily for deployment, but for development one usually does not create stand-alone executables like you'd do with C. Instead you're always in your Lisp executable (or image) and incrementally working on your program inside it.

Harnon wrote: You're other options are creating clisp/sbcl executables. However, these executables are packed with the whole clisp.sbcl system. Thus, a small program will eb around 25 mb. It doesn't scale up, the clisp.sbcl system (around 25 mb) is only included once, but still...

SBCL executables compress really well with tools like gzexe (an ELF executables compressor). Size goes about 4 times to ~6M.

Thanks for replies, now I'm more confused though.. anyway I don't know much about how you work with images but the final product for is exe file so that I could send it to other people who know nothing about programming, lisp and such to test.
I've found a way to create exe files using lisp.exe, lispinit.mem and some cmd script and it seems to be working ok.
It created a windowed application executable 3Mb in size which also seems ok so I just need to check if I can build console appp with that.

And can anyone plz gimme a link to how create a CGI with CLISP?
I mean I can google it but it seems that you have to use some custom packages/libraries and I'm not sure which one is preferable.

I never knew clisp produced such a smaller image size than sbcl. Now i know!
I have never used CGI so i don't know. However, if you're trying to develop a website using lisp, you should use Hunchentoot. If that's not what you're trying to do, sorry, i
didn't really look too closely at what it was.

To clear up my comments on executables:

As far as i know, open source lisp include the entire lisp environment in its executables. That means you have access to everything that comes by default with clisp, not
just what you use. This tends to make the 'base executable size' (size of included environment) large for your exe files.
For your purpose, you would want to do one of the following to create exes (seems you have done it already):

(1) Create exe with sbcl, clisp, etc.
(a) clisp produces smaller images than sbcl.
(2) Create exe with Ecl lisp
(a) even smaller
(3)Create a compressed exe to reduce the size (using the tool mentioned above)

If you already have lisp installed on your system, you can simply use cl-launch which will create executables that access your lisp environment on your current
computer in order to run your program. You don't want this you said.

Harnon wrote:There is also the option of ecl. Ecl takes a different approach and compmiles lisp to c programs. I haven't used it, so don't know how stable it is.

ECL is quite stable. Juanjo does a great job with it and is very responsive to any problems found. IMO, it's a more specialized version of CL, very useful for certain deployment scenarios, like say where you want things compiled to C. I typically prefer SBCL for general Linux usage.

findinglisp wrote:CL is quite stable. Juanjo does a great job with it and is very responsive to any problems found.

I am glad you got that impression

findinglisp wrote:IMO, it's a more specialized version of CL.

I really would like to understand why people do have that image of niche lisp. There are three things that I normally read attached to ECL: (1) slow, (2) only useful for embedding, (3) unstable. It is very hard to dispell these miths, even though ECL is now running perfectly fine large programs, such as Maxima. Indeed ECL replaced CLISP in the Sage project because of portability, another thing that seems to be unimportant for Common Lisp developers, and it is achieving greater performance with ECL than with CLISP.

There is also nothing fundamental that prevents ECL from, say, achieving the speed of SBCL, and work is in progress to produce a better compiler that performs better type inference. Using C indeed is not such a big problem, and a mid-term goal it should be possible to get code generation via LLVM's compiler. However all this requires work and there are not many people that contribute code around.

Related to this, I seem to get the impression that ECL is not perceived as lispy enough. The fact that we use C as portable backend seems to scare away some people, or disgust others. Who knows. I wonder whether these people have ever considered how much of ECL is actually developed in C, or the convenience of having a very small (*) core that can bootstrap itself on any platform with C.

In any case, I can not complain. Right now there are four projects, Maxima, OpenAxiom and Fricas that give useful feedback, we are improving in testing and building, and there is a very supportive and friendly user base out there.

(*) Indeed small, even if the line number count says the opposite: Common Lisp code is much more compact.

jjgarcia wrote:

findinglisp wrote:CL is quite stable. Juanjo does a great job with it and is very responsive to any problems found.

I am glad you got that impression

findinglisp wrote:IMO, it's a more specialized version of CL.

I really would like to understand why people do have that image of niche lisp. There are three things that I normally read attached to ECL: (1) slow, (2) only useful for embedding, (3) unstable. It is very hard to dispell these miths, even though ECL is now running perfectly fine large programs, such as Maxima. Indeed ECL replaced CLISP in the Sage project because of portability, another thing that seems to be unimportant for Common Lisp developers, and it is achieving greater performance with ECL than with CLISP.

There is also nothing fundamental that prevents ECL from, say, achieving the speed of SBCL, and work is in progress to produce a better compiler that performs better type inference. Using C indeed is not such a big problem, and a mid-term goal it should be possible to get code generation via LLVM's compiler. However all this requires work and there are not many people that contribute code around.

Related to this, I seem to get the impression that ECL is not perceived as lispy enough. The fact that we use C as portable backend seems to scare away some people, or disgust others. Who knows. I wonder whether these people have ever considered how much of ECL is actually developed in C, or the convenience of having a very small (*) core that can bootstrap itself on any platform with C.

In any case, I can not complain. Right now there are four projects, Maxima, OpenAxiom and Fricas that give useful feedback, we are improving in testing and building, and there is a very supportive and friendly user base out there.

(*) Indeed small, even if the line number count says the opposite: Common Lisp code is much more compact.

Quick question; why not work on making SBCL more portable seeing as SBCL already has a pretty decent compiler with type inference etc. going for it?

Perhaps there are some fundamental things in SBCL which makes it hard to port to e.g. Windows though. IIRC there was some talk about Windows doing "weird stuff" with memory that did not fit well with SBCL's memory management system.

lnostdal wrote:Quick question; why not work on making SBCL more portable seeing as SBCL already has a pretty decent compiler with type inference etc. going for it?

* Memory usage;
* Executable size: like you would do in C, an ECL executable is linked against libecl.so or ecl.dll (which is already very small) and any libraries you need to use;
* It makes dynamic libraries (so you don't need a 100MB executable with all libs included);
* You don't need to include a full optimized compiler with every program you make (this is, I think, the main advantage of ECL, and partially the reason of the other advantages).

In SBCL you can create .fasl files and scripts to load the code, but it is not the same thing. If your program is a bit large, loading fasls takes a while (try timing while you load elephant or mcclim, for instance).

It isn't nice to port a simple program in SBCL to, for instance, a smartphone, because it would eat a lot of memory. SBCL is perfect when you have lots of RAM and you are not executing various SBCL instances at the same time. ECL can be used in many other scenarios.

gugamilare wrote:

lnostdal wrote:Quick question; why not work on making SBCL more portable seeing as SBCL already has a pretty decent compiler with type inference etc. going for it?

* Memory usage;
* Executable size: like you would do in C, an ECL executable is linked against libecl.so or ecl.dll (which is already very small) and any libraries you need to use;
* It makes dynamic libraries (so you don't need a 100MB executable with all libs included);
* You don't need to include a full optimized compiler with every program you make (this is, I think, the main advantage of ECL, and partially the reason of the other advantages).

In SBCL you can create .fasl files and scripts to load the code, but it is not the same thing. If your program is a bit large, loading fasls takes a while (try timing while you load elephant or mcclim, for instance).

It isn't nice to port a simple program in SBCL to, for instance, a smartphone, because it would eat a lot of memory. SBCL is perfect when you have lots of RAM and you are not executing various SBCL instances at the same time. ECL can be used in many other scenarios.

Makes sense. Thanks.

gugamilare wrote:

lnostdal wrote:Quick question; why not work on making SBCL more portable seeing as SBCL already has a pretty decent compiler with type inference etc. going for it?

* You don't need to include a full optimized compiler with every program you make (this is, I think, the main advantage of ECL, and partially the reason of the other advantages).

There is a more serious reason, since the other ones can be worked around (mmapping binary images, stripping less relevant parts of code, etc). SBCL implements its own compiler. Porting to a different platform means creating a new backend for that compiler. That makes a huge barrier for bootstrapping new lisps. I personally know very little assembler and do not want to be bother with learning the ABI conventions of different operating systems and other low level details. OTOH, seems like a nice challenge for many hackers and probably one of the reasons why many of the best lispers contribute to SBCL

jjgarcia wrote:

findinglisp wrote:CL is quite stable. Juanjo does a great job with it and is very responsive to any problems found.

I am glad you got that impression

You're welcome. You earned it.

findinglisp wrote:IMO, it's a more specialized version of CL.

I really would like to understand why people do have that image of niche lisp. There are three things that I normally read attached to ECL: (1) slow, (2) only useful for embedding, (3) unstable. It is very hard to dispell these miths, even though ECL is now running perfectly fine large programs, such as Maxima. Indeed ECL replaced CLISP in the Sage project because of portability, another thing that seems to be unimportant for Common Lisp developers, and it is achieving greater performance with ECL than with CLISP.

Yes, I think all of those are myths. It certainly isn't slow when it's compiled. I don't know if the interpreter is slow(er) than something like CLISP. I know you have dropped in a bytecode interpreter now, for instance. I agree that it isn't only useful for embedding, but I think that was some of the history of it, which might explain that impression. I definitely agree that it isn't unstable.

There is also nothing fundamental that prevents ECL from, say, achieving the speed of SBCL, and work is in progress to produce a better compiler that performs better type inference. Using C indeed is not such a big problem, and a mid-term goal it should be possible to get code generation via LLVM's compiler. However all this requires work and there are not many people that contribute code around.

I'd just warn you here to avoid arguing the "...the is nothing fundamental that prevents..." angle. I would agree with you that there is nothing fundamental that prevents it, but the work has not yet been done. As it stands TODAY, ECL is slower than SBCL, which was the main root of my comment that I use SBCL for general Lisp programming and then I turn to ECL for more specialized tasks. In particular, the ECL memory footprint is very small in comparison to something like SBCL.

Related to this, I seem to get the impression that ECL is not perceived as lispy enough. The fact that we use C as portable backend seems to scare away some people, or disgust others. Who knows. I wonder whether these people have ever considered how much of ECL is actually developed in C, or the convenience of having a very small (*) core that can bootstrap itself on any platform with C.

Yea, I don't have a problem with C. The only "problem" I can think of is that it's sometimes a pain to have the dependency on the C compiler itself; it's simply another dependency that I'd rather not deal with, particularly for a dynamic language that can do runtime compilation and optimization generally. With SBCL, you always have the fast compiler available. The downside is, you always have it available and SBCL is huge. With ECL, you only have the fastest compiler available in those environments when you have it available. But now you're comparing the overall footprint of ECL + C compiler + C libs + etc.

In any case, I can not complain. Right now there are four projects, Maxima, OpenAxiom and Fricas that give useful feedback, we are improving in testing and building, and there is a very supportive and friendly user base out there.

Indeed, those are great projects to have using ECL all the time and they will contribute greatly to ECL progress over the coming months and years.