need help with lispworks

[Harnon]

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.

[findinglisp]

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.

[jjgarcia]

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

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.

[lnostdal]

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

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.

[gugamilare]

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.

[lnostdal]

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.

[jjgarcia]

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

[findinglisp]

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.

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.