[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.lisp

cl-launch 4.1.2: multicall binaries

Faré

4/1/2015 9:53:00 AM

I just released cl-launch 4.1.2, which minimally implements support
for a --dispatched-entry feature that's mostly compatible with Xach's
buildapp. Differences are:

1- like cl-launch in general, it works on all command-line Lisp
implementations supported by ASDF,
not just on SBCL and CCL

2- I don't do as much error checking as Xach; in case of conflict,
last one wins.

3- I accept UIOP-style function designators for the main function, not
just symbol designators, see uiop:ensure-function.



Background:
a- I'm more and more replacing my shell-scripts with CL scripts, as described in my papers from last year about Lisp now being an acceptable scripting language.

b- One missing piece, though, was that the startup time of a script can be noticeably high if we load from fasl every time, even when no compilation is needed: a simple script I write typically takes 2 seconds to start, despite my using caching for the source-registry, just for loading all the fasl's.

c- Dumping an image instead of dynamically loading the code from fasl's every time leads to nearly instantaneous start times; however, dumping one image per script is expensive, with the smallest CL implementation (CLISP) taking about 16MB for a simple script.

d- Therefore, I implemented --dispatched-entry in a way mostly compatible with
buildapp, to let the user build a "multi-call binary" in the genre of busybox. I can then dump a single image for all my scripts, and they start super fast, evaluate super fast, and only occupy those those tens of megabytes once.

e- This --dispatched-entry feature is implemented as a thin layer that delegates
everything to a small new library call cl-launch-dispatch
distributed with cl-launch. That means it will actually slow things
down a tiny bit if you use it without dumping an image, but won't slow
things down at all if you don't use it and don't dump an image.

http://cliki.net...

One fewer reason not to use CL for all your scripting needs, including as accessible from other programs.

—?ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare...
The whole modern world has divided itself into Conservatives and Progressives.
The business of Progressives is to go on making mistakes. The business of the
Conservatives is to prevent the mistakes from being corrected.
— G.K. Chesterton
2 Answers

Max Rottenkolber

4/3/2015 11:34:00 AM

0

On Wed, 01 Apr 2015 02:53:25 -0700, Faré wrote:

> d- Therefore, I implemented --dispatched-entry in a way mostly
> compatible with buildapp, to let the user build a "multi-call binary" in
> the genre of busybox. I can then dump a single image for all my scripts,
> and they start super fast, evaluate super fast, and only occupy those
> those tens of megabytes once.
>
> e- This --dispatched-entry feature is implemented as a thin layer that
> delegates everything to a small new library call cl-launch-dispatch
> distributed with cl-launch. That means it will actually slow things down
> a tiny bit if you use it without dumping an image, but won't slow things
> down at all if you don't use it and don't dump an image.

May I ask why you don't just keep your Lisp running? E.g. I use Emacs as
my primary UI, it is started when I log in, along with a CCL instance. In
Emacs I have functions to execute arbitrary CL code. Running a script for
me is:

(package:some-function ...)[C-x e]

(Even including some job management, etc.)

Why do you try to force CL into the UNIX world and not the other way
around? I found it easier and more powerful to enslave a UNIX to a Lisp
instead of the other way around.

I have seen the busybox-style executable in other projects with multiple
sub programs but compiling your shell scripts into your shell seems weird.

Zach Beane

4/3/2015 12:55:00 PM

0

Max Rottenkolber <max@mr.gy> writes:

> May I ask why you don't just keep your Lisp running? E.g. I use Emacs as
> my primary UI, it is started when I log in, along with a CCL instance. In
> Emacs I have functions to execute arbitrary CL code. Running a script for
> me is:
>
> (package:some-function ...)[C-x e]
>
> (Even including some job management, etc.)

I do that most of the time, too.

> Why do you try to force CL into the UNIX world and not the other way
> around? I found it easier and more powerful to enslave a UNIX to a Lisp
> instead of the other way around.

For me, it's mostly to run things at boot time or from cron.

Zach