Deploying Common LISP?

[Archenoth]

Heyas all..!

I am relatively new to Common LISP, so bear with me here. I have been
reading through Practical Common LISP and reading questions and answers
about the language on here and Stackoverflow, for the most part everything
about the language seems spiffy, except for one thing...

If I were to write an application in Common LISP for others, how would I
go about deploying it?

The problem is the not everyone has the environment needed to run anything
I code... I am aware of exporting executable images, but those are often
really cumbersome and large. Is there a way of delivering a stripped down
image maybe? How would I handle dependencies? Would I only be able to send
code to those who have a LISP runtime in place? What is the preferred
means of deployment for a Common LISP application?

Thanks.

--
The arch foe

[Marco Antoniotti]

Define "really cumbersome and large" in the days when a 1Tb disk is more or less 70 EUR.

Cheers
--
MA

[Cor]

Most ignorant people do not care anymore about clockticks or diskspace.
Onve upom a time both where at a premium ticks cost dollars per
second and diskspace was $10K per 1024 kilo BYTES. (1 Mb for the newbies)

c,

--
Slaven hebben geen recht op zelfverdediging, mensen ook niet vlg de UN
Dieren hebben recht op een gezonde plaats, mijn bord en het bos zijn dat
In dit huis noemen we slechte jagers vegetarier
http://www.nerdstein.nl

[Aatu Koskensilta]

Cor <c...@clsnet.nl> writes:

> Most ignorant people do not care anymore about clockticks or diskspace.

This is true, but only because these days most people, ignorant or
otherwise, care little about such things.

> Onve upom a time both where at a premium ticks cost dollars per
> second and diskspace was $10K per 1024 kilo BYTES. (1 Mb for the newbies)

When I was a wee lad there were no cell phones, computers were built
out of paper clips and navel lint, and all we had to eat was cold poison
-- on a good day. What of it? This sort of nostalgic grumbling, over how
easy the kids of today have it and so on, is no doubt a constant of
human nature, but usually, as in this instance, a bit silly and of no
apparent relevance.

--
Aatu Koskensilta (aatu.kos...@uta.fi)

"Wovon man nicht sprechen kann, darüber muss man schweigen"
- Ludwig Wittgenstein, Tractatus Logico-Philosophicus

[Marco Antoniotti]

I also pine for the time when people were actually roasting their coffee beans on a wood-carbon fire. It usually happens when I sip my cappuccino that the vending machine just prepared me.

Cheers
--
MA

PS. Wittgenstein sprached too much. :)

[Archenoth]

On Tue, 27 Nov 2012 23:02:56 -0700, Marco Antoniotti <mar...@gmail.com>
wrote:

I mean 20MB "Hello world" large... I know things like SBCL include an
entire REPL when you export the executable image, but there's gotta be a
way to cut that down to only support the required functionality, right?

And it's not just hard disk space I'm worried about either, but rather how
long it takes to download on a slow connection such as my own.

--
The arch foe

[Burton Samograd]

Archenoth <Arch...@live.something> writes:

> On Tue, 27 Nov 2012 23:02:56 -0700, Marco Antoniotti

> I mean 20MB "Hello world" large... I know things like SBCL include an
> entire REPL when you export the executable image, but there's gotta be
> a way to cut that down to only support the required functionality,
> right?
>
> And it's not just hard disk space I'm worried about either, but rather
> how long it takes to download on a slow connection such as my own.

Some (most?) commercial lisps contain a 'tree shaker' that will remove
the unneeded portions of the lisp runtime and create smaller
executables. This feature is lacking in AFAIK all open-source lisps.
ECL (Embedded Common Lisp) generally creates the smallest executables
due to it's compile to C nature but it still requires a fairly
substantial shared library that contains the rest of the lisp runtime;
this solves the huge Hello World problem, but the library still needs to
be deployed.

--
Burton Samograd

[Raymond Wiker]

Aatu Koskensilta <aatu.kos...@uta.fi> writes:

