Hello everybody,
I was using CLISP to learn Common Lisp. It seems CLISP does not
compile to native code. So, just to see how to compile a lisp
program, I installed SBCL. But I don't seem to be able to find
a way to compile any program.
For example, I wrote a trivial program named hello.lisp:
(defun hello ()
(write-string "Hello World!!"))
(hello)
Now I can compile any C program using 'gcc file.c'(Debian),
but what is the equivalent command to compile hello.lisp ?
Also, once inside sbcl, I did
(load "hello.lisp")
(compile-file "hello.lisp")
This produces a hello.fasl file, which, I thought was the
compiled file. So, I exited from sbcl, made it an executable
file (chmod +x hello.fasl), and tried to run it, but it seems
to be something else!!
What am I missing? I want to be able to write a lisp program,
compile it, and be able to run it on some other computer
where no lisp is available.
What am I missing ?
Regards,
Santanu
In Santanu Chatterjee wrote:
> Hello everybody,
>
> I was using CLISP to learn Common Lisp. It seems CLISP does not
> compile to native code. So, just to see how to compile a lisp
> program, I installed SBCL. But I don't seem to be able to find
> a way to compile any program.
>
> For example, I wrote a trivial program named hello.lisp:
> (defun hello ()
> (write-string "Hello World!!"))
> (hello)
>
> Now I can compile any C program using 'gcc file.c'(Debian),
> but what is the equivalent command to compile hello.lisp ?
>
> Also, once inside sbcl, I did
> (load "hello.lisp")
> (compile-file "hello.lisp")
>
Try one of:
(compile-file "hello.lisp")
(load "hello.fasl")
or
(load (compile-file "hello.lisp"))
> This produces a hello.fasl file, which, I thought was the
> compiled file. So, I exited from sbcl, made it an executable
> file (chmod +x hello.fasl), and tried to run it, but it seems
> to be something else!!
>
> What am I missing? I want to be able to write a lisp program,
> compile it, and be able to run it on some other computer
> where no lisp is available.
>
> What am I missing ?
Unlike C you are not compiling your programs, and then executing them.
Instead you are working inside the lisp environment. When you have loaded
your file into sbcl as above, you can just type
(hello)
And your code will be executed, and the code you run is compiled, and not
interpreted. In SBCL you don't need to explicitly compile first, since
all code you type or load into sbcl is compiled on the fly. In fact there
is no interpreter in sbcl. In other lisp systems you may need to compile
explicitly to get the code compiled though.
The fasl file is not executable by itself, it must be used together with
sbcl.
Hope this helps
>
> Regards,
> Santanu
--
--
Gisle S�lensminde
Computational biology unit, University of Bergen, Norway
Email: ·····@cbu.uib.no
On 15 Oct 2003 20:46:03 GMT, Gisle S�lensminde <·····@apal.ii.uib.no> wrote:
> Unlike C you are not compiling your programs, and then executing
> them. Instead you are working inside the lisp environment. When you
> have loaded your file into sbcl as above, you can just type
>
> (hello)
>
> And your code will be executed, and the code you run is compiled,
> and not interpreted. In SBCL you don't need to explicitly compile
> first, since all code you type or load into sbcl is compiled on the
> fly. In fact there is no interpreter in sbcl. In other lisp systems
> you may need to compile explicitly to get the code compiled though.
>
> The fasl file is not executable by itself, it must be used together
> with sbcl.
While this is correct there are two things one can add with respect to
CMUCL/SBCL:
1. You can make FASL files directly executable by the kernel if you're
on Linux 2.2 or greater:
<http://www.cons.org/cmucl/doc/executable.html>
They will still depend on CMUCL/SBCL being there but they will
"feel" like C binaries.
2. Both CMUCL and SBCL have recently added the ability to create
"stand-alone" executables that don't depend on the Lisp runtime. I
don't have the references at hand but for CMUCL it's in the current
CVS (search the cmucl-imp mailing list archives for messages by
Fred Gilham) and for recent SBCL releases it should be in contrib,
i.e. something like
(require :sb-executable)
will do.
For CLISP you'll want to read
<http://clisp.cons.org/impnotes/quickstart.html>.
Edi.
Edi Weitz <···@agharta.de> writes:
> 2. Both CMUCL and SBCL have recently added the ability to create
> "stand-alone" executables that don't depend on the Lisp runtime. I
This is true for CMUCL but not for SBCL
> i.e. something like
>
> (require :sb-executable)
>
> will do.
The :sb-executable contrib in SBCL actually generates a fasl file with
a #! shell header that starts SBCL up. So it's not a way to avoid
having SBCL installed, just a way to hide its presence somewhat.
-dan
--
http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro
On Thu, 16 Oct 2003 03:54:26 +0100, Daniel Barlow <···@telent.net> wrote:
> The :sb-executable contrib in SBCL actually generates a fasl file
> with a #! shell header that starts SBCL up. So it's not a way to
> avoid having SBCL installed, just a way to hide its presence
> somewhat.
OK, thanks, I didn't know that. Any chance that Fred Gilham's
executable stuff will be merged into SBCL?
Edi.
>>>>> "Edi" == Edi Weitz <···@agharta.de> writes:
Edi> On Thu, 16 Oct 2003 03:54:26 +0100, Daniel Barlow <···@telent.net> wrote:
>> The :sb-executable contrib in SBCL actually generates a fasl file
>> with a #! shell header that starts SBCL up. So it's not a way to
>> avoid having SBCL installed, just a way to hide its presence
>> somewhat.
Edi> OK, thanks, I didn't know that. Any chance that Fred Gilham's
Edi> executable stuff will be merged into SBCL?
I don't think it's officially released with CMUCL either, so I'd
wait. The executable stuff is on a branch right now.
Ray
Ray Toy writes:
> I don't think it's officially released with CMUCL either, so I'd
> wait. The executable stuff is on a branch right now.
The save part of the CMUCL executable stuff makes use of non-portable
tricks with GNU linker scripts. I hope, even intend, to rewrite the
save part so that it can write out the executable itself instead of
having to call the linker. I would use the objdump utility but it
doesn't page-align the sections.
However, the time I spent on the executable stuff was a sort of
fortuitous happenstance. So I'm not sure when I'll have time to
finish this part.
Right now it works on FreeBSD 4 and 5, and on Linux on some RedHat
versions. I'm not a Linux expert so I can't even say what RedHat
versions it works on. The problem is that it has to be able to *find*
the stuff it needs, and RedHat, at least, scatters it all over the
disk, or so it seems. (Wasn't there some kind of Linux Directory
Standard or something?)
If you want to get my version, you can check the lisp-executable
branch out of CMUCL's CVS tree.
--
Fred Gilham ······@csl.sri.com
Time is nature's way of making sure everything doesn't happen at once.
Unfortunately, like most things in nature it doesn't always work.
Edi Weitz <···@agharta.de> writes:
> On Thu, 16 Oct 2003 03:54:26 +0100, Daniel Barlow <···@telent.net> wrote:
>
>> The :sb-executable contrib in SBCL actually generates a fasl file
>> with a #! shell header that starts SBCL up. So it's not a way to
>> avoid having SBCL installed, just a way to hide its presence
>> somewhat.
>
> OK, thanks, I didn't know that. Any chance that Fred Gilham's
> executable stuff will be merged into SBCL?
That or something like it is a possibility.
I'd actually be pretty happy with the #! approach for most purposes,
were it not for the fact that SBCL fasl files just aren't very fas.
It's not as if there's any restriction on redistributing the sbcl
runtime - sure, it'd be /nice/ to have an application that's a single
binary, but even C programs don't tend to do that much these days,
what with libraries, configuration files, etc.
So, speed (and shareable pages, of which there aren't any in a fasl)
is a concern. I'd like to do something about this, but I'm not yet
decided exactly what.
-dan
--
http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro
On Wed, 15 Oct 2003 20:46:03 +0000, Gisle S�lensminde wrote:
> In Santanu Chatterjee wrote:
>> What am I missing? I want to be able to write a lisp program, compile
>> it, and be able to run it on some other computer where no lisp is
>> available.
> Unlike C you are not compiling your programs, and then executing them.
> Instead you are working inside the lisp environment. When you have loaded
> your file into sbcl as above, you can just type
>
> (hello)
> The fasl file is not executable by itself, it must be used together with
> sbcl.
Does that mean that one cannot create executable programs using lisp,
which runs from the command line, the way it is done using C ??
Regards,
Santanu
From: Joe Marshall
Subject: Re: How to compile a lisp file ?
Date:
Message-ID: <r81e2oek.fsf@ccs.neu.edu>
"Santanu Chatterjee" <·······@softhome.net> writes:
> On Wed, 15 Oct 2003 20:46:03 +0000, Gisle S�lensminde wrote:
>
>> In Santanu Chatterjee wrote:
>
>>> What am I missing? I want to be able to write a lisp program, compile
>>> it, and be able to run it on some other computer where no lisp is
>>> available.
>
>> Unlike C you are not compiling your programs, and then executing them.
>> Instead you are working inside the lisp environment. When you have loaded
>> your file into sbcl as above, you can just type
>>
>> (hello)
>
>> The fasl file is not executable by itself, it must be used together with
>> sbcl.
>
> Does that mean that one cannot create executable programs using lisp,
> which runs from the command line, the way it is done using C ??
No, it means that you cannot run fasl files.
A fasl file is like a Java class file --- you cannot just run it.
From: Joe Marshall
Subject: Re: How to compile a lisp file ?
Date:
Message-ID: <n0c22o8w.fsf@ccs.neu.edu>
Joe Marshall <···@ccs.neu.edu> writes:
> "Santanu Chatterjee" <·······@softhome.net> writes:
>
>> On Wed, 15 Oct 2003 20:46:03 +0000, Gisle S�lensminde wrote:
>>
>>> In Santanu Chatterjee wrote:
>>
>>>> What am I missing? I want to be able to write a lisp program, compile
>>>> it, and be able to run it on some other computer where no lisp is
>>>> available.
>>
>>> Unlike C you are not compiling your programs, and then executing them.
>>> Instead you are working inside the lisp environment. When you have loaded
>>> your file into sbcl as above, you can just type
>>>
>>> (hello)
>>
>>> The fasl file is not executable by itself, it must be used together with
>>> sbcl.
>>
>> Does that mean that one cannot create executable programs using lisp,
>> which runs from the command line, the way it is done using C ??
>
> No, it means that you cannot run fasl files.
To clarify, I was denying that creation of fasl means that one cannot
run a lisp program from the command line. (grrrr, that's ambiguous, too)
You can run a lisp program from the command line like C.
You cannot run a fasl file from the command line any more than
you could run a Java class file or a C .o file.
But you *can* run a lisp program from the command line.
On Thu, 16 Oct 2003 02:02:57 +0500, "Santanu Chatterjee" <·······@softhome.net> wrote:
> Does that mean that one cannot create executable programs using
> lisp, which runs from the command line, the way it is done using C??
You can - see my other message in this thread. Also, the major
commercial Lisp compilers (AllegroCL, Corman Lisp, Digitool MCL,
Xanalys LispWorks) all have an option to do this.
Edi.
From: Alexey Dejneka
Subject: Re: How to compile a lisp file ?
Date:
Message-ID: <m3n0c1oo5n.fsf@comail.ru>
Gisle S�lensminde <·····@apal.ii.uib.no> writes:
> In SBCL you don't need to explicitly compile first, since
> all code you type or load into sbcl is compiled on the fly. In fact there
> is no interpreter in sbcl.
While SBCL really does not have an interpreter, it does not mean you
don't need to explicitly compile your code. REPL and LOAD compiler
optimizes for safety and debugability, ignoring global
declarations. And you cannot even say (COMPILE 'FOO) and expect any
speedup, because FOO is already compiled. Hopefully, in ILISP it is
just a matter of using the right key.
--
Regards,
Alexey Dejneka
"Alas, the spheres of truth are less transparent than those of
illusion." -- L.E.J. Brouwer
This thread has come up several times over the years in numerous
guises. In some, the flame wars have gotten intense, with some
calling LISP worthless because it did not provide this capability.
Things have changed, but perhaps the question can be self-answered by
ponderng the question 'what do I need to implement a program that
calls cons'
Are you saying You want to distribute your LISP code as an .EXE file
with a number of DLLS, in a manner familiar to you from your
experience with languages? I believe that CommonLispWorks provides
this capability, although I have never played with it commercially.
You can provide your users with a ".exe" file in this way.
[Disclaimer: I do not work for Xanalys, and derive no commercial
benefit from making this claim. It was true based on my experience
with an older version of the program.]
Typically what you buy is a runtime library that provides this support
and distribute it with your application. There are also commercial
systems that will compile your program to C++ and then compile *that*
against the appropriate libraries to get a 'standalone' executable.
A parallel would be - how do you distribute a database application you
develop with Access? Microsoft provides (for a fee) a module that
gives you just enough of Access to distribute your application with.
Hope that helps. I did this for a living for a few years, so I
sweated through the same questions. There is an art to making the
runtime as small as humanly possible by cutting out support for lisp
functions and packaging your program will not be calling.
At one time this was critical - Using ACL I managed to get the
standalone executable down from 4 Mb (at a time when this was
considered intolerably large for retail distribution) to a svelte 1.7
Mb. Now it seems like silly bit-twiddling.
Hope that helped.
--
Michael Tuchman
·········@alum.mit.edu
On Thu, 16 Oct 2003 03:40:48 +0000, Michael Tuchman wrote:
> This thread has come up several times over the years in numerous guises.
> In some, the flame wars have gotten intense, with some calling LISP
> worthless because it did not provide this capability.
>
> Things have changed, but perhaps the question can be self-answered by
> ponderng the question 'what do I need to implement a program that calls
> cons'
Thanks for the elaborate explanation you provided in the rest of the
reply. Also, thanks to all who responded.
Lisp seems to be a compiler (not all implementations) and an interpreter
at the same time !! Maybe this is what most tutorials mention as
incremental compilation. Things seem to done a bit differently here. I
don't know whether to like it or not ... probably I need some time and
practice to get familiar with this concept. Until then, I will try to
forget the compiler part and treat lisp as an interpreter.
Regards,
Santanu
From: ·············@comcast.net
Subject: Re: How to compile a lisp file ?
Date:
Message-ID: <d6cwwtcp.fsf@comcast.net>
"Santanu Chatterjee" <·······@softhome.net> writes:
> Thanks for the elaborate explanation you provided in the rest of the
> reply. Also, thanks to all who responded.
>
> Lisp seems to be a compiler (not all implementations) and an interpreter
> at the same time !!
Yes. One of the things we like about it.
> Maybe this is what most tutorials mention as incremental
> compilation. Things seem to done a bit differently here.
That they are.
> I don't know whether to like it or not ... probably I need some time
> and practice to get familiar with this concept.
Yes. Give it bit of time. Some of the things will appear truly
weird until you realize that you have a sticky problem and suddenly
the weird thing provides *exactly* the way out.
> Until then, I will try to forget the compiler part and treat lisp as
> an interpreter.
Treat it like an interpreter on steroids. Once you're happy with
the parts of the code that you've already debugged, just compile them:
* (defun foo (x) ...)
* (compile 'foo)
Whee! Now it runs a lot faster. You can even compile half-written
code:
* (defun foo (x)
(if (> x 100)
(handle-the-big-case x)
(dotimes (i x)
(frob something i))))
Haven't written the code for HANDLE-THE-BIG-CASE? Lisp doesn't care.
Compile it anyway. You can at least test the little cases.
Santanu Chatterjee writes:
> Lisp seems to be a compiler (not all implementations) and an interpreter
> at the same time !! Maybe this is what most tutorials mention as
Lis is interactive.
Paolo
--
Paolo Amoroso <·······@mclink.it>
"Santanu Chatterjee" <·······@softhome.net> writes:
> Now I can compile any C program using 'gcc file.c'(Debian),
> but what is the equivalent command to compile hello.lisp ?
In C, you generate a (small) main program and to do anything useful,
it dynamically loads big libraries. To run the program, you say:
gcc -o program program.c
program # (and it implicitely loads /lib/libc.6.so)
In Lisp, the main program is kept in the libraries (the lisp
environment) and you load your program as external object files. To
run the program, you say:
clisp -c program.lisp
clisp program.fas
156 hello.c
13504 hello*
1384072 /lib/libc.so.6
108 hello.lisp
283 hello.fas
1743852 /usr/local/clisp/lib/lisp.run* (clisp is just a small script
that run this lisp.run program).
The result is the same. Well, lisp.run includes the compiler and an
interpreter too, you would have to add gcc...
du -sh /usr/lib/gcc-lib/i486-suse-linux/
16M /usr/lib/gcc-lib/i486-suse-linux
In both cases, you can also statically link the libraries and your
program, giving big executable (a big lisp image) too.
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.
Pascal Bourguignon wrote:
> In Lisp, the main program is kept in the libraries (the lisp
> environment) and you load your program as external object files. To
> run the program, you say:
>
> clisp -c program.lisp
> clisp program.fas
>
> 156 hello.c
> 13504 hello*
> 1384072 /lib/libc.so.6
>
> 108 hello.lisp
> 283 hello.fas
> 1743852 /usr/local/clisp/lib/lisp.run* (clisp is just a small script
> that run this lisp.run program).
>
> The result is the same. Well, lisp.run includes the compiler and an
> interpreter too, you would have to add gcc...
>
> du -sh /usr/lib/gcc-lib/i486-suse-linux/
> 16M /usr/lib/gcc-lib/i486-suse-linux
>
> In both cases, you can also statically link the libraries and your
> program, giving big executable (a big lisp image) too.
Let's see. Given
#include <stdio.h>
int main(void)
{
puts("Hello");
return 0;
}
we get this on FreeBSD 4.8:
$ cc -O hello.c
$ size a.out
text data bss dec hex filename
1016 208 28 1252 4e4 a.out
$ cc -O -static hello.c
$ size a.out
text data bss dec hex filename
14148 440 1920 16508 407c a.out
$ du -h /usr/lib/libc.so.4 /usr/lib/libc.a
592K /usr/lib/libc.so.4
1.2M /usr/lib/libc.a
I suspect the sizes will be in the same ballpark on your Linux system.
How big would the equivalent program be using a statically linked clisp?
--
Torsten
Torsten Poulin wrote:
> Pascal Bourguignon wrote:
>
>
>>In Lisp, the main program is kept in the libraries (the lisp
>>environment) and you load your program as external object files. To
>>run the program, you say:
>>
>> clisp -c program.lisp
>> clisp program.fas
>>
>> 156 hello.c
>> 13504 hello*
>>1384072 /lib/libc.so.6
>>
>> 108 hello.lisp
>> 283 hello.fas
>>1743852 /usr/local/clisp/lib/lisp.run* (clisp is just a small script
>> that run this lisp.run program).
>>
>>The result is the same. Well, lisp.run includes the compiler and an
>>interpreter too, you would have to add gcc...
>>
>>du -sh /usr/lib/gcc-lib/i486-suse-linux/
>>16M /usr/lib/gcc-lib/i486-suse-linux
>>
>>In both cases, you can also statically link the libraries and your
>>program, giving big executable (a big lisp image) too.
>
>
> Let's see. Given
>
> #include <stdio.h>
>
> int main(void)
> {
> puts("Hello");
> return 0;
> }
>
> we get this on FreeBSD 4.8:
>
> $ cc -O hello.c
> $ size a.out
> text data bss dec hex filename
> 1016 208 28 1252 4e4 a.out
> $ cc -O -static hello.c
> $ size a.out
> text data bss dec hex filename
> 14148 440 1920 16508 407c a.out
> $ du -h /usr/lib/libc.so.4 /usr/lib/libc.a
> 592K /usr/lib/libc.so.4
> 1.2M /usr/lib/libc.a
>
> I suspect the sizes will be in the same ballpark on your Linux system.
> How big would the equivalent program be using a statically linked clisp?
>
The all-too-informative hello-world example! And what does it proove?
That you can write a small, slick and fast application in C which prints
"Hello".
Pascal wrote:
> In C, you generate a (small) main program and to do anything useful,
> it dynamically loads big libraries.
note the word *useful*.
--
Ivan Toshkov
email: ··········@last-name.org
Ivan Toshkov wrote:
> The all-too-informative hello-world example! And what does it
> proove? That you can write a small, slick and fast application
> in C which prints "Hello".
What do you assume Pascal's hello.c and hello.lisp do?
> Pascal wrote:
> > In C, you generate a (small) main program and to do anything useful,
> > it dynamically loads big libraries.
>
> note the word *useful*.
Sure, but you can do quite a lot of useful stuff with nothing
more than a few stdio functions. The Lisp equivalent of a
reasonable Unix ld would be some kind of tree shaker, of course.
--
Torsten
Torsten Poulin wrote:
> Ivan Toshkov wrote:
>
>
>>The all-too-informative hello-world example! And what does it
>>proove? That you can write a small, slick and fast application
>>in C which prints "Hello".
>
>
> What do you assume Pascal's hello.c and hello.lisp do?
>
They do the same thing, of course. But my point is, that comparing the
sizes (or execution times, for that matter) of hello-world programs
gives you very little meaningful data.
>
>>Pascal wrote:
>>
>>>In C, you generate a (small) main program and to do anything useful,
>>>it dynamically loads big libraries.
>>
>>note the word *useful*.
>
>
> Sure, but you can do quite a lot of useful stuff with nothing
> more than a few stdio functions. The Lisp equivalent of a
> reasonable Unix ld would be some kind of tree shaker, of course.
>
Ok, I guess I read "useful" as "sufficiently complicated" :)
The majority of UNIX utilities are in C and would be quite huge if you
implement every one of them as a separately compiled Common Lisp
program. In this sense Common Lisp *feels* like a OS in its own right.
It has memory manager, compiler, linker, utilities, etc. So, I guess
a fairer comparison would be between e.g. MAPCAR and sed.
--
Ivan Toshkov
email: ··········@last-name.org
From: Paul F. Dietz
Subject: Re: How to compile a lisp file ?
Date:
Message-ID: <3F8E9333.9000005@dls.net>
Ivan Toshkov wrote:
> The majority of UNIX utilities are in C and would be quite huge if you
> implement every one of them as a separately compiled Common Lisp
> program. In this sense Common Lisp *feels* like a OS in its own right.
> It has memory manager, compiler, linker, utilities, etc. So, I guess a
> fairer comparison would be between e.g. MAPCAR and sed.
>
It should be possible to implement Common Lisp so that all the builtin
stuff is in read-only space and can then be shared (or, at least, shared
with COW). This would be analogous to a small C 'hello world' executable
that depended on large shared C libraries.
Paul
Ivan Toshkov <·······@hotmail.com> writes:
> >> 156 hello.c
> >> 13504 hello*
> >>1384072 /lib/libc.so.6
> >>
> >> 108 hello.lisp
> >> 283 hello.fas
> >>1743852 /usr/local/clisp/lib/lisp.run* (clisp is just a small script
> >> that run this lisp.run program).
> The all-too-informative hello-world example! And what does it proove?
> That you can write a small, slick and fast application in C which
> prints "Hello".
My point is that in BOTH cases, you have the same order of magnitude
sizes and features, and that the only difference is where lies the
main() function. In C, it's in the small file generated, in Lisp, it's
kept in the library.
Even if you want to add in the equation the compiler, generating
native code, you compare the size of gcc and that of sbcl rather than
the size of libc and clisp, and still find the same order of magnitude.
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.
On Thu, 16 Oct 2003 06:26:48 +0200, Pascal Bourguignon wrote:
>
> "Santanu Chatterjee" <·······@softhome.net> writes:
>> Now I can compile any C program using 'gcc file.c'(Debian), but what is
>> the equivalent command to compile hello.lisp ?
>
> In C, you generate a (small) main program and to do anything useful, it
> dynamically loads big libraries. To run the program, you say:
>
> gcc -o program program.c
> program # (and it implicitely loads /lib/libc.6.so)
>
>
> In Lisp, the main program is kept in the libraries (the lisp
> environment) and you load your program as external object files. To run
> the program, you say:
>
> clisp -c program.lisp
> clisp program.fas
>
> ....[snip]...
Thanks for the explanation.
Now I think I am getting the procedure. Also, after some study
I was able to create a 'standalone executable' using sbcl,
as mentioned by Edi Weitz, but as has been already mentioned in this
thread, it turned out to be a script that calls sbcl.
Anyway, maybe I should not worry about this this thing right now, and
concentrate on learning lisp first. For the moment, I think it is
better for me to treat lisp just like another interpreter.
Regards,
Santanu
"Santanu Chatterjee" <·······@softhome.net> wrote in message news:<······························@softhome.net>...
> Thanks for the explanation.
> Now I think I am getting the procedure. Also, after some study
> I was able to create a 'standalone executable' using sbcl,
> as mentioned by Edi Weitz, but as has been already mentioned in this
> thread, it turned out to be a script that calls sbcl.
>
If you don't mind trying Scheme, there are some implemntations that
compile to C, so you can create standalone executables in a similar
manner as with C.
For example, in Bigloo:
[········@tequila grzegorz]$ cat > hello.scm
(module hello)
(print "Hello World!")
[········@tequila grzegorz]$ bigloo hello.scm
hello.scm:
[········@tequila grzegorz]$ size a.out
text data bss dec hex filename
3876 348 8 4232 1088 a.out
[········@tequila grzegorz]$ bigloo -static-bigloo hello.scm
hello.scm:
[········@tequila grzegorz]$ size a.out
text data bss dec hex filename
495695 54720 48560 598975 923bf a.out
[········@tequila grzegorz]$ ./a.out
Hello World!
The statically linked executable is biggish (543K) but can be used on
a computer with no Bigloo installed.
Cheers,
--
Grzegorz
········@pithekos.net (Grzegorz Chrupala) writes:
> "Santanu Chatterjee" <·······@softhome.net> wrote in message news:<······························@softhome.net>...
>
> > Thanks for the explanation.
> > Now I think I am getting the procedure. Also, after some study
> > I was able to create a 'standalone executable' using sbcl,
> > as mentioned by Edi Weitz, but as has been already mentioned in this
> > thread, it turned out to be a script that calls sbcl.
> >
>
> If you don't mind trying Scheme, there are some implemntations that
> compile to C, so you can create standalone executables in a similar
> manner as with C.
gcl too.
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.
Lying for having sex or lying for making war? Trust US presidents :-(
On Fri, Oct 17, 2003 at 04:12:52AM +0500, Santanu Chatterjee wrote:
> Anyway, maybe I should not worry about this this thing right now, and
> concentrate on learning lisp first. For the moment, I think it is
> better for me to treat lisp just like another interpreter.
Well, actually it probably would not be better. If you mean like
``another interpreter'' which you write files with #!env lisp or
something at the top, that would be a bad idea. You would not be taking
advantage of the interactive environment that Lisp offers, which is
generally far superior to the average ``scripting language
interpreter''. The way to go is to setup an IDE that lets you easily
edit Lisp code and then compile definitions at a keystroke, then run
your programs from the REPL. Creating an executable file is really an
issue for distribution, certainly something you're not doing right now.
Commonly used IDEs are Emacs w/ some package such as ILISP, Hemlock
which comes with CMUCL, or the various IDEs that come with the
commercial compilers, which usually have a free personal edition to try
out.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."