Hi,
I'm trying to find a free CL which is capable of creating reasonably
small and reasonably fast native Windows executables. If possible, the
generated executable should not rely on cygwin.
Here are the possibilities I'm aware of:
Clozure CL:
I tried to create an executable and it was enormous. Also didn't
work... and the documentation says almost nothing about the options. I
kind of lost hope in CCL for standalone executables, and decided to
look further.
CLISP:
Haven't tried it yet, but from comments that I read I don't expect it
to do significantly better.
GCL:
Next option I'm going to try.
Ufasoft Common Lisp:
Haven't tried it yet. The home page says it is a fork of CLISP, so I
don't expect any benefit.
ECL:
Haven't tried it yet. No threading and Unicode support under Windows,
so I'll consider it an option if I don't find anything better.
CLiCC:
Doesn't seem very promising and also seems to be very outdated.
ThinLisp:
Seems inactive and outdated.
Poplog:
Haven't tested it yet, but seems that support for Windows is way
behind Linux support as with almost all free CL implementations. Also
as CL is not the major goal of the product, I wonder how well
implemented it is.
So, if someone has experience with any of these options or can direct
me to an option I did not think of, please share...
Thanks in advance ;)
On 17 Apr, 10:32, MishoM <···············@gmail.com> wrote:
> I'm trying to find a free CL which is capable of creating reasonably
> small and reasonably fast native Windows executables. If possible, the
> generated executable should not rely on cygwin.
I've generated and deployed Windows executables using CLISP without
problems. They're not as small as a C compiled exe though as they
include a full Lisp system! I'd say 8-10Mb is a typical baseline.
If it's a GUI application you may find you end up with an additional
'Command Prompt' window popping up but you can suppress this by
writing a small start.exe wrapper in C to kick off your main
executable. I can send you the code for this if you need, it's only a
couple of lines.
--
Phil
http://phil.nullable.eu/
On Apr 17, 12:57 pm, Phil Armitage <···············@gmail.com> wrote:
> On 17 Apr, 10:32, MishoM <···············@gmail.com> wrote:
>
> > I'm trying to find a free CL which is capable of creating reasonably
> > small and reasonably fast native Windows executables. If possible, the
> > generated executable should not rely on cygwin.
>
> I've generated and deployed Windows executables using CLISP without
> problems. They're not as small as a C compiled exe though as they
> include a full Lisp system! I'd say 8-10Mb is a typical baseline.
>
> If it's a GUI application you may find you end up with an additional
> 'Command Prompt' window popping up but you can suppress this by
> writing a small start.exe wrapper in C to kick off your main
> executable. I can send you the code for this if you need, it's only a
> couple of lines.
>
> --
> Philhttp://phil.nullable.eu/
Thanks, so I'll switch to CLISP.
But I'm really disappointed that the free CL implementations don't
seem to make a difference between an "open" Lisp system and a
"finalized, closed" standalone executable. It seems obvious to me that
both are totally valid use cases and are also fundamentally different.
It is of great benefit to be able to change the system while it is
running when running a web based application for example, but when you
want to create a "desktop" application the "full Lisp system" is just
unnecessary baggage... I think I saw a "tree shaker" for Scheme but
couldn't find it now. Is there anything similar for CL (that works)?
On 17 Apr, 11:27, MishoM <···············@gmail.com> wrote:
> But I'm really disappointed that the free CL implementations don't
> seem to make a difference between an "open" Lisp system and a
> "finalized, closed" standalone executable. It seems obvious to me that
> both are totally valid use cases and are also fundamentally different.
> It is of great benefit to be able to change the system while it is
> running when running a web based application for example, but when you
> want to create a "desktop" application the "full Lisp system" is just
> unnecessary baggage...
It's just a different way of looking at things. I agree, native
executables are what most end users will expect but you can of course
ship the compiler, libraries and a batch file inside a neat installer
package which puts the necessary bits in the start menu. Most users
don't tend to go routing around in 'Program Files' to see what you put
there.
As Pascal mentions, LispWorks and Allegro are also good for making
executables.
> I think I saw a "tree shaker" for Scheme but
> couldn't find it now. Is there anything similar for CL (that works)?
I believe they exist but most of my stuff needs the compiler and
runtime in place so I've never had need for one.
--
Phil
http://phil.nullable.eu/
On Apr 17, 1:42 pm, Phil Armitage <···············@gmail.com> wrote:
> On 17 Apr, 11:27, MishoM <···············@gmail.com> wrote:
>
> > But I'm really disappointed that the free CL implementations don't
> > seem to make a difference between an "open" Lisp system and a
> > "finalized, closed" standalone executable. It seems obvious to me that
> > both are totally valid use cases and are also fundamentally different.
> > It is of great benefit to be able to change the system while it is
> > running when running a web based application for example, but when you
> > want to create a "desktop" application the "full Lisp system" is just
> > unnecessary baggage...
>
> It's just a different way of looking at things. I agree, native
> executables are what most end users will expect but you can of course
> ship the compiler, libraries and a batch file inside a neat installer
> package which puts the necessary bits in the start menu. Most users
> don't tend to go routing around in 'Program Files' to see what you put
> there.
This approach means shipping the compiler with every application -
i.e. a lot of duplication. And delivering executables is not only what
users expect, its also what many developers expect (at least because
the users expect it, if not for some other reason). Not having this
ability, or having an inadequate implementation of it is a problem
which ranges from a mere inconvenience to a real showstopper, because
it may affect the final application in many ways. And the fact that
the major commercial implementers support it is a clear indication
that this is a feature which adds value to the product, otherwise they
wouldn't put effort into it.
Bottom line - this is a valuable feature and to me, not having it in
the free implementations shows that their implementers are biased to
Linux, where there is often a CL system available, and to web apps,
where this doesn't matter.
On 17 Apr, 13:02, MishoM <···············@gmail.com> wrote:
> This approach means shipping the compiler with every application -
> i.e. a lot of duplication.
I suppose. If you know for sure that you have users who will be using
multiple of your Windows applications. Is this a likely problem you
face or just a hypothetical one?
> And delivering executables is not only what
> users expect, its also what many developers expect (at least because
> the users expect it, if not for some other reason).
I agree and already described how I *successfully delivered*
applications in this way. Have a go, see if it works for you.
> the major commercial implementers support it is a clear indication
> that this is a feature which adds value to the product, otherwise they
> wouldn't put effort into it.
Yes it's a feature which differentiates them from the current free
implementations and for those who need it and are willing to pay for
it, it's valuable. I understand your frustration but at the moment a
tree shaken, compiled exe on Windows may require you to spend money
unless someone knows otherwise.
> Bottom line - this is a valuable feature and to me, not having it in
> the free implementations shows that their implementers are biased to
> Linux, where there is often a CL system available, and to web apps,
> where this doesn't matter.
From what I see at conferences and user group meetings, a lot of
developers working on free Lisp stuff use Linux and Mac. I know I do
and obviously this is common across the whole free software world. I'm
just very glad that there are free compilers available for Windows at
all. Indeed, I'm pretty excited that CCL is looking very promising
across the big-three.
--
Phil
http://phil.nullable.eu/
On Apr 17, 8:02 am, MishoM <···············@gmail.com> wrote:
> On Apr 17, 1:42 pm, Phil Armitage <···············@gmail.com> wrote:
> > On 17 Apr, 11:27, MishoM <···············@gmail.com> wrote:
[...]
> > It's just a different way of looking at things. I agree, native
> > executables are what most end users will expect but you can of course
> > ship the compiler, libraries and a batch file inside a neat installer
> > package which puts the necessary bits in the start menu. Most users
> > don't tend to go routing around in 'Program Files' to see what you put
> > there.
> This approach means shipping the compiler with every application -
> i.e. a lot of duplication.
There's a lot of duplication in general with software delivery.
> And delivering executables is not only what users expect, its also
> what many developers expect (at least because the users expect it,
> if not for some other reason).
IME using Windows, users actually expect install scripts. Since you're
going to be including the compiler (or FASL loader) as part of the
runtime anyway, why not use it as part of your installation process
and then dump the executable image as the last stage? It's not a
perfect solution by any means, but by the standards of workarounds for
annoying software limitations, it's not all that unpleasant.
My advice is to write your app and ship it bloated with the extra
stuff, while venting your ongoing frustration about it here. :)
Many people won't notice, and many people who do notice won't care.
Some people will even prefer it---shipping with a built-in Lisp
implementation is a major part of why Emacs has been so successful,
and the built-in Lisp implementation you ship with will be a good deal
better than Emacs'.
[...]
> And the fact that the major commercial implementers support it is a clear
> indication that this is a feature which adds value to the product,
> otherwise they wouldn't put effort into it.
No doubt. But usually when a commercial product offers a feature that
its free counterparts don't, it's usually for a reason. In this case,
the reason is that no one is going to implement tree-shaking on
Windows if they don't get paid for it.
I can't think of a lot of ways to shift this calculus, but one thing
that just might work is to ship an awesome Windows applcation despite
the limited delivery abilities of the existing implementations.
Cheers,
Pillsy
From: Pascal J. Bourguignon
Subject: Re: Anyone have experience with building Windows executables with free Common Lisp implementations?
Date:
Message-ID: <7cab6ffmjy.fsf@pbourguignon.anevia.com>
MishoM <···············@gmail.com> writes:
> On Apr 17, 1:42�pm, Phil Armitage <···············@gmail.com> wrote:
>> On 17 Apr, 11:27, MishoM <···············@gmail.com> wrote:
>>
>> > But I'm really disappointed that the free CL implementations don't
>> > seem to make a difference between an "open" Lisp system and a
>> > "finalized, closed" standalone executable. It seems obvious to me that
>> > both are totally valid use cases and are also fundamentally different.
>> > It is of great benefit to be able to change the system while it is
>> > running when running a web based application for example, but when you
>> > want to create a "desktop" application the "full Lisp system" is just
>> > unnecessary baggage...
>>
>> It's just a different way of looking at things. I agree, native
>> executables are what most end users will expect but you can of course
>> ship the compiler, libraries and a batch file inside a neat installer
>> package which puts the necessary bits in the start menu. Most users
>> don't tend to go routing around in 'Program Files' to see what you put
>> there.
>
> This approach means shipping the compiler with every application -
I don't understand. Do you mean you can ship applications WITHOUT a
compiler embedded? But then, how can these application modify
themselves? How can they learn anything?
> [...] And delivering executables is not only what
> users expect, its also what many developers expect (at least because
> the users expect it, if not for some other reason).
Open source developers expect to be delivered the _sources_ of the
applications, not the executables. Already, with the sources I find
it hard to trust the software, have a look at
http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
so when I get a binary the first thing I do is to erase it, download
the sources, browse them and recompile them myself.
> Not having this ability, or having an inadequate implementation of
> it is a problem which ranges from a mere inconvenience to a real
> showstopper, because it may affect the final application in many
> ways. And the fact that the major commercial implementers support it
> is a clear indication that this is a feature which adds value to the
> product, otherwise they wouldn't put effort into it.
You seem to have a problem understanding the meaning of free software:
You are FREE to implement any feature you miss, we give you the
sources so you can easily modify the program!
So if you are _really_ lacking the feature, be our guest! Implement it!
> Bottom line - this is a valuable feature and to me, not having it in
> the free implementations shows that their implementers are biased to
> Linux, where there is often a CL system available, and to web apps,
> where this doesn't matter.
And you're not biased toward providing what _your_ users require perhaps?
--
__Pascal Bourguignon__
On Apr 17, 4:16 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> MishoM <···············@gmail.com> writes:
> > On Apr 17, 1:42 pm, Phil Armitage <···············@gmail.com> wrote:
> >> On 17 Apr, 11:27, MishoM <···············@gmail.com> wrote:
>
> >> > But I'm really disappointed that the free CL implementations don't
> >> > seem to make a difference between an "open" Lisp system and a
> >> > "finalized, closed" standalone executable. It seems obvious to me that
> >> > both are totally valid use cases and are also fundamentally different.
> >> > It is of great benefit to be able to change the system while it is
> >> > running when running a web based application for example, but when you
> >> > want to create a "desktop" application the "full Lisp system" is just
> >> > unnecessary baggage...
>
> >> It's just a different way of looking at things. I agree, native
> >> executables are what most end users will expect but you can of course
> >> ship the compiler, libraries and a batch file inside a neat installer
> >> package which puts the necessary bits in the start menu. Most users
> >> don't tend to go routing around in 'Program Files' to see what you put
> >> there.
>
> > This approach means shipping the compiler with every application -
>
> I don't understand. Do you mean you can ship applications WITHOUT a
> compiler embedded? But then, how can these application modify
> themselves? How can they learn anything?
>
> > [...] And delivering executables is not only what
> > users expect, its also what many developers expect (at least because
> > the users expect it, if not for some other reason).
>
> Open source developers expect to be delivered the _sources_ of the
> applications, not the executables. Already, with the sources I find
> it hard to trust the software, have a look athttp://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
> so when I get a binary the first thing I do is to erase it, download
> the sources, browse them and recompile them myself.
>
> > Not having this ability, or having an inadequate implementation of
> > it is a problem which ranges from a mere inconvenience to a real
> > showstopper, because it may affect the final application in many
> > ways. And the fact that the major commercial implementers support it
> > is a clear indication that this is a feature which adds value to the
> > product, otherwise they wouldn't put effort into it.
>
> You seem to have a problem understanding the meaning of free software:
>
> You are FREE to implement any feature you miss, we give you the
> sources so you can easily modify the program!
>
> So if you are _really_ lacking the feature, be our guest! Implement it!
>
> > Bottom line - this is a valuable feature and to me, not having it in
> > the free implementations shows that their implementers are biased to
> > Linux, where there is often a CL system available, and to web apps,
> > where this doesn't matter.
>
> And you're not biased toward providing what _your_ users require perhaps?
>
> --
> __Pascal Bourguignon__
Look, I don't want to start a heated argument here. I was just
inquiring some information and then I expressed my frustration about
not being able to do what I wanted. I know that this is free software
and that many people have put a lot of effort to make it possible for
me to use a CL system for free and I really appreciate it. It's just
that I have a very limited amount of free time in which I want to try
to write some applications that I have in mind and something that
works out of the box would make my life easier, because I don't have
the time to both tweak a CL implementation and do my own projects
(believe it or not, I have less than 6 hours of free time _per_week_).
You'll probably say that in this case I should pay for some of the
commercial implementations, and you'll probably be right, but when
there are high quality free implementations available it is natural to
want to use them instead.
I really don't want to argue, all I'll say is that in my opinion the
free CL implementations are underserving a big group of developers who
might otherwise decide to use CL. Any application which for some
reason doesn't need to be modified during execution needs only a part
of the CL system to run. And any project would benefit from
accommodating a larger user base - it's the users that stimulate the
development of a product - so free CL implementations would benefit
from being suitable for more developers.
Anyway, enough from me, thanks to all for the information and the good
suggestions.
Mihail
From: Pascal J. Bourguignon
Subject: Re: Anyone have experience with building Windows executables with free Common Lisp implementations?
Date:
Message-ID: <7cvdp3e29k.fsf@pbourguignon.anevia.com>
MishoM <···············@gmail.com> writes:
> On Apr 17, 4:16�pm, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> So if you are _really_ lacking the feature, be our guest! �Implement it!
>>
> Look, I don't want to start a heated argument here. I was just
> inquiring some information and then I expressed my frustration about
> not being able to do what I wanted. I know that this is free software
> and that many people have put a lot of effort to make it possible for
> me to use a CL system for free and I really appreciate it. It's just
> that I have a very limited amount of free time in which I want to try
> to write some applications that I have in mind and something that
> works out of the box would make my life easier, because I don't have
> the time to both tweak a CL implementation and do my own projects
> (believe it or not, I have less than 6 hours of free time _per_week_).
> You'll probably say that in this case I should pay for some of the
> commercial implementations, and you'll probably be right, but when
> there are high quality free implementations available it is natural to
> want to use them instead.
You know, we're all in the same boat here. The fact is that indeed,
CL implementations targetted first unix systems (it's easier to work
on unix, and since we're time starved, it's more efficient to use unix
than MS-Windows).
> I really don't want to argue, all I'll say is that in my opinion the
> free CL implementations are underserving a big group of developers who
> might otherwise decide to use CL. Any application which for some
> reason doesn't need to be modified during execution needs only a part
> of the CL system to run. And any project would benefit from
> accommodating a larger user base - it's the users that stimulate the
> development of a product - so free CL implementations would benefit
> from being suitable for more developers.
If there was really a big group of developers (or even interested
potential developers) wanting to use a free CL implementation on
MS-Windows with more features, they could probably finance the
developping of the missing features. But since the later is not
witnessed, we may doubt of the former.
I'm concluding that the small number of developers needing a lisp
implementation on MS-Windows need it to be able to _sell_ a program to
MS-Windows customers, so they can and do afford a commercial
implementation. At least until someone with enough free time and a
masochistic mindset fancy implementing the missing features on
MS-Windows.
Honestly, with the advent of Internet, can you still imagine any
developer stuck with MS-Windows, if not for commercial/professionnal
reasons?
Also, what may explain the less pressing urge on these features is
that CL is a standardized language. So you can develop your
application in portable CL on unix, and when you're ready to
distribute it, you make a demo to the first customer (with a
KDE/linux system), get some money, buy a commercial implementation on
MS-Windows, and easily port it to that commercial implementation to
conclude your first sell.
> Anyway, enough from me, thanks to all for the information and the good
> suggestions.
Hopefully, in a few years, free implementations will be more advanced
on MS-Windows. Clearly there's work done in this dirrection even if
it's slow.
--
__Pascal Bourguignon__
From: Thomas A. Russ
Subject: Re: Anyone have experience with building Windows executables with free Common Lisp implementations?
Date:
Message-ID: <ymifxg757tk.fsf@blackcat.isi.edu>
···@informatimago.com (Pascal J. Bourguignon) writes:
> If there was really a big group of developers (or even interested
> potential developers) wanting to use a free CL implementation on
> MS-Windows with more features, they could probably finance the
> developping of the missing features. But since the later is not
> witnessed, we may doubt of the former.
Hmmm. At least in the Mac world, there seems to be such a core of
developers. They are financing the improvement of the IDE for Clozure
Common Lisp (the lisp formerly known as OpenMCL).
So, it actually happens occassionally.
--
Thomas A. Russ, USC/Information Sciences Institute
From: Madhu
Subject: Re: Anyone have experience with building Windows executables with free Common Lisp implementations?
Date:
Message-ID: <m3ab6f5p1z.fsf@moon.robolove.meer.net>
* (Pascal J. Bourguignon) <··············@pbourguignon.anevia.com> :
Wrote on Fri, 17 Apr 2009 15:16:01 +0200:
| Open source developers expect to be delivered the _sources_ of the
| applications, not the executables. Already, with the sources I find
| it hard to trust the software, have a look at
| http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf so
| when I get a binary the first thing I do is to erase it, download the
| sources, browse them and recompile them myself.
Are you sure you're not missing the point of that classic paper? ---
Thompson is asking you to reflect on trusting the compiler and tool
chain---and just inspecting the source you are compiling will not
protect you from evil virii present in the tool chain that you are
implicitly trusting.
--
Madhu :)
From: Kenneth Tilton
Subject: Re: Anyone have experience with building Windows executables with free Common Lisp implementations?
Date:
Message-ID: <49e89a62$0$5935$607ed4bc@cv.net>
> * (Pascal J. Bourguignon) <··············@pbourguignon.anevia.com> :
> Wrote on Fri, 17 Apr 2009 15:16:01 +0200:
>
> | Open source developers expect to be delivered the _sources_ of the
> | applications, not the executables. Already, with the sources I find
> | it hard to trust the software, have a look at
> | http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf so
> | when I get a binary the first thing I do is to erase it, download the
> | sources, browse them and ...
easily pick out any attacks..... PWUUAHAHAHAHAHAHAHAHAHAHAHHAHAA!!!!!!
hth,kt
From: Pascal J. Bourguignon
Subject: Re: Anyone have experience with building Windows executables with free Common Lisp implementations?
Date:
Message-ID: <7czlefe2t2.fsf@pbourguignon.anevia.com>
Madhu <·······@meer.net> writes:
> * (Pascal J. Bourguignon) <··············@pbourguignon.anevia.com> :
> Wrote on Fri, 17 Apr 2009 15:16:01 +0200:
>
> | Open source developers expect to be delivered the _sources_ of the
> | applications, not the executables. Already, with the sources I find
> | it hard to trust the software, have a look at
> | http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf so
> | when I get a binary the first thing I do is to erase it, download the
> | sources, browse them and recompile them myself.
>
> Are you sure you're not missing the point of that classic paper? ---
> Thompson is asking you to reflect on trusting the compiler and tool
> chain---and just inspecting the source you are compiling will not
> protect you from evil virii present in the tool chain that you are
> implicitly trusting.
Of course, you have to compile by hand your bootstrap compiler, and
then use it to compile a compiler you've checked against such traps.
But then, you have to trust Intel, (which I don't), so you must go
back to the beach...
--
__Pascal Bourguignon__
From: George Neuner
Subject: Re: Anyone have experience with building Windows executables with free Common Lisp implementations?
Date:
Message-ID: <h9khu4pd0qhjbipa1v15831r99i4kifgqu@4ax.com>
On Fri, 17 Apr 2009 05:02:05 -0700 (PDT), MishoM
<···············@gmail.com> wrote:
>On Apr 17, 1:42�pm, Phil Armitage <···············@gmail.com> wrote:
>> On 17 Apr, 11:27, MishoM <···············@gmail.com> wrote:
>>
>> > But I'm really disappointed that the free CL implementations don't
>> > seem to make a difference between an "open" Lisp system and a
>> > "finalized, closed" standalone executable. It seems obvious to me that
>> > both are totally valid use cases and are also fundamentally different.
>> > It is of great benefit to be able to change the system while it is
>> > running when running a web based application for example, but when you
>> > want to create a "desktop" application the "full Lisp system" is just
>> > unnecessary baggage...
>>
>> It's just a different way of looking at things. I agree, native
>> executables are what most end users will expect but you can of course
>> ship the compiler, libraries and a batch file inside a neat installer
>> package which puts the necessary bits in the start menu. Most users
>> don't tend to go routing around in 'Program Files' to see what you put
>> there.
>
>This approach means shipping the compiler with every application -
>i.e. a lot of duplication. And delivering executables is not only what
>users expect, its also what many developers expect (at least because
>the users expect it, if not for some other reason).
You said you're targeting Windows. Have you not noticed there is a
folder called "Common Files" in "Program Files"? That is one place
you can put stuff that you expect to reuse in multiple applications.
Every Windows version since NT (~1993) has had it.
The other simple answer is to create a folder named for your company
and install each product in a subfolder within it. You can then
install CLisp in a common subfolder and reuse it as you wish. Or you
can just install CLisp directly in Program Files ... then anyone can
use it.
The only thing you need to watch out for with shared executable
dependencies is the EXE version of DLL hell. If your program depends
on any private modifications to your Lisp or any of its libraries,
keep the mods in your own program directory so you don't accidentally
screw up another application. This holds regardless of what platform
you deploy on.
>Not having this
>ability, or having an inadequate implementation of it is a problem
>which ranges from a mere inconvenience to a real showstopper, because
>it may affect the final application in many ways. And the fact that
>the major commercial implementers support it is a clear indication
>that this is a feature which adds value to the product, otherwise they
>wouldn't put effort into it.
>
>Bottom line - this is a valuable feature and to me, not having it in
>the free implementations shows that their implementers are biased to
>Linux, where there is often a CL system available, and to web apps,
>where this doesn't matter.
Linux (or shall we say "command line") bias is mostly irrelevant.
Windows is, for the most part, no harder to develop for or install on
than Linux - it's just different.
Microsoft's Windows installer is freely available and it will take
care of creating directories, modifying the path, making registry
entries (if necessary), installing for everyone or just the current
user, etc.
The only really important difference between the platforms is memory
management. Windows executables are not (memory) position independent
so you have to be careful on 32-bit Windows if your programs need to
share memory or if you need to run multiple instances of programs that
use (non-system) DLLs. In these circumstances it's a bit too easy to
run out of address space. The issues largely go away on 64-bit
Windows.
George
On 17 Apr., 12:27, MishoM <···············@gmail.com> wrote:
> On Apr 17, 12:57 pm, Phil Armitage <···············@gmail.com> wrote:
>
>
>
>
>
> > On 17 Apr, 10:32, MishoM <···············@gmail.com> wrote:
>
> > > I'm trying to find a free CL which is capable of creating reasonably
> > > small and reasonably fast native Windows executables. If possible, the
> > > generated executable should not rely on cygwin.
>
> > I've generated and deployed Windows executables using CLISP without
> > problems. They're not as small as a C compiled exe though as they
> > include a full Lisp system! I'd say 8-10Mb is a typical baseline.
>
> > If it's a GUI application you may find you end up with an additional
> > 'Command Prompt' window popping up but you can suppress this by
> > writing a small start.exe wrapper in C to kick off your main
> > executable. I can send you the code for this if you need, it's only a
> > couple of lines.
>
> > --
> > Philhttp://phil.nullable.eu/
>
> Thanks, so I'll switch to CLISP.
>
> But I'm really disappointed that the free CL implementations don't
> seem to make a difference between an "open" Lisp system and a
> "finalized, closed" standalone executable. It seems obvious to me that
> both are totally valid use cases and are also fundamentally different.
> It is of great benefit to be able to change the system while it is
> running when running a web based application for example, but when you
> want to create a "desktop" application the "full Lisp system" is just
> unnecessary baggage... I think I saw a "tree shaker" for Scheme but
> couldn't find it now. Is there anything similar for CL (that works)?
Well - LispWorks and Allegro CL come with a tree shaker and delivery
functions that allow you to drop runtime components like the debugger,
compiler, interpreter, detailed stuff like support for rationals or
complex numbers. You can even drop parts of the FORMAT implementation
in LispWorks if you want. Delivery of small standalone executables is
NOT something you just hit some button and the result will be perfect.
It is real work. Common Lisp as a language ecosystem has many
dependencies you might not foresee now. Dropping things like compiler,
interpreter or other parts can arbitrarily break libraries you may
want to use – a tree shaker does not safe you from that. Commercial
lisps like LispWorks and AllegroCL make this process easier by
offering tools and documentation to do it (LispWorks even has a
graphical delivery tool in the current release).
You _can_ do the same with the free CL implementations. I've seen it
done with SBCL for example. You actually have the source and therefore
can also drop things to reduce it. The main problem is knowing which
parts you can safely drop - so you have to invest in extending your
own knowledge of it or hope that someone else wants the same thing
like you and does it for you. But isn't this the price of using open
source?
ciao,
Jochen
On 17 Apr., 11:32, MishoM <···············@gmail.com> wrote:
> Hi,
>
> I'm trying to find a free CL which is capable of creating reasonably
> small and reasonably fast native Windows executables. If possible, the
> generated executable should not rely on cygwin.
I've used CLISP with success in the past. I think it all depends a bit
what your scale is on "small" and "reasonably fast". It even would
depend on how settled you are on "free" and "native executable". Is
"native windows executable" really so fixed to being a .exe or would a
shell script running your programm using the lisp executable and image
be enough?
(Just to offer some alternative ways that might be interesting even if
not valid within your constraints)
If you drop "free" you can add at least LispWorks and AllegroCL which
are both fast and can produce reasonably small native windows
executables.
If you drop "native windows executable" you could also choose ABCL
(Armed Bear Common Lisp) which runs on the JVM. I've written an
article about it and have done some benchmarks; if you do not heavily
depend on CLOS it can actually be quite fast.
SBCL is another option if the size of the result would not be that
important.
>
> Here are the possibilities I'm aware of:
>
> Clozure CL:
> I tried to create an executable and it was enormous. Also didn't
> work... and the documentation says almost nothing about the options. I
> kind of lost hope in CCL for standalone executables, and decided to
> look further.
AFAIU the Clozure CL port to Windows is quite new - give it some time
and I'm certain it would get better.
>
> CLISP:
> Haven't tried it yet, but from comments that I read I don't expect it
> to do significantly better.
I've used it in the past. If there are any problems you could try
asking on the CLISP mailing list.
>
> GCL:
> Next option I'm going to try.
It is known to run Maxima on several platforms including Windows. For
Maxima it also seems to be quite fast. In the past it has been known
for not being very compatible with ANSI Common Lisp, but this is long
ago and there has been quite some work on it AFAIR. It's certainly
worth a try!
>
> Ufasoft Common Lisp:
> Haven't tried it yet. The home page says it is a fork of CLISP, so I
> don't expect any benefit.
Never tried it - I personally would stick with CLISP instead.
>
> ECL:
> Haven't tried it yet. No threading and Unicode support under Windows,
> so I'll consider it an option if I don't find anything better.
I think it really depends on what you actually want to do with it.
I'm a very satisfied LispWorks customer (Mac, Win, Linux) and have
used SBCL (mainly under Linux), Clozure CL (under Mac), ABCL (Mac,Win)
and CLISP (under Linux, Mac and Windows). I think it is a great
fortune, that there is such a broad span of Common Lisp
implementations for many different constraints and purposes.
ciao,
Jochen
Thank you for taking the time to answer :)
On Apr 17, 1:36 pm, ····@crispylogics.com wrote:
> I've used CLISP with success in the past. I think it all depends a bit
> what your scale is on "small" and "reasonably fast". It even would
> depend on how settled you are on "free" and "native executable". Is
> "native windows executable" really so fixed to being a .exe or would a
> shell script running your programm using the lisp executable and image
> be enough?
Well, if native is impossible, I guest java or .NET are some
alternative. But distributing the development environment together
with every application seems too much to me...
> SBCL is another option if the size of the result would not be that
> important.
As far as I can say from experimenting and looking at the code, SBCL
has no support for creating Windows executables. The code is strictly
Linux specific.
> I'm a very satisfied LispWorks customer (Mac, Win, Linux)
It's for personal purposes, so I'm not ready to make the investment in
AllegroCL or LispWorks. If I decide that none of the free
implementations gives sufficient results, I'll first look into Corman
Lisp.
Thanks again.
On 17 Apr., 12:51, MishoM <···············@gmail.com> wrote:
> Thank you for taking the time to answer :)
>
> On Apr 17, 1:36 pm, ····@crispylogics.com wrote:
>
> > I've used CLISP with success in the past. I think it all depends a bit
> > what your scale is on "small" and "reasonably fast". It even would
> > depend on how settled you are on "free" and "native executable". Is
> > "native windows executable" really so fixed to being a .exe or would a
> > shell script running your programm using the lisp executable and image
> > be enough?
>
> Well, if native is impossible, I guest java or .NET are some
> alternative. But distributing the development environment together
> with every application seems too much to me...
Hm - it's not as if it is a hog like Visual Studio or Eclipse - isn't
it? ;-)
What do you mean by having the development environment within the
application? Being able to call COMPILE or EVAL? Some libraries or
applications can make good use of that possibility. If you want to
deliver patches you can distribute them as source or as FASLs which
you can just LOAD in your application. If something breaks you can
just flip some switch and have a debugger helping you finding what was
wrong. I don't see why not having those parts is a good idea for
desktop applications. I don't think you will save so much more space
that it is worth the pain; particularily in this days were the cost/GB
is so low. (I've put a 500 GB 2.5" drive in my MacBook last
days ;-) ).
>
> > SBCL is another option if the size of the result would not be that
> > important.
>
> As far as I can say from experimenting and looking at the code, SBCL
> has no support for creating Windows executables. The code is strictly
> Linux specific.
Sorry I didn't know that - I haven't tried it on windows. What SBCL
actually does on Linux is (simply spoken) prepending the lisp
executable to the lisp image so that it comes in one file. There is no
difference in the code of the lisp system. So actually just using
a .bat should give you much of the same effect.
> > I'm a very satisfied LispWorks customer (Mac, Win, Linux)
>
> It's for personal purposes, so I'm not ready to make the investment in
> AllegroCL or LispWorks. If I decide that none of the free
> implementations gives sufficient results, I'll first look into Corman
> Lisp.
Yes that is an option too - sorry I've forgotten Corman Lisp as MS
Windows lisp system.
Haven't tried it for a while - any interesting news?
ciao,
Jochen
On Apr 17, 7:26 pm, ····@crispylogics.com wrote:
> Sorry I didn't know that - I haven't tried it on windows. What SBCL
> actually does on Linux is (simply spoken) prepending the lisp
> executable to the lisp image so that it comes in one file.
which is also what newLISP does, at least on the Windows side.
--Bruce.
On Apr 17, 4:26 am, ····@crispylogics.com wrote:
> I don't think you will save so much more space
> that it is worth the pain; particularily in this days were the cost/GB
> is so low.
To me this is the operative point. The treeshakers in the commercial
implementations date back to the 1980s, when disk space cost
something. Now, the overhead of having the full Lisp implementation
in the executable is on the same order as a few mp3 files. Who cares
anymore???
-- Scott
From: Evans Winner
Subject: Re: Anyone have experience with building Windows executables with free Common Lisp implementations?
Date:
Message-ID: <864ownrozi.fsf@timbral.net>
MishoM <···············@gmail.com> writes:
It's for personal purposes, so I'm not ready to make the
investment in AllegroCL or LispWorks.
In that case this question is off-topic, but do the licenses
of the free CL implementations even allow for commercial
distribution of a dumped .exe including the whole lisp and
repl? I believe Clisp is GPL (because of readline?) and so
I don't think that would fly, would it? Implementations
that are llgpl or some such I don't know about. What is the
story with that?
As a side note, as far as end-user, desktop-type
applications, I can hardly think of something so trivial
that I wouldn't like to be able to get a repl and make my
own changes or additions, or automations.
On 17 abr, 07:51, MishoM <···············@gmail.com> wrote:
> Thank you for taking the time to answer :)
>
> On Apr 17, 1:36 pm, ····@crispylogics.com wrote:
>
> > I've used CLISP with success in the past. I think it all depends a bit
> > what your scale is on "small" and "reasonably fast". It even would
> > depend on how settled you are on "free" and "native executable". Is
> > "native windows executable" really so fixed to being a .exe or would a
> > shell script running your programm using the lisp executable and image
> > be enough?
>
> Well, if native is impossible, I guest java or .NET are some
> alternative. But distributing the development environment together
> with every application seems too much to me...
Java does that, doesn't it? I mean, the java virtual machine is much
bigger and uses a lot of more memory than, say, SBCL. Or am I wrong?
>
> > SBCL is another option if the size of the result would not be that
> > important.
>
> As far as I can say from experimenting and looking at the code, SBCL
> has no support for creating Windows executables. The code is strictly
> Linux specific.
That is not true. SBCL produces executables for Windows, but they are
more or less big, threads are not supported (at least didn't use to
be) and it is alpha state (it has to do with a bug with memory that
occurs rarely). See http://elliottslaughter.net/bunnyslayer/about for
an example of end-user executable produced for Windows using SBCL.
>
> > I'm a very satisfied LispWorks customer (Mac, Win, Linux)
>
> It's for personal purposes, so I'm not ready to make the investment in
> AllegroCL or LispWorks. If I decide that none of the free
> implementations gives sufficient results, I'll first look into Corman
> Lisp.
>
> Thanks again.
From: Pascal J. Bourguignon
Subject: Re: Anyone have experience with building Windows executables with free Common Lisp implementations?
Date:
Message-ID: <7ciql3fvof.fsf@pbourguignon.anevia.com>
MishoM <···············@gmail.com> writes:
> CLISP:
> Haven't tried it yet, but from comments that I read I don't expect it
> to do significantly better.
AFAIK, CLISP is the free CL implementation that produces the smalest
executables.
> So, if someone has experience with any of these options or can direct
> me to an option I did not think of, please share...
Franz and Lispworks also provide commercial implementations on
MS-Windows, and they will probably fulfill better your needs to
produce native executables.
--
__Pascal Bourguignon__
On 17 abr, 06:58, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> MishoM <···············@gmail.com> writes:
> > CLISP:
> > Haven't tried it yet, but from comments that I read I don't expect it
> > to do significantly better.
>
> AFAIK, CLISP is the free CL implementation that produces the smalest
> executables.
>
> > So, if someone has experience with any of these options or can direct
> > me to an option I did not think of, please share...
>
> Franz and Lispworks also provide commercial implementations on
> MS-Windows, and they will probably fulfill better your needs to
> produce native executables.
>
> --
> __Pascal Bourguignon__
Are you sure? ECL is pretty good at this as well, and is a bit faster
than CLISP. All you need to run an executable with ECL is the ecl.dll
library (about 4 mb last time I checked) and the executable (which is
nearly as small as a C executable). And, if you are distributing many
executables, you need to distribute the library only once, so I think
ECL is a better choice.
And some posts to ECL list say that it is working if you compile it
with MSVC
On Apr 17, 5:32 am, MishoM <···············@gmail.com> wrote:
> Hi,
>
> I'm trying to find a free CL which is capable of creating reasonably
> small and reasonably fast native Windows executables. If possible, the
> generated executable should not rely on cygwin.
Hi,
In very general terms:
You've got to treat your Lisp more like a virtual machine than like an
executable.
This is for a number of reasons, foremost of which is that lisp is
more like a virtual machine methodology than a C methedology.
Pretty much you have one image/executable of your lisp, and then a
number of sub-directories with the compiled files that you need for
your program to run.
Then you just create a file that loads the compiled files in the right
order, and a bat file (a shortcut works too sometimes); which calls
lisp and evaluates the file which loads the compiled files into the
image.
I've found that it is actually really really useful to have the REPL
and the compiler attached, even when delivering desktop applications.
A lot of this is that if you get a client calling you saying he has
crashed (or whatever), you can get some clue of what is going on by
having him use the REPL.
(I know some will argue that bugs should never happen, but as you
increase the size/age of a system, ++entropy and all that).
Also if you want to patch, you just send the appropriate compiled and
*poof* upgrade (vs. re-downloading an entire executable...).
If you have another program you want to sell, well he already has the
lisp image, so it is just a matter of the new load .fasl, the new
shortcut and the compiled files.
It also gives you an easy way to make the program user-extensible.
Using the lisp image is a perfectly reasonable solution, it is just a
matter of you having a pre-conceived notion about what is 'good'.
I should note that you can get one of the executable-installer-creator
programs, and wrap-up the installation process into a .msi or .exe or
whatever.
Then its really easy: they literally just download the appropriate
version (with lisp or without), run the installer (as with any other
application), and it installs... the shortcut appears on the start
menu just like any other application.
The only external difference between this and a .exe is that it might
take a couple seconds to load everything up (which is really trivial
for any program beyond a utility).
I've already read all previous reply.
Your need is quite unusual. As a C/C++ developer, the most native
executables oriented language I'd say, I'm used to ship a few DLL and
supporting files. Therefore the advice you've already got to save your
files in an installation directory and then providing a shortcut,
makes sense to me. Unless your application is trivial, there are going
to be a few dependencies.
Maybe you can have a look at a virtualization software, which compress
all needed files in a single executable? I know of a commercial one,
ThinInstall:
http://www.thindownload.com/
For simpler uses, I've heard that WinZip allows you to extract an
archive and automatically run one of the extracted files.
Think out of the box ;-)
Cheers
From: Dimiter "malkia" Stanev
Subject: Re: Anyone have experience with building Windows executables with free Common Lisp implementations?
Date:
Message-ID: <49ECD9CC.5070408@mac.com>
Here are some applications build using Lisp on Windows (most of them are
not using free lisp):
Raymond Kurzweill's Aaron (11mb) - http://www.kurzweilcyberart.com/ -
Franz AllegroCL 5.0
Andes Physics Tutor Demo (300mb) - http://www.andestutor.org/ - Franz
AllegroCL 8.10
Anvita Demo (1.8gb) - http://www.anvitahealth.com/ - Lispworks
Bunny Slayer (37mb) - http://elliottslaughter.net/bunnyslayer/about - SBCL
Igor Engraver (50mb) - http://www.noteheads.com/ - Lispworks
Lispix (53mb) - http://www.nist.gov/lispix/ - Franz AllegroCL 8.10
Maxima (86mb) - http://maxima.sourceforge.net/ - GCL 5.11
PrimeTrader (26mb) - http://www.netfonds.no/pt.php - Lispworks
Regex Coach (8mb) - http://www.weitz.de/regex-coach/ - Lispworks
Stuck On Algebra (97mb) - http://www.theoryyalgebra.com/ - Franz
AllegroCL 8.17
At last, something I've did, but haven't put anywhere, as it's not worth
that much:
P4Switch (5mb) - (no website) - Lispworks 5.1 - This was done by me -
it's a small applications that switches between different P4Win settings
found in the registry. This off course does not work with P4V (The Qt P4
frontend), but at my workplace we use P4Win still a lot
here is the code (Lispworks 5.1 Professional, Personal might work too)
;;p4switch.lisp
(defpackage "P4SWITCH" (:use "CL" "LISPWORKS"))
(in-package "P4SWITCH")
(defconstant +p4-client-list-registry-key+
"Software\\Perforce\\P4Win\\Recent Port-Client-User List")
(defconstant +p4-environment-registry-key+
"Software\\Perforce\\Environment")
(defun p4-get-default-client ()
(mapcar #'(lambda (value-name)
(win32:registry-value
+p4-environment-registry-key+
value-name))
'("P4PORT" "P4CLIENT" "P4USER")))
(defun p4-set-default-client (client-list)
(assert (= (length client-list) 3))
(mapcar #'(lambda (value-name value)
(setf (win32:registry-value
+p4-environment-registry-key+
value-name
:expected-type :string)
value))
'("P4PORT" "P4CLIENT" "P4USER")
client-list))
#+nil
(p4-get-default-client)
#+nil
(p4-set-default-client (p4-get-default-client))
(defun p4-get-recent-clients ()
(let ((clients-list
(win32:collect-registry-values
+p4-client-list-registry-key+))
(clients))
(dolist (client clients-list)
(let ((client-list
(split-sequence " " (cdr client))))
(when (= (length client-list) 3)
(pushnew client-list clients)
#+nil
(format t "P4PORT=~A P4CLIENT=~A P4USER=~A~&"
(first client-list)
(second client-list)
(third client-list)))))
(nreverse clients)))
#+nil
(p4-get-recent-clients)
(capi:define-interface p4switch-interface ()
((p4-default-client :initform (p4-get-default-client))
(p4-recent-clients :initform (p4-get-recent-clients)))
(:panes
(listbox capi:multi-column-list-panel
:columns '((:title "Server:port")
(:title "Client")
(:title "User"))
:items p4-recent-clients
:action-callback
#'(lambda (item self)
(declare (ignore self))
(p4-set-default-client item)))
(move-up-button capi:push-button
:text "Move up")
(move-down-button capi:push-button
:text "Move down")
(delete-button capi:push-button
:callback
#'(lambda (data interface)
(declare (ignore data))
(with-slots (listbox) interface
(capi:remove-items listbox
(print
(capi:choice-selected-item listbox)))
(setf (capi:collection-items listbox)
'("1" "2" "3"))
))
:text "Delete"))
(:layouts
(column-layout-1 capi:column-layout
'(simple-layout-1
row-layout-1))
(simple-layout-1 capi:simple-layout
'(listbox))
(row-layout-1 capi:row-layout
'(move-up-button
move-down-button
delete-button)))
(:default-initargs
:layout 'column-layout-1
:best-height 300
:best-width 300
:title "p4switch - ······@gmail.com"))
(defmethod initialize-instance :after ((self p4switch-interface)
&key &allow-other-keys)
(with-slots (listbox p4-default-client) self
(print p4-default-client)
(setf (capi:collection-test-function listbox) #'equal)
(setf (capi:choice-selected-item listbox) p4-default-client)))
(defun main ()
(capi:display (make-instance 'p4switch-interface)))
#+nil
(main)
;; The delivery file:
;; p4deliver-lisp.lisp
(in-package "CL-USER")
(load-all-patches)
(defvar *delivered-image-name* "p4switch")
(compile-file-if-needed (current-pathname *delivered-image-name*) :load
t :output-file (pathname-location *delivered-image-name*))
(deliver 'p4switch::main *delivered-image-name* 5 :interface :capi)
From: Dimiter "malkia" Stanev
Subject: Re: Anyone have experience with building Windows executables with free Common Lisp implementations?
Date:
Message-ID: <gsiluh$c33$1@malkia.motzarella.org>
I've just uploaded the p4switch.zip example.
You would need Lispworks Professional to recompile it.
It's using the wonderful LW's CAPI GUI library.
http://p4switch.googlecode.com/files/p4switch.zip (1.7mb)
From: Dimiter "malkia" Stanev
Subject: Re: Anyone have experience with building Windows executables with free Common Lisp implementations?
Date:
Message-ID: <gsim46$c33$2@malkia.motzarella.org>
I've uploaded p4switch.zip - not the same version of what I've posted
above, but still working (though needs some more work)
http://p4switch.googlecode.com/files/p4switch.zip - 1.7mb