make source executable

hello~
I am new to lisp
lisp looks very interesting.
since I am new to lisp and lisp IDE, I have no idea how to make source executable.
I want to distribute my program when I finish my work
to windows, linux, mac os.
could somebody tell me how to make source file executable in lispbox?
I am in Ubuntu 10 and lispbox's version is 0.7

there is compile menu in lispbox's emacs, but it makes file with fasl extension
I can't execute it

evaluate whole source code and execute executable file shows different result sometimes
so I want to make it executable and run for test

could somebody let me know?
your little advice would be very helpful
thanks in advanced

CL fasl files are somewhat like C's object files (*.o) or Java's class files (*.class). You need to do another step to make an executable. In C, this requires linking object files into a library or executable with one object containing main(). Java bundles them into a Jar file with its manifest. Cl implementations generally add the compiler/kernel to make an executable image.

Each implementation has its own ways of making executables. [rul=http://www.cliki.net/cl-launch]cl-launch[/url] provides a semi-standard interface for creating shell scripts that run lisp programs.

Which version of lisp are you using? [e.g. run (lisp-implementation-type) and (lisp-implementation-version)]

You esesentially cant.

There are ways to dump images (implementation specific).However lisp kind of has its own special environment.

So no matter what, even if your implementation compiles to native code like sbcl you always need that environkment linked with your binary.
To make an example see it like a really really fucking huge list of libraries statically linked.
For added complexity your program gets fucked up and probably loses its hability to see or interact with anything but the "packed" environment and libs.

Anyway, CL goes a long way to isolate you form the OS. So when talking about portability people mostly think in terms of CL implementations.
Thinking you could play nice with everyone else is something they probably thought stupid, when everyone else was tryin to be C compatible...
They were too busy preparing their autistic im-so-special environment for the coming of the lisp machines dominance.
Too bad that never came nor will ever come.


That is, a "standalone" would be shipping your compiler and full runtime with the code all packed and made an exe/elf.

Think of it as making a python script standalone by making an executable tht basically packs the whole fucking interpreter and libraries(only deps).

Google for it, but i would be surprised if the "standalone" wasnt in the range of the dozens of megs for a simple "hello world", feed it some dependencies and it will grow like a sponge.

If you need binary portability, you might have to use a specific lisp. There are a few ways to do it:

• Lisp produces an executable (or a DLL). Some Commerial lisps do this. The resulting binary/dll will probably be in the 50 meg range.
• Compile to C, use that to build distributable executables.
• Compile to Java, use that to build distributable jar files.
• Use an embeddable Lisp inside a larger distributable program.
• Use a Lisp that runs on the JVM.

Here are some noteworthy Lisp implementations.

• ECL -- Embeddable Common Lisp is aimed at producing a small-footprint Lisp system that can be embedded into existing C-based applications. It is able to create stand-alone ELF executables from Common Lisp code and runs on most platforms that support a C compiler.
• GNU Common Lisp (GCL) is the GNU Project's Common Lisp compiler, an evolutionary development of Kyoto Common Lisp. It produces native object code by first generating C code and then calling a C compiler.
• Closure CL -- Clozure CL supports the Mac OS X, Linux, FreeBSD, Solaris and Microsoft Windows platforms. There are 32 and 64 bit x86 variants for each. Additionally, there are PowerPC ports for Mac OS X and Linux.
• ABCL -- ABCL is a full implementation of the Common Lisp language featuring both an interpreter and a compiler, running in the JVM.
• CLforJava -- (under development) looks like it can compile Lisp code into Java byte code. I think ABCL can do something similar.

Also, there is Clojure (Clojure runs on the Java Virtual Machine and the Common Language Runtime. Clojure honors the code-as-data philosophy and has a sophisticated Lisp macro system.)

There are also some Scheme implementations.

• Bigloo is an implementation of the Scheme programming language developed at the French IT research institute INRIA. Its orientation is towards providing tools for effective and diverse code generation that can match the performance of hand-written C or C++. The Bigloo system contains a Scheme compiler that can generate C code and JVM or .NET bytecode.
• Chicken is a compiler and interpreter for the Scheme programming language that compiles Scheme code to standard C. It is mostly R5RS compliant and offers many extensions to the standard. Chicken is free software available under the BSD license.
• Gambit, also called Gambit-C, is a free software Scheme implementation, consisting of a Scheme interpreter, and a compiler which compiles Scheme to C.
• Gauche is an R5RS Scheme implementation. It is designed for scripting in a production environment. It is intended to allow programmers and system administrators to write scripts in support of daily operations. Quick startup, built-in system interface, native multilingual support are some of its key design goals.
• Kawa is a language framework written in Java that implements the programming language Scheme, and can be used to implement other languages. It is a part of the GNU Project.
• SISC -- Like GNU Guile, this Scheme is suitable for embedding into larger programs, where Guile is designed for inclusion in C programs, SISC is designed for the JVM.
• Stalin is intended for production use in generating an optimized executable. "Stalin brutally optimizes."

Kind&Deadly wrote:You esesentially cant.
...
So no matter what, even if your implementation compiles to native code like sbcl you always need that environkment linked with your binary.
To make an example see it like a really really fucking huge list of libraries statically linked.
For added complexity your program gets fucked up and probably loses its hability to see or interact with anything but the "packed" environment and libs.

Please don't spout ignorance. You speak as if C/C++ programs didn't have a large support runtime (e.g. libc =1.6MB, ld=133KB, libstdc++=1MB, ...), Java apps could run without the JVM, etc.

CL doesn't lose abilities when standalone executables are made (unless you ask it to).

nuntius wrote:

Kind&Deadly wrote:You esesentially cant.
...
So no matter what, even if your implementation compiles to native code like sbcl you always need that environkment linked with your binary.
To make an example see it like a really really fucking huge list of libraries statically linked.
For added complexity your program gets fucked up and probably loses its hability to see or interact with anything but the "packed" environment and libs.

Please don't spout ignorance. You speak as if C/C++ programs didn't have a large support runtime (e.g. libc =1.6MB, ld=133KB, libstdc++=1MB, ...), Java apps could run without the JVM, etc.

CL doesn't lose abilities when standalone executables are made (unless you ask it to).

http://www.sbcl.org/manual/Generating-Executables.html

Created an image with a simple :toplevel that just prints "Hello World" and dies.

No imports , no asdf and no quicklisp.

28MB on Hello World app.

Point proven.

Btw want me to make you a simple Hello world on c/c++ under 10k(quite absurdly easy)?

Also, refrain from demanding it to be statically linked.On c/c++ its quite unnecessary, since the runtime is ubiquitous.


And please bear in mind that if by any chance you suggest compression or packing as "compesation" method to get them closer they wont, not only the lisp runtime will always be a lot bigger but, anythying you think can bea applied to their not-BEHEMOTH c/c++ counterpart.

Are you really that deluded?

I will repeat: You are ignorant on this topic.

SBCL is good at many things. Making small executables is not one of them. They badly need a tree-shaker or better executable file format.

Try ECL instead. http://ecls.sourceforge.net/ecldev/Comp ... mples.html

I get a ~40KB executable linked against a 7MB support library. Not optimal, but nothing to worry about.


Other free and commercial lisps can do similarly with little effort.

ECL and CLISP let you make compact executables (tutorial for CLISP: http://code.google.com/p/lispbuilder/wi ... AloneCLISP, it also lets you run .fas compiled files as programs: http://www.gnu.org/software/clisp/impno ... start.html).

There is lispx-proxy, which makes program distributions (even with stuff like tray icons etc.) for a bunch of Free Software Lisp implementations (also for Clojure and Racket) for Windows.

Clozure can make Mac OS X apps, and at one point could make really small executables (something like 1.5 MiB for everything), but I don't know if it still does.

Lispworks and Allegro both come with very good support for delivering native applications, including "tree shakers," which strip out unneeded things like the compiler and documentation strings (which is what makes SBCL ~30 MiB large).

I am brand new to Ubuntu and Debian but familiar with lisp programming on other platforms. After using Synaptic to get SBCL I was poking around and tripped across the "common-lisp-controller" mechanism. I found some developer-oriented docs on the Debian site but I haven't found anything about how to set up one's personal file structure to work most harmoniously with the mechanism. Are there conventions for dot files (I saw reference to a ".clc" but no info on what should be put therein)? I like the idea of having the cl libraries available to more than one common lisp implementation, but I am in the dark as to how that can be made to happen. Any hints?

Instead of CLC, take a look at http://www.quicklisp.org/

Its not perfect, but it has a lot of momentum.

walter80 wrote:Are there conventions for dot files (I saw reference to a ".clc" but no info on what should be put therein)?

The directory ~/.clc/systems/ is where CLC looks for .asd files. (Note that you must symlink them there from their original directories, not copy them.) In fact, I've been using the ~/.clc/systems/ directory as a convention since I first started using Common Lisp, even when not on Debian/Ubuntu/Gentoo, as it seems as good a canonical asdf:*central-registry* member as any other to me.

Note that Quicklisp, too, will happily find and load stuff from all the places that CLC searches (as long as CLC is present in the Lisp you're using), so if you follow nuntius' suggestion and use Quicklisp, there's no need to distinguish between Debian-provided libraries and Quicklisp-native ones.

I use ECL build example's exe on windows.ECL build by nmake only VC2005 on windows.
But it's error message is "Cannot Symobl BUILD-PROGRAM in #'("C" package)".
why?

Please reply to the ECL question on the new topic.