> Cor <c...@clsnet.nl> writes:
>
>> Most ignorant people do not care anymore about clockticks or diskspace.
>
> This is true, but only because these days most people, ignorant or
> otherwise, care little about such things.
>
>> Onve upom a time both where at a premium ticks cost dollars per
>> second and diskspace was $10K per 1024 kilo BYTES. (1 Mb for the newbies)
>
> When I was a wee lad there were no cell phones, computers were built
> out of paper clips and navel lint, and all we had to eat was cold poison
> -- on a good day. What of it? This sort of nostalgic grumbling, over how
> easy the kids of today have it and so on, is no doubt a constant of
> human nature, but usually, as in this instance, a bit silly and of no
> apparent relevance.

Efficiency and sensible resource usage is still as important, the moment
the problems become big enough. The main difference is that previously,
you had linear degradation of performance, while current hardware is so
powerful that everything looks great until the moment it breaks
completely.

[Pascal J. Bourguignon]

Aatu Koskensilta <aatu.kos...@uta.fi> writes:

> Cor <c...@clsnet.nl> writes:
>
>> Most ignorant people do not care anymore about clockticks or diskspace.
>
> This is true, but only because these days most people, ignorant or
> otherwise, care little about such things.
>
>> Onve upom a time both where at a premium ticks cost dollars per
>> second and diskspace was $10K per 1024 kilo BYTES. (1 Mb for the newbies)
>
> When I was a wee lad there were no cell phones, computers were built
> out of paper clips and navel lint, and all we had to eat was cold poison
> -- on a good day. What of it? This sort of nostalgic grumbling, over how
> easy the kids of today have it and so on, is no doubt a constant of
> human nature, but usually, as in this instance, a bit silly and of no
> apparent relevance.

Yes. That's why it's a bit silly to ask things like:

"Is there a way of delivering a stripped down image maybe? How would
I handle dependencies? Would I only be able to send code to those
who have a LISP runtime in place?"

--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.

[Pascal J. Bourguignon]

Archenoth <Arch...@live.something> writes:

> I mean 20MB "Hello world" large... I know things like SBCL include an
> entire REPL when you export the executable image, but there's gotta be
> a way to cut that down to only support the required functionality,
> right?

Right. The way is to use ecl.

> And it's not just hard disk space I'm worried about either, but rather
> how long it takes to download on a slow connection such as my own.

You should not download binary code anyways. Sources are much smaller.

[Archenoth]

On Wed, 28 Nov 2012 08:20:38 -0700, Burton Samograd <bur...@samograd.ca>
wrote:

ECL huh?

I took a look into it and this does look like it will solve my problems.
Yes I may need a library, but this library appears to be easily
installable via a package manager, so I could just include it as a
dependency when deploying the application package for various Linux
distros. The executables are also small. (39KB for hello world this time)

This was one of the main concerns holding me back when I was looking into
this language. It had some cool features, but the ability to give
non-lispers the result of my work and have them be able to run it without
having to walk them through setting up an environment first was definitely
something I wanted to be able to do.

Some reading tells me that ECL has limitations, I'll have to take a deeper
look at those, but I'm sure I'll manage.

Thanks Burton, this was the answer I was looking for..!

--
The arch foe

[Archenoth]

On Wed, 28 Nov 2012 11:39:27 -0700, Pascal J. Bourguignon
<p...@informatimago.com> wrote:

> Archenoth <Arch...@live.something> writes:
>
>> I mean 20MB "Hello world" large... I know things like SBCL include an
>> entire REPL when you export the executable image, but there's gotta be
>> a way to cut that down to only support the required functionality,
>> right?
>
> Right. The way is to use ecl.
>
>
>> And it's not just hard disk space I'm worried about either, but rather
>> how long it takes to download on a slow connection such as my own.
>
> You should not download binary code anyways. Sources are much smaller.
>

Perhaps, but this size concern is not specifically for me, but rather
people I may eventually want to write things for.

--
The arch foe

[Zach Beane]

Archenoth <Arch...@live.something> writes:

