If you want to make available your Lisp application, "turn-key", to
someone who doesn't necessarily have your flavor of Lisp installed on
her machine, it would seem (for SBCL) (sb-ext:save-lisp-and-
die :executable t) is the way to go. In fact, in order for myself to
remember this next time, I've written a blurb about it at
http://mikael.jansson.be/journal/2008/03/freezing-lisp-in-time (please
let me know if you spot any errors regarding any assumptions I made!)
Without a tree-shaker, 8M (compressed) for just a hello-world
application is a bit.. tough. And hard to use with small system (I
assume you *can* use Lisp for that!)
In any event, what do *you* people usually do when distributing
applications, using a free Lisp, e.g. SBCL?
Mikael Jansson <··············@gmail.com> writes:
> If you want to make available your Lisp application, "turn-key", to
> someone who doesn't necessarily have your flavor of Lisp installed on
> her machine, it would seem (for SBCL) (sb-ext:save-lisp-and-
> die :executable t) is the way to go. In fact, in order for myself to
> remember this next time, I've written a blurb about it at
> http://mikael.jansson.be/journal/2008/03/freezing-lisp-in-time (please
> let me know if you spot any errors regarding any assumptions I made!)
> Without a tree-shaker, 8M (compressed) for just a hello-world
> application is a bit.. tough. And hard to use with small system (I
> assume you *can* use Lisp for that!)
>
> In any event, what do *you* people usually do when distributing
> applications, using a free Lisp, e.g. SBCL?
I use clisp, it has a smaller footprint.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You can tell the Lisp programmers. They have pockets full of punch
cards with close parentheses on them." --> http://tinyurl.com/8ubpf
On Fri, 28 Mar 2008 00:39:00 -0700, Mikael Jansson wrote:
>
> In any event, what do *you* people usually do when distributing
> applications, using a free Lisp, e.g. SBCL?
I use web GUIs for my applications.
--
Lars Rune Nøstdal
http://nostdal.org/
On Fri, 28 Mar 2008 00:39:00 -0700 (PDT), Mikael Jansson <··············@gmail.com> wrote:
> In any event, what do *you* people usually do when distributing
> applications
We don't write applications in the first place. Only Kenny does.
HTH,
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Fri, 28 Mar 2008 00:39:00 -0700 (PDT), Mikael Jansson <··············@gmail.com> wrote:
>
>
>>In any event, what do *you* people usually do when distributing
>>applications
>
>
> We don't write applications in the first place. Only Kenny does.
And I do not even distribute them. (But I am getting there.)
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Mar 28, 1:57 pm, Edi Weitz <········@agharta.de> wrote:
> On Fri, 28 Mar 2008 00:39:00 -0700 (PDT), Mikael Jansson <··············@gmail.com> wrote:
> > In any event, what do *you* people usually do when distributing
> > applications
>
> We don't write applications in the first place. Only Kenny does.
>
True, you write libraries. And I write about how it would be to code
in Lisp. That puts His Kennyness at the top of the food chain, and me
just slightly above the amoebas.
--
Mikael
http://mikael.jansson.be
Edi Weitz wrote:
> On Fri, 28 Mar 2008 00:39:00 -0700 (PDT), Mikael Jansson <··············@gmail.com> wrote:
>
>> In any event, what do *you* people usually do when distributing
>> applications
>
> We don't write applications in the first place. Only Kenny does.
Well, except for Regex Coach, but clearly that isn't Lisp because it's a
stand alone executable, and clearly Lisp can't do that <smile>.
Mikael Jansson <··············@gmail.com> writes:
> In any event, what do *you* people usually do when distributing
> applications, using a free Lisp, e.g. SBCL?
I don't use a free lisp, so maybe you don't want to hear it, but I
distribute gui-based applications for Windows, linux and Mac OS X
delivered with LispWorks. The Windows version needs to install a
Microsoft runtime library (if the customer doesn't already have it) in
addition to the application, but the application itself is
self-contained, and could be run right off a CD if necessarily.
Hello World is 2.9MB when delivered in the most space-consuming way
with LW. I prefer to deliver less compact applications though, so they
can be patched and modified in any fashion by loading patches
distributed as fasl-files. The installers for all three platforms sum
up to 48MB on the CD, plenty of space left :-)
--
(espen)
On Fri, 28 Mar 2008 14:12:16 +0100, Espen Vestre <·····@vestre.net> wrote:
> I don't use a free lisp, so maybe you don't want to hear it, but I
> distribute gui-based applications for Windows, linux and Mac OS X
> delivered with LispWorks. The Windows version needs to install a
> Microsoft runtime library (if the customer doesn't already have it)
> in addition to the application, but the application itself is
> self-contained, and could be run right off a CD if necessarily.
For completeness, it should be noted that this is kind of a
"transitional" requirement. AFAIU you won't need the runtime library
on Vista as it's part of the OS already and you won't need it for
applications built with LispWorks 4.4.6 or earlier. A detailed
explanation is here:
http://article.gmane.org/gmane.lisp.lispworks.general/5765
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> For completeness, it should be noted that this is kind of a
> "transitional" requirement. AFAIU you won't need the runtime library
> on Vista as it's part of the OS already and you won't need it for
> applications built with LispWorks 4.4.6 or earlier.
Yes, thanks for pointing that out (personally, I don't quite get why
MS isn't distributing this library as part of their numerous software
updates anyway...).
--
(espen)
On Mar 28, 4:12 pm, Espen Vestre <·····@vestre.net> wrote:
> Mikael Jansson <··············@gmail.com> writes:
> > In any event, what do *you* people usually do when distributing
> > applications, using a free Lisp, e.g. SBCL?
>
> I don't use a free lisp, so maybe you don't want to hear it, but I
> distribute gui-based applications for Windows, linux and Mac OS X
> delivered with LispWorks. The Windows version needs to install a
> Microsoft runtime library (if the customer doesn't already have it) in
> addition to the application, but the application itself is
> self-contained, and could be run right off a CD if necessarily.
>
> Hello World is 2.9MB when delivered in the most space-consuming way
> with LW. I prefer to deliver less compact applications though, so they
> can be patched and modified in any fashion by loading patches
> distributed as fasl-files. The installers for all three platforms sum
> up to 48MB on the CD, plenty of space left :-)
> --
> (espen)
We use Corman Lisp (<2Mb for our console app).
igor
--
http://www.idearover.com/
On Mar 28, 12:39 am, Mikael Jansson <··············@gmail.com> wrote:
> If you want to make available your Lisp application, "turn-key", to
> someone who doesn't necessarily have your flavor of Lisp installed on
> her machine, it would seem (for SBCL) (sb-ext:save-lisp-and-
> die :executable t) is the way to go.
A dumped memory image is not a direct solution to the problem that the
user doesn't have a binary installation of the given Lisp system.
The direct solution to that specific problem is to provide a binary
package of that Lisp system.
Kaz Kylheku wrote:
> On Mar 28, 12:39�am, Mikael Jansson <··············@gmail.com> wrote:
> > If you want to make available your Lisp application, "turn-key", to
> > someone who doesn't necessarily have your flavor of Lisp installed on
> > her machine, it would seem (for SBCL) (sb-ext:save-lisp-and-
> > die :executable t) is the way to go.
>
> A dumped memory image is not a direct solution to the problem that the
> user doesn't have a binary installation of the given Lisp system.
>
> The direct solution to that specific problem is to provide a binary
> package of that Lisp system.
Umm, the user wouldn't need a binary installation of SBCL if that
command was used because the output would be SBCL and the image
wrapped up as an executable.
Mikael Jansson schrieb:
> In any event, what do *you* people usually do when distributing
> applications, using a free Lisp, e.g. SBCL?
Just for my interest: The simple (format t "Hello World")-Program has
27K when compiled using ECL's compile-file-Commands. It needs libecl,
which is about 4 MB for me but can be used by all Applications that are
compiled with ECL on a Computer. There is no big difference to CLISP's
Images.
And ECL should be very portable, as there are only a few files written
in C, that have to be ported to another Platform (and almost any
Platform has a working C-Compiler).
But it seems like only few people are interested in ECL (which may be
the reason for the lack of some features). So, since I am not an
expierienced Programmer, I wonder about the reasons for that?
"C.-S. S." <···@swissjabber.ch> writes:
> Mikael Jansson schrieb:
>> In any event, what do *you* people usually do when distributing
>> applications, using a free Lisp, e.g. SBCL?
>
> Just for my interest: The simple (format t "Hello World")-Program has
> 27K when compiled using ECL's compile-file-Commands. It needs libecl,
> which is about 4 MB for me but can be used by all Applications that
> are compiled with ECL on a Computer. There is no big difference to
> CLISP's Images.
>
> And ECL should be very portable, as there are only a few files written
> in C, that have to be ported to another Platform (and almost any
> Platform has a working C-Compiler).
>
> But it seems like only few people are interested in ECL (which may be
> the reason for the lack of some features). So, since I am not an
> expierienced Programmer, I wonder about the reasons for that?
Why do you wonder about that?
Instead, you should ask yourself whether ECL could be useful to you.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Pour moi, la grande question n'a jamais �t�: �Qui suis-je? O� vais-je?�
comme l'a formul� si adroitement notre ami Pascal, mais plut�t:
�Comment vais-je m'en tirer?� -- Jean Yanne
Pascal Bourguignon schrieb:
>> But it seems like only few people are interested in ECL (which may be
>> the reason for the lack of some features). So, since I am not an
>> expierienced Programmer, I wonder about the reasons for that?
>
> Why do you wonder about that?
>
> Instead, you should ask yourself whether ECL could be useful to you.
The reason why I am interested in ECL is that once I was thinking about
how I would implement a CL-Compiler. I would try to create a small core
written in C and use an external (or internal) C-Compiler to compile the
functions, since C should be very portable without having to handle with
ABIs and assembler-Stuff, and almost every Platform has a C-Compiler...
And thats what ECL is - this was so far convincing me.
But it didnt support gray streams (it meanwhile does), finalisations and
weak pointers (it still doesnt, but maybe it will soon). And it is not
supported by many Projects.
Since I am not expierienced I think it is a good question to ask, why so
many people are not interested in ECL, and it might be interesting to me
(and others) to know the disadvantages before working with it. This is
why I was asking.
"C.-S. S." <···@swissjabber.ch> writes:
> Pascal Bourguignon schrieb:
>>> But it seems like only few people are interested in ECL (which may be
>>> the reason for the lack of some features). So, since I am not an
>>> expierienced Programmer, I wonder about the reasons for that?
>> Why do you wonder about that? Instead, you should ask yourself
>> whether ECL could be useful to you.
>
> The reason why I am interested in ECL is that once I was thinking
> about how I would implement a CL-Compiler. I would try to create a
> small core written in C and use an external (or internal) C-Compiler
> to compile the functions, since C should be very portable without
> having to handle with ABIs and assembler-Stuff, and almost every
> Platform has a C-Compiler... And thats what ECL is - this was so far
> convincing me.
>
> But it didnt support gray streams (it meanwhile does), finalisations
> and weak pointers (it still doesnt, but maybe it will soon). And it is
> not supported by many Projects.
>
> Since I am not expierienced I think it is a good question to ask, why
> so many people are not interested in ECL, and it might be interesting
> to me (and others) to know the disadvantages before working with
> it. This is why I was asking.
Well, I know what advantage ECL has: it's embeddable.
I don't know many of its disadvantages, since I've not used it yet. I
haven't had to embed a CL in any application. Well, actually I would
like to embed id in a few applications, but I'm just lacking time to
do so.
Why don't you just use it, and tell us if you find any disadvantage?
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live.
Pascal Bourguignon schrieb:
> Well, I know what advantage ECL has: it's embeddable.
>
> I don't know many of its disadvantages, since I've not used it yet. I
> haven't had to embed a CL in any application. Well, actually I would
> like to embed id in a few applications, but I'm just lacking time to
> do so.
>
> Why don't you just use it, and tell us if you find any disadvantage?
I dont use it much because it does not support trivial-garbage (it has
no finalizations and no weak pointers), and some packages I use for some
Programs require trivial-garbage. And many Libraries use the
finalizations of cffi, which also do not work.
But I am using it for some things. For example, I used it for some Stuff
on a little VPS, where all other CL's I tried (except clisp, which has
no threads, and alisp) couldnt even start. It mostly needs less RAM and
loads faster that SBCL (at least this was my expierience), but it had no
support for gray streams (which was the reason why i could not use
allegroserve and hunchentoot and had to write many things myself).
But again, I am not an expierienced programmer or professional in any
way. Just doing this stuff for fun. So I wanted to know what the "real"
cl-programmers say.
P� Wed, 02 Apr 2008 19:43:01 +0200, skrev C.-S. S. <···@swissjabber.ch>:
> Pascal Bourguignon schrieb:
>> Well, I know what advantage ECL has: it's embeddable.
>> I don't know many of its disadvantages, since I've not used it yet. I
>> haven't had to embed a CL in any application. Well, actually I would
>> like to embed id in a few applications, but I'm just lacking time to
>> do so.
>> Why don't you just use it, and tell us if you find any disadvantage?
>
> I dont use it much because it does not support trivial-garbage (it has
> no finalizations and no weak pointers), and some packages I use for some
> Programs require trivial-garbage. And many Libraries use the
> finalizations of cffi, which also do not work.
>
> But I am using it for some things. For example, I used it for some Stuff
> on a little VPS, where all other CL's I tried (except clisp, which has
> no threads, and alisp) couldnt even start. It mostly needs less RAM and
> loads faster that SBCL (at least this was my expierience), but it had no
> support for gray streams (which was the reason why i could not use
> allegroserve and hunchentoot and had to write many things myself).
>
> But again, I am not an expierienced programmer or professional in any
> way. Just doing this stuff for fun. So I wanted to know what the "real"
> cl-programmers say.
Last I heard a port of Huchentoot for ECL was underway.
ECL isn't much used, but as it get's closer to the ANSI standard I believe
it will gain momentum.
--------------
John Thingstad
"C.-S. S." <···@swissjabber.ch> writes:
> But again, I am not an expierienced programmer or professional in any
> way. Just doing this stuff for fun. So I wanted to know what the
> "real" cl-programmers say.
Oh, you mean the non-yobbos. I'd guess they use some commercial
implementation, and whine at their vendors when it doesn't do what
they want.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Remember, Information is not knowledge; Knowledge is not Wisdom;
Wisdom is not truth; Truth is not beauty; Beauty is not love;
Love is not music; Music is the best." -- Frank Zappa
thus spoke C.-S. S. <···@swissjabber.ch>:
> I dont use it much because it does not support trivial-garbage (it has
> no finalizations and no weak pointers), and some packages I use for some
> Programs require trivial-garbage. And many Libraries use the
> finalizations of cffi, which also do not work.
That's unusual. ECL uses Boehm GC which supports finalizers alright.
--
Nawet świnka wejdzie na drzewo kiedy ją chwalą.
On Apr 1, 11:42 pm, "C.-S. S." <····@swissjabber.ch> wrote:
> But it didnt support gray streams (it meanwhile does), finalisations and
> weak pointers (it still doesnt, but maybe it will soon). And it is not
> supported by many Projects.
Let me clear some things. ECL did support gray streams for a long
time. The only difference is that CLOSE, STREAM-ELEMENT-TYPE and a
couple other functions were not generic and you had to specialize
STREAM-CLOSE, etc, etc. That has changed.
ECL does not have weak pointers yet. This is an issue that has to do
with the garbage collector, where weak pointers are not directly
supported, and the equivalent, disappearing links, are not entirely
what one wants.
But ECL does have finalization. It has for some time, though the
appropriate chapter in the manual is still missing.
http://sourceforge.net/mailarchive/message.php?msg_id=c159f9ab0712290408qbc2719bt6e57d4a94cdcc95b%40mail.gmail.com
Juanjo
On Apr 4, 7:42 pm, Juanjo <·····················@googlemail.com>
wrote:
> But ECL does have finalization. It has for some time, though the
> appropriate chapter in the manual is still missing.
By the way, the finalization mechanism is now documented
http://ecls.sourceforge.net/new-manual/
Juanjo
Juanjo schrieb:
> On Apr 4, 7:42 pm, Juanjo <·····················@googlemail.com>
> wrote:
>> But ECL does have finalization. It has for some time, though the
>> appropriate chapter in the manual is still missing.
>
> By the way, the finalization mechanism is now documented
>
> http://ecls.sourceforge.net/new-manual/
>
> Juanjo
How old is this new manual? I didnt find anything about finalizations a
few weeks ago.
But anyway. Thank you. That was what I needed.
Couldnt weak pointers be implemented using Finalizations? I have to
admit that I dont know much about the inner Mechanisms of the Boehm GC,
so I could be completely wrong, but: Couldnt you just "hide" a Pointer
from the Garbage Collector by xor-ing it with some value, and implement
a weak-pointer as an object that consists of this xor-ed pointer to the
object and a boolean value that tells if the object still exists, which
is set to nil, if a finalization is called?
CSS
On Apr 7, 11:52 pm, "C.-S. S." <····@swissjabber.ch> wrote:
> How old is this new manual? I didnt find anything about finalizations a
> few weeks ago.
The manual is at least two years old, but it is slowly growing. The
finalization chapter was written last week.
> Couldnt weak pointers be implemented using Finalizations?
It is tricky to have a good mechanism that does not interfere with the
finalization routines that the user sets up and that is efficient.
Just finalization is currently not too efficient to have scalable weak
pointers and weak hashes (which is probably what you want in the end).
But I am working on that.
Juanjo