Hello,
No, I'm not a newcomer wanting you to teach me Common Lisp; Peter
Seibel
does the job quite nice with his Practical Common Lisp and I can
already
make Common Lisp libraries (making the packages, making the asdf
definitions, etc. But so far, I didn't manage to make a program. Te be
able
to have a meaningful answer, I'll have to make a meaninful question,
so let
me define what a program is, for me at least.
A program, let's call it helloworld should work this way:
$ apt-get install
# helloworld gets installed, alternative it may be installed with rpm,
urpmi, yast, emerge, ports, whatever.
# helloworld dependencies get installed, this may or may not include
lisp
libraries, and a CL implementation.
$ helloworld
# helloworld runs and entertains its user for about 5 picoseconds.
That is, the user shouldn't be aware that the program was written in
lisp,
or that it is being interpreted or whatever.
Some people recommended me to ship an image, and even then I'd need a
script. I don't like this solution because I'll be re-shipping all the
libraries that the target host already has or may have by simple
dependencies (that is, when I program in C, I do shared compiling, not
static compiling). And the size is a problem, lots of mb for
helloworld
doesn't make sense.
I could ship a script that runs my favourite CL implementation, but
I'd like
to be a bit more portable than that. So, maybe there's already a
script, or
script generator, that may run an option of some CL implementations,
or
something like that. I don't know. I've asked several times on #lisp
at
freenode without getting anywhere.
A couple of notes:
- This is not a rant, I just want a solution.
- I don't care about Windows or other non-posix-like OSs.
Thank you very much!
--
J. Pablo Fernández <······@pupeno.com> (http://pupeno.com)
P� Sat, 04 Aug 2007 13:33:32 +0200, skrev <······@pupeno.com>:
>
> Some people recommended me to ship an image, and even then I'd need a
> script. I don't like this solution because I'll be re-shipping all the
> libraries that the target host already has or may have by simple
> dependencies (that is, when I program in C, I do shared compiling, not
> static compiling). And the size is a problem, lots of mb for
> helloworld
> doesn't make sense.
>
> I could ship a script that runs my favourite CL implementation, but
> I'd like
> to be a bit more portable than that. So, maybe there's already a
> script, or
> script generator, that may run an option of some CL implementations,
> or
> something like that. I don't know. I've asked several times on #lisp
> at
> freenode without getting anywhere.
>
> A couple of notes:
> - This is not a rant, I just want a solution.
> - I don't care about Windows or other non-posix-like OSs.
>
Common Lisp doesn't provide a way of generating applications.
Many Lisp implementations however do.
If you are creating a program it is a binary.
It is locked to a architecture and a that compiler.
There is no way to distribute source code and have it run on any system.
Some can I believe deliver fat binaries. That is a program that can run
machine code
for several machines.
With the exception of Corman all Lisp's that can deliver programs are
commercial.
SBCL and CLISP provide ways of making the compiler load with the program
source and run it.
But you have to choose. Then we could provide help for a specific compiler.
On Aug 4, 3:31 pm, "John Thingstad" <··············@chello.no> wrote:
> På Sat, 04 Aug 2007 13:33:32 +0200, skrev <······@pupeno.com>:
>
>
>
>
>
> > Some people recommended me to ship an image, and even then I'd need a
> > script. I don't like this solution because I'll be re-shipping all the
> > libraries that the target host already has or may have by simple
> > dependencies (that is, when I program in C, I do shared compiling, not
> > static compiling). And the size is a problem, lots of mb for
> > helloworld
> > doesn't make sense.
>
> > I could ship a script that runs my favourite CL implementation, but
> > I'd like
> > to be a bit more portable than that. So, maybe there's already a
> > script, or
> > script generator, that may run an option of some CL implementations,
> > or
> > something like that. I don't know. I've asked several times on #lisp
> > at
> > freenode without getting anywhere.
>
> > A couple of notes:
> > - This is not a rant, I just want a solution.
> > - I don't care about Windows or other non-posix-like OSs.
>
> Common Lisp doesn't provide a way of generating applications.
> Many Lisp implementations however do.
> If you are creating a program it is a binary.
> It is locked to a architecture and a that compiler.
> There is no way to distribute source code and have it run on any system.
> Some can I believe deliver fat binaries. That is a program that can run
> machine code
> for several machines.
>
> With the exception of Corman all Lisp's that can deliver programs are
> commercial.
> SBCL and CLISP provide ways of making the compiler load with the program
> source and run it.
>
> But you have to choose. Then we could provide help for a specific compiler.
Since SBCL is my favorite CL implementation, getting a hint of how to
do it with SBCL would be nice.
Thank you.
--
J. Pablo Fernández <······@pupeno.com> (http://pupeno.com)
On Aug 4, 11:48 am, ·······@pupeno.com" <······@pupeno.com> wrote:
[...]
> Since SBCL is my favorite CL implementation, getting a hint of how to
> do it with SBCL would be nice.
The SBCL documentation may be helpful. ;-)
You might find these bits particularly interesting:
http://www.sbcl.org/manual/Unix_002dstyle-Command-Line-Protocol.html
http://www.sbcl.org/manual/Saving-a-Core-Image.html
Cheers,
Pillsy
Pillsy wrote:
> On Aug 4, 11:48 am, ·······@pupeno.com" <······@pupeno.com> wrote:
> [...]
> > Since SBCL is my favorite CL implementation, getting a hint of how to
> > do it with SBCL would be nice.
>
> The SBCL documentation may be helpful. ;-)
>
> You might find these bits particularly interesting:
> http://www.sbcl.org/manual/Unix_002dstyle-Command-Line-Protocol.html
This looks promising, but then, if it is not the default, my program
can't be just packaged and delivered.
> http://www.sbcl.org/manual/Saving-a-Core-Image.html
I've reply to this one in another post.
Thank you.
P� Sat, 04 Aug 2007 17:48:23 +0200, skrev ······@pupeno.com
<······@pupeno.com>:
>
> Since SBCL is my favorite CL implementation, getting a hint of how to
> do it with SBCL would be nice.
>
> Thank you.
> --
> J. Pablo Fern�ndez <······@pupeno.com> (http://pupeno.com)
>
I don't use SBCL but I dug up the following link.
Load the program with all dependencies and write
(sb-ext:save-lisp-and-die)
should create a binary.
http://www.esden.net/blog/2006/07/10/compiling-binaries-with-sbcl/
John Thingstad wrote:
> På Sat, 04 Aug 2007 17:48:23 +0200, skrev ······@pupeno.com
> <······@pupeno.com>:
>
> >
> > Since SBCL is my favorite CL implementation, getting a hint of how to
> > do it with SBCL would be nice.
> >
> > Thank you.
> > --
> > J. Pablo Fernández <······@pupeno.com> (http://pupeno.com)
> >
>
> I don't use SBCL but I dug up the following link.
> Load the program with all dependencies and write
> (sb-ext:save-lisp-and-die)
> should create a binary.
>
> http://www.esden.net/blog/2006/07/10/compiling-binaries-with-sbcl/
This is exactly what I didn't want to do. I was aware you could save
an image, but this is not good. It includes everything in the image,
hello world takes 25MB, do you imagine every little binary in your
system taking 25MB? My target is posix-like OSs which already have a
good way to deal with dependencies (with a package manager), so
dependencies are not a problem, they'll be automatically installed
(sbcl or some other lisp and all the needed libraries), so I want them
not to be included in the "binary" (which doesn't have to be a binary,
it can be a shell script).
Thank you.
·······@pupeno.com" <······@pupeno.com> writes:
> John Thingstad wrote:
>> P� Sat, 04 Aug 2007 17:48:23 +0200, skrev ······@pupeno.com
>> <······@pupeno.com>:
>>
>> >
>> > Since SBCL is my favorite CL implementation, getting a hint of how to
>> > do it with SBCL would be nice.
>> >
>> > Thank you.
>> > --
>> > J. Pablo Fern�ndez <······@pupeno.com> (http://pupeno.com)
>> >
>>
>> I don't use SBCL but I dug up the following link.
>> Load the program with all dependencies and write
>> (sb-ext:save-lisp-and-die)
>> should create a binary.
>>
>> http://www.esden.net/blog/2006/07/10/compiling-binaries-with-sbcl/
>
> This is exactly what I didn't want to do. I was aware you could save
> an image, but this is not good. It includes everything in the image,
> hello world takes 25MB, do you imagine every little binary in your
> system taking 25MB? My target is posix-like OSs which already have a
> good way to deal with dependencies (with a package manager), so
> dependencies are not a problem, they'll be automatically installed
> (sbcl or some other lisp and all the needed libraries), so I want them
> not to be included in the "binary" (which doesn't have to be a binary,
> it can be a shell script).
> Thank you.
Executable images are like statically linked programs. They may be
useful in some situation, but it's understandable you'd prefer to
share the big sbcl "library".
You can distribute your programs in two forms:
- source form (prefered ;-))
- fasl form.
The advantage of the source form, is that it can work with any version
of the sbcl "library". Usually, fasl cannot be loaded in a different
version of the implementation (and even more so for images, which
cannot be used by a different "compile" of the implementation).
Of course, if you distribute your program in source form, you still
want to compile it to fasl (or an image) when you install it. And if
you distribute your program as fasl, it'd be good to install them
generating an image too, since loading an image is usually faster than
loading the fasl. We're not discussing executable images here, only
the bare image. You still need the sbcl "shared library" to load
these images, so they shouldn't be too big.
For real small tools (scripts), you can just give them as #! scripts
(in source form, or I believe they can also be fasl, at least in clisp
we can put #! in front of a .fas file).
In anycase, since we're not considering executable images, you'll have
to have small launcher scripts to run sbcl with the --core argument or
--load arguments.
I don't know of any tool to do that systematically, but it shouldn't
be too hard to write one. (I usually do this kind of stuff in makefiles
(*^.^*) )
--
__Pascal Bourguignon__ http://www.informatimago.com/
The mighty hunter
Returns with gifts of plump birds,
Your foot just squashed one.
Pascal Bourguignon wrote:
> Executable images are like statically linked programs.
Indeed.
> They may be useful in some situation,
Yes, I see myself using it when passing alpha versions to some friends
to try. It may also be useful when coding a server application
deploying it to my own server machine.
> but it's understandable you'd prefer to
> share the big sbcl "library".
Yes.
> You can distribute your programs in two forms:
> - source form (prefered ;-))
That's what I'll do.
> - fasl form.
That's what I won't do.
> The advantage of the source form, is that it can work with any version
> of the sbcl "library". Usually, fasl cannot be loaded in a different
> version of the implementation (and even more so for images, which
> cannot be used by a different "compile" of the implementation).
Debian and derivates, and Gentoo (and derivates) have a thing called
"common-lisp-controler" which can compile on the fly CL sources when
you need them and store them in a cache in /var/something. So you
don't need to compile them again and the packages only contain the
sources. I see this can be a problem for a thousand-user installation,
but well, I haven't seen one of those... ever (not without a local HD
on each machine).
> Of course, if you distribute your program in source form, you still
> want to compile it to fasl (or an image) when you install it.
Not with Debian and Gentoo and their derivates... and I haven't tried
other distributions/OSs to see what they do. I supouse they already
offer a way to distribute lisp libraries so my application could be
distributed in the same way... or they don't support lisp at all.
> And if
> you distribute your program as fasl, it'd be good to install them
> generating an image too, since loading an image is usually faster than
> loading the fasl. We're not discussing executable images here, only
> the bare image. You still need the sbcl "shared library" to load
> these images, so they shouldn't be too big.
>
> For real small tools (scripts), you can just give them as #! scripts
> (in source form, or I believe they can also be fasl, at least in clisp
> we can put #! in front of a .fas file).
How do you do that (for sources, not really interested in fasls)? SBCL
requires a "customization" to be able to do it as mentioned in other
posts on this thread:
http://www.sbcl.org/manual/Unix_002dstyle-Command-Line-Protocol.html#Unix_002dstyle-Command-Line-Protocol
> In anycase, since we're not considering executable images, you'll have
> to have small launcher scripts to run sbcl with the --core argument or
> --load arguments.
>
>
> I don't know of any tool to do that systematically, but it shouldn't
> be too hard to write one. (I usually do this kind of stuff in makefiles
> (*^.^*) )
I'm thinking about making a small program called lisp-runner, which
you could put in the shebang and it would run the current file in some
available CL implementation. Nobody made it yet? I don't want to re-
invent the wheel.
Some nice features would be:
- define a list of compatible lisps: #!/usr/bin/env lisp-runner
sbcl,clisp. That would mean, run the program in sbcl, if available,
otherwise in clisp.
- have global configurations on /etc and per-user configuration on
~/.lisp-runner that would allow to specify what lisps you have and
want to run, which you want to try even if they are not supported,
which you don't want to use at all.
Thank you.
(message (Hello ·······@pupeno.com)
(you :wrote :on '(Sat, 04 Aug 2007 18:34:03 -0000))
(
p> I'm thinking about making a small program called lisp-runner,
p> which you could put in the shebang and it would run the current file in
p> some available CL implementation. Nobody made it yet?
maybe this: http://www.cliki.net/cl-launch
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"choose no life")
Alex Mizrahi wrote:
> maybe this: http://www.cliki.net/cl-launch
Yes, this looks very close to what I thought, actually, it works in a
very different way, but to solve the same problem. I'm surprised I
never got this pointed to before (when I asked the same question).
Now, I can't find any program that uses it. Do you know of any program
that uses it?
From: ···············@no.such.domain
Subject: Re: How do I make a program in Common Lisp?
Date:
Message-ID: <13baenelvt3nmb8@corp.supernews.com>
pupeno said:
> I'm thinking about making a small program called lisp-runner, which
> you could put in the shebang and it would run the current file in some
> available CL implementation. Nobody made it yet? I don't want to re-
> invent the wheel.
This might be a non-trivial hack. The same exact program might be
in /usr/bin on one system and in /usr/local/bin in another and in
some specialized sub-directory in another system. You need to run
whereis to find the correct location. But that doesn't work if the
name is 'lisp' on one system and 'sbcl' on another system and 'cl'
on another system. So you might need to do several 'whereis' calls
until you find a name-match. But 'lisp' or 'cl' might not be the
implementation you can deal with, it might be cmucl or something
truly ancient or something somewhat nonstandard. How does your
installation script even decide whether 'lisp' is really cmucl or
sbcl or whatnot? Start it under a PTY and parse the initial
greeting?? Maybe a totally automated installation isn't feasible.
So instead, make a nice GUI or CGI script that performs
configuration and installation, where the user is asked to look at
the initial greeting and check a box what program seems to be
running.
And what if, after the program is installed and has been in regular
use, the sysadmin suddenly pulls the rug out from under your
lisp-runner by installing a new version of lisp, so 'lisp' now runs
ucblisp2008 instead of sbcl?
···············@no.such.domain wrote:
> pupeno said:
>> I'm thinking about making a small program called lisp-runner, which
>> you could put in the shebang and it would run the current file in some
>> available CL implementation. Nobody made it yet? I don't want to re-
>> invent the wheel.
>
> This might be a non-trivial hack. The same exact program might be
> in /usr/bin on one system and in /usr/local/bin in another and in
> some specialized sub-directory in another system.
That's what env is for. Doesn't solve the problem completely but
helps: http://en.wikipedia.org/wiki/Shebang_(Unix)#Solving_shebang_problems_with_the_env_program
And none of my users install my software from sources, they install it
from packages their OS vedors did, so the vendor is free to correct
the path to env.
> You need to run
> whereis to find the correct location. But that doesn't work if the
> name is 'lisp' on one system and 'sbcl' on another system and 'cl'
> on another system. So you might need to do several 'whereis' calls
> until you find a name-match. But 'lisp' or 'cl' might not be the
> implementation you can deal with, it might be cmucl or something
> truly ancient or something somewhat nonstandard. How does your
> installation script even decide whether 'lisp' is really cmucl or
> sbcl or whatnot? Start it under a PTY and parse the initial
> greeting??
This is not how I intended lisp-runner to work, but being that there's
a good solution out there to solve this problem, called cl-launcher
(well, actually, I still have to figure out how to use it portably), I
think it makes no sense to talk about lisp-runner. If you feel
otherwise, let me know and I'll address your concerns.
> Maybe a totally automated installation isn't feasible.
It should be, it is a must. If *my* users can't open their nice GUI
package manager, click, click, click and have my application installed
and running, they are just not going to do it. They are doing it today
with C++, but I want to code in a nice, powerful, practical language:
Common Lisp.
> And what if, after the program is installed and has been in regular
> use, the sysadmin suddenly pulls the rug out from under your
> lisp-runner by installing a new version of lisp, so 'lisp' now runs
> ucblisp2008 instead of sbcl?
I don't see why that should break it, but then, I'm not sure what
ucblisp2008 is. If a sysadmin breaks his own system, its their fault.
Like if you download a unstable version of libc that changed something
importand and install it over-writting the one your OS vendor prepared
for you. You are on your own with you non-working system.
·······@pupeno.com" <······@pupeno.com> writes:
> John Thingstad wrote:
>> P� Sat, 04 Aug 2007 17:48:23 +0200, skrev ······@pupeno.com
>> <······@pupeno.com>:
>>
>> >
>> > Since SBCL is my favorite CL implementation, getting a hint of how to
>> > do it with SBCL would be nice.
>> >
>> > Thank you.
>> > --
>> > J. Pablo Fern�ndez <······@pupeno.com> (http://pupeno.com)
>> >
>>
>> I don't use SBCL but I dug up the following link.
>> Load the program with all dependencies and write
>> (sb-ext:save-lisp-and-die)
>> should create a binary.
>>
>> http://www.esden.net/blog/2006/07/10/compiling-binaries-with-sbcl/
>
> This is exactly what I didn't want to do. I was aware you could save
> an image, but this is not good. It includes everything in the image,
> hello world takes 25MB, do you imagine every little binary in your
> system taking 25MB? My target is posix-like OSs which already have a
> good way to deal with dependencies (with a package manager), so
> dependencies are not a problem, they'll be automatically installed
> (sbcl or some other lisp and all the needed libraries), so I want them
> not to be included in the "binary" (which doesn't have to be a binary,
> it can be a shell script).
> Thank you.
Or it can be a source or fasl file that pulls in the already-installed
lisp via the unix scripting facilities. Some lisps on some
architectures provide for this - see:
http://www.franz.com/support/documentation/8.0/doc/startup.htm#starting-unix-script-3
--
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: Matthias Buelow
Subject: Re: How do I make a program in Common Lisp?
Date:
Message-ID: <5hp3afF3ks63eU1@mid.dfncis.de>
······@pupeno.com <······@pupeno.com> wrote:
> It includes everything in the image,
> hello world takes 25MB, do you imagine every little binary in your
> system taking 25MB?
In the defense of SBCL (etc.) I have to say that Common Lisp is probably
not the proper choice for hello-world style programs...
Matthias Buelow <···@incubus.de> writes:
> ······@pupeno.com <······@pupeno.com> wrote:
>
>> It includes everything in the image,
>> hello world takes 25MB, do you imagine every little binary in your
>> system taking 25MB?
>
> In the defense of SBCL (etc.) I have to say that Common Lisp is probably
> not the proper choice for hello-world style programs...
A full featured CL implementation, no.
But one could design an implementation of a subset of CL adapted to
hello-world style programs, that would compile to even smaller object
files than C.
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
P� Sat, 04 Aug 2007 16:31:37 +0200, skrev John Thingstad
<··············@chello.no>:
> With the exception of Corman all Lisp's that can deliver programs are
> commercial.
Ooops.. On closer thought I think ECL and GCL can deliver applications as
well.
On Sat, 04 Aug 2007 16:35:37 +0200, John Thingstad wrote:
> På Sat, 04 Aug 2007 16:31:37 +0200, skrev John Thingstad
> <··············@chello.no>:
>
>> With the exception of Corman all Lisp's that can deliver programs are
>> commercial.
>
> Ooops.. On closer thought I think ECL and GCL can deliver applications as
> well.
And what about SBCL?
> (defun main ()
(format T "Hello word!~%")
(quit :unix-status 0))
> (save-lisp-and-die "simpleapp" :executable t :toplevel (function main))
:~$ file simpleapp
simpleapp: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for
GNU/Linux 2.6.0, dynamically linked (uses shared libs), stripped
:~$ ./simpleapp
Hello word!
Cheers, Ralf Mattes
Ralf Mattes wrote:
> On Sat, 04 Aug 2007 16:35:37 +0200, John Thingstad wrote:
>
> > På Sat, 04 Aug 2007 16:31:37 +0200, skrev John Thingstad
> > <··············@chello.no>:
> >
> >> With the exception of Corman all Lisp's that can deliver programs are
> >> commercial.
> >
> > Ooops.. On closer thought I think ECL and GCL can deliver applications as
> > well.
>
> And what about SBCL?
>
> > (defun main ()
> (format T "Hello word!~%")
> (quit :unix-status 0))
>
> > (save-lisp-and-die "simpleapp" :executable t :toplevel (function main))
>
> :~$ file simpleapp
> simpleapp: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for
> GNU/Linux 2.6.0, dynamically linked (uses shared libs), stripped
>
>
> :~$ ./simpleapp
> Hello word!
The problem with that is that it is a 25MB image with the whole SBCL
and all the libraries included instead of using the installed SBCL and
libraries. It was already discussed in this thread and I explained why
this wasn't what I was looking for.
From: Cesar Rabak
Subject: Re: How do I make a program in Common Lisp?
Date:
Message-ID: <f932b8$tj5$1@aioe.org>
······@pupeno.com escreveu:
> Ralf Mattes wrote:
[snipped]
>> And what about SBCL?
>>
>>> (defun main ()
>> (format T "Hello word!~%")
>> (quit :unix-status 0))
>>
>>> (save-lisp-and-die "simpleapp" :executable t :toplevel (function main))
>> :~$ file simpleapp
>> simpleapp: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for
>> GNU/Linux 2.6.0, dynamically linked (uses shared libs), stripped
>>
>>
>> :~$ ./simpleapp
>> Hello word!
>
> The problem with that is that it is a 25MB image with the whole SBCL
> and all the libraries included instead of using the installed SBCL and
> libraries. It was already discussed in this thread and I explained why
> this wasn't what I was looking for.
>
So lets understand your requirements: you want to run a Common Lisp
program from the (shell) command line as it were an executable, but
don't want to compile it in a binary for the platform.
Is it correct?
On Sat, 04 Aug 2007 20:26:52 +0000, ······@pupeno.com wrote:
> Ralf Mattes wrote:
>> On Sat, 04 Aug 2007 16:35:37 +0200, John Thingstad wrote:
>>
>> > På Sat, 04 Aug 2007 16:31:37 +0200, skrev John Thingstad
>> > <··············@chello.no>:
>> >
>> >> With the exception of Corman all Lisp's that can deliver programs are
>> >> commercial.
>> >
>> > Ooops.. On closer thought I think ECL and GCL can deliver applications as
>> > well.
>>
>> And what about SBCL?
>>
>> > (defun main ()
>> (format T "Hello word!~%")
>> (quit :unix-status 0))
>>
>> > (save-lisp-and-die "simpleapp" :executable t :toplevel (function main))
>>
>> :~$ file simpleapp
>> simpleapp: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for
>> GNU/Linux 2.6.0, dynamically linked (uses shared libs), stripped
>>
>>
>> :~$ ./simpleapp
>> Hello word!
>
> The problem with that is that it is a 25MB image with the whole SBCL
> and all the libraries included instead of using the installed SBCL and
> libraries. It was already discussed in this thread and I explained why
> this wasn't what I was looking for.
I was answering John.
Anyway - iff you deploy to platforms where sbcl (and probably libraries)
is/are present then why don't you do what a lot of
P{erl|ython}/Ruby/Lua/whatever apps are doing:
cat /usr/bin/sillyapp
#!/bin/sh
APPDIR='/usr/share/sillyapp'
/usr/bin/sbcl --noinform \
--userinit /dev/null \
--sysinit /dev/null \
--load ${APPDIR}/lib.lisp \
--eval '(main)'
Cheers, Ralf Mattes
Ralf Mattes wrote:
> Anyway - iff you deploy to platforms where sbcl (and probably libraries)
> is/are present then why don't you do what a lot of
> P{erl|ython}/Ruby/Lua/whatever apps are doing:
>
> cat /usr/bin/sillyapp
>
> #!/bin/sh
> APPDIR='/usr/share/sillyapp'
> /usr/bin/sbcl --noinform \
> --userinit /dev/null \
> --sysinit /dev/null \
> --load ${APPDIR}/lib.lisp \
> --eval '(main)'
Indeed! The only problem I see with that its that it is too
implementation-dependant. cl-launcher looks like a better alternative.
Thank you.
From: Cesar Rabak
Subject: Re: How do I make a program in Common Lisp?
Date:
Message-ID: <f932fr$1dd$1@aioe.org>
······@pupeno.com escreveu:
> Ralf Mattes wrote:
>> Anyway - iff you deploy to platforms where sbcl (and probably libraries)
>> is/are present then why don't you do what a lot of
>> P{erl|ython}/Ruby/Lua/whatever apps are doing:
>>
>> cat /usr/bin/sillyapp
>>
>> #!/bin/sh
>> APPDIR='/usr/share/sillyapp'
>> /usr/bin/sbcl --noinform \
>> --userinit /dev/null \
>> --sysinit /dev/null \
>> --load ${APPDIR}/lib.lisp \
>> --eval '(main)'
>
> Indeed! The only problem I see with that its that it is too
> implementation-dependant. cl-launcher looks like a better alternative.
>
> Thank you.
>
OK, ok, replace /usr/bin/sbcl with `which sbcl`, or better, call only
sbcl and rely on sbcl being in the path of your platform.
Cesar Rabak wrote:
> ······@pupeno.com escreveu:
> > Ralf Mattes wrote:
> >> Anyway - iff you deploy to platforms where sbcl (and probably libraries)
> >> is/are present then why don't you do what a lot of
> >> P{erl|ython}/Ruby/Lua/whatever apps are doing:
> >>
> >> cat /usr/bin/sillyapp
> >>
> >> #!/bin/sh
> >> APPDIR='/usr/share/sillyapp'
> >> /usr/bin/sbcl --noinform \
> >> --userinit /dev/null \
> >> --sysinit /dev/null \
> >> --load ${APPDIR}/lib.lisp \
> >> --eval '(main)'
> >
> > Indeed! The only problem I see with that its that it is too
> > implementation-dependant. cl-launcher looks like a better alternative.
> >
> > Thank you.
> >
> OK, ok, replace /usr/bin/sbcl with `which sbcl`, or better, call only
> sbcl and rely on sbcl being in the path of your platform.
By implementation I meant SBCL, not the path to it. I believe the most
cross-platform way to call a binary is /usr/bin/env binary-name.
Anyway, a better solution was provided: cl-launch. Maybe I should stop
replying to let the thread die.
I'll post my findings about cl-launch in some days.
(message (Hello ·······@pupeno.com)
(you :wrote :on '(Sat, 04 Aug 2007 22:34:18 -0000))
(
??>> /usr/bin/sbcl --noinform \
??>> --userinit /dev/null \
??>> --sysinit /dev/null \
??>> --load ${APPDIR}/lib.lisp \
??>> --eval '(main)'
p> Indeed! The only problem I see with that its that it is too
p> implementation-dependant. cl-launcher looks like a better alternative.
but you've said "my programs aren't for lispers". why should non-lispers
have a way to choose lisp implementation to run your program -- for which
reason? you'll need much more testing, and nevertheless it increases chances
that your program will be broken with some version of some implementation.
OTOH if you'll just choose a single implementation -- e.g. sbcl as
reasonably mature, stable and widespread -- you can thoroughly test your
application with all available versions.
at same lisp enthusiasts and people with alternative requirements will still
be able to run it with other lisp implementations -- change start script a
little (or you can just ship alternative scripts). they will be more ready
to face problems in your application, if there will be any with
"non-standard" implemenation.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"choose no life")
Ralf Mattes <··@mh-freiburg.de> wrote:
+---------------
| And what about SBCL?
| > (defun main ()
| (format T "Hello word!~%")
| (quit :unix-status 0))
|
| > (save-lisp-and-die "simpleapp" :executable t :toplevel (function main))
+---------------
In recent versions of CMUCL for FreeBSD & Linux,
this can be done in almost exactly the same way:
(save-lisp "simpleapp" :executable t :init-function (function main))
And, yes, it packages up the whole Lisp image into the executable.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
P� Sat, 04 Aug 2007 22:02:19 +0200, skrev Ralf Mattes <··@mh-freiburg.de>:
>
> And what about SBCL?
>
If you look through this thread you will see that I mention
save-lisp-and-die elsewhere. I had just forgotten about it as I don't use
SBCL. Anyhow from what I see he would be better off with
http://www.cliki.net/cl-launch
"John Thingstad" <··············@chello.no> writes:
>
> There is no way to distribute source code and have it run on any
> system.
One could distribute the source code and a script which would find a
Common Lisp implementation and create a binary with it. This would be
the equivalent of an SRPM--in fact, one could create an SRPM to do
exactly this. It'd be a bit of a chore though.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Make backups before you try something new or interesting or experimental
or radical or if the day has a 'y' in it. --Chris Hacking
Robert Uhl <·········@NOSPAMgmail.com> writes:
> "John Thingstad" <··············@chello.no> writes:
>>
>> There is no way to distribute source code and have it run on any
>> system.
>
> One could distribute the source code and a script which would find a
> Common Lisp implementation and create a binary with it. This would be
> the equivalent of an SRPM--in fact, one could create an SRPM to do
> exactly this. It'd be a bit of a chore though.
Of course, gentoo distributes only source packages, a lot of CL
libraries in /usr/portage/dev-lisp/, but also a few programs.
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
From: Kent M Pitman
Subject: Re: How do I make a program in Common Lisp?
Date:
Message-ID: <ufy2wgjrq.fsf@nhplace.com>
Robert Uhl <·········@NOSPAMgmail.com> writes:
> "John Thingstad" <··············@chello.no> writes:
> >
> > There is no way to distribute source code and have it run on any
> > system.
>
> One could distribute the source code and a script which would find a
> Common Lisp implementation and create a binary with it. This would be
> the equivalent of an SRPM--in fact, one could create an SRPM to do
> exactly this. It'd be a bit of a chore though.
And, to be viable as a solution, it requires that you don't mind exposing
the source code in the first place. It turns out that that's not a given.
(sigh)
(message (Hello ·······@pupeno.com)
(you :wrote :on '(Sat, 04 Aug 2007 04:33:32 -0700))
(
p> $ apt-get install
so, you question is how to do a package for Debian.
that's quite different from "make a program in Common Lisp".
i think you can find documentation on creating Debian packages on Debian
site.
you can also try to find existing package to check how it's done and do it
in that way.
i would suggest to run aptitude and check packages that depend on
common-lisp-controller, for exampe -- common-lisp-controller is a thingie
that handles library dependencies "automatically" among multiple Common Lisp
implementations.
so you can apt-get source some package to see how it's built, installed etc.
also, if you really want to create a Debian package, you might want to
contact Kevin Rosenberg or Peter van Eynde -- they are maintainers of many
Debian Common Lisp packages.
also, consider following things. if users of your progam are lispers, they
would be happy if it would be a library, as REPL acts as shell for lispers.
Unix users are quite comfortable bulding programs from source, so you can
just ship tarball with makefile, and write required libs in README. no real
need for automatically installable packages.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"choose no life")
Alex Mizrahi wrote:
> (message (Hello ·······@pupeno.com)
> (you :wrote :on '(Sat, 04 Aug 2007 04:33:32 -0700))
> (
>
> p> $ apt-get install
>
> so, you question is how to do a package for Debian.
> that's quite different from "make a program in Common Lisp".
> i think you can find documentation on creating Debian packages on Debian
> site.
No. As you can see I also listed other package managers, so it can be
Debian, RedHat, Gentoo, FreeBSD, whatever. And, also, I specified that
it should be runable from bash (which you didn't quote).
> you can also try to find existing package to check how it's done and do it
> in that way.
> i would suggest to run aptitude and check packages that depend on
> common-lisp-controller, for exampe -- common-lisp-controller is a thingie
> that handles library dependencies "automatically" among multiple Common Lisp
> implementations.
> so you can apt-get source some package to see how it's built, installed etc.
> also, if you really want to create a Debian package, you might want to
> contact Kevin Rosenberg or Peter van Eynde -- they are maintainers of many
> Debian Common Lisp packages.
I already know there are libraries for Debian, I already know how to
package them, heck! I even packaged some of them and maintained
repositories of them for people that want them. Now, if you take a
look, you'll notice that the only things packaged are libraries, there
are no programs.
> also, consider following things. if users of your progam are lispers, they
> would be happy if it would be a library, as REPL acts as shell for lispers.
No, my programs aren't for lispers, my programs are for everybody (or
anybody interested in them). I don't live in Lisp REPL and I hate it
when I install a Lisp program and I have to figure out what function
to run in a REPL and even then, I have to run a REPL (which I don't do
for any other programs in any other languages).
> Unix users are quite comfortable bulding programs from source,
I'm not targeting Unix. All the OSs I'm targeting are modern OSs which
have a package manager with the idea of solving the problems related
to building from source. I run Kubuntu and I haven't built from source
even one of the programs I run daily, and so do many people using
these OSs.
> so you can
> just ship tarball with makefile, and write required libs in README. no real
> need for automatically installable packages.
Even then, how will you build a program in a Makefile other than
generating a huge image?
Thank you.
(message (Hello ·······@pupeno.com)
(you :wrote :on '(Sat, 04 Aug 2007 18:44:46 -0000))
(
p> No. As you can see I also listed other package managers, so it can be
p> Debian, RedHat, Gentoo, FreeBSD, whatever.
it would be just more work to do. there are freaking lots installation
systems.
if program is not terribly popular i think it's not feasible to do that
work -- just supply tarball for enthusiasts..
p> repositories of them for people that want them. Now, if you take a
p> look, you'll notice that the only things packaged are libraries, there
p> are no programs.
there are some -- cedilla (some proggy manipulating texts, runs in clisp)
and vcs-tree -- it works in sbcl and is shipped in a form of fasl,
cleverly stuffed into shell-executable file. but unfortunately it doesn't
work because shipped fasl version doesn't match current sbcl fasl version.
but it's possible to build it from deb source (and it works from bash by the
way -- is that a problem at all?).
you are right, i wasn't able to find a really good-packaged program. but i
think it's not hard to make it -- for example, just make main stuff a
library, to be handled by clc, and make in runnable via cl-launch.
for example, let's take library cl-f2cl, already available in Debian -- to
make runnable script:
cl-launch --system f2cl --init "(fortran-to-lisp:f2cl (first
cl-launch:*arguments*))" --output runf2cl
now i can launch it:
./runf2cl fff.f
it's far from perfect, because it can produce weird error messages, but
that's fixable.
then you can bundle that script with your package, or re-create it on user
system via cl-launch.
(no, i don't know any "real" applications using cl-launch)
??>> so you can
??>> just ship tarball with makefile, and write required libs in README. no
??>> real need for automatically installable packages.
p> Even then, how will you build a program in a Makefile other than
p> generating a huge image?
ehm.. compile-file produce FASL files. this is kinda standard way for
compiling lisp applications. and there is (asdf:oos 'asdf:compile-op
:package-name) to do it in a smart way, and common-lisp-controller to do it
automatically..
but i guess you already know that, why are you asking?
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"choose no life")
Alex Mizrahi wrote:
> (message (Hello ·······@pupeno.com)
> (you :wrote :on '(Sat, 04 Aug 2007 18:44:46 -0000))
> (
>
> p> No. As you can see I also listed other package managers, so it can be
> p> Debian, RedHat, Gentoo, FreeBSD, whatever.
>
> it would be just more work to do. there are freaking lots installation
> systems.
> if program is not terribly popular i think it's not feasible to do that
> work -- just supply tarball for enthusiasts..
I produce tarballs for packagers and enthusiasts. I've seen too many
good software never reach popularity because it is impossible to
package.
> p> repositories of them for people that want them. Now, if you take a
> p> look, you'll notice that the only things packaged are libraries, there
> p> are no programs.
>
> there are some -- cedilla (some proggy manipulating texts, runs in clisp)
> and vcs-tree -- it works in sbcl and is shipped in a form of fasl,
> cleverly stuffed into shell-executable file. but unfortunately it doesn't
> work because shipped fasl version doesn't match current sbcl fasl version.
> but it's possible to build it from deb source (and it works from bash by the
> way -- is that a problem at all?).
>
> you are right, i wasn't able to find a really good-packaged program. but i
> think it's not hard to make it -- for example, just make main stuff a
> library, to be handled by clc, and make in runnable via cl-launch.
> for example, let's take library cl-f2cl, already available in Debian -- to
> make runnable script:
>
> cl-launch --system f2cl --init "(fortran-to-lisp:f2cl (first
> cl-launch:*arguments*))" --output runf2cl
>
> now i can launch it:
>
> ./runf2cl fff.f
>
> it's far from perfect, because it can produce weird error messages, but
> that's fixable.
> then you can bundle that script with your package, or re-create it on user
> system via cl-launch.
>
> (no, i don't know any "real" applications using cl-launch)
Indeed this looks promising. I'm going to investigate it a bit more
and see if I can improve it (not cl-launch, it looks very nice, but
the way to use it). I want to see more Common Lisp applications out
there.
······@pupeno.com schrieb:
> # helloworld dependencies get installed, this may or may not include
> lisp
> libraries, and a CL implementation.
>
> $ helloworld
>
> # helloworld runs and entertains its user for about 5 picoseconds.
>
> That is, the user shouldn't be aware that the program was written in
> lisp,
> or that it is being interpreted or whatever.
>
> Some people recommended me to ship an image, and even then I'd need a
> script. I don't like this solution because I'll be re-shipping all the
> libraries that the target host already has or may have by simple
> dependencies (that is, when I program in C, I do shared compiling, not
> static compiling). And the size is a problem, lots of mb for
> helloworld doesn't make sense.
Then you could compile your program to a .fasl file.
You then write a C program which embeds the .fasl and runs a command line
command in which it calls the installed lisp.
To make sure it is installed you can write a package for Ubuntu or
Gentoo or whatever and make sure that for example sbcl 1.0.3 is a
dependency which has to be installed first.
Or you compile 10 .fasl files: 2 for the last 5 SBCLs, 3 for the last
3 CLISP versions and 2 for the last two CMUCL versions. Then the right
Lisp might already be installed.
So: embedding .fasl files inside a minimal C program.
Andr�
--
Andr� Thieme <······························@justmail.de> writes:
> ······@pupeno.com schrieb:
>> # helloworld dependencies get installed, this may or may not include
>> lisp
>> libraries, and a CL implementation.
>>
>> $ helloworld
>>
>> # helloworld runs and entertains its user for about 5 picoseconds.
>>
>> That is, the user shouldn't be aware that the program was written in
>> lisp,
>> or that it is being interpreted or whatever.
>>
>> Some people recommended me to ship an image, and even then I'd need a
>> script. I don't like this solution because I'll be re-shipping all the
>> libraries that the target host already has or may have by simple
>> dependencies (that is, when I program in C, I do shared compiling, not
>> static compiling). And the size is a problem, lots of mb for
>> helloworld doesn't make sense.
>
> Then you could compile your program to a .fasl file.
> You then write a C program which embeds the .fasl and runs a command line
> command in which it calls the installed lisp.
> To make sure it is installed you can write a package for Ubuntu or
> Gentoo or whatever and make sure that for example sbcl 1.0.3 is a
> dependency which has to be installed first.
> Or you compile 10 .fasl files: 2 for the last 5 SBCLs, 3 for the last
> 3 CLISP versions and 2 for the last two CMUCL versions. Then the right
> Lisp might already be installed.
>
> So: embedding .fasl files inside a minimal C program.
There is no need for a C program!
% cat /opt/my-pgm/bin/my-pgm
#!/bin/bash
FASL="/opt/my-pgm/fasl"
exec sbcl --userinit /dev/null \
--load "$FASL"/my-lib.fasl \
--load "$FASL"/my-pgm.fasl \
--eval "(my-pgm:main $(for f in ··@" ; do echo "$f"|sed -e 's/"/\\"/g' -e 's/^/"/' -e 's/$/"/' ; done) )"
The only thing is that here you trade time to load the .fasl, for the
same of a core image. If the program you're loading is small, it
might be better to keep it as fasl, if it's big, it would be
worthwhile to keep an image.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Specifications are for the weak and timid!"