> ECL huh?
>
> I took a look into it and this does look like it will solve my
> problems. Yes I may need a library, but this library appears to be
> easily installable via a package manager, so I could just include it
> as a dependency when deploying the application package for various
> Linux distros. The executables are also small. (39KB for hello world
> this time)
>
> This was one of the main concerns holding me back when I was looking
> into this language. It had some cool features, but the ability to give
> non-lispers the result of my work and have them be able to run it
> without having to walk them through setting up an environment first
> was definitely something I wanted to be able to do.

What does your application do?

Zach

[Archenoth]

I don't have an application.

I intended on learning the language, or a variant thereof, but I was
hesitant to. The reason I was hesitant about Common LISP in particular was
the inability to write things that I could give other people with relative
ease. I didn't want to learn something that only I could use.

It's cool being able to do awesome things in a language, but if someone
were to say "Hey Archenoth! Could you write something that did blah blah
herpaderp for me?", being able to write it in Common LISP would be even
cooler. And being able to write something that I can make a package of to
deploy to wider audiences was also something I was hoping to do eventually.

So I needed to verify that this capability existed before choosing a
variant. Not before getting my feet wet with how the language works
though, which was why I was working my way through PCL.

--
The arch foe

[Zach Beane]

Archenoth <Arch...@live.something> writes:

>>
>> What does your application do?
>>
>> Zach
>
> I don't have an application.
>
> I intended on learning the language, or a variant thereof, but I was
> hesitant to. The reason I was hesitant about Common LISP in particular
> was the inability to write things that I could give other people with
> relative ease. I didn't want to learn something that only I could
> use.
>
> It's cool being able to do awesome things in a language, but if
> someone were to say "Hey Archenoth! Could you write something that did
> blah blah herpaderp for me?", being able to write it in Common LISP
> would be even cooler. And being able to write something that I can
> make a package of to deploy to wider audiences was also something I
> was hoping to do eventually.

Has that evere happened to you before?

Zach

[Archenoth]

Yes. I ended up writing it in C though with odd bits of Delphi for
interface work. (Yeah, yeah, I know, quiet you!)

--
The arch foe

[Frode V. Fjeld]

Archenoth <Arch...@live.something> writes:

> Perhaps, but this size concern is not specifically for me, but rather
> people I may eventually want to write things for.

Why would you be concerned about having your system optimized for
delivering "Hello World!"-equivalent programs? It's probably possible to
do this with CL, but I don't expect anyone to find it worthwhile.

--
Frode V. Fjeld

[Espen Vestre]

Archenoth <Arch...@live.something> writes:

> I mean 20MB "Hello world" large... I know things like SBCL include an
> entire REPL when you export the executable image, but there's gotta be
> a way to cut that down to only support the required functionality,
> right?

LispWorks has delivery options that will give you smaller executables
than that, but you still typically end up with a 4MB "Hello World".

> And it's not just hard disk space I'm worried about either, but rather
> how long it takes to download on a slow connection such as my own.

Think again: Is this *really* a problem in 2012? The compressed
installers of the application I create with LispWorks are typically
~13MB large. My DSLR needs more than that for one single picture! And IF
there should be some poor soul out there who is still using e.g. ISDN,
download time will still be less than 5 minutes.

But of course, if an RFC 1149 implementation is your only available
internet connection, you may still have a point ;-)
--
(espen)

[Archenoth]

On Thu, 29 Nov 2012 02:00:20 -0700, Frode V. Fjeld <fro...@gmail.com>
wrote:

I'm not concerned with Hello World programs in the least...
I simply used Hello World as a test to see how things are deployed in CL.

--
The arch foe

[Archenoth]

I don't think it's a problem for most people, but I don't like to exclude
those that it would be. It also feels just, well, wrong. (But that's
subjective I suppose)

--
The arch foe

[Bigos]

On 28/11/12 06:02, Marco Antoniotti wrote:
>> --
>>
>> The arch foe
>
> Define "really cumbersome and large" in the days when a 1Tb disk is more or less 70 EUR.
>
> Cheers
> --
> MA
>

Not everyone has as much money as you have.

[Bigos]

If you are not bothered about making your code available to others I
would suggest distributing the source.

