From: Emre Sevinc
Subject: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <877jg2wkq0.fsf@ileriseviye.org>
Went around the SBCL docs and cll archive for
a while but couldn't find what I'm looking for.
I'm running SBCL on Debian GNU/Linux. What if I
want to create a binary for my latest Lisp program
to distribute to other GNU/Linux users? I don't want
to tell them "go and install SBCL runtime (or whatever)"
and after that you can run my program (it already has
Graphviz dependency, but that's ok for now). I want
to tell them "download only this binary and run it, presto!"
How can I create such a binary out of my simple
Lisp code which can run on a modern GNU/Linux
system (Debian, Red Hat, etc.)?
Thanks in advance.
--
Emre Sevinc
eMBA Software Developer Actively engaged in:
http:www.bilgi.edu.tr http://ileriseviye.org
http://www.bilgi.edu.tr http://fazlamesai.net
Cognitive Science Student http://cazci.com
http://www.cogsci.boun.edu.tr
>I'm running SBCL on Debian GNU/Linux. What if I
>want to create a binary for my latest Lisp program
>to distribute to other GNU/Linux users?
I don't believe SBCL has that option. Allegro does. If you really
wanted something like this for SBCL, you could distribute your fast
load file, an SBCL runtime, and a shell script in one big tar file.
Emre Sevinc <·····@bilgi.edu.tr> writes:
> I'm running SBCL on Debian GNU/Linux. What if I
> want to create a binary for my latest Lisp program
> to distribute to other GNU/Linux users? I don't want
See the `sb-executable' contrib module, particularly
SB-EXECUTABLE:MAKE-EXECUTABLE.
To manually do something similar, you can dump from SBCL a Lisp image
containing your application and distribute to users the `sbcl'
executable, the Lisp image, and a shell script that invokes `sbcl' and
passes it the appropriate image. You may also add an installation
script that copies all the required files to a directory.
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
From: Peter Herth
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <dajuq4$va1$03$1@news.t-online.com>
Emre Sevinc wrote:
> Went around the SBCL docs and cll archive for
> a while but couldn't find what I'm looking for.
>
> I'm running SBCL on Debian GNU/Linux. What if I
> want to create a binary for my latest Lisp program
> to distribute to other GNU/Linux users? I don't want
> to tell them "go and install SBCL runtime (or whatever)"
> and after that you can run my program (it already has
> Graphviz dependency, but that's ok for now). I want
> to tell them "download only this binary and run it, presto!"
>
> How can I create such a binary out of my simple
> Lisp code which can run on a modern GNU/Linux
> system (Debian, Red Hat, etc.)?
If you mean by a binary a single file -- that cannnot be done
with sbcl, but if you only want to have something self-contained,
then it is easy: save your own core via save-lisp-and-die
(you can specify an init function that is run automatically
when the core is loaded, that would be the main function of
your program) and then just pack the core, the runtime "sbcl"
(200k only) and a small shellscript which starts the runtime
with your custom core and you got an standallone application.
Peter
--
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
get Ltk here: http://www.peter-herth.de/ltk/
From: Emre Sevinc
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <873bqqwe1q.fsf@ileriseviye.org>
Peter Herth <·······@t-online.de> writes:
> Emre Sevinc wrote:
>> Went around the SBCL docs and cll archive for
>> a while but couldn't find what I'm looking for.
>> I'm running SBCL on Debian GNU/Linux. What if I
>> want to create a binary for my latest Lisp program
>> to distribute to other GNU/Linux users? I don't want
>> to tell them "go and install SBCL runtime (or whatever)"
>> and after that you can run my program (it already has
>> Graphviz dependency, but that's ok for now). I want
>> to tell them "download only this binary and run it, presto!"
>> How can I create such a binary out of my simple
>> Lisp code which can run on a modern GNU/Linux
>> system (Debian, Red Hat, etc.)?
>
> If you mean by a binary a single file -- that cannnot be done
> with sbcl, but if you only want to have something self-contained,
> then it is easy: save your own core via save-lisp-and-die
> (you can specify an init function that is run automatically
> when the core is loaded, that would be the main function of
> your program) and then just pack the core, the runtime "sbcl"
> (200k only) and a small shellscript which starts the runtime
> with your custom core and you got an standallone application.
Thanks for suggestion. I tried to do that and was successful to
some extent.I created a standalone-dir directory and copied
my /usr/bin/sbcl there. Then I followed the my local documentation of
SBCL and had such a file setup:
-rw-r--r-- 1 fz fz 697 Jul 7 23:10 grammar.rc.lisp
-rwxr-xr-x 1 fz fz 104632 Jul 7 23:10 sbcl
-rwxr-xr-x 1 fz fz 140 Jul 7 23:17 standalone.lisp
Now, the SBCL docs tell me something but I was not
able to duplicate it exactly. What the SBCL doc says:
===========================================================================
2.4.4.1 Unix-style Command Line Protocol
Standard Unix tools that are interpreters follow a common command
line protocol that is necessary to work with "shebang scripts".
SBCL doesn't do this by default, but adding the following snippet
to an initialization file does the trick:
;;; If the first user-processable command-line argument is a filename,
;;; disable the debugger, load the file handling shebang-line and quit.
(let ((script (and (second *posix-argv*)
(probe-file (second *posix-argv*)))))
(when script
;; Handle shebang-line
(set-dispatch-macro-character #\# #\!
(lambda (stream char arg)
(declare (ignore char arg))
(read-line stream)))
;; Disable debugger
(setf *invoke-debugger-hook*
(lambda (condition hook)
(declare (ignore hook))
;; Uncomment to get backtraces on errors
;; (sb-debug:backtrace 20)
(format *error-output* "Error: ~A~%" condition)
(quit)))
(load script)
(quit)))
Example file (hello.lisp):
#!/usr/local/bin/sbcl --noinform
(write-line "Hello, World!")
Usage examples:
$ ./hello.lisp
Hello, World!
$ sbcl hello.lisp
This is SBCL 0.8.13.70, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
Hello, World!
===========================================================================
I copy-pasted above initialization code directly into my grammar.rc.lisp
file. Then I created standalone.lisp:
#!./sbcl --noinform --userinit grammar.rc.lisp
(defvar *my-var*)
(setf *my-var* 1234)
(format t "The value of *my-var* is: ~a~%" *my-var*)
which is a very minor variation on the example provided SBCL doc's example.
OK, then I tried:
=====================================================================
/home/fz/programming/Lisp/graphviz/standalone-dir $ ./standalone.lisp
This is SBCL 0.8.20.5, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
*
====================================================================
Whoops! Not exactly what I wanted!
Gave it another try:
====================================================================
/home/fz/programming/Lisp/graphviz/standalone-dir $ ./sbcl --noinform --userinit grammar.rc.lisp standalone.lisp
The value of *my-var* is: 1234
====================================================================
Well, yes, the above is what I want but now it forces
me to write another wrapper script for the my users
so they won't have to type this long and ugly line but just
a simple command. Why do I have to do that?
Why doesn't standalone.lisp work the way SBCL it is going to?
Other questions:
Now it seems nice, a very small binary and source code including
the Lisp program does fine in a standalone fashion but
why the source code? Isn't there something like binary FASL
file? When I work within Emacs it says that it is compiling
my program to some temporary .fasl and only after that
it runs my program. Can't I use that binary .fasl file,
pass it to the sbcl binary, etc?
--
Emre Sevinc
eMBA Software Developer Actively engaged in:
http:www.bilgi.edu.tr http://ileriseviye.org
http://www.bilgi.edu.tr http://fazlamesai.net
Cognitive Science Student http://cazci.com
http://www.cogsci.boun.edu.tr
>When I work within Emacs it says that it is compiling
>my program to some temporary .fasl and only after that
>it runs my program. Can't I use that binary .fasl file,
>pass it to the sbcl binary, etc?
These two lines will create your .fasl files (not temporary):
(compile-file "grammar.rc.lisp")
(compile-file "standalone.lisp")
And here is your new invocation line:
/home/fz/programming/Lisp/graphviz/standalone-dir $ ./sbcl --noinform
--userinit grammar.rc standalone
Note how I removed the .lisp extensions in your invocation line. If you
don't give it an extension, it will first look for the .fasl fast load
file and, if it can't find that, it will use the .lisp source file
instead.
From: Emre Sevinc
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <87y88iuvto.fsf@ileriseviye.org>
"Eric Lavigne" <············@gmail.com> writes:
>>When I work within Emacs it says that it is compiling
>>my program to some temporary .fasl and only after that
>>it runs my program. Can't I use that binary .fasl file,
>>pass it to the sbcl binary, etc?
>
> These two lines will create your .fasl files (not temporary):
> (compile-file "grammar.rc.lisp")
> (compile-file "standalone.lisp")
I fired up my sbcl and tried:
··@debian:~/programming/Lisp/graphviz/standalone-dir$ sbcl
This is SBCL 0.8.20.5, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (compile-file "grammar.rc.lisp")
; compiling file "/home/fz/programming/Lisp/graphviz/standalone-dir/grammar.rc.lisp"
(written 07 JUL 2005 11:10:38 PM):
; compiling (LET (#) ...)
; /home/fz/programming/Lisp/graphviz/standalone-dir/grammar.rc.fasl written
; compilation finished in 0:00:00
#P"/home/fz/programming/Lisp/graphviz/standalone-dir/grammar.rc.fasl"
NIL
NIL
*
However it gave an error for standalone.lisp:
* (compile-file "standalone.lisp")
; compiling file "/home/fz/programming/Lisp/graphviz/standalone-dir/standalone.lisp"
(written 08 JUL 2005 12:41:17 AM):
; compilation unit aborted
; caught 1 fatal ERROR condition
compilation aborted because of fatal error:
READ failure in COMPILE-FILE:
READER-ERROR at 2 (line 1, column 2) on #<FILE-STREAM for
"file \"/home/fz/programming/Lisp/graphviz/standalone-dir/standalone.lisp\"" {905E429}>:
no dispatch function defined for #\!
; /home/fz/programming/Lisp/graphviz/standalone-dir/standalone.fasl written
; compilation finished in 0:00:00
#P"/home/fz/programming/Lisp/graphviz/standalone-dir/standalone.fasl"
T
T
*
I had 2 .fasl files in my standalone-dir/ directory but when I tried:
>
> And here is your new invocation line:
> /home/fz/programming/Lisp/graphviz/standalone-dir $ ./sbcl --noinform
> --userinit grammar.rc standalone
It gave:
fatal error before reaching READ-EVAL-PRINT loop:
The file "grammar.rc" was not found.
I gave it another try:
./sbcl --noinform --userinit grammar.rc.fasl standalone.fasl
and this one produced no output at all. Just came back to command
line instantly.
I'm a little bit surprised and confused. Why doesn't it compile
the second file? It can run the source code but complains for
producing the standalone.fasl. Also why does it say it can't
find the grammar.rc?
--
Emre Sevinc
eMBA Software Developer Actively engaged in:
http:www.bilgi.edu.tr http://ileriseviye.org
http://www.bilgi.edu.tr http://fazlamesai.net
Cognitive Science Student http://cazci.com
http://www.cogsci.boun.edu.tr
From: Emre Sevinc
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <87pstuuul2.fsf@ileriseviye.org>
Emre Sevinc <·····@bilgi.edu.tr> writes:
> "Eric Lavigne" <············@gmail.com> writes:
>
>>>When I work within Emacs it says that it is compiling
>>>my program to some temporary .fasl and only after that
>>>it runs my program. Can't I use that binary .fasl file,
>>>pass it to the sbcl binary, etc?
>>
>> These two lines will create your .fasl files (not temporary):
>> (compile-file "grammar.rc.lisp")
>> (compile-file "standalone.lisp")
UPDATE:
After removing the line:
#!./sbcl --noinform --userinit grammar.rc.lisp
I compiled it once again. Now this command line works OK:
./sbcl --noinform --userinit grammar.rc.fasl standalone.fasl
The value of *my-var* is: 1234
However, if I don't give tha .fasl extension it complains.
Aynway, at least now I can make it binary, wrap the above
command line invocation in a shell script and let the users
just type a simpler command.
However passing command line parameters to those binaries
is going to be another issue if I want to do something like:
./sbcl --noinform --userinit grammar.rc.fasl standalone.fasl -parname1 value1 -parname2 value2 ...
Any ideas about handling that as simple as possible?
--
Emre Sevinc
eMBA Software Developer Actively engaged in:
http:www.bilgi.edu.tr http://ileriseviye.org
http://www.bilgi.edu.tr http://fazlamesai.net
Cognitive Science Student http://cazci.com
http://www.cogsci.boun.edu.tr
From: Peter Herth
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <dak6kh$ilo$03$1@news.t-online.com>
Why not just save a lisp core (look for save-lisp-and-die in the sbcl
manual) and run that with
sbcl --core yourcorefile
?
Peter
--
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
get Ltk here: http://www.peter-herth.de/ltk/
From: Emre Sevinc
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <87u0j6uv0c.fsf@ileriseviye.org>
Peter Herth <·······@t-online.de> writes:
> Why not just save a lisp core (look for save-lisp-and-die in the sbcl
> manual) and run that with
> sbcl --core yourcorefile
> ?
I tried your method, I went to CL-USER> prompt and tried:
CL-USER> (save-lisp-and-die "standalone.core")
It didn't tell anything, did not return to CL-USER>
prompt and when I looked the dir. I have seen that there is
such a file.
By the way I had some errors in some buffer:
Can't purify when more than one thread exists
[undoing binding stack and other enclosing state... done]
[saving current Lisp image into /home/fz/programming/Lisp/graphviz/standalone.core:
writing 18437624 bytes from the read-only space at 0x01000000
writing 6197472 bytes from the static space at 0x05000000
writing 20611072 bytes from the dynamic space at 0x09000000
done]
Help! 11 nested errors. SB-KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
fatal error encountered in SBCL pid 9389:
%PRIMITIVE HALT called; the party is over.
The system is too badly corrupted or confused to continue at the Lisp
level. If the system had been compiled with the SB-LDB feature, we'd drop
into the LDB low-level debugger now. But there's no LDB in this build, so
we can't really do anything but just exit, sorry.
Process inferior-lisp exited abnormally with code 1
Also the standalone.core file did not produce the desired
output but it just ran SBCL and waited for me to enter
something.
Then I wanted to try again, this time removed the line:
#!./sbcl --noinform --userinit grammar.rc.lisp
from standalone.lisp, compiled it with C-c C-k
and then again:
CL-USER> (save-lisp-and-die "standalone.core")
It again produced standalone.core file, the size of the
was nearly 41 MB. Quite a file I guess. However when I tried
to run it nothing meaningful happened:
··@debian:~/programming/Lisp/graphviz/standalone-dir$ ./sbcl --core standalone.core
This is SBCL 0.8.20.5, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
*
I had to quit. What am I doing wrong? Is producing a core
file better method? It takes 41 MB of disk space and I
could not get the output of that very simple program.
What am I doing wrong?
Seems like it is quite an adventure to wrap your program
in a binary file and invoke it from the command line, I'm
a little bit confused which method is better, which one
doesn't work for why, etc.?
Maybe you Lisp meisters can enlighten me once again.
Happy hacking,
--
Emre Sevinc
eMBA Software Developer Actively engaged in:
http:www.bilgi.edu.tr http://ileriseviye.org
http://www.bilgi.edu.tr http://fazlamesai.net
Cognitive Science Student http://cazci.com
http://www.cogsci.boun.edu.tr
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <87irz7ix29.fsf@qrnik.zagroda>
Emre Sevinc <·····@bilgi.edu.tr> writes, quoting SBCL docs:
> Standard Unix tools that are interpreters follow a common command
> line protocol that is necessary to work with "shebang scripts".
> SBCL doesn't do this by default,
Why?
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
From: Christophe Rhodes
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <sqll4il0p8.fsf@cam.ac.uk>
Emre Sevinc <·····@bilgi.edu.tr> writes:
> I'm running SBCL on Debian GNU/Linux. What if I
> want to create a binary for my latest Lisp program
> to distribute to other GNU/Linux users? I don't want
> to tell them "go and install SBCL runtime (or whatever)"
> and after that you can run my program (it already has
> Graphviz dependency, but that's ok for now). I want
> to tell them "download only this binary and run it, presto!"
>
> How can I create such a binary out of my simple
> Lisp code which can run on a modern GNU/Linux
> system (Debian, Red Hat, etc.)?
You distribute the sbcl runtime yourself along with your application,
obviously.
(Or, since you mention specifically "GNU/Linux", which in practice
means Debian, you distribute a .deb which Depends on sbcl. Or,
preferably, you distribute your application as remotely-installable
source code, unless you actually have a reason not to.)
Christophe
From: Emre Sevinc
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <87ll4iurjz.fsf@ileriseviye.org>
Christophe Rhodes <·····@cam.ac.uk> writes:
> Emre Sevinc <·····@bilgi.edu.tr> writes:
>
>> I'm running SBCL on Debian GNU/Linux. What if I
>> want to create a binary for my latest Lisp program
>> to distribute to other GNU/Linux users? I don't want
>> to tell them "go and install SBCL runtime (or whatever)"
>> and after that you can run my program (it already has
>> Graphviz dependency, but that's ok for now). I want
>> to tell them "download only this binary and run it, presto!"
>>
>> How can I create such a binary out of my simple
>> Lisp code which can run on a modern GNU/Linux
>> system (Debian, Red Hat, etc.)?
>
> You distribute the sbcl runtime yourself along with your application,
> obviously.
I'm persuaded :) Since I want to stick with SBCL and don't want
to play with LispWorks and Allegro for now, distributing a
100 KB binary wouldn't hurt too much.
> (Or, since you mention specifically "GNU/Linux", which in practice
> means Debian, you distribute a .deb which Depends on sbcl. Or,
Well, if everybody on the planet used Debian (there are still
a few people who don't) I'd have no trouble in this respect.
However it seems like it's going to be the best if I make a few
different packagings, one in a .deb format, beautifully telling
Debian users about the dependencies (graphviz, sbcl, etc.) and
another not-so-beautiful .tar.gz or something like that for
other GNU/Linux users (and maybe somebody is going to help
me create packages for MS Win and Mac). I also plan to
wrap a simple web interface for my small linguistic utility
so that a Mozilla Firefox (or IE or whatever) will suffice.
> preferably, you distribute your application as remotely-installable
> source code, unless you actually have a reason not to.)
What is remotely-installable source code? I don't have the intention
to close the source of course, can you explain that concept a little
bit more?
What is it exactly and what are the advantages of remotely-installable
source code? Any URLs talking about that?
Thanks in advance.
--
Emre Sevinc
eMBA Software Developer Actively engaged in:
http:www.bilgi.edu.tr http://ileriseviye.org
http://www.bilgi.edu.tr http://fazlamesai.net
Cognitive Science Student http://cazci.com
http://www.cogsci.boun.edu.tr
From: Edi Weitz
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <ud5pu5gq1.fsf@agharta.de>
On Fri, 08 Jul 2005 02:25:52 +0300, Emre Sevinc <·····@bilgi.edu.tr> wrote:
> I'm persuaded :) Since I want to stick with SBCL and don't want to
> play with LispWorks and Allegro for now, distributing a 100 KB
> binary wouldn't hurt too much.
100 KB? That certainly won't include the SBCL runtime... :)
The smallest "stand-alone" CL binaries I've seen where done with
Corman Lisp which uses gzip to shrink the Lisp image. Still, they're
usually at least 1 MB. For SBCL, you can probably multiply this by
20 or so.
You might be interested in this, by the way:
<http://www.cs.helsinki.fi/u/jesnellm/blog/archive/2005-07-06.html>
> Well, if everybody on the planet used Debian (there are still a few
> people who don't) I'd have no trouble in this respect. However it
> seems like it's going to be the best if I make a few different
> packagings, one in a .deb format, beautifully telling Debian users
> about the dependencies (graphviz, sbcl, etc.) and another
> not-so-beautiful .tar.gz or something like that for other GNU/Linux
> users (and maybe somebody is going to help me create packages for MS
> Win and Mac).
You'll have a hard time finding someone to help you package your SBCL
app for Windows... :)
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Emre Sevinc
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <87hdf6un9d.fsf@ileriseviye.org>
Edi Weitz <········@agharta.de> writes:
> On Fri, 08 Jul 2005 02:25:52 +0300, Emre Sevinc <·····@bilgi.edu.tr> wrote:
>
>> I'm persuaded :) Since I want to stick with SBCL and don't want to
>> play with LispWorks and Allegro for now, distributing a 100 KB
>> binary wouldn't hurt too much.
>
> 100 KB? That certainly won't include the SBCL runtime... :)
Thanks for completely confusing my mind :)
If that doesn't include sbcl runtime, then what is
/usr/bin/sbcl? I copied it to a dir and it was able to
run a Lisp program. The sbcl binary executable was around
100 KB.
My other try, I mean save-lisp-and-die to produce a "core",
which was not successful produced a 41 MB binary file.
Now, can somebody have a pith on this tortured soul
and make things a bit more clear? All wanted to reach
was having a few files that can be packed to run stand alone.
What I got was two extremes as stated above. I'm totally confused.
>
> The smallest "stand-alone" CL binaries I've seen where done with
> Corman Lisp which uses gzip to shrink the Lisp image. Still, they're
> usually at least 1 MB. For SBCL, you can probably multiply this by
> 20 or so.
20 MB! Oh my god!
> You might be interested in this, by the way:
>
> <http://www.cs.helsinki.fi/u/jesnellm/blog/archive/2005-07-06.html>
>
save and die, shake and die, shake the trees, die anyway... I need
to take a breath! Too much death here. :) I need some explanations,
Dr, tell me the truth
>> Well, if everybody on the planet used Debian (there are still a few
>> people who don't) I'd have no trouble in this respect. However it
>> seems like it's going to be the best if I make a few different
>> packagings, one in a .deb format, beautifully telling Debian users
>> about the dependencies (graphviz, sbcl, etc.) and another
>> not-so-beautiful .tar.gz or something like that for other GNU/Linux
>> users (and maybe somebody is going to help me create packages for MS
>> Win and Mac).
>
> You'll have a hard time finding someone to help you package your SBCL
> app for Windows... :)
Well, for MS Win, can't somebody do it with LispWorks? Maybe I can
handle that myself. I mean like your cool RegEx Coach app which is
a Windows binary (isn't it?). But I don't know if one needs to buy licence
in order to produce and distribute such a binary on Windows.
--
Emre Sevinc
eMBA Software Developer Actively engaged in:
http:www.bilgi.edu.tr http://ileriseviye.org
http://www.bilgi.edu.tr http://fazlamesai.net
Cognitive Science Student http://cazci.com
http://www.cogsci.boun.edu.tr
From: Andy Cristina
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <Brkze.27335$FP2.23220@lakeread03>
Emre Sevinc wrote:
> Edi Weitz <········@agharta.de> writes:
>
>
>>On Fri, 08 Jul 2005 02:25:52 +0300, Emre Sevinc <·····@bilgi.edu.tr> wrote:
>>
>>
>>>I'm persuaded :) Since I want to stick with SBCL and don't want to
>>>play with LispWorks and Allegro for now, distributing a 100 KB
>>>binary wouldn't hurt too much.
>>
>>100 KB? That certainly won't include the SBCL runtime... :)
>
>
> Thanks for completely confusing my mind :)
>
> If that doesn't include sbcl runtime, then what is
> /usr/bin/sbcl? I copied it to a dir and it was able to
> run a Lisp program. The sbcl binary executable was around
> 100 KB.
>
> My other try, I mean save-lisp-and-die to produce a "core",
> which was not successful produced a 41 MB binary file.
>
The sbcl runtime consists of at least the sbcl executable and a ~20meg
lisp core file. The runtime is just the bootstrapping code; the image
is all of the lisp libraries and, if you dump your own image, your code
as well.
> ...
> 20 MB! Oh my god!
Yeah, thats what I said :-) For what its worth, clisp images are
smaller (~2 megs for the core file, and ~2.5 megs for my current
install), and clisp runs on mac, windows, linux and other unix.
> ...
>
>
>>You might be interested in this, by the way:
>>
>> <http://www.cs.helsinki.fi/u/jesnellm/blog/archive/2005-07-06.html>
>>
>
> save and die, shake and die, shake the trees, die anyway... I need
> to take a breath! Too much death here. :) I need some explanations,
> Dr, tell me the truth
>
>
save-lisp-and-die is the sbcl way to dump a core. Tree shaking is a
technique where the system tries to remove parts of the core file that
aren't going to be used. In an earlier post, you said that when you
loaded the core nothing special happened. This is likely because you
did not specify an initial function for the core file. See the SBCL
manual; I don't know offhand how to specify the function.
Andy
From: Emre Sevinc
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <87d5ptvgfu.fsf@ileriseviye.org>
Andy Cristina <·············@gmail.com> writes:
> Emre Sevinc wrote:
>> Edi Weitz <········@agharta.de> writes:
>>
>>>On Fri, 08 Jul 2005 02:25:52 +0300, Emre Sevinc <·····@bilgi.edu.tr> wrote:
>>>
>>>
>>>>I'm persuaded :) Since I want to stick with SBCL and don't want to
>>>>play with LispWorks and Allegro for now, distributing a 100 KB
>>>>binary wouldn't hurt too much.
>>>
>>>100 KB? That certainly won't include the SBCL runtime... :)
>> Thanks for completely confusing my mind :)
>> If that doesn't include sbcl runtime, then what is
>> /usr/bin/sbcl? I copied it to a dir and it was able to run a Lisp
>> program. The sbcl binary executable was around
>> 100 KB. My other try, I mean save-lisp-and-die to produce a "core",
>> which was not successful produced a 41 MB binary file.
>>
>
> The sbcl runtime consists of at least the sbcl executable and a ~20meg
> lisp core file. The runtime is just the bootstrapping code; the image
> is all of the lisp libraries and, if you dump your own image, your
> code as well.
>> ...
>> 20 MB! Oh my god!
>
> Yeah, thats what I said :-) For what its worth, clisp images are
> smaller (~2 megs for the core file, and ~2.5 megs for my current
> install), and clisp runs on mac, windows, linux and other unix.
What confuses me is, how comes that I could run that successfuly
without a core:
ls -l
-rw-r--r-- 1 fz fz 697 Jul 7 23:10 grammar.rc.lisp
-rwxr-xr-x 1 fz fz 104632 Jul 7 23:10 sbcl
-rwxr-xr-x 1 fz fz 92 Jul 8 01:03 standalone.lisp
./sbcl --noinform --userinit grammar.rc.lisp standalone.lisp
The value of *my-var* is: 1234
There is no core around but just the small sbcl binary and
my small standalone.lisp program.
After your explanations, I assume that I need a core but
then I don't understand what happened in the above example.
--
Emre Sevinc
eMBA Software Developer Actively engaged in:
http:www.bilgi.edu.tr http://ileriseviye.org
http://www.bilgi.edu.tr http://fazlamesai.net
Cognitive Science Student http://cazci.com
http://www.cogsci.boun.edu.tr
From: Bulent Murtezaoglu
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <87eka9vezk.fsf@p4.internal>
>>>>> "ES" == Emre Sevinc <·····@bilgi.edu.tr> writes:
[...]
ES> There is no core around but just the small sbcl binary and my
ES> small standalone.lisp program. [...]
Are you _sure_ "There is no core around" in your filesystem? Try
setting SBCL_HOME to your current dir and try again. This, BTW, is an
argument we use around here when people complain about 'standalone'
exe's and such -- a whole bunch of .so or .dll files preexisting on the
system are taken for granted by C apps.
cheers,
BM
From: Emre Sevinc
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <874qb5vdyk.fsf@ileriseviye.org>
Bulent Murtezaoglu <··@acm.org> writes:
>>>>>> "ES" == Emre Sevinc <·····@bilgi.edu.tr> writes:
> [...]
> ES> There is no core around but just the small sbcl binary and my
> ES> small standalone.lisp program. [...]
>
> Are you _sure_ "There is no core around" in your filesystem? Try
> setting SBCL_HOME to your current dir and try again.
So, my educated guess was correct ;-)
> This, BTW, is an
> argument we use around here when people complain about 'standalone'
> exe's and such -- a whole bunch of .so or .dll files preexisting on the
> system are taken for granted by C apps.
I think it is a simple problem of popularity/availibility and default
installation conditions. People think that way because their "normal"
"GNU/Linux"es and "Windows"es are already installed with those .so/.dll
files that those compiled C and C++ binaries depend. (Hmm maybe
we need ruthless propaganda in order to make people see installin
Lisp runtime a natural and required act just the way they see
installing basic Perl, Java runtime, etc. natural!)
Now, after all those messages, things are much more clarified for me
regarding that binary, core, etc. issues.
--
Emre Sevinc
eMBA Software Developer Actively engaged in:
http:www.bilgi.edu.tr http://ileriseviye.org
http://www.bilgi.edu.tr http://fazlamesai.net
Cognitive Science Student http://cazci.com
http://www.cogsci.boun.edu.tr
From: Edi Weitz
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <umzox95fh.fsf@agharta.de>
On Fri, 08 Jul 2005 03:58:38 +0300, Emre Sevinc <·····@bilgi.edu.tr> wrote:
> Thanks for completely confusing my mind :)
You're welcome... :)
> If that doesn't include sbcl runtime, then what is /usr/bin/sbcl? I
> copied it to a dir and it was able to run a Lisp program. The sbcl
> binary executable was around 100 KB.
See the answer of Andy Cristina - the `sbcl' binary is just a tiny
"driver" program that starts the actual Lisp image, so to say.
> My other try, I mean save-lisp-and-die to produce a "core", which
> was not successful produced a 41 MB binary file.
Yep. You either use your own core file or you use the standard core
plus fasl or source files.
> Now, can somebody have a pith on this tortured soul and make things
> a bit more clear? All wanted to reach was having a few files that
> can be packed to run stand alone. What I got was two extremes as
> stated above. I'm totally confused.
You need
a) the "driver" binary sbcl,
b) a Lisp image, either custom-made or stock,
c) fasl and/or source files for your specific app.
If your home-made core already includes all your app's code you don't
need part c). The part that'll be huge, no matter what you do, is b).
> save and die, shake and die, shake the trees, die anyway... I need
> to take a breath! Too much death here. :) I need some explanations,
> Dr, tell me the truth
Tree-shaking is "just" a technique to reduce the image size before
saving it. This is what all the commercial implementations do when
creating "executables" but so far wasn't a feature of the open source
Lisps.
> Well, for MS Win, can't somebody do it with LispWorks? Maybe I can
> handle that myself. I mean like your cool RegEx Coach app which is a
> Windows binary (isn't it?). But I don't know if one needs to buy
> licence in order to produce and distribute such a binary on Windows.
Yep, one needs a license. Definitely worth it, though.
HTH,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Emre Sevinc
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <878y0hvg8p.fsf@ileriseviye.org>
Edi Weitz <········@agharta.de> writes:
> On Fri, 08 Jul 2005 03:58:38 +0300, Emre Sevinc <·····@bilgi.edu.tr> wrote:
>
>> Thanks for completely confusing my mind :)
>
> You're welcome... :)
>
>> If that doesn't include sbcl runtime, then what is /usr/bin/sbcl? I
>> copied it to a dir and it was able to run a Lisp program. The sbcl
>> binary executable was around 100 KB.
>
> See the answer of Andy Cristina - the `sbcl' binary is just a tiny
> "driver" program that starts the actual Lisp image, so to say.
See my question to Cristina. How was I able to run that .lisp file
without having any core file in that directory (just the .lisp files
and sbcl executable). That's what confuses me.
>> My other try, I mean save-lisp-and-die to produce a "core", which
>> was not successful produced a 41 MB binary file.
>
> Yep. You either use your own core file or you use the standard core
> plus fasl or source files.
Hmm, wait a minute, do you mean that when I invoke the sbcl executable
from that standalone-dir/ of mine, it goes and finds the standard
core, runs it and then runs the .lisp files I've passed to it?
If the answer is yes to the above question then my confusion
will disappear because it means that sbcl executable binary, somehow
knows the place of the standard core (hardcoded?).
--
Emre Sevinc
eMBA Software Developer Actively engaged in:
http:www.bilgi.edu.tr http://ileriseviye.org
http://www.bilgi.edu.tr http://fazlamesai.net
Cognitive Science Student http://cazci.com
http://www.cogsci.boun.edu.tr
From: Edi Weitz
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <uslyp8sse.fsf@agharta.de>
On Fri, 08 Jul 2005 11:44:54 +0300, Emre Sevinc <·····@bilgi.edu.tr> wrote:
> Hmm, wait a minute, do you mean that when I invoke the sbcl
> executable from that standalone-dir/ of mine, it goes and finds the
> standard core, runs it and then runs the .lisp files I've passed to
> it?
Yep.
> If the answer is yes to the above question then my confusion will
> disappear because it means that sbcl executable binary, somehow
> knows the place of the standard core (hardcoded?).
Environment variable, IIRC.
See `man sbcl' and specifically the section about the `-- core'
command line option.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Fri, 08 Jul 2005 11:44:54 +0300, <·····@bilgi.edu.tr> wrote:
>
> See my question to Cristina. How was I able to run that .lisp file
> without having any core file in that directory (just the .lisp files
> and sbcl executable). That's what confuses me.
CMUCL has a built-in search path for finding a core, SBCL probably
kept that. Somewhere, a lisp core exists. If you know the name (or
basename) of core files, "find" will locate them for you. Or examine
the .deb file for details on a default core location.
--
LOOP :: a Domain Specific Language.
Emre Sevinc <·····@bilgi.edu.tr> writes:
> My other try, I mean save-lisp-and-die to produce a "core",
> which was not successful produced a 41 MB binary file.
Seems reasonable. When I dump with CMUCL a core containing McCLIM, it
is around 47 MB.
>> The smallest "stand-alone" CL binaries I've seen where done with
>> Corman Lisp which uses gzip to shrink the Lisp image. Still, they're
>> usually at least 1 MB. For SBCL, you can probably multiply this by
>> 20 or so.
>
> 20 MB! Oh my god!
It's instructive to sum the total size of your favorite Qt/GTk C/C++
application--including all libraries it relies on.
> save and die, shake and die, shake the trees, die anyway... I need
> to take a breath! Too much death here. :) I need some explanations,
> Dr, tell me the truth
With CMUCL, I use all the time the Lisp image dump procedure I
explained in another post of this thread.
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
From: Brian Downing
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <0lwze.146025$nG6.114276@attbi_s22>
In article <··············@plato.moon.paoloamoroso.it>,
Paolo Amoroso <·······@mclink.it> wrote:
> >> The smallest "stand-alone" CL binaries I've seen where done with
> >> Corman Lisp which uses gzip to shrink the Lisp image. Still, they're
> >> usually at least 1 MB. For SBCL, you can probably multiply this by
> >> 20 or so.
> >
> > 20 MB! Oh my god!
>
> It's instructive to sum the total size of your favorite Qt/GTk C/C++
> application--including all libraries it relies on.
Be sure to throw in gcc, too.
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
From: Christophe Rhodes
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <sqhdf5lnu0.fsf@cam.ac.uk>
Emre Sevinc <·····@bilgi.edu.tr> writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
>> preferably, you distribute your application as remotely-installable
>> source code, unless you actually have a reason not to.)
>
> What is remotely-installable source code? I don't have the intention
> to close the source of course, can you explain that concept a little
> bit more?
Rather than distribute your application as one monolithic binary with
all dependencies included, you could put a source tarball up on the
web, write a cliki page for your application, and then let your users
install your application themselves (and its dependencies) using
whatever lisp they already have by doing (asdf-install:install
:yourapp). This is a bit like Debian's package management, only
somewhat more decentralised: it does, however, depend on your users
being apt enough to install a lisp first.
> What is it exactly and what are the advantages of remotely-installable
> source code? Any URLs talking about that?
<http://www.cliki.net/asdf-install> has a little more information.
The advantage to you is that you don't have to deal too much with
distribution issues, such as finding hosting space and bandwidth for a
10MB-or-so tarball (although SBCL core files do end up at around 40Mb,
they compress fairly well :-); advantages to the rest of the world
include that they are not limited to platforms you the application
writer can compile for, and they don't need to download a huge binary
-- just a smallish set of sources.
Christophe
On Thu, 07 Jul 2005 21:10:31 +0300, <·····@bilgi.edu.tr> wrote:
>
> How can I create such a binary out of my simple
> Lisp code which can run on a modern GNU/Linux
> system (Debian, Red Hat, etc.)?
Look over the other suggestions, and if you really need a single file,
you can do it the old-fashioned (and apparently forgotten) way via a
shell archive. There are some modern installers (even GUI ones) that
also appear as a single file - see Linux Game Tomb for one.
However, are you only going to release a single program? If it is a
series of programs, then you probably want to bundle the lib
separately.
--
The LOOP construct is really neat, it's got a lot of knobs to turn!
Don't push the yellow one on the bottom.
Emre Sevinc wrote:
>
> I'm running SBCL on Debian GNU/Linux. What if I
> want to create a binary for my latest Lisp program
> to distribute to other GNU/Linux users? I don't want
Well, if you felt like writing some C, then you could:
1) Change the build process for the sbcl stub to include a lisp core file as
an ELF object.
2) SAVE-LISP-AND-DIE to produce said lisp core.
3) bzip -9 lisp.core (that should reduce the size a bit).
3) Modify runtime.c to extract and bunzip the lisp core from the binary into
memory (I'm assuming here that your core will fit into a reasonable space).
Libelf might be your frined here...
4) Track down everything else that does file ops on the core and modify it
suitably.
It sounds like a bigger job than I thought, but I'm sure it can be done.
I think I'll give it a try myself, actually.
Jamie
"Jamie Border" <·····@jborder.com>:
> 3) bzip -9 lisp.core (that should reduce the size a bit).
No, that will kill performance.
CMUCL and SBCL will map a core file in memory and jump all over it.
Using a technique that doesn't allow random access to the core file
will absolutely kill performance and memory usage.
There is one way to make smaller images: it's to build an image
without a compiler. While this is possible with CMUCL (I don't know
about SBCL), it breaks CLOS, which is why it's not usually done currently.
It should not be difficult to add support for CLOS-ful compiler-less
images, but nobody appears to be interested in doing so.
Juliusz
From: Christopher C. Stacy
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <u3bqprp04.fsf@news.dtpq.com>
Juliusz Chroboczek <···@pps.jussieu.fr> writes:
> There is one way to make smaller images
What is this fixation everyone has on "smaller" images?
Smaller than what? Who cares?
These are not meant as rhetorical questions.
From: James Bielman
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <m2vf3k94bn.fsf@jamesjb.com>
······@news.dtpq.com (Christopher C. Stacy) writes:
> What is this fixation everyone has on "smaller" images?
> Smaller than what? Who cares?
> These are not meant as rhetorical questions.
Speaking as someone interested in using a native-compiling Lisp on a
PDA, I think image size is important. On modern PCs, less so.
I often see people make comparisons about Lisp image sizes versus the
system libc, gcc, etc, but given the tendency of most Lisp compilers
to change FASL and image file formats often I don't think this
comparison is necessarily fair.
James
From: Christopher C. Stacy
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <ubr5cppb4.fsf@news.dtpq.com>
James Bielman <·······@jamesjb.com> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
> > What is this fixation everyone has on "smaller" images?
> > Smaller than what? Who cares?
> > These are not meant as rhetorical questions.
>
> Speaking as someone interested in using a native-compiling Lisp on a
> PDA, I think image size is important. On modern PCs, less so.
I agree that size matters on a tiny palmtop computer.
I am not sure these days what sizes are typical,
and what operating systems you are talking about.
From: Joe Marshall
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <irzlhrrm.fsf@comcast.net>
······@news.dtpq.com (Christopher C. Stacy) writes:
> Juliusz Chroboczek <···@pps.jussieu.fr> writes:
>> There is one way to make smaller images
>
> What is this fixation everyone has on "smaller" images?
> Smaller than what? Who cares?
> These are not meant as rhetorical questions.
Image envy. People want to say `Mine's smaller.'
--
~jrm
Joe Marshall <·············@comcast.net> writes:
>> What is this fixation everyone has on "smaller" images?
>> Smaller than what? Who cares?
>> These are not meant as rhetorical questions.
>
>Image envy. People want to say `Mine's smaller.'
For big programming systems, it doesn't matter but you'll have a hard
time peddling commodity utilities to people when the executables are
20+ megs in size (think of irc and messaging clients, image
previewers, desktop utilities and other "normal" sized programs, or
even the kind of stuff that populates /usr/bin.) Even though disk
space today is large, bandwidth is wide and RAM is plenty, many people
would probably object to such an obviously extremely crass waste of
resources.
A real solution would be to hoist Lisp into the age of shared
libraries so that one could have small binaries that contain only the
application logics and not the whole runtime system but that's
probably not as easy to do as with more static languages like C, Java,
etc.
mkb.
From: Christopher C. Stacy
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <ufyuoppii.fsf@news.dtpq.com>
Matthias Buelow <···@incubus.de> writes:
> Joe Marshall <·············@comcast.net> writes:
>
> >> What is this fixation everyone has on "smaller" images?
> >> Smaller than what? Who cares?
> >> These are not meant as rhetorical questions.
> >
> >Image envy. People want to say `Mine's smaller.'
>
> For big programming systems, it doesn't matter but you'll have a hard
> time peddling commodity utilities to people when the executables are
> 20+ megs in size (think of irc and messaging clients, image
> previewers, desktop utilities and other "normal" sized programs, or
> even the kind of stuff that populates /usr/bin.) Even though disk
> space today is large, bandwidth is wide and RAM is plenty, many people
> would probably object to such an obviously extremely crass waste of
> resources.
I think this is an imaginary problem.
······@news.dtpq.com (Christopher C. Stacy) writes:
>> For big programming systems, it doesn't matter but you'll have a hard
>> time peddling commodity utilities to people when the executables are
>> 20+ megs in size (think of irc and messaging clients, image
>> previewers, desktop utilities and other "normal" sized programs, or
>> even the kind of stuff that populates /usr/bin.) Even though disk
>> space today is large, bandwidth is wide and RAM is plenty, many people
>> would probably object to such an obviously extremely crass waste of
>> resources.
>
>I think this is an imaginary problem.
I think it's a problem within the Lisp community that this isn't
recognized as a problem.
mkb.
Well, to the extent that small total executable image size is an issue
(not much for most people, but a huge deal to me), you have 5 options
that I know of (on windows, anyway):
1: write in C/asm and don't use much in the way of libs
2: write in C/asm, dynamically link, and pray that your deps are
everywhere you want to be
3: VB, batch, INF, etc..
4: forth
5: lisp
on unix your options are a lot better, with perl, bash, etc.
the windows options mostly have a lot of problems
1- doable but very slow to develop in, and you reinvent a lot of wheels
2- fairly risky unless you don't include much, which leads to the same
problems as in #1
3- scripting on windows mostly blows. Not fun at all, and of course
you ship source, usually.
4- you have to write in forth. That is hard, and not all that
high-level
5-this is the way to go, if you want really small apps.
I have collected a few dozen very small lisps, from SIOD and tinyscheme
to lithp and the unnamed lisp that was entered into the obfuscated C
contest in the 80s. The smallest I could get a lisp without GC was 3K,
and tinyscheme can be compiled down pretty small-I have seen it down to
about 20K on windows. That is a rounding error on the size of most
webpages. Of course, none of these lisps are Common Lisps-most are
schemes, and some of them are truly rudimentary (no GC, for example).
On the other hand, if you are working either on a really restricted
platform, or under some other constraint, then some form of lisp/scheme
dialect is the way to go.
There is not much support for this in the community, you are right.
This specific case is not all that big a deal, though-you don't need a
bunch of implementations with a very small footprint, and there is not
all that much demand for doing embedded-style programming in lisp.
I do think that the more general problem of lisp not evolving fast
enough is a very big deal, by the way-just not here.
From: Christopher C. Stacy
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <uzmsvrxpz.fsf@news.dtpq.com>
Matthias Buelow <···@incubus.de> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
> >> For big programming systems, it doesn't matter but you'll have a hard
> >> time peddling commodity utilities to people when the executables are
> >> 20+ megs in size (think of irc and messaging clients, image
> >> previewers, desktop utilities and other "normal" sized programs, or
> >> even the kind of stuff that populates /usr/bin.) Even though disk
> >> space today is large, bandwidth is wide and RAM is plenty, many people
> >> would probably object to such an obviously extremely crass waste of
> >> resources.
> >
> >I think this is an imaginary problem.
>
> I think it's a problem within the Lisp community
> that this isn't recognized as a problem.
It's never been a problem for any of my customers.
Probably the same is true for others, or else they
would have perceived the problem and solved it.
Why don't you solve it?
On Sun, 10 Jul 2005 06:17:44 GMT, <······@news.dtpq.com> wrote:
>
> Matthias Buelow <···@incubus.de> writes:
>
>> ······@news.dtpq.com (Christopher C. Stacy) writes:
>>
>> >> For big programming systems, it doesn't matter but you'll have a hard
>> >> time peddling commodity utilities to people when the executables are
>> >> 20+ megs in size (think of irc and messaging clients, image
>> >> previewers, desktop utilities and other "normal" sized programs, or
>> >> even the kind of stuff that populates /usr/bin.) Even though disk
>> >> space today is large, bandwidth is wide and RAM is plenty, many people
>> >> would probably object to such an obviously extremely crass waste of
>> >> resources.
>> >
>> >I think this is an imaginary problem.
>>
>> I think it's a problem within the Lisp community
>> that this isn't recognized as a problem.
>
> It's never been a problem for any of my customers.
> Probably the same is true for others, or else they
> would have perceived the problem and solved it.
I thought it might be a problem once too. Lasted a few weeks to a
month while reading during initial exposure to Lisp. Nowdays it is
clearly an imaginary problem, I can hand off fasls (<<1M of xfer) and
they will work. But then I have actually done the distribution,
rather than sit and dream up problems with it. It's all about
infrastructure.
--
LOOP :: a Domain Specific Language.
Matthias Buelow <···@incubus.de> writes:
> For big programming systems, it doesn't matter but you'll have a hard
> time peddling commodity utilities to people when the executables are
> 20+ megs in size (think of irc and messaging clients, image
> previewers, desktop utilities and other "normal" sized programs, or
> even the kind of stuff that populates /usr/bin.) Even though disk
> space today is large, bandwidth is wide and RAM is plenty, many people
> would probably object to such an obviously extremely crass waste of
> resources.
Here are Joel Spolsky's opinions on bloatware:
Strategy Letter IV: Bloatware and the 80/20 Myth
http://www.joelonsoftware.com/articles/fog0000000020.html
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
From: Cameron MacKinnon
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <TqCdnTPkcatAbVLfRVn-3g@rogers.com>
Paolo Amoroso wrote:
>
> Here are Joel Spolsky's opinions on bloatware:
His company ships two products, both designed to be deployed on
servers and used via web the web. So to his ultimate end users, his
application size is zero.
--
Cameron MacKinnon
Toronto, Canada
From: Rainer Joswig
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <BEF62801.103A1%joswig@lisp.de>
Am 09.07.2005 0:20 Uhr schrieb "Matthias Buelow" unter <···@incubus.de> in
··············@drjekyll.mkbuelow.net:
> Joe Marshall <·············@comcast.net> writes:
>
>>> What is this fixation everyone has on "smaller" images?
>>> Smaller than what? Who cares?
>>> These are not meant as rhetorical questions.
>>
>> Image envy. People want to say `Mine's smaller.'
>
> For big programming systems, it doesn't matter but you'll have a hard
> time peddling commodity utilities to people when the executables are
> 20+ megs in size (think of irc and messaging clients, image
> previewers, desktop utilities and other "normal" sized programs, or
I thought that exactly some of that stuff is especially huge.
Mozilla? 44MB. Photoshop Elements is 145MB on my disk. Canon's utilities
are about 260MB. Firefox is 26MB. GarageBand and its sound libraries
literally take gigabytes on my disk. iPhoto is 160MB.
> even the kind of stuff that populates /usr/bin.) Even though disk
> space today is large, bandwidth is wide and RAM is plenty, many people
> would probably object to such an obviously extremely crass waste of
> resources.
Current software is HUGE.
A few install images on my PowerBook:
OSX Update 55MB
MS Office Update: 45 MB
LispWorks Installer 45MB
Aquamacs Installer 35MB
MySQL Installer 27.7MB
Camino Installer 21.2
Mozilla Installer 13.8
...
iTunes 11.1 MB
and so on
> A real solution would be to hoist Lisp into the age of shared
> libraries so that one could have small binaries that contain only the
> application logics and not the whole runtime system but that's
> probably not as easy to do as with more static languages like C, Java,
> etc.
Several Lisps do support shared libraries. With some you can create
your own. A good example for a space efficient Lisp is for example
Macintosh Common Lisp, it allows several ways to create deliverables.
If you have some MCL installed, you can share the base stuff
(library, compiler, ...) between your Lisp applications.
CMUCL (and its relative) have always been on the extremely big side
of things. The compiler generates huge code (which tends to run
in many benchmarks fast, but not in some real-world settings) and
it is based on a huge Lisp image. LispWorks isn't creating small
code either. But there is a tradeoff: faster code tends to be big
(lots of inlining, less branches, ...). More information in compiled
code at runtime (source files recorded, variable names, ...) makes
the code even bigger.
If you have an interesting application in CMUCL or SBCL written
for a PC running Linux or FreeBSD and it needs 20 MB on the disk,
I don't think anybody will care. My advice would be, write the
software first and then solve the distribution problem later.
>
> mkb.
Rainer Joswig <······@lisp.de> writes:
>> 20+ megs in size (think of irc and messaging clients, image
>> previewers, desktop utilities and other "normal" sized programs, or
>
>I thought that exactly some of that stuff is especially huge.
>Mozilla? 44MB. Photoshop Elements is 145MB on my disk. Canon's utilities
>are about 260MB. Firefox is 26MB. GarageBand and its sound libraries
>literally take gigabytes on my disk. iPhoto is 160MB.
These are all HUGE programs. I was deliberately talking about "normal"
sized programs and gave the example of irc and messaging clients as a
typical end-user utility (because these are a class of programs that
are in ubiquitous use but considered small utilites and hence do not
warrant huge program size).
Just for example, what I consider some (randomly selected) end-user
tools:
-r-xr-xr-x 1 root wheel 738624 May 26 19:59 /usr/X11R6/bin/gaim*
-r-xr-xr-x 1 root wheel 704604 May 26 21:41 /usr/X11R6/bin/gqview*
-r-xr-xr-x 1 root wheel 226608 May 26 19:49 /usr/X11R6/bin/gv*
-r-xr-xr-x 1 root wheel 872492 May 26 19:25 /usr/X11R6/bin/xpdf*
They are all substantial tools but none of them is nearly 20 megs in
size.
>Current software is HUGE.
>
>A few install images on my PowerBook:
>
>OSX Update 55MB
>MS Office Update: 45 MB
>LispWorks Installer 45MB
>Aquamacs Installer 35MB
>MySQL Installer 27.7MB
>Camino Installer 21.2
>Mozilla Installer 13.8
But they contain the entire software, don't they. Including all data
files. And they're all _huge_ software systems, not ordinary utility
programs. For something like M$ Office an additional 20 megs might be
nothing. For a small tool that displays postit-notes on your desktop,
it would be ridiculous.
mkb.
From: David Golden
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <i3bAe.2284$R5.96@news.indigo.ie>
Rainer's point about shared libraries is important here.
>Just for example, what I consider some (randomly selected) end-user
> tools:
> -r-xr-xr-x 1 root wheel 738624 May 26 19:59 /usr/X11R6/bin/gaim*
> -r-xr-xr-x 1 root wheel 704604 May 26 21:41 /usr/X11R6/bin/gqview*
> -r-xr-xr-x 1 root wheel 226608 May 26 19:49 /usr/X11R6/bin/gv*
> -r-xr-xr-x 1 root wheel 872492 May 26 19:25 /usr/X11R6/bin/xpdf*
They are typically dynamically linked binaries.
If you look at all the support libraries one of those applications pulls
in, it adds up quite fast.
·····@golden1:~$ ldd /usr/bin/gqview
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb7cef000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb7c6f000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb7c53000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0
(0xb7c3d000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7c1b000)
libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0
(0xb7c14000)
libpangox-1.0.so.0 => /usr/lib/libpangox-1.0.so.0 (0xb7c09000)
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb7bcf000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb7b9b000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb7b97000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7b94000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7b14000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb79df000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb7917000)
libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0xb7913000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0xb790b000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xb78fd000)
libXft.so.2 => /usr/lib/libXft.so.2 (0xb78ea000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb787d000)
libz.so.1 => /usr/lib/libz.so.1 (0xb786a000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb783b000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb7832000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb782a000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fea000)
libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0
(0xb7804000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb77e3000)
David Golden <············@oceanfree.net> writes:
>They are typically dynamically linked binaries.
>If you look at all the support libraries one of those applications pulls
>in, it adds up quite fast.
Without doubt, a Lisp program would also link against (most of) those
libraries, so that's hardly a valid argument.
mkb.
From: Christophe Rhodes
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <sqk6jylcyp.fsf@cam.ac.uk>
Matthias Buelow <···@incubus.de> writes:
> David Golden <············@oceanfree.net> writes:
>
>>They are typically dynamically linked binaries.
>>If you look at all the support libraries one of those applications pulls
>>in, it adds up quite fast.
>
> Without doubt
Perhaps you'd like to rephrase that? Not only do I doubt it, I have a
counterexample (and one is all I need).
> a Lisp program would also link against (most of) those libraries, so
> that's hardly a valid argument.
It is true that no standard has emerged for sharable delivery of lisp
over all platforms and all implementations. However, you vastly
overstate your case here.
Christophe
Christophe Rhodes <·····@cam.ac.uk> writes:
>>>They are typically dynamically linked binaries.
>>>If you look at all the support libraries one of those applications pulls
>>>in, it adds up quite fast.
>> Without doubt
>
>Perhaps you'd like to rephrase that? Not only do I doubt it, I have a
>counterexample (and one is all I need).
>
>> a Lisp program would also link against (most of) those libraries, so
>> that's hardly a valid argument.
>
>It is true that no standard has emerged for sharable delivery of lisp
>over all platforms and all implementations. However, you vastly
>overstate your case here.
Why? Cells-GTK is using GTK. Other GUI programs would want to use
either: Gtk, Qt or Motif (on X11), or the Win32 GUI widgets on
Windows, same for MacOS with Aqua. That would include the bulk of
linked-in libraries that we're talking about (see the ldd output from
the gqview program that David Golden posted, where 20 of the 26 shared
objects are part of either Gtk or X11). In general, other libraries
(SSL, etc.) would also be linked in.
Where's the counter-example? You haven't posted it. Besides, one
counter-example wouldn't serve you since the conjecture I made is
about existence, not universality. For me, one example of a Lisp
program that would link in all those libraries would suffice. It is
trivial to construct a Lisp program that does NOT use these libraries
but that is hardly interesting.
mkb.
From: Christophe Rhodes
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <sqfyuml4cv.fsf@cam.ac.uk>
Matthias Buelow <···@incubus.de> writes:
> Where's the counter-example? You haven't posted it.
It should be relatively simple for you to find graphical interface
programs with my name in them which have minimal system library
support, not that that's a particularly interesting thing to examine.
(I think this whole discussion is a hydra: in the process of setting
right one misguided opinion, two others spawn. To be specific, I do
not think either that large core files or large numbers of shared
library dependencies are serious barriers in the way of getting things
done, and I wish people would actually go and try to do things rather
than complain endlessly that some facet of the Universe isn't arranged
precisely to their liking.)
> Besides, one counter-example wouldn't serve you since the conjecture
> I made is about existence, not universality.
I appreciate your native language may not be English, but "Without
doubt a Lisp program would also link against (most of) these
libraries" is a universal assertion, not an existential conjecture.[*]
I'm happy to accept that Lisp programs linking against those graphical
toolkits will link against those graphical toolkit libraries; I
dispute the notion that all graphical Lisp programs must do so.
Christophe
[*] "Without doubt" is a very bad translation of "sans doute": the
French means something similar to "maybe" or "probably", while the
English means "certainly". Might there be a similar confusion going
on here?
From: Cameron MacKinnon
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <Xd-dnVOCjLzTMUzfRVn-pQ@rogers.com>
Christophe Rhodes wrote:
> (I think this whole discussion is a hydra: in the process of setting
> right one misguided opinion, two others spawn. To be specific, I do
> not think either that large core files or large numbers of shared
> library dependencies are serious barriers in the way of getting things
> done, and I wish people would actually go and try to do things rather
> than complain endlessly that some facet of the Universe isn't arranged
> precisely to their liking.)
As to large core files: You are entitled to your opinion, but it becomes
more difficult to defend month by month. There is a continuous trickle
in c.l.l of apparently distinct newbies who think that large core file
sizes (relative to functionality delivered, and to application sizes in
other implementation languages) are a problem. The larger that number,
the more difficult to defend is your assertion that they're all wrong.
Basically, you're asserting that they're irrational in caring about
something which you feel should be universally inconsequential. That's
plausible when your opponents numbers are small, but as they get bigger,
you're defending an increasingly implausible position -- that everyone
else (in a self selecting group of those who are investigating Lisp,
which I will assume to be smarter than the average programmer) is crazy.
Also, there's a few other arguments against your position: Historically,
Lisps have had "tree shakers" and other means to remove unaffordable
bloat from images, dating back to Lisp 1.5. Presumably you're not going
to cast aspersions on that user/implementor community, too? And today,
the range in image sizes between different Lisps on the same
architecture, and with approximately the same feasture set, is 10:1. Do
the larger Lisps gain a tenfold improvement in speed? In functionality?
Threefold, perhaps? Is all that extra size required for those increases?
--
Cameron MacKinnon
Toronto, Canada
From: Edi Weitz
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <uoe9agrit.fsf@agharta.de>
On Sun, 10 Jul 2005 19:16:29 -0400, Cameron MacKinnon <··········@clearspot.net> wrote:
> Historically, Lisps have had "tree shakers" and other means to
> remove unaffordable bloat from images, dating back to Lisp
> 1.5. Presumably you're not going to cast aspersions on that
> user/implementor community, too?
Good point. AFAIK all the commercial Lisps provide ways to create the
dreaded "stand-alone" executables and include tree shakers or other
means to reduce the size of these files. LispWorks, e.g., even comes
with a "Delivery User Guide" (100+ pages) that discusses several
strategies to obtain a small Lisp image.
To me this clearly shows that there's a market for "small" Lisp apps
because otherwise the vendors wouldn't bother to offer these features
- repeated utterance of other opinions on c.l.l notwithstanding.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Christopher C. Stacy
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <uirzi6rbj.fsf@news.dtpq.com>
Edi Weitz <········@agharta.de> writes:
> On Sun, 10 Jul 2005 19:16:29 -0400, Cameron MacKinnon <··········@clearspot.net> wrote:
>
> > Historically, Lisps have had "tree shakers" and other means
>
> To me this clearly shows that there's a market for "small" Lisp apps
> because otherwise the vendors wouldn't bother to offer these features
> - repeated utterance of other opinions on c.l.l notwithstanding.
Maybe those features were put in place when it used to be important?
From: Edi Weitz
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <umzotvj2g.fsf@agharta.de>
On Mon, 11 Jul 2005 01:53:51 GMT, ······@news.dtpq.com (Christopher C. Stacy) wrote:
> Edi Weitz <········@agharta.de> writes:
>
>> On Sun, 10 Jul 2005 19:16:29 -0400, Cameron MacKinnon <··········@clearspot.net> wrote:
>>
>> > Historically, Lisps have had "tree shakers" and other means
>>
>> To me this clearly shows that there's a market for "small" Lisp
>> apps because otherwise the vendors wouldn't bother to offer these
>> features - repeated utterance of other opinions on c.l.l
>> notwithstanding.
>
> Maybe those features were put in place when it used to be important?
My laptop has 1.5GB of RAM and a 60GB hard disk so I certainly don't
care much about the size of executables as long as they're provided on
CD. However, nobody has addressed what Bulent has written and I'm in
the same situation - I use LispWorks to write Windows executables and
I send prototypes to my clients every now and then, sometimes several
times a day. A compressed executable created with the highest
delivery settings (smallest image size) still takes my customer about
two or three minutes to download from my ASDL line.
And I'm glad that it's only three minutes. If my Lisp images were ten
times as big I wouldn't want to tell them that the thirty minute
download they're experiencing used to be important a long time ago...
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Christophe Rhodes
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <sqwtnxhgro.fsf@cam.ac.uk>
Edi Weitz <········@agharta.de> writes:
> A compressed executable created with the highest
> delivery settings (smallest image size) still takes my customer about
> two or three minutes to download from my ASDL line.
I recognize the cheek of this question; nevertheless: is there an
analogy to be made here between not paying for business bandwidth and
not paying for a commercial Lisp?
> And I'm glad that it's only three minutes. If my Lisp images were
> ten times as big I wouldn't want to tell them that the thirty minute
> download they're experiencing used to be important a long time
> ago...
Delivering fasls seems likely to be a better bet than delivering whole
images, but maybe your Lisp's licence prohibits you from doing so.
Christophe
From: Edi Weitz
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <uirzhvhp9.fsf@agharta.de>
On Mon, 11 Jul 2005 09:46:19 +0100, Christophe Rhodes <·····@cam.ac.uk> wrote:
> Edi Weitz <········@agharta.de> writes:
>
>> A compressed executable created with the highest delivery settings
>> (smallest image size) still takes my customer about two or three
>> minutes to download from my ASDL line.
>
> I recognize the cheek of this question; nevertheless: is there an
> analogy to be made here between not paying for business bandwidth
> and not paying for a commercial Lisp?
Sure. But I already pay for business bandwidth. This is a "business
contract" offered by Deutsche Telekom which includes fixed IP numbers
and costs me approx. 250 Euro per month. The last time I asked a line
with similar features and significantly higher upstream speed was
almost three times more expensive.[1] That's almost the price of one
LispWorks license per month. Not a good comparison, IMHO, but maybe
you're just making much more money than me... :)
And, as I said, with compressed images that went through a tree-shaker
for me the situation is OK although not great.
> Delivering fasls seems likely to be a better bet than delivering
> whole images, but maybe your Lisp's licence prohibits you from doing
> so.
License-wise it'd be OK but it's (a bit) more work and if I deliver
EXEs I can always be sure that the customer is really checking what I
want him to check. If my Lisp images were 30MB or bigger I'd probably
send FASL files as well.
Cheers,
Edi.
[1] I can get cheaper SDSL lines but not with fixed IP numbers which I
need for certain things.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> License-wise it'd be OK but it's (a bit) more work and if I deliver
> EXEs I can always be sure that the customer is really checking what I
> want him to check. If my Lisp images were 30MB or bigger I'd probably
> send FASL files as well.
Or compress them. The flip side of SBCL's 24.6 MB core is that it
compresses quite well: on the Sun I'm sitting at, bzip gives me a file
less than 25% the size of the uncompressed core (5.9 MB). Still not
tiny, but it's a lot more reasonable to send over the wire.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Edi Weitz <········@agharta.de> writes:
>Sure. But I already pay for business bandwidth. This is a "business
>contract" offered by Deutsche Telekom which includes fixed IP numbers
>and costs me approx. 250 Euro per month. The last time I asked a line
>with similar features and significantly higher upstream speed was
>almost three times more expensive.[1] That's almost the price of one
>LispWorks license per month. Not a good comparison, IMHO, but maybe
>you're just making much more money than me... :)
Hmm, why don't you get a (relatively inexpensive) hosting provider and
lease a root server? You can upload stuff to it in your own time and
customers have full download bandwidth (reasonable offers have 1000gb
or more included monthly volume, that would probably be enough). Price
is typically around 80 EUR for a Linux/FreeBSD PC machine (more for
Sun etc.)
mkb.
From: Edi Weitz
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <ueka5vfre.fsf@agharta.de>
On Mon, 11 Jul 2005 11:14:41 +0200, Matthias Buelow <···@incubus.de> wrote:
> Hmm, why don't you get a (relatively inexpensive) hosting provider
> and lease a root server? You can upload stuff to it in your own time
> and customers have full download bandwidth (reasonable offers have
> 1000gb or more included monthly volume, that would probably be
> enough). Price is typically around 80 EUR for a Linux/FreeBSD PC
> machine (more for Sun etc.)
I already have two root servers. Uploading files to these root
servers still takes the same time, though. ("Oh, yeah, that's a bug.
But it's easy to fix, that'll take me ten seconds. No, wait, er, make
that one hour - I'll have to upload the EXE to my root server
first...")
Let me repeat: The current situation is OK for me - it could be better
but I see no easy (and inexpensive) way to change it. I just wanted
to argue against the common c.l.l wisdom that image size exists only
in the imagination of ditzy newbies.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Ulrich Hobelmann
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <3jetctFp7idrU2@individual.net>
Christophe Rhodes wrote:
> Delivering fasls seems likely to be a better bet than delivering whole
> images, but maybe your Lisp's licence prohibits you from doing so.
But it feels a bit like delivering .o files, when you really want
to deliver an executable file, stripped of all symbols.
Also, fasls aren't even standardized between implementations,
though that's not really a problem. But it means you can't just
put up a fasl on your website for download.
--
By claiming a patent [...], I'm saying that you are not permitted
to use your own knowledge to further your ends. By what right?
Roderick T. Long
Edi Weitz <········@agharta.de> writes:
> On Sun, 10 Jul 2005 19:16:29 -0400, Cameron MacKinnon <··········@clearspot.net> wrote:
>
>
> Good point. AFAIK all the commercial Lisps provide ways to create the
> dreaded "stand-alone" executables and include tree shakers or other
> means to reduce the size of these files. LispWorks, e.g., even comes
> with a "Delivery User Guide" (100+ pages) that discusses several
> strategies to obtain a small Lisp image.
>
> To me this clearly shows that there's a market for "small" Lisp apps
> because otherwise the vendors wouldn't bother to offer these features
> - repeated utterance of other opinions on c.l.l notwithstanding.
>
Hmm. I'm not sure that existence of a feature is in itself
justification for an argument that uses that feature. For example, the
existance of features within commercial lisp implementations which
allow you to create "tight/small" images may simply be a remnant of an
earlier time when portable media was mor restrictive and download
speeds were much slower - I still remember having to break up software
onto multiple floppy disks to distribute it.
This is not to say the feature isn't sometimes convenient, just that
its existance in commercial implementations does not automatically
represent a failing/flaw in implementations which don't have it.
Tim
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
From: Christophe Rhodes
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <sq7jfxluqd.fsf@cam.ac.uk>
Cameron MacKinnon <··········@clearspot.net> writes:
> Christophe Rhodes wrote:
>> (I think this whole discussion is a hydra: in the process of setting
>> right one misguided opinion, two others spawn. To be specific, I do
>> not think either that large core files or large numbers of shared
>> library dependencies are serious barriers in the way of getting things
>> done, and I wish people would actually go and try to do things rather
>> than complain endlessly that some facet of the Universe isn't arranged
>> precisely to their liking.)
>
> As to large core files: You are entitled to your opinion, but it
> becomes more difficult to defend month by month. There is a continuous
> trickle in c.l.l of apparently distinct newbies who think that large
> core file sizes (relative to functionality delivered, and to
> application sizes in other implementation languages) are a
> problem.
Oh, I'd agree that it's a small problem, in that (all other things
being equal) it is better to offer a smaller download, take up less
disk space, and fit on a smaller sized USB storage device. As I say,
however, I don't think that it's a serious barrier in the way of doing
stuff, and I don't think that any number of newbies with largely
uninformed opinions is a serious meta-argument against this position.
> The larger that number, the more difficult to defend is your
> assertion that they're all wrong. Basically, you're asserting that
> they're irrational in caring about something which you feel should be
> universally inconsequential. That's plausible when your opponents
> numbers are small, but as they get bigger, you're defending an
> increasingly implausible position -- that everyone else (in a self
> selecting group of those who are investigating Lisp, which I will
> assume to be smarter than the average programmer) is crazy.
Not "crazy", though "irrational" is reasonable: my observation is that
very few people seem to think about their use case before making
shopping lists of requirements which boil down to what they're already
familiar with. I wouldn't want to defend your assumption that Lisp
investigators are smarter than others, either; I think that's an
extremely dangerous and arrogant attitude.
> Also, there's a few other arguments against your position:
> Historically, Lisps have had "tree shakers" and other means to remove
> unaffordable bloat from images, dating back to Lisp 1.5. Presumably
> you're not going to cast aspersions on that user/implementor
> community, too?
This is a reasonable point, but I think that a tree shaker or similar
was historically more important than it is now: core file size
empirically grows roughly linearly (from
<http://sbcl.boinkor.net/bench/index.html#CORE-FILE-SIZE>, at about
1Mb/year); over the time over which that growth has taken place, there
has been a upwards step discontinuity in a parochial "typical"
download bandwidth, and exponential growth in disk space.
> And today, the range in image sizes between different Lisps on the
> same architecture, and with approximately the same feasture set, is
> 10:1. Do the larger Lisps gain a tenfold improvement in speed? In
> functionality? Threefold, perhaps? Is all that extra size required
> for those increases?
There can easily be a tenfold difference in speed between smallest and
largest lisps, though not for all benchmarks and I wouldn't want to
plot a straight line between those two points.
Christophe
Cameron MacKinnon <··········@clearspot.net> writes:
> As to large core files: You are entitled to your opinion, but it
> becomes more difficult to defend month by month. There is a
> continuous trickle in c.l.l of apparently distinct newbies who think
> that large core file sizes (relative to functionality delivered, and
> to application sizes in other implementation languages) are a
> problem.
I'm sure they do _think_ it is a problem. Indeed, it may even be a
problem in that there may be a psychological problem wrt it vis-a-vis
your potential end users. Technically and economically, it is no
longer a problem at all. It is entirely plausible that it may take
awhile before this sinks in.
OTOH, maybe not, as huge numbers of people (both developers and users)
don't seem to care about this when it comes to Java. Unless you're
targetting only 1.0 functionality, you pretty much have to bundle a
JRE with your Java application. IME, you simply can't rely on the
customers specific platform for deployment to have a) the correct
version, b) the correct vendor's implementation, c) the correct
implementation version, and d) the correct configuration. If you want
this stuff to be plug-and-play you really need to bundle the JRE you
know works for the platform in question with your application. As I'm
sure you know a JRE is around 35MB. IME, customers don't care about
this at all - they care that the damn thing just works out of the box.
> The larger that number, the more difficult to defend is your
> assertion that they're all wrong. Basically, you're asserting that
> they're irrational in caring about something which you feel should be
> universally inconsequential.
No, I think the issue is that there is no technical or econmic issue
for the user and thus there is no "real" problem. I suppose you may
run up against a psychological problem wrt this still. OTOH, my guess
is that this psychological problem largely rests with these
_developers_, not their potential customers. Customers not only don't
seem to care anymore, they don't even seem to know one way or the
other. It's totally meaningless. What they care about is if: "I can
plug this thing in, push a button and it just works".
> Also, there's a few other arguments against your position:
> Historically, Lisps have had "tree shakers" and other means to remove
> unaffordable bloat from images, dating back to Lisp 1.5.
Historically, you didn't have $300.00 Dell's with 500GB of storage
available at the local Staples and/or KMart.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
From: Alan Shutko
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <873bqlckpl.fsf@vera.springies.com>
jayessay <······@foo.com> writes:
> If you want this stuff to be plug-and-play you really need to bundle
> the JRE you know works for the platform in question with your
> application. As I'm sure you know a JRE is around 35MB.
As a data point, my work machine seems to have 40 JREs installed.
Yes, that's insane, but that's the way it is. (True, it is a java
development box, but I only installed two or three of those
myself... the rest came bundled.)
--
Alan Shutko <···@acm.org> - I am the rocks.
Amoebas need no excuse.
Christophe Rhodes <·····@cam.ac.uk> writes:
>I'm happy to accept that Lisp programs linking against those graphical
>toolkits will link against those graphical toolkit libraries; I
>dispute the notion that all graphical Lisp programs must do so.
Let's cut this down a bit.
The sequence of reasoning was as following:
* Rainer Joswig named a couple (large) programs to show that, what he
apparently sees as commodity utilities, are actually large (Office,
Mozilla, Photoshop, ...).
* I've presented some examples of nontrivial programs that had a
rather small executable size, to show what I mean by typical
"utility programs".
* Then David Golden came around telling me that all these programs linked
against dynamic libraries, for example with gqview and Gtk. As I
understand it, what he wants to say by this is that one should take
the entire loaded program size (including mapped shared objects) and
not just the executable size, and compare this against the CMUCL 20+MB
image.
* I responded that Lisp programs would also link against those libraries,
and hence his argument was invalid. Of course I meant Lisp programs
that use Gtk, X11, etc. I mean, it's obvious. Of course one could
write a Lisp program that communicates directly with the X server,
without toolkit or even X-lib. The same holds for C programs. If at
all, one could only take libc (and perhaps libm, if used) for direct
comparison, since they are the ones implementing the C runtime. But
afaik, the Lisps on Unix also use libc, at least for communicating
with the OS.
mkb.
From: Christophe Rhodes
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <sqbr5al2ja.fsf@cam.ac.uk>
Matthias Buelow <···@incubus.de> writes:
> * I responded that Lisp programs would also link against those
> libraries, and hence his argument was invalid. Of course I meant
> Lisp programs that use Gtk, X11, etc. I mean, it's obvious.
Thank you for the clarification. (It's still not true unless it's a
tautology; I do not need any shared libraries beyond libc -- and
libsocket on Solaris -- to put a window on the screen).
> Of course one could write a Lisp program that communicates
> directly with the X server, without toolkit or even X-lib.
I'm glad you recognize the possibility, but it's not just "one could",
but "one does". Garnet, CLUE, and McCLIM are all Lisp toolkits which
do not rely on system libraries to put graphics on the screen, at
least in their X backends: they talk the X Windows protocol directly
to the X server. (This means that they rely on an X server when
talking to an X server, so that's an additional huge dependency, but
it's not one you would find through inspecting lists of dynamic
linking information :-)
Christophe
Christophe Rhodes <·····@cam.ac.uk> writes:
>I'm glad you recognize the possibility, but it's not just "one could",
>but "one does". Garnet, CLUE, and McCLIM are all Lisp toolkits which
>do not rely on system libraries to put graphics on the screen, at
>least in their X backends: they talk the X Windows protocol directly
>to the X server. (This means that they rely on an X server when
Well, Garnet has been superseded 10 years ago by Amulet, which is a
C++ toolkit (and probably out of use aswell, at least I've never seen
a program that uses that), I've never heard about CLUE and I've never
seen a program using McCLIM either. Despite the existence of such
niche things, what if I _want_ to use Gtk (or Qt)? IMHO it's more
beneficial for both programmer and user to use some kind of "standard"
toolkit than to cook your own, potentially superior one that noone
else uses. There has been some convergence towards Gtk and Qt[1] in
the last years (from Motif, a dozen Xaw-based hacks, Tcl/Tk, fltk,
xforms, xview/OLIT, and homebrewn stuff) and, while I don't in
particular like either Gtk nor Qt, it's not a bad thing that people
now focus on these toolkits, giving X11 users finally something of a
more predictable GUI. Any GUI programmer would probably be well
advised to chose one of the more common toolkits that users are
already familiar with and which they can configure like the rest of
their applications.
Of course that does not apply to all people. I'm happy with the half
dozen or so different toolkits that are currently displaying stuff on
my desktop but the typical end user is quite irritated by such a chaos.
mkb.
[1] And Java of course, which may or may not use "native" Widgets
under the hood..
Christophe Rhodes <·····@cam.ac.uk> writes:
> Matthias Buelow <···@incubus.de> writes:
>
> > Where's the counter-example? You haven't posted it.
>
> It should be relatively simple for you to find graphical interface
> programs with my name in them which have minimal system library
> support, not that that's a particularly interesting thing to examine.
>
> (I think this whole discussion is a hydra: in the process of setting
> right one misguided opinion, two others spawn. To be specific, I do
> not think either that large core files or large numbers of shared
> library dependencies are serious barriers in the way of getting things
> done, and I wish people would actually go and try to do things rather
> than complain endlessly that some facet of the Universe isn't arranged
> precisely to their liking.)
>
> > Besides, one counter-example wouldn't serve you since the conjecture
> > I made is about existence, not universality.
>
> I appreciate your native language may not be English, but "Without
> doubt a Lisp program would also link against (most of) these
> libraries" is a universal assertion, not an existential conjecture.[*]
> I'm happy to accept that Lisp programs linking against those graphical
> toolkits will link against those graphical toolkit libraries; I
> dispute the notion that all graphical Lisp programs must do so.
>
Going back to the original argument concerning (the possibly
non-problem) of distributing lisp programs in a straight forward
manner - I tend to agree with some who have argued this isnt a real
problem, but possibly a percieved non-problem.
These days, its extremely rare to have any software which actually
does something that
1. doesn't consist of multiple files
2. doesn't link with and require specific shared libraries.
I would go as far as to say that in many cases, the main motivation
for releasing only a binary is more about protection of intellectual
property by not releasing the source code than about ease of
installation. While its important to have a straight-forward
installation, its not that hard to automate the process. If the
omstallation has some form of installer, then it really doesn't matter
how many different files there are or what type or location they get
stored in.
As an example, look at a commercial application like the Opera web
browser. It runs on multiple platforms, has a free versiona nd a
non-free version. If you want to download it, you choose your platform
- Linux, Windows, etc. You then choose the version (Debian, Red Hat,
Windows 2000, XP etc) and then download the appropriate binary. Some
of the distributions are dynamically linked and others are staticly
linked with the graphics library it uses (in this case, I think its
Qt for Linux - not sure about other platforms).
The distribution consists of many files and a few shared
libraries. Installation is a simple as running the installer for that
platform - the user really doesn't need to know about anything and in
fact, many users wouldn't even know where it is installed or what
files it contains.
I cannot see why the same principal cannot be applied to lisp
programs. The installers on these platforms don't care if they are
installing code, binaries, images etc - its just data files. All that
is required is for the author to create the packages. While this takes
some initial work - mainly in getting familiar with the various
installation programs, its no big deal and is just what you have to do
if you want others to use your software on a specific platform. If
anything, it will probably reduce issues and support enquiries as most
package managers/installers are able to verify certain dependencies
are met.
Having said all of that, in some ways I have to contradict myself at
one level and confirm what I'm saying at another. I'm running Debian
with a lot of diffeent CL packages and 3 different CL
implementations. All of these have been installed with a simple
apt-get install <package name>. My contradiction here (or perhaps what
some would call "out of my ..." is because I'm actaully very
unfamiliar with what is involved in installing a new CL package or
program. Confirmation of what I'm saying is the fact that I am able to
run and use many diffeent CL packages and programs and write my own
which uses varous packages without needing any real knowledge about
how all of this is installed and managed.
Tim
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
From: Ulrich Hobelmann
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <3jetjuFp0j7aU1@individual.net>
Tim X wrote:
> These days, its extremely rare to have any software which actually
> does something that
> 1. doesn't consist of multiple files
> 2. doesn't link with and require specific shared libraries.
>
> I would go as far as to say that in many cases, the main motivation
> for releasing only a binary is more about protection of intellectual
> property by not releasing the source code than about ease of
> installation. While its important to have a straight-forward
> installation, its not that hard to automate the process. If the
> omstallation has some form of installer, then it really doesn't matter
> how many different files there are or what type or location they get
> stored in.
Well, on the Mac an application bundles all files, and it looks
like one file to the user. I imagine it wouldn't be too hard to
bundle images etc. into the .data part of a C executable. It IS
about ease of installation, if you do it right.
The way it's mostly done on Linux hardly qualifies for good usability.
> The distribution consists of many files and a few shared
> libraries. Installation is a simple as running the installer for that
> platform - the user really doesn't need to know about anything and in
> fact, many users wouldn't even know where it is installed or what
> files it contains.
They used to have one version with Qt statically linked in, and
one version for people who have Qt installed.
--
By claiming a patent [...], I'm saying that you are not permitted
to use your own knowledge to further your ends. By what right?
Roderick T. Long
Ulrich Hobelmann <···········@web.de> writes:
>
> The way it's mostly done on Linux hardly qualifies for good usability.
>
I don't agree. All the major Linux distributions have extremely usable
package management these days. While ther is a lot of open source
distributions which still rely on the config, make and make install
style of installation, this is not a short fall of Linux, rather a
failure of people to make their distributions available using these
packaging systems - its no different than with software for Windows
(or the Mac) if you want to install it and its not in that platforms
installation package/format. The commercial OS platforms certainly had
usable package management systems before Linux, but on the Windows
platform at least, you needed it as installation was/is often a lot
morre difficult than Linux.
The real issue here is in getting people, especailly people
distributing open source apps, to use the available package
systems. To some extent, there some resistance in the open source
community to provding apps in a packaged format - partially due to the
number of idfferent formats (though most of the main ones are now
supported under multiple platforms) and possibly some arrogance in
that there seems to be an attitude that if you cannot install it from
sources, you shouldn't be running it.
All the commercial software I've installed on Linux has had a very
straight forward installation - usually its either in deb or rpm
format or has a simple script you run - sometimes with a few prompts
for info relating to configuration.
Tim
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
From: Edi Weitz
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <u64vgwjac.fsf@agharta.de>
On 12 Jul 2005 17:47:19 +1000, Tim X <····@spamto.devnul.com> wrote:
> All the commercial software I've installed on Linux has had a very
> straight forward installation - usually its either in deb or rpm
> format or has a simple script you run - sometimes with a few prompts
> for info relating to configuration.
Funny, I've never seen that. I've never seen commercial software in
deb format at all. And the packages that I saw that were in rpm
format were for Red Hat and didn't work with my SuSE system at that
time. My personal summary for commercial software on Linux is that it
hardly ever works without tweaking the installation. (Yes, there are
exceptions, I know.)
I'm used to SuSE and Debian, though. YMMV if you use Red Hat.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On 12 Jul 2005 17:47:19 +1000, Tim X <····@spamto.devnul.com> wrote:
>
>> All the commercial software I've installed on Linux has had a very
>> straight forward installation - usually its either in deb or rpm
>> format or has a simple script you run - sometimes with a few prompts
>> for info relating to configuration.
>
> Funny, I've never seen that.
The Java Development kit for example is delivered as RPM and self
extracting shell script:
http://java.sun.com/j2se/1.5.0/download.jsp
I've installed it on some Linux systems (RedHat, SuSE and Debian) and it
was never a problem, just starting the script and extending the PATH to the
bin directory and you are done.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Edi Weitz
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <uu0j0v1v0.fsf@agharta.de>
On Tue, 12 Jul 2005 10:35:15 +0200, Frank Buss <··@frank-buss.de> wrote:
> The Java Development kit for example is delivered as RPM and self
> extracting shell script:
>
> http://java.sun.com/j2se/1.5.0/download.jsp
>
> I've installed it on some Linux systems (RedHat, SuSE and Debian)
> and it was never a problem, just starting the script and extending
> the PATH to the bin directory and you are done.
So, now it's installed on your machine but it's most likely not really
integrated with your system, or is it? For example, here are the
steps that used to be necessary to "really" install Java (1.4.x) on
Debian Woody:
<http://wiki.osuosl.org/display/DEV/Java+on+Debian>
Anyway, I don't want to discuss the details of specific packages or
Linux distros. As I said in the part of my message that you snipped:
"Yes, there are exceptions, I know."
And while I wrote this I knew that half a dozen people were going to
post their counter-examples anyway...
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> So, now it's installed on your machine but it's most likely not really
> integrated with your system, or is it? For example, here are the
> steps that used to be necessary to "really" install Java (1.4.x) on
> Debian Woody:
>
> <http://wiki.osuosl.org/display/DEV/Java+on+Debian>
yes, you are right, the Java installer doesn't care about to integrate
itself in the system the Unix way, for example it is not available in
/usr/bin, but this was never a problem for me, I just extended the PATH in
/etc/profile and in init.d-scripts. But if a program installs itself in
/usr/bin, libraries in /usr/lib and configs in /etc, it could be as easy as
installing a program for Windows.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Bulent Murtezaoglu
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <87slyktodr.fsf@p4.internal>
>>>>> "EW" == Edi Weitz <········@agharta.de> writes:
EW> On 12 Jul 2005 17:47:19 +1000, Tim X <····@spamto.devnul.com>
EW> wrote:
>> All the commercial software I've installed on Linux has had a
>> very straight forward installation - usually its either in deb
>> or rpm format or has a simple script you run - sometimes with a
>> few prompts for info relating to configuration.
EW> Funny, I've never seen that. I've never seen commercial
EW> software in deb format at all. [...]
I don't recall seeing any in _pure_ deb either, but Lispworks
Professional, and I believe Allegro (for-money version dunno what they
call it) had/have .deb installers that did/do the right thing. You
install the .deb and it asks where your tarball or CD is, and installs
the package from the vendor-provided kind of package taking care to show
you screens you say yes to and enter serial numbers into etc. It'd
even go get patches for you. Very smooth.
(the last Lispworks upgrade I ended up doing manually using Lispworks'
scripts to /usr/local for reasons I don't remember. That's why I am
typing the did/do kind of awkwardness.)
cheers,
BM
From: Edi Weitz
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <u1x64wgug.fsf@agharta.de>
On Tue, 12 Jul 2005 11:33:20 +0300, Bulent Murtezaoglu <··@acm.org> wrote:
> I don't recall seeing any in _pure_ deb either, but Lispworks
> Professional, and I believe Allegro (for-money version dunno what
> they call it) had/have .deb installers that did/do the right thing.
> You install the .deb and it asks where your tarball or CD is, and
> installs the package from the vendor-provided kind of package taking
> care to show you screens you say yes to and enter serial numbers
> into etc. It'd even go get patches for you. Very smooth.
I'm pretty sure you're confusing some things here. I've had Linux
licenses for LW since 4.2 or so and I never saw a .deb distributed by
Xanalys/LispWorks. Just checked and there isn't a .deb on my 4.4.5
CD.
What you've most likely seen is the LispWorks Debian installer which
was created by Kevin Rosenberg. (And he did something similar for
AllegroCL IIRC.) Quite nice, yep, I've also used it. But based on
the private initiative of one person. And now that Kevin has given up
maintenance of a lot of Debian packages the LW package seems to be
gone anyway.
Also, from the LispWorks website[1]:
"LispWorks for Linux supports Redhat Linux (versions 6 through 9) on
Pentium-compatible CPU. Also Mandrake and SuSE Linux with kernel
2.2 or later on Pentium-compatible CPU."
That's not exactly a commercial software that comes with an easy .deb
installation... :)
Cheers,
Edi.
[1] <http://www.lispworks.com/support/system-requirements.html#lwl>
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Bulent Murtezaoglu
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <87ll4ctm4d.fsf@p4.internal>
>>>>> "EW" == Edi Weitz <········@agharta.de> writes:
EW> On Tue, 12 Jul 2005 11:33:20 +0300, Bulent Murtezaoglu
EW> <··@acm.org> wrote:
>> I don't recall seeing any in _pure_ deb either, but Lispworks
>> Professional, and I believe Allegro (for-money version dunno
>> what they call it) had/have .deb installers that did/do the
>> right thing. You install the .deb and it asks where your
>> tarball or CD is, and installs the package from the
>> vendor-provided kind of package taking care to show you screens
>> you say yes to and enter serial numbers into etc. It'd even go
>> get patches for you. Very smooth.
EW> I'm pretty sure you're confusing some things here. I've had
EW> Linux licenses for LW since 4.2 or so and I never saw a .deb
EW> distributed by Xanalys/LispWorks. Just checked and there
EW> isn't a .deb on my 4.4.5 CD.
I am not, but I am perhaps obscuring the fact that Xanalys/LispWorks
was/is not the source of the said .deb. Sorry about that. I was
trying respond about what I thought was the broader issue.
EW> What you've most likely seen is the LispWorks Debian installer
EW> which was created by Kevin Rosenberg. (And he did something
EW> similar for AllegroCL IIRC.) Quite nice, yep, I've also used
EW> it. But based on the private initiative of one person. And
EW> now that Kevin has given up maintenance of a lot of Debian
EW> packages the LW package seems to be gone anyway.
This is indeed correct, and prolly why I didn't use the .deb installer
for the 4.4.x series.
EW> Also, from the LispWorks website[1]:
EW> "LispWorks for Linux supports Redhat Linux (versions 6
EW> through 9) on Pentium-compatible CPU. Also Mandrake and SuSE
EW> Linux with kernel 2.2 or later on Pentium-compatible CPU."
EW> That's not exactly a commercial software that comes with an
EW> easy .deb installation... :)
Yeah, point taken. I can see their point too, Lispworks is being
understandably conservative. I wonder if they know how many of us use
their system on Debian though. I never told them myself (but was never
asked either) and they had no occasion to find out through a "doesn't
work for my preferred platform" kind of complaint. Anyway, we both know
where to talk about that (lisp-hug, also accessible through gmane as
gmane.lisp.lispworks.general).
cheers,
BM
From: Edi Weitz
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <ull4cuzph.fsf@agharta.de>
On Tue, 12 Jul 2005 12:22:10 +0300, Bulent Murtezaoglu <··@acm.org> wrote:
> Yeah, point taken. I can see their point too, Lispworks is being
> understandably conservative.
Yep. I wasn't intending to criticize LispWorks. It seems most
commercial software vendors eschew Debian - probably because it's kind
of a moving target and because there's not really a "vendor" they can
negotiate with. ISTR that Bruce Perens (?) tried to create a Linux
distro based on Debian that lends itself better to commercial
deployment but I forgot the details.
> I wonder if they know how many of us use their system on Debian
> though.
Probably not. There was a "which distro do you use" poll on the Franz
website recently, though. I think Debian more or less "won."
> I never told them myself (but was never asked either) and they had
> no occasion to find out through a "doesn't work for my preferred
> platform" kind of complaint. Anyway, we both know where to talk
> about that (lisp-hug, also accessible through gmane as
> gmane.lisp.lispworks.general).
Well, as long as it works there's no need to complain. Same here.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On 2005-07-12 05:43:22 -0400, Edi Weitz <········@agharta.de> said:
> On Tue, 12 Jul 2005 12:22:10 +0300, Bulent Murtezaoglu <··@acm.org> wrote:
>
>> Yeah, point taken. I can see their point too, Lispworks is being
>> understandably conservative.
>
> Yep. I wasn't intending to criticize LispWorks. It seems most
> commercial software vendors eschew Debian - probably because it's kind
> of a moving target and because there's not really a "vendor" they can
> negotiate with. ISTR that Bruce Perens (?) tried to create a Linux
> distro based on Debian that lends itself better to commercial
> deployment but I forgot the details.
That was (pretty sure it's sunk) Progeny Linux. For a newer, more
up-to-date (six month releases is the goal, I believe) distro based on
.debs, you might want to check out Ubuntu Linux:
<http://www.ubuntulinux.org/>
Zac
From: Edi Weitz
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <ud5poav5w.fsf@agharta.de>
On Tue, 12 Jul 2005 15:12:45 GMT, Zachery Bir <····@urbanape.com> wrote:
> On 2005-07-12 05:43:22 -0400, Edi Weitz <········@agharta.de> said:
>
>> It seems most commercial software vendors eschew Debian - probably
>> because it's kind of a moving target and because there's not really
>> a "vendor" they can negotiate with. ISTR that Bruce Perens (?)
>> tried to create a Linux distro based on Debian that lends itself
>> better to commercial deployment but I forgot the details.
>
> That was (pretty sure it's sunk) Progeny Linux.
No. I meant this one:
<http://www.userlinux.com/>
Progeny was done by Debian founder Ian Murdoch not by Perens.
> For a newer, more up-to-date (six month releases is the goal, I
> believe) distro based on .debs, you might want to check out Ubuntu
> Linux:
>
> <http://www.ubuntulinux.org/>
Their focus is different. There are a lot of Debian-based distros and
Ubuntu seems to be pretty fashionable at the moment. I was talking
about something aimed at businesses, though - competing with products
like Red Hat Enterprise and the corresponding SuSE thingy.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Ulrich Hobelmann
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <3jhchmFq4sojU1@individual.net>
Tim X wrote:
> Ulrich Hobelmann <···········@web.de> writes:
>
>
>>The way it's mostly done on Linux hardly qualifies for good usability.
>>
>
> I don't agree. All the major Linux distributions have extremely usable
> package management these days. While ther is a lot of open source
> distributions which still rely on the config, make and make install
> style of installation, this is not a short fall of Linux, rather a
> failure of people to make their distributions available using these
> packaging systems - its no different than with software for Windows
> (or the Mac) if you want to install it and its not in that platforms
> installation package/format. The commercial OS platforms certainly had
> usable package management systems before Linux, but on the Windows
> platform at least, you needed it as installation was/is often a lot
> morre difficult than Linux.
Sure it's nice to just use dselect or make install on NetBSD.
Easier, in fact, than clicking through your random Windows
installer (finding the app and pushing "next" ten times or so).
But I still think it's more convenient to just drop bundles like
on the Mac, on RiscOS, and what other systems work the same way.
The point is that you can put everything into the same directory,
instead of having the executable live in /usr/local/bin, the
support files somewhere under .../lib/... or .../share/...
And finally, not everything exists as deb or rpm, and even if they
do, they sometimes just don't work (at least a couple years ago).
I don't like the system of having one centralized instance
managing a list of all packages I may install. Better to just
drag and drop as you need to.
> The real issue here is in getting people, especailly people
> distributing open source apps, to use the available package
> systems.
Which one? pkgsrc, deb, rpm, darwinports, FreeBSD ports,
openpackage, gentoo, slackware, arch?
Everybody roll his own system, instead of curing the problem at
the root, like gobolinux for instance (I don't have a PC, so never
tried it out).
> To some extent, there some resistance in the open source
> community to provding apps in a packaged format - partially due to the
> number of idfferent formats (though most of the main ones are now
> supported under multiple platforms) and possibly some arrogance in
> that there seems to be an attitude that if you cannot install it from
> sources, you shouldn't be running it.
If there isn't a bundle, you should be able to compile it, sure.
I think most open-source apps work fine in that respect.
> All the commercial software I've installed on Linux has had a very
> straight forward installation - usually its either in deb or rpm
> format or has a simple script you run - sometimes with a few prompts
> for info relating to configuration.
Yes. Debian usually works great (was my first Linux back then),
while RedHat/Mandrake used to fail in random ways not
understandable to a non-guru user (both installation and use), but
the first example proves the existence claim true ;)
--
By claiming a patent [...], I'm saying that you are not permitted
to use your own knowledge to further your ends. By what right?
Roderick T. Long
From: Christopher C. Stacy
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <uhdf2obxr.fsf@news.dtpq.com>
Matthias Buelow <···@incubus.de> writes:
> Rainer Joswig <······@lisp.de> writes:
>
> >> 20+ megs in size (think of irc and messaging clients, image
> >> previewers, desktop utilities and other "normal" sized programs, or
> >
> >I thought that exactly some of that stuff is especially huge.
> >Mozilla? 44MB. Photoshop Elements is 145MB on my disk. Canon's utilities
> >are about 260MB. Firefox is 26MB. GarageBand and its sound libraries
> >literally take gigabytes on my disk. iPhoto is 160MB.
>
> >Current software is HUGE.
> >
> >A few install images on my PowerBook:
> >
> >OSX Update 55MB
> >MS Office Update: 45 MB
> >LispWorks Installer 45MB
> >Aquamacs Installer 35MB
> >MySQL Installer 27.7MB
> >Camino Installer 21.2
> >Mozilla Installer 13.8
>
> But they contain the entire software, don't they. Including all data
> files. And they're all _huge_ software systems, not ordinary utility
> programs. For something like M$ Office an additional 20 megs might be
> nothing. For a small tool that displays postit-notes on your desktop,
> it would be ridiculous.
I'm sure I've already had this conversation,
more than once, more than a year ago.
http://groups-beta.google.com/group/comp.lang.lisp/browse_thread/thread/1ba1e868d930fb46/a3e2c89aa6f698a1?q=weather+process+group:comp.lang.lisp+author:Christopher+author:C.+author:Stacy&rnum=1&hl=en#a3e2c89aa6f698a1
http://groups-beta.google.com/group/comp.lang.lisp/browse_thread/thread/27feaa0ff97cccbd/63fbaa0df6385a62?q=weather+process+group:comp.lang.lisp+author:Christopher+author:C.+author:Stacy&rnum=2&hl=en#63fbaa0df6385a62
>> -r-xr-xr-x 1 root wheel 226608 May 26 19:49 /usr/X11R6/bin/gv*
gv doesn't do much of anything without ghostscript, so claiming it's a
'standalone binary' is a bit dubious. ghostscript itself also depends
on all kinds of postscript headers and fonts and stuff ...
-dan
Ingvar <······@hexapodia.net> writes:
>For GAIM, you also need to include the actual does-the-work parts
>(hiding in, most probably, /usr/lib/gaim). On my system, this more
>than doublesthe "installed size" (and isn't a single-file executable;
>it was, howvere, a single-file install, at least for me).
Hmm.. oops :) Haven't thought of the plugins, you're right.
% du -hs /usr/X11R6/lib/gaim
19M /usr/X11R6/lib/gaim
(but that covers nearly all IM protocols on the planet.)
[Why the FreezeBSD ports entry puts the stuff under /usr/X11R6 is
beyond my understanding.]
mkb.
From: Björn Lindberg
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <42d27b33$1@news.cadence.com>
Matthias Buelow wrote:
> Joe Marshall <·············@comcast.net> writes:
>
>
>>>What is this fixation everyone has on "smaller" images?
>>>Smaller than what? Who cares?
>>>These are not meant as rhetorical questions.
>>
>>Image envy. People want to say `Mine's smaller.'
>
>
> For big programming systems, it doesn't matter but you'll have a hard
> time peddling commodity utilities to people when the executables are
> 20+ megs in size (think of irc and messaging clients, image
> previewers, desktop utilities and other "normal" sized programs, or
> even the kind of stuff that populates /usr/bin.) Even though disk
> space today is large, bandwidth is wide and RAM is plenty, many people
> would probably object to such an obviously extremely crass waste of
> resources.
>
> A real solution would be to hoist Lisp into the age of shared
> libraries so that one could have small binaries that contain only the
> application logics and not the whole runtime system but that's
> probably not as easy to do as with more static languages like C, Java,
> etc.
For such a small program you could ship it as FASLs. The local Lisp
installation would then correspond to the shared library, or the
scripting language interpreter. Except that there usually is no local
Lisp installation.
Bj�rn
From: Bulent Murtezaoglu
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <87ackwvro8.fsf@p4.internal>
>>>>> "CCS" == Christopher C Stacy <······@news.dtpq.com> writes:
[...]
CCS> What is this fixation everyone has on "smaller" images?
CCS> Smaller than what? Who cares? These are not meant as
CCS> rhetorical questions.
I wouldn't call it a fixation, but upload speed matters to me
sometimes when I am sending prototype code with clients (especially UI
stuff, with 'you mean like this?' exchanges). I have 64kbps upload
speed on this line, and a bz2 compressed Lispworks exe with my stuff
is typically about 4-5mb. It does take a while. (About a minute
would be ideal for me, and the cost of that for ADSL at gov't monopoly
prices here would be exorbitant). I also used to think nothing of
downloading the linux kernel source when I had cable on a not-so-busy
segment, or even a t-1 to myself (that was slower than cable!) but now
with 256kbps ADSL I no longer check out kernels and such as and take
the time to fish out patches. Perhaps better organized people or
people with different work patterns are not as sensitive to bandwidth
though.
I think all these problems will disappear in a few years though (and
they don't exist everyhere, Turkey is somewhat backward in this) I
don't see image sizes growing faster than the increases in 'home
grade' bandwidth. Except perhaps if MS produces a lisp.NET that
weighs in at around a gig.
cheers,
BM
Bulent Murtezaoglu <··@acm.org> writes:
>>>>>> "CCS" == Christopher C Stacy <······@news.dtpq.com> writes:
> [...]
> CCS> What is this fixation everyone has on "smaller" images?
> CCS> Smaller than what? Who cares? These are not meant as
> CCS> rhetorical questions.
> I wouldn't call it a fixation, but upload speed matters to me
> sometimes when I am sending prototype code with clients (especially UI
> stuff, with 'you mean like this?' exchanges). I have 64kbps upload
> speed on this line, and a bz2 compressed Lispworks exe with my stuff
> is typically about 4-5mb. It does take a while.
But, as has been stated several times before, you shouldn't do this.
Instead, you should send the aforementioned 4-5mb exe once, and then
send fasls for the "you mean like this?" patches. Once you and your
customer are agreed, you repackage the app and ship.
--
Espen Wiborg <·······@grumblesmurf.org>
The average person falls asleep in seven minutes.
>> There is one way to make smaller images...
······@news.dtpq.com (Christopher C. Stacy):
> What is this fixation everyone has on "smaller" images?
While working alone on your Symbolics Lisp machine is good fun, some
of us sometimes need to distribute a binary to those pesky people
known as ``users''. In my particular case, I often give my students a
binary that generates test cases for their programming assignment;
giving out the sources would give too much information about the
solution.
Right now, I have the following ways to distribute a binary:
(1) write a program in Lisp, and require the recipient to install CMUCL
on his system and compile my source himself; this is not doable
when I don't want to give the sources away;
(2) write a program in Lisp, and statically link against CLISP; I end
up with a 3MB image;
(3) write a program in Scheme, Haskell or O'Caml, and compile using
the batch compilers for these languages (Stalin, Ghc, ocamlopt);
I end up with a binary that is well below the megabyte;
(4) write a program in C; I'll end up with a tiny binary, and if I'm
smart about shared libs, it will work on other people's systems.
I usually do (3), except when the program is trivial, in which case I
do (4). It is a pity that I cannot use my favourite programming
environment just because CMUCL cannot do delivery.
Juliusz
From: Christopher C. Stacy
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <ueka56trh.fsf@news.dtpq.com>
Juliusz Chroboczek <···@pps.jussieu.fr> writes:
> >> There is one way to make smaller images...
>
> ······@news.dtpq.com (Christopher C. Stacy):
> > What is this fixation everyone has on "smaller" images?
>
> While working alone on your Symbolics Lisp machine is good fun,
> some of us sometimes need to distribute a binary to those pesky
> people known as ``users''. In my particular case, I often give
> my students a binary that generates test cases for their
> programming assignment; giving out the sources would give too
> much information about the solution.
Juliusz Chroboczek <···@pps.jussieu.fr> writes:
> >> There is one way to make smaller images...
>
> ······@news.dtpq.com (Christopher C. Stacy):
>
> > What is this fixation everyone has on "smaller" images?
>
> While working alone on your Symbolics Lisp machine is good fun, some
> of us sometimes need to distribute a binary to those pesky people
> known as ``users''. In my particular case, I often give my students a
> binary that generates test cases for their programming assignment;
> giving out the sources would give too much information about the
> solution.
I don't know what Lisp Machines have to do with anything.
I deliver most of my applications on CMUCL (including the CMUCL
runtime) or on Lispworks (as standalone .EXE files), and I give
them patches as FASL files. My customers are fine with that.
I don't know why you are talking about source code in the
same breath as deliverable binaries.
Apparently CMUCL is not adequate for your academic needs.
I think you should be talking to your Lisp vendor, not to me.
We're fine here!
······@news.dtpq.com (Christopher C. Stacy):
> I deliver most of my applications on CMUCL (including the CMUCL
> runtime) or on Lispworks (as standalone .EXE files), and I give
> them patches as FASL files. My customers are fine with that.
Christopher,
There's a non sequitur in your argumentation. You say that 25MB
deliverables are fine for you, which I'm happy to hear. From that it
does not follow, however, that there is no problem with the current
state of Common Lisp technology.
The inability to deliver sub-megabyte binaries with any Common Lisp
implementation available is a serious problem for some people. Who
end up using Haskell, O'Caml or Scheme instead of Common Lisp.
Juliusz
From: Pascal Costanza
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <3jg1v7Fpar3vU1@individual.net>
Juliusz Chroboczek wrote:
> ······@news.dtpq.com (Christopher C. Stacy):
>
>>I deliver most of my applications on CMUCL (including the CMUCL
>>runtime) or on Lispworks (as standalone .EXE files), and I give
>>them patches as FASL files. My customers are fine with that.
>
> Christopher,
>
> There's a non sequitur in your argumentation. You say that 25MB
> deliverables are fine for you, which I'm happy to hear. From that it
> does not follow, however, that there is no problem with the current
> state of Common Lisp technology.
It's a problem that will most likely resolve itself in the
not-so-distant future. Advances in hardware will solve it for us.
> The inability to deliver sub-megabyte binaries with any Common Lisp
> implementation available is a serious problem for some people. Who
> end up using Haskell, O'Caml or Scheme instead of Common Lisp.
clisp is around 15 MB (unless I am missing something). ECL should be
rather compact as well, right? (I don't have any numbers here.) It seems
to me that you can get somewhere between 5 and 10 MB with OpenMCL.
OpenLisp is an implementation of ISLISP, which is more or less a subset
of Common Lisp, and they claim that they can create a full-fledged
system at around 400 KB. See http://www.eligis.com/
Pascal
P.S.: I am not really interested in this topic, the numbers I have
posted above are the results of quickly checking installations on my
system and googling a little bit. It sounds as if people are just
drawing conclusions from one system here that isn't necessarily the
slimmest one.
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
From: Sam Steingold
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <uhdf1xflo.fsf@gnu.org>
> * Pascal Costanza <··@c-pbf.arg> [2005-07-11 22:09:11 +0200]:
>
> clisp is around 15 MB (unless I am missing something).
you are off by a factor of 4.
lisp.run: < 2MB
lispinit.mem ~ 1.6MB
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.honestreporting.com> <http://www.mideasttruth.com/>
<http://www.dhimmi.com/> <http://www.iris.org.il>
Between grand theft and a legal fee, there only stands a law degree.
From: Pascal Costanza
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <3jg392Fn7u2jU1@individual.net>
Sam Steingold wrote:
>>* Pascal Costanza <··@c-pbf.arg> [2005-07-11 22:09:11 +0200]:
>>
>>clisp is around 15 MB (unless I am missing something).
>
>
> you are off by a factor of 4.
>
> lisp.run: < 2MB
> lispinit.mem ~ 1.6MB
Thanks for the correction!
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
From: Edi Weitz
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <upstpruq1.fsf@agharta.de>
On Mon, 11 Jul 2005 20:03:40 +0200, Juliusz Chroboczek <···@pps.jussieu.fr> wrote:
> Right now, I have the following ways to distribute a binary:
>
> (1) write a program in Lisp, and require the recipient to install CMUCL
> on his system and compile my source himself; this is not doable
> when I don't want to give the sources away;
> (2) write a program in Lisp, and statically link against CLISP; I end
> up with a 3MB image;
> (3) write a program in Scheme, Haskell or O'Caml, and compile using
> the batch compilers for these languages (Stalin, Ghc, ocamlopt);
> I end up with a binary that is well below the megabyte;
> (4) write a program in C; I'll end up with a tiny binary, and if I'm
> smart about shared libs, it will work on other people's systems.
(2b) write a program in Lisp and deliver as an executable with
LispWorks; depending on your application this might be as small
as 3MB.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
"Juliusz Chroboczek" <···@pps.jussieu.fr> wrote in message
···················@lanthane.pps.jussieu.fr...
> "Jamie Border" <·····@jborder.com>:
>
>> 3) bzip -9 lisp.core (that should reduce the size a bit).
>
> No, that will kill performance.
>
Well I thought the OP was irritated my huge core files.. If he wants
performance he'll have to give up and accept them.
> CMUCL and SBCL will map a core file in memory and jump all over it.
Well you could always mmap the section of the executable containing the
(uncompressed) image
> Using a technique that doesn't allow random access to the core file
> will absolutely kill performance and memory usage.
Yes, but this is not such a technique, provided the decompressed core will
sit nicely in memory without swallowing the majority of physical memory.
Personally, I don't care about massive file size, but if I can distribute a
statically-linked ELF binary (unix only), then this is a big win for me. I
know I could tar it all up instead, but why should I have to? If I want
sometning I can mail to a friend to test, I don't want him to moan because:
a) He has to install SBCL, or CMUCL, or whatever.
b) I forgot to include some esoteric dependency, which didn't affect person
A,B or C.
Jamie
From: Christopher C. Stacy
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <u7jg0pp1b.fsf@news.dtpq.com>
"Jamie Border" <·····@jborder.com> writes:
> Personally, I don't care about massive file size, but if I can distribute a
> statically-linked ELF binary (unix only), then this is a big win for me. I
> know I could tar it all up instead, but why should I have to? If I want
> sometning I can mail to a friend to test, I don't want him to moan because:
>
> a) He has to install SBCL, or CMUCL, or whatever.
> b) I forgot to include some esoteric dependency,
> which didn't affect person A,B or C.
I guess he won't accept any Java programs, or Ruby programs,
or anything other than statically linked C programs, then?
Also, why aren't people just using installers?
Is the technology on these operating systems, whatever they are,
so poor that installers don't exist or are too inconvenient to use?
What's with shipping all these files around? Why not just push a
button on the sending end, everything gets automatically packed up
into an executable binary format, and then on the receiving end
the user just runs the executable and all the right things happen?
(Microsoft Windows, no paragon of technology, has all that.)
CS>
JB>> sometning I can mail to a friend to test, I don't want him to moan
because:
JB>>
JB>> a) He has to install SBCL, or CMUCL, or whatever.
JB>> b) I forgot to include some esoteric dependency,
JB>> which didn't affect person A,B or C.
CS>
CS> I guess he won't accept any Java programs, or Ruby programs,
CS> or anything other than statically linked C programs, then?
Sure. Mail a lisp core to somebody who has never used Lisp, and tell them
"oh yeah, it needs SBCL v0.9.1, built without unicode support, but with
threads".
Java? Well that's preinstalled with almost all Unices now, and Windows boxes
can get it easily.
Ruby? Sure, these's only one distribution of Ruby. I could point him at the
one-click installer, which would make it easier.
>
CS> Also, why aren't people just using installers?
CS> sIs the technology on these operating systems, whatever they are,
CS> so poor that installers don't exist or are too inconvenient to use?
No, but there is no obligation to use one particular package management
system.
(Anti-MS rant: Windows has no package management system - "who owns
shdocvw.dll?")
I wasn't trying to show the *one true way* to distribute Lisp apps, but
rather explain why I personally found it a useful idea to be able to give a
single binary image to somebody who (*gasp*) never gets told it's a Lisp
program.
What's so terrible about that?
Jamie
From: Peter Herth
Subject: Re: How to create a standalone GNU/Linux binary using SBCL?
Date:
Message-ID: <dao72f$5fa$03$1@news.t-online.com>
Jamie Border wrote:
or anything other than statically linked C programs, then?
>
> Sure. Mail a lisp core to somebody who has never used Lisp, and tell them
> "oh yeah, it needs SBCL v0.9.1, built without unicode support, but with
> threads".
>
Well just mail the sbcl runtime (which is a single 200k file) with the
executable. To some extend, it is especially easy to deploy Lisp
applications with sbcl, as you just need the core and the runtime file,
yet I would find it very convenient, if it were possible to put the
runtime and the core in a file so you can just run that file.
Peter
--
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
get Ltk here: http://www.peter-herth.de/ltk/
"Jamie Border" <·····@jborder.com> writes:
>Java? Well that's preinstalled with almost all Unices now, and Windows boxes
>can get it easily.
I'd like to contest that. For many systems, Java is not available at
all. And even for systems like FreeBSD or NetBSD (i386), it's rather
complicated to install. You have to get the source and the BSD patches
separately and then build it from source (with an existing JDK,
possibly the Linux one, running in emulation). That's because Sun's
restrictive licensing doesn't allow redistribution of the patched
thing. Pretty annoying. This is certainly _not_ useful for the
unsophisticated end user (but they use Windows anyways).
mkb.
>
JB>>Java? Well that's preinstalled with almost all Unices now, and Windows
boxes
JB>>can get it easily.
>
> I'd like to contest that. For many systems, Java is not available at
> all. And even for systems like FreeBSD or NetBSD (i386), it's rather
> complicated to install. You have to get the source and the BSD patches
> separately and then build it from source (with an existing JDK,
> possibly the Linux one, running in emulation). That's because Sun's
Well, that shows my ignorance of Java on BSD then :-)
I assumed there was a port of Blackdown or something. Aparently not.
> restrictive licensing doesn't allow redistribution of the patched
> thing. Pretty annoying. This is certainly _not_ useful for the
> unsophisticated end user (but they use Windows anyways).
Is it a long-held ideal that (CLisp/CMUCL/SBCL) Lisp software should be
delivered in a similar way?
Why shouldn't I build something that is indistinguishable from any other
executable program?
Jamie
>
> mkb.
"Jamie Border" <·····@jborder.com> writes:
> Why shouldn't I build something that is indistinguishable from any other
> executable program?
Why indeed. Instead of calling it myapp.core, call it libmyapp.so,
send a small sbcl binary, a big libmyapp, and a shell script to start
it. Concepts like "installation prefix" and the need to type "make
install" are not exactly strange on Unix.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
"Jamie Border" <·····@jborder.com>:
> Personally, I don't care about massive file size, but if I can distribute a
> statically-linked ELF binary (unix only), then this is a big win for me.
Modifying the CMUCL startup code to map the image from itself is a
couple hours' job. However, it's completely useless as long as hello
world is 25 MB.
According to the experiments I did some time ago, a compiler-less
CMUCL image with almost full CLOS support (no ability to change the
class hierarchy at runtime) and reduced typechecking would be in the
12-13 MB range on x86, which is still a lot, but much better than what
we have now. Unfortunately, I've had some bootstrapping issues with
the type system that I was unable to solve.
Juliusz