Hello,
I'm a beginner Common Lisper and wondered how one typically deploys
his/her Lisp application on the production server.
I know that you usually debug your program on the fly, thanks to the
REPL. I also heard about dumping an image of your current Lisp process.
What are its benefits compared to just installing your Lisp and running
your application? When you use an image, it's binary that you can give
to your customer and not worry about stealing the sources.
Can you elaborate on this topic (deploying strategies etc.)? Thank you!
--
Flynn,
e-mail: ·@wapwap.hu
If you can just run Lisp on the server and load your source or fasl
files from there, here's a good strategy:
1. Start Lisp on your server, load your program, and make sure you have
some way of connecting to the REPL remotely, like detatchtty or swank.
2. Let it run. If you need to fix anything, change the source code and
connect to the remote REPL and load in your changes.
I'm running an UnCommonWeb server using this strategy, and I was
actually cackling in delight at the ability to fix things while the
server was running.
In case I haven't emphasized this enough: REMOTE REPL! This is easiest
to do on a server.
-Peter
Hello,
Thanks for your reply, Peter, it was helpful. I'm interested in how you
install your program. Do you dump an image? If so, why? If you just
install a Lisp and use that, why?
Thanks in advance.
Cheers.
--
Flynn,
e-mail: ·@wapwap.hu
home-page: http://humankraft.hu/~lambda/
·@wapwap.hu writes:
> Thanks for your reply, Peter, it was helpful. I'm interested in how you
> install your program. Do you dump an image? If so, why? If you just
> install a Lisp and use that, why?
We're mostly using lispworks delivered applications, because there's
no point in having the whole lisp environment on the server (level-0-
delivered lispworks binaries contain almost everything you need
for maintenance anyway), and because lispworks runtimes are free.
We use two different models: Some of our applications have a toplevel
REPL and run under emacs, which runs under screen. Others run as
conventional daemons, but have a built-in REPL server which you can
connect to.
--
(espen)
·@wapwap.hu writes:
> Hello,
>
> Thanks for your reply, Peter, it was helpful. I'm interested in how you
> install your program. Do you dump an image? If so, why? If you just
> install a Lisp and use that, why?
Yes, the easiest and safest is to dump an image.
Then you have loaded in the image all the program, and you have
initialized all the globals (perhaps with pre-compiled data), so it's
faster to load the image than to reload even the .fasl, and you don't
risk to break the program when you update one of the dependencies.
For example, I launch the server MYSERVER using this script:
% cat /usr/local/app/MYSERVER/bin/MYSERVER
#!/bin/bash
export PREFIX=/usr/local/app/MYSERVER
cd "$PREFIX"
while true ; do
"$PREFIX"/bin/clisp \
-norc -ansi -q -K full -m 32M -I -E ISO-8859-1 \
-M "$PREFIX"/lib/MYSERVER.mem.gz \
|| true
done
% grep MYSERVER /etc/init.d/boot.local
su - MYSERVERUSER screen -d -m /usr/local/app/MYSERVER/bin/MYSERVER
Now, I do also package the lisp and all the dependencies in this
/usr/local/app/MYSERVER/ directory. So if root wants to update the
system-wide clisp, it won't break my application either. Thanksfully,
clisp is small enought that it's no problem to ship a 1.8 MB lisp.run
executable + an image (from 2 MB) for each application. A little UCW
application I have here makes a 5.4 MB image, more medium size
applications would be much bigger, so the 1.8 MB lisp.run overhead is
not too much.
Now, this kind of packaging is valid when you're distributing open
source anyway. If you want to distribute closed source, it's
preferable to give .fasl to let the user reconstruct it and patch it
at least from your .fasl. But that would be at installation time, she
would still build an image and use it for production.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
So does this mean that loading packages with asdf-install each time you
start Lisp is pretty much the same as loading them manually and then
saving the image and starting with that image instead?
"jonathon" <···········@bigfoot.com> writes:
> So does this mean that loading packages with asdf-install each time you
> start Lisp is pretty much the same as loading them manually and then
> saving the image and starting with that image instead?
The latter can be much, much, much faster. In some Lisps, FASL files
do not load very quickly at all, while starting up from an image is
mostly instantaneous.
(Also, please cite some context in your replies.)
Zach
Zach Beane wrote:
> "jonathon" <···········@bigfoot.com> writes:
>
> > So does this mean that loading packages with asdf-install each time
you
> > start Lisp is pretty much the same as loading them manually and
then
> > saving the image and starting with that image instead?
>
> The latter can be much, much, much faster. In some Lisps, FASL files
> do not load very quickly at all, while starting up from an image is
> mostly instantaneous.
So if the standard image is 20M, for example, will extra loads increase
that substantially, or just in small amounts? I guess the 20M is the
core of the language, the REPL, the built-ins, and so on?
"jonathon" <···········@bigfoot.com> writes:
> Zach Beane wrote:
>> "jonathon" <···········@bigfoot.com> writes:
>>
>> > So does this mean that loading packages with asdf-install each time
> you
>> > start Lisp is pretty much the same as loading them manually and
> then
>> > saving the image and starting with that image instead?
>>
>> The latter can be much, much, much faster. In some Lisps, FASL files
>> do not load very quickly at all, while starting up from an image is
>> mostly instantaneous.
>
> So if the standard image is 20M, for example, will extra loads increase
> that substantially, or just in small amounts? I guess the 20M is the
> core of the language, the REPL, the built-ins, and so on?
But assume you never use the function HOST-NAMESTRING. It won't ever
be mmaped from the image. When "loading" an image, a program or a
shared library, only the function used are actually read from the
disks. When you load a .fasl, the whole file is loaded, and if not
used, it might get back to swap only when the generation will have
grown old enough to not be touched anymore by the garbage collector.
(And I don't know what 20M can account for when clisp uses only 4MB).
--
__Pascal Bourguignon__ http://www.informatimago.com/
Kitty like plastic.
Confuses for litter box.
Don't leave tarp around.
Pascal Bourguignon wrote:
> "jonathon" <···········@bigfoot.com> writes:
> > Zach Beane wrote:
> >> "jonathon" <···········@bigfoot.com> writes:
> >>
> >> > So does this mean that loading packages with asdf-install each
time
> > you
> >> > start Lisp is pretty much the same as loading them manually and
> > then
> >> > saving the image and starting with that image instead?
> >>
> >> The latter can be much, much, much faster. In some Lisps, FASL
files
> >> do not load very quickly at all, while starting up from an image
is
> >> mostly instantaneous.
> >
> > So if the standard image is 20M, for example, will extra loads
increase
> > that substantially, or just in small amounts? I guess the 20M is
the
> > core of the language, the REPL, the built-ins, and so on?
>
> But assume you never use the function HOST-NAMESTRING. It won't ever
> be mmaped from the image. When "loading" an image, a program or a
> shared library, only the function used are actually read from the
> disks. When you load a .fasl, the whole file is loaded, and if not
> used, it might get back to swap only when the generation will have
> grown old enough to not be touched anymore by the garbage collector.
>
> (And I don't know what 20M can account for when clisp uses only 4MB).
>
> --
> __Pascal Bourguignon__
http://www.informatimago.com/
> Kitty like plastic.
> Confuses for litter box.
> Don't leave tarp around.
Seems that he's using Allegro ~20M, LW is about 12MB
"fireblade" <········@YAHOO.COM> writes:
> Pascal Bourguignon wrote:
> >
> > (And I don't know what 20M can account for when clisp uses only 4MB).
> >
> Seems that he's using Allegro ~20M, LW is about 12MB
It's likely that that the Allegro CL image is on Windows and contains
the full-blown IDE and Common Graphics system. Also, 20M is likely the
"Mem Usage" size (as seen on the Task Manager) - the better measure of
any program's "heaviness", whether Lisp or not, is in the "VM Usage"
column - it shows what is being currently used, rather than what is
allocated. If on a *nix system, the best measure of "heaviness" is
the Resident Set size. This is seen on most systems as the RSS column
in the output of a ps command.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: André Thieme
Subject: Re: Deploying Common Lisp applications
Date:
Message-ID: <d6kup4$q2n$1@ulric.tng.de>
fireblade schrieb:
> Seems that he's using Allegro ~20M, LW is about 12MB
How do some people manage to create smaller files?
For example Frank Bu�s little game is ~4M:
http://www.frank-buss.de/lisp/aqueduct.html
(and it's done with LispWorks)
Andr�
--
Andr� Thieme <······························@justmail.de> wrote:
> How do some people manage to create smaller files?
> For example Frank Bu�s little game is ~4M:
> http://www.frank-buss.de/lisp/aqueduct.html
> (and it's done with LispWorks)
and zipped it is only 1.5 MB. Some magic in the deliver.lisp
(it is not possible for all programs)
- setting the delivery level to 5
- :keep-complex-numbers nil
- :compact t
- :keep-bignum-numbers nil
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Edi Weitz
Subject: Re: Deploying Common Lisp applications
Date:
Message-ID: <u1x81ncld.fsf@agharta.de>
On Fri, 20 May 2005 17:13:28 +0200, Andr� Thieme <······························@justmail.de> wrote:
> How do some people manage to create smaller files? For example
> Frank Bu�s little game is ~4M:
> http://www.frank-buss.de/lisp/aqueduct.html (and it's done with
> LispWorks)
<http://www.lispworks.com/documentation/lw445/DV/html/deluser.htm>
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> On Fri, 20 May 2005 17:13:28 +0200, Andr� Thieme <······························@justmail.de> wrote:
>
> > How do some people manage to create smaller files? For example
> > Frank Bu�s little game is ~4M:
> > http://www.frank-buss.de/lisp/aqueduct.html (and it's done with
> > LispWorks)
>
> <http://www.lispworks.com/documentation/lw445/DV/html/deluser.htm>
And of course, Allegro CL has one as well:
http://www.franz.com/support/documentation/7.0/doc/delivery.htm
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
> But assume you never use the function HOST-NAMESTRING. It won't ever
> be mmaped from the image. When "loading" an image, a program or a
> shared library, only the function used are actually read from the
> disks. When you load a .fasl, the whole file is loaded, and if not
> used, it might get back to swap only when the generation will have
> grown old enough to not be touched anymore by the garbage collector.
Ah, okay. Of course.
> (And I don't know what 20M can account for when clisp uses only 4MB).
CMUCL Lisp has a 22M .core file.
I tried clisp and switched for some reason. I forget exactly what,
since I was just trying different versions. What made you decide to go
with clisp?
jonathon <···········@bigfoot.com> wrote:
+---------------
| > (And I don't know what 20M can account for when clisp uses only 4MB).
|
| CMUCL Lisp has a 22M .core file.
| I tried clisp and switched for some reason. I forget exactly what...
+---------------
Before I switched to using a mod_lisp-style application server daemon
[in CMUCL, for the speed of the compiled code], I tried using both
CMUCL & CLISP to do traditional CGI scripting. On both, the load time
for my utility libraries (CGI stuff, forms parsing HTML generation,
PostgreSQL interface) was quite slow, so I built a custom image for
each tailored to CGI scripting. To my surprise, the ~23 MB of the
CMUCL image was *not* a performance issue, since it is "mmap()'d" and
not "read()" into memory, and FreeBSD & Linux do a good job of caching
recently-mmap'd read-only files [which is what "mmap(,,,MAP_PRIVATE,)"
gives you, effectively]. In fact, after the first execution, a trivial
CGI script runs slightly *faster* with CMUCL (16-17ms) than CLISP (20-21ms).
[Also note that, compared to a custom image, using a standard CMUCL
image and LOADing the CGI/HTML/PG libraries per invocation *did* carry
a significant penalty, and raised the trivial CGI script time to ~100ms!]
So do some measurements of your own in the application environment
you'll be using before deciding that one image or another is "too big".
-Rob
p.s. As I said, I later switched to the persistent server daemon
approach [talking via a socket to Apache], where the time to use
ASDF to compile/load everything at boot time doesn't matter.
Also, my "LHP" pages are [optionally compiled and] cached on first
access, so repeated references to the same base URL [which can
have varying trailing pathname components and query args] don't
even have to touch the filesystem except to check modification times.
Still, the CGI approach is occasionally useful for "one-off" hacks
and prototyping.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Fri, 20 May 2005 10:22:46 -0400, Zach Beane wrote:
> The latter can be much, much, much faster. In some Lisps, FASL files do
> not load very quickly at all, while starting up from an image is mostly
> instantaneous.
This often annoys me actually. What's the reason for FASL files being slow
to load in say SBCL? Does it just need some tweaking or is there something
about loading FASL files which makes them inherently slow to load no
matter what kind of tweaking you do?
I use SBCL for a lot of general purpose programming. It can be a bit
upsetting to see the same program in lisp run much faster in say perl, but
because of the time it takes to load the fasl files compared to perl
modules the overall loading and running takes several hundred times
longer. Dumping cores isn't very practical for such small scripts. It's a
bit of a waste to have many small scripts each represented by their own
22M core.
Robert Marlow <··········@bobturf.org> writes:
> I use SBCL for a lot of general purpose programming. It can be a bit
> upsetting to see the same program in lisp run much faster in say perl, but
> because of the time it takes to load the fasl files compared to perl
> modules the overall loading and running takes several hundred times
> longer. Dumping cores isn't very practical for such small scripts. It's a
> bit of a waste to have many small scripts each represented by their own
> 22M core.
What about having one core with all your scripts? Or starting your
Lisp at boot time with all the fasl files loaded.
Andras
On Mon, 23 May 2005 15:45:20 +0800, <··········@bobturf.org> wrote:
>
> This often annoys me actually. What's the reason for FASL files being slow
> to load in say SBCL?
Annoyed?? Most lispers are probably wondering why you keep reloading.
> I use SBCL for a lot of general purpose programming. It can be a bit
> upsetting to see the same program in lisp run much faster in say perl, but
> because of the time it takes to load the fasl files compared to perl
> modules the overall loading and running takes several hundred times
> longer. Dumping cores isn't very practical for such small scripts. It's a
> bit of a waste to have many small scripts each represented by their own
> 22M core.
I'd say you're wrong. "Very practical" ?? 22M is nothing, what are
you using, an 8080? Do you want speed or not?? Clearly you have
never learned that:
Speed, Small, Cheap
at best, you get 2 out of 3
The advantages of core files have been pointed out, the suggestion to
have all your scripts in one core looks good.
--
With sufficient thrust, pigs fly fine.
GP lisper wrote:
> On Mon, 23 May 2005 15:45:20 +0800, <··········@bobturf.org> wrote:
>
>> This often annoys me actually. What's the reason for FASL files
>> being slow to load in say SBCL?
>
>
> Annoyed?? Most lispers are probably wondering why you keep
> reloading.
THIS Lisper wonders why they're called "FASt Load" files if loading them
isn't fast.
>> I use SBCL for a lot of general purpose programming. It can be a
>> bit upsetting to see the same program in lisp run much faster in
>> say perl, but because of the time it takes to load the fasl files
>> compared to perl modules the overall loading and running takes
>> several hundred times longer. Dumping cores isn't very practical
>> for such small scripts. It's a bit of a waste to have many small
>> scripts each represented by their own 22M core.
>
>
> I'd say you're wrong. "Very practical" ?? 22M is nothing, what are
> you using, an 8080? Do you want speed or not?? Clearly you have
> never learned that:
>
> Speed, Small, Cheap at best, you get 2 out of 3
You'd be so right (yet banal), if only the platitude wasn't "good, fast
and cheap: pick any two" Personally, I don't think that the original is
always right, though it often provides useful guidance. But people who
figure they can just substitute their favourite three criteria into the
expression and still have it hold true, they make me wonder....
22M may well be nothing to some people in some situations, but for
others, it represents an (embarrassing, costly, unworkable; pick all
that apply) constraint. I'm not saying that your "just buy more memory,
you cheap bastard" response won't change anyone's mind, but the history
of this newsgroup suggests that memory consumption IS a concern for many
who contemplate delivering applications in Lisp, and yours is the
weakest of all arguments explaining why the trade-off is worthwhile. Is
your day job selling C compilers, or are you just THAT bad at explaining
the advantages of (some) Lisps' 22M core files?
> The advantages of core files have been pointed out, the suggestion to
> have all your scripts in one core looks good.
Lisp "core files" are a wonderful idea which can markedly speed
application load time and memory requirements in some instances. But
your support for the suggestion that a user with N independent scripts
just load 'em all up and dump a core probably looks, to typical UNIX/C
developers, like suggesting:
- just stick all your code in one big binary, branch on argv[0]
- just compile it into the kernel, rebuild/boot when necessary
I.e. stupid. It's a workaround for a problem that doesn't exist in other
development/runtime environments, but you haven't enumerated any of the
advantages that typical Lisp implementations have over those environments.
Cameron MacKinnon <··········@clearspot.net> wrote:
+---------------
| GP lisper wrote:
| > The advantages of core files have been pointed out, the suggestion to
| > have all your scripts in one core looks good.
|
| Lisp "core files" are a wonderful idea which can markedly speed
| application load time and memory requirements in some instances. But
| your support for the suggestion that a user with N independent scripts
| just load 'em all up and dump a core probably looks, to typical UNIX/C
| developers, ... [stupid].
+---------------
There *is* an intermediate approach...
Make one specialized core file [or more, maybe, but in any case a
very small number] that has all of your "usual suspect" utility and
support library functions, and then write your CL scripts as calls of
these. Since the size of each script will be small (since the scripts
are now mostly just "glue" between library functions), you can even run
them purely interpreted, probably faster even than LOADing FASL files.
[Well, this is true for CMUCL, but maybe not for SBCL.]
Example: I have a CMUCL image "cgi.core" that has my CGI query-parsing
tools in it, the "HTOUT" HTML-generation macros, the "PG" PostgreSQL
binding, and a bunch of miscellaneous tools and widgets I've found to
be handy in general-purpose CGI scripting and Unix shell scripting.
Simple interpreted scripts using this image take only ~20 ms to run
on an Athlon 1600+ (1.4 GHz) under FreeBSD, e.g.:
$ cat ./foo
#!/usr/local/bin/cmucl -core /usr/local/lib/cmucl/lib/cgi.core
(format t "Hello, world!~%")
$ time ./foo
Hello, world!
0.006u 0.013s 0:00.02 50.0% 252+5160k 0+0io 0pf+0w
$
[Yes, the core contains a reader macro for "#!".]
Loading additional FASL libraries can take 30-100 ms (or more), so if
you find something being used by several scripts just add it to the
base core [if it's not *too* big].
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Cameron MacKinnon <··········@clearspot.net> writes:
> GP lisper wrote:
>> On Mon, 23 May 2005 15:45:20 +0800, <··········@bobturf.org> wrote:
>>
>>> This often annoys me actually. What's the reason for FASL files
>>> being slow to load in say SBCL?
>> Annoyed?? Most lispers are probably wondering why you keep
>> reloading.
>
> THIS Lisper wonders why they're called "FASt Load" files if loading them
> isn't fast.
Well, absent fixing the actual performance problems, you could always
apply this patch
diff -u -r1.54 early-fasl.lisp
--- src/code/early-fasl.lisp 22 May 2005 00:07:45 -0000 1.54
+++ src/code/early-fasl.lisp 24 May 2005 06:11:41 -0000
@@ -124,7 +124,7 @@
;;; the conventional file extension for our fasl files
(declaim (type simple-string *fasl-file-type*))
-(defvar *fasl-file-type* "fasl")
+(defvar *fasl-file-type* "slol")
;;;; information about below-Lisp-level linkage
but loading slols is still faster than loading source. Alternatively,
run a profiler, see where loading is spending time, and answer your
question to your own satisfaction.
Christophe
Cameron MacKinnon <··········@clearspot.net> writes:
> Lisp "core files" are a wonderful idea which can markedly speed
> application load time and memory requirements in some instances. But
> your support for the suggestion that a user with N independent scripts
> just load 'em all up and dump a core probably looks, to typical UNIX/C
> developers, like suggesting:
> - just stick all your code in one big binary, branch on argv[0]
> - just compile it into the kernel, rebuild/boot when necessary
> I.e. stupid. It's a workaround for a problem that doesn't exist in other
> development/runtime environments, but you haven't enumerated any of the
> advantages that typical Lisp implementations have over those environments.
Note that the first of these two approaches is actually used
to great effect on certain memory- and storage-constrained systems -
like FreeBSD install disks, and Linux running on handhelds. I.e, not
so stupid, after all.
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
> Cameron MacKinnon <··········@clearspot.net> writes:
>
>> Lisp "core files" are a wonderful idea which can markedly speed
>> application load time and memory requirements in some instances. But
>> your support for the suggestion that a user with N independent scripts
>> just load 'em all up and dump a core probably looks, to typical UNIX/C
>> developers, like suggesting:
>> - just stick all your code in one big binary, branch on argv[0]
You must be a recent developer. This trick is very common, several
bin files use it to select various sets of command line options. Look
for symlinks within the same directory. 'Busybox' isn't as common
nowdays with CD installs, but those floppy installs loved it.
>> - just compile it into the kernel, rebuild/boot when necessary
Where you are trying to go here is baffling...ah just how are a unix
kernel and a lisp image suppose to be related? An image is a 'world'
whereas a kernel is a 'base'.
>> I.e. stupid. It's a workaround for a problem that doesn't exist in other
>> development/runtime environments, but you haven't enumerated any of the
>> advantages that typical Lisp implementations have over those environments.
What problem? The problem lies in your mind apparently. You have
some made up concept of "fast" that you feel is not being met. You
don't think that you might be going about things the wrong way. You
are sure that the prior developers have missed this, but haven't
pointed out any errors in coding, as a unix/c developer might do...
I spend a lot of time using cmucl lisp as a user shell, and that image
might run for a week. CL-Yahoo might take a moment to load at the
start, but I can use it dozens of times afterwards without any loading
penalty.
Maybe you should use perl, since it fits your small and overall
fastest needs.
--
With sufficient thrust, pigs fly fine.
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: Deploying Common Lisp applications
Date:
Message-ID: <87u0kt7xdr.fsf@qrnik.zagroda>
GP lisper <········@CloudDancer.com> writes:
>>> - just stick all your code in one big binary, branch on argv[0]
>
> You must be a recent developer. This trick is very common, several
> bin files use it to select various sets of command line options. Look
> for symlinks within the same directory. 'Busybox' isn't as common
> nowdays with CD installs, but those floppy installs loved it.
This saves disk space at the expense of modularity / maintenance.
It's a workaround, not a good solution.
In both cases it's needed because the native way of making programs
has a big constant cost, which is better paid once instead of for each
program separately. When it's not needed from the maintenance point
of view, it's bad.
Well, in *some* cases the original commands are perhaps split too much,
e.g. most of the code of gzip and zcat is the same (they are different
interfaces for subsets of the same functionality), so they are better
put in the same program even from the maintenance point of view. But
these are only a few cases.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> GP lisper <········@CloudDancer.com> writes:
>
>>>> - just stick all your code in one big binary, branch on argv[0]
>>
>> You must be a recent developer. This trick is very common, several
>> bin files use it to select various sets of command line options. Look
>> for symlinks within the same directory. 'Busybox' isn't as common
>> nowdays with CD installs, but those floppy installs loved it.
>
> This saves disk space at the expense of modularity / maintenance.
> It's a workaround, not a good solution.
Not at all. That's the magic of lisp images: you can debug and modify
them "on the fly". While you hardly can load back a C executable to
patch a few functions, you can easily start your lisp image, break
into the debugger, get back to the top level REPL, (if your
implementation doesn't allow you to boot an image without starting the
predefined function), define or redefine stuff, load a new application
or a new verion of an old application, and re-save the image.
> In both cases it's needed because the native way of making programs
> has a big constant cost, which is better paid once instead of for each
> program separately. When it's not needed from the maintenance point
> of view, it's bad.
>
> Well, in *some* cases the original commands are perhaps split too much,
> e.g. most of the code of gzip and zcat is the same (they are different
> interfaces for subsets of the same functionality), so they are better
> put in the same program even from the maintenance point of view. But
> these are only a few cases.
It really doesn't matter much, assuming they both use the same libz
shared library.
The only debatable difference, is the way the address spaces are
separated and shared: either by the kernel, by pages, or adding a
layer with the lisp virtual machine, by references (arithmetic-less
pointers to typed memory cells.).
--
__Pascal Bourguignon__ http://www.informatimago.com/
The mighty hunter
Returns with gifts of plump birds,
Your foot just squashed one.
On Tue, 24 May 2005 12:04:48 +0200, <······@knm.org.pl> wrote:
> GP lisper <········@CloudDancer.com> writes:
>
>>>> - just stick all your code in one big binary, branch on argv[0]
>>
>> You must be a recent developer. This trick is very common, several
>> bin files use it to select various sets of command line options. Look
>> for symlinks within the same directory. 'Busybox' isn't as common
>> nowdays with CD installs, but those floppy installs loved it.
>
> This saves disk space at the expense of modularity / maintenance.
> It's a workaround, not a good solution.
The disk space savings was immediately utilized to provide a broader
command set, granting users a greater ability to solve (in the busybox
case) installation problems in 'non-standard' hardware. "Good" is
relative. I needed that ability several times, thus my evaluation of
the trick is different.
> In both cases it's needed because the native way of making programs
> has a big constant cost, which is better paid once instead of for each
> program separately. When it's not needed from the maintenance point
> of view, it's bad.
This is back to the 'Best deal is 2 out of 3' rule. Eye of the
beholder etc. "good" and "bad" remain relative judgements, different
needs, different judgements...but these cases can be written down and
determined (I have counted bytes more than once). Just handwaving and
declaring it wrong is another story.
> Well, in *some* cases the original commands are perhaps split too much,
> e.g. most of the code of gzip and zcat is the same (they are different
> interfaces for subsets of the same functionality), so they are better
> put in the same program even from the maintenance point of view. But
> these are only a few cases.
I was maintaining two sets of code recently, one dealt with a file,
the other with a unix pipe. The two programs performed indentical
manipulations on the data streams. Lisp actually made this simple to
see that I should combine them into one program with just 2 entry
point functions. My old perl way-of-thinking would have left it as
two separate files. In perl (or similar) I would have needed some
sort of dispatcher as the front end in a combination program. In a
lisp image, I get that for free....for some disk space rent.
YMMV
It's not a few cases, it can occur everyplace where there is a
datastream transformation. Look at the RAID tools, probably would
show up in crypto tools, etc.
--
With sufficient thrust, pigs fly fine.
GP lisper wrote:
> I was maintaining two sets of code recently, one dealt with a file,
> the other with a unix pipe. The two programs performed indentical
> manipulations on the data streams. Lisp actually made this simple to
> see that I should combine them into one program with just 2 entry
> point functions. My old perl way-of-thinking would have left it as
> two separate files. In perl (or similar) I would have needed some
> sort of dispatcher as the front end in a combination program. In a
> lisp image, I get that for free....for some disk space rent.
man ln.
mkb.
On Thu, 26 May 2005 04:22:03 +0200, <···@incubus.de> wrote:
> GP lisper wrote:
>
>> I was maintaining two sets of code recently, one dealt with a file,
>> the other with a unix pipe. The two programs performed indentical
>> manipulations on the data streams. Lisp actually made this simple to
>> see that I should combine them into one program with just 2 entry
>> point functions. My old perl way-of-thinking would have left it as
>> two separate files. In perl (or similar) I would have needed some
>> sort of dispatcher as the front end in a combination program. In a
>> lisp image, I get that for free....for some disk space rent.
>
> man ln.
Gee, I looked there, but I didn't find anything in PERL, nor is there
anything about DISPATCHERS. Better supply an example of whatever
straw you are grasping at.
--
With sufficient thrust, pigs fly fine.
GP lisper <········@CloudDancer.com> writes:
> On Thu, 26 May 2005 04:22:03 +0200, <···@incubus.de> wrote:
>> man ln.
>
> Gee, I looked there, but I didn't find anything in PERL, nor is there
> anything about DISPATCHERS. Better supply an example of whatever
> straw you are grasping at.
I'm guessing he was referring to the old trick of using multiple names
for the same file (symbolic or hard links), and dispatching on $0 in
your perl (or shell) program.
That way you wouldn't need two separate perl files, you could keep all
your source in one file and have two entry points, more or less like
in lisp.
...Peder...
--
I wish a new life awaited _me_ in some off-world colony.
On Fri, 27 May 2005 09:08:38 +0200, <·····@news.klingenberg.no> wrote:
> GP lisper <········@CloudDancer.com> writes:
>> On Thu, 26 May 2005 04:22:03 +0200, <···@incubus.de> wrote:
>>> man ln.
>>
>> Gee, I looked there, but I didn't find anything in PERL, nor is there
>> anything about DISPATCHERS. Better supply an example of whatever
>> straw you are grasping at.
>
> I'm guessing he was referring to the old trick of using multiple names
> for the same file (symbolic or hard links), and dispatching on $0 in
> your perl (or shell) program.
Which _I_ had discussed earlier in my post.
> That way you wouldn't need two separate perl files, you could keep all
> your source in one file and have two entry points, more or less like
> in lisp.
Nope, my point was the dispatcher in lisp is free and invisible.
Whereas in other languages, dispatcher code is required in the source.
--
With sufficient thrust, pigs fly fine.
GP lisper wrote:
> Nope, my point was the dispatcher in lisp is free and invisible.
> Whereas in other languages, dispatcher code is required in the source.
Can't you call perl subroutines with perl -e '...' in the same way you
would invoke the specific function in lisp?
Besides, I think it's better to dispatch on argv[0] (or how it's called
in perl) and use different executable names (via ln).
mkb.
GP lisper <········@CloudDancer.com> writes:
> On Fri, 27 May 2005 09:08:38 +0200, <·····@news.klingenberg.no> wrote:
>> I'm guessing he was referring to the old trick of using multiple names
>> for the same file (symbolic or hard links), and dispatching on $0 in
>> your perl (or shell) program.
>
> Which _I_ had discussed earlier in my post.
So you had. Sorry for jumping into the middle of the discussion. (I
had actually read your full post as well, but my short term memory is
lousy.)
I was confused by your anecdote about the two differen perl programs
and having to have a third perl program to act as dispatcher. I would
have combined all three into a single file from the beginning, and
dispatched on filename or argument as appropriate. In my mind, it
would then have been one program with different entry points, just as
in lisp.
> Nope, my point was the dispatcher in lisp is free and invisible.
> Whereas in other languages, dispatcher code is required in the source.
While not free, such a dispatcher in perl is literally minutes of work
to write, more or less maintenance free, and (to my eye) completely
invisible.
Not that I don't prefer the lisp way, of course, it's one of many
things that make lisp such a nice environment to program in, but I
don't think dispatcher code in the source is something to make a big
fuss about.
Besides, when delivering lisp applications, I frequently still have
dispatcher code interpreting command line arguments, so not even lisp
has completely freed me from dispatching. Not that I care.
...Peder...
--
I wish a new life awaited _me_ in some off-world colony.
Cameron MacKinnon <··········@clearspot.net> writes:
> GP lisper wrote:
>> On Mon, 23 May 2005 15:45:20 +0800, <··········@bobturf.org> wrote:
>>
>>> This often annoys me actually. What's the reason for FASL files
>>> being slow to load in say SBCL?
>> Annoyed?? Most lispers are probably wondering why you keep
>> reloading.
>
> THIS Lisper wonders why they're called "FASt Load" files if loading them
> isn't fast.
Speed is relative. The question is with respect to what they're fast?
It's faster to load these files than to load the source + compile. At
least with implementations that have a slow compiler or a compiler at
all. Or even an interpreter:
(with-open-file (out "/tmp/10000.lisp" :direction :output
:if-does-not-exist :create)
(loop for i below 10000 do
(print `(defun #1=,(intern (format nil "X~8,'0D" i)) (x)
(if (<= x 1) 1 (* x (#1# (1- x))))) out)))
[···@thalassa tmp]$ clisp -q -norc -ansi -x '(time (load "10000.lisp"))'
[1]>
Real time: 1.839754 sec.
Run time: 1.84 sec.
Space: 14171040 Bytes
GC: 5, GC time: 0.73 sec.
T
[···@thalassa tmp]$ clisp -q -norc -ansi -x '(time (compile-file "10000.lisp"))'
[1]>
Real time: 304.04483 sec.
Run time: 269.13 sec.
Space: 387055752 Bytes
GC: 203, GC time: 20.24 sec.
#P"/tmp/10000.fas" ;
NIL ;
NIL
[···@thalassa tmp]$ clisp -q -norc -ansi -x '(time (load "10000.fas"))'
[1]>
Real time: 1.453715 sec.
Run time: 1.44 sec.
Space: 6811016 Bytes
GC: 3, GC time: 0.31 sec.
T
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live