Is it possible to compile Lisp code into a binary executable such that
one can execute it on a samiliar platform family even if they don't
have Lisp installed?
My system [Windows 98]
(lisp code) -> interpreter -> .EXE file
Friend's system [Windows XP]
.EXE will run
Friend's system [Windows 2000]
.EXE will run
or
My system [Debian GNU Linux - testing]
{lisp code) -> interpreter -> a.out file
Friend's system [Red Hat 9]
a.out will run
Friend's system [Gentoo]
a.out will run
Regards,
Zaqch
On 9 Nov 2005 10:57:38 -0800, "Zach" <······@gmail.com> wrote:
> Is it possible to compile Lisp code into a binary executable such
> that one can execute it on a samiliar platform family even if they
> don't have Lisp installed?
Yes.
<http://www.lispworks.com/documentation/lw445/DV/html/deluser.htm>
<http://www.franz.com/support/documentation/7.0/doc/delivery.htm>
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
>
> Yes.
>
> <http://www.lispworks.com/documentation/lw445/DV/html/deluser.htm>
> <http://www.franz.com/support/documentation/7.0/doc/delivery.htm>
Hallo Edi,
Ah so one needs to buy a commercial implementation such as LispWorks or
Allegro CL in order to do this it seems. Is there any effort going on
by the open source Lisp community to produce a way to do this in a
freely available Lisp implementation?
Zach
Zach wrote:
> Edi Weitz wrote:
>
>>Yes.
>>
>> <http://www.lispworks.com/documentation/lw445/DV/html/deluser.htm>
>> <http://www.franz.com/support/documentation/7.0/doc/delivery.htm>
>
>
> Hallo Edi,
>
> Ah so one needs to buy a commercial implementation such as LispWorks or
> Allegro CL in order to do this it seems. Is there any effort going on
> by the open source Lisp community to produce a way to do this in a
> freely available Lisp implementation?
There's ways to do it for CMUCL, but the executables aren't small.
They'd get smaller if you ran them through one of those programs that
makes self-expanding executables. That's UNIX only.
I think there's ways to do it for CLisp, but that's for "Free" software
only. Are you selling your work? Giving away the source code? Neither?
On Wed, 09 Nov 2005 20:12:37 +0100, Zach <······@gmail.com> wrote:
> Edi Weitz wrote:
>>
>> Yes.
>>
>> <http://www.lispworks.com/documentation/lw445/DV/html/deluser.htm>
>> <http://www.franz.com/support/documentation/7.0/doc/delivery.htm>
>
> Hallo Edi,
>
> Ah so one needs to buy a commercial implementation such as LispWorks or
> Allegro CL in order to do this it seems. Is there any effort going on
> by the open source Lisp community to produce a way to do this in a
> freely available Lisp implementation?
>
> Zach
>
Under Windows Corman Lisp has free use of the runtime and allows
the distribution of executables. http://www.cormanlisp.com/
The GUI is not free and a trial only works for a month.
However I have it running under emacs and that works fine for
me. (some of the others that have tried this seem to have problems)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Wed, 09 Nov 2005 21:26:40 +0100, "John Thingstad" <··············@chello.no> wrote:
> Under Windows Corman Lisp has free use of the runtime and allows
> the distribution of executables. http://www.cormanlisp.com/
Only for "personal, non-commercial" purposes:
<http://www.cormanlisp.com/license.html>
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
J.C. Roberts <···············@abac.com> writes:
> CLISP is undoubtedly lacking in this regard but many other open source
> implementations do produce native executables
> [...]
> SBCL
This is not true in the boring sense that most people usually mean
"native executable". It's relatively tedious to explain that "native
executable" is actually a relative term of convenience more than
anything else, but it would be remiss of me not to correct false
information.
Christophe
On Fri, 11 Nov 2005 00:06:03 +0000, Christophe Rhodes <·····@cam.ac.uk>
wrote:
>J.C. Roberts <···············@abac.com> writes:
>
>> CLISP is undoubtedly lacking in this regard but many other open source
>> implementations do produce native executables
>> [...]
>> SBCL
>
>This is not true in the boring sense that most people usually mean
>"native executable". It's relatively tedious to explain that "native
>executable" is actually a relative term of convenience more than
>anything else, but it would be remiss of me not to correct false
>information.
>
>Christophe
I'm more than a bit confused by your reply. Does the term "native
executable" means something different in the Common Lisp world than it
does in the "boring" sense used in the rest of computing?
By "native executable" I meant the typical combination of (1) an
executable file format understood by the host operating system and (2)
the executable file holds data and instructions that are understood by
the particular hardware architecture. In other words, a file that can be
executed on a particular "platform" consisting of OS and hardware.
Examples of file format would be "elf" and "a.out" for unix/linux and PE
or NX for MS-Windows.
Examples of architecture would mainly be defined by the processor used
in the arch such as x86_32, x86_64, sparc_32, sparc_64 and so on.
Many CL implementations, including CLISP, can create platform specific
and implementation dependent binaries via (compile-file ...). I listed
this type of file as #3 in a previous post. None the less, the result of
(compile-file ...) is not really a "native executable" according to the
definition above, since the OS does not understand the format and
execution is dependent on having a particular CL implementation
installed.
Could you toss me in the direction for docs to learn about this other
definition of "native executable" in the common lisp world?
Thanks,
JCR
J.C. Roberts wrote:
> Could you toss me in the direction for docs to learn about this other
> definition of "native executable" in the common lisp world?
A few questions to get you thinking:
Do you consider a shell script a native executable? Does it matter if
the shell script calls /usr/bin/python (which is not part of posix)
instead of /bin/sh (which is)?
Do you consider dynamic linking to have an effect on an executable's
nativeness? Does it matter if the dynamic linking is to libSDL (which
is not in posix) instead of libc (which is)?
Do you consider spawning other processes to have an effect on an
executable's nativeness? Does it matter if the process being spawned is
in the posix standard?
Do you consider any of the following executables native?
bash, emacs, firefox, ooffice
-- MJF
J.C. Roberts wrote:
> On Fri, 11 Nov 2005 00:06:03 +0000, Christophe Rhodes <·····@cam.ac.uk>
> wrote:
>>
>>This is not true in the boring sense that most people usually mean
>>"native executable". It's relatively tedious to explain that "native
>>executable" is actually a relative term of convenience more than
>>anything else, but it would be remiss of me not to correct false
>>information.
I really don't buy this. It's not that I don't understand your
reasoning, Christophe. I even see a little bit of validity in it. But
there's really no confusion about what people mean when they say "native
executable" and Lispers tend to try to muddy the waters because many
Lisps aren't good at making executables.
I'd suggest taking a page from the virus writers' playbook. An
executable is a single file which the computer will do the "right/wrong
thing" with even if the user is a moron incapable of following simple
instructions.
> I'm more than a bit confused by your reply. Does the term "native
> executable" means something different in the Common Lisp world than it
> does in the "boring" sense used in the rest of computing?
Done to death:
http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/27feaa0ff97cccbd
Some Lisps will, some Lisps won't, some can be made to via
user-contributed hacks, and some just can't be coerced to produce
anything rather than a bundle of files, in which case developers
typically have to resort to install wizards.
Cameron MacKinnon <··········@clearspot.net> writes:
> J.C. Roberts wrote:
>> On Fri, 11 Nov 2005 00:06:03 +0000, Christophe Rhodes <·····@cam.ac.uk>
>> wrote:
>>>
>>>This is not true in the boring sense that most people usually mean
>>>"native executable". It's relatively tedious to explain that "native
>>>executable" is actually a relative term of convenience more than
>>>anything else, but it would be remiss of me not to correct false
>>>information.
>
> I really don't buy this. It's not that I don't understand your
> reasoning, Christophe. I even see a little bit of validity in it.
How kind. I am overwhelmed by your ocular acuity.
> But there's really no confusion about what people mean when they say
> "native executable" and Lispers tend to try to muddy the waters
> because many Lisps aren't good at making executables.
Ah yes, that's what I was doing when posting a correction to false
information -- trying to muddy the waters. Next time, I'll just let
myths about lisp compilers I help to maintain go uncorrected.
> I'd suggest taking a page from the virus writers' playbook. An
> executable is a single file which the computer will do the "right/wrong
> thing" with even if the user is a moron incapable of following simple
> instructions.
So, a relative term of convenience, then, as I said in the excerpt you
quoted above? (Not to mention that I could drive a truck through your
definition, but frankly I've expended all the effort I can bear on
this issue for approximately the next ten years.)
Christophe
J.C. Roberts <···············@abac.com> writes:
> I'm more than a bit confused by your reply. Does the term "native
> executable" means something different in the Common Lisp world than it
> does in the "boring" sense used in the rest of computing?
Yes and no. :-) As I say, I think that "native executable" is a
nuanced, context-sensitive term, and...
> By "native executable" I meant the typical combination of (1) an
> executable file format understood by the host operating system and (2)
> the executable file holds data and instructions that are understood by
> the particular hardware architecture. In other words, a file that can be
> executed on a particular "platform" consisting of OS and hardware.
... that this is not the only possible definition in the rest of
computing, or rather that there exist nuances in both "OS" and
"hardware".
> Examples of file format would be "elf" and "a.out" for unix/linux and PE
> or NX for MS-Windows.
>
> Examples of architecture would mainly be defined by the processor used
> in the arch such as x86_32, x86_64, sparc_32, sparc_64 and so on.
OK, let's start here. If I give you a hypothetical x86-64/linux sbcl
image and fasls packed as an elf file, performing direct system calls
for all its Operating System interface, you would presumably agree
that this is a "native executable" by your definition. Yes? (Patches
to do more-or-less this exist out there, but they're not supported or
maintained; nevertheless, this has been done in the past, which is why
I use it as an example.)
Now, let's take away the ability to do direct system calls, and
instead say that we statically link in libc to do the system calls for
us. Still a native executable? Is it still a native executable if
you dynamically link to libc? Presumably you would say yes. I hope
you also accept that there's a continuum here, and that this continuum
can be extended in circumstances which are not too wild.
Let's explore another continuous direction. Still distributing my
sbcl image as an elf file, but loading fasls (output from
compile-file) from separate files at application startup. Ignoring
the fact that this is a little eccentric, is what I've provided a
"native executable"? (If not, how does it differ from, say,
dlopen()ing libraries at startup?) What about if I compile and load
lisp source files at startup? Is this still a "native executable"?
(If not, how does it differ from an application which reads a config
file at startup?)
Now, what about if I don't distribute my sbcl image as one elf file,
but instead as a small elf file and a separate memory image. Is this
still a "native executable"? It is native compiled code and does not
rely on a previously installed lisp, so presumably yes, but maybe you
don't think so. What if I include a #!/bin/sh script to start the
image up; is /that/ a native executable? Presumably not, though it
satisfies your (1) and (2) -- it is an executable file format
understood by the OS (shebang script execution is handled in the
kernel, and the file contains a high-level assembly language which is
understood, after interpretation, by the hardware -- in case you think
this is a stretch, be aware that "ordinary" x86-64 binary instructions
are _also_ interpreted).
So, essentially, I don't think there's an obvious point, universally
agreed on, which divides "native executable" from not-"native
executable". It depends on your point of view.
> Many CL implementations, including CLISP, can create platform specific
> and implementation dependent binaries via (compile-file ...).
No, no, clisp creates platform-independent (but
implementation-dependent: i.e. they only work with clisp) binaries.
Well, except they're not really binaries, or are they? Here is the
start of config.fas from a clisp source build:
(|SYSTEM|::|VERSION| '(20050505.))
#0Y |CHARSET|::|UTF-8|
#Y(#:|1 5 (IN-PACKAGE "EXT")-1|
#17Y(00 00 00 00 00 00 00 00 00 01 DA 31 E6 0F 01 19 01)
(|COMMON-LISP|::|T| |COMMON-LISP|::|T| |COMMON-LISP|::|T|) "EXT"
|COMMON-LISP|::|*PACKAGE*|)
Binary? Text? You decide.
> I listed this type of file as #3 in a previous post. None the less,
> the result of (compile-file ...) is not really a "native executable"
> according to the definition above, since the OS does not understand
> the format and execution is dependent on having a particular CL
> implementation installed.
OS-dependent tricks can be played, though, to make the OS understand
the format. On Windows, you can associate extensions with runtimes;
presto, the OS understands it; Linux has (or had) binfmt_misc, and so
on; and you can distribute the lisp runtime along with your
application. Is the aggregate a native executable, even if some of
the parts are not?
Christophe
On Fri, 11 Nov 2005 17:08:48 +0000, Christophe Rhodes <·····@cam.ac.uk>
wrote:
>J.C. Roberts <···············@abac.com> writes:
>
>> I'm more than a bit confused by your reply. Does the term "native
>> executable" means something different in the Common Lisp world than it
>> does in the "boring" sense used in the rest of computing?
>
>Yes and no. :-) As I say, I think that "native executable" is a
>nuanced, context-sensitive term, and...
>
;-)
>> By "native executable" I meant the typical combination of (1) an
>> executable file format understood by the host operating system and (2)
>> the executable file holds data and instructions that are understood by
>> the particular hardware architecture. In other words, a file that can be
>> executed on a particular "platform" consisting of OS and hardware.
>
>... that this is not the only possible definition in the rest of
>computing, or rather that there exist nuances in both "OS" and
>"hardware".
>
>> Examples of file format would be "elf" and "a.out" for unix/linux and PE
>> or NX for MS-Windows.
>>
>> Examples of architecture would mainly be defined by the processor used
>> in the arch such as x86_32, x86_64, sparc_32, sparc_64 and so on.
>
>OK, let's start here. If I give you a hypothetical x86-64/linux sbcl
>image and fasls packed as an elf file, performing direct system calls
>for all its Operating System interface, you would presumably agree
>that this is a "native executable" by your definition. Yes? (Patches
>to do more-or-less this exist out there, but they're not supported or
>maintained; nevertheless, this has been done in the past, which is why
>I use it as an example.)
>
>Now, let's take away the ability to do direct system calls, and
>instead say that we statically link in libc to do the system calls for
>us. Still a native executable? Is it still a native executable if
>you dynamically link to libc? Presumably you would say yes. I hope
>you also accept that there's a continuum here, and that this continuum
>can be extended in circumstances which are not too wild.
>
>Let's explore another continuous direction. Still distributing my
>sbcl image as an elf file, but loading fasls (output from
>compile-file) from separate files at application startup. Ignoring
>the fact that this is a little eccentric, is what I've provided a
>"native executable"? (If not, how does it differ from, say,
>dlopen()ing libraries at startup?) What about if I compile and load
>lisp source files at startup? Is this still a "native executable"?
>(If not, how does it differ from an application which reads a config
>file at startup?)
>
S-Exp config files! :-)
>Now, what about if I don't distribute my sbcl image as one elf file,
>but instead as a small elf file and a separate memory image. Is this
>still a "native executable"? It is native compiled code and does not
>rely on a previously installed lisp, so presumably yes, but maybe you
>don't think so. What if I include a #!/bin/sh script to start the
>image up; is /that/ a native executable? Presumably not, though it
>satisfies your (1) and (2) -- it is an executable file format
>understood by the OS (shebang script execution is handled in the
>kernel, and the file contains a high-level assembly language which is
>understood, after interpretation, by the hardware -- in case you think
>this is a stretch, be aware that "ordinary" x86-64 binary instructions
>are _also_ interpreted).
>
It's not a stretch at all. In general, the majority of modern CPU
designs actually work on their own, highly proprietary, internal
microcode. Assembly code instructions are basically an abstraction or
representation of said microcode. The method of going from microcode to
assembly instructions (or back) could be considered "interpretation" or
it could be "translation" depending on processor design, particular
microcode sequence, and, as always, semantic definitions. ;-)
>So, essentially, I don't think there's an obvious point, universally
>agreed on, which divides "native executable" from not-"native
>executable". It depends on your point of view.
>
Hmmm...
>> Many CL implementations, including CLISP, can create platform specific
>> and implementation dependent binaries via (compile-file ...).
>
>No, no, clisp creates platform-independent (but
>implementation-dependent: i.e. they only work with clisp) binaries.
>Well, except they're not really binaries, or are they? Here is the
>start of config.fas from a clisp source build:
>
>(|SYSTEM|::|VERSION| '(20050505.))
>#0Y |CHARSET|::|UTF-8|
>#Y(#:|1 5 (IN-PACKAGE "EXT")-1|
> #17Y(00 00 00 00 00 00 00 00 00 01 DA 31 E6 0F 01 19 01)
> (|COMMON-LISP|::|T| |COMMON-LISP|::|T| |COMMON-LISP|::|T|) "EXT"
> |COMMON-LISP|::|*PACKAGE*|)
>
>Binary? Text? You decide.
>
The spec says the output is supposedly "binary" but you've undoubtedly
have a point.
http://www.lisp.org/HyperSpec/Body/fun_compile-file.html#compile-file
It seems I had output of (compile-file ...) and (saveimage ...) for
CLISP (among others) confused.
Is it safe to assume (compile-file ...) will always produce some kind of
implementation specific, interpreted "bytecode" ?
Is it safe to assume (saveimage ...) or similar will always produce some
kind of memory dump of the implementation heap? -I couldn't find any
symbols/functions with the term "image" in the HyperSpec?
>> I listed this type of file as #3 in a previous post. None the less,
>> the result of (compile-file ...) is not really a "native executable"
>> according to the definition above, since the OS does not understand
>> the format and execution is dependent on having a particular CL
>> implementation installed.
>
>OS-dependent tricks can be played, though, to make the OS understand
>the format. On Windows, you can associate extensions with runtimes;
>presto, the OS understands it; Linux has (or had) binfmt_misc, and so
>on; and you can distribute the lisp runtime along with your
>application. Is the aggregate a native executable, even if some of
>the parts are not?
>
>Christophe
There are countless possible configurations tricks one could use to
start execution of a given file but I tend to think simply, namely a
default OS installation without any custom configuration tricks or
additional software (i.e. additional installed interpreters).
From what I've read in the last few weeks, it seems the most used
methods for deployment of a common lisp applications is to either
install a full common lisp implementation or install enough of an
implementation to act as an interpreter. And then handle various
launching details via custom configuration.
I want to keep things *very* simple on deployment by not requiring
configuration tricks or additional installed software (i.e a CL
implementation). In other words, an application would consist of a
single, stand-alone executable that would run on a default installation
of the operating system.
I'm thinking "HelloWorld.exe" simple.
At the moment it *seems* possible with CL, but I'm still trying to
figure out how/if it could/should be done.
JCR
J.C. Roberts wrote:
> There are countless possible configurations tricks one could use to
> start execution of a given file but I tend to think simply, namely a
> default OS installation without any custom configuration tricks or
> additional software (i.e. additional installed interpreters).
>
> From what I've read in the last few weeks, it seems the most used
> methods for deployment of a common lisp applications is to either
> install a full common lisp implementation or install enough of an
> implementation to act as an interpreter. And then handle various
> launching details via custom configuration.
>
> I want to keep things *very* simple on deployment by not requiring
> configuration tricks or additional installed software (i.e a CL
> implementation). In other words, an application would consist of a
> single, stand-alone executable that would run on a default installation
> of the operating system.
Just by the way, if one takes your requirements seriously, most programs
written for Mac OS X don't exist. They're almost all "application
bundles", which are directories full of various twiddly bits.
paul
On Fri, 11 Nov 2005 16:22:33 -0500, Paul Wallich <··@panix.com> wrote:
>J.C. Roberts wrote:
>
>> I want to keep things *very* simple on deployment by not requiring
>> configuration tricks or additional installed software (i.e a CL
>> implementation). In other words, an application would consist of a
>> single, stand-alone executable that would run on a default installation
>> of the operating system.
>
>Just by the way, if one takes your requirements seriously, most programs
>written for Mac OS X don't exist. They're almost all "application
>bundles", which are directories full of various twiddly bits.
>
>paul
In general, I think the Apple approach of putting the entire application
in single directory is rather good.
I might be wrong but I believe Pascals' adherence to the idea of
"application bundles" was also hinting at supporting the MacOS-10 way of
doing things.
Right or wrong, the high-end CAD/CAM/EDA market has very little, if any,
support for MacOS-10, so the MacOS-Way is something I can safely ignore
for the moment.
JCR
J.C. Roberts wrote:
> In general, I think the Apple approach of putting the entire application
> in single directory is rather good.
I think so too, but you rely on the host's file system for features and
performance.
The alternative is to emulate a file system inside an image. I think
Quake 3 and 4 (probably the older ones too) use huge files (.pk3 and
.pk4) for most of their resources, so I assume those contain some kind
of file system.
Of course there's nothing that prevents you from sticking such file
contents inside the .data section of an executable file. (Not sure...)
Isn't that even what Emacs does?
--
The road to hell is paved with good intentions.
Paul Wallich wrote:
> J.C. Roberts wrote:
>
>> I want to keep things *very* simple on deployment by not requiring
>> configuration tricks or additional installed software (i.e a CL
>> implementation). In other words, an application would consist of a
>> single, stand-alone executable that would run on a default installation
>> of the operating system.
>
> Just by the way, if one takes your requirements seriously, most programs
> written for Mac OS X don't exist. They're almost all "application
> bundles", which are directories full of various twiddly bits.
So does the end user get a bunch of twiddly bits which he has to install
himself, or does the bundle arrive as a single file which the OS
miraculously knows how to handle? Do Lisp tools for the Mac explain how
to create these application bundles, or is there no documentation,
leaving the developer to puzzle out for himself how to deliver his
application?
Hmm, Googling 'application bundle', there's a result on the first page:
Creating a Mac OS application bundle, from the Lisp Works 4.3 documentation.
Conclusion: Many Lisp users ask how to deliver applications in the
conventional way for their given platform. Commercial vendors have
responded with "You want it, you got it!" while others, many of whom are
otherwise friendly, helpful and knowledgable people, play some warped
combination of Twenty Questions and Eliza with those who inquire.
On Fri, 11 Nov 2005 11:32:56 -0800, J.C. Roberts <···············@abac.com> wrote:
> Is it safe to assume (compile-file ...) will always produce some
> kind of implementation specific, interpreted "bytecode" ?
For CLISP or for Common Lisp in general? For implementations like
LispWorks, AllegroCL, OpenMCL, CMUCL, SBCL, etc. that compile to
machine code COMPILE-FILE will generally /not/ compile to "bytecode"
but to a (so-called FASL) file that consists mostly of machine code
but which is implementation-specific in the sense that only the
corresponding runtime can use it - it's not a stand-alone EXE or a.out
or whatever.
> Is it safe to assume (saveimage ...) or similar will always produce
> some kind of memory dump of the implementation heap?
Again this depends on the implementation. In LispWorks SAVE-IMAGE can
create a full executable like the original compiler that you got when
you bought LW:
<http://www.lispworks.com/documentation/lw445/LWRM/html/lwref-214.htm>
> In other words, an application would consist of a single,
> stand-alone executable that would run on a default installation of
> the operating system.
>
> I'm thinking "HelloWorld.exe" simple.
>
> At the moment it *seems* possible with CL, but I'm still trying to
> figure out how/if it could/should be done.
In this very thread you have already seen pointers to CL
implementations that can produce "single, stand-alone executables" in
the sense you describe above. I wonder why you insist on spreading
the impression that it only "seems" possible. Do you think the people
who gave this information were lying?
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Fri, 11 Nov 2005 21:27:59 +0100, Edi Weitz <········@agharta.de>
wrote:
>> I'm thinking "HelloWorld.exe" simple.
>>
>> At the moment it *seems* possible with CL, but I'm still trying to
>> figure out how/if it could/should be done.
>
>In this very thread you have already seen pointers to CL
>implementations that can produce "single, stand-alone executables" in
>the sense you describe above. I wonder why you insist on spreading
>the impression that it only "seems" possible. Do you think the people
>who gave this information were lying?
No, that was not my intent at all. I'm sorry if it seemed that way. I'm
just trying to learn my way around all the variations.
Using the documentation and this group to figure out what is possible in
which implementations and with what syntax is challenging. Leaving the
functionality subject to question until proven is simply just me being
prudent while researching.
Kind Regards,
JCR
On Fri, 11 Nov 2005 12:55:56 -0800, J.C. Roberts <···············@abac.com> wrote:
> Leaving the functionality subject to question until proven is simply
> just me being prudent while researching.
So, try this one which was written in Common Lisp
<http://weitz.de/regex-coach/>
and let us know if it passes your "Hello World" test. (Note that the
installer will install a couple of files but you can throw all of them
away except for the actual EXE if you want - it'll still work.)
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Fri, 11 Nov 2005 22:03:31 +0100, Edi Weitz <········@agharta.de>
wrote:
>On Fri, 11 Nov 2005 12:55:56 -0800, J.C. Roberts <···············@abac.com> wrote:
>
>> Leaving the functionality subject to question until proven is simply
>> just me being prudent while researching.
>
>So, try this one which was written in Common Lisp
>
> <http://weitz.de/regex-coach/>
>
>and let us know if it passes your "Hello World" test. (Note that the
>installer will install a couple of files but you can throw all of them
>away except for the actual EXE if you want - it'll still work.)
>
>Cheers,
>Edi.
Beautiful! Absolutely Beautiful.
You stated in the "technical" section that Regex-Coach is using the
LispWorks CAPI. If you needed to make Regex-Coach portable between CL
implementations, what would you use in place of LispWorks CAPI?
Thank You,
JCR
On Fri, 11 Nov 2005 14:01:43 -0800, J.C. Roberts <···············@abac.com> wrote:
> You stated in the "technical" section that Regex-Coach is using the
> LispWorks CAPI. If you needed to make Regex-Coach portable between
> CL implementations, what would you use in place of LispWorks CAPI?
If you want to have something that can be used (almost) unchanged on
Windows, OS X, Linux, and several Unix variants (like CAPI) there is
no alternative that's portable between CL implementations AFAIK. I
think there isn't even something comparable for /one/ other CL
implementation. (I understand that Franz recently ported "Common
Graphics" which previously was Windows-only to Linux but that still
leaves out OS X.)
Things that are worth trying are LTK[1] and CLIM[2].
LTK should work with most major CL implementations but the user of
your app has to install Tk (or you provide an installer for it).
Also, it isn't a "pure" Lisp solution as it talks to Tk which does the
actual drawing - if that bothers you.
CLIM is available from several commercial vendors and also in an open
source variant called McCLIM and I think it is reasonably portable
because there's an independent specification for it. So I guess you
could build more or less the same app on Linux using, say,
McCLIM/SBCL, on OS X using McCLIM/OpenMCL, and on Windows using
LispWorks or AllegroCL (no McCLIM for Windows yet). The drawback is
that a typical CLIM app doesn't look very familiar and "native" to Joe
User.
Disclaimer: I haven't used LTK or CLIM in earnest, so don't take my
word for it - try for yourself.
And then there are bindings to C/C++ libraries which themselves are
portable like wxCL[3] and Idolino[4]. I know virtually nothing about
these projects.
Cheers,
Edi.
[1] <http://www.peter-herth.de/ltk/>
[2] <http://www.cliki.net/CLIM>
<http://www.lispworks.com/documentation/lw44/CLIM/html/climguide.htm>
<http://www.franz.com/support/documentation/7.0/doc/clim-ug.pdf>
<http://common-lisp.net/project/mcclim/>
[3] <http://www.wxcl-project.org/>
[4] <http://mypage.bluewin.ch/bandersnatch/>
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
J.C. Roberts <···············@abac.com> writes:
> The spec says the output is supposedly "binary" but you've undoubtedly
> have a point.
> http://www.lisp.org/HyperSpec/Body/fun_compile-file.html#compile-file
which says:
compile-file transforms the contents of the file specified by
input-file into implementation-dependent binary data [...]
The key word is implementation-dependent.
> It seems I had output of (compile-file ...) and (saveimage ...) for
> CLISP (among others) confused.
>
> Is it safe to assume (compile-file ...) will always produce some kind of
> implementation specific, interpreted "bytecode" ?
It's not safe to assume anything about implementation-dependant stuff.
> Is it safe to assume (saveimage ...) or similar will always produce some
> kind of memory dump of the implementation heap? -I couldn't find any
> symbols/functions with the term "image" in the HyperSpec?
saveimage is not a Common Lisp function. Please, read the
documentation of the implementation you use, and check the contract
you have with your vendor before assuming anything about the safety of
your assumptions.
> I want to keep things *very* simple on deployment by not requiring
> configuration tricks or additional installed software (i.e a CL
> implementation). In other words, an application would consist of a
> single, stand-alone executable that would run on a default installation
> of the operating system.
What is a "single stand-alone executable"?
You don't know what you're talking.
It's all bits!
Why should it matter how they're organized on the hard disks?
Files are only figments of our imaginations. If you put some bits in
"file a" and some other bits in "file b", what matters? They're all
embeded somewhat in the hard disk magnetic field.
Just put all the files of your "application" in a directory, and
provide the user with an clickable icon to launch it. Be it a
bootstrap binary executable, or a script, or a PIF, or whatever.
> I'm thinking "HelloWorld.exe" simple.
There's no HelloWorld.exe simple: you've got resources: icons,
background jpeg, hello-world.wav sound to be played while the Hello
World dialog shows, etc. All these files are better put in a
directory along the executable.
> At the moment it *seems* possible with CL, but I'm still trying to
> figure out how/if it could/should be done.
See: cl-launch
--
"Our users will know fear and cower before our software! Ship it!
Ship it and let them flee like the dogs they are!"
Pascal Bourguignon <····@mouse-potato.com> writes:
> What is a "single stand-alone executable"?
> You don't know what you're talking.
> It's all bits!
> Why should it matter how they're organized on the hard disks?
It matters that the program is callable from other programs using the
standard Unix/Windows interface, and that all these are acceptable:
- startup time (i.e. preferably without initializing tons of things
which are not used in the given program)
- running speed (i.e. preferably compiled to native code)
- memory consumption (i.e. preferably with sharing code between
processes, and without keeping in memory tons of things which are
not used in the given program)
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> Pascal Bourguignon <····@mouse-potato.com> writes:
>
> > What is a "single stand-alone executable"?
> > You don't know what you're talking.
> > It's all bits!
> > Why should it matter how they're organized on the hard disks?
>
> It matters that the program is callable from other programs using the
> standard Unix/Windows interface, and that all these are acceptable:
> - startup time (i.e. preferably without initializing tons of things
> which are not used in the given program)
> - running speed (i.e. preferably compiled to native code)
> - memory consumption (i.e. preferably with sharing code between
> processes, and without keeping in memory tons of things which are
> not used in the given program)
Hmmm, that would seem to eliminate things like Word, most browsers,
most RDBs, and many others. Not that it matters one way or the other...
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
J.C. Roberts wrote:
> I want to keep things *very* simple on deployment by not requiring
> configuration tricks or additional installed software (i.e a CL
> implementation). In other words, an application would consist of a
> single, stand-alone executable that would run on a default installation
> of the operating system.
>
> I'm thinking "HelloWorld.exe" simple.
>
> At the moment it *seems* possible with CL, but I'm still trying to
> figure out how/if it could/should be done.
see http://www.frank-buss.de/lisp/clisp.html , but don't use it for
production code, because currently it is experimental. Maybe it will be
included in the next stable CLISP release, if there are enough people
interested in it and when some core developers of CLISP have time to make
production quality code from my hack.
More discussions about the best way how to write native GUI applications
take place in the CL Gardeners mailing list. I'll post again in this
newsgroup when there is something more to see.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
On Thu, 29 Dec 2005 23:41:02 +0100, Frank Buss <··@frank-buss.de> tried
to confuse everyone with this message:
>J.C. Roberts wrote:
>
>> I want to keep things *very* simple on deployment by not requiring
>> configuration tricks or additional installed software (i.e a CL
>> implementation). In other words, an application would consist of a
>> single, stand-alone executable that would run on a default installation
>> of the operating system.
>>
>> I'm thinking "HelloWorld.exe" simple.
>>
>> At the moment it *seems* possible with CL, but I'm still trying to
>> figure out how/if it could/should be done.
>
>see http://www.frank-buss.de/lisp/clisp.html , but don't use it for
>production code, because currently it is experimental. Maybe it will be
>included in the next stable CLISP release, if there are enough people
>interested in it and when some core developers of CLISP have time to make
>production quality code from my hack.
Excellent! This would really work toward the acceptance of Lisp by
.exe-wanting noobs!
--
|a\o/r|,-------------.,---------- Timofei Shatrov aka Grue ------------.
| m"a ||FC AMKAR PERM|| mail: grue at mail.ru http://grue3.tripod.com |
| k || PWNZ J00 || Kingdom of Loathing: Grue3 lvl 18 Seal Clubber |
`-----'`-------------'`-------------------------------------------[4*72]
J.C. Roberts <···············@abac.com> writes:
> On Fri, 11 Nov 2005 00:06:03 +0000, Christophe Rhodes <·····@cam.ac.uk>
> wrote:
>
>>J.C. Roberts <···············@abac.com> writes:
>>
>>> CLISP is undoubtedly lacking in this regard but many other open source
>>> implementations do produce native executables
>>> [...]
>>> SBCL
>>
>>This is not true in the boring sense that most people usually mean
>>"native executable". It's relatively tedious to explain that "native
>>executable" is actually a relative term of convenience more than
>>anything else, but it would be remiss of me not to correct false
>>information.
>>
>>Christophe
>
> I'm more than a bit confused by your reply. Does the term "native
> executable" means something different in the Common Lisp world than it
> does in the "boring" sense used in the rest of computing?
>
> By "native executable" I meant the typical combination of (1) an
> executable file format understood by the host operating system and (2)
> the executable file holds data and instructions that are understood by
> the particular hardware architecture. In other words, a file that can be
> executed on a particular "platform" consisting of OS and hardware.
What are the boundaries of the OS?
If you limited the OS to the kernel, why should you limit the
platform to the OS? Is Java a platform? It's not usually the OS!
> Examples of file format would be "elf" and "a.out" for unix/linux and PE
> or NX for MS-Windows.
Neither elf nor a.out are native on Linux! Indeed, both are optional
modules! And you can add at run-time more "executable" format: you
only need to provide launchers or interpreters.
So, admit that the platform can be any compound of software and
hardware, and therefore a file containing:
-----(/usr/local/bin/hw)------------->8---
#!/usr/bin/clisp
(princ "Hello world!")
------------------------------------->8---
is a native executable on a platform containing unix and /usr/bin/clisp
> Examples of architecture would mainly be defined by the processor used
> in the arch such as x86_32, x86_64, sparc_32, sparc_64 and so on.
>
> Many CL implementations, including CLISP, can create platform specific
> and implementation dependent binaries via (compile-file ...). I listed
> this type of file as #3 in a previous post. None the less, the result of
> (compile-file ...) is not really a "native executable" according to the
> definition above, since the OS does not understand the format and
> execution is dependent on having a particular CL implementation
> installed.
Try this:
rm /usr/lib/libc.*
Then try:
/bin/ls
Is /bin/ls a native executable or is it not?
Why shouldn't my little /usr/local/bin/hw be a native executable,
while you don't destroy the platform (keep the /usr/bin/clisp library).
> Could you toss me in the direction for docs to learn about this other
> definition of "native executable" in the common lisp world?
Forget all about it. It's turtles all the way down!
A prominent scientist was once giving a public lecture on
astronomy. He described how the earth orbits around the sun, and
the sun, in turn orbits around the center of a vast collection of
stars. At the end of the lecture, a little old lady came up to him
and said, Thats rubbish. The world is really a flat plate
supported on the back of a giant turtle.
The scientist gave her a superior smile before replying. Then what
is the turtle standing on?
Another turtle, came the reply.
And that turtle? the scientist asked in exasperation.
You're very clever, young man, very clever, said the old lady. But
its turtles all the way down.
Well, what the old lady did not tell, is that the turtles on the way
down are every step smaller and faster. Now the processors are so
fast compared to the RAM, that you can consider that the instructions
of the processors are actually microcode, and the actual processor is
the VM of clisp. Actually, if you processed more data than can be
held in the cache it wouldn't make a difference if you had what you
want to call "native" instructions or if it is VM instructions: when
the processor waits for the data from the RAM, it has enough time to
run the virtual machine in the cache!
--
__Pascal Bourguignon__ http://www.informatimago.com/
Kitty like plastic.
Confuses for litter box.
Don't leave tarp around.
J.C. Roberts <···············@abac.com> writes:
> The short answer is end users don't care, so in some regards it does not
> matter if a free lisp is installed. End users just want applications to
> be simple and do the task they desire. Installing a full lisp
> environment is one approach but it seems a bit convoluted when viewed
> from the perspective of other languages. An end user would not want
> every particular version of every particular C compiler installed for
> every single application they use mainly because they have no intention
> of using the development tools in the first place.
Maybe, but they do not have any problems to install yet another
interpreter be it for Tcl/Tk, Perl, or diverse Pythons. So I'd argue
you can install a lisp also without worrying.
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
"Zach" <······@gmail.com> writes:
> Is it possible to compile Lisp code into a binary executable such that
> one can execute it on a samiliar platform family even if they don't
> have Lisp installed?
Following
http://ecls.sourceforge.net/ecldev/devel_2.html#SEC8
Section 2.6.3 it should work with ECL.
If it does work under Windows? - I don't know - as I couldn't compile
Ecl with mingw.
> Regards,
> Zaqch
okflo
--
Otto Diesenbacher ···················@gmail.com
Salzburg, Austria http://okflo.homelinux.net/
Otto Diesenbacher wrote:
> [...] I couldn't compile Ecl with mingw.
You should try again from CVS sources, as there have been a lot of
fixes lately :-)
Juanjo
Juanjo wrote:
>Otto Diesenbacher wrote:
>> [...] I couldn't compile Ecl with mingw.
>You should try again from CVS sources, as there have been a lot of
>fixes lately :-)
I forgot to mention that there's also the possibility of building ECL
with the free tools provided by Microsoft. That means: MS Visual Studio
C++ 2003 and MS Platform SDK.
My experience is that it takes way less time to build ECL using these
tools than with mingw32. However, I have not compared performance
differences, executable sizes, etc.
Juanjo
·········@gmail.com writes:
> Well, I don't know if this is a troll, but I'll bite:
>
> The best Lisp out there (IMO, of course, everything I say is just MO),
> is Bigloo. It can produce TIGHT executables on all platforms it
> supports.
>
I think they're talking about Common Lisp, not Scheme...
And bigloo is really good, I hear that It can deliver scheme code to Java byte
code classfile and native executive file, does it?
--
GnuPG Key: 0xF7C63B10
Zach <······@gmail.com> wrote:
> Is it possible to compile Lisp code into a binary executable such that
> one can execute it on a samiliar platform family even if they don't
> have Lisp installed?
[...]
> My system [Debian GNU Linux - testing]
> {lisp code) -> interpreter -> a.out file
>
> Friend's system [Red Hat 9]
> a.out will run
>
> Friend's system [Gentoo]
> a.out will run
This page http://random-state.net/log/3309245899.html
seems to explain how to get to the "make install" level.