There's a very cool project called quicklisp which would take care of
your dependencies.

I would distribute an installation script that would install and
configure a lisp environment for your users.

I did some calculations and had a shock. if all files in my /usr/bin
were lisp images it would be over 20GB.

[Marco Antoniotti]

No. But usually people with less money have other concerns than Lisp programming.

Cheers
--
MA

[Raymond Wiker]

What size would they be if they were statically linked? What
size would they be if were implemented in Lisp using a similar mechanism
to dynamic libraries?

[Pascal J. Bourguignon]

Bigos <ruby....@googlemail.com> writes:

> I did some calculations and had a shock. if all files in my /usr/bin
> were lisp images it would be over 20GB.

So little? I could load them all in my RAM!

[Archenoth]

On Mon, 03 Dec 2012 01:29:26 -0700, Marco Antoniotti <mar...@gmail.com>
wrote:

It's not the programmer, but rather the person who gets to run the program
in the end.

--
The arch foe

[Bigos]

On 03/12/12 19:16, Pascal J. Bourguignon wrote:
> Bigos <ruby....@googlemail.com> writes:
>
>> I did some calculations and had a shock. if all files in my /usr/bin
>> were lisp images it would be over 20GB.
>
> So little? I could load them all in my RAM!
>
>

:-P I'd love to see the specification of your machine.

I know I sound daft when I mention the 20GB, but it would be lovely and
cool if you could compile a lisp program to a small executable.

At the moment CL is like a huge and powerful truck that lacks of some
flexibility of a small car. It might be the most powerful in the world
but most people either don't needs it's power, or don't know it's available.

Perhaps it's not possible with CL but I wonder if here was a project
where somebody would try to write a Lisp compiler (not CL) that would
create small executables.

I wonder how much would have to be stripped off contemporary Lisp
specifications to make such compilation possible.

[Bigos]

On 03/12/12 17:52, Raymond Wiker wrote:

> Bigos <ruby....@googlemail.com> writes:
>> I did some calculations and had a shock. if all files in my /usr/bin
>> were lisp images it would be over 20GB.
>
> What size would they be if they were statically linked? What
> size would they be if were implemented in Lisp using a similar mechanism
> to dynamic libraries?
>

good question

[Archenoth]

On Mon, 03 Dec 2012 14:55:45 -0700, Bigos <ruby....@googlemail.com>
wrote:

Well, the answer I got was pretty adequate for this...

> ECL (Embedded Common Lisp) generally creates the smallest executables
> due to it's compile to C nature but it still requires a fairly
> substantial shared library that contains the rest of the lisp runtime;
> this solves the huge Hello World problem, but the library still needs to
> be deployed.

It requires a 16MB library, but the executables it creates are small...
And if you have a lot of them, the resulting size is much smaller.

http://ecls.sourceforge.net/

Is this what you're looking for?

--
The arch foe

[Bigos]

On 03/12/12 23:38, Archenoth wrote:

>
>> ECL (Embedded Common Lisp) generally creates the smallest executables
>> due to it's compile to C nature but it still requires a fairly
>> substantial shared library that contains the rest of the lisp runtime;
>> this solves the huge Hello World problem, but the library still needs to
>> be deployed.
>
> It requires a 16MB library, but the executables it creates are small...
> And if you have a lot of them, the resulting size is much smaller.
>
> http://ecls.sourceforge.net/
>
> Is this what you're looking for?
>

I'll give it a try. One library is not a problem.

[Pascal J. Bourguignon]

Bigos <ruby....@googlemail.com> writes:

> On 03/12/12 19:16, Pascal J. Bourguignon wrote:
>> Bigos <ruby....@googlemail.com> writes:
>>
>>> I did some calculations and had a shock. if all files in my /usr/bin
>>> were lisp images it would be over 20GB.
>>
>> So little? I could load them all in my RAM!
>>
>>
>
> :-P I'd love to see the specification of your machine.
>
> I know I sound daft when I mention the 20GB, but it would be lovely
> and cool if you could compile a lisp program to a small executable.

People keep forgetting that we have something very few language
ecosystem has: we have tens of implementations!

