The last thing that keeps me from lisp is how should I do this ? There
are lot's of different lisp implementations, some of them can compile
the program into their specific bytecode, but how do I get the final
prouct? I mean is it possible to create an executable for linux,
windows or (insert your favorite OS here) without any commercial
software.
Ignas Mikalajunas
Ignas Mikalajunas wrote:
> The last thing that keeps me from lisp is how should I [distribute
programs written in Lisp]?
Then welcome aboard. :) I have used MCL and ACL to make standalone exes,
I wager Lispworks does the same. Others will fill in the gaps, but with
CMUCL and kin I gather you just do a "save image" (with it set up to
launch into your app and stay there) and distribute that.
The good news is that you are getting native machine code, not byte code
(except CLisp?).
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
Ignas Mikalajunas <······@centras.lt> wrote:
> are lot's of different lisp implementations, some of them can compile
> the program into their specific bytecode, but how do I get the final
> prouct? I mean is it possible to create an executable for linux,
> windows or (insert your favorite OS here) without any commercial
Typical *binary* distribution options include compiled sources
(fasl-files), lisp-images and standalone applications. Which of these you
pick is a factor of requirements, taste and your CL-implementation.
(The first option is actually analogous to the way Java applications tend
to be distributed.)
Fasl-files
The ANSI standard only guarantees that you can compile your sources
into an implementation dependant fasl-format. Then you can distribute
your application as a bundle of fasls, the lisp implementation, and a
loader script. The end-user only sees the loader script that fires up
the lisp and handles the behind the scenes stuff.
Lisp-image
Though not defined in the ANSI spec, pretty much all the CL
implementations provide a way to save the current lisp-image to file.
Then your distibution becomes a bundle of the image, the lisp runtime
and a loader script. The main difference to the Fasl-distribution is a
faster start-up time and a simpler loader-script.
Standalone application
Not all, but many CL implementations provide a way to create
standalone applications. The details are highly implementation specific,
but this facility is none the less provided for by both commercial and
free CL's.
Cheers,
-- Nikodemus
······@centras.lt (Ignas Mikalajunas) writes:
> The last thing that keeps me from lisp is how should I do this ?
> There are lot's of different lisp implementations, some of them can
> compile the program into their specific bytecode, but how do I get
> the final prouct?
Actually, all CL implementations I know of (except for CLISP) compile
to machine code, not to bytecode.
> I mean is it possible to create an executable for linux, windows or
> (insert your favorite OS here) without any commercial software.
AllegroCL, LispWorks, MCL, CormanLisp can do that. If that's too
"commercial" for you, try this:
<http://article.gmane.org/gmane.lisp.cmucl.devel/3029/>
Edi.
Martha Stewart called it a Good Thing whenEdi Weitz <···@agharta.de>wrote:
> ······@centras.lt (Ignas Mikalajunas) writes:
>
>> The last thing that keeps me from lisp is how should I do this ?
>> There are lot's of different lisp implementations, some of them can
>> compile the program into their specific bytecode, but how do I get
>> the final prouct?
>
> Actually, all CL implementations I know of (except for CLISP) compile
> to machine code, not to bytecode.
Hum?
You mean that the following is just a figment of my imagination?
* (compile-file "/home/cbbrowne/Lisp/lispcookie.lisp" :byte-compile t)
; Python version 1.1, VM version Intel x86 on 13 JUN 03 12:28:52 am.
; Compiling: /brownes/chvatal/home/cbbrowne/Lisp/lispcookie.lisp 15 MAY 03 07:48:57 am
; Converted QUOTIFY.
; Byte Compiling DEFUN QUOTIFY:
; Converted PROLOG-BUILD-EMAIL-ADDRESS.
; Byte Compiling DEFUN PROLOG-BUILD-EMAIL-ADDRESS:
; Converted SQL-BUILD-EMAIL-ADDRESS.
; Byte Compiling DEFUN SQL-BUILD-EMAIL-ADDRESS:
; Converted A+-BUILD-EMAIL-ADDRESS.
..
; Compilation unit finished.
; 2 errors
; 2 warnings
; 1 note
; /home/cbbrowne/Lisp/lispcookie.lbytef written.
; Compilation finished in 0:00:01.
#p"/brownes/chvatal/home/cbbrowne/Lisp/lispcookie.lbytef"
T
T
*
>> I mean is it possible to create an executable for linux, windows or
>> (insert your favorite OS here) without any commercial software.
> AllegroCL, LispWorks, MCL, CormanLisp can do that. If that's too
> "commercial" for you, try this:
> <http://article.gmane.org/gmane.lisp.cmucl.devel/3029/>
And it is important to consider that even C applications require
having a bunch of additional libraries and program loaders.
There are _very_ unusual cases where apps written in assembly language
may be "self-contained," but this is very unusual...
--
output = ("cbbrowne" ·@" "ntlug.org")
http://www3.sympatico.ca/cbbrowne/languages.html
Rules of the Evil Overlord #186. "I will not devise any scheme in
which Part A consists of tricking the hero into unwittingly helping me
and Part B consists of laughing at him then leaving him to his own
devices." <http://www.eviloverlord.com/>
From: David Steuber
Subject: Re: Distributing programms writen in lisp
Date:
Message-ID: <87of10hqtd.fsf@verizon.net>
Christopher Browne <········@acm.org> writes:
> You mean that the following is just a figment of my imagination?
Reality is an illusion. Lunch doubly so.
> And it is important to consider that even C applications require
> having a bunch of additional libraries and program loaders.
This is true. The one minor difference is that the loader for the
linked binary file is already there.
Java has the same issues (I believe this has been pointed out
before). When I first played with Java (I was evaluating it for
serious programming), I was initially impressed by the small size of
the .class files that were generated. Then along came jar so that you
didn't need to package a zillion .class files in some home grown way.
This all never got around the little problem of different JRE
implementations behaving differently in very annoying ways.
I often wonder if Unix has its own version of .dll hell. A C program
tends to be linked against particular libraries. You can hope that
the standard libraries are present on the target host. You may even
wish that defacto standard (i.e. libpng) are also present. If they
aren't, then either you have to include the libraries you used or tell
the customer to fetch, build, and install those as well, all the while
hoping that compatible compiler options are used.
Unix works best for source distribution. Debian does a good job of
package management so you can target a Debian system easily enough.
RPM also works, but not all RPM systems are Red Hat.
Windows and Mac OS X are easy to target. There is much less variation
to worry about.
I imagine the Lisp comunity hasn't bothered working towards a standard
library. That is, the equivilent of libc. That presupposes a
particular style of operating system that uses shared libraries
compiled to a particular binary format. I used to think that it would
be a good idea to do that so that code could be shared for more
efficient memory usage, disk space, etc. I've since changed my mind.
Those efficiencies would certainly be nice to have, but they also
freeze you to a standard. I don't mean a good standard like ANSI CL
which defines how the language should work. I mean a stifling
standard that defines how the language should be implemented.
C++ became popular because you could still use the existing C
libraries and whatnot. Transition from C to C++ is easy. This same
pragmatic decision for backwards compatibility has limited what C++
could have been. I imagine Java is trying to fix that but, well, I
don't think it has.
There is nothing to prevent a Lisp system from generating the boot
strap code you need to load your Lisp image into memory and kick start
it so that it looks like any other native program on the system. Even
C++ programs have been bundled in the form of a "setup.exe" on
Windows. The user need never know the difference.
Sorry for blathering on so long. I've had the exact same concerns
about distributing binaries produced by Lisp and have had ample time
to form some partly baked ideas about the entire issue of program
distribution.
--
One Editor to rule them all. One Editor to find them,
One Editor to bring them all and in the darkness bind them.
(do ((a 1 b) (b 1 (+ a b))) (nil a) (print a))
David Steuber <·············@verizon.net> writes:
>
> Windows and Mac OS X are easy to target. There is much less variation
> to worry about.
Its easy on Windows until you start having to support 3 or 4 different
versions of the OS. There are some devilish problems you can get into
with some of the system .dll's- kind of thing where installing your
program can render the host OS inoperable. The problem can generally
be avoided by making the install software sufficiently complicated.
Though Linux occasionally does have shared library problems, at least
the library version numbering is apparent and you can readily get
library dependency information from executables. On Windows some
.dll's can only be differentiated by the file timestamp- and given the
filenames are identical, there are sometimes situations where you
can't have 2 versions of the same file co-existing. Or, in recent
Windows versions you can duplicate .dll's for each installed app,
selecting the appropriate versions for each one, which is the most
classic Microsoft kludge I've seen yet. Another further difficulty in
Windows is its sometimes impossible to find out what .dll's a program
depends on, so triage becomes a matter of guesswork- or perhaps a
ouija board.
Gregm
Hi Greg.
> Another further difficulty in
> Windows is its sometimes impossible to find out what .dll's a program
> depends on, so triage becomes a matter of guesswork- or perhaps a
> ouija board.
Try Dependency Walker:
http://www.dependencywalker.com/
I reckon you'll never need your ouija board again for this particular
problem again.
Cheers
Mike Thomas.
"Mike Thomas" <······@brisbane.paradigmgeo.com> writes:
> Hi Greg.
>
> > Another further difficulty in
> > Windows is its sometimes impossible to find out what .dll's a program
> > depends on, so triage becomes a matter of guesswork- or perhaps a
> > ouija board.
>
> Try Dependency Walker:
>
> http://www.dependencywalker.com/
>
> I reckon you'll never need your ouija board again for this particular
> problem again.
>
> Cheers
>
> Mike Thomas.
I chose a better alternative, I went Windows-free. Though to be
accurate, the Necronomicon is more what you need when trying to track
down Windows .dll issues...
It does look like it will take care of at least the bigger dependency
problems. I could've really used it a few years ago...
Regards,
Gregm
On 6/16/03 19:39, in article ··············@europa.pienet, "Greg Menke"
<··········@toadmail.com> wrote:
> I chose a better alternative, I went Windows-free.
I want into your world... :)
Damond