size of executables?
Aleksandr Skobelev
produced by commercial Lisp's realizations (LWW, Allegro). If, for
example, the program contains only definition and call of one simple
function.
Aleksandr
Wade Humeniuk
2,949,148 Bytes hello-world.exe
1,052,779 Bytes hello-world.zip
http://www.cadvision.com/humeniuw/hello-world.zip
To be fair, a non-trivial full size LWW CAPI app is not much bigger
(4,390,940 Bytes)
Self installing exe at:
http://www.cadvision.com/humeniuw/runnerslogtrial1.40.exe (1,703,587 Bytes)
The CAPI app is much smaller (1/3) than some Visual Basic apps with the same
functionality.
Wade
"Aleksandr Skobelev" <22...@mail.ru> wrote in message
news:jnltn9...@hermit.athome...
Kent M Pitman
Aleksandr Skobelev
As far as I understand they are statically linked binaries in contrast to
Basic's dynamically linked (to VB dlls) ones?
Aleksandr
Aleksandr Skobelev
For I am curious. :)
To have a more clear picture.
To compare.
To make conclusions.
To take decisions. :)
Thomas F. Burdick
> Kent M Pitman <pit...@world.std.com> wrote:
> > Aleksandr Skobelev <22...@mail.ru> writes:
> >
> >> I should be curious to know how much is a size of standalone executables
> >> produced by commercial Lisp's realizations (LWW, Allegro). If, for
> >> example, the program contains only definition and call of one simple
> >> function.
> >
> > Why?
>
> For I am curious. :)
> To have a more clear picture.
Okay.
> To compare.
> To make conclusions.
> To take decisions. :)
Oh, be careful! Use this information only to make conclusions and
descisions about programs that consist of one simple function.
Whatever you do, don't use this to draw conclusions about reasonable
applications. One of the central design goals of C++ was "pay as you
go". Lisp implementations sometimes have a facility to remove what
you didn't use from the delivered application, but they're generally
constructed with the idea that you'll use most of the facilities in
the system. This makes C++ okay for delivering one-off applications
(so long as you don't use iostreams), but that doesn't say a thing
about larger programs. Once you add in the parts of the STL you're
using, iostreams, and whatever 3rd-party libraries you need, C++ apps
that do something useful tend to bloat pretty quickly up to and
surpassing Lisp apps.
Coby Beck
> Kent M Pitman <pit...@world.std.com> wrote:
> > Aleksandr Skobelev <22...@mail.ru> writes:
> >
> >> I should be curious to know how much is a size of standalone executables
> >> produced by commercial Lisp's realizations (LWW, Allegro). If, for
> >> example, the program contains only definition and call of one simple
> >> function.
> >
> > Why?
>
> For I am curious. :)
There must be more interesting questions to investigate! : )
> To have a more clear picture.
Of what?
> To compare [size?].
Again, one would ask "Why?"
> To make conclusions.
> To take decisions. :)
>
About what? ?:o|
I'm not trying to be at all combative here, but I think if you consider
carefully the value of any answer to your above question, you will realize it
is only useful if your decision is "I have one floppy left with X bytes, can I
fit this program on it?" How else could it matter and what does it tell you
about the language that its smallest .exe is such and such a size?
That said, you might check
http://www-aig.jpl.nasa.gov/public/home/gat/lisp-study.html for a comparative
study of lisp/java/c++ programs in terms of size, speed, LOC and developer time
if these are really critical factors for a project you are about to undertake.
Coby
--
(remove #\space "coby . beck @ opentechgroup . com")
Scott Schwartz
> On LWW, hello-world is
>
> 2,949,148 Bytes hello-world.exe
> 1,052,779 Bytes hello-world.zip
Using stalin-0.8 (a scheme compiler), on sparc, the size of the a.out is 7,128
bytes, (2472 code, 472 data, 356 bss, and some debugging symbols).
Aleksandr Skobelev
Thomas F. Burdick <t...@apocalypse.ocf.berkeley.edu> wrote:
> Aleksandr Skobelev <22...@mail.ru> writes:
>
>> Kent M Pitman <pit...@world.std.com> wrote:
>> > Aleksandr Skobelev <22...@mail.ru> writes:
>> >
>> >> I should be curious to know how much is a size of standalone executables
>> >> produced by commercial Lisp's realizations (LWW, Allegro). If, for
>> >> example, the program contains only definition and call of one simple
>> >> function.
>> >
>> > Why?
>>
>> For I am curious. :)
>> To have a more clear picture.
>
> Okay.
>
>> To compare.
>> To make conclusions.
>> To take decisions. :)
>
> Oh, be careful! Use this information only to make conclusions and
> descisions about programs that consist of one simple function.
I will be very careful. :)
> Whatever you do, don't use this to draw conclusions about reasonable
> applications. One of the central design goals of C++ was "pay as you
> go". Lisp implementations sometimes have a facility to remove what
> you didn't use from the delivered application, but they're generally
> constructed with the idea that you'll use most of the facilities in
> the system. This makes C++ okay for delivering one-off applications
> (so long as you don't use iostreams), but that doesn't say a thing
> about larger programs. Once you add in the parts of the STL you're
> using, iostreams, and whatever 3rd-party libraries you need, C++ apps
> that do something useful tend to bloat pretty quickly up to and
> surpassing Lisp apps.
I see your point and in general I agree with you. But, in my opinion, it
would be not bad if Lisp executables could been built without features
that were not used. "Pay only for what you use" -- it is a thing that I
like in C++. If I don't use iostreams and exceptions and still use STL, I
need not link a c++ library. I believe it can be also implemented in CL
realisations, because after the moment when a standalone executable has
been created, it is not a part of a Lisp system more, and theoretically
:) all unusable parts could be determinated and removed during the
building stage. On the other hand I can say nothing about is this work on
reduction of size of Lisp executables is really needed to be done? ...
Well, if consider Lisp system as a means for creation complex intellectual
and probably interactive system, then defenitely not, it isn't needed.
Aleksandr
Aleksandr Skobelev
Coby Beck <cb...@mercury.bc.ca> wrote:
>
> "Aleksandr Skobelev" <22...@mail.ru> wrote in message
> news:1hqun9...@hermit.athome...
>> Kent M Pitman <pit...@world.std.com> wrote:
>> > Aleksandr Skobelev <22...@mail.ru> writes:
>> >
>> >> I should be curious to know how much is a size of standalone executables
>> >> produced by commercial Lisp's realizations (LWW, Allegro). If, for
>> >> example, the program contains only definition and call of one simple
>> >> function.
>> >
>> > Why?
>>
>> For I am curious. :)
>
> There must be more interesting questions to investigate! : )
But this is such simple and yet hasn't been learned.
>
>> To have a more clear picture.
>
> Of what?
Of a size.
>
>> To compare [size?].
>
> Again, one would ask "Why?"
>
>> To make conclusions.
>> To take decisions. :)
>>
>
> About what? ?:o|
>
> I'm not trying to be at all combative here, but I think if you consider
> carefully the value of any answer to your above question, you will realize it
> is only useful if your decision is "I have one floppy left with X bytes, can I
> fit this program on it?" How else could it matter and what does it tell you
> about the language that its smallest .exe is such and such a size?
>
I don't require of Lisp realization to generate smallest executables. But
I'd prefer if size was not too much big.
If I take participation in a project and I'd like to move my part silently from
C++ into Lisp then any dramatically worsening in any of characteristics is not
allowed. Despite of any advantages of using Lisp. Size is also very important
because of distribution of programs over Internet. Not all people have a
very good Internet connection. For example, my home uplink is only 28 kb
mostly. So I always think twice before downloading something that ~500 kB.
> That said, you might check
> http://www-aig.jpl.nasa.gov/public/home/gat/lisp-study.html for a comparative
> study of lisp/java/c++ programs in terms of size, speed, LOC and developer time
> if these are really critical factors for a project you are about to undertake.
> ...
Thank you I've already read it and added to my armoury. :)
Alekasndr
Erik Naggum
> I see your point and in general I agree with you. But, in my opinion, it
> would be not bad if Lisp executables could been built without features
> that were not used.
Why is that not bad? You keep repeating all these things as if there
were no reason to explain yourself. There is. Your assumptions need to
be made explicit and open to re-evaluation.
> "Pay only for what you use" -- it is a thing that I like in C++.
So use C++, then. I completely fail to see the problem. If you want to
use a different language, you actually have to buy the whole package
deal, not just the bits and pieces you like and then keep some other
language -- if you want that, build yourself a CL++ environment.
> I believe it can be also implemented in CL realisations, because after
> the moment when a standalone executable has been created, it is not a
> part of a Lisp system more, and theoretically :) all unusable parts could
> be determinated and removed during the building stage.
The "standalone executable" (the only such thing on modern computers are
boot loaders, so why you so desperately want a boot loader in Common Lisp
is beyond me, and I might even argue strongly against writing boot
loaders in Common Lisp unless you booting a Common Lisp system from the
bare metal) _is_ the Common Lisp system. There is no pracical difference
between the development environment and the "executable". If you decide
to remove large fractions of the development environment, you end up with
a system that is both hard to debug and harder to evolve. One of the
great strengths of a Common Lisp system is that you can patch it while it
is running, and so one of the great features of Common Lisp applications
that they can run forever (bounded only by system reboot and shutdown)
> On the other hand I can say nothing about is this work on reduction of
> size of Lisp executables is really needed to be done? ... Well, if
> consider Lisp system as a means for creation complex intellectual and
> probably interactive system, then defenitely not, it isn't needed.
Certain Common Lisp vendors have positioned themselves such that it is
financially suicidal to create anything _but_ hugely complex applications
in Common Lisp. This means (their) Common Lisp is never used to build
the kinds of toys that programmers need to build trust in their tools.
Being able to dump a toy executable like you ask for is therefore highly
desirable, but it is a completely useless exercise for anything other
than such building of trust in your tools. You would never actually want
to deploy an "application" in C, C++, or Java that did anything similarly
trivial to the hello, world programs, but the model for building a simple
program is similar in certain respects to building a large program, and
that is why the hello, world program is useful in their context. In the
Common Lisp context, dumping an image that can be the "application" is a
very late stage in the application development process, and one of my
major Common Lisp projects never got that far at all -- it is running in
the same environment it was developed, and it has been for almost four
years. (Some communications slaves were built as runtime images because
of licensing issues, but we would otherwise not have been forced to build
runtime images.)
The hello, world programs are necessary in order to show people how to
get from source to callable function. This is superfluous in a language
where typing in the source code is sufficient to all it. It is like
asking how you write a hello, world program in a Unix shell. Stuff "echo
hello, world!" in a file, then run it. Big deal. The shell is the same
kind of interactive environment that a Common Lisp environment is, so the
task of compiling a C source program is that of bringing it into the
shall's world-view. Since Common Lisp environments are powerful enough
to accept a reasonable language (imagine how much more intelligent Unix
would have been if you could have written interactive C programs in the
shell!), you do not need bridging source (definition) and usage, and it
is generally not necessary to bridge Common Lisp environments and the
shell, either, since starting the application can be arbitrarily complex
without meaning anything to the user -- just use a shell script that
fires up the Common Lisp system with the appropriate options. That is,
after all, what shell scripts are intended to be used for, and there is
absolutely no value in forcing every other program to do what the shell
can do much more painlessly for you, and installing files and stuff is
already done by package management software (at least on all reasonable
operating systems), so you only ship one file to your uses, anyway. (On
the other hand, no Common Lisp environment I know of is able to build a
RPM or, much, much preferably, a Debian package, but that is the _real_
application delivery these days.)
On the other hand, I would have preferred a Common Lisp system that built
binaries and used the shared library ("DLL" to Microsoft victims) support
in the operating system instead of re-implementing all this stuff on
their own in ways that means you cannot use them with other languages,
while they still have to be able to use shared libraries to interface with
foreign function code, so something is clearly wanting in that design.
///
Erik Naggum
> Of a size.
You have to check the memory imprint of a program when it terminates to
see its size. What is on disk in the particular file you call to run it
is completely irrelevant. If you want that file to be small, use a shell
script that invokes the Common Lisp system. If you think this is highly
misleading, consider the fact that omitting the size of all the shared
resources that makes it possible to end up with a small executable is
also cheating.
> I don't require of Lisp realization to generate smallest executables.
> But I'd prefer if size was not too much big.
_Why_? What is it to you? Why does disk space matter to _anyone_ these
days? My Debian GNU/Linux development machine has 120G of disk space
right now, and I cannot even _imagine_ life as a programmer without huge
excesses of disk resources, anymore. With the kind of cheap disks we get
these days, that amount of disk space is within reach for anyone with no
more than your take-home pay for a couple week's worth of work.
> If I take participation in a project and I'd like to move my part
> silently from C++ into Lisp then any dramatically worsening in any of
> characteristics is not allowed.
Pardon me, but this is a really stupid position to hold. You argue as if
you were dirt poor with absolutely no hope of improving your situation
because you are in such a dire situation that you cannot spend a nickel
to get out of it. If this is indeed true, Common Lisp cannot help you.
I can tell you right away that you will not get out of your dump with the
aid of Common Lisp. Sorry about that.
If, however, you are willing to work _with_ the Common Lisp system and
not against it, you will find that you can have your "executables" be
only the compiled files and you can invoke them easily with shell scripts
or simple loader functions in init files.
> Despite of any advantages of using Lisp. Size is also very important
> because of distribution of programs over Internet. Not all people have a
> very good Internet connection. For example, my home uplink is only 28 kb
> mostly. So I always think twice before downloading something that ~500
> kB.
The way to do this is to download the Common Lisp environment _once_,
then download small object files, not full executables or images. E.g.,
CMUCL can dump _huge_ images, and most other Common Lisp environments
also dump huge images files (however, they do compress really well :),
but the source code or the compiled files are fairly small. People tend
to have to install runtime libraries for _all_ their other environments,
too, so I fail to see why the same standard cannot be applied to Common
Lisp. It is as if some people simply have made up their mind that they
cannot use Common Lisp unless it is virtually identical to their some
particular other tools. For instance, do you see people whine that Perl
programs are so big? No, not at all, but why? Perl is already installed
and the programs are very small, but Perl itself is *large*, yet nobody
complains.
I think there are many assumptions underlying your line of questioning
that need to be enunciated and re-opened for you to get closer to useful
answers.
///
Christophe Rhodes
> (On the other hand, no Common Lisp environment I know of is able
> to build a RPM or, much, much preferably, a Debian package, but
> that is the _real_ application delivery these days.)
Well, there are some wanderings in that direction with cCLan and Peter
van Eynde's common-lisp-controller; essentially, slurping in a
defsystem, working out which are the source files (this is slightly
tricky), heuristically writing the debian/* files and running
dpkg-buildpackage can be done.
There's a proof of concept in cCLan CVS, but it's a while away from
prime-time; for a start a defsystem that isn't MK-defsystem is needed,
as rather more introspection and extensibility is necessary (Dan
Barlow's asdf is probably my favoured candidate at the moment). The
other thing that I maintain needs to be done is a move away from CL's
pathnames, both physical and logical towards something entirely new (I
think URLs), but this may involve some serious tinkering with
functions in the CL package (should
(open #u"file://localhost/tmp/foo.lisp")
work? Should
(open #u"http://www.bar.com/foo.lisp")?
Should there be provision for user-defined schemes?) These slightly
vague musings might turn into a real proposal eventually; in the
meantime, there's
<URL:http://www-jcsu.jesus.cam.ac.uk/~csr21/uri.lisp> (patches
welcome...)
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Kent M Pitman
> Thomas F. Burdick <t...@apocalypse.ocf.berkeley.edu> wrote:
> > Aleksandr Skobelev <22...@mail.ru> writes:
> >
> ...
> > Oh, be careful! Use this information only to make conclusions and
> > descisions about programs that consist of one simple function.
>
> I will be very careful. :)
> ...
> > Whatever you do, don't use this to draw conclusions about reasonable
> > applications. ...
>
> I see your point and in general I agree with you. But, in my opinion,
> it would be not bad if Lisp executables could been built without features
> that were not used.
It's fine for any individual to hold whatever opinion they like. The
language is utterly neutral on the issue; it's left to the vendors.
And the measure of goodness and badness for a vendor is "do I think
this will affect sales".
There are several things to be said on this matter:
* Different vendors make this trade-off differently. Find a vendor
that has your sensibilities and is responsive to your needs.
* It is a fact that users lie (not always, but sometimes) about things
they say would make or break a sale. Users want to get certain all
the things they can for as little as possible, and many (including
probably myself from time to time) aren't above posturing to try to
sway a vendor into action. Vendors know users lie and sometimes bank
on it by making decisions to spend their investment dollars in other
ways, hoping the user base will understand. Which often it does.
Lots of people have asked for small footprint in "hello world", but
the bigger vendors have found that this is not where their market is.
That leaves a niche for smaller vendors to fill in order to get some
market traffic the big vendors didn't go after. That doesn't make
either vendor right or wrong, it shows that markets take care of
themselves by incentivizing diversity.
* The real issue that drives where we should go is not any individual's
opinion (though you're always welcome to express yours, and it's only
through aggregating many such expressions that we learn what people
want--and though, as in my previous point, simple "summing" of what
people said is a misleading tool for doing such aggregation). It's
easy to say "I want x", "I want y", "I want z". What's hard to come
to grips with is that what REALLY matters and what's harder to say is
"x is more important than y". Vendors are, within the limits of their
budget, happy to provide everything you ask for. But their budgets
end up being more limited than they wish, and it's not that they
don't listen but that they end up making choices between things.
"I want x" does not help them set priorities. It sounds to them like
a kid in a candy store who wants one of everything--it doesn't help
the parent know what to get. "I want small hello world footprint
more than I want XML support" would be a materially more interesting
statement. Or "I want small hello world footprint more than I want
support for RMI".
> "Pay only for what you use" -- it is a thing that I
> like in C++.
You're just saying what you want. Examine the list of things vendors are
making and tell them what things they are working on that they shouldn't be
in order that they know out of what budget to pay for this request.
> If I don't use iostreams and exceptions and still use STL, I
> need not link a c++ library.
It's an accident of history that Lisp didn't focus on this kind of
construction at the lowest level. It does at the higher level, of course,
since you can load whatever libraries you want and not others. So the
question becomes whether the relatively tiny footprint of lisp is where
Lisp's limited investment dollars should go. A typical video game like
Starcraft takes nearly a gigabyte of disk and uses tons of memory compared
to Lisp.
Lisp has a number of serious competitive issues to confront, but it's
so hard to make the case that this is one of them as prices of disk
and memory go down, down, down that I find requests of this kind
to be dangerously distracting from what Lisp really needs to do. IMO,
it would be bad for all vendors to just drop what they are doing and
address your concern, however legitimate that concern is to you personally.
> I believe it can be also implemented in CL
> realisations, because after the moment when a standalone executable has
> been created, it is not a part of a Lisp system more, and theoretically
> :) all unusable parts could be determinated and removed during the
> building stage. On the other hand I can say nothing about is this work on
> reduction of size of Lisp executables is really needed to be done? ...
> Well, if consider Lisp system as a means for creation complex intellectual
> and probably interactive system, then defenitely not, it isn't needed.
Implementability has never been the issue. Focus of resources is always
the issue. At the time most of the other languages developed the modular,
linkable component application, Lisp was elsewhere. By the time Lisp
realized it mattered, many vendors had made assumptions that made it hard
to retrofit that; they have done some retrofitting, but it is not complete.
But at this point, memory/disk prices are dropping so fast as to make
concern over this of diminishing value compared to other issues.
Also, traditionally, such bigger systems are where Lisp has been able to
make its mark, and such bigger systems tend to dwarf the size of the
little footprint anyway, enough that even in the past before memory
got cheap, this was not a major concern.
But at this point, with the possibly singular exception of floppy
disks, no one cares at all about an application that is only 2 or 16
MB. Yes, writing CD-roms is not QUITE as convenient, but it's pretty
darned easy. And not everyone has a CD-ROM reader, but most people
with serious money do (that is, most people who are going to pay the
money that keeps vendors in business). Home computers often come standard with
40GB disks now, and it's getting hard to find disks of 10GB or less.
40GB is roughly enough to hold 10,000 such applications. The Start
Menu would fill up long before the disk at that rate. Not to mention
the charges on your credit card.
Jochen Schmidt
I don't know if you have looked at my CommonURI package that is an
implementation of Franz' URI API. As we already talked on the topic of URIs
I thought you would contact me to merge the efforts (As I have already done
some of the work involved...)
ciao,
Jochen
Bijan Parsia
[snip]
> > Despite of any advantages of using Lisp. Size is also very important
> > because of distribution of programs over Internet. Not all people have a
> > very good Internet connection. For example, my home uplink is only 28 kb
> > mostly. So I always think twice before downloading something that ~500
> > kB.
>
> but the source code or the compiled files are fairly small. People tend
> to have to install runtime libraries for _all_ their other environments,
> too, so I fail to see why the same standard cannot be applied to Common
> Lisp. It is as if some people simply have made up their mind that they
> cannot use Common Lisp unless it is virtually identical to their some
> particular other tools. For instance, do you see people whine that Perl
> programs are so big? No, not at all, but why? Perl is already installed
> and the programs are very small, but Perl itself is *large*, yet nobody
> complains.
Python, Ruby, and other non-Perl environments of this sort are also very
large and more often than Perl have to be downloaded (and installed, and
configured) before you can run a thing. I've *never* seen that be an
issue. Never. It *is*, sometimes, an issue (i.e., I've experienced the
pain of having to download a newer version of these environment and had
trouble getting someone else to run a program because they had to download
a bunch of HUGE zips), but it's rarely puffed up into a show stopping
worry *except* for image based langauges. Weird that.
And Python, at least, has a "freeze" facility that let's you basically
"dump an image". I've seen many such programs distributed over the
internet. And even downloaded by poor 28kers.
Cheers,
Bijan Parsia.
Bijan Parsia
[snip]
> the kinds of toys that programmers need to build trust in their tools.
> Being able to dump a toy executable like you ask for is therefore highly
> desirable, but it is a completely useless exercise for anything other
> than such building of trust in your tools. You would never actually want
> to deploy an "application" in C, C++, or Java that did anything similarly
> trivial to the hello, world programs, but the model for building a simple
> program is similar in certain respects to building a large program, and
> that is why the hello, world program is useful in their context.
Y'know, I've taken this line for years, but reading this made me think of
CGIs. It seems to me that loads of actually deployed CGIs aren't *that*
much more complex than the hello, world program. For some reason this
never struck me as plausible when people brought up "trivial" shell utils.
(I think for hello, world *per se* your analysis is spot on and I doubt
that people asking about it are asking about simple cgis.)
It might be a worthwhile addition to a FAQ to have examples of very simple
CGIs, at least for raising the general trust in Common Lisp as a tool.
Cheers,
Bijan Parsia.
Christophe Rhodes
> Christophe Rhodes wrote:
>
> > The
> > other thing that I maintain needs to be done is a move away from CL's
> > pathnames, both physical and logical towards something entirely new (I
> > think URLs), but this may involve some serious tinkering with
> > functions in the CL package (should
> > (open #u"file://localhost/tmp/foo.lisp")
> > work? Should
> > (open #u"http://www.bar.com/foo.lisp")?
> > Should there be provision for user-defined schemes?) These slightly
> > vague musings might turn into a real proposal eventually; in the
> > meantime, there's
> > <URL:http://www-jcsu.jesus.cam.ac.uk/~csr21/uri.lisp> (patches
> > welcome...)
>
> I don't know if you have looked at my CommonURI package that is an
> implementation of Franz' URI API. As we already talked on the topic of URIs
> I thought you would contact me to merge the efforts (As I have already done
> some of the work involved...)
Oh, yes, it's on my list of things to do, I promise. It's not yet
entirely clear to me what I want, which is why I'm not at the stage of
merging efforts.
Aleksandr Skobelev
> * Aleksandr Skobelev <22...@mail.ru>
>
> Why is that not bad? You keep repeating all these things as if there
> were no reason to explain yourself. There is. Your assumptions need to
> be made explicit and open to re-evaluation.
>
I think, I have tried explaining myself well enough in this thread. But
if you have any questions, I always will be glad to reply. Just ask.
> So use C++, then. I completely fail to see the problem. If you want to
> use a different language, you actually have to buy the whole package
> deal, not just the bits and pieces you like and then keep some other
> language -- if you want that, build yourself a CL++ environment.
>
So do I. There is no any problem. But I don't feel that I have to buy
something to use different language. At least at the beginning stage.
>> I believe it can be also implemented in CL realisations, because after
>> the moment when a standalone executable has been created, it is not a
>> part of a Lisp system more, and theoretically :) all unusable parts could
>> be determinated and removed during the building stage.
>
> The "standalone executable" (the only such thing on modern computers are
> boot loaders, so why you so desperately want a boot loader in Common Lisp
> is beyond me, and I might even argue strongly against writing boot
> loaders in Common Lisp unless you booting a Common Lisp system from the
> bare metal) _is_ the Common Lisp system.
You are kidding. Need I explain you meaning of "standalone executable"
term in my messages?
> There is no pracical difference between the development environment and
> the "executable". If you decide to remove large fractions of the
> development environment, you end up with a system that is both hard to
> debug and harder to evolve. One of the great strengths of a Common
> Lisp system is that you can patch it while it is running, and so one of
> the great features of Common Lisp applications that they can run
> forever (bounded only by system reboot and shutdown)
>
I don't argee. Computers programs are intendent to be using but not
debugging by other people. So if your programm will be able to run only in
CL enviroment with all its really nice development features which are not
required by program's semantics, then you just shift off a cost of these
features on an user. Sometimes such features have to be in program,
sometimes have not. I like freedom to choose use or not such features in
a distributed program.
>
> ...
>
> On the other hand, I would have preferred a Common Lisp system that built
> binaries and used the shared library ("DLL" to Microsoft victims) support
> in the operating system instead of re-implementing all this stuff on
> their own in ways that means you cannot use them with other languages,
> while they still have to be able to use shared libraries to interface with
> foreign function code, so something is clearly wanting in that design.
>
I am definitly on your side here.
> ///
Aleksandr Skobelev
>> But I'd prefer if size was not too much big.
>
> _Why_? What is it to you? Why does disk space matter to _anyone_ these
> days? My Debian GNU/Linux development machine has 120G of disk space
> right now, and I cannot even _imagine_ life as a programmer without huge
> excesses of disk resources, anymore. With the kind of cheap disks we get
> these days, that amount of disk space is within reach for anyone with no
> more than your take-home pay for a couple week's worth of work.
Where have I wrote about disk space? I've only wrote about size of
program. This is different things, I think. Here also can be just human
factor. By the way, I don't understand why my wish of Lisp system can
generate small applications is so horrible?
>
>> If I take participation in a project and I'd like to move my part
>> silently from C++ into Lisp then any dramatically worsening in any of
>> characteristics is not allowed.
>
> Pardon me, but this is a really stupid position to hold. You argue as if
> you were dirt poor with absolutely no hope of improving your situation
> because you are in such a dire situation that you cannot spend a nickel
> to get out of it. If this is indeed true, Common Lisp cannot help you.
> I can tell you right away that you will not get out of your dump with the
> aid of Common Lisp. Sorry about that.
You have missed my point here. I argue that some qualities of CL
realizations won't allowed me to start using it on my work very soon.
But I never said that it was an insuperable obstacle.
>
>> Despite of any advantages of using Lisp. Size is also very important
>> because of distribution of programs over Internet. Not all people have a
>> very good Internet connection. For example, my home uplink is only 28 kb
>> mostly. So I always think twice before downloading something that ~500
>> kB.
>
> The way to do this is to download the Common Lisp environment _once_,
> then download small object files, not full executables or images. E.g.,
> CMUCL can dump _huge_ images, and most other Common Lisp environments
> also dump huge images files (however, they do compress really well :),
> but the source code or the compiled files are fairly small. People tend
> to have to install runtime libraries for _all_ their other environments,
> too, so I fail to see why the same standard cannot be applied to Common
> Lisp. It is as if some people simply have made up their mind that they
> cannot use Common Lisp unless it is virtually identical to their some
> particular other tools. For instance, do you see people whine that Perl
> programs are so big? No, not at all, but why? Perl is already installed
> and the programs are very small, but Perl itself is *large*, yet nobody
> complains.
>
I would prefer that CL environment has been preinstalled on any platform. :)
> I think there are many assumptions underlying your line of questioning
> that need to be enunciated and re-opened for you to get closer to useful
> answers.
Posting the my first message, which started this thread I only wished to
get some information about size of binaries generated commercial Lisp
realisations. I've only got information about LWW. In all other messages
I've just explained why I had asked about size and why I had thought that
is was better if one was smaller. :)
I want to say that I tried to explain my position as well as my level of
English is allowed me. Unfortunately it doesn't allow me very much. :)
Sorry if it misleads or annoys somebody.
Aleksandr
Aleksandr Skobelev
Aleksandr
Jochen Schmidt
> Jochen Schmidt <j...@dataheaven.de> writes:
>
>> Christophe Rhodes wrote:
>>
>> > The
>> > other thing that I maintain needs to be done is a move away from CL's
>> > pathnames, both physical and logical towards something entirely new (I
>> > think URLs), but this may involve some serious tinkering with
>> > functions in the CL package (should
>> > (open #u"file://localhost/tmp/foo.lisp")
>> > work? Should
>> > (open #u"http://www.bar.com/foo.lisp")?
>> > Should there be provision for user-defined schemes?) These slightly
>> > vague musings might turn into a real proposal eventually; in the
>> > meantime, there's
>> > <URL:http://www-jcsu.jesus.cam.ac.uk/~csr21/uri.lisp> (patches
>> > welcome...)
>>
>> I don't know if you have looked at my CommonURI package that is an
>> implementation of Franz' URI API. As we already talked on the topic of
>> URIs I thought you would contact me to merge the efforts (As I have
>> already done some of the work involved...)
>
> Oh, yes, it's on my list of things to do, I promise. It's not yet
> entirely clear to me what I want, which is why I'm not at the stage of
> merging efforts.
An interesting thing to ask here in c.l.l is - besides of if there is any
interest in creating integrated URI support for CL - if it is preferable to
change standard-functions like LOAD, OPEN, COMPILE-FILE or if it is better
to let the user shadow the originals on demand or as the third option to
create a completely disjunct set of functions (e. g. LOAD-URI, OPEN-URI,
COMPILE-URI...). I personally do not think it is a good idea to propose a
change of the standard-functions. I would prefer the shadow on demand or
"another set of functions" approach.
Another problem is what reader-macro name to choose (if one) for literal
URIs #u is used by CL-HTTP and probably Franz' URIs too AFAIK.
Looking at your file I have one minor style-note. Why have you chosen to
implement e. g. the "scheme" as an explicit generic-function? Why not
defining "scheme" as slot of URI and creating a URI-SCHEME accessor (which
would automatically involve generic-method dispatch...
I would prefer a somewhat hierarchical name like URI-SCHEME over only
SCHEME too.
I fear this get's a bit away from the threads topic - probably we should
begin a new thread with that topic?
ciao,
Jochen
>
> Christophe
Erik Naggum
> You are kidding. Need I explain you meaning of "standalone executable"
> term in my messages?
Yes. Because if you compare a hello, world program that uses massively
optimized operating system facilities and shared libraries and all sorts
of other things that work very well to reduce the size of "executables",
you are looking at the wrong end of the stick. Look at what that small
executable is attached to: A huge set of libraries and support functions
from the operating system.
I mean, I could write a hello, world program in MACRO-10 for TOPS-10 that
consisted of three machine instructions and the string literal. That was
done at a time when small _actual_ executables were worth real money, but
these days, small executables are not small in memory imprint, any longer.
Therefore, the _concept_ "standalone executable" is no longer valid.
> Computers programs are intendent to be using but not debugging by other
> people.
This is so broad as to be utterly false by the very nature of the claim.
Please limit your statements to the assumptions that support them, then
always evaluate the assumptions for validity for broader claims.
Otherwise, you will always be stuck in using your observations from a
very limited context in a much broader context, and that never leads to
anything good.
> So if your programm will be able to run only in CL enviroment with all
> its really nice development features which are not required by program's
> semantics, then you just shift off a cost of these features on an user.
How did you arrive at this strange conclusion?
> Sometimes such features have to be in program, sometimes have not. I
> like freedom to choose use or not such features in a distributed program.
Sometimes, we do not get the freedoms we want, but instead may other ones
we did not know we wanted because we never asked for them. You are way
too quick for my taste to dismiss what you do not know, yet. I find this
very annoying, in fact, and suspect that you will not want to invest the
time it takes to learn a new language. I suspect you will only learn C++
with a new syntax if you learn Common Lisp in your present state of mind.
_Please_ look at what you get, not at what you want. Somehow, you _did_
do that when you came to C++ and found "small executable" a valid concern.
You have to be equall open-minded with _every_ language you approach, not
just the first.
///
Christopher Stacy
Aleksandr> I've just explained why I had asked about size and why I had thought
Aleksandr> that is was better if one was smaller. :)
I might have missed some of the messages, so I hope I am not asking
you to repeat yourself. But I have two questions for you:
1. "Smaller" than *what*?
2. Why would that be better?
Kaz Kylheku
>You are kidding. Need I explain you meaning of "standalone executable"
>term in my messages?
Even the boot sector on your PC's hard disk is not a standalone executable,
because it refers to routines in the BIOS.
A ``hello, world'' program is typically linked to a hefty library,
which uses the services of a hefty kernel, so it hardly stands alone.
Thomas F. Burdick
Ah, but CGIs are a different beast. If you're using CL to write CGI
scripts, you presumably have more than one little hello world type
script. You probably have a whole bunch. So you install the CL
system just as you would perl, and then the cost to deliver each CGI
script is the cost of a .lisp or .fasl file.
Thomas F. Burdick
> Erik Naggum <er...@naggum.net> wrote:
>
> > So use C++, then. I completely fail to see the problem. If you want to
> > use a different language, you actually have to buy the whole package
> > deal, not just the bits and pieces you like and then keep some other
> > language -- if you want that, build yourself a CL++ environment.
> >
>
> So do I. There is no any problem. But I don't feel that I have to buy
> something to use different language. At least at the beginning stage.
He was using "buy" in a metaphorical sense. If you want to use Common
Lisp, you should try to do things the CL way and judge things using a
CL value system. Then, once you understand why things are done the
way they are, *then* you can try to improve on it. There are good
reasons that CL does the things it does; if you understand those
reasons, you may be able to improve it; if you don't understand why
things are done as they are, you will be doomed to making a mess. And
you'll end up fighting against the CL system and trying to recreate C++.
> I don't argee. Computers programs are intendent to be using but not
> debugging by other people. So if your programm will be able to run only in
> CL enviroment with all its really nice development features which are not
> required by program's semantics, then you just shift off a cost of these
> features on an user. Sometimes such features have to be in program,
> sometimes have not. I like freedom to choose use or not such features in
> a distributed program.
You can get rid of some things (IDE, etc.) quite easily. I completely
disagree with the philosophy of shipping applications with no
debugging ability. When something goes wrong, it sucks. Unless I
*absolutely* need the speed and space savings, I leave a minimal
debugging environment in all my C++ programs. CL gets that by
default.
Marc Battyani
"Thomas F. Burdick" <t...@apocalypse.OCF.Berkeley.EDU> wrote
>
> Ah, but CGIs are a different beast. If you're using CL to write CGI
> scripts, you presumably have more than one little hello world type
> script. You probably have a whole bunch. So you install the CL
> system just as you would perl, and then the cost to deliver each CGI
> script is the cost of a .lisp or .fasl file.
I know somebody that makes CGI like scripts in Lisp with mod_lisp + Apache.
Basically he processes URI like http://www.server.com/lisp/page1.lisp by
loading the page.lisp file (or .fasl) and calling a function in it to
process the request. That way the CGI scripts are very small and the
starting time is very short as the Lisp process is already loaded in memory
and running.
Marc
Aleksandr Skobelev
In article <32096689...@naggum.net> you wrote:
> * Aleksandr Skobelev <22...@mail.ru>
>> You are kidding. Need I explain you meaning of "standalone executable"
>> term in my messages?
>
> Yes. Because if you compare a hello, world program that uses massively
> optimized operating system facilities and shared libraries and all sorts
> of other things that work very well to reduce the size of "executables",
> you are looking at the wrong end of the stick. Look at what that small
> executable is attached to: A huge set of libraries and support functions
> from the operating system.
Yes. I've just wanted to get an estimation for minimal size of program that
had been generated by commercail CL realization. I think I've got what
I wanted.
>
> I mean, I could write a hello, world program in MACRO-10 for TOPS-10 that
> consisted of three machine instructions and the string literal. That was
> done at a time when small _actual_ executables were worth real money, but
> these days, small executables are not small in memory imprint, any longer.
>
> Therefore, the _concept_ "standalone executable" is no longer valid.
>
An any concept is not valid in absolute sense. It is only valid in
context of current discussion after all sides who take part in that
discussion came to agree about the meaning of that concept and until the
end of discussion.
And if your 'yes' concerns to need of explaining term "standalone
executable" in the context of my messages, here it is.
I have used concept "standalone executable" as a well known in this
newsgroup for signing an file which contains program in instructions of
CPU, has a format of executable file for target OS, and can be running as
a process by this OS. That concept has also included a requirement of
independency (i.e. process can be running without) of any Lisp system or
special Lisp's libraries (i. e. libraries that contains code providing
functionality of Lisp system, because it is implied that all such code had
been already statically linked in executable body). Such executable could,
of course, be dynamically linked with libraries which are the part of OS
(this libraies are always exist and it is just stupid to pay attention to
them) and dynamically or statically linked with libraries which provides
semantic program's functionality.
>> Computers programs are intendent to be using but not debugging by other
>> people.
>
> This is so broad as to be utterly false by the very nature of the claim.
> Please limit your statements to the assumptions that support them, then
> always evaluate the assumptions for validity for broader claims.
> Otherwise, you will always be stuck in using your observations from a
> very limited context in a much broader context, and that never leads to
> anything good.
>
OK. :)
<IN-MY-OPINION>
Computer's programs are intendent to be used but not debugged by users.
(If it wasn't so then probaly they were called 'debuggers') :) For they
use programs for solving their own problems but not for solving problems
of programmers who have developed these programs. Debugging of broken
programs is a task for programmers but not for users. Programmers only can
ask users to help them but they can not force them to do it.
</IN-MY-OPINION>
>> So if your programm will be able to run only in CL enviroment with all
>> its really nice development features which are not required by program's
>> semantics, then you just shift off a cost of these features on an user.
>
> How did you arrive at this strange conclusion?
OK. May be I have told that too sharp or incorrect. I've meant to say
that user should paid for things he/she not needed.
<IN-MY-OPINION>
There are situations when the user has to pay for presence of such
features. This is an indirect payment. Because such features always requires
additional resources which have to be paid. Such payment can be more or less.
It is obviously chip when we talking about place on hard drives. But if
program is intendent to be used on computers without HDD but with flush
memory? Downloading files over Internet is also costs somewhat, and it is
not always chip.
</IN-MY-OPINION>
>
>> Sometimes such features have to be in program, sometimes have not. I
>> like freedom to choose use or not such features in a distributed program.
>
> Sometimes, we do not get the freedoms we want, but instead may other ones
> we did not know we wanted because we never asked for them.
No any objections.
But it is sounds like that there is something that can save the my life
and I know nothing about it. Well, if you tell me about it, I might be
much obliged to you the rest of all my life. :)
> You are way
> too quick for my taste to dismiss what you do not know, yet. I find this
> very annoying, in fact, and suspect that you will not want to invest the
> time it takes to learn a new language. I suspect you will only learn C++
> with a new syntax if you learn Common Lisp in your present state of mind.
Excuse me, but, I think, you just give your dreams out to be my decisions.
I didn't dismiss anything, especially, for your taste. :)
As far as I remember in this thread I only expressed my opinion, that it
would be good for me and, probably, for Lisp, if some feature existed. And
I've tried to explain my point, which, I agreed, might have been wrong.
But I never wrote that CL have to be dropped because of absence of that
or any other feature.
You, of course, have an absolute freedom to suspect anything you want. And
your suspects can, of course, be very reasonable and come true. But could
I, with my deep respect to you, ask you do not claim any of such
suspections about me, please. Just because I wouldn't like to be an
subject for discussion anywhere.
> _Please_ look at what you get, not at what you want. Somehow, you _did_
> do that when you came to C++ and found "small executable" a valid concern.
> You have to be equall open-minded with _every_ language you approach, not
> just the first.
>
I've just tried to understand what I get and how it is correlated with
what I want. Where I can use it and where I can't.
Aleksandr
Aleksandr Skobelev
> Lisp, you should try to do things the CL way and judge things using a
> CL value system. Then, once you understand why things are done the
> way they are, *then* you can try to improve on it. There are good
> reasons that CL does the things it does; if you understand those
> reasons, you may be able to improve it; if you don't understand why
This is what I trying to do.
> things are done as they are, you will be doomed to making a mess. And
> you'll end up fighting against the CL system and trying to recreate C++.
>
Hmm... Or you don't read this thread from the begining but only Erik's
message, or I have been explaning myself very bad. :(
There were not any fighting against the CL. If not, of course, you
consider that having own opinion about features which one'd like to have
in CL is a fightning against the CL. :)
Janis Dzerins
> Thomas F. Burdick <t...@apocalypse.ocf.berkeley.edu> wrote:
> >
> > He was using "buy" in a metaphorical sense. If you want to use Common
> > Lisp, you should try to do things the CL way and judge things using a
> > CL value system. Then, once you understand why things are done the
> > way they are, *then* you can try to improve on it. There are good
> > reasons that CL does the things it does; if you understand those
> > reasons, you may be able to improve it; if you don't understand why
>
> This is what I trying to do.
But it looks like your value system is heavily influenced by C++. At
this point the choice is yours: either you drop your preconceptions
and learn CL in its own terms or you try to cast CL into your C++ way
of thinking and don't learn CL (but a CL++ as it has been called
recently).
> There were not any fighting against the CL. If not, of course, you
> consider that having own opinion about features which one'd like to
> have in CL is a fightning against the CL. :)
You may of course think that it's just your opinion. But you have been
brainwashed by C++ and might think that C++ is the one and only right
way to do things. CL is a completely different world. C++ value system
just doesn't make sense here.
Do you think my being faster, stronger has anything to do with my
muscles in this place? Do you believe that's air you are breathing
now? If you can free your mind, the body will follow.
-- Morpheus, The Matrix
I just want to help you understand where the problem is.
--
Janis Dzerins
If million people say a stupid thing it's still a stupid thing.
Coby Beck
>
>
> Posting the my first message, which started this thread I only wished to
> get some information about size of binaries generated commercial Lisp
> realisations. I've only got information about LWW. In all other messages
> I've just explained why I had asked about size and why I had thought that
> is was better if one was smaller. :)
>
> I want to say that I tried to explain my position as well as my level of
> English is allowed me. Unfortunately it doesn't allow me very much. :)
> Sorry if it misleads or annoys somebody.
>
Don't worry, I think you explained your position just fine. If people reacted
a bit more, um.. emphatically.. than you might have expected it is just because
this is a sore spot in the lisp community. Don't take it personally. This
"problem" about lisp, that is in fact no problem at all, is frequently used as
one of a few common but irrational excuses to dismiss the entire language out
of hand.
Coby Beck
> >> like freedom to choose use or not such features in a distributed program.
> >
> > Sometimes, we do not get the freedoms we want, but instead may other ones
> > we did not know we wanted because we never asked for them.
>
> No any objections.
>
> But it is sounds like that there is something that can save the my life
> and I know nothing about it. Well, if you tell me about it, I might be
> much obliged to you the rest of all my life. :)
>
(Assuming a good natured joke in the line "something that can save my life" -
ie I don't think you really believe a small executable is so important that you
won't sacrifice it except to save your life)
No, you can not get a very small "Hello World" program in Common Lisp without a
lot of the Lisp system included. This is a mark on the column of bad points.
But what do you get in return?
* A *much* faster development cycle
* A program that can be modified/enhanced/debugged while it is still running
* The ability to use symbols as data
* A macro system so powerful you can define your own programming language on
top of CL
* An object oriented development platform that allows you to redefine your
classes at runtime, existing objects and all
* A language that can easily produce, compile and execute it's own source code,
again at runtime
This is just a start of a list of Common Lisp's good points, perhaps others
will chime in with others. But I think it is quite enough to outweigh any
disadvantage of a small executable for all but a very few and very specific
situations.
Tim Bradshaw
> <IN-MY-OPINION>
I think the preferred syntax is (with-opinion (:mine t) ...)
> Computer's programs are intendent to be used but not debugged by users.
> (If it wasn't so then probaly they were called 'debuggers') :) For they
> use programs for solving their own problems but not for solving problems
> of programmers who have developed these programs. Debugging of broken
> programs is a task for programmers but not for users. Programmers only can
> ask users to help them but they can not force them to do it.
Well, it's not just debugging, is it. Imagine a long-running
mission-critical program, in which a bug is found. Now the
traditional approach to this is stop the application, upgrade it,
convert all the data to some new format, and restart. Maybe this
takes you a few hours.
Now imagine a system which lets you load into it, while it's running,
a patch file. The patch file contains the bug fix, but, even better,
it also contains mechanisms that cause all the program's data to be
converted on-the-fly (and almost certainly on-demand) tot he new
format. There is no downtime. I think it's clear that this sort of
thing would be nice to have - even C++ people are groping towards it
though, last I read, they hadn't worked out the on-the-fly conversion.
stuff yet.
CL systems provide this stuff as near-standard functionality (there
are caveats but they're not a problem in practice). And the way
they do this is by keeping various meta-information about stuff, so
that there is enough information in the running system to do this
magic. I'm not an implementor, but I bet you that a lot of this data
is *the same* as the kind of thing you need for debugging.
Does this mean that minimal CL systems are slightly bigger than
minimal C ones? Yes. Does it mean they aren't suitable for embedded
controllers in washing machines? Probably it does (though they seem
to work OK in embedded controllers in spacecraft). But not all
systems are minimal, and having this kind of stuff can save you a lot
of money in systems that aren't.
--tim
Valeriy E. Ushakov
> <IN-MY-OPINION>
> Computer's programs are intendent to be used but not debugged by users.
> (If it wasn't so then probaly they were called 'debuggers') :) For they
> use programs for solving their own problems but not for solving problems
> of programmers who have developed these programs. Debugging of broken
> programs is a task for programmers but not for users. Programmers only can
> ask users to help them but they can not force them to do it.
Have you ever tried to deal with bug reports for "standalone" programs
in real life? (this is not a rethorical question).
User: "Gee, this program crashes sometimes. Here's a 40M core
dump. No, sorry, my executable is stripped".
Even OS kernels have built-in debugging facilities, either a fully
blown interactive debugger or at least enough of it to print a
symbolic stack trace on panic. And (with my kernel hacker hat on) to
say that it's very useful does not even start to describe just how
much I appreciate it's there in the kernel.
And if you want to go even more down to the iron, consider that
e.g. OpenFirmware comes with debugger as well. Re boot loaders ;)
- this debugger helped me a great deal recently to debug a boot loader
and kernel bootstrapping code (before kernel debugger is initialized).
> But if program is intendent to be used on computers without HDD but
> with flush memory?
Yes, OpenFirmware resides in flash memory ;).
This low level stuff has nothing to do with CL directly, but I just
want to show you that even at the bare iron level of "standalone-ness"
people actually deploy code in production (even in the flash!) with
debugging facilities built-in.
> As far as I remember in this thread I only expressed my opinion,
> that it would be good for me and, probably, for Lisp, if some
> feature existed. And I've tried to explain my point, which, I
> agreed, might have been wrong.
And to quote Erik's reply:
> > Please limit your statements to the assumptions that support
> > them, then always evaluate the assumptions for validity for
> > broader claims.
IOW: why do you think it would be good for you (and for Lisp)?
Do the analysis of the problem you have at hands, calculate the costs,
consider trade-offs and make an informed decision.
And as far as "don't pay for things you don't use" is concerned...
IMO, C++, the language as whole paid a *huge* price to let its users
think they do not pay for things they don't use. So when calculating
your trade-offs you should take that price into account too.
SY, Uwe
--
u...@ptc.spbu.ru | Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/ | Ist zu Grunde gehen
Wade Humeniuk
> Thank you for reply.
> As far as I understand they are statically linked binaries in contrast to
> Basic's dynamically linked (to VB dlls) ones?
I would assume that you are correct. There is no CAPI DLL that one can link
to, which I assume VB has DLL libraries for equivalent functionality. The
comparison I am making is to other running log programs, written in VB, that
have the approximate functionality that my program has. They are large with
a 8 to 12MB self-installing exe.
I used to be concerned with the size of executables. It hardly crosses my
mind anymore. There seems to be a minimum size that any delivered LWW exe
can be (~2MB). This includes code essential to basic CL functionality (no
compiler, loader, CAPI, multi-processing). Of course this could be greatly
reduced but it would take vendor work, OR, some bright person out there
could write their own compiler to generate very small exes for small
programs like that. Totally doable (as evidenced by the post about
stalin-0.8). The compiler would have to analyze the code, decide what
functionality is needed, decide if garbage collection is needed, and emit an
executable.
Though there is a minimum size to a LWW executable, I can say that for
additional functionality that is added (for a more complex app) the
executable size does not increase any more quickly compared to other
languages.
Wade
Tim Bradshaw
> This low level stuff has nothing to do with CL directly, but I just
> want to show you that even at the bare iron level of "standalone-ness"
> people actually deploy code in production (even in the flash!) with
> debugging facilities built-in.
It's always misleading to give examples from spacecraft because
they're so weird, but I remember a story about some mars spacecraft
(quite recent I think, and one of the ones that didn't crash), which
suffered from system crashes due to <something>. The thing ran some
embedded OS - perhaps OS9? - and the people, being sensible, had left
all the debugging tools there. The description I read was a bit vague
but it sounded suspiciously as if they essentially logged in to the
spacecraft and edited parameters interactively to fix the problem. I
thought this was really cool. What was sad was that they (the NASA
people) got attacked for launching the thing with bugs, when in fact
they'd done everything they needed to to make sure they could fix the
bugs on the fly, while not missing the launch window due to testing).
Anyone whose run Unix machines has also, as you say, been very
thankful for the interactive debugger that most of them have under the
kernel: if only to be able to do something which causes the system to
sync the disks before rebooting this is worth it (of course systems
don't typically need to sync disks nowadays, but the point is still
good I think).
--tim
Lieven Marchand
> Y'know, I've taken this line for years, but reading this made me think of
> CGIs. It seems to me that loads of actually deployed CGIs aren't *that*
> much more complex than the hello, world program. For some reason this
> never struck me as plausible when people brought up "trivial" shell utils.
A lot of CGIs have been written in Perl. When people test this, CLISP
starts up faster than Perl and is for a lot of things faster. So,
there's no reason CLISP couldn't be used for CGIs.
--
Lieven Marchand <m...@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words
Duane Rettig
> In article <32096689...@naggum.net> you wrote:
> > * Aleksandr Skobelev <22...@mail.ru>
> >> You are kidding. Need I explain you meaning of "standalone executable"
> >> term in my messages?
> >
> > Yes. Because if you compare a hello, world program that uses massively
> > optimized operating system facilities and shared libraries and all sorts
> > of other things that work very well to reduce the size of "executables",
> > you are looking at the wrong end of the stick. Look at what that small
> > executable is attached to: A huge set of libraries and support functions
> > from the operating system.
>
> Yes. I've just wanted to get an estimation for minimal size of program that
> had been generated by commercail CL realization.
> I think I've got what
> I wanted.
I don't think that's true, because not all of us have weighed in yet.
You may have gotten at least one answer, but before we talk about
how low we can go with Common Lisp, I want to know if you understand
where your own bar is. I don't think you do yet. If you do, you
certainly haven't communicated it to us to my satisfaction.
> > I mean, I could write a hello, world program in MACRO-10 for TOPS-10 that
> > consisted of three machine instructions and the string literal. That was
> > done at a time when small _actual_ executables were worth real money, but
> > these days, small executables are not small in memory imprint, any longer.
> >
> > Therefore, the _concept_ "standalone executable" is no longer valid.
> >
>
> An any concept is not valid in absolute sense. It is only valid in
> context of current discussion after all sides who take part in that
> discussion came to agree about the meaning of that concept and until the
> end of discussion.
>
> And if your 'yes' concerns to need of explaining term "standalone
> executable" in the context of my messages, here it is.
>
> I have used concept "standalone executable" as a well known in this
> newsgroup for signing an file which contains program in instructions of
> CPU, has a format of executable file for target OS, and can be running as
> a process by this OS. That concept has also included a requirement of
> independency (i.e. process can be running without) of any Lisp system or
> special Lisp's libraries (i. e. libraries that contains code providing
> functionality of Lisp system, because it is implied that all such code had
> been already statically linked in executable body). Such executable could,
> of course, be dynamically linked with libraries which are the part of OS
> (this libraies are always exist and it is just stupid to pay attention to
> them) and dynamically or statically linked with libraries which provides
> semantic program's functionality.
Thank you for finally giving us this definition. Incidentally, by this
definition most C programs are not standalone. They do _not_ link in
their library (libc.so) statically, and thus cannot run without library
support. It is possible on some systems to link a program completely
statically (e.g. Solaris has a -Bstatic option), but it gets harder
and harder all the time. In fact, many third-party vendors provide
only .so libraries, and not .a files for static linking.
[ ... ]
I have focussed in on this question, and I am staying away from the
debugging/debggability question, because I think my specific size
question will remain unanswered if it is not pursued specifically.
So here is some background followed by my real question to you:
In this entire thread you have not told us yet what you are trying
to do, and what your goals are in limiting the size of CL images.
In my experience, there are only a couple of reasons why people want
to limit a CL size:
- They have limited transfer capability. Usually the internet or
the size of floppy-disks limits what can be transferred of a program.
However, a lisp "program" is really a series of functions, which can
be contained in a source or .fasl file. Others have mentioned this
before. I can write a trivial lisp program and give its fasl file a
magic-number that allows the program to run the lisp that is on the
system and to load in its own fasl file and run it. Such a program
can be only a few hundred bytes. We lispers seldom talk about such
programs because it is too trivial, and we tend to think of it as
cheating (i.e. it does not really show how much actual memory the
program is using when it is running). And if the media you want to
use is floppy disk, then I recommend that you rethink your distribution
strategy and buy a cheap CD-rom burner; some systems don't even come
with floppy drives anymore, though all come with CD-Rom drives.
You did mention wanting to be able to have lisps loaded on machines
so that such small programs can be transferred via internet.
But you do not state why; are you planning to sell products to
customers who will not want to install a lisp system on their
machines?
- They have limited memory space. Nowadays, the only things left
that have less than a couple of megabytes of memory in them are
the older embedded systems. Soon your refrigerator will have
more memory than your vintage 1995 PC. My wife and I just went
out looking for refrigerators, and were amazed at the sophistication
of the electronics; I was tempted to look for a USB port, but
knew it was useless because these refrigerators were made after
Webvan went out of business :-) But the age of embedded systems is
here, and the size of the embedded systems nowadays does not preclude
CL from being ubiquitous, even in that arena.
So now for my question: Given the above background, can you explain
to me a little of what you are trying to _do_, and help me to
understand the reason or reasons why you want your CL system to
be a specific size?
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
Raymond Toy
Tim> Now imagine a system which lets you load into it, while it's running,
Tim> a patch file. The patch file contains the bug fix, but, even better,
Tim> it also contains mechanisms that cause all the program's data to be
Tim> converted on-the-fly (and almost certainly on-demand) tot he new
Tim> format. There is no downtime. I think it's clear that this sort of
Tim> thing would be nice to have - even C++ people are groping towards it
Tim> though, last I read, they hadn't worked out the on-the-fly conversion.
Tim> stuff yet.
Can you describe how this works in a bit more detail? Is this a
multithreaded Lisp so you can do patch in one thread without stopping the
processing in the other threads? How does changing a function, say,
interact with other running threads? (I don't use a threaded Lisp.)
Thanks,
Ray
Tim Bradshaw
> Can you describe how this works in a bit more detail? Is this a
> multithreaded Lisp so you can do patch in one thread without stopping the
> processing in the other threads? How does changing a function, say,
> interact with other running threads? (I don't use a threaded Lisp.)
I think that it would really be interesting only for some
multithreaded application, although I can imagine something
event-driven as well (one source of events would be something that
said `you have a patch, waiting, please load it'). For such a
single-threaded application you wouldn't have the issue of other
threads, but you would have the issue of whether redefining a function
actually means that callers pick up the new version, which is I think
not guaranteed by the standard (unless you declare everything
NOTINLINE) but in practice it's easy enough to know what the
implementation does that it is not a problem.
For a multithreaded application you'd have to do something that put
the other threads into a good state, and this might involve
essentially momentarily stopping the application while the patch
loaded, but the interruption would be brief - and you can likely
arrange things so that volatile state is not lost while this happens.
On top of this you have the same redefinition caveats as above.
This is really what I meant by `near-standard functionality' - there
are caveats but it's fairly clear that it's possible to do this kind
of thing without extreme pain.
In the application I worked on until recently we were generally
constrained by politics not to do this kind of thing (patches couldn't
go into the live system without huge testing) but we did occasionally
in desperate circumstances, and there was a mechanism of stopping the
system to load the patch. This was a lot faster than the 20 minutes
or so it took to come up from cold.
--tim
Bijan Parsia
> Bijan Parsia <bpa...@email.unc.edu> writes:
>
> > On Sun, 16 Sep 2001, Erik Naggum wrote:
> > [snip]
> > > in Common Lisp. This means (their) Common Lisp is never used to build
> > > the kinds of toys that programmers need to build trust in their tools.
> > > Being able to dump a toy executable like you ask for is therefore highly
> > > desirable, but it is a completely useless exercise for anything other
> > > than such building of trust in your tools.
[snip]
> > Y'know, I've taken this line for years, but reading this made me think of
> > CGIs. It seems to me that loads of actually deployed CGIs aren't *that*
> > much more complex than the hello, world program. For some reason this
> > never struck me as plausible when people brought up "trivial" shell utils.
[snip]
> Ah, but CGIs are a different beast.
Not "in themselves". I.e., "building" many CGIs is not fundementally more
complex than building hello, world.
> If you're using CL to write CGI
> scripts, you presumably have more than one little hello world type
> script. You probably have a whole bunch.
Sure.
> So you install the CL
> system just as you would perl, and then the cost to deliver each CGI
> script is the cost of a .lisp or .fasl file.
Absolutely, but I wasn't addressing the distributabilty issue, per
se. That is, I was *only* thinking about the "toy" nature of hello,
world. See my subsequent post for a similar view to what you express
above.
A clean web archive of CL CGIs might also be a "friendly to the
lost" thing. They would be simple programs, about familiar things, and are
immediateately useable in a public way.
Cheers,
Bijan Parsia.
Bijan Parsia
> Bijan Parsia <bpa...@email.unc.edu> writes:
>
> > Y'know, I've taken this line for years, but reading this made me think of
> > CGIs. It seems to me that loads of actually deployed CGIs aren't *that*
> > much more complex than the hello, world program. For some reason this
> > never struck me as plausible when people brought up "trivial" shell utils.
>
> A lot of CGIs have been written in Perl. When people test this, CLISP
> starts up faster than Perl and is for a lot of things faster. So,
> there's no reason CLISP couldn't be used for CGIs.
Never said otherwise. Indeed, that's one of CLISP's strong niches
IMHO. Remember the context of the discussion: do people deploy "hello,
world" like toys? Yes, they do. Of course, you don't need to assemble a
super striped image to deploy 'em, you can follow the very standard
Perl/Python/etc. practice of forcing the user to install the enivroment
and then download the script files.
My comments were *very* targeted :) But it's good to re-bring up the
actually use of CL for this sort of thing.
Cheers,
Bijan Parsia.
Coby Beck
"Raymond Toy" <t...@rtp.ericsson.se> wrote in message
news:4n8zfds...@rtp.ericsson.se...
I did this kind of on-the-fly patching with a system I worked on a couple of
jobs ago. This application was a server executing GUI requests one at a time.
There was an administrative interface that could put special requests on the
cue that was just any lisp code you cared to send (like new method
definitions). The system start-up was ~3 hours and was used by airline crew
controllers so that much down time was not an attractive option...
Erik Naggum
> An any concept is not valid in absolute sense. It is only valid in
> context of current discussion after all sides who take part in that
> discussion came to agree about the meaning of that concept and until the
> end of discussion.
That is basically what I said. Please get rid of the silly arguments
assuming anyone here are stupid enough here to argue about "valid in an
absolute sense". Nobody has even given you cause to believe they think
in such retarded terms. We all _know_ what context means and does to the
validity of concepts and ideas. Please assume that people here are not
lamebrained, OK?
Let me repeat myself:
Therefore, the _concept_ "standalone executable" is no longer valid.
_You_ are, in other words, trying to abuse the context of the validity of
the concept "standalone executable" beyond what it once was able to
withstand. Standandalone executables no longer exist, except those in
embedded systems. Everything else depends on a lot of supporting
software around them that you simply cannot ignore. (I was wrong about
boot loaders -- they depend on the BIOS, which are not standalone,
either.) It is a very good idea to rid yourself of the whole notion of
"standalone" in dealing with executables. It marks you as completely
outdated in the modern computer world.
> Computer's programs are intendent to be used but not debugged by users.
That depends on what you consider "debug". I consider the famous DOS
query "Abort, Retry, Ignore" to be a debugger interface, for instance.
_Really_ good programs actually allow users to decide the fate of the
system in face of unhandled exceptional situations, not just _die_, like
crappy software does. It is highly unlikely that really complex software
will not encounter unhandled situtations. If they turn into disasters,
you have bugs. If they turn into a query to an operator, they are not
bugs. The former requires static-style debugging by an off-site crew.
The latter allows an on-site operator to handle the situation nicely and
get the system back up and running. This is what we have system admins
for these days. I thus consider your views of what computer programs are
intended to do alarmingly outdated. You argue as if you work on an
embedded system in isolation from everything else. If you do, please say
so in explicit terms, do not drag in all the old, invalid concepts from
that mode of operation for computers -- it is _truly_ outdated.
> Debugging of broken programs is a task for programmers but not for users.
Your view of what debugging consists of reveals a lack of willingness to
listen to what people are telling you. Please drop this arrogance and
start to listen. That _is_ why you came to this newsgroup, is it not?
> As far as I remember in this thread I only expressed my opinion, that it
> would be good for me and, probably, for Lisp, if some feature existed.
You have asked us to help you with more information. Your "opinions" are
the vehicles on which we try to deliver the answers your questions,
because they constitute the context in which communication with you can
take place. Therefore, they are not _just_ your opinions, but the whole
framework of your mind when you come here to receive information. If it
is clear that you are not able or willing to listen to information that
says that your "opinions" are misguided (i.e, that your context needs to
be expanded), you will not learn anything and only frustrate everybody.
This is not mere suspicion. All newsgroups have "newbies" who come and
ask questions in a context they are familiar with and refuse to listen to
anything that does not work in their original context. It is one of the
most annoying features of USENET. I actually expect people to _listen_
before they take the time to express any "opinions". A good USENET rule
is to read a newsgroup for a couple weeks before you post anything. This
may be too hard to do in some cases, but it is definitely not bad advice.
///
Erik Naggum
> Where have I wrote about disk space?
Please do not be coy with me. The way you have defined standalone
executable is definitely a disk-space argument.
> By the way, I don't understand why my wish of Lisp system can generate
> small applications is so horrible?
Look, I have already told you it is not, in fact, that it is a good thing
for certain limited purposes. Please pay attention to what I say if you
wish to talk with me. I am _trying_ to be patient with you, but you are
turning out to be very, very annoying and persistent in repeating things
that have been refuted by several people. Why are you doing this? My
"USENET troll" sensor is peaking.
> You have missed my point here. I argue that some qualities of CL
> realizations won't allowed me to start using it on my work very soon.
My argument is that those are not some qualities of CL, but some of
_your_ qualities in interaction with some of the qualities of CL. You
seem very persistent in ignoring your own background and argue as if you
have some very fixed ideas about what is right and wrong. One of the
best things about Common Lisp is that we learn the meaning and importance
of tradeoffs in a much deeper and more profound way than any other
language. Common Lisp people have to pay for their features. ("Pay" and
"buy" do not necessarily refer to money, but to any resource.) Some
other languages give you no choice, so it works just like taxation.
> I would prefer that CL environment has been preinstalled on any platform. :)
Well, this silly response may actually be the core of your problems. You
have to deal with reality as it exists. Asking people to deal with you
in terms of your dreams is not at all inspiring to anybody but yourself.
///
Tim Moore
> * Valeriy E Ushakov wrote:
> > This low level stuff has nothing to do with CL directly, but I just
> > want to show you that even at the bare iron level of "standalone-ness"
> > people actually deploy code in production (even in the flash!) with
> > debugging facilities built-in.
>
> It's always misleading to give examples from spacecraft because
> they're so weird, but I remember a story about some mars spacecraft
> (quite recent I think, and one of the ones that didn't crash), which
> suffered from system crashes due to <something>. The thing ran some
> embedded OS - perhaps OS9? - and the people, being sensible, had left
> all the debugging tools there. The description I read was a bit vague
> but it sounded suspiciously as if they essentially logged in to the
> spacecraft and edited parameters interactively to fix the problem. I
> thought this was really cool. What was sad was that they (the NASA
> people) got attacked for launching the thing with bugs, when in fact
> they'd done everything they needed to to make sure they could fix the
> bugs on the fly, while not missing the launch window due to testing).
The OS was VxWorks. They left the command line interpreter compiled in to
the image, so they were able to change the type of a mutex on the fly.
See http://www.kohala.com/start/papers.others/pathfinder.html.
Tim
Raymond Toy
Tim> * Raymond Toy wrote:
>> Can you describe how this works in a bit more detail? Is this a
>> multithreaded Lisp so you can do patch in one thread without stopping the
>> processing in the other threads? How does changing a function, say,
>> interact with other running threads? (I don't use a threaded Lisp.)
Tim> I think that it would really be interesting only for some
Tim> multithreaded application, although I can imagine something
Tim> event-driven as well (one source of events would be something that
Tim> said `you have a patch, waiting, please load it'). For such a
Tim> single-threaded application you wouldn't have the issue of other
Tim> threads, but you would have the issue of whether redefining a function
Tim> actually means that callers pick up the new version, which is I think
Tim> not guaranteed by the standard (unless you declare everything
Tim> NOTINLINE) but in practice it's easy enough to know what the
Tim> implementation does that it is not a problem.
Tim> For a multithreaded application you'd have to do something that put
Tim> the other threads into a good state, and this might involve
Tim> essentially momentarily stopping the application while the patch
Tim> loaded, but the interruption would be brief - and you can likely
Tim> arrange things so that volatile state is not lost while this happens.
Tim> On top of this you have the same redefinition caveats as above.
Thanks for the example (and Coby Beck too). All of my lisp code has
been simulations of a wireless radio link so if I goofed, that meant
all previous results were wrong and the current state would very
likely be wrong too ,so I would have to start over in any case.
Startup times are on the order of seconds to maybe a minute.
Thanks,
Ray
Aleksandr Skobelev
> * Aleksandr Skobelev wrote:
>> <IN-MY-OPINION>
>
> I think the preferred syntax is (with-opinion (:mine t) ...)
You have just read my thoughts! :) I've wanted to use something like that,
but I haven't decided what to do with special characters in the body of
such form. So I decided to went by beaten track. We could also use
something like
(deftype confidence ()
'(member
:rumours :my-opinion :law-of-nature :hyperspec))
(declaim (type confidence *confidence-level*))
(defparameter *confidence-level* :my-opinion)
But it is of course a little verbose. :)
Absolutly agree with you. No any objections.
Aleksandr
Aleksandr Skobelev
>
>> much obliged to you the rest of all my life. :)
>>
>
> (Assuming a good natured joke in the line "something that can save my life" -
> ie I don't think you really believe a small executable is so important that you
> won't sacrifice it except to save your life)
If you look at the end of my phrase more carefully, you will find there a
little sign, which is used to mark this phrase as a joke and, of course,
good natured joke. :)
>
> No, you can not get a very small "Hello World" program in Common Lisp without a
> lot of the Lisp system included. This is a mark on the column of bad points.
Thank you it is all that I've tried to know.
> But what do you get in return?
>
> * A *much* faster development cycle
> * A program that can be modified/enhanced/debugged while it is still running
> * The ability to use symbols as data
> * A macro system so powerful you can define your own programming language on
> top of CL
> * An object oriented development platform that allows you to redefine your
> classes at runtime, existing objects and all
> * A language that can easily produce, compile and execute it's own source code,
> again at runtime
>
> This is just a start of a list of Common Lisp's good points, perhaps others
> will chime in with others. But I think it is quite enough to outweigh any
> disadvantage of a small executable for all but a very few and very specific
> situations.
>
Thank you for propaganda. :) It is always useful to speak some good words
about advantages of CL.
Aleksandr
Aleksandr Skobelev
In article <9o52v4$2230$1...@news.spbu.ru> you wrote:
> Aleksandr Skobelev <22...@mail.ru> wrote:
>
> Have you ever tried to deal with bug reports for "standalone" programs
> in real life? (this is not a rethorical question).
>
> User: "Gee, this program crashes sometimes. Here's a 40M core
> dump. No, sorry, my executable is stripped".
In a real "non UNIX" life -- yes. Until now I have been working
professionally only for windoze. So on my work I never encountered with a
core dumps. Usually I just write some critical information in a logfile,
which can be sent me by user in the critical situations. It is work well
enough for me. It might not always give me precise point in the case of
crash as this could be with a core dump.
But, I'd like to notice, that, from my experience, errors when program
"core dumped" (as in UNIX) or "abnormal terminated" usualy occur somewhere
in the begining of development. In the middle or end of development cicle
I've encountered more frequently with logical errors. In such situations
additional debug facilities included in the program running on machine,
which is in a thousand miles away from me, just has no any sense. I think,
not one of us hopes that user will be step over program in a debugger or
just print backtrace.
> ...
> And if you want to go even more down to the iron, consider that
> e.g. OpenFirmware comes with debugger as well. Re boot loaders ;)
> - this debugger helped me a great deal recently to debug a boot loader
> and kernel bootstrapping code (before kernel debugger is initialized).
I must admit that I have no any idea of what is OpenFirmware. :)
> ...
> IOW: why do you think it would be good for you (and for Lisp)?
>
I beg you don't ask me, please, questions which I already several times
replayed in this thread and by mail. Just read this thread and if any
questions remain I will answer. We can also discuss this by mail in
Russian. Which I know better, I hope, :) and probably I will be able to
describe my point better. And then you help me bring it to other. :)
> ...
> And as far as "don't pay for things you don't use" is concerned...
> IMO, C++, the language as whole paid a *huge* price to let its users
> think they do not pay for things they don't use.
It sounds interesting but I don't see your point. Are the users pay? :)
Aleksandr
Aleksandr Skobelev
> Aleksandr Skobelev <22...@mail.ru> writes:
>
>> Thomas F. Burdick <t...@apocalypse.ocf.berkeley.edu> wrote:
>>
>> This is what I trying to do.
>
> But it looks like your value system is heavily influenced by C++. At
> this point the choice is yours: either you drop your preconceptions
> and learn CL in its own terms or you try to cast CL into your C++ way
> of thinking and don't learn CL (but a CL++ as it has been called
> recently).
>
I have no any preconceptions about CL.
>> There were not any fighting against the CL. If not, of course, you
>> consider that having own opinion about features which one'd like to
>> have in CL is a fightning against the CL. :)
>
> You may of course think that it's just your opinion. But you have been
> brainwashed by C++ and might think that C++ is the one and only right
> way to do things.
Speak for youself, please. What have you been brainwashed by?
> CL is a completely different world. C++ value system
> just doesn't make sense here.
It is absolutly no use for you try to explain me obvious things.
> I just want to help you understand where the problem is.
Really? Excuse me, I didn't mind it.
By the way, I have no any problem.
Thomas F. Burdick
> Thomas F. Burdick <t...@apocalypse.ocf.berkeley.edu> wrote:
> > If you want to use Common Lisp, you should try to do things the CL
> > way and judge things using a CL value system.
[...]
> Hmm... Or you don't read this thread from the begining but only Erik's
> message, or I have been explaning myself very bad. :(
> There were not any fighting against the CL. If not, of course, you
> consider that having own opinion about features which one'd like to have
> in CL is a fightning against the CL. :)
It's not fighting against CL, yet, but your opinions about what CL
should and should not be are still based on the values C++ was
designed for. My point is that if you follow that path, you will end
out fighting against CL, trying to turn it into C++.
Thomas F. Burdick
> No, you can not get a very small "Hello World" program in Common Lisp without a
> lot of the Lisp system included. This is a mark on the column of bad points.
> But what do you get in return?
And I don't even buy that. When was the last time you used a
statically linked program, outside of the context of installing an
operating system? Perhaps "large support library" is a mark against
CL, but then C loses too. On my Linux system, the kernel knows how to
run CLISP's .fas files, so that's essentially the same as if they were
dynamically linked. hello.fas is 222 bytes.
Thomas F. Burdick
> Let me repeat myself:
>
> Therefore, the _concept_ "standalone executable" is no longer valid.
>
> _You_ are, in other words, trying to abuse the context of the validity of
> the concept "standalone executable" beyond what it once was able to
> withstand. Standandalone executables no longer exist, except those in
> embedded systems. Everything else depends on a lot of supporting
> software around them that you simply cannot ignore. (I was wrong about
> boot loaders -- they depend on the BIOS, which are not standalone,
> either.) It is a very good idea to rid yourself of the whole notion of
> "standalone" in dealing with executables. It marks you as completely
> outdated in the modern computer world.
Of course, this doesn't mean there's no concept that took its place.
When I'm installing a program on my system, particularly back when I
had a modem connection, I ask: how big is its package, and what
support libraries does it need. If I were to release some trivial CL
GUI application on Debian, its dependencies would probably be:
cmucl, libc6, cmucl-small, garnet, xlibs
(Of course, I'd have to package up garnet for Debian...)
If I were to rewrite the same in a conventional language (C++), its
dependencies would probably be:
libstdc++2.10, libc6, libgtkmm, libglib1.2, libgtk1.2, xlib6g, xlibs, libxaw6
These are the base levels from which I would start adding libraries
specific to a more useful app. I used to look at the CL list, and
notice that cmucl-small and garnet are kind of big -- not too bad, but
a pain on a 28k modem -- and I thought the C++ dependencies were fine.
Until I was talking to a friend about a cute little trivial utility I
wrote, and he wanted a copy. He runs KDE. It would have been easier
for him to have installed cmucl-small and garnet then all the junk my
utility required (most of Gnome). He ended out saying, thanks, but no
thanks.
Seriously, for little trivial gui apps, I think Common Lisp,
Objective-C/OpenStep, and SmallTalk are more reasonable than their C++
counterparts. All three of these had full-featured impressive gui
environments 10 years ago, at which point people freaked out about the
size of the environment required to run apps developed under them.
But the support environment they need is scary by 1991 standards, not
2001 standards. Meanwhile, C++ has *very* slowly grown into a
comparable environment. And things like KDE and Gnome can be scary to
install by 2001 standards.
Dr. Edmund Weitz
> A lot of CGIs have been written in Perl. When people test this, CLISP
> starts up faster than Perl and is for a lot of things faster.
I was surprised to read this and tested it on my laptop but I'm not
convinced: I created two files - test.pl and test.lisp - that were
both empty except for the shebang lines (#!/usr/bin/perl and
#!/usr/bin/clisp), made them executable and got the following results:
edi@bird:~ > time for i in 1 2 3 4 5; do for j in 1 2 3 4 5; do for k in 1 2 3 4 5; do ./test.lisp; done; done; done
real 0m3.503s
user 0m2.330s
sys 0m1.180s
edi@bird:~ > time for i in 1 2 3 4 5; do for j in 1 2 3 4 5; do for k in 1 2 3 4 5; do ./test.pl; done; done; done
real 0m0.710s
user 0m0.400s
sys 0m0.290s
Is something wrong with my testing methodology or did you mean
something different? (I'm using a more or less stock SuSE 7.2 -
kernel 2.4.4, perl 5.6.0, clisp 2000.03.06-56 - if that matters.)
Thanks,
Edi.
Daniel Barlow
> support libraries does it need. If I were to release some trivial CL
> GUI application on Debian, its dependencies would probably be:
>
> cmucl, libc6, cmucl-small, garnet, xlibs
> (Of course, I'd have to package up garnet for Debian...)
(with-hope (:forlorn)
(declare (optimize (optimism 3)))
"If you _want_ to package Garnet for Debian, the cCLan project would
be happy to distribute it ...")
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Espen Vestre
> Let me repeat myself:
>
> Therefore, the _concept_ "standalone executable" is no longer valid.
I still think, though, that it's interesting to talk about
"self-contained" applications, where "self-contained" means something
like "can be installed by simply copying into any diretory on a
vanilla install of the target OS". I actually think it's great that I
can build self-contained applications with ACL or LispWorks and tell
puzzled system administrators that they actually don't have to
"install a lisp interpreter" on the target machine. In my context, the
size of these self-contained applications is absolutely irrelevant.
--
(espen)
Dr. Edmund Weitz
> I still think, though, that it's interesting to talk about
> "self-contained" applications, where "self-contained" means something
> like "can be installed by simply copying into any diretory on a
> vanilla install of the target OS". I actually think it's great that I
> can build self-contained applications with ACL or LispWorks and tell
> puzzled system administrators that they actually don't have to
> "install a lisp interpreter" on the target machine.
Just curious: I wonder why this is not possible in the 'free' CL
implementations (whereby I mean CMUCL and CLISP which can be
downloaded and deployed without charge as well as the demonstration
versions of ACL, LispWorks, and MCL). Is this a feature that is
extremely difficult to implement and thus used by the commercial
vendors as a means to differentiate themselves from the rest? Or did
the maintainers of CMUCL and CLISP leave this out on purpose?
And, if I may add: It looks like Franz, Xanalys, and Digitool seem to
value the concept of "self-contained" applications (or at least think
their customers do) because they only offer the ability to build these
in their non-evaluation products.
Thanks,
Edi.
PS: I'm not sure about the status of GCL as far as this feature is
concerned. IIRC it compiles to C code that can be fed into gcc. Does
that mean it will produce "self-contained" apps? What about Corman
Lisp?
Paolo Amoroso
> they're so weird, but I remember a story about some mars spacecraft
> (quite recent I think, and one of the ones that didn't crash), which
> suffered from system crashes due to <something>. The thing ran some
> embedded OS - perhaps OS9? - and the people, being sensible, had left
> all the debugging tools there. The description I read was a bit vague
> but it sounded suspiciously as if they essentially logged in to the
> spacecraft and edited parameters interactively to fix the problem. I
> thought this was really cool. What was sad was that they (the NASA
The spacecraft was Mars Pathfinder and the operating system VxWorks.
I include below two very interesting articles posted to sci.space.news a few
years ago about this issue. I apologize in advance for their length, but they
include details that may not be widely known, and they may provide some useful
insight.
Paolo
=========================================================================
~From: baa...@brucie.jpl.nasa.gov (Ron Baalke)
~Newsgroups: sci.space.news
~Subject: What Really Happend On Mars Pathinder
~Date: 2 Jan 1998 07:10 UT
Here's a technical discussion about the real-time software used on the
Mars Pathfinder lander.
Ron Baalke
-----------------------------------------------------------------
From: Mike Jones <m...@MICROSOFT.com>
Subject: What really happened on Mars Rover Pathfinder
Date: December 7, 1997
The Mars Pathfinder mission was widely proclaimed as "flawless" in the early
days after its July 4th, 1997 landing on the Martian surface. Successes
included its unconventional "landing" -- bouncing onto the Martian surface
surrounded by airbags, deploying the Sojourner rover, and gathering and
transmitting voluminous data back to Earth, including the panoramic pictures
that were such a hit on the Web. But a few days into the mission, not long
after Pathfinder started gathering meteorological data, the spacecraft began
experiencing total system resets, each resulting in losses of data. The
press reported these failures in terms such as "software glitches" and "the
computer was trying to do too many things at once".
This week at the IEEE Real-Time Systems Symposium I heard a fascinating
keynote address by David Wilner, Chief Technical Officer of Wind River
Systems. Wind River makes VxWorks, the real-time embedded systems kernel
that was used in the Mars Pathfinder mission. In his talk, he explained in
detail the actual software problems that caused the total system resets of
the Pathfinder spacecraft, how they were diagnosed, and how they were
solved. I wanted to share his story with each of you.
VxWorks provides preemptive priority scheduling of threads. Tasks on the
Pathfinder spacecraft were executed as threads with priorities that were
assigned in the usual manner reflecting the relative urgency of these tasks.
Pathfinder contained an "information bus", which you can think of as a
shared memory area used for passing information between different components
of the spacecraft. A bus management task ran frequently with high priority
to move certain kinds of data in and out of the information bus. Access to
the bus was synchronized with mutual exclusion locks (mutexes).
The meteorological data gathering task ran as an infrequent, low priority
thread, and used the information bus to publish its data. When publishing
its data, it would acquire a mutex, do writes to the bus, and release the
mutex. If an interrupt caused the information bus thread to be scheduled
while this mutex was held, and if the information bus thread then attempted
to acquire this same mutex in order to retrieve published data, this would
cause it to block on the mutex, waiting until the meteorological thread
released the mutex before it could continue. The spacecraft also contained
a communications task that ran with medium priority.
Most of the time this combination worked fine. However, very infrequently
it was possible for an interrupt to occur that caused the (medium priority)
communications task to be scheduled during the short interval while the
(high priority) information bus thread was blocked waiting for the (low
priority) meteorological data thread. In this case, the long-running
communications task, having higher priority than the meteorological task,
would prevent it from running, consequently preventing the blocked
information bus task from running. After some time had passed, a watchdog
timer would go off, notice that the data bus task had not been executed for
some time, conclude that something had gone drastically wrong, and initiate
a total system reset.
This scenario is a classic case of priority inversion.
HOW WAS THIS DEBUGGED?
VxWorks can be run in a mode where it records a total trace of all
interesting system events, including context switches, uses of
synchronization objects, and interrupts. After the failure, JPL engineers
spent hours and hours running the system on the exact spacecraft replica in
their lab with tracing turned on, attempting to replicate the precise
conditions under which they believed that the reset occurred. Early in the
morning, after all but one engineer had gone home, the engineer finally
reproduced a system reset on the replica. Analysis of the trace revealed
the priority inversion.
HOW WAS THE PROBLEM CORRECTED?
When created, a VxWorks mutex object accepts a boolean parameter that
indicates whether priority inheritance should be performed by the mutex.
The mutex in question had been initialized with the parameter off; had it
been on, the low-priority meteorological thread would have inherited the
priority of the high-priority data bus thread blocked on it while it held
the mutex, causing it be scheduled with higher priority than the
medium-priority communications task, thus preventing the priority inversion.
Once diagnosed, it was clear to the JPL engineers that using priority
inheritance would prevent the resets they were seeing.
VxWorks contains a C language interpreter intended to allow developers to
type in C expressions and functions to be executed on the fly during system
debugging. The JPL engineers fortuitously decided to launch the spacecraft
with this feature still enabled. By coding convention, the initialization
parameter for the mutex in question (and those for two others which could
have caused the same problem) were stored in global variables, whose
addresses were in symbol tables also included in the launch software, and
available to the C interpreter. A short C program was uploaded to the
spacecraft, which when interpreted, changed the values of these variables
from FALSE to TRUE. No more system resets occurred.
ANALYSIS AND LESSONS
First and foremost, diagnosing this problem as a black box would have been
impossible. Only detailed traces of actual system behavior enabled the
faulty execution sequence to be captured and identified.
Secondly, leaving the "debugging" facilities in the system saved the day.
Without the ability to modify the system in the field, the problem could not
have been corrected.
Finally, the engineer's initial analysis that "the data bus task executes
very frequently and is time-critical -- we shouldn't spend the extra time in
it to perform priority inheritance" was exactly wrong. It is precisely in
such time critical and important situations where correctness is essential,
even at some additional performance cost.
HUMAN NATURE, DEADLINE PRESSURES
David told us that the JPL engineers later confessed that one or two system
resets had occurred in their months of pre-flight testing. They had never
been reproducible or explainable, and so the engineers, in a very
human-nature response of denial, decided that they probably weren't
important, using the rationale "it was probably caused by a hardware
glitch".
Part of it too was the engineers' focus. They were extremely focused on
ensuring the quality and flawless operation of the landing software. Should
it have failed, the mission would have been lost. It is entirely
understandable for the engineers to discount occasional glitches in the
less-critical land-mission software, particularly given that a spacecraft
reset was a viable recovery strategy at that phase of the mission.
THE IMPORTANCE OF GOOD THEORY/ALGORITHMS
David also said that some of the real heroes of the situation were some
people from CMU who had published a paper he'd heard presented many years
ago who first identified the priority inversion problem and proposed the
solution. He apologized for not remembering the precise details of the
paper or who wrote it. Bringing things full circle, it turns out that the
three authors of this result were all in the room, and at the end of the
talk were encouraged by the program chair to stand and be acknowledged.
They were Lui Sha, John Lehoczky, and Raj Rajkumar. When was the last time
you saw a room of people cheer a group of computer science theorists for
their significant practical contribution to advancing human knowledge? :-)
It was quite a moment.
POSTLUDE
For the record, the paper was:
L. Sha, R. Rajkumar, and J. P. Lehoczky. Priority Inheritance Protocols: An
Approach to Real-Time Synchronization. In IEEE Transactions on Computers,
vol. 39, pp. 1175-1185, Sep. 1990.
=========================================================================
~From: baa...@brucie.jpl.nasa.gov (Ron Baalke)
~Newsgroups: sci.space.news
~Subject: Re: What Really Happened On Mars?
~Date: 8 Jan 1998 01:52 UT
This is a followup to the technical discussion about the Mars
Pathfinder flight software from Glenn Reeves. Glenn Reeves is
team leader of the software team for the Mars Pathfinder spacecraft.
Ron Baalke
------------------------------------------------------------------
Subject: Re: [Fwd: FW: What really happened on Mars?]
From: Glenn E Reeves
What really happend on Mars ?
By now most of you have read Mike's (m...@microsoft.com) summary of Dave Wilner's
comments given at the IEEE Real-Time Systems Symposium. I don't know Mike and I
didn't attend the symposium (though I really wish I had now) and I have not
talked to Dave Wilner since before the talk. However, I did lead the software
team for the Mars Pathfinder spacecraft. So, instead of trying to find out what
was said I will just tell you what happened. You can make your own judgments.
I sent this message out to everyone who was a recipient of Mike's original that
I had an email address for. Please pass it on to anyone you sent the first one
to. Mike, I hope you will post this wherever you posted the original.
Since I want to make sure the problem is clearly understood I need to step
through each of the areas which contributed to the problem.
THE HARDWARE
The simplified view of the Mars Pathfinder hardware architecture looks like
this. A single CPU controls the spacecraft. It resides on a VME bus which also
contains interface cards for the radio, the camera, and an interface to a 1553
bus. The 1553 bus connects to two places : The "cruise stage" part of the
spacecraft and the "lander" part of the spacecraft. The hardware on the cruise
part of the spacecraft controls thrusters, valves, a sun sensor, and a star
scanner. The hardware on the lander part provides an interface to
accelerometers, a radar altimeter, and an instrument for meteorological science
known as the ASI/MET. The hardware which we used to interface to the 1553 bus
(at both ends) was inherited from the Cassini spacecraft. This hardware came
with a specific paradigm for its usage : the software will schedule activity at
an 8 Hz rate. This **feature** dictated the architecture of the software which
controls both the 1553 bus and the devices attached to it.
THE SOFTWARE ARCHITECTURE
The software to control the 1553 bus and the attached instruments was
implemented as two tasks. The first task controlled the setup of transactions
on the 1553 bus (called the bus scheduler or bc_sched task) and the second task
handled the collection of the transaction results i.e. the data. The second
task is referred to as the bc_dist (for distribution) task. A typical timeline
for the bus activity for a single cycle is shown below. It is not to scale.
This cycle was constantly repeated.
|< ------------- .125 seconds ------------------------>|
|<***************| |********| |**>|
|<- bc_dist active ->| bc_sched active
|< -bus active ->| |<->|
----|----------------|--------------------|--------|---|---|-------
t1 t2 t3 t4 t5 t1
The *** are periods when tasks other than the ones listed are executing. Yes,
there is some idle time.
t1 - bus hardware starts via hardware control on the 8 Hz boundary. The
transactions for the this cycle had been set up by the previous execution of the
bc_sched task.
t2 - 1553 traffic is complete and the bc_dist task is awakened.
t3 - bc_dist task has completed all of the data distribution
t4 - bc_sched task is awakened to setup transactions for the next cycle
t5 - bc_sched activity is complete
The bc_sched and bc_dist tasks check each cycle to be sure that the other had
completed its execution. The bc_sched task is the highest priority task in the
system (except for the vxWorks "tExec" task). The bc_dist is third highest (a
task controlling the entry and landing is second). All of the tasks which
perform other spacecraft functions are lower. Science functions, such as
imaging, image compression, and the ASI/MET task are still lower.
Data is collected from devices connected to the 1553 bus only when they are
powered. Most of the tasks in the system that access the information collected
over the 1553 do so via a double buffered shared memory mechanism into which the
bc_dist task places the latest data. The exception to this is the ASI/MET task
which is delivered its information via an interprocess communication mechanism
(IPC). The IPC mechanism uses the vxWorks pipe() facility. Tasks wait on one
or more IPC "queues" for messages to arrive. Tasks use the select() mechanism
to wait for message arrival. Multiple queues are used when both high and lower
priority messages are required. Most of the IPC traffic in the system is not
for the delivery of real-time data. However, again, the exception to this is
the use of the IPC mechanism with the ASI/MET task. The cause of the reset on
Mars was in the use and configuration of the IPC mechanism.
THE FAILURE
The failure was identified by the spacecraft as a failure of the bc_dist task to
complete its execution before the bc_sched task started. The reaction to this
by the spacecraft was to reset the computer. This reset reinitializes all of
the hardware and software. It also terminates the execution of the current
ground commanded activities. No science or engineering data is lost that has
already been collected (the data in RAM is recovered so long as power is not
lost). However, the remainder of the activities for that day were not
accomplished until the next day.
The failure turned out to be a case of priority inversion (how we discovered
this and how we fixed it are covered later). The higher priority bc_dist task
was blocked by the much lower priority ASI/MET task that was holding a shared
resource. The ASI/MET task had acquired this resource and then been preempted
by several of the medium priority tasks. When the bc_sched task was activated,
to setup the transactions for the next 1553 bus cycle, it detected that the
bc_dist task had not completed its execution. The resource that caused this
problem was a mutual exclusion semaphore used within the select() mechanism to
control access to the list of file descriptors that the select() mechanism was
to wait on.
The select mechanism creates a mutual exclusion semaphore to protect the "wait
list" of file descriptors for those devices which support select. The vxWorks
pipe() mechanism is such a device and the IPC mechanism we used is based on
using pipes. The
ASI/MET task had called select, which had called pipeIoctl(), which had called
selNodeAdd(), which was in the process of giving the mutex semaphore. The ASI/
MET task was preempted and semGive() was not completed. Several medium
priority tasks ran until the bc_dist task was activated. The bc_dist task
attempted to send the newest ASI/MET data via the IPC mechanism which called
pipeWrite(). pipeWrite() blocked, taking the mutex semaphore. More of the
medium priority tasks ran, still not allowing the ASI/MET task to run, until the
bc_sched task was awakened. At that point, the bc_sched task determined that
the bc_dist task had not completed its cycle (a hard deadline in the system) and
declared the error that initiated the reset.
HOW WE FOUND IT
The software that flies on Mars Pathfinder has several debug features within it
that are used in the lab but are not used on the flight spacecraft (not used
because some of them produce more information than we can send back to Earth).
These features were not "fortuitously" left enabled but remain in the software
by design. We strongly believe in the "test what you fly and fly what you test"
philosophy.
One of these tools is a trace/log facility which was originally developed to
find a bug in an early version of the vxWorks port (Wind River ported vxWorks to
the RS6000 processor for us for this mission). This trace/log facility was
built by David Cummings who was one of the software engineers on the task. Lisa
Stanley, of Wind River, took this facility and instrumented the pipe services,
msgQ services, interrupt handling, select services, and the tExec task. The
facility initializes at startup and continues to collect data (in ring buffers)
until told to stop. The facility produces a voluminous dump of information when
asked.
After the problem occurred on Mars we did run the same set of activities over
and over again in the lab. The bc_sched was already coded so as to stop the
trace/log collection and dump the data (even though we knew we could not get the
dump in flight) for this error. So, when we went into the lab to test it we did
not have to change the software.
In less that 18 hours we were able to cause the problem to occur. Once we were
able to reproduce the failure the priority inversion problem was obvious.
HOW WAS THE PROBLEM CORRECTED
Once we understood the problem the fix appeared obvious : change the creation
flags for the semaphore so as to enable the priority inheritance. The Wind
River folks, for many of their services, supply global configuration variables
for parameters such as the "options" parameter for the semMCreate used by the
select service (although this is not documented and those who do not have
vxWorks source code or have not studied the source code might be unaware of this
feature). However, the fix is not so obvious for several reasons :
1) The code for this is in the selectLib() and is common for all device
creations. When you change this global variable all of the select semaphores
created after that point will be created with the new options. There was no
easy way in our initialization logic to only modify the semaphore associated
with the pipe used for bc_dist task to ASI/MET task communications.
2) If we make this change, and it is applied on a global basis, how will this
change the behavior of the rest of the system ?
3) The priority inversion option was deliberately left out by Wind River in the
default selectLib() service for optimum performance. How will performance
degrade if we turn the priority inversion on ?
4) Was there some intrinsic behavior of the select mechanism itself that would
change if the priority inversion was enabled ?
We did end up modifying the global variable to include the priority inversion.
This corrected the problem. We asked Wind River to analyze the potential
impacts for (3) and (4). They concluded that the performance impact would be
minimal and that the behavior of select() would not change so long as there was
always only one task waiting for any particular file descriptor. This is true
in our system. I believe that the debate at Wind River still continues on
whether the priority inversion option should be on as the default. For (1) and
(2) the change did alter the characteristics of all of the select semaphores.
We concluded, both by analysis and test, that there was no adverse behavior. We
tested the system extensively before we changed the software on the spacecraft.
HOW WE CHANGED THE SOFTWARE ON THE SPACECRAFT
No, we did not use the vxWorks shell to change the software (although the shell
is usable on the spacecraft). The process of "patching" the software on the
spacecraft is a specialized process. It involves sending the differences
between what you have onboard and what you want (and have on Earth) to the
spacecraft. Custom software on the spacecraft (with a whole bunch of
validation) modifies the onboard copy. If you want more info you can send me
email.
WHY DIDN'T WE CATCH IT BEFORE LAUNCH ?
The problem would only manifest itself when ASI/MET data was being collected and
intermediate tasks were heavily loaded. Our before launch testing was limited
to the "best case" high data rates and science activities. The fact that data
rates from the surface were higher than anticipated and the amount of science
activities proportionally greater served to aggravate the problem. We did not
expect nor test the "better than we could have ever imagined" case.
HUMAN NATURE, DEADLINE PRESSURES
We did see the problem before landing but could not get it to repeat when we
tried to track it down. It was not forgotten nor was it deemed unimportant.
Yes, we were concentrating heavily on the entry and landing software. Yes, we
considered this problem lower priority. Yes, we would have liked to have
everything perfect before landing. However, I don't see any problem here other
than we ran out of time to get the lower priority issues completed.
We did have one other thing on our side; we knew how robust our system was
because that is the way we designed it.
We knew that if this problem occurred we would reset. We built in mechanisms to
recover the current activity so that there would be no interruptions in the
science data (although this wasn't used until later in the landed mission). We
built in the ability (and tested it) to go through multiple resets while we were
going through the Martian atmosphere. We designed the software to recover from
radiation induced errors in the memory or the processor. The spacecraft would
have even done a 60 day mission on its own, including deploying the rover, if
the radio receiver had broken when we landed. There are a large number of
safeguards in the system to ensure robust, continued operation in the event of a
failure of this type. These safeguards allowed us to designate problems of this
nature as lower priority.
We had our priorities right.
ANALYSIS AND LESSONS
Did we (the JPL team) make an error in assuming how the select/pipe mechanism
would work ? Yes, probably. But there was no conscious decision to not have
the priority inversion enabled. We just missed it. There are several other
places in the flight software where similar protection is required for critical
data structures and the semaphores do have priority inversion protection. A
good lesson when you fly COTS stuff - make sure you know how it works.
Mike is quite correct in saying that we could not have figured this out **ever**
if we did not have the tools to give us the insight. We built many of the tools
into the software for exactly this type of problem. We always planned to leave
them in. In fact, the shell (and the stdout stream) were very useful the entire
mission. If you want more detail send me a note.
SETTING THE RECORD STRAIGHT
First, I want to make sure that everyone understands how I feel in regard to
Wind River. These folks did a fantastic job for us. They were enthusiastic and
supported us when we came to them and asked them to do an affordable port of
vxWorks. They delivered the alpha version in 3 months. When we had a problem
they put some of the brightest engineers I have ever worked with on the problem.
Our communication with them was fantastic. If they had not done such a
professional job the Mars Pathfinder mission would not have been the success
that it is.
Second, Dave Wilner did talk to me about this problem before he gave his talk.
I could not find my notes where I had detailed the description of the problem.
So, I winged it and I sure did get it wrong. Sorry Dave.
ACKNOWLEDGMENTS
First, thanks to Mike for writing a very nice description of the talk. I think
I have had probably 400 people send me copies. You gave me the push to write
the part of the Mars Pathfinder End-of-Mission report that I had been
procrastinating doing.
A special thanks to Steve Stolper for helping me do this.
The biggest thanks should go to the software team that I had the privilege of
leading and whose expertise allowed us to succeed :
Pam Yoshioka
Dave Cummings
Don Meyer
Karl Schneider
Greg Welz
Rick Achatz
Kim Gostelow
Dave Smyth
Steve Stolper
Also ,
Miguel San Martin
Sam Sirlin
Brian Lazara (WRS)
Mike Deliman (WRS)
Lisa Stanley (WRS)
---------------------
Glenn Reeves
Mars Pathfinder Flight Software Cognizant Engineer
glenn.e...@jpl.nasa.gov
=========================================================================
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
Daniel Barlow
> Espen Vestre <espen@*do-not-spam-me*.vestre.net> writes:
>
> > I still think, though, that it's interesting to talk about
> > "self-contained" applications, where "self-contained" means something
> > like "can be installed by simply copying into any diretory on a
> > vanilla install of the target OS". I actually think it's great that I
[...]
> Just curious: I wonder why this is not possible in the 'free' CL
> implementations (whereby I mean CMUCL and CLISP which can be
Well, one obvious reason is that the target user can install the
complete free CL development environment without any licensing issues,
so the value of a "self-contained" application is really only what it
saves you in the time it would otherwise take to install the
development environment (and, yeah, the disk space).
SBCL 0.6.13 as a Debian binary package is about a 6Mb download, and
installation is a question of typing "apt-get install sbcl"[*] as root
and waiting for stuff to happen. This is not complicated, expensive,
or particularly time-consuming, so for the developers to expend vast
effort building tree-shakers and suchlike would probably not be all
that worthwhile when there's so much else that needs doing first.
-dan
[*] Nearly. It's not actually _in_ the debian package system just
yet, but people are working on it.
Aleksandr Skobelev
> * Aleksandr Skobelev <22...@mail.ru>
>> Where have I wrote about disk space?
>
> Please do not be coy with me. The way you have defined standalone
> executable is definitely a disk-space argument.
>
Internet channel) and just a "human factor".
>> By the way, I don't understand why my wish of Lisp system can generate
>> small applications is so horrible?
>
> Look, I have already told you it is not, in fact, that it is a good thing
> for certain limited purposes.
Excuse me I don't understand what it is not a good thing?
> Please pay attention to what I say if you wish to talk with me.
I beg you about the same thing. If you wish to talk with me, please, read my
answers more carefully.
> I am _trying_ to be patient with you, but you are
> turning out to be very, very annoying and persistent in repeating things
> that have been refuted by several people.
>
First of all, it isn't need for you be patient. Just ignore my messages.
And they won't bother you.
There is nothing has been refuted by anyone. Some people just tried to
refute some things which AS THEY THOUGHT had been told by me. But, really,
things we told about were same.
I think, also, you shouldn't hide for other people. Just speak for yourself.
> Why are you doing this? My "USENET troll" sensor is peaking.
It is your problems. I think it might point to you. Might it has been be
better for you to stop looking for enemy? And just drop your broken
sensor.
>> You have missed my point here. I argue that some qualities of CL
>> realizations won't allowed me to start using it on my work very soon.
>
> My argument is that those are not some qualities of CL, but some of
> _your_ qualities in interaction with some of the qualities of CL.
> ...
In the quote from my message which you put here just wrote the same
things. There are mention about CL qualities and mentions about my
qualities ('allowed ME', 'on MY work', 'VERY SOON').
READ MORE CAREFULLY. Learn to get what other people want to
express, but not what you expect hear from their.
Aleksandr Skobelev
Isn't it possible to create dynamically linked applications with
commercial Lisps?
Aleksandr Skobelev
> * Aleksandr Skobelev <22...@mail.ru>
>> An any concept is not valid in absolute sense. It is only valid in
>> context of current discussion after all sides who take part in that
>> discussion came to agree about the meaning of that concept and until the
>> end of discussion.
>
You definitely didn't say nothing appropriate. :)
You only said that "... the concept 'standalone executable' is no longer
valid' because of '... A huge set of libraries and support functions from the
ioperating system'".
But I hope that at least we came to agreement that any term can only exist
in given context.
>
> Let me repeat myself:
>
> Therefore, the _concept_ "standalone executable" is no longer valid.
>
> _You_ are, in other words, trying to abuse the context of the validity of
> the concept "standalone executable" beyond what it once was able to
> withstand. Standandalone executables no longer exist, except those in
> embedded systems. Everything else depends on a lot of supporting
> software around them that you simply cannot ignore. (I was wrong about
> boot loaders -- they depend on the BIOS, which are not standalone,
> either.) It is a very good idea to rid yourself of the whole notion of
> "standalone" in dealing with executables. It marks you as completely
> outdated in the modern computer world.
>
Erik. I don't know why you are trying to explain me very simple and
obvious things, all the time. I know them. At the same time, it seems to
me, that you just have missed here one simple thing again. Which is that
"standalone executable" is, to speak plain, not a program, not a real
thing, but a term to call some thing. You use it to call one thing, I use
it to call another.
So, I'd like to offer you replace term "standalone executable" by
"RUNNABLE-IN-GIVEN-ENVIRONMENT" and bind *GIVEN-ENVIRONMENT* when you
reply to my messages with COMMON-WINDOWS-INSTALLATION. I'd like that it was
SOME-LINUX-INSTALLATION. But in context of my work it can not be such.
If we will rebind *GIVEN-ENVIRONMENT* to different values we get very
different levels abstraction. If bind *GIVEN-ENVIRONMENT* to something
like BARE-METALL we probably get "standalone executable" in your sence.
We also can bind this variable with LINUX-CMULISP-INSTALLATION which will
have wider range of things which can be RUNNABLE-IN-GIVEN-ENVIRONMENT. So
all *.x86f and *.lisp files also will be included.
So my request in thr new form could be: how much is a size of
RUNNABLE-IN-GIVEN-ENVIRONMENT file produced by commercial Lisp's
realizations (LWW, Allegro)?
And you could reply :)
(CASE *GIVEN-ENVIRONMENT*
('COMMON-WINDOWS-INSTALLATION "~2MB")
('BARE-METALL "~50MB")
('LINUX-CMULISP-INSTALLATION "~1kB")
(OTHERWISE "UNKNOWN")))
>> Computer's programs are intendent to be used but not debugged by users.
>
> That depends on what you consider "debug". I consider the famous DOS
> query "Abort, Retry, Ignore" to be a debugger interface, for instance.
> _Really_ good programs actually allow users to decide the fate of the
> system in face of unhandled exceptional situations, not just _die_, like
> crappy software does. It is highly unlikely that really complex software
> will not encounter unhandled situtations.
> ...
Absolutly have no any objections, just you remember about existence of a
lot of more simple programs, utils.
>
> You have asked us to help you with more information. Your "opinions" are
> the vehicles on which we try to deliver the answers your questions,
> because they constitute the context in which communication with you can
> take place. Therefore, they are not _just_ your opinions, but the whole
> framework of your mind when you come here to receive information. If it
> is clear that you are not able or willing to listen to information that
> says that your "opinions" are misguided (i.e, that your context needs to
> be expanded), you will not learn anything and only frustrate everybody.
> ...
words, words, words...
I have got only 2 replies relevant my request. Both senders haven't
required no any pieces information about my opinions. They just help me.
But not you, Erik...
Aleksandr Skobelev
>
> I don't think that's true, because not all of us have weighed in yet.
You are welcome.
> You may have gotten at least one answer, but before we talk about
> how low we can go with Common Lisp, I want to know if you understand
> where your own bar is. I don't think you do yet. If you do, you
> certainly haven't communicated it to us to my satisfaction.
>
> ...
>
> Thank you for finally giving us this definition. Incidentally, by this
> definition most C programs are not standalone. They do _not_ link in
> their library (libc.so) statically, and thus cannot run without library
> support. It is possible on some systems to link a program completely
> statically (e.g. Solaris has a -Bstatic option), but it gets harder
> and harder all the time. In fact, many third-party vendors provide
> only .so libraries, and not .a files for static linking.
>
C library included in distributives of all modern operating systems I
know. If any library included in distributive and installed by default it
is definitly part of whole OS and any dependencies from such library can
be consider like dependencies of OS. At least in my case this is so.
> ...
>
> In this entire thread you have not told us yet what you are trying
> to do, and what your goals are in limiting the size of CL images.
Excuse me, Duane, I definitely have told. It might be in several messages
so it could require some work to collect all pieces together.
> In my experience, there are only a couple of reasons why people want
> to limit a CL size:
>
> - They have limited transfer capability. Usually the internet or
> the size of floppy-disks limits what can be transferred of a program.
Yes, Internet is one of most critical.
> However, a lisp "program" is really a series of functions, which can
> be contained in a source or .fasl file. Others have mentioned this
> before. I can write a trivial lisp program and give its fasl file a
> magic-number that allows the program to run the lisp that is on the
> system and to load in its own fasl file and run it. Such a program
> can be only a few hundred bytes. We lispers seldom talk about such
> programs because it is too trivial, and we tend to think of it as
> cheating (i.e. it does not really show how much actual memory the
> program is using when it is running).
As far as I undersatnd, this is required from user to have preinstalled
Lisp system. Am I wrong? In MY CURRENT SITUATION is it impossible.
By the way, if, for example, I buy ACL, develope some program with it then
will I be able to distribute part, developed by me, separately from needed
ACL parts?
> You did mention wanting to be able to have lisps loaded on machines
> so that such small programs can be transferred via internet.
> But you do not state why; are you planning to sell products to
> customers who will not want to install a lisp system on their
> machines?
> ...
> So now for my question: Given the above background, can you explain
> to me a little of what you are trying to _do_, and help me to
> understand the reason or reasons why you want your CL system to
> be a specific size?
>
The users and customers is not the same in this case. This system will
contain client's programs which intendent to be download and used by,
theoretically, any user in Internet. There also some parts that works
as a NT service and web-server.
John Markus Bjorndalen
> Just curious: I wonder why this is not possible in the 'free' CL
> implementations (whereby I mean CMUCL and CLISP which can be
> downloaded and deployed without charge as well as the demonstration
> versions of ACL, LispWorks, and MCL). Is this a feature that is
> extremely difficult to implement and thus used by the commercial
> vendors as a means to differentiate themselves from the rest? Or did
> the maintainers of CMUCL and CLISP leave this out on purpose?
I've done something like this when I needed to send lisp programs over
to clusters I didn't have administrator access to:
1. dump a lisp core file (in CMUCL, I haven't tried this with CLISP)
2. copy the core file and /usr/bin/lisp to the host.
3. Run it on the host: ./lisp -core ./whatever.core
4. enjoy
CMUCL generates rather large core files, but I could send "patches" as
source or compiled lisp files whenever changes were needed (I could
even have started with lisp-normal.core which comes with CMUCL and
just loaded the .x86f files if I didn't want to make my own core).
I don't see this as any more difficult than doing the same for a
Python program. If anything, it's probably easier. Especially if you
need to make sure a particular version of Python with necessary
modules is present at the host.
As for C++.... If the two systems didn't have the same version of the
_compiler_ (not just the libraries) things quickly got ugly (recompile
on the target host was the simplest solution).
--
// John Markus Bjørndalen
Erik Naggum
> You definitely didn't say nothing appropriate. :)
You have exhausted my patience. You are here to troll and annoy people,
not to learn anything new, not to listen to others but to insist that
people think the way you do. This kind of arrogance is very annoying,
but you only see yourself, so you do not notice anything else, anyway.
> words, words, words...
> I have got only 2 replies relevant my request. Both senders haven't
> required no any pieces information about my opinions. They just help me.
> But not you, Erik...
I have tried to figure out what you really need, not what you _believe_
you need from a different value syste, and so have several other people,
but you never get the hint. Stupid people do not generally find such
quests for underlying assumptions and desires fruitful, but go blundering
on about the things they think they must need because they are completely
unaware of how they got to the point where they are, and thus cannot move
anywhere else.
Just go away, troll. We should have known just by your question that you
were trolling. It is just _too_ dumb to ask about size of executables to
be a real and honest question.
///
John Markus Bjorndalen
Aleksandr Skobelev <22...@mail.ru> writes:
> So, I'd like to offer you replace term "standalone executable" by
> "RUNNABLE-IN-GIVEN-ENVIRONMENT" and bind *GIVEN-ENVIRONMENT* when you
> reply to my messages with COMMON-WINDOWS-INSTALLATION. I'd like that it was
> SOME-LINUX-INSTALLATION. But in context of my work it can not be such.
That's what I would call a moving target. It seems like most of the
time when you try to install something on Windows (or even quite
frequently when you try to view something on the web), you get a
dialog box explaining that you are missing a
component/library/whatever. Your choices are then to either download
(or dig out the correct cd from one of the cd piles[1]) and install it,
or abort whatever you were trying to do at the moment.
Some of these requirements are much larger than a usable Lisp
development system.
Let's assume that we require a Lisp system to trim out the pieces you
don't expect to be using in the installed system (debugger and
compiler for instance). Can you extend the same requirements to GTK+
if the only reason for installing it on the host is that your
application is linked with it but only uses 5-10% of the library?
1. If you're lucky, newer versions of ActiveX, Acroreader and explorer
were included on the CD you tried to install the application from.
Coby Beck
"Erik Naggum" <er...@naggum.net> wrote in message
news:32098174...@naggum.net...
> * Aleksandr Skobelev <22...@mail.ru>
> You have exhausted my patience. You are here to troll and annoy people,
> not to learn anything new, not to listen to others but to insist that
> people think the way you do. This kind of arrogance is very annoying,
> but you only see yourself, so you do not notice anything else, anyway.
>
I disagree very strongly. This person has done nothing but ask reasonable
questions in a reasonable manner. That is not a troll. It is not his fault
that he walks a path this group has seen many times before.
He has respectfully acknowledged responses and advice and has been within his
rights to disagree/agree/take into consideration any and all replies.
> > words, words, words...
> > I have got only 2 replies relevant my request. Both senders haven't
> > required no any pieces information about my opinions. They just help me.
> > But not you, Erik...
>
> I have tried to figure out what you really need, not what you _believe_
> you need from a different value syste, and so have several other people,
> but you never get the hint. Stupid people do not generally find such
> quests for underlying assumptions and desires fruitful, but go blundering
> on about the things they think they must need because they are completely
> unaware of how they got to the point where they are, and thus cannot move
> anywhere else.
>
> Just go away, troll.
Please feel free to remain and ask any other questions.
> We should have known just by your question that you
> were trolling. It is just _too_ dumb to ask about size of executables to
> be a real and honest question.
>
Please define what you mean be "we". You most certainly do not speak for me.
Aleksandr Skobelev
> You have exhausted my patience. You are here to troll and annoy people,
> not to learn anything new, not to listen to others but to insist that
> people think the way you do. This kind of arrogance is very annoying,
> but you only see yourself, so you do not notice anything else, anyway.
>
>
> you need from a different value syste, and so have several other people,
> but you never get the hint. Stupid people do not generally find such
> quests for underlying assumptions and desires fruitful, but go blundering
> on about the things they think they must need because they are completely
> unaware of how they got to the point where they are, and thus cannot move
> anywhere else.
>
> Just go away, troll. We should have known just by your question that you
> were trolling. It is just _too_ dumb to ask about size of executables to
> be a real and honest question.
Poor Erik... :(
Are you really consider yourself as The Only True Last Great Programmer?
Of course, I will remain here. Because there are a lot of really clever
people. You are not among them. But I just will ignore all your moronic
messages. The traffic will be less, but a quote of good, constructive
messages will increase.
Go away you troll.
Wade Humeniuk
LWW dynamically links to the win32 libraries and has example code included
to use the openGL dlls. Also a LWW image can be delivered as a DLL which
third party or other LWW executables can dynamically link to.
Wade
"Aleksandr Skobelev" <22...@mail.ru> wrote in message
news:4rb7o9...@hermit.athome...
Greg Menke
> * Valeriy E Ushakov wrote:
> > This low level stuff has nothing to do with CL directly, but I just
> > want to show you that even at the bare iron level of "standalone-ness"
> > people actually deploy code in production (even in the flash!) with
> > debugging facilities built-in.
>
> It's always misleading to give examples from spacecraft because
> (quite recent I think, and one of the ones that didn't crash), which
> suffered from system crashes due to <something>. The thing ran some
> embedded OS - perhaps OS9? - and the people, being sensible, had left
> all the debugging tools there. The description I read was a bit vague
> but it sounded suspiciously as if they essentially logged in to the
> spacecraft and edited parameters interactively to fix the problem. I
> thought this was really cool. What was sad was that they (the NASA
> they'd done everything they needed to to make sure they could fix the
> bugs on the fly, while not missing the launch window due to testing).
If I recall correctly, the problem was a priority inversion in the
thread scheduling, a known bug, which was estimated to manifest itself
once in a time period approximately double the expected mission
duration. Naturally, it occured during the mission.
Whats <really> scary are bugs like what happened to the NEAR
spacecraft; they initiated a burn to insert the spacecraft into orbit
around Eros and it went completely offline. A couple days later, it
reset itself, re-oriented to Earth and the mission was able to resume,
requiring the satellite make another orbit around the Sun before
trying again, with resounding success. I can only imagine what the
NEAR team went through.
Gregm
Erik Naggum
> I disagree very strongly. This person has done nothing but ask
> reasonable questions in a reasonable manner. That is not a troll.
Watch his behavior when he is asked to consider other options than he
brings from his C++ background. Watch his _very_ strong need to go
personal when he is challenged.
> It is not his fault that he walks a path this group has seen many times
> before.
It _is_ his fault he fails to recognize that he does so after several
people try to communicate to him beyond his "I had this with C++, so I
need excatly the same thing in every other environment" stance.
I have actually tried to get this stupid troll to think beyond his very
limited vision of what he needs. His hostility in response to requests
for a deeper understanding of what he is after is indicative of a lack of
willingness to think about what he is really after, and _that_ suggests a
permanently limited vision, probably by will, and that is precisely what
a troll is.
However, _you_ are free to give him all he "needs", Coby. Do not expect
him to be satisfied with anything, _ever_. Trolls never are, remember?
> Please define what you mean be "we".
Christ, Coby, grow the hell up!
///
Thomas F. Burdick
> Lieven Marchand <m...@wyrd.be> writes:
>
> > A lot of CGIs have been written in Perl. When people test this, CLISP
> > starts up faster than Perl and is for a lot of things faster.
>
> I was surprised to read this and tested it on my laptop but I'm not
> convinced: I created two files - test.pl and test.lisp - that were
> both empty except for the shebang lines (#!/usr/bin/perl and
> #!/usr/bin/clisp), made them executable and got the following results:
I did a similar test a while ago and found CLISP to be (slightly)
faster at starting up (significantly faster at the sort of computation
I was doing, but that's a different story), and for what it's worth, I
was surprised too. After reading your post, I tried again, and found
that Perl indeed started up about 5x faster. Then I looked at my perl
version: 5.4.1. The last time I checked with something in the
5.00... area. I can't say I'm surprised to see this speedup. Given
that Perl is used so heavily for CGI scripting, optimizing for
start-up time was probably a good use of their developer time. I
guess what was once a surprising fact is now misinformation...too bad,
I got such satisfaction out of quoting it :)
Aleksandr Skobelev
me get a more clear picture.
Aleksandr
Duane Rettig
> Duane Rettig <du...@franz.com> wrote:
> > ...
> >
> > Thank you for finally giving us this definition. Incidentally, by this
> > definition most C programs are not standalone. They do _not_ link in
> > their library (libc.so) statically, and thus cannot run without library
> > support. It is possible on some systems to link a program completely
> > statically (e.g. Solaris has a -Bstatic option), but it gets harder
> > and harder all the time. In fact, many third-party vendors provide
> > only .so libraries, and not .a files for static linking.
> >
>
> C library included in distributives of all modern operating systems I
> know. If any library included in distributive and installed by default it
> is definitly part of whole OS and any dependencies from such library can
> be consider like dependencies of OS. At least in my case this is so.
Ah, so you want to be able to distrubute parts of a program, with
the runtime portion already installed on the machine? Thank you
for giving us yet another piece of this puzzle.
> > ...
> >
> > In this entire thread you have not told us yet what you are trying
> > to do, and what your goals are in limiting the size of CL images.
>
> Excuse me, Duane, I definitely have told. It might be in several messages
> so it could require some work to collect all pieces together.
You are excused, but I must apologize, because I'm not intelligent
enough to piece together this whole puzzle. What has me baffled are
all of the little missing pieces I have to supply by reading your
mind. I'm not very good at that.
> > In my experience, there are only a couple of reasons why people want
> > to limit a CL size:
> >
> > - They have limited transfer capability. Usually the internet or
> > the size of floppy-disks limits what can be transferred of a program.
>
> Yes, Internet is one of most critical.
OK, another piece of the puzzle...
> > However, a lisp "program" is really a series of functions, which can
> > be contained in a source or .fasl file. Others have mentioned this
> > before. I can write a trivial lisp program and give its fasl file a
> > magic-number that allows the program to run the lisp that is on the
> > system and to load in its own fasl file and run it. Such a program
> > can be only a few hundred bytes. We lispers seldom talk about such
> > programs because it is too trivial, and we tend to think of it as
> > cheating (i.e. it does not really show how much actual memory the
> > program is using when it is running).
>
> As far as I undersatnd, this is required from user to have preinstalled
> Lisp system. Am I wrong?
You are not wrong, just as you understand that C runtime libraries
must be pre-installed. Also, if you do much web-browsing, you have no
doubt visited some sites that say "this site uses xyz presenting-engine
which you do not have installed on your machine. Download now?..."
at which point you will make a decision whether or not to do the
download. It should not necessarily have to be any different in Lisp.
> In MY CURRENT SITUATION is it impossible.
I have trouble parsing this statement. It is either a question or a
statement, but I do not know which. So I will treat it as both, one
at a time, since the answer is similar:
If read as: "In MY CURRENT SITUATION is it impossible?"
No, it should be entirely possible.
If read as: "In MY CURRENT SITUATION it is impossible."
If this is a statement, then I think that the only possible way that
this could be true is if you have no disk space and no money to buy
a new disk.
> By the way, if, for example, I buy ACL, develope some program with it then
> will I be able to distribute part, developed by me, separately from needed
> ACL parts?
Of course. Why would you think differently?
In fact, if you are not going to charge for your program, you could
distribute the Allegro CL runtime part for free as well; see
http://www.franz.com/downloads/license.php3
> > You did mention wanting to be able to have lisps loaded on machines
> > so that such small programs can be transferred via internet.
> > But you do not state why; are you planning to sell products to
> > customers who will not want to install a lisp system on their
> > machines?
> > ...
> > So now for my question: Given the above background, can you explain
> > to me a little of what you are trying to _do_, and help me to
> > understand the reason or reasons why you want your CL system to
> > be a specific size?
> >
>
> The users and customers is not the same in this case. This system will
> contain client's programs which intendent to be download and used by,
> theoretically, any user in Internet. There also some parts that works
> as a NT service and web-server.
Well, I suppose that this qualifies as being more information, but you
still haven't made the connection for me to help me to understand why
this has anything to do with the size of a lisp program or with standalone
executables.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
Boris Schaefer
| So, I'd like to offer you replace term "standalone executable" by
| "RUNNABLE-IN-GIVEN-ENVIRONMENT" and bind *GIVEN-ENVIRONMENT* when
| you reply to my messages with COMMON-WINDOWS-INSTALLATION. I'd like
| that it was SOME-LINUX-INSTALLATION. But in context of my work it
| can not be such.
Please define a common Windows installation. As it happens, almost
every time I download something from the web, I also have to download
some "common" Windows libraries as well (like for example a new
version of DirectX, or what have you). Since I don't download Windows
stuff that often, this really happens very often.
To be fair, this happens to me with Linux as well. I sometimes buy a
new distribution just to stop that annoying downloading of half the
system, just because I want one new package.
So, please, what _is_ a common Windows installation?
Boris
--
bo...@uncommon-sense.net - <http://www.uncommon-sense.net/>
The things that interest people most are usually none of their business.
Israel Raj T
One that crashes regularly ?
Aleksandr Skobelev
> Aleksandr Skobelev <22...@mail.ru> writes:
>
>> Duane Rettig <du...@franz.com> wrote:
>>
>> C library included in distributives of all modern operating systems I
>> know. If any library included in distributive and installed by default it
>> is definitly part of whole OS and any dependencies from such library can
>> be consider like dependencies of OS. At least in my case this is so.
>
> Ah, so you want to be able to distrubute parts of a program, with
> the runtime portion already installed on the machine? Thank you
> for giving us yet another piece of this puzzle.
I'm sorry that I could explain it before more clearly. That is what in one
of my previous messages I wrote that I would preferred Lisp systems
preinstalled on a most machines.
> ...
>
> You are not wrong, just as you understand that C runtime libraries
> must be pre-installed. Also, if you do much web-browsing, you have no
> doubt visited some sites that say "this site uses xyz presenting-engine
> which you do not have installed on your machine. Download now?..."
> at which point you will make a decision whether or not to do the
> download. It should not necessarily have to be any different in Lisp.
>
Yes, sometimes such things can happen. In such situation I just take
decision in depend on the size of the download. If the size more ~500 kB
then I, probably go in another place. Of course, everybody has his/her own
limit for taken such decision. There are of couse persons for which such
limit can achieve several tens MBytes.
>> In MY CURRENT SITUATION is it impossible.
>
> I have trouble parsing this statement. It is either a question or a
> statement, but I do not know which. So I will treat it as both, one
> at a time, since the answer is similar:
>
> If read as: "In MY CURRENT SITUATION is it impossible?"
>
> No, it should be entirely possible.
>
> If read as: "In MY CURRENT SITUATION it is impossible."
>
> If this is a statement, then I think that the only possible way that
> this could be true is if you have no disk space and no money to buy
> a new disk.
>
No, Duane. You are wrong. Please, try to understand. This "size
limitation" that, of course, doesn't have an absolute character, also
correlate with a "human factor" of my bosses and coworkers. If I start my
own project (what I thinking about) then in such new "my current
sutuation" I prefer CL. But now if I reimplement silently some program in
Lisp and present it my boss, the first thing he, I belive, will be "Hey!
Why has the size increased in ten times?". And, very likely, I will get a
problems or just will drop my work in dustbin.
I'd like to impress it "impossible in _MY_ _CURRENT_ situation". It does
NOT mean "impossible for me (or somebody else) forever and everywhere".
>> By the way, if, for example, I buy ACL, develope some program with it then
>> will I be able to distribute part, developed by me, separately from needed
>> ACL parts?
>
> Of course. Why would you think differently?
Well... I don't know why. I have decided to make my knowledge more
accurate. Let me ask you yet another question. Could you describe it a
little detailed, how much is size of exe-file and dlls in the cases of
very simple "hello-world" and more complex programs?
But I beg you, please, if you don't want to ask me on this question, just
ignore it.
>
> In fact, if you are not going to charge for your program, you could
> distribute the Allegro CL runtime part for free as well; see
> http://www.franz.com/downloads/license.php3
Excuse me, but this URL refers only to lisense for trial version.
>
> Well, I suppose that this qualifies as being more information, but you
> still haven't made the connection for me to help me to understand why
> this has anything to do with the size of a lisp program or with standalone
> executables.
>
To speak my mind, I don't understand very well what you are meaning by
"make the connection for you". Really, I have asked for some information
and now have more or less clear picture. If you give me yet another piece
of information about ACL to my great pleasure, this picture will be more
clear. But, I'd like to say that I consider this information as "an
auxilary information for thinking" (if I can speak so in English) but not
a "critical part of something". In the same time, I am ready to continue
our conversation on this topic and will try to reply on all yours questions.
Aleksandr
Aleksandr Skobelev
> every time I download something from the web, I also have to download
> some "common" Windows libraries as well (like for example a new
> version of DirectX, or what have you). Since I don't download Windows
> stuff that often, this really happens very often.
In context of my request I think it can be just a Windows 98 default
installation. I think we can also add MS Word.
>
> To be fair, this happens to me with Linux as well. I sometimes buy a
> new distribution just to stop that annoying downloading of half the
> system, just because I want one new package.
This is because you don't do upgrade regulary. :)
Aleksandr
Ola Rinta-Koski
> sutuation" I prefer CL. But now if I reimplement silently some program in
> Lisp and present it my boss, the first thing he, I belive, will be "Hey!
> Why has the size increased in ten times?".
As opposed to "Does this work at all?" or "Does this improve things?"
I guess?
Do you truly believe the problem is with Lisp here?
--
Ola Rinta-Koski o...@cyberell.com
Cyberell Oy +358 41 467 2502
Rauhankatu 8 C, FIN-00170 Helsinki, FINLAND www.cyberell.com
Erik Naggum
> Do you truly believe the problem is with Lisp here?
Pertinent question. The answer is that this dude really is trolling.
///
Duane Rettig
> Duane Rettig <du...@franz.com> wrote:
> > Aleksandr Skobelev <22...@mail.ru> writes:
> >
> >> Duane Rettig <du...@franz.com> wrote:
> >>
> >> C library included in distributives of all modern operating systems I
> >> know. If any library included in distributive and installed by default it
> >> is definitly part of whole OS and any dependencies from such library can
> >> be consider like dependencies of OS. At least in my case this is so.
> >
> > Ah, so you want to be able to distrubute parts of a program, with
> > the runtime portion already installed on the machine? Thank you
> > for giving us yet another piece of this puzzle.
>
> I'm sorry that I could explain it before more clearly. That is what in one
> of my previous messages I wrote that I would preferred Lisp systems
> preinstalled on a most machines.
Yes, of course, it would be nice if lisps could be installed on all
machines. But they are not, and so we must live with that.
Incidentally, when Steve Jobs started his second company, NeXT,
he placed a copy of Allegro CL (version 3.1, I believe) on every
box. Too bad his box was 10 years ahead of its time, and thus
not profitable...
> > ...
>
> >
> > You are not wrong, just as you understand that C runtime libraries
> > must be pre-installed. Also, if you do much web-browsing, you have no
> > doubt visited some sites that say "this site uses xyz presenting-engine
> > which you do not have installed on your machine. Download now?..."
> > at which point you will make a decision whether or not to do the
> > download. It should not necessarily have to be any different in Lisp.
> >
>
> Yes, sometimes such things can happen. In such situation I just take
> decision in depend on the size of the download. If the size more ~500 kB
> then I, probably go in another place. Of course, everybody has his/her own
> limit for taken such decision. There are of couse persons for which such
> limit can achieve several tens MBytes.
Ah, another piece of the puzzle: a number: approximately 500 kB. Of
course, you have stated this number as the cutoff point for how much
you are willing to download yourself, but you didn't say whether this is
related to how much, on the average, any of your users are willing to
download. Because you have not supplied me with that information, I will
assume approximately 500 kB and you can correct me if the number is
different.
I think we agree that everyone's comfort limit is different, and because
of this we try hard to make the downloads as small as possible. And
although some people will gladly download tens of megabytes, we try
not to assume this magnitude of size when preparing our downloads.
> >> In MY CURRENT SITUATION is it impossible.
> >
> > I have trouble parsing this statement. It is either a question or a
> > statement, but I do not know which. So I will treat it as both, one
> > at a time, since the answer is similar:
> >
> > If read as: "In MY CURRENT SITUATION is it impossible?"
> >
> > No, it should be entirely possible.
> >
> > If read as: "In MY CURRENT SITUATION it is impossible."
> >
> > If this is a statement, then I think that the only possible way that
> > this could be true is if you have no disk space and no money to buy
> > a new disk.
> >
>
> No, Duane. You are wrong. Please, try to understand. This "size
> limitation" that, of course, doesn't have an absolute character, also
> correlate with a "human factor" of my bosses and coworkers. If I start my
> own project (what I thinking about) then in such new "my current
> sutuation" I prefer CL. But now if I reimplement silently some program in
> Lisp and present it my boss, the first thing he, I belive, will be "Hey!
> Why has the size increased in ten times?". And, very likely, I will get a
> problems or just will drop my work in dustbin.
>
> I'd like to impress it "impossible in _MY_ _CURRENT_ situation". It does
> NOT mean "impossible for me (or somebody else) forever and everywhere".
We are simply dealing with a different definition of impossible. I would
have understood your meaning if instead you had said something like "In my
current situation, I am faced with constraints that make it hard for me to
make the decision I would like to make". Such a statement, followed by
some description of the constraints, would have become a good starting
point toward a problem description. You would find that in this newsgroup,
when we have a good problem description, we are more than willing to help
you solve the problem, or to restate the problem in a way that you can
solve the problem yourself.
I'd like to revisit part of the previous paragraph:
> But now if I reimplement silently some program in
> Lisp and present it my boss, the first thing he, I belive, will be "Hey!
> Why has the size increased in ten times?". And, very likely, I will get a
> problems or just will drop my work in dustbin.
There are several problems with this statement:
- You are talking of implementing something silently. This is a very
quick way to get yourself into trouble. Now, I know that sometimes
bosses can be unreasonable, especially when it comes to using Lisp,
but it is is very certain that a boss would be well-justified in
firing you if you were doing something behind his back, especially
if he had told you explicitly not to do it the way you did.
However, I do not know what constraints or freedoms your boss has
placed on you, because you have not told me. Another missing puzzle
piece.
- You are talking about a 10x increase, but you have not indicated why
your boss would care, or why your boss would even be likely to notice.
Is he going to look at process size, or is he going to look at program
startup times?
- You are talking about your work being trashed. Has such a thing
happened to you before? I find that when I perform an experiment
that fails, I tend to trash that experiment myself, and my boss
never has to do the trashing for me. If it comes to my boss asking
me what I've been doing with my time, I then say "I tried an
experiment, and it failed". And unless your failure rate for such
experiments is very high, you can usually do this kind of thing
once in a while.
> >> By the way, if, for example, I buy ACL, develope some program with it then
> >> will I be able to distribute part, developed by me, separately from needed
> >> ACL parts?
> >
> > Of course. Why would you think differently?
>
> Well... I don't know why. I have decided to make my knowledge more
> accurate. Let me ask you yet another question. Could you describe it a
> little detailed, how much is size of exe-file and dlls in the cases of
> very simple "hello-world" and more complex programs?
>
> But I beg you, please, if you don't want to ask me on this question, just
> ignore it.
Well, first there is yet another missing puzzle piece; you don't say
what platform you are on. However, I think I have figured this one
out; and will assume that you are on Windows, because you talk of
exe-file and dlls.
The Trial version of Allegro CL for Windows includes the full IDE and
interface builder, and is about a 1.9 Mb download. Larger than your
500 kB cutoff, true, but much smaller than the 10x figure you were
quoting. And if you wanted to get smaller, you could certainly create
a runtime using our Enterprise product that is around a megabyte, which
you could then compress to 600 - 700 kB.
> > In fact, if you are not going to charge for your program, you could
> > distribute the Allegro CL runtime part for free as well; see
> > http://www.franz.com/downloads/license.php3
>
> Excuse me, but this URL refers only to lisense for trial version.
Right. I am not a salesperson, so I am not trying to sell you software.
You can, however, buy our Enterprise Edition and distribute runtimes
of your application for which you collect money.
> > Well, I suppose that this qualifies as being more information, but you
> > still haven't made the connection for me to help me to understand why
> > this has anything to do with the size of a lisp program or with standalone
> > executables.
> >
>
> To speak my mind, I don't understand very well what you are meaning by
> "make the connection for you". Really, I have asked for some information
> and now have more or less clear picture. If you give me yet another piece
> of information about ACL to my great pleasure, this picture will be more
> clear. But, I'd like to say that I consider this information as "an
> auxilary information for thinking" (if I can speak so in English) but not
> a "critical part of something". In the same time, I am ready to continue
> our conversation on this topic and will try to reply on all yours questions.
The reason why you consider such information auxilliary is because you
already see your whole picture. However, nobody else who is reading
this thread knows any more about your situation than what they can draw
from the information you have provided, and so such information is not
auxilliary to us, but crucial in understanding your situation.
People on this newsgroup respond extremely well to a well-formed
problem that includes good background. However, I would
characterize your initial post as the _answer_ to a problem
(i.e. as if to say "I need lisp to be small"), without stating
the actual problem (e.g. "I have xxx situation and I am trying
to to yyy, but am faced with the following constraints ...")
and _also_ without even qualifying the answer (i.e. how small is
small?) It is very hard to answer such an answer.
Lieven Marchand
> Lieven Marchand <m...@wyrd.be> writes:
>
> > A lot of CGIs have been written in Perl. When people test this, CLISP
> > starts up faster than Perl and is for a lot of things faster.
>
> I was surprised to read this and tested it on my laptop but I'm not
> convinced: I created two files - test.pl and test.lisp - that were
> both empty except for the shebang lines (#!/usr/bin/perl and
> #!/usr/bin/clisp), made them executable and got the following results:
>
> edi@bird:~ > time for i in 1 2 3 4 5; do for j in 1 2 3 4 5; do for k in 1 2 3 4 5; do ./test.lisp; done; done; done
> real 0m3.503s
> user 0m2.330s
> sys 0m1.180s
>
> edi@bird:~ > time for i in 1 2 3 4 5; do for j in 1 2 3 4 5; do for k in 1 2 3 4 5; do ./test.pl; done; done; done
> real 0m0.710s
> user 0m0.400s
> sys 0m0.290s
>
> Is something wrong with my testing methodology or did you mean
> something different? (I'm using a more or less stock SuSE 7.2 -
> kernel 2.4.4, perl 5.6.0, clisp 2000.03.06-56 - if that matters.)
I was actually misremembering
where Christopher Browne comes to the result that Perl is faster than
CLISP but CLISP is faster than Python.
Anyway, the main point stands that CLISP starts up fast enough to make
CGI work feasible.
--
Lieven Marchand <m...@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words
Wade Humeniuk
I am of the mind that I give the information I think the person needs and
not be overly critical. Executable size was an issue for me, but I have got
over it. Now I focus on ease of development, "is it good enough", and
functionality. You may come to the same conclusion, or, maybe not.
Executable size is a fact, but one has to remember that a lot of the LWW CL
core system is delivered with each and every exe. This is opposed to say,
Java, where one has to install a Java runtime or development environment,
(which is essentially what is delivered in the Lisp Executable). But no one
complains (I think) about installing the JRE.
Just the facts, sir, just the facts.
Wade.
PS I think that ACL now has a DLL library for most of the system and
delivery is now limited to a small startup program. I may be mistaken,
maybe Franz could comment.
"Aleksandr Skobelev" <22...@mail.ru> wrote in message
news:0de9o9...@hermit.athome...
Aleksandr Skobelev
> ... We are simply dealing with a different definition of impossible. I
> would have understood your meaning if instead you had said something
> like "In my current situation, I am faced with constraints that make it
> hard for me to make the decision I would like to make". Such a
> statement, followed by some description of the constraints, would have
> become a good starting point toward a problem description. You would
> find that in this newsgroup, when we have a good problem description, we
> are more than willing to help you solve the problem, or to restate the
> problem in a way that you can solve the problem yourself.
>
exist? So I need not solve one. This problem definitly could take place
if I would really tried to rewrite in Lisp and after all understood that
it could be accepted because of some difference in characteristics between
old and new implementation. I'd prefer that we all understand this and
that I am not waiting from you any help in this thread, but just
explaining you my reasons, circumstances, conclusions concern my message
about size of executable.
>
> - You are talking of implementing something silently. This is a very
> quick way to get yourself into trouble. Now, I know that sometimes
> bosses can be unreasonable, especially when it comes to using Lisp,
> but it is is very certain that a boss would be well-justified in
> firing you if you were doing something behind his back, especially
> if he had told you explicitly not to do it the way you did.
> However, I do not know what constraints or freedoms your boss has
> placed on you, because you have not told me. Another missing puzzle
> piece.
There is not any risk I think. First, I'd say my group manager (? I don't
know how to call the boss just above me) about I was going to do. He
entrust me and accept my offers as a rule. Second, I'd be doing it in my
spare time so it'd affect on other work.
> - You are talking about a 10x increase, but you have not indicated why
> your boss would care, or why your boss would even be likely to notice.
> Is he going to look at process size, or is he going to look at program
> startup times?
How meticulous are you. :) I often use e-mail to send my compiled program
to my group manager. He regulary send all bunch of programs (from me and
my coworkers) to a head office also through e-mail. We both have 28 kb
Internet channels.
> - You are talking about your work being trashed. Has such a thing
> happened to you before? I find that when I perform an experiment
> that fails, I tend to trash that experiment myself, and my boss
> never has to do the trashing for me. If it comes to my boss asking
> me what I've been doing with my time, I then say "I tried an
> experiment, and it failed". And unless your failure rate for such
> experiments is very high, you can usually do this kind of thing
> once in a while.
>
I wanted to say only that I'd wasted time on a useless work.
>
> ...
>
> The reason why you consider such information auxilliary is because you
> already see your whole picture. However, nobody else who is reading
> this thread knows any more about your situation than what they can draw
> from the information you have provided, and so such information is not
> auxilliary to us, but crucial in understanding your situation.
To speak my mind, I can imagine very hard that this branch of the thread
is interesting anybody else but us. So, I'd like to offer you to continue
our conversation with e-mail.
>
> People on this newsgroup respond extremely well to a well-formed
> problem that includes good background. However, I would
> characterize your initial post as the _answer_ to a problem
> (i.e. as if to say "I need lisp to be small"), without stating
> the actual problem (e.g. "I have xxx situation and I am trying
> to to yyy, but am faced with the following constraints ...")
> and _also_ without even qualifying the answer (i.e. how small is
> small?) It is very hard to answer such an answer.
In spite of, I really don't need help now (as I wrote before), could you
please explain me how can you help me in solving of the such problem. I
think, I give you enough information, and you being a very smart man can
easily describe me one or may be several possible desisions. It would be
intereseting for me could be give me some glue to understand what kind of
help I can get in the analogous situations in a future.
Aleksandr
Dr. Edmund Weitz
> Anyway, the main point stands that CLISP starts up fast enough to make
> CGI work feasible.
This is definitely true.
Paul Wallich
<22...@mail.ru> wrote:
>How meticulous are you. :) I often use e-mail to send my compiled program
>to my group manager. He regulary send all bunch of programs (from me and
>my coworkers) to a head office also through e-mail. We both have 28 kb
>Internet channels.
If that's true, at least initially you have not a whole lot of trouble. If you
once bite the bullet of installing a lisp (similar to installing perl or a C
compiler) at these locations the .fasl files will be tiny.
paul
Boris Schaefer
| Boris Schaefer <bo...@uncommon-sense.net> wrote:
|
| > Please define a common Windows installation. As it happens, almost
| > every time I download something from the web, I also have to download
| > some "common" Windows libraries as well (like for example a new
| > version of DirectX, or what have you). Since I don't download Windows
| > stuff that often, this really happens very often.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Probably everybody understood, although I was less than clear. Of
course that should read: "I don't download Windows stuff that
often, and it happens almost every time."
| [ Please define a common Windows installation. ]
|
| In context of my request I think it can be just a Windows 98 default
| installation. I think we can also add MS Word.
If that's the case, then there probably were not many stand-alone
executables developed in the last 2 years (under your definition of
stand-alone executable, given upthread). At least I haven't seen
many. YMMV, of course.
When have you last installed some _current_ package on a bare-bones
Windows 98 and you didn't need some newer version of some library?
(And silently including that newer library in the installation package
is "cheating". Remember, your definition of stand-alone executable.)
Boris
Prediction is very difficult, especially of the future.
-- Niels Bohr
cbbr...@acm.org
> I was actually misremembering
>
> http://groups.google.com/groups?q=clisp+perl+time+group:comp.lang.lisp&hl=en&scoring=r&rnum=2&selm=slrn8bs10k.pe.cbbrowne%40knuth.brownes.org
> where Christopher Browne comes to the result that Perl is faster
> than CLISP but CLISP is faster than Python.
Note that I observed that the test "shows how long it takes to do
*NOTHING* with all of these languages."
FYI, a recent run on a 600MHz Duron shows that I can spawn 100 CMU/CL
instances in about 7.5 seconds, and that the same with CLISP takes
about 5.5 seconds.
Again, a test of how long it takes to do *NOTHING* isn't
_spectacularly_ interesting, although it is encouraging to the notion
of considering these as possible options for running CGI scripts that
often don't do MUCH work...
> Anyway, the main point stands that CLISP starts up fast enough to
> make CGI work feasible.
That's fair.
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://www.cbbrowne.com/info/
Referring to undocumented private communications allows one to claim
virtually anything: "we discussed this idea in our working group last
year, and concluded that it was totally brain-damaged".
-- from the Symbolics Guidelines for Sending Mail
Espen Vestre
> If that's true, at least initially you have not a whole lot of trouble. If you
> once bite the bullet of installing a lisp (similar to installing perl or a C
> compiler) at these locations the .fasl files will be tiny.
installing lisp is usually easier than installing perl. Another option
to remember is that you can almost always reload a new version of
(parts of) your application into a running image. So you can send the
self-contained application once, and then send upgrades as fasl-files.
--
(espen)
Aleksandr Skobelev
> Aleksandr Skobelev <22...@mail.ru> writes:
>
> | Boris Schaefer <bo...@uncommon-sense.net> wrote:
> |
> | > Please define a common Windows installation. As it happens, almost
> | > every time I download something from the web, I also have to download
> | > some "common" Windows libraries as well (like for example a new
> | > version of DirectX, or what have you). Since I don't download Windows
> | > stuff that often, this really happens very often.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Probably everybody understood, although I was less than clear. Of
> course that should read: "I don't download Windows stuff that
> often, and it happens almost every time."
>
> | [ Please define a common Windows installation. ]
> |
> | In context of my request I think it can be just a Windows 98 default
> | installation. I think we can also add MS Word.
>
> If that's the case, then there probably were not many stand-alone
> executables developed in the last 2 years (under your definition of
> stand-alone executable, given upthread). At least I haven't seen
> many. YMMV, of course.
Yes, there were not many such executables. But they exist and can not be
just dropped.
>
> When have you last installed some _current_ package on a bare-bones
> Windows 98 and you didn't need some newer version of some library?
> (And silently including that newer library in the installation package
> is "cheating". Remember, your definition of stand-alone executable.)
No objections, there is a lot additional libraries might be required in
some and probably most cases. I wanted to know how much will be minimal
part added by commercial Lisp realization.
Aleksandr
Aleksandr Skobelev
> You are welcome,
>
> I am of the mind that I give the information I think the person needs and
> not be overly critical. Executable size was an issue for me, but I have got
> over it. Now I focus on ease of development, "is it good enough", and
> functionality. You may come to the same conclusion, or, maybe not.
> Executable size is a fact, but one has to remember that a lot of the LWW CL
> core system is delivered with each and every exe. This is opposed to say,
> Java, where one has to install a Java runtime or development environment,
> (which is essentially what is delivered in the Lisp Executable). But no one
> complains (I think) about installing the JRE.
Yes. Lisp, might be, also needs its own Sun.
>
> Just the facts, sir, just the facts.
This costs much. There was so much emotions in the most of other replies.
>
> Wade.
>
> PS I think that ACL now has a DLL library for most of the system and
> delivery is now limited to a small startup program. I may be mistaken,
> maybe Franz could comment.
>
I have asked Duane Rettig in this thread about it. Here my question and
his reply:
== begin of quote ==
> By the way, if, for example, I buy ACL, develope some program with it
> then will I be able to distribute part, developed by me, separately from
> needed ACL parts?
Of course. Why would you think differently?
In fact, if you are not going to charge for your program, you could
distribute the Allegro CL runtime part for free as well; see
http://www.franz.com/downloads/license.php3
== end of quote ==
To speak honestly, I don't sure now that we understood well each other
here and the answer he gave me corresponded to what I thought about.
Aleksandr
Aleksandr Skobelev
I have installed C compiler only on my own machine and have't installed it
in Canada and Hong-Kong. By the way, if I would use commercial Lisp in
commercial purposes then should I pay 'distribution fees' for each
distribution of parts of a Lisp system in the case of statically or
dynamically linkage with these parts?
Ed L Cashin
...
> But no one complains (I think) about installing the JRE.
I do. Specifically, I complain that too many software vendors (I'm
thinking of non-free software) who has some java software in their
product bundles an entire JRE with their product.
--
--Ed Cashin integrit file-verification system:
eca...@terry.uga.edu http://integrit.sourceforge.net/
Note: If you want me to send you email, don't munge your address.