Lisp500 is a subset of Common Lisp. If you want to deliver small
programs, you can develop with SBCL programs that will run on lisp500.

Or if you need a full CL implementation, you can use ecl, and like any
other modern unix program, use shared libraries including
/usr/lib/libecl.so.


> [pjb@kuiper :0 ecldemo]$ ./ecldemo

> (* 3 4)

12
> (list-all-packages)

(#<"FFI" package> #<"GRAY" package> #<"MP" package> #<"CLOS" package>
#<"SI" package> #<"KEYWORD" package> #<"COMMON-LISP-USER" package>
#<"COMMON-LISP" package>)
> (si:exit)
[pjb@kuiper :0 ecldemo]$ ls -l ecldemo
-rwxr-xr-x 1 pjb pjb 12715 Dec 4 00:59 ecldemo*
[pjb@kuiper :0 ecldemo]$ strip ecldemo
[pjb@kuiper :0 ecldemo]$ ls -l ecldemo
-rwxr-xr-x 1 pjb pjb 10376 Dec 4 01:00 ecldemo*
[pjb@kuiper :0 ecldemo]$

----(ecldemo.c)---------------------------------------------------------
/* -*- mode:c; coding:us-ascii */

/* Example of a C program embedding ECL with callbacks to C functions. */
/* Compiled via: gcc ecldemo.c -lecl */

#include <stdio.h>
#include <stdlib.h>
#include "ecl/ecl.h"

#define DEFUN(name,fun,args) \
cl_def_c_function(c_string_to_object(name), \
(cl_objectfn_fixed)fun, \
args)

cl_object foo() {
return ecl_make_integer(42);
}

cl_object bar(cl_object a, cl_object b) {
int aval = fix(a);
int bval = fix(b);
return ecl_make_integer(aval + bval);
}

/*
Assumes the string is a valid call.
*/
cl_object ecl_call(char *call) {
return cl_safe_eval(c_string_to_object(call), Cnil, Cnil);
}

void init() {
cl_boot(1, (char **)&"");

atexit(cl_shutdown);

/*
Uncomment these lines to place your code into a separate package,
They may then be called like (my-code:foo)
*/
// ecl_call("(make-package :my-code)");
// ecl_call("(in-package my-code)");

DEFUN("foo", foo, 0);
DEFUN("bar", bar, 2);

// ecl_call("(export foo)");
// ecl_call("(export bar)");
// ecl_call("(in-package common-lisp-user)");
}

int main() {
init();
cl_object exit_obj = c_string_to_object(":EXIT");
cl_object result = Cnil;

while (cl_equal(exit_obj, result) == Cnil) {
printf("\n> ");
fflush(stdout);
cl_object form = ecl_call("(read)");
result = cl_safe_eval(form, Cnil, Cnil);
cl_print(1, result);
}
putchar('\n');

return 0;
}
------------------------------------------------------------------------

> At the moment CL is like a huge and powerful truck that lacks of some
> flexibility of a small car.

No, you are entirely wrong.

CL is a shop with bicycles, sedans, trucks, camions, trains, transport
airplanes, fighter jets, rockets, and UFOs.

You get to choose which one you use.

> It might be the most powerful in the world
> but most people either don't needs it's power, or don't know it's
> available.

Yes, people may need more information.

> Perhaps it's not possible with CL but I wonder if here was a project
> where somebody would try to write a Lisp compiler (not CL) that would
> create small executables.

Smaller than ten thousand three hundred and seventy six bytes for a
64-bit hello world that contains a whole CL implementation?

> I wonder how much would have to be stripped off contemporary Lisp
> specifications to make such compilation possible.

Absolutely nothing.

[Zach Beane]

Bigos <ruby....@googlemail.com> writes:

> On 03/12/12 19:16, Pascal J. Bourguignon wrote:
>> Bigos <ruby....@googlemail.com> writes:
>>
>>> I did some calculations and had a shock. if all files in my /usr/bin
>>> were lisp images it would be over 20GB.
>>
>> So little? I could load them all in my RAM!
>>
>>
>
> :-P I'd love to see the specification of your machine.
>
> I know I sound daft when I mention the 20GB, but it would be lovely
> and cool if you could compile a lisp program to a small executable.

It would be pretty cool.

I think what generates so much discussion around this topic is the
notion that it's a prerequisite to even *starting* to use Common
Lisp. To think that way, to me, is to put the cart before the horse.

Zach

[Espen Vestre]

Zach Beane <xa...@xach.com> writes:

> I think what generates so much discussion around this topic is the
> notion that it's a prerequisite to even *starting* to use Common
> Lisp. To think that way, to me, is to put the cart before the horse.

It's a very boring and silly variant of more general problem of
premature optimization.

I have a 44 byte Common Lisp "Hello World" program. It looks like this:

----------
#!/usr/bin/lws

(format t "Hello World!~%")
----------

"lws" is our internal lispworks-based "lisp shell interpreter" which we
use for all kinds of small utility programs (like most of the stuff in
/usr/bin ;-)). It has not been optimized for disk space, so it weighs in
at - GASP! - 44 MB - which is more than the entire disk of the mac I
wrote fancy computational linguistics software on in 1990....

Has anyone made such a "lisp shell" out of one of the free lisps? It
would be both a useful tool and an easy way to stop these silly
discussions, and whenever someone drags in the "but it's interpreted..."
argument, just tell them to make their lisp script a simple load form
for a tiny fasl file...
--
(espen)

[Pascal J. Bourguignon]

It would NOT stop those silly discussions,
for the simple reason that almost all the current CL implementations are
usable as script interpreter already!

I use /usr/bin/clisp for all my scripting needs.
Check:
http://git.informatimago.com/viewgit/index.php?a=viewblob&p=public/bin&h=c6a153ad2034ccaf4f741d6f7838e8c55d03b995&hb=ec2d3f9ca133794a5e6d427636a9aed30f2248e5&f=LISP-SCRIPTS.txt
in:
http://git.informatimago.com/viewgit/index.php?a=tree&p=public/bin&h=d6f2615422cc8a99f897ef60864b8b2e0f765aa6&hb=ec2d3f9ca133794a5e6d427636a9aed30f2248e5

[Christophe Rhodes]

Espen Vestre <es...@vestre.net> writes:

> Has anyone made such a "lisp shell" out of one of the free lisps? It
> would be both a useful tool and an easy way to stop these silly
> discussions, and whenever someone drags in the "but it's interpreted..."
> argument, just tell them to make their lisp script a simple load form
> for a tiny fasl file...

I was about to post saying substantively what Pascal said, namely that
things are already usable like this, and that sbcl (at least) also makes
its fasls directly executable on unix systems (by having the start of
the fasl header be a shebang line). So the idea is that you can do

$ cat hello.lisp
(format t "Hello, World!~%")
$ sbcl --eval '(compile-file "hello.lisp") </dev/null >/dev/null
$ chmod +x hello.fasl
$ time ./hello.fasl
Hello, World!

real 0m0.008s
user 0m0.000s
sys 0m0.004s
$ ls -l hello.fasl
-rwxr-xr-x 1 csr21 csr21 734 Dec 4 20:46 hello.fasl

And this does actually work, but only in my current development tree,
not for any release SBCL has made in the last 18 months, when a commit
was made that broke that functionality. In the intervening time, we
have received zero bug reports about it, which might indicate how much
demand there really is for such a feature...

Christophe

[Zach Beane]

This is a good response for "But 'hello world' is so big!", but I don't
use SBCL for scripting because most of the stuff I want to do requires
loading external libraries, and SBCL is slow and verbose at loading
them.

It makes me wish something like steeldump still worked.

Zach

[No One]

This is actually one of the things that drove me from CL to Scheme. I tried ECL, but it just doesn't support enough libraries for the kind of work I do. With Chicken Scheme and Gambit, I get code that compiles to C, gives easy access to C libraries, then compiles to executables that are portable, fast and small. Chicken, in particular, has a large set of well-written libraries that get the job done for me. For scripting, I use Guile. I'd prefer CL, but in my use-case, I'm writing apps, scripts and webapps to do day to day chores in a large, on-going web development effort. Scheme makes that easy to develop and to distribute across a dozen or more servers. CL, in my experience, makes that kind of work harder than it has to be, though it may be perfect for other kinds of work.

Norm

[Antsan]

I didn't know fasls where supposed to be executable, so I didn't file a bug report.

[Espen Vestre]

Christophe Rhodes <cs...@cantab.net> writes:

> $ time ./hello.fasl
> Hello, World!
>
> real 0m0.008s
> user 0m0.000s
> sys 0m0.004s
> $ ls -l hello.fasl
> -rwxr-xr-x 1 csr21 csr21 734 Dec 4 20:46 hello.fasl

Hey, that's really nice :-)

> And this does actually work, but only in my current development tree,
> not for any release SBCL has made in the last 18 months, when a commit
> was made that broke that functionality. In the intervening time, we
> have received zero bug reports about it, which might indicate how much
> demand there really is for such a feature...

Well, we actually use this quite a bit, but only for small scripts that
are actually put to production. I suspect that the reason for the not so
high demand, is that the vast majority of "lisp scripting" being done is
done by programmers from within their lisp development environment.
--
(espen)

[Christophe Rhodes]

Antsan <thomas.b...@gmail.com> writes:

> I didn't know fasls where supposed to be executable, so I didn't file
> a bug report.

Well, now you do. Sorry for the inconvenience.

Christophe

[Christophe Rhodes]

Espen Vestre <es...@vestre.net> writes:

>> And this does actually work, but only in my current development tree,
>> not for any release SBCL has made in the last 18 months, when a commit
>> was made that broke that functionality. In the intervening time, we
>> have received zero bug reports about it, which might indicate how much
>> demand there really is for such a feature...
>
> Well, we actually use this quite a bit, but only for small scripts that
> are actually put to production. I suspect that the reason for the not so
> high demand, is that the vast majority of "lisp scripting" being done is
> done by programmers from within their lisp development environment.

To be clear, what was broken was the execution of fasls. The execution
of lisp source scripts has worked throughout the period. (And what Xach
says is true, that this in SBCL is a good solution for the "Hello,
World" problem, and also for cases when a core with all or most
dependencies can be saved, but it's not so good where large systems need
to be loaded from fasls, as startup time then tends to become
prohibitively long).

Christophe

[Espen Vestre]

Christophe Rhodes <cs...@cantab.net> writes:

> but it's not so good where large systems need to be loaded from fasls,
> as startup time then tends to become prohibitively long).

Sure, but those big systems are quite different from a typical /usr/bin
tool - e.g. /usr/bin/yes ;-)
--
(espen)

[Zach Beane]

No One <ats...@gmail.com> writes:

>> This is a good response for "But 'hello world' is so big!", but I don't
>> use SBCL for scripting because most of the stuff I want to do requires
>> loading external libraries, and SBCL is slow and verbose at loading
>> them.
>>
>> It makes me wish something like steeldump still worked.
>>
>> Zach
>
> This is actually one of the things that drove me from CL to Scheme. I
> tried ECL, but it just doesn't support enough libraries for the kind
> of work I do. With Chicken Scheme and Gambit, I get code that compiles
> to C, gives easy access to C libraries, then compiles to executables
> that are portable, fast and small. Chicken, in particular, has a large
> set of well-written libraries that get the job done for me. For
> scripting, I use Guile. I'd prefer CL, but in my use-case, I'm writing
> apps, scripts and webapps to do day to day chores in a large, on-going
> web development effort. Scheme makes that easy to develop and to
> distribute across a dozen or more servers. CL, in my experience, makes
> that kind of work harder than it has to be, though it may be perfect
> for other kinds of work.

I don't use SBCL for scripting, but I still do use it for everyday
command-line tools. I just build binaries and don't care much that
they're pretty big. Buildapp makes it very convenient. I've also found
that the library support for SBCL is very good; I think that's because
it's the implementation of Common Lisp with the most users.

Zach

[Burton Samograd]

Antsan <thomas.b...@gmail.com> writes:

> I didn't know fasls where supposed to be executable, so I didn't file
> a bug report.

It would be great if they were again. That's a pretty awesome feature
that would solve the big hello world problem once and for all.

--
Burton

[Teemu Likonen]

Zach Beane [2012-12-04 15:57:07 -0500] wrote:

> I don't use SBCL for scripting because most of the stuff I want to do
> requires loading external libraries, and SBCL is slow and verbose at
> loading them.

I use SBCL for scripting. I just create my own image that includes all
the needed libraries. The same image runs all my CL scripts.

#!/usr/local/bin/my-sbcl-script-image --script

[Zach Beane]

I've thought about doing something like that, too. What do you consider
the critical libraries?

Zach

[Teemu Likonen]

Zach Beane [2012-12-06 06:21:55 -0500] wrote:

> Teemu Likonen <tlik...@iki.fi> writes:
>> I use SBCL for scripting. I just create my own image that includes
>> all the needed libraries. The same image runs all my CL scripts.

> I've thought about doing something like that, too. What do you
> consider the critical libraries?

Actually I don't use bare #! scripts much. I have one small #! launcher
script named "run-sbcl" and symlinks which point to this launcher. The
launcher loads my custom SBCL image which uses symlink's name to find
the actual program which is located elsewhere (.fasl or .lisp).

Basically the functionality is same as having bare #! scripts except
that my SBCL image automatically tries to load a fasl file and compiles
it from .lisp file if an up-to-date fasl is not found.

Currently I build the image with these libraries:

alexandria
babel
cffi
cl-ppcre
decimals
iconv
iolib.os
iolib.pathnames
iolib.syscalls
local-time
pathname-convert
quicklisp
split-sequence
unix-options
voikko

"Pathname-convert" is my own SBCL-specific library for converting
pathnames back and forth. "Voikko" is an interface for Finnish
spell-checker and hyphenation library (libvoikko).

[Juanjo]

On Wednesday, December 5, 2012 1:23:09 AM UTC+1, No One wrote:
>
> This is actually one of the things that drove me from CL to Scheme. I tried ECL, but it just doesn't support enough libraries for the kind of work I do.

Let's rather leave it at "not enough libraries support it", which is a quite different statement :-)

Juanjo

[fum...@yahoo.com]

On Tuesday, November 27, 2012 10:02:56 PM UTC-8, Marco Antoniotti wrote:
>
> Define "really cumbersome and large" in the days when a 1Tb disk is more or less 70 EUR.
>
> Cheers
> --
> MA

Why are people in c.l.l. are so dense lately...

[Rob Warnock]

<fum...@yahoo.com> wrote:
+---------------

| Marco Antoniotti wrote:
| > Define "really cumbersome and large" in the days when a 1Tb disk is more or less 70 EUR.
|

| Why are people in c.l.l. are so dense lately...

+---------------

I dunno, maybe because the trolls are more fluffy than usual?


-Rob

-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <http://rpw3.org/>
San Mateo, CA 94403

[derrr_fhurer]

On Tuesday, November 27, 2012 7:18:31 PM UTC-5, Archenoth wrote:
> Heyas all..!
>
> I am relatively new to Common LISP, so bear with me here. I have been
> reading through Practical Common LISP and reading questions and answers
> about the language on here and Stackoverflow, for the most part everything
> about the language seems spiffy, except for one thing...
>
> If I were to write an application in Common LISP for others, how would I
> go about deploying it?
>
> The problem is the not everyone has the environment needed to run anything
> I code... I am aware of exporting executable images, but those are often
> really cumbersome and large. Is there a way of delivering a stripped down
> image maybe? How would I handle dependencies? Would I only be able to send
> code to those who have a LISP runtime in place? What is the preferred
> means of deployment for a Common LISP application?
>
> Thanks.
>
> --
> The arch foe

copy file to target server, load with lisp, done

[Marco Antoniotti]

"Lately"? I posted that 2 years ago. The price per Tb has dropped since. 3:)

Cheers
--
MA