At least once a month, someone asks how to deliver a "standalone"
executable of a Lisp application. It's often his first post, and often
his last.
I suspect that a lot of these people have written small applications and
want to share them on the net. They're likely to be some of the most
effective proselytizers of Lisp, introducing compelling apps to others,
some of whom will get the source and become lispers themselves. What do
they hear?
- You can't do that
- You can only do it with the commercial lisps
- You can do it, but the binary will be 11MB
And those are just the serious answers. Some comedians try to convince
the OP that he should be comparing the download size with all the C
libraries that his users wouldn't have to download if the app was in C.
Others suggest that what he really wants is a batch file, a lisp
environment and a hassle, um, fasl file.
Coders might not have that much web space or transfer available. End
users might not want an 11MB download. Even though that's only two or
three mp3 tracks, I think people expect a certain amount of
functionality out of code that size, and a minor app is likely to be
viewed as hopelessly bloated.
Maybe it would be instructive to look at how other languages handled
this chicken-and-egg problem:
Perl started small (even Perl 4 was only a few hundred k) and
ingratiated itself with the sysadmin crowd. It didn't bulk up until it
was in the indispensable category.
Sun sued Microsoft to stop the distribution of a buggy and incompatible
Java, tried to get the court to compel Microsoft to distribute an
updated version, and paid HP and others (presumably) lots so they would
distribute Java with new PCs.
Java, Macromedia Flash, Realaudio and other applets benefit from
Netscape's plugin paradigm - if the end user doesn't have the plugin,
the content creator can direct the browser to get it from the plugin
creator's website. The end user only downloads it once, the content
creator doesn't pay for the bandwidth, and the process is sometimes
painless.
My reading of the Lisp 1.5 manual suggests that users demanded and got
ways to manually remove parts of lisp even then, though the scarce
resources were RAM and tape capacity.
Yes, if I were more skilled I'd understand
http://www.unlambda.com/lispm/explorer-source/explorer-lispm-sources/band-tools/tree-shake.lisp
and hack it into CMUCL. As it is, all I can do is suggest and hope and wait.
I think that the community is turning away trend setters and
influencers, precisely the people it needs, with its attitude of "If you
want to eat hippopotamus, you've got to pay the freight." They come,
they're mocked and they go away again, to continue dining on python,
camel and java.
--
Cameron MacKinnon
Toronto, Canada
"I am the Lorax. I speak for the tree shakers."
Cameron MacKinnon <··········@clearspot.net> writes:
> At least once a month, someone asks how to deliver a "standalone"
> executable of a Lisp application. It's often his first post, and often
> his last.
>
> I suspect that a lot of these people have written small applications and
> want to share them on the net.
Where did you get that idea? If they'd written small applications
they wanted to share, don't you think they might mention it, at least
in passing?
This is a potential market for Lisp, nowadays, and there are good,
low-cost options here: OpenMCL, ECL, Corman, MCL, and CLISP. Speaking
of CLISP, you can strip it down < 1.0Mb if you need a Lisp in a
constrained space. It works nicely. If anyone asks, "How do I
deliver my app that I have 3/4 developed?" They'll get good advice.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@famine.OCF.Berkeley.EDU>, Thomas F. Burdick
<···@famine.OCF.Berkeley.EDU> wrote:
> Cameron MacKinnon <··········@clearspot.net> writes:
>
> > At least once a month, someone asks how to deliver a "standalone"
> > executable of a Lisp application. It's often his first post, and often
> > his last.
> >
> > I suspect that a lot of these people have written small applications and
> > want to share them on the net.
>
> Where did you get that idea? If they'd written small applications
> they wanted to share, don't you think they might mention it, at least
> in passing?
>
> This is a potential market for Lisp, nowadays, and there are good,
> low-cost options here: OpenMCL, ECL, Corman, MCL, and CLISP. Speaking
> of CLISP, you can strip it down < 1.0Mb if you need a Lisp in a
> constrained space. It works nicely. If anyone asks, "How do I
> deliver my app that I have 3/4 developed?" They'll get good advice.
Why would a fledgling CL developer investigate how to deliver an app
only after developing it that far? That would be poor planning on her
part. I suspect that most potential app developers would check means of
delivery even before beginning development on their apps.
Casual empiricism: Most questions I've seen in the c.l.* hierarchy
w.r.t. delivering an app appear to be by someone who has played with
the language and is excited enough to contemplate developing her first
app in that language.
Michael
Thomas F. Burdick wrote:
> This is a potential market for Lisp, nowadays, and there are good,
> low-cost options here: OpenMCL, ECL, Corman, MCL, and CLISP. Speaking
> of CLISP, you can strip it down < 1.0Mb if you need a Lisp in a
> constrained space. It works nicely. If anyone asks, "How do I
> deliver my app that I have 3/4 developed?" They'll get good advice.
Would you mind terribly muvh to please explain how to do this? I assume
that you are talking about Common Lisp? I have versions for both Windows
and Linux and really would appreciate some information about this.
Regards
Pieter
Pieter <·······@lynxgeo.com> writes:
> Thomas F. Burdick wrote:
> > This is a potential market for Lisp, nowadays, and there are good,
> > low-cost options here: OpenMCL, ECL, Corman, MCL, and CLISP. Speaking
> > of CLISP, you can strip it down < 1.0Mb if you need a Lisp in a
> > constrained space. It works nicely. If anyone asks, "How do I
> > deliver my app that I have 3/4 developed?" They'll get good advice.
>
> Would you mind terribly muvh to please explain how to do this? I assume
> that you are talking about Common Lisp? I have versions for both Windows
> and Linux and really would appreciate some information about this.
All of the Lisps listed above are Common Lisps. CLISP is a very
portable, byte-compiled implementation of CL. I've delivered a
smallish application using CLISP; I did a full CLISP build telling gcc
to optimize for size, stripped the resulting binary, and delivered a
system based on that and a normal CLISP core file. IIRC, the base
system was 800k or so on Linux/x86.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Erik Winkels
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <87ektcndt1.fsf@xs4all.nl>
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
>
> I've delivered a smallish application using CLISP; I did a full
> CLISP build telling gcc to optimize for size, stripped the resulting
> binary, and delivered a system based on that and a normal CLISP core
> file. IIRC, the base system was 800k or so on Linux/x86.
Hey, that fits on a funny looking CD!
Pieter <·······@lynxgeo.com> writes:
> Thomas F. Burdick wrote:
>> This is a potential market for Lisp, nowadays, and there are good,
>> low-cost options here: OpenMCL, ECL, Corman, MCL, and CLISP. Speaking
>> of CLISP, you can strip it down < 1.0Mb if you need a Lisp in a
>> constrained space. It works nicely. If anyone asks, "How do I
>> deliver my app that I have 3/4 developed?" They'll get good advice.
>
> Would you mind terribly muvh to please explain how to do this? I assume
> that you are talking about Common Lisp? I have versions for both Windows
> and Linux and really would appreciate some information about this.
If you are wondering about GNU CLISP, the procedure(s) for delivery
applications are explained in the implementation notes document
included in the system.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
I think the fundemental problem is that a lot of Lisp'ers don't want
to integrate with the rest of the C-using world. They see the standard
Lisp runtime model to be superior. In that, they have an excellent
point, but also miss the realities of the market. The market has
settled on "the way things are." You can either lament it in
perpetuity, or adapt to it. Runtimes are just hard to sell. Even
*Microsoft* is having a hard time convincing everyone to download the
.NET framework to use .NET apps! If CMUCL spit out a small binary that
linked with "libcmucl.so" or "cmucl.dll" end-user Lisp apps would
become much more palatable. It doesn't matter if the binary is 500KB
but libcmucl.dll is 11.5MB --- the difference in perception is huge.
Another part of the problem is that, for the markets where CL is used
right now, distribution really isn't a factor. Not a whole lot of
commodity, end-user apps are written in CL. I get the impression that
many Lisp'ers are perfectly fine with this, and really don't care if
Lisp sees more widespread usage. However, today is a better day for
Lisp in the mainstream than any other in recent memory. People are
actually paying attention to more than just C and C++. Java and C#
have both come along and (especially the latter) reintroduced people
to some good Lisp ideas. Perl, Python, Ruby, etc, are getting very
popular, and are turning on a lot of people to dynamic typing. Many of
the old arguments against Lisp (its slow, memory-hungry, etc) are
easier to refute not just because of better compilers, but because the
competition has gotten slower. A good, natively-compiled Lisp program
can be a good bit faster and more memory-efficient than a Java
program. Now isn't that a great argument? Lisp does more than Java, is
more productive than Java, and well, its faster too! That might not
lead to Lisp world domination, but might expand the Lisp userbase
quite a bit, and bring with it the niceities that come with popularity
--- better/more bindings, more libraries for new things, better
implementations, etc.
Rayiner Hashem <·······@mindspring.com> wrote:
+---------------
| ... If CMUCL spit out a small binary that
| linked with "libcmucl.so" or "cmucl.dll" end-user Lisp apps would
| become much more palatable. It doesn't matter if the binary is 500KB
| but libcmucl.dll is 11.5MB --- the difference in perception is huge.
+---------------
Done. All you need is a CMUCL core image with a "#!" reader macro
that acts like a comment, then concatenate the following onto the
front of your FASL files (as noted):
#!/usr/local/bin/cmucl
;;;; Hack to allow CMUCL FASL files to run as shell scripts.
;;;; Usage: cat {this_file} foo1.x86f ... fooN.x86f > foo ; chmod +x foo
;;;; The last "fooN.x86f" should have a top-level form which starts the app.
(let* ((my-name (second *command-line-strings*))
(stream (open *script-name* :element-type '(unsigned-byte 8))))
(dotimes (i 9) (read-line stream)) ; Eat header text from stream, then
(load stream :contents :binary) ; pass rest to FASLOAD.
(continue)) ; Keep LOAD of script from falling into FASL file(s).
The "libcmucl.so" is actually two files, a small executable (".../bin/lisp")
and a larger core file (".../lib/cmucl/lib/lisp.core"), but the point is
that it would be shared by all of the "executables" you deliver.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Christopher C. Stacy
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <usmhsy4ym.fsf@news.dtpq.com>
>>>>> On 2 Feb 2004 22:51:01 -0800, Rayiner Hashem ("Rayiner") writes:
Rayiner> I think the fundemental problem is that a lot of Lisp'ers
Rayiner> don't want to integrate with the rest of the C-using world.
This is belied by the increasing attention paid in recent years to
"binding" libraries, utilizing both the "foreign function" calling
and the JAVA communication systems (not to mention the vendor
supplied interfaces to COM and CORBA).
But that's an entirely different issue from "delivering an executable".
You seem to be conflating binary interoperability or leveraging
libraries with delivery issues, something about the sizes of
stand-alone executable images versus those that require a
seperate run-time library.
Users don't know (nor should they care) about those details.
On Windows (or even Linux) Users do not download DLLs or EXEs.
They download a self-contained bundle that automatically
installs the files, and runs scripts that do all the other
setup (Registry, desktop icons, query for options and user
preferences, process lanching, etc.)
And for Lisp, you do exactly the same things on those
platforms, using exactly the same tools.
Rayiner> *Even *Microsoft* is having a hard time convincing everyone
Rayiner> to download the .NET framework to use .NET apps! If CMUCL
Rayiner> spit out a small binary that linked with "libcmucl.so" or
Rayiner> "cmucl.dll" end-user Lisp apps would become much more
Rayiner> palatable. It doesn't matter if the binary is 500KB but
Rayiner> libcmucl.dll is 11.5MB --- the difference in perception is huge.
I don't follow your reasoning here. If Microsoft can't convince
people to download a runtime library, why would it be desirable
for Lisp to require a special runtime library? You appear to
be saying that a "huge" improvement in the perception of the
Lisp program if it's smaller.
Who are you imagining has a problematic perception?
A few people who come to this newsgroup? Is there some reason
to believe that they represent a typical application customer?
Their fixation with small deliverable images under 2 MB for
toy programs does not correspond to any customer that I know.
The only time that users might even be aware of the size of a
program is if (assuming it's not distributed on CD) it takes
too long to download, or is too big to fit into memory.
But a 3 MB Lisp image would certainly not be considered a
very large download -- that's the same as one MP3 song.
As far as memory issues go: the only critical programs would be
the permanently resident "system tray" applets. On my Windows
machine, those seem to range from just over 2 MB (scanner buttons)
to 5 MB (Weather icon) on up to 14 MB (Palm sync/alarm, instant
messaging background). And of course Lisp can dump out those
same kinds of applications in the same amount of space and formats.
If people want to continue to claim there are problems with Lisp
in this area, they need to describe the customer environment that
they are talking about
Meanwhile, I just don't understand what alleged problems are
being presupposed in this thread -- I don't see or experience
them and they don't correspond to any of visible customer base.
My suspicion is that these messages are quasi-trolls from people
who aren't really writing programs and are just making excuses.
Perhaps they spend their time going around looking for a silver
bullet that will save them from having to actually do anything,
and are disappointed that the highly touted Lisp (like the other
languages) doesn't provide them with a magical software fairy.
The suggestion that people are "abusing" them contributes
to this theory.
> This is belied by the increasing attention paid in recent years to
> "binding" libraries, utilizing both the "foreign function" calling
> and the JAVA communication systems (not to mention the vendor
> supplied interfaces to COM and CORBA).
I'm not talking so much as cooperating at a binary level, but
cooperating at an organizational level. Systems built on C tend to
have a certain way of doings things. Programs are compiled binaries,
and libraries are native shared objects. Existing systems built on C
are very much oriented towards managing programs using this model, and
users are used to dealing with programs that use this model.
> Users don't know (nor should they care) about those details.
> On Windows (or even Linux) Users do not download DLLs or EXEs.
> They download a self-contained bundle that automatically
> installs the files, and runs scripts that do all the other
> setup (Registry, desktop icons, query for options and user
> preferences, process lanching, etc.)
Users don't often have to deal with these things (but do when
something inevitably goes wrong!), but developers do. Its a lot easier
to sell Lisp to a potential developer if they can use it within their
existing, familier framework.
> I don't follow your reasoning here. If Microsoft can't convince
> people to download a runtime library, why would it be desirable
> for Lisp to require a special runtime library?
Its slightly more subtle than that. Microsoft doesn't ship a library,
it ships a runtime. Its not just a DLL you stuff into a folder, but
rather a large program that must be installed seperately. In theory,
both should behave the same way, but in practice, they don't. Current
systems are set up to handle shared libraries very well. Basically,
you put the library in a known directory, and the system finds
everything else automatically. It is much harder to install a runtime
reliably, because you have to get correct paths set up (where to
packages live, etc). Its really a by-product of the C-oriented design
of current systems. So I'm suggesting a Lisp runtime library, not a
Lisp runtime as CMUCL is currently.
> You appear to be saying that a "huge" improvement in the perception of the
> Lisp program if it's smaller.
Not so much for users, but a Lisp runtime that behaved similarly to a
C runtime would be a lot easier to sell to developers. Developers are
already having a problem with the Java/C# way of handling the runtime
issue, and currently, Lisp really isn't much better. (Well, CMUCL/SBCL
isn't much better --- I don't own Allegro, so I won't comment on it).
> Who are you imagining has a problematic perception?
> A few people who come to this newsgroup? Is there some reason
> to believe that they represent a typical application customer?
They might not represent a typical application consumer, but I have a
hunch there are some "on the edge" developers in there that could be
Lisp users if the system were more accessible to them.
> Their fixation with small deliverable images under 2 MB for
> toy programs does not correspond to any customer that I know.
The internet makes small application size rather important. A one-time
download for a Lisp-library is one thing, but repeated downloads of
2MB for small apps is another. Application size might not matter to a
customer installing shrink-wrapped software off a CD, but a whole lot
of the interesting stuff in the software market is not happening in
the shrink-wrapped world. These days, everything from media players to
AIM clients are small, free programs distributed over the internet.
Not to mention the whole "Open Source" thing :) Adobe most likely
isn't going to write the next version of Photoshop in Lisp, but its
entirely possible that someone may decide to write what becomes a
popular chat client in Lisp. Any new developers is better than no new
developers.
> As far as memory issues go: the only critical programs would be
> the permanently resident "system tray" applets. On my Windows
> machine, those seem to range from just over 2 MB (scanner buttons)
> to 5 MB (Weather icon) on up to 14 MB (Palm sync/alarm, instant
> messaging background).
Those numbers seem very large. These apps should take a few hundred KB
if they are making proper use of shared libraries. Also, that
situation is slightly different for UNIX machines. UNIX machines have
lots of little daemons running in the background, so paying a 2MB
penalty for each one would significantly change the hardware
requirements of the system.
> My suspicion is that these messages are quasi-trolls from people
> who aren't really writing programs and are just making excuses.
Oh come on. Not everyone is a troll in disguise. In reality, some
people have certain needs, and are wondering if Lisp meets those
needs, and if not, why not*. For example, I'd love to do GUI apps in
CL. However, I am completely uninterested in Windows, and there are no
complete CL bindings for GTK+ or Qt. So my current GUI app is being
written in --- C++ :-/ And assuming I did manage to develop the app in
Lisp, I'd have to package it, and it'd be a lot easier to package
something if I had a binary and a library, rather than if I had to
deal with getting cmucl set up correctly on a number of different
platforms. These are all factors beyond my control, dictated by the
system I work in. Some languages (eg. Ocaml, Dylan) are more flexible
in this regard than others.
*Now, as for the question about why people keep bringing this up, when
it has been answered before, repeatedly. I'll be generous and assume
that this is a sign of laziness, rather than trolling.
Rayiner Hashem wrote:
> So I'm suggesting a Lisp runtime library, not a
> Lisp runtime as CMUCL is currently.
Did you check http://www.eligis.com ?
Did you check all of http://alu.cliki.net/Implementation ?
Do you really think there is something missing?
Or do you really expect that all vendors should support the particular
deployment model that you have in mind?
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
> Did you check http://www.eligis.com ?
Um, I don't see how an islisp link helps here, since I thought this
was a defacto CL newsgroup. I like islisp very much as a language its
severely lacking compared to CL in the department of available
libraries.
> Did you check all of http://alu.cliki.net/Implementation ?
Most of them. Because of my platform (Linux/KDE), architecture (x86),
and budget (cheap), CMUCL/SBCL are really the best choices. Both are
excellent compilers, but don't support binary distribution with a
shared runtime.
> Do you really think there is something missing?
I think the Lisp equivilent of GCC is missing. Something free that has
very good performance, runs on lots of platforms, has very good
language compatibility, and has broad support.
Of course, that's just me. Yet, that was my whole point in getting
into this discussion. Someone accused of the poster who started this
thread of being a troll who was just looking for excuses not to use
Lisp. Depending on your situation, there may be very good reasons that
you simply cannot use Lisp for a given program.
On 3 Feb 2004 16:22:46 -0800, ·······@mindspring.com (Rayiner Hashem) wrote:
> CMUCL/SBCL are really the best choices. Both are excellent
> compilers, but don't support binary distribution
Why not? I just shipped a CMUCL binary to a customer. It consisted of
the little 'lisp' driver program, a custom-built core file, and an
'install.sh' script that moved both of these somewhere (say,
/opt/my-app/) and created an executable shell script
/usr/local/bin/my-app that looked like
#!/bin/sh
/opt/my-app/lisp -core /opt/my-app/my-code
Presto. Just unpack the tarball and 'sh install.sh' - done. Isn't that
binary distribution?
> with a shared runtime.
Ship the normal core plus a FASL file and change your shell script to
be something like
#!/bin/sh
/opt/my-app/lisp -noinit -core /opt/cmucl/normal-core -load my-app.x86f
Edi.
> Why not? I just shipped a CMUCL binary to a customer. It consisted of
> the little 'lisp' driver program, a custom-built core file, and an
> 'install.sh' script that moved both of these somewhere (say,
Sorry, that has laziness on my part. I intended to say that CMUCL does
not support the type of binary distribution I'm talking about --- a
native-compiled executable and a shared library for the runtime. As
for why I'm talking about this sort of binary-distribution
specifically, well, that's kind of the way the thread headed after my
first post.
Edi Weitz <···@agharta.de> writes:
> On 3 Feb 2004 16:22:46 -0800, ·······@mindspring.com (Rayiner Hashem) wrote:
>
>> CMUCL/SBCL are really the best choices. Both are excellent
>> compilers, but don't support binary distribution
Code has been commited to allow cmu to create exe's on freebsd. I
think sbcl can also do it. I do not know about openmcl.
marc
On 2004-02-04 07:47:08 -0800, Marc Spitzer <········@optonline.net> said:
> Edi Weitz <···@agharta.de> writes:
>
> > On 3 Feb 2004 16:22:46 -0800, ·······@mindspring.com (Rayiner Hashem)
wrote:
> >
> >> CMUCL/SBCL are really the best choices. Both are excellent
> >> compilers, but don't support binary distribution
>
> Code has been commited to allow cmu to create exe's on freebsd. I
> think sbcl can also do it. I do not know about openmcl.
With OpenMCL, binary distribution means dumping a memory image and
distributing it with a copy of the (472K) lisp kernel. Maybe it also means
including a small shell script to launch the kernel with the image.
But this is mostly irrelevant on Mac OS X, where if you are distributing a
'binary' for easy launching, you are probably distributing an application
bundle. It's straightforward to package an OpenMCL application as an
application bundle, although there are a lot of fussy steps that aren't
necessarily obvious. The mac-lisp-ide mailing list at common-lisp.net is
working on making things easier.
Greetings! Just a quick note -- GCL currently produces standalone
executables for maxima, acl2, and axiom in the Debian GNU/Linux
distribution. While complete independence from standard
(i.e. non-lisp) system shared libs is possible, its more efficient in
a setting like this to dynamically link against libc, for example,
as is the case in the three aforementioned programs. Installing these
packages does not require GCL to be installed.
Take care,
Marc Spitzer <········@optonline.net> writes:
> Edi Weitz <···@agharta.de> writes:
>
> > On 3 Feb 2004 16:22:46 -0800, ·······@mindspring.com (Rayiner Hashem) :
> >
> >> CMUCL/SBCL are really the best choices. Both are excellent
> >> compilers, but don't support binary distribution
>
> Code has been commited to allow cmu to create exe's on freebsd. I
> think sbcl can also do it. I do not know about openmcl.
>
> marc
--
Camm Maguire ····@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
On Wed, 04 Feb 2004 15:47:08 GMT, Marc Spitzer <········@optonline.net> wrote:
> Edi Weitz <···@agharta.de> writes:
>
>> On 3 Feb 2004 16:22:46 -0800, ·······@mindspring.com (Rayiner Hashem) wrote:
>>
>>> CMUCL/SBCL are really the best choices. Both are excellent
>>> compilers, but don't support binary distribution
>
> Code has been commited to allow cmu to create exe's on freebsd. I
> think sbcl can also do it. I do not know about openmcl.
>
> marc
Just to make this clear: There's nothing in the above quote that was
written by me so I wonder why the message has to start with "Edi Weitz
wrote."
Edi.
Edi Weitz <···@agharta.de> writes:
> On 3 Feb 2004 16:22:46 -0800, ·······@mindspring.com (Rayiner Hashem) wrote:
>
>> CMUCL/SBCL are really the best choices. Both are excellent
>> compilers, but don't support binary distribution
>
> Why not? I just shipped a CMUCL binary to a customer. It consisted of
> the little 'lisp' driver program, a custom-built core file, and an
I ship a CMUCL application based on McCLIM in a similar way.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
·······@mindspring.com (Rayiner Hashem) writes:
> Not to mention the whole "Open Source" thing :) Adobe most likely
Which you're quite right not to mention, because Open Source is about
distributing the _source code_, not the binaries.
The answer to "how do I distribute my app as source code" is, as far
as I'm concerned, very very simple. You package it with an asdf
system definition, pgp-sign the package, upload it somewhere, and
create a cliki page with a :package link pointing at it. Now all the
asdf-install users can get it (conceded, it helps to get your pgp key
signed by a few people)
> Those numbers seem very large. These apps should take a few hundred KB
> if they are making proper use of shared libraries. Also, that
> situation is slightly different for UNIX machines. UNIX machines have
> lots of little daemons running in the background, so paying a 2MB
> penalty for each one would significantly change the hardware
> requirements of the system.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3451 dan 15 0 42992 36m 8276 S 0.0 29.5 6:52.50 emacs
5482 dan 16 0 84408 25m 23m S 0.0 20.8 1:49.42 MozillaFirebird
20270 dan 15 0 608m 6728 24m S 0.0 5.3 0:26.29 sbcl
3394 root 5 -10 34948 4980 16m S 1.0 3.9 5:00.72 XFree86
6605 dan 15 0 8156 4464 4376 S 0.0 3.5 18:05.24 xterm
3433 dan 16 0 8448 2444 5000 S 0.0 1.9 1:22.32 sawfish
741 root 15 0 2256 2248 2020 S 0.0 1.8 0:00.10 ntpd
4430 news 15 0 2876 1852 1660 S 0.0 1.5 0:00.14 leafnode
13941 dan 16 0 8156 1584 4376 S 0.0 1.2 0:00.64 xterm
4218 dan 15 0 8156 1488 4376 S 0.0 1.2 0:04.71 xterm
18475 dan 15 0 8156 1396 4376 S 0.3 1.1 0:04.58 xterm
From the RES column it looks like I'm paying a number of 2Mb penalties
here already. Do journalists care? Are the analysts up in arms about
it? Is this going to be the sticking point that prevents Linux from
succeeding on the desktop? Somehow I doubt it. The other machine I'm
using right now (an x86-64 box over ssh) is running a process called
"kflux.rss". It has 17 Mb resident of a 54M virtual size, and I'm
given to understand it's a /screensaver plugin/. The days when typical
small apps consumed a "few hundred k" went out at about the time
OpenLook took off, I'll bet.
I believe it's reasonable for new users to ask about "standalone
executables". They want to check that the system they're about to
invest significant time into learning is actually capable of
delivering the products that they hope eventually to be able to write.
I don't think it's a failing of Lisp that it doesn't have a standard
way to address this perceived problem; if the users stick with Lisp
they will eventually realise that the picture is more complex than
they initially thought and realise that the question is ill-posed. I
do think that the posters on c.l.l could work on a better and more
reassuring response than "don't worry about it now, trust us, you can
work something out when you actually need it".
Here's a couple of starting points:
http://alu.cliki.net/Frequently%20Asked%20Questions
http://ww.telent.net/lisp/according_to/hello-world.html
-dan
> Which you're quite right not to mention, because Open Source is about
> distributing the _source code_, not the binaries.
No! The whole point of Open Source is making source code available.
Users should not have to deal with source code unless they want to. A
lot of people work very hard to make sure that users never have to see
the source, but always can if they need to.
> From the RES column it looks like I'm paying a number of 2Mb penalties
> here already.
That's a terrible way to measure memory usage. If I add up the RSS
entries on my machine right now, I get way more memory than is
actually in use. And I'm not using swap either. But in either case, I
thought we were talking about 2MB in terms of binary-size. After all,
what was all that talk about it only being as large a download as a
single MP3 file? The actual memory usage of the binary is going to be
a lot higher than the size of the binary on disk. For reference, even
a fairly significant KDE app like Quanta is only 1.5MB on disk. Of
course, that's with 30MB of supporting libraries, but those are only
loaded once so nobody cares. Heck, even d2c produces 500KB stand-alone
executables, and that's without (if I understand correctly) a
tree-shaker. Of course, KDE has 30MB of shared libs, and d2c has 20MB,
but those are a one-time cost, not a recurring one. Given that, CL
code should easily compile to svelte executables a few-hundred KB in
size. I think the biggest issue is that none of the free
implementations really do it.
·······@mindspring.com (Rayiner Hashem) writes:
>> Which you're quite right not to mention, because Open Source is about
>> distributing the _source code_, not the binaries.
> No! The whole point of Open Source is making source code available.
> Users should not have to deal with source code unless they want to. A
> lot of people work very hard to make sure that users never have to see
> the source, but always can if they need to.
And I'm greatly indebted to projects like Debian for doing this
packaging so that I as a sysadmin don't have to. Two points:
(1) The binaries on my systems were built by Debian (or by me, in a
few cases), not by the upstream author. As an author of free
software, I don't have to concern myself with "generating executables"
much beyond making sure it's somehow possible.
(2) The Debian packaging system dependency management knows how to
find shared libraries, making "standalone" so totally not even an
issue. If I as a free software author write some code that requires
additional resources (shared libraries, or a Lisp environment, or
whatever), all that the packager has to do is declare dependencies on
those external resources and they'll get downloaded when I install the
first app that needs them. There's no need for a "single .exe"
I was a bit overemphatic in my original post, but I still maintain
that distributing executables is not the primary concern of the free
software author. For the most part, that responsibility has shifted
to packagers, and if the two roles sometimes coincide, that's just
coincidence.
>> From the RES column it looks like I'm paying a number of 2Mb penalties
>> here already.
> That's a terrible way to measure memory usage. If I add up the RSS
> entries on my machine right now, I get way more memory than is
> actually in use. And I'm not using swap either. But in either case, I
> thought we were talking about 2MB in terms of binary-size. After all,
If you trace backward through the thread, you'll find that we were
talking about memory usage at this point: you said "UNIX machines have
lots of little daemons running in the background, so paying a 2MB
penalty for each one would significantly change the hardware
requirements of the system": given the current price of hard disks, I
find it hard to believe you were talking about binary size here.
> but those are a one-time cost, not a recurring one. Given that, CL
> code should easily compile to svelte executables a few-hundred KB in
> size. I think the biggest issue is that none of the free
> implementations really do it.
It's quite rare that my fasls get as large as a few hundred kB, actually.
-dan
Daniel Barlow <···@telent.net> writes:
> ·······@mindspring.com (Rayiner Hashem) writes:
>
> >> Which you're quite right not to mention, because Open Source is about
> >> distributing the _source code_, not the binaries.
> >
> > No! The whole point of Open Source is making source code available.
> > Users should not have to deal with source code unless they want to. A
> > lot of people work very hard to make sure that users never have to see
> > the source, but always can if they need to.
>
> And I'm greatly indebted to projects like Debian for doing this
> packaging so that I as a sysadmin don't have to. Two points:
>
> (1) The binaries on my systems were built by Debian (or by me, in a
> few cases), not by the upstream author. As an author of free
> software, I don't have to concern myself with "generating executables"
> much beyond making sure it's somehow possible.
And in the case of CL, it's possible to tackle both at the same time,
using asdf and asdf-install. Sure, you have to wait for it to build,
but you don't have to do it yourself. It's almost as good as binary
packages.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Erik Winkels
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <87oesfm155.fsf@xs4all.nl>
·······@mindspring.com (Rayiner Hashem) wrote on 3 Feb 2004 16:49:55 -0800:
>
> Given that, CL code should easily compile to svelte executables a
> few-hundred KB in size. I think the biggest issue is that none of
> the free implementations really do it.
Have you checked out ECL?:
http://ecls.sourceforge.net/ecldev/devel_2.html#SEC3
Erik
--
"With the emergence of the mushroom cloud over its headquarters, Gartner
believes it's time for people to start investigating some other means of
settling conflicts than war." -- Ralph Wade Phillips in the Monastery
>>>>> "CCS" == Christopher C Stacy <······@news.dtpq.com> writes:
[...]
CCS> Users don't know (nor should they care) about those details.
CCS> On Windows (or even Linux) Users do not download DLLs or
CCS> EXEs. They download a self-contained bundle that
CCS> automatically installs the files, and runs scripts that do
CCS> all the other setup (Registry, desktop icons, query for
CCS> options and user preferences, process lanching, etc.) [...]
That's right, mostly. One thing I have not seen mentioned re: exe's
that has been important for me for at least the past 4-5 years is
getting rapid feedback from unsophisticated Windows users with
broadband. User here means client. E-mailing "Here, click on this
URL, run that exe and tell me what you think" _is_ important for rapid
progress in remote work (for values of remote varying from 1 to 10k
miles). I don't think "get this bundle, unzip, run install, let it
grind and then run it" would work as quickly especially when you just
need the client to spend a minute on whatever it is you are showing
him. Shipping off libraries in advance doesn't quite work -- people
don't seem to use the same machine and windows users have this
tendency to reinstall their OS often. Anyway, this is a moot point as
we _can_ generate single exes from most lisps.
cheers,
BM
On Tue, 03 Feb 2004 10:15:29 +0200, Bulent Murtezaoglu <··@acm.org> wrote:
> That's right, mostly. One thing I have not seen mentioned re: exe's
> that has been important for me for at least the past 4-5 years is
> getting rapid feedback from unsophisticated Windows users with
> broadband. User here means client. E-mailing "Here, click on this
> URL, run that exe and tell me what you think" _is_ important for
> rapid progress in remote work (for values of remote varying from 1
> to 10k miles). I don't think "get this bundle, unzip, run install,
> let it grind and then run it" would work as quickly especially when
> you just need the client to spend a minute on whatever it is you are
> showing him. Shipping off libraries in advance doesn't quite work
Right - but as I said in another thread there are (even free) tools
like "Inno Setup"[1] which, if necessary, will hide all this
complexity from the user. I have a hard time imagining a client who
wouldn't want to go through a simple routine like that. Windows users
launch these "installers" every day and they really don't care if they
install one file or one hundred.
Edi.
[1] <http://www.jrsoftware.org/isinfo.php>
>>>>> "EW" == Edi Weitz <···@agharta.de> writes:
[...]
EW> Right - but as I said in another thread there are (even free)
EW> tools like "Inno Setup"[1] which, if necessary, will hide all
EW> this complexity from the user.
Thanks. I have the wise installer under 'free installer' bookmarks
(www.wise.com) and seem to remember it being free at some point.
Apparently not, as of now.
EW> I have a hard time imagining a
EW> client who wouldn't want to go through a simple routine like
EW> that.
Oh they would. I wouldn't want them to if it can be helped though.
In any event LW does this just fine (as do others under windows, I
imagine).
EW> Windows users launch these "installers" every day and
EW> they really don't care if they install one file or one
EW> hundred.
That's right, but for really short stuff (getting comments or
confirming that you understood what they wanted by sending a dummy
implementation etc.) I don't want to do that to people. I find very
short turn around time invaluable and the quicker/less hassle I make
it the more likely it is that the guy'll spend the minute as soon as
he gets my message. I'd prolly look into fasl loading through
compressed http streams for stuff like that and ship off a base test
jig with an installer _once_ if I couldn't do the single exe scheme.
But this is a "collaborative remote development w/o filesystem access"
scenario which is distict from the regular complaint we get here
(which I don't even understand well enough to rephrase).
cheers,
BM
From: André Thieme
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <bvp4c2$d7f$1@ulric.tng.de>
Edi Weitz wrote:
> Right - but as I said in another thread there are (even free) tools
> like "Inno Setup"[1] which, if necessary, will hide all this
> complexity from the user. I have a hard time imagining a client who
> wouldn't want to go through a simple routine like that. Windows users
> launch these "installers" every day and they really don't care if they
> install one file or one hundred.
I personally "hate" these installers for little applications.
If I want to download a little tool, lets say a ftp client, an auto
reminder, etc. I would prefer it much more if it is one .exe or a zipped
file that I can simply unzip where I want and that's it.
When I don't want to use this application anymore I can simply delete
the directory and forget it. When it was installed with an installer I
need to run an uninstaller.
Even big applications like Mozilla can be easily "installed" by just
unpacking a zip file.
Of course this "zip trick" could also work for CL apps. I could simply
write a 20k .exe file that runs Lisp and loads/executes my program that
I shipped with the packed file.
For some small applications, maybe a nice Minesweeper or Solitair game
an single, clickable .exe file is simply the best (for me).
To reduce the size of this binary one can simply upx them:
http://upx.sourceforge.net/
(also works under linux, open source)
This sounds like a fair solution to me.
Andr�
From: Christopher C. Stacy
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <uhdy8izr8.fsf@news.dtpq.com>
>>>>> On Mon, 02 Feb 2004 21:49:36 -0500, Cameron MacKinnon ("Cameron") writes:
Cameron> I suspect that a lot of these people have written small
Cameron> applications and want to share them on the net.
Cameron> I think that the community is turning away trend setters and influencers
Common Lisp was not designed for delivering small applications
and most of the vendors are not interested in that market.
I don't know why you would think that people who have written
small applications as you describe are industry "trend setters".
If they are focused on delivering toy programs, and don't have
the patience to study and learn to understand the benefits of
something that is too complex to be easily absorbed, then it
seems to me that they are more likely to just be following
whatever trends are popular.
Cameron> What do they hear?
Cameron> - You can't do that
Cameron> - You can only do it with the commercial lisps
Cameron> - You can do it, but the binary will be 11MB
Actually, they are told about the implementations that are better
at delivering small executables, such as Corman Common Lisp and ECL.
They are also informed that Xanalys Lispworks can easily deliver
applications that are about 2 MB.
Most importantly, they are told about the trial educational versions
of the commercial quality Lisp systems, which can be used to learn
about programming in Lisp before even making a monetary investment.
But there's no getting around the learning investment.
We're not interested in "Lisp For Dummies In 21 Days".
In over four decades, we have seen languages come and languages go,
and are not very worried about popularity contests. Lisp is not well
suited to be the most popular language available, and that's fine.
From: Duane Rettig
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <41xpcd2cc.fsf@franz.com>
······@news.dtpq.com (Christopher C. Stacy) writes:
> >>>>> On Mon, 02 Feb 2004 21:49:36 -0500, Cameron MacKinnon ("Cameron") writes:
> Cameron> I suspect that a lot of these people have written small
> Cameron> applications and want to share them on the net.
>
> Cameron> I think that the community is turning away trend setters and influencers
>
> Common Lisp was not designed for delivering small applications
> and most of the vendors are not interested in that market.
Why do you say that?
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Christopher C. Stacy
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <uad40y0gi.fsf@news.dtpq.com>
>>>>> On 02 Feb 2004 23:55:15 -0800, Duane Rettig ("Duane") writes:
Duane> ······@news.dtpq.com (Christopher C. Stacy) writes:
>> >>>>> On Mon, 02 Feb 2004 21:49:36 -0500, Cameron MacKinnon ("Cameron") writes:
Cameron> I suspect that a lot of these people have written small
Cameron> applications and want to share them on the net.
>>
Cameron> I think that the community is turning away trend setters and influencers
>>
>> Common Lisp was not designed for delivering small applications
>> and most of the vendors are not interested in that market.
Duane> Why do you say that?
Lisp was developed for programming large systems, with the first
application domain being Artificial Intelliegence, followed by
object-oriented operating systems, followed by general purpose
applications (often leveraging those other two Lisp areas).
Common Lisp has been used in embedded systems, but those were
not small programs. When Lisp people have focused on smaller
programs, they have changed the language into something with
a new name, such as Scheme (academic instruction purposes and
concise demonstrations of theoretical language power) or Dylan
(with more modularity and deployment features in the language).
In some cases, limited versions of Lisp have also been developed
as application extension languages, which are typically small
programs, but those are not Common Lisp (and are usually interpreted
by a large runtime system, anyway). Finally, people use many
varieties of Lisp to implement domain specific languages which
may have compilers that emit small programs.
As for the claim about most the major vendors not being interested,
I simply observe they have not spent the resources to create a Lisp
compiler that delivers "hello world" in a 1 KB stand-alone image
that scales up linearly with the program functionality to the size
of the "large" (ha ha) 2 to 3 MB program's images.
One reason for this is the fact of Common Lisp's large core library.
There is no ANSI subset, and the standard provides no support or
guidance in creating one. And the typical implementation strategy
involves a proprietary dynamic linker, and FASL files. To reduce
program delivery size, there is also sometimes a GC-based un-linker
("tree shaker'), although that may result in image that's more
fragile in the face of certain kinds of bugs.
Meanwhile, the bigger commercial vendors (Franz, Xanalys, MCL)
focus on providing connectivity features such as networking,
database, GUI, distributed object procedure calling, multi-media
content location and management, and native platform bindings,
which are not the hallmarks of trivial little applications.
They also sometimes invest in layered products such as expert
system shells. This is on top of being fairly busy working
on the quality of the runtime and compiler.
As a language, Common Lisp came out of the original "big hard
problems" community, and I think it shows it.
And as I said, I don't see the problem with this. As an application
developer (and once-upon-a-time Lisp vendor), I haven't seen any
customers who are willing to pay much for me shipping them "hello world".
In the past 15 years, computer hardware has caught up to requirements
of Lisp applications, and compared to 99% of the programs in the
world today Lisp now seems relatively svelte.
The only area where the "small program" issue seems relevent these days
is in personal mobile computing. It remains to be seen how those power
curves will go. Maybe more work will be needed to deliver Lisp programs
on those kinds of devices, or maybe I'll just be able to run Genera on
my cell phone in a few years.
From: Duane Rettig
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <4d68wqauh.fsf@franz.com>
······@news.dtpq.com (Christopher C. Stacy) writes:
> >>>>> On 02 Feb 2004 23:55:15 -0800, Duane Rettig ("Duane") writes:
>
> Duane> ······@news.dtpq.com (Christopher C. Stacy) writes:
> >> >>>>> On Mon, 02 Feb 2004 21:49:36 -0500, Cameron MacKinnon ("Cameron") writes:
> Cameron> I suspect that a lot of these people have written small
> Cameron> applications and want to share them on the net.
> >>
> Cameron> I think that the community is turning away trend setters and influencers
> >>
> >> Common Lisp was not designed for delivering small applications
> >> and most of the vendors are not interested in that market.
>
> Duane> Why do you say that?
[ histories elided ... ]
> As for the claim about most the major vendors not being interested,
> I simply observe they have not spent the resources to create a Lisp
> compiler that delivers "hello world" in a 1 KB stand-alone image
> that scales up linearly with the program functionality to the size
> of the "large" (ha ha) 2 to 3 MB program's images.
Well, yes, that's true, but you certainly have an outdated view of
what is small and what is large. And 1 Kb is unrealistic nowadays,
even for highly compact languages. I've heard more things along the
lines of 50 - 100 Kb as realistic tiny-programs, and even up to a
megabyte is acceptable as a small program (no, I have no references,
it's just the "feel" I get from seeing what's out there, what sells,
and what is available in hardware).
So a 2 Mb program is not "small", but it certainly is not large
either. And as memory gets even more and more dense, as long as
CL can stay as small as it is currently without bloating up too
much, it fits into more and more devices.
Let me ask you this - using Moore's Law, even as applicable to
embedded systems, and assuming that in 10 years you buy a
refrigerator that is attached to the rest of your kitchen and
orders the milk online for you when it is low, how much memory
do you think will be in that embedded processor? Do you really
think that they will starve such systems with less than 100 Mb
of memory? And that will be considered a _tiny_ system!
[ more history , etc elided ...]
> As a language, Common Lisp came out of the original "big hard
> problems" community, and I think it shows it.
I agree with the first part, but not the second. If the feel of
lisp's size showed it's origins in "big problem" thought, then
you wouldn't be able to make the following statements, because
by Moore's Law and (is there a Gates' law? :-) the lisps would
then tend to have a base size of 300 Mb, rather than the 2-10 Mb
they are now:
> And as I said, I don't see the problem with this. As an application
> developer (and once-upon-a-time Lisp vendor), I haven't seen any
> customers who are willing to pay much for me shipping them "hello world".
> In the past 15 years, computer hardware has caught up to requirements
> of Lisp applications, and compared to 99% of the programs in the
> world today Lisp now seems relatively svelte.
Precisely. Why do you think that is? You don't think the vendors have
had anything to do with that?
> The only area where the "small program" issue seems relevent these days
> is in personal mobile computing. It remains to be seen how those power
> curves will go. Maybe more work will be needed to deliver Lisp programs
> on those kinds of devices, or maybe I'll just be able to run Genera on
> my cell phone in a few years.
Well, to the extent that personal mobile computing stays stagnant,
I suppose that there would be no reason to want to do a me-too
cell-phone operating system. But why would we ever conclude that
things would stay stagnant? And why limit personal mobile computing
to cell phones? We already have more power than old style mainframes
hanging off our shoulders; why do we think that the "cell-phones"
of the future won't be our main computing devices by then?
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Joe Marshall
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <hdy8gg7p.fsf@ccs.neu.edu>
Duane Rettig <·····@franz.com> writes:
> If the feel of lisp's size showed it's origins in "big problem"
> thought, then you wouldn't be able to make the following statements,
> because by Moore's Law and (is there a Gates' law? :-)
Yes there is!
Moore's law: The number of transistors on a chip doubles about every
18 months.
Gates's law: The speed of software halves every 18 months.
From: Duane Rettig
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <48yjkq8aw.fsf@franz.com>
Joe Marshall <···@ccs.neu.edu> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > If the feel of lisp's size showed it's origins in "big problem"
> > thought, then you wouldn't be able to make the following statements,
> > because by Moore's Law and (is there a Gates' law? :-)
>
> Yes there is!
>
>
> Moore's law: The number of transistors on a chip doubles about every
> 18 months.
>
> Gates's law: The speed of software halves every 18 months.
So then, all we have to do is bide our time; in 5 years, CL will
be the smallest _and_ fastest software in the world!
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Joe Marshall
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <znc0eyug.fsf@ccs.neu.edu>
Duane Rettig <·····@franz.com> writes:
>>
>> Gates's law: The speed of software halves every 18 months.
>
> So then, all we have to do is bide our time; in 5 years, CL will
> be the smallest _and_ fastest software in the world!
As part of the work I do here at Northeastern, I had to install the
.NET development environment. This weighs in at around 3GB.
The CADR had an *address space* of about 3MB. (And the original CADRs
had up to 192K of memory.)
Joe Marshall <···@ccs.neu.edu> writes:
> As part of the work I do here at Northeastern, I had to install the
> .NET development environment. This weighs in at around 3GB.
"But that's different!" :-)
Personally, I don't see the big problem. High-level languages, CL and
others, in my experience produce compact code. Programs also tend to
be parsimonious with resources unless written by novices. (Both of
these properties as compared to conventional commercial software
packages.) Furthermore, portability is generally excellent: once the
underlying language has been ported to the new platform, the remaining
effort is small. (And isn't it's nice that a third party thus can do
most of the work, without even peeking at your code?) My hypothesis is
that the reverse of Greenspun's 10th is a major reason for those
properties.
The people who ask about generating executables probably(?) worry
about whether app delivery, upgrade, and support is incomprehensible
and painful. Maybe a HOWTO or tutorial would be the right thing in
that case, just to show that it's not a problem in practice. At least
it would make a reasonable FAQ.
Best,
Thomas
--
Thomas Lindgren
"It's becoming popular? It must be in decline." -- Isaiah Berlin
Joe Marshall <···@ccs.neu.edu> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > If the feel of lisp's size showed it's origins in "big problem"
> > thought, then you wouldn't be able to make the following statements,
> > because by Moore's Law and (is there a Gates' law? :-)
>
> Yes there is!
>
>
> Moore's law: The number of transistors on a chip doubles about every
> 18 months.
>
> Gates's law: The speed of software halves every 18 months.
I thought Gates' Law refered to 16 month periods ;-)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Christopher C. Stacy
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <uisiovscz.fsf@news.dtpq.com>
>>>>> On 03 Feb 2004 10:25:26 -0800, Duane Rettig ("Duane") writes:
[ a bunch of stuff]
Perhaps I am not expressing myself very well, but I
believe that we are in complete agreement on all the
points that I raised, and therefore your questions
all sounded rhetorical to me.
From: Duane Rettig
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <44qu7rfcr.fsf@franz.com>
······@news.dtpq.com (Christopher C. Stacy) writes:
> >>>>> On 03 Feb 2004 10:25:26 -0800, Duane Rettig ("Duane") writes:
> [ a bunch of stuff]
>
> Perhaps I am not expressing myself very well, but I
> believe that we are in complete agreement on all the
> points that I raised, and therefore your questions
> all sounded rhetorical to me.
I think we mostly do agree, but I took exception and to regarded
as hyperbolic your statement about Lisp Vendors not caring about
delivering a 1 Kb executable. It's the old "have you stopped
beating your wife" question. Even on linux, the default gcc
compilation of hello.c is 11 Kb, and if you strip it it becomes
2 Kb. But what is more important is not the size of the executable;
it is the size in memory; when stepping hello through gdb ps tells
me that hello is consuming 1.3 Mb of memory. Not far from what
you can see in a small application in a well-configured CL
implementation
Many common lisps allow the creation of very small executables
via the #! shell construct, on operating systems which support
it. In fact Allegro CL allows such constructs to be prepended to
fasl files, so not only is the code loaded into the target lisp
small, it is pre-compiled! But we do not promulgate such tricks
because they are pretty much meaningless; what we really target
is memory size. And if we can, for any reasonable size of problem,
provide a reasonable size for the image that is generated (both
in terms of disk space and in terms of total memory footprint)
then we've done a good job at caring about image sizes.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Christopher C. Stacy
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <uad3zsl07.fsf@news.dtpq.com>
>>>>> On 03 Feb 2004 14:02:44 -0800, Duane Rettig ("Duane") writes:
Duane> ······@news.dtpq.com (Christopher C. Stacy) writes:
>> >>>>> On 03 Feb 2004 10:25:26 -0800, Duane Rettig ("Duane") writes:
>> [ a bunch of stuff]
>>
>> Perhaps I am not expressing myself very well, but I
>> believe that we are in complete agreement on all the
>> points that I raised, and therefore your questions
>> all sounded rhetorical to me.
Duane> I think we mostly do agree, but I took exception and to
Duane> regarded as hyperbolic your statement about Lisp Vendors not
Duane> caring about delivering a 1 Kb executable.
I was reponding to the troll, who was claiming that Lisp can't
deliver small stand-alone executables (which is true, if you
adjust the parameters down the point of nonsense).
My point was that that's nonsense, which is why the
vendors don't (and should not) care about it.
From: Duane Rettig
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <4ad3ze7jq.fsf@franz.com>
······@news.dtpq.com (Christopher C. Stacy) writes:
> >>>>> On 03 Feb 2004 14:02:44 -0800, Duane Rettig ("Duane") writes:
>
> Duane> ······@news.dtpq.com (Christopher C. Stacy) writes:
> >> >>>>> On 03 Feb 2004 10:25:26 -0800, Duane Rettig ("Duane") writes:
> >> [ a bunch of stuff]
> >>
> >> Perhaps I am not expressing myself very well, but I
> >> believe that we are in complete agreement on all the
> >> points that I raised, and therefore your questions
> >> all sounded rhetorical to me.
>
> Duane> I think we mostly do agree, but I took exception and to
> Duane> regarded as hyperbolic your statement about Lisp Vendors not
> Duane> caring about delivering a 1 Kb executable.
>
> I was reponding to the troll, who was claiming that Lisp can't
> deliver small stand-alone executables (which is true, if you
> adjust the parameters down the point of nonsense).
But this argument becomes specious, if the parameters are adjusted
down to the point where it is nonsense even for languages that
are _known_ for their ability to deliver small applications.
The "troll" you responded to had a good point, and never
mentioned any actual sizes. And your response was:
| Common Lisp was not designed for delivering small applications
| and most of the vendors are not interested in that market.
which is half false. Many Common Lisp vendors do care to
make their product as small as possible, so as to grab as much
of the small application market as possible, as that market pushes
its way up through the barriers of those factors which limit how
small CLs can in fact get. And yes, we do get new customers
that way, as they discover that CL is not as big and bulky as
they once believed, and can indeed handle their (constantly
growing) small applications.
> My point was that that's nonsense, which is why the
> vendors don't (and should not) care about it.
Now, of course, _this_ market is one we obviously don't care
about (i.e. the 1k-byte application market) because it doesn't
exist.
I think our differences in perception stem from what each of us
views as a "small" application (or at least what each of us is
willing to admit is in fact a believable small application in
2004 terms).
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> wrote in message news:<·············@franz.com>...
>
> Now, of course, _this_ market is one we obviously don't care
> about (i.e. the 1k-byte application market) because it doesn't
> exist.
I suspect it does exist, still, although not in general machines. I
admit to not having looked that recently (say within the last 2
years), but there certainly were an awful lot of microcontrollers sold
which had maybe a couple of K of ROM and some small number of bytes of
RAM. I'd guess that these things are still used, and possibly used in
enormous numbers, since in the market they're aimed at getting things
very cheap is a significant win, and the computastional requirements
are not very large. It may be though that you can put hundreds of K
of ROM on them for nothing (literally...) now though.
Of course, if this market still exists it's probably not interesting
for CL, even though it may be very large.
--tim
From: Duane Rettig
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <47jz2poc9.fsf@franz.com>
··········@tfeb.org (Tim Bradshaw) writes:
> Duane Rettig <·····@franz.com> wrote in message news:<·············@franz.com>...
>
> >
> > Now, of course, _this_ market is one we obviously don't care
> > about (i.e. the 1k-byte application market) because it doesn't
> > exist.
>
> I suspect it does exist, still, although not in general machines. I
> admit to not having looked that recently (say within the last 2
> years), but there certainly were an awful lot of microcontrollers sold
> which had maybe a couple of K of ROM and some small number of bytes of
> RAM.
I'd be interested in seeing any specs for such hardware. For the
past 30 years, as soon as memory of one size became prevalent and
its cost came down to match memory of smaller size, the smaller sized
chips/boards became obsolete, because there was never any reason to
spend the same money for less RAM as to get the larger RAM. In fact,
the only reason that _might_ have kept such older chips/boards
around was compatibility, but the smarter hardware always allows for
pin-compatible upward mobility (unless it is so cheap as to be throw-away,
in which case the whole model becomes obsolete and is replaced by the
next generation). It might be interesting to see what the smallest
processors (perhaps divided into two categories: general purpose and
special-purpose) are that are currently sold.
> I'd guess that these things are still used, and possibly used in
> enormous numbers, since in the market they're aimed at getting things
> very cheap is a significant win, and the computastional requirements
> are not very large. It may be though that you can put hundreds of K
> of ROM on them for nothing (literally...) now though.
Some of the "tiny" robots I hear of have "only" 1M ROM and 1M RAM.
> Of course, if this market still exists it's probably not interesting
> for CL, even though it may be very large.
At issue is the size of the markets for machines of various sizes.
Imagine a curve, where if you plot the size of memory in computing
devices against the number of units sold, you would get a sweet spot
at some size of memory which happens to be a the lowest end of the
mass-production scale; i.e. if you make a 1M chip and it costs you
less to make a 500K chip, but a 250K chip costs the same as a 500K
chip, then the sweet spot in the curve will hover around those units
which use the 500K chip. That sweet spot is moving rapidly, according
to Moore's Law, and to the extent that it is close to the point where
CLs can operate comfortably, we in the CL business most _certainly_
should be interested in it. We have to be careful not to let ourselves
get trapped in "codgerism" (I just coined this term) where we old
codgers can't imagine a world where so much memory is available for
so cheap, and thus we imagine the curve I am describing as being
further down the scale than it really is, and thus miss a potential
market.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> I'd be interested in seeing any specs for such hardware. For the
> past 30 years, as soon as memory of one size became prevalent and
> its cost came down to match memory of smaller size, the smaller sized
> chips/boards became obsolete, because there was never any reason to
> spend the same money for less RAM as to get the larger RAM. In fact,
> the only reason that _might_ have kept such older chips/boards
> around was compatibility, but the smarter hardware always allows for
> pin-compatible upward mobility (unless it is so cheap as to be throw-away,
> in which case the whole model becomes obsolete and is replaced by the
> next generation). It might be interesting to see what the smallest
> processors (perhaps divided into two categories: general purpose and
> special-purpose) are that are currently sold.
See www.microchip.com (a representative manufacturer with a broad line).
Briefly, the chips range from about 1/2k to 128k of flash or one time
programmable ROM, and a few tens of bytes to a few k of RAM. C, Forth
and assembly are the tools of choice. Odd, non Von Neumann architectures
are common. Millions of units. Lisp would need to be CONSless.
Somewhat bigger than that, there's 32 bit MCUs with specialized DSP
units. These would have enough horsepower to run a Lisp, but garbage
collection would have to be realtime, and the coders would want to do
their inner DSP loops in assembly anyway.
> Some of the "tiny" robots I hear of have "only" 1M ROM and 1M RAM.
Scheme for Lego Mindstorms: http://www.cs.indiana.edu/~mtwagner/legoscheme/
From: Tim Bradshaw
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <ey3k731uh8j.fsf@cley.com>
* Duane Rettig wrote:
> Some of the "tiny" robots I hear of have "only" 1M ROM and 1M RAM.
I'm not talking about tiny robots. I'm talking about the kind of
processor which is in, say, the digital thermometer/hygrometer I have
measuring the humidity around musical instruments. It might not
*have* a processor, but I'd guess it does nowadays. It needs to store
maybe 10 integers (max and min for temp and humidity, current values,
some scratch space). The program it runs is probably quite small.
My intuition (which may be wrong) is that a huge amount of stuff which
used to be custom logic is now done by tiny low-power embedded
processors. I suspect there are billions of these things out there,
and many of them are in things whose retail cost is pence, or maybe a
few pounds, so the processor/memory cost needs to be small numbers of
pence.
I'm not suggesting that this is a market that Lisp should target!
--tim
From: Christopher C. Stacy
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <u7jz0y8el.fsf@news.dtpq.com>
>>>>> On Fri, 06 Feb 2004 01:30:36 +0000, Tim Bradshaw ("Tim") writes:
Tim> * Duane Rettig wrote:
>> Some of the "tiny" robots I hear of have "only" 1M ROM and 1M RAM.
Tim> I'm not talking about tiny robots. I'm talking about the kind of
Tim> processor which is in, say, the digital thermometer/hygrometer I have
Tim> measuring the humidity around musical instruments.
Tim> I'm not suggesting that this is a market that Lisp should target!
A small device like a thermometer obviously doesn't need a powerful
dynamic language. Common Lisp would be unsuitable for this purpose.
However, the firmware for such a device could be nicely written in
a language that is implemented in Lisp. This "small" language could
have the synax of Lisp, and could include many familiar Lisp operators
and concepts, and could use Lisp macros. But it would compile down to
something that is "not really Lisp": a tiny static program image that
lacks all the dynamic features of Lisp. For some kinds of devices,
the program would actually be a hardware circuit description.
The main advantage of writing this in the Lisp-like source language,
rather than in assembly language, or some HDL, or someone other
higher-level FPGA description language, is the power of Lisp macros
and the Lisp extensibility of the language.
······@news.dtpq.com (Christopher C. Stacy) writes:
> A small device like a thermometer obviously doesn't need a powerful
> dynamic language. Common Lisp would be unsuitable for this purpose.
> However, the firmware for such a device could be nicely written in
> a language that is implemented in Lisp. This "small" language could
> have the synax of Lisp, and could include many familiar Lisp operators
> and concepts, and could use Lisp macros. But it would compile down to
> something that is "not really Lisp": a tiny static program image that
> lacks all the dynamic features of Lisp. For some kinds of devices,
> the program would actually be a hardware circuit description.
> The main advantage of writing this in the Lisp-like source language,
> rather than in assembly language, or some HDL, or someone other
> higher-level FPGA description language, is the power of Lisp macros
> and the Lisp extensibility of the language.
The people programming microcontrollers I know mostly program in
assembler, some also in C (if you manage to convince them that the C
compiler is doing a very good job in producing code with very small
footprint and/or if no hard realtime constraints are to be obeyed).
They resent C++ because it is "too high level".
I doubt that it would be easy to convince these developers to switch
to a lisp, and I doubt it would be worthwhile: The programs written
for microcontrollers are often relatively small and well-specified.
Also, you sometimes have bugs in your hardware. Each additional level
of abstraction between you and your hardware makes it harder to detect
these (I am being told).
One exception is matlab: Some signal processing people explore their
algorithms in matlab and then convert their code automatically to
DSPs. Matlab offers for signal processing a concise syntax and
excellent visualization capabilities. Its capabilities to build new
abstractions are limited. But only computer scientists (like me) seem
to be bothered, sometimes. ;-)
"Tim Bradshaw" <···@cley.com> wrote
>
> I'm not talking about tiny robots. I'm talking about the kind of
> processor which is in, say, the digital thermometer/hygrometer I have
> measuring the humidity around musical instruments. It might not
> *have* a processor, but I'd guess it does nowadays. It needs to store
> maybe 10 integers (max and min for temp and humidity, current values,
> some scratch space). The program it runs is probably quite small.
I'm currently doing exactly this.
Temperature/humidity data logging and processing devices. (for the blood
supply chain for instance)
The devices I use are microcontrollers devices with 128 to 256 bytes of RAM
and 4K to 8K of code. They cost from $0.85 to $1.8 (in millions quantity)
The code is in C but partly generated from Lisp.
All the support software like calibration, tests, etc. is written in Lisp.
And the most important point is that all the applications are Lisp web
applications.
Using Lisp for this is very cool anyway. ;-)
> My intuition (which may be wrong) is that a huge amount of stuff which
> used to be custom logic is now done by tiny low-power embedded
> processors. I suspect there are billions of these things out there,
> and many of them are in things whose retail cost is pence, or maybe a
> few pounds, so the processor/memory cost needs to be small numbers of
> pence.
Yes.
> I'm not suggesting that this is a market that Lisp should target!
Lisp won't run directly on them but using lisp to program them is an unfair
advantage.
Marc
Hello!
Duane Rettig <·····@franz.com> wrote:
>[... HW with *little* memory ...]
>I'd be interested in seeing any specs for such hardware. For the
>[...]
Aren't typical smart cards still equipped with rather *little*
memory?
Kind regards,
Hannah.
From: Duane Rettig
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <4ptcsi56p.fsf@franz.com>
······@schlund.de (Hannah Schroeter) writes:
> Hello!
>
> Duane Rettig <·····@franz.com> wrote:
> >[... HW with *little* memory ...]
>
> >I'd be interested in seeing any specs for such hardware. For the
> >[...]
>
> Aren't typical smart cards still equipped with rather *little*
> memory?
I think I need to clarify here. I've seen posts and emails describing
several kinds of hardware that are highly specialized and need very
little programming. As such, they are also fairly inflexible, as
general purpose computing goes.
From my own personal viewpoint: I came from a background in hardware,
and specifically hardware testing, which is a sort of crossroads
between development, manufacturing, and QA, and which disciplines
included both hardware and software; in fact, it was that mixture and
the higher degree of complexity in supercomputers-on-a-chip that forced
my group to get into AI and eventually into Lisp (yes, Kenny, I know,
I still need to write up my Road to Lisp, but haven't gotten 'round
to it :-). But we also found that those hardware designs that accomodated
the most general-purpose computational abilities got the most mileage
and usage, and specialized hardware was useful for specialized tasks
that were well-known and unchanging. I have no doubts that there is a
large market for specialized hardware, but I doubt that _any_ language
developer is going to be interested in targeting such hardware (though
a programmer in any language might do so, and the language is never
a limitation there). I went out of the hardware industry with the
belief that the commodity markets would shift more and more toward
general-purpose computing, and I have been right, so far. Obviously,
the specialized hardware industry is not going to go away, but GP
hardware is definitely on the rise, even in problem set areas that
used to be thought of as specialized.
As a Lisp Developer, I see three worlds of Lisp development. One
is the Lisp Machine world, which has pretty much dried up. Not
completely, but the business is not big enough to support more than
one tiny company. Many wax nostalgic about their machines, and some
have tried to resurrect it, but that will likely not happen.
The second world of Lisp computing is the GP hardware world. It is
the one which I entered when I came to Franz, and it is the largest,
even though as Lispers we only have a small slice of the GP-hardware
software market. We are, of course, working hard to add to that
slice. We target our Lisp to GP hardware, and indeed don't consider
non-gp hardware, though as more and more specialized hardware is
implemented on GP machines, we see more and more potential.
The third area is one little-explored by our customers, but present.
It has been alluded to elsewhere in this thread, and is what I call
the "targeted" market. It is not Lisp vendor-developers that tend
to target this kind of hardware, any more than C++ companies would
target such hardware, but instead Lisp programmers, who would build
target code out of the compilation abilities of their Lisps (just as
C/C++ cross-developers would build their targeted software out of
the environments which they get from their language vendors). One
very successful example of this is Naughty Dog Software: see:
http://www.franz.com/success/customer_apps/animation_graphics/naughtydog.lhtml
Lisp is supposed to be the language-writing language. Most CL
implementations already compile down to the machine-code level,
very efficiently, and it is not too hard to compile to bit-levels
of specialized hardwares (the native compiler can probably even help).
So why don't people just do that? Perhaps it is because they don't
think it can be done. (refutation: see the naughty dog article above).
Perhaps they think that the Lisp vendors will do it. Sorry, we do
have our hands full with the growing cadre of GP hardware. Perhaps
they just don't know how. I doubt that; Lispers tend to be pretty
smart. I think that Lispers just don't associate the capability
of targeted software with Lisp, and that's a shame, because Lisp
is such a great language for doing such work.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> Lisp is supposed to be the language-writing language. Most CL
> implementations already compile down to the machine-code level,
> very efficiently, and it is not too hard to compile to bit-levels
> of specialized hardwares (the native compiler can probably even help).
I would like to see a replacement for gcc written in CL. Too much
of gcc's internals reinvents parts of lisp, poorly.
Paul
Hello!
Cameron MacKinnon <··········@clearspot.net> wrote:
>Paul Dietz wrote:
>> I would like to see a replacement for gcc written in CL. Too much
>> of gcc's internals reinvents parts of lisp, poorly.
>Seconded.
Thirded :-)
In fact, the most important thing to me would be a *much* faster
C++ compiler than gcc. Target code quality may suffer (even though
I've seen faster compilers for C w/o the "++" part which generated
better code w/o optimization compared to gcc -O0), but that's
needed for anything remotely associated to "reasonable development
cycles" for C++.
Perhaps implementing a C/C++ compiler (or even multi-frontend w/
nearly common IL) in Lisp would allow for experimenting with
more efficient compiler design with not much worse target code
generation abilities?
Kind regards,
Hannah.
On 9 Feb 2004 14:20:21 GMT, Hannah Schroeter <······@schlund.de> wrote:
> Hello!
>
> Cameron MacKinnon <··········@clearspot.net> wrote:
>> Paul Dietz wrote:
>>> I would like to see a replacement for gcc written in CL. Too much
>>> of gcc's internals reinvents parts of lisp, poorly.
>
>> Seconded.
>
> Thirded :-)
>
> In fact, the most important thing to me would be a *much* faster
> C++ compiler than gcc. Target code quality may suffer (even though
> I've seen faster compilers for C w/o the "++" part which generated
> better code w/o optimization compared to gcc -O0), but that's
> needed for anything remotely associated to "reasonable development
> cycles" for C++.
>
> Perhaps implementing a C/C++ compiler (or even multi-frontend w/
> nearly common IL) in Lisp would allow for experimenting with
> more efficient compiler design with not much worse target code
> generation abilities?
>
>
> Kind regards,
>
> Hannah.
The reason gcc is so slow is because it calls different programs for each
part of the compilation cycle.
Both Borland compiler and Microsoft's provide much better compilation
speeds.
The do this by running all stages of compilation in one proces and
eliminating the need to write intermediate
data to disc. (By the way a good way to speed up gcc is to create a RAM
disk and write the temporary files to that disk.) They altso provide pre
compiled headers since C++ has a brain dead #include structure wich
requires you to include major parts of the program in each file and then
recompile it potentially hundreds of times.
By comparison a compile of Opera under Microsoft visual studio takes 2
minutes on a 2.4 GHz pentium celleron and about 10 minutes under linux
using gcc. In addition Borland and Microsoft compilers provide incremental
linkage.
Adding code, recompiling it and then running it takes only a few seconds
in Visual C++ even for a system as large as the Opera browser (approaching
600 000 lines and 120 cpp files)
Remeber that gcc technology is basically seventies. Before solving
yesteday's problem look at some modern compilers. A good place to start
would be the Borland C++ comiler for linux which I believe is available
for free.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Chello <··············@chello.no> writes:
> On 9 Feb 2004 14:20:21 GMT, Hannah Schroeter <······@schlund.de> wrote:
>
> > Hello!
> >
> > Cameron MacKinnon <··········@clearspot.net> wrote:
> >> Paul Dietz wrote:
> >>> I would like to see a replacement for gcc written in CL. Too much
> >>> of gcc's internals reinvents parts of lisp, poorly.
> >
> >> Seconded.
> >
> > Thirded :-)
> >
> > In fact, the most important thing to me would be a *much* faster
> > C++ compiler than gcc. Target code quality may suffer (even though
> > I've seen faster compilers for C w/o the "++" part which generated
> > better code w/o optimization compared to gcc -O0), but that's
> > needed for anything remotely associated to "reasonable development
> > cycles" for C++.
> >
> > Perhaps implementing a C/C++ compiler (or even multi-frontend w/
> > nearly common IL) in Lisp would allow for experimenting with
> > more efficient compiler design with not much worse target code
> > generation abilities?
> >
> >
> > Kind regards,
> >
> > Hannah.
>
> The reason gcc is so slow is because it calls different programs for
> each part of the compilation cycle.
> Both Borland compiler and Microsoft's provide much better compilation
> speeds.
> The do this by running all stages of compilation in one proces and
> eliminating the need to write intermediate
> data to disc. (By the way a good way to speed up gcc is to create a
> RAM disk and write the temporary files to that disk.) They altso
> provide pre compiled headers since C++ has a brain dead #include
> structure wich requires you to include major parts of the program in
> each file and then recompile it potentially hundreds of times.
> By comparison a compile of Opera under Microsoft visual studio takes 2
> minutes on a 2.4 GHz pentium celleron and about 10 minutes under linux
> using gcc. In addition Borland and Microsoft compilers provide
> incremental linkage.
> Adding code, recompiling it and then running it takes only a few
> seconds in Visual C++ even for a system as large as the Opera browser
> (approaching 600 000 lines and 120 cpp files)
> Remeber that gcc technology is basically seventies. Before solving
> yesteday's problem look at some modern compilers. A good place to
> start would be the Borland C++ comiler for linux which I believe is
> available for free.
Please define "70's" technology, and how Microsoft/Borland's compilers
are more "modern". I assume you've done the benchmarks to isolate
gcc's slowness to the intermediate files instead of something else?
Have you tested those benchmarks against using -pipe in gcc?
Precompiled headers and incremental linking are more a byproduct
trying to save time while dealing with C than a property of a "modern"
compiler- which is not to say they're useless or undesirable, but they
don't have much of anything to do with code generation- or with
compiling Lisp either.
Gregm
Chello <··············@chello.no> writes:
> The reason gcc is so slow is because it calls different programs for
> each part of the compilation cycle.
> Both Borland compiler and Microsoft's provide much better compilation
> speeds.
You can use -pipe to avoid writing intermediary files.
-pipe
Use pipes rather than temporary files for communication
between the various stages of compilation. This fails to
work on some systems where the assembler is unable to read
from a pipe; but the GNU assembler has no trouble.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Hello!
Chello <··············@chello.no> wrote:
>[...]
>The reason gcc is so slow is because it calls different programs for each
>part of the compilation cycle.
If that were the only reason. Forget it, most of the time in
my compilations is spent in the C++ compiler *proper*. And
there's -pipe always...
>Both Borland compiler and Microsoft's provide much better compilation
>speeds.
They don't help me, as I'm developping on OpenBSD (though deployment
is mostly on Linux).
>[...]
>disk and write the temporary files to that disk.) They altso provide pre
>compiled headers since C++ has a brain dead #include structure wich
>requires you to include major parts of the program in each file and then
>recompile it potentially hundreds of times.
That would probably a gain for me, but template expansion will probably
still take some CPU cycles, won't they?
>[...]
>Remeber that gcc technology is basically seventies. Before solving
>yesteday's problem look at some modern compilers. A good place to start
>would be the Borland C++ comiler for linux which I believe is available
>for free.
As said, that won't help me. Btw, how compatible is Borland C++,
when it comes to Unix interfaces and things like that?
Kind regards,
Hannah.
>>> I would like to see a replacement for gcc written in CL. Too much
>>> of gcc's internals reinvents parts of lisp, poorly.
>
>>Seconded.
>
> Thirded :-)
Just what the Lisp world needs ... a better C compiler ?!
--
jan
jan wrote:
>>>>I would like to see a replacement for gcc written in CL. Too much
>>>>of gcc's internals reinvents parts of lisp, poorly.
>>
>>>Seconded.
>>
>>Thirded :-)
>
>
> Just what the Lisp world needs ... a better C compiler ?!
Sure. When I first read about Greenspun's tenth [what were the others?],
the best example *by far* that I could think of was gcc.
Coming up with a superior replacement for gcc would be the biggest
possible coup for Lisp. And while the open source community would
naturally be wary of introducing a new compiler with new bugs into the
equation, it isn't like gcc hasn't gone through some bumpy (and buggy)
periods in the last few years. (disclaimer vendors shipped buggy
versions not meant for distribution, not gcc team's fault, blah blah blah)
If you look at the sources for gcc, I think you'll agree, there's a lisp
in there struggling to get out.
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon <··········@clearspot.net> wrote in message news:<······················@golden.net>...
> Sure. When I first read about Greenspun's tenth [what were the others?],
> the best example *by far* that I could think of was gcc.
[ snip ]
> If you look at the sources for gcc, I think you'll agree, there's a lisp
> in there struggling to get out.
It's hard to come to any other conclusion when you find a mapcar
function in there. :)
Cameron MacKinnon <··········@clearspot.net> writes:
> Sure. When I first read about Greenspun's tenth [what were the
> others?], the best example *by far* that I could think of was gcc.
>
> Coming up with a superior replacement for gcc would be the biggest
> possible coup for Lisp. And while the open source community would
> naturally be wary of introducing a new compiler with new bugs into the
> equation, it isn't like gcc hasn't gone through some bumpy (and buggy)
> periods in the last few years. (disclaimer vendors shipped buggy
> versions not meant for distribution, not gcc team's fault, blah blah
> blah)
In what way would a Lisp-based C/C++ compiler be "superior" to gcc or
Intel's compiler? Which differences would a user experience? Would
it produce code faster? Would it produce faster code?
The fact that gcc may look ugly inside (haven't checked myself)
doesn't seem to bother the C/C++ developers very much.
BTW, there are popular scripting languages which lack a compiler.
Some of them are cute (in some way), but extremely slow in execution.
I believe, with these languages there is a demand for a compiler. If
someone (I'm very general because I cannot be the one:) wrote a
Lisp-based compiler for such a scripting language, and if people
started using it, and if they started to port libraries to the
underlying Lisp-platform, it might become a "big possible coup" for
Lisp.
Matthias wrote:
> In what way would a Lisp-based C/C++ compiler be "superior" to gcc or
> Intel's compiler? Which differences would a user experience? Would
> it produce code faster? Would it produce faster code?
>
> The fact that gcc may look ugly inside (haven't checked myself)
> doesn't seem to bother the C/C++ developers very much.
gcc's internal ugliness reduces the rate at which improvements
can be made. As a result, gcc is slow (and getting slower)
and produces inferior code compared to its commercial
platform-specific competitors.
Paul
Matthias wrote:
> In what way would a Lisp-based C/C++ compiler be "superior" to gcc or
> Intel's compiler? Which differences would a user experience? Would
> it produce code faster? Would it produce faster code?
>
> The fact that gcc may look ugly inside (haven't checked myself)
> doesn't seem to bother the C/C++ developers very much.
>
I understand these as rhetorical questions, and I also doubt that this
will have a strong effect on members of other communities. Writing a
C/C++ compiler is hard and takes a high investment in terms of time and
people, most probably also in Lisp. The result will most likely have
incompatibilities, and it would be too easy to blame Lisp for these
problems. The advantages wouldn't be that clear, especially since there
already exist incremental compilers for C++, AFAIK.
Making CLIM look more flashy should be more worthwhile. ;)
> BTW, there are popular scripting languages which lack a compiler.
> Some of them are cute (in some way), but extremely slow in execution.
> I believe, with these languages there is a demand for a compiler. If
> someone (I'm very general because I cannot be the one:) wrote a
> Lisp-based compiler for such a scripting language, and if people
> started using it, and if they started to port libraries to the
> underlying Lisp-platform, it might become a "big possible coup" for
> Lisp.
On the one hand, you're right. Most scripting languages are only
interpreted at the moment, so a Common Lisp based execution environment
would be cool to speeed them up. It should be rather easy to achieve
this by making use of macros to essentially build just-in-time compilers
for those languages. On the other hand, many of those scripting
languages seem to make the wrong decisions wrt technical details. For
example, most of them seem to be Lisp-1, and many of them have adopted
continuations or else are considering to include continuations (i.e.
call/cc). [1]
This will cause some problems wrt mixed use of libraries from different
languages. It's probably simpler to base something like this on Scheme.
AFAIR, someone is already integrating Python into Scheme. And Parrot
will probably be able to host Scheme as well.
Since scripting languages are moving targets anyway, why not create a
new scripting language that more or less has the feature set of Common
Lisp. Maybe with a Dylan-like syntax. Then we could claim to have the
newest buzzword-compatible language around. Better than those 10-year
old senile beasts. :}
Pascal
[1] "Wrong" here means: wrong for being implemented on top of Common Lisp.
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza wrote:
> Since scripting languages are moving targets anyway, why not create a
> new scripting language that more or less has the feature set of Common
> Lisp. Maybe with a Dylan-like syntax. Then we could claim to have the
> newest buzzword-compatible language around. Better than those 10-year
> old senile beasts. :}
Why not just write a good M-expression parser and tack it onto Common
Lisp? All the power and elegance of Lisp without all the parentheses,
and people might give it a shot for scripting.
Ari Johnson <·····@hotmail.com> writes:
> Why not just write a good M-expression parser and tack it onto
> Common Lisp? All the power and elegance of Lisp without all the
> parentheses, and people might give it a shot for scripting.
There's a long history of this with M-expressions, R-expressions, the
#I infix package, Dylan, etc. They rarely catch on. In fact, I've
never heard that any of them did, except Dylan, which has an active
community.
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
Lars Brinkhoff wrote:
> There's a long history of this with M-expressions, R-expressions, the
> #I infix package, Dylan, etc. They rarely catch on. In fact, I've
> never heard that any of them did, except Dylan, which has an active
> community.
What's an R-expression?
Ari Johnson <·····@hotmail.com> writes:
> Lars Brinkhoff wrote:
> > There's a long history of this with M-expressions, R-expressions, the
> > #I infix package, Dylan, etc.
> What's an R-expression?
Sorry, that should be RLISP. It's an Algol-like syntax used in the
implementation of Portable Standard Lisp and the REDUCE package. For
more info:
http://groups.google.com/groups?q=rlisp
(A connection back to the original topic is that Stan Shebs was once a
PSL maintainer, and is now a major GCC hacker.)
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
In article <··············@junk.nocrew.org>,
Lars Brinkhoff <·········@nocrew.org> wrote:
> Ari Johnson <·····@hotmail.com> writes:
> > Why not just write a good M-expression parser and tack it onto
> > Common Lisp? All the power and elegance of Lisp without all the
> > parentheses, and people might give it a shot for scripting.
>
> There's a long history of this with M-expressions, R-expressions, the
> #I infix package, Dylan, etc. They rarely catch on. In fact, I've
> never heard that any of them did, except Dylan, which has an active
> community.
Active but small :-( There are maybe half a dozen of us making regular
contributions to Gwydion Dylan, and each new release (roughly
twice-yearly over the last five years) attracts only several hundred
downloads.
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> Active but small :-( There are maybe half a dozen of us making regular
> contributions to Gwydion Dylan, and each new release (roughly
> twice-yearly over the last five years) attracts only several hundred
> downloads.
I'd be a *lot* more interested in it if it had parenthesis.
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu>
wrote:
> Bruce Hoult <·····@hoult.org> writes:
>
> > Active but small :-( There are maybe half a dozen of us making regular
> > contributions to Gwydion Dylan, and each new release (roughly
> > twice-yearly over the last five years) attracts only several hundred
> > downloads.
>
> I'd be a *lot* more interested in it if it had parenthesis.
Since parentheses are so much easier to handle than not-parentheses, it
should be pretty trivial to write a parser of parentheses syntax (to
either not-parentheses, or to the internal parse tree), right?
If someone cares to write such a beast, I will personally check it into
the Gwydion CVS for you.
You're not going to get 'eval', regardless, of course.
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> Since parentheses are so much easier to handle than not-parentheses, it
> should be pretty trivial to write a parser of parentheses syntax (to
> either not-parentheses, or to the internal parse tree), right?
>
> If someone cares to write such a beast, I will personally check it into
> the Gwydion CVS for you.
I'll put some thought into it, but I cannot promise it anytime soon.
> You're not going to get 'eval', regardless, of course.
I don't mind. It ought to be reasonably easy to write an evaluator
for Dylan in Dylan, no?
--
~jrm
In article <············@comcast.net>,
Joe Marshall <·············@comcast.net> wrote:
> Bruce Hoult <·····@hoult.org> writes:
>
> > Since parentheses are so much easier to handle than not-parentheses, it
> > should be pretty trivial to write a parser of parentheses syntax (to
> > either not-parentheses, or to the internal parse tree), right?
> >
> > If someone cares to write such a beast, I will personally check it into
> > the Gwydion CVS for you.
>
> I'll put some thought into it, but I cannot promise it anytime soon.
This is open source. It's done when it's done. There is no schedule.
> > You're not going to get 'eval', regardless, of course.
>
> I don't mind. It ought to be reasonably easy to write an evaluator
> for Dylan in Dylan, no?
We actually have the start of one built into the d2c compiler as an
experiment (on the GD_2_5 branch). It allows you to enter a Dylan
expression which is then lexed, parsed, optimized, and then the
optimized parse tree is interpreted.
It might be interesting one day to break this functionality out into a
library that could be linked into any program.
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> Lars Brinkhoff <·········@nocrew.org> wrote:
> > Dylan [...] has an active community.
> Active but small :-( There are maybe half a dozen of us making regular
> contributions to Gwydion Dylan, and each new release (roughly
> twice-yearly over the last five years) attracts only several hundred
> downloads.
I'm sorry to hear that. I had an impression there would be more Dylan
programmers around since the heydays, what with Apple's involvement,
Fun'O and all.
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
Ari Johnson wrote:
> Pascal Costanza wrote:
>
>> Since scripting languages are moving targets anyway, why not create a
>> new scripting language that more or less has the feature set of Common
>> Lisp. Maybe with a Dylan-like syntax. Then we could claim to have the
>> newest buzzword-compatible language around. Better than those 10-year
>> old senile beasts. :}
>
> Why not just write a good M-expression parser and tack it onto Common
> Lisp? All the power and elegance of Lisp without all the parentheses,
> and people might give it a shot for scripting.
Many people have already done this. Go ahead, just do it. You'll be
surprised. ;)
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Ari Johnson wrote:
> Pascal Costanza wrote:
>
>> Since scripting languages are moving targets anyway, why not create a
>> new scripting language that more or less has the feature set of Common
>> Lisp. Maybe with a Dylan-like syntax. Then we could claim to have the
>> newest buzzword-compatible language around. Better than those 10-year
>> old senile beasts. :}
>
> Why not just write a good M-expression parser and tack it onto Common
> Lisp? All the power and elegance of Lisp without all the parentheses,
> and people might give it a shot for scripting.
You cannot get the power and elegance of Lisp without all the parentheses.
Google for "those parentheses are there for a reason".
See also http://www.paulgraham.com/syntaxquestion.html
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> writes:
> You cannot get the power and elegance of Lisp without all the
> parentheses.
>
> Google for "those parentheses are there for a reason".
>
> See also http://www.paulgraham.com/syntaxquestion.html
On the other hand, precisely because Lisp makes it easy to play with
program representations, it is always easy for the novice to
experiment with alternative notations. Therefore we expect future
generations of Lisp programmers to continue to reinvent Algol-style
syntax for Lisp, over and over and over again, and we are equally
confident that they will continue, after an initial period of
infatuation, to reject it. (Perhaps this process should be regarded as
a rite of passage for Lisp hackers.)"
- Steele and Gabriel, "The Evolution of Lisp"
That is what they said, and although I'm a newbie, I agree. I've been
interested in Lisp for just some weeks to now, but really, parentheses
is not a so bad thing and when you read some code your eyes/mind
rapidly can "parse" them. :)
--
�� javuchi ��
javuchi <······@nospam.com> writes:
> That is what they said, and although I'm a newbie, I agree. I've been
> interested in Lisp for just some weeks to now, but really, parentheses
> is not a so bad thing and when you read some code your eyes/mind
> rapidly can "parse" them. :)
Let me get this right: you have been using lisp for 'some weeks', and yet a
week or so ago you were authoritativly telling people how a lisp editor
should work?
Just checking.
S.
ps: glad to hear you got over the parenthesis thing quickly --- it really
doesn't seem to take long for anyone who actually sits down and codes for
a bit, rather than complaining about parenthesis....
Pascal Costanza <········@web.de> wrote:
+---------------
| Since scripting languages are moving targets anyway, why not create a
| new scripting language that more or less has the feature set of Common Lisp.
+---------------
Maybe I don't understand, but why not just *use* Common Lisp for
"scripting"?!? I do it all the time, very happily...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Pascal Costanza <········@web.de> wrote:
> +---------------
> | Since scripting languages are moving targets anyway, why not create a
> | new scripting language that more or less has the feature set of Common Lisp.
> +---------------
>
> Maybe I don't understand, but why not just *use* Common Lisp for
> "scripting"?!? I do it all the time, very happily...
I understand this thread being about marketing stunts, not real
technical merits. That's probably why noone seriously bothers to write this.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
····@rpw3.org (Rob Warnock) writes:
> Pascal Costanza <········@web.de> wrote:
> +---------------
> | Since scripting languages are moving targets anyway, why not create a
> | new scripting language that more or less has the feature set of Common Lisp.
> +---------------
>
> Maybe I don't understand, but why not just *use* Common Lisp for
> "scripting"?!? I do it all the time, very happily...
I work in an environment where hundreds of people with no real
computing expertise (or, in many cases, real inerest) need to write
small programs (scripts) to select event data, send them off to
various destinations, based on various criteria that they code up.
Currently they are expected to do this in C++. Clearly this is wrong.
In my opinion, Python is much more suitable than Lisp _for this
audience_ and _in this context_, (almost) purely because of of the way
it looks.
That's why I reckon a simple facade (eg Python) for Common Lisp would
be worthwhile: Implementors can use the full power of CL; users have
access to the functionality provided by the implementors, via a
language which is easy to learn and use.
I see it a bit like OS X ... the pretty, user-friendly, but hollow
interface provided by Mac OS was joined with the solid but "unuseable"
functional core of BSD. Both sides gain.
····@rpw3.org (Rob Warnock) writes:
> Pascal Costanza <········@web.de> wrote:
> +---------------
> | Since scripting languages are moving targets anyway, why not create a
> | new scripting language that more or less has the feature set of Common Lisp.
> +---------------
>
> Maybe I don't understand, but why not just *use* Common Lisp for
> "scripting"?!? I do it all the time, very happily...
Allow me to echo this sentiment. There are a few utilities that
you'll want to write, but once you have them, the rest becomes a lot
easier than you'd think.
--
~jrm
Joe Marshall <·············@comcast.net> writes:
> Allow me to echo this sentiment. There are a few utilities that
> you'll want to write, but once you have them, the rest becomes a lot
> easier than you'd think.
Actually, since I spent the day "scripting in CL", as it was
just too painful to try to remember all the @···@%! /bin/sh syntax,
perhaps these common utilities should be packaged up and submitted,
say, to CLIKI? Heck, just posting them to this group would be
a great start.
_IF_ you are at liberty and willing to do so, of course. I don't
meant to pressure you into anything; just noting it since it may
not have crossed your mind that these "trivial utils I once wrote"
may be of interest to any others.
Cheers,
--ap
Alain Picard <···························@memetrics.com> wrote:
+---------------
| Joe Marshall <·············@comcast.net> writes:
| > Allow me to echo this sentiment. There are a few utilities that
| > you'll want to write, but once you have them, the rest becomes a lot
| > easier than you'd think.
|
| Actually, since I spent the day "scripting in CL", as it was
| just too painful to try to remember all the @···@%! /bin/sh syntax,
| perhaps these common utilities should be packaged up and submitted,
| say, to CLIKI? Heck, just posting them to this group would be
| a great start.
+---------------
Bear in mind that the utilities you end up needing/using are typically
*very* platform-specific [and by "platform" I include both the CL
implementation and the operating system] and application-specific.
But just to get us started, here's one small example...
ANSI CL provides no standard way to read a single TTY character without
echoing it or requiring a newline, something one often needs to do when
coding the usual "more"-like pager or "curses"-like menu interaction.
Here's one cut at it that works well enough for me in CMUCL-18e on
FreeBSD 4.x:
#| What "less" does:
s.c_lflag &= ~(ICANON|ECHO|ECHOE|ECHOK|ECHONL);
s.c_oflag |= (OPOST|ONLCR|TAB3);
s.c_oflag &= ~(OCRNL|ONOCR|ONLRET);
s.c_cc[VMIN] = 1;
s.c_cc[VTIME] = 0;
|#
(use-package :alien)
(use-package :unix)
(defun read-char-no-echo-cbreak (&optional (stream *query-io*))
(with-alien ((old (struct termios))
(new (struct termios)))
(let ((e0 (unix-tcgetattr 0 old))
(e1 (unix-tcgetattr 0 new))
(bits (logior tty-icanon tty-echo tty-echoe tty-echok tty-echonl)))
(declare (ignorable e0 e1))
(unwind-protect
(progn
(setf (slot new 'c-lflag) (logandc2 (slot old 'c-lflag) bits))
(setf (deref (slot new 'c-cc) vmin) 1)
(setf (deref (slot new 'c-cc) vtime) 0)
(unix-tcsetattr 0 tcsadrain new)
(read-char stream))
And a helper routine that uses it:
(defun space-or-q-p (&optional (prompt "[More... (q to quit)] "))
(format *query-io* "~A" prompt)
(force-output *query-io*)
(let* ((c (read-char-no-echo-cbreak *query-io*))
(bs (make-string (1+ (length prompt)) :initial-element #\backspace))
(sp (make-string (1+ (length prompt)) :initial-element #\space)))
(format *query-io* "~A~A~A" bs sp bs) ; Erase the prompt.
(force-output *query-io*)
(char-equal c #\q)))
which would be used in a "pager" something like this [untested fragment]:
(loop for line = (get-next-line)
and line-num from 1
do (format t "~a~%" line)
(when (and (zerop (mod line-num page-length))
(space-or-q-p))
(return (values))))
The above code conses excessively in a couple of places, and could
certainly be optimized and/or cleaned up further [e.g., LOAD-TIME-VALUE
in a couple of places would help].
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Pascal Costanza <········@web.de> writes:
> It should be rather easy to achieve this by making use of macros to
> essentially build just-in-time compilers for those languages. On the
> other hand, many of those scripting languages seem to make the wrong
> decisions wrt technical details. For example, most of them seem to
> be Lisp-1, and many of them have adopted continuations or else are
> considering to include continuations (i.e. call/cc). [1]
> [1] "Wrong" here means: wrong for being implemented on top of Common Lisp.
If it's really "easy" to get, let's say, Python/ Perl/ Ruby on top of
CL and if it executed noticeably faster people would probably start
using it (even when the libraries coming with Python/ Perl/ Ruby are
not available at the beginning) and some would get interested in its
implementation.
> Since scripting languages are moving targets anyway, why not create a
> new scripting language that more or less has the feature set of Common
> Lisp. Maybe with a Dylan-like syntax. Then we could claim to have the
> newest buzzword-compatible language around. Better than those 10-year
> old senile beasts. :}
Inventing another new-and-better scripting language would be nice and
I'm sure many Lispers would love doing it. But it would miss my main
point: There /already are large communities/ out there using some
decent-but-not-perfect languages. They like their languages quite a
lot. They spent time and effort learning them. They even write parts
of their software in C to get adequate runtime performance and still
be able to use their languages most of the time.
It would require a huge marketing effort and strong arguments to
/create a new community/ for the new-and-better scripting language. I
would guess that the chances that this fails are noticeably larger
than if you just say: "Oh, by the way, I implemented CLPython. It's
exactly like Python or JPython but 10-100 times faster. I could use a
helping hand porting some libs to <CL implementation> so that I can
use them within CLPython."
If any Lispers are interested in implementing an "inferior" language
is a whole different story, of course. I just thought in this
direction when reading that some are interested in writing a new gcc.
Matthias <··@spam.pls> writes:
> It would require a huge marketing effort and strong arguments to
> /create a new community/ for the new-and-better scripting language. I
> would guess that the chances that this fails are noticeably larger
> than if you just say: "Oh, by the way, I implemented CLPython. It's
> exactly like Python or JPython but 10-100 times faster. I could use a
> helping hand porting some libs to <CL implementation> so that I can
> use them within CLPython."
Exactly.
I've been thinking about the possibilities of a "Lython" for ages.
I am now involved in work whose aim is to protect innocent people from
C++. This is being done by interposing Python, and it has made it
painfully clear that the greatest challenge of Lython would be its
loss of the "Included Batteries", all the standard and third-party
libraries for Python which are coded in C or C++, and an increase in
the difficulty of linking to existing C and C++ libraries[1].
We can sell Python as the interface, as long as people can continue to
use the functionality of their existing C and C++ code, via that
interface.
Of course, given that a CL-based Python would come with a native
compiler, the need to write extension modules would be much smaller,
and the simplest way, for a Pythoneer, of porting the extension
modules to <CL implementation> would probably be to write them in pure
Lython ... that doesn't mitigate the overall situation that much, but
it could help in individual cases.
But, looking at it from a different point of view, Lython would look
like Python, but it would run much faster, and it would actually _be_
Lisp.
Why should I care? Well, now I would be able to scriptable libraries
in Lisp, but disguise them in Python's clothing. Those who fear
Lisp[2] need never really be aware that it is Lisp.
It is often said that Common Lisp is a language for experts. But I
think that it is quite reasonable to try to provide a scripitng
interface for non-experts, to functionality developed in Lisp. Python
seems like an excellent candidate for that job.
[1] Though I've recently heard that SWIG has some support for UFFI.
[2] Fire-breathing parentheses, sabre-toothed arcane names, etc.
Jacek Generowicz <················@cern.ch> writes:
> Of course, given that a CL-based Python would come with a native
> compiler, the need to write extension modules would be much smaller,
> and the simplest way, for a Pythoneer, of porting the extension
> modules to <CL implementation> would probably be to write them in pure
> Lython ... that doesn't mitigate the overall situation that much, but
> it could help in individual cases.
I would say that "magic native compiler pee" is not enough to make a
hypothetical Lython go significantly faster than Python's existing C
implementation.
Of course, developing a sufficiently smart implementation to go really
fast is probably easier in CL (or Python...) than in C.
Cheers,
mwh
--
You owe the Oracle a star-spangled dunce cap.
-- Internet Oracularity Internet Oracularity #1299-08
Michael Hudson <···@python.net> writes:
> Jacek Generowicz <················@cern.ch> writes:
>
>> Of course, given that a CL-based Python would come with a native
>> compiler, the need to write extension modules would be much smaller,
>> and the simplest way, for a Pythoneer, of porting the extension
>> modules to <CL implementation> would probably be to write them in pure
>> Lython ... that doesn't mitigate the overall situation that much, but
>> it could help in individual cases.
>
> I would say that "magic native compiler pee" is not enough to make a
> hypothetical Lython go significantly faster than Python's existing C
> implementation.
Oh, but it is... for a silly example like fibonacci, OpenMCL
is about 50 times faster than Python. If your Python code is just a
thin wrapper around something implemented in C/C++, you obviously
aren't going to see this sort of improvement, but for code written
mainly in Python, going for native code should be a win.
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
Raymond Wiker <·············@fast.no> writes:
> Michael Hudson <···@python.net> writes:
>
> > Jacek Generowicz <················@cern.ch> writes:
> >
> >> Of course, given that a CL-based Python would come with a native
> >> compiler, the need to write extension modules would be much smaller,
> >> and the simplest way, for a Pythoneer, of porting the extension
> >> modules to <CL implementation> would probably be to write them in pure
> >> Lython ... that doesn't mitigate the overall situation that much, but
> >> it could help in individual cases.
> >
> > I would say that "magic native compiler pee" is not enough to make a
> > hypothetical Lython go significantly faster than Python's existing C
> > implementation.
>
> Oh, but it is...
No, really, it isn't.
> for a silly example like fibonacci, OpenMCL is about 50
> times faster than Python.
The big problem is runtime uncertainty; in compiling something like
a + b
you really don't know much about a or b: they could be integers,
floats, longs (bignums), strings, user-defined types, lists, or
tuples, at least. It's hard to compile it to anything other than the
moral equivalent of
PyObject_Add(a, b); /* or maybe (py:object-add a b) */
Sure, you can dispense with the interpreter overhead, but that's
usually only around 20%.
There are ways of doing better, of course, but they go well beyond
"magic native compiler pee".
> If your Python code is just a thin wrapper around something
> implemented in C/C++, you obviously aren't going to see this sort of
> improvement, but for code written mainly in Python, going for native
> code should be a win.
I await your implementation.
Cheers,
mwh
--
If you're talking "useful", I'm not your bot.
-- Tim Peters, 08 Nov 2001
Michael Hudson <···@python.net> writes:
> I would say that "magic native compiler pee" is not enough to make a
> hypothetical Lython go significantly faster than Python's existing C
> implementation.
No, but it should make pure Python modules go significantly faster.
> Of course, developing a sufficiently smart implementation to go really
> fast is probably easier in CL (or Python...) than in C.
... which is what the PyPy effort is about.
Jacek Generowicz <················@cern.ch> writes:
> Michael Hudson <···@python.net> writes:
>
> > I would say that "magic native compiler pee" is not enough to make a
> > hypothetical Lython go significantly faster than Python's existing C
> > implementation.
>
> No, but it should make pure Python modules go significantly faster.
As I said to Raymond, I don't actually think so.
> > Of course, developing a sufficiently smart implementation to go really
> > fast is probably easier in CL (or Python...) than in C.
>
> ... which is what the PyPy effort is about.
Indeed! PyPy already has a very simple Python-to-CL translator, but
there are many things between where we are now and something useful...
Cheers,
mwh
--
I think my standards have lowered enough that now I think ``good
design'' is when the page doesn't irritate the living fuck out of
me. -- http://www.jwz.org/gruntle/design.html
Michael Hudson <···@python.net> writes:
> PyPy already has a very simple Python-to-CL translator
Would it be interesting or relevant to say something about this, and
how it fits into the grand PyPy scheme, in this forum ?
Jacek Generowicz <················@cern.ch> writes:
> Michael Hudson <···@python.net> writes:
>
> > PyPy already has a very simple Python-to-CL translator
>
> Would it be interesting or relevant to say something about this, and
> how it fits into the grand PyPy scheme, in this forum ?
Maybe... as I tried to say, it's little more than a proof of concept
at the moment (as indeed are PyPy's Python-to-anything translators).
You can see the code at
http://codespeak.net/svn/pypy/trunk/src/pypy/translator/gencl.py
(it and the code it produces are far from pretty).
As to where it fits in the "grand PyPy scheme", whatever that turns
out to be... unclear. We'll probably keep it working, but I don't
know how many of the other PyPy hackers are that interested in working
on it (gencl as it is today is mostly the work of Seo Sanghyeon).
Cheers,
mwh
--
In the 1950s and 60s there was a regular brain drain of young
Australians from the cities to London, but it was because of
money, culture and opportunity, not spiders.
-- Al Grant, ucam.chat, from Owen Dunn's review of the year
Jacek Generowicz wrote:
> I've been thinking about the possibilities of a "Lython" for ages.
Think also about the actual outcome of Dylan.
>
> I am now involved in work whose aim is to protect innocent people from
> C++.
The Mother Teresa of programmers!
> But, looking at it from a different point of view, Lython would look
> like Python, but it would run much faster, and it would actually _be_
> Lisp.
_be_ in what sense? Would you expose CL to the Lythonista? I guess ala
Jython it would be easier for Lythonistas to use CL libraries, except
there aren't any. Except Cello. RSN.
>
> Why should I care? Well, now I would be able to scriptable libraries
> in Lisp, but disguise them in Python's clothing. Those who fear
> Lisp[2] need never really be aware that it is Lisp.
Your fear of the fear of others of parentheses is unjustified. The
parens are /not/ the problem (see "Dylan").
>
> It is often said that Common Lisp is a language for experts.
Methinks "often" does not entail "true that", and you are betting a huge
effort on this myth. The way to save folks from C++ is to help CL grow,
by doing FFI work to expose more libs. Don't bother with OpenGL, FGLT,
or ImageMagick, they're in the bag. And make sure you brag about any
libraries you make available to CLers here on c.l.l. -- Brian loves that
kind of stuff.
:)
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
> The way to save folks from C++ is to help CL grow, by
> doing FFI work to expose more libs. Don't bother with
> OpenGL, FGLT, or ImageMagick, they're in the bag.
This is exciting news to me. I am writing a CL program to
convert images to counted cross-stitch patterns. (Strictly
speaking I failing to get started on such a program, see my
post about length limits in CLX) I use ImageMagick to
convert the image to a file of RGB bytes, then read than
into my CL program. It would be much cooler to have my
program use ImageMagick as a library.
Googling "Lisp CL interface to ImageMagick" gets me 1610
hits or none at all. The Cliki graphics libraries' and
graphics toolkits' pages don't reveal the library to my
gaze.
Please tell me where I can find it.
Alan Crowe
----------
CL puts the funk into function
From: Scott Determan
Subject: Re: An implementation of Python in Common Lisp
Date:
Message-ID: <m34qtxmm1l.fsf@yahoo.com>
Alan Crowe <····@cawtech.freeserve.co.uk> writes:
> This is exciting news to me. I am writing a CL program to
> convert images to counted cross-stitch patterns.
Hi Alan,
I don't know what "counted cross-stitch patterns" are, but I am also
experimenting with lisp and image processing. I have bindings to some
of the lti lib
(http://ltilib.sourceforge.net/doc/homepage/index.shtml) and I would
recommend looking at this lib. The bindings are mostly uffi, but I do
use cmu specific stuff to pass images without copying them. I should
mention I ran into a small problem. You need to say:
(set-floating-point-modes :traps nil) ;; umm..yikes!!!!
Or cmucl will not load the lib.
Good Luck,
-Scott
From: Scott Determan
Subject: Re: An implementation of Python in Common Lisp
Date:
Message-ID: <m3znbpl6cm.fsf@yahoo.com>
Alan Crowe <····@cawtech.freeserve.co.uk> writes:
> I use ImageMagick to
> convert the image to a file of RGB bytes, then read than
> into my CL program. It would be much cooler to have my
> program use ImageMagick as a library.
Hi Alan,
I should have put this into my last post, but here's what I use to load
jpeg images. Hopefully you can use it as an example. I'm still a bit new
with lisp, so try not to laugh too hard at my code.
Here's the lisp side:
(This isn't quite complete - I think the only thing that's missing is
my structured-data-set struct).
(uffi:def-function ("get_jpeg_shape" lti-get-jpeg-shape)
((fileName :cstring)
(shape (* :int))
(size :int))
:returning :int)
(defun get-jpeg-shape (file-name)
(let ((op-result 0)
(shape (make-array 3 :element-type '(signed-byte 32))))
(uffi:with-cstring
(file-name-cstring file-name)
(system:without-gcing
(setf op-result
(lti-get-jpeg-shape file-name-cstring
(system:vector-sap shape)
(array-dimension shape 0))))
(values shape op-result))))
(uffi:def-function ("load_jpeg" lti-load-jpeg)
((fileName :cstring)
(shape (* :int))
(size :int)
(pixles (* :unsigned-char)))
:returning :int)
(defun load-jpeg (file-name)
(let* ((op-result 0)
(shape (get-jpeg-shape file-name))
(pixels (make-array (num-atoms-from-shape shape)
:element-type '(unsigned-byte 8))))
(uffi:with-cstring
(file-name-cstring file-name)
(system:without-gcing
(setf op-result
(lti-load-jpeg file-name-cstring
(system:vector-sap shape)
(array-dimension shape 0)
(system:vector-sap pixels)))))
(values (make-structured-data-set :shape shape :data pixels) op-result)))
Here's the C side:
#include <ctype.h>
#include <stdlib.h>
#include <math.h>
#include <vector>
#include "ltilib/ltiJPEGFunctor.h"
#include "ltilib/ltiVector.h"
extern "C" {
int get_jpeg_shape(char* fileName,
int* shape,
int shapeSize/*should be 3*/);
int load_jpeg(char* fileName,
int* shape, /*get this from get_jpeg_shape*/
int shapeSize,
unsigned char* pixels);
int save_jpeg(char* fileName,
int* shape,
int shapeSize,
unsigned char* pixels);
};
int get_jpeg_shape(char* fileName,
int* shape,
int shapeSize/*should be 3*/)
{
if (shapeSize!=3) return 0;
lti::loadJPEG loadJPEGOp;
std::string comment;
lti::point imageSize;
bool isGray;
bool result=
loadJPEGOp.checkHeader(fileName,imageSize,comment,isGray);
if (!result) return 0;
shape[0]=imageSize.y;
shape[1]=imageSize.x;
shape[2]=4; // load grey images as color for now (and there is really only 3)
return 1;
};
int load_jpeg(char* fileName,
int* shape, /*get this from get_jpeg_shape*/
int shapeSize,
unsigned char* pixels)
{
if (shapeSize!=3) return 0;
lti::loadJPEG loadJPEGOp;
lti::image image;
bool result=
loadJPEGOp.load(fileName,image);
lti::rgbPixel* srcPixels=&image.at(0,0);
memcpy(pixels,(unsigned char*)srcPixels,
shape[0]*shape[1]*shape[2]*sizeof(unsigned char));
if (!result) return 0;
return 1;
};
int save_jpeg(char* fileName,
int* shape,
int shapeSize,
unsigned char* pixels)
{
if (shapeSize!=3) return 0;
if (shape[2]!=4) return 0;
const int imageHeight=shape[0];
const int imageWidth=shape[1];
lti::saveJPEG saveJPEGOp;
lti::image image;
image.useExternData(imageHeight,imageWidth,
(lti::rgbPixel*)pixels);
bool result=
saveJPEGOp.save(fileName,image);
if (!result) return 0;
return 1;
};
Alan Crowe wrote:
> Kenny Tilton wrote:
>
>>The way to save folks from C++ is to help CL grow, by
>>doing FFI work to expose more libs. Don't bother with
>>OpenGL, FGLT, or ImageMagick, they're in the bag.
>
>
> This is exciting news to me. I am writing a CL program to
> convert images to counted cross-stitch patterns. (Strictly
> speaking I failing to get started on such a program, see my
> post about length limits in CLX) I use ImageMagick to
> convert the image to a file of RGB bytes, then read than
> into my CL program. It would be much cooler to have my
> program use ImageMagick as a library.
>
> Googling "Lisp CL interface to ImageMagick" gets me 1610
> hits or none at all. The Cliki graphics libraries' and
> graphics toolkits' pages don't reveal the library to my
> gaze.
>
> Please tell me where I can find it.
<sigh> I would Just Mail It(tm) to you but now I am having dark, devious
thoughts about making Cello proprietary/commercial. Now that does not
mean I cannot give away the Imagick FFI bindings, but I have to meditate
on all this a little. This disgusting capitalistic impulse just hit me
this AM when I got the Lighting Panel demo working and I saw how
gorgeous my widgets started to look. Sports Illustrated can have Anna
Kournikova, I've got OpenGL!
BTW, in concordance with the Strandh Doctrine of "no pain, no gain", may
I highly recommend you grab UFFI and undertake a week of pain to open up
the whole world of groovy C libs? The good news is that once you crack
your first lib via the FFI, the rest are just there for the taking. Use
UFFI specifically to get the portability.
kenny das kapitalist?
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<···················@twister.nyc.rr.com>...
>
>
> kenny das kapitalist?
Shame on you, Kenny. In the 24th century, money ceases to exist and
people work for the general improvement of mankind as its own payment.
Henry
EL Henry wrote:
> Kenny Tilton <·······@nyc.rr.com> wrote in message news:<···················@twister.nyc.rr.com>...
>
>>
>>kenny das kapitalist?
>
> Shame on you, Kenny. In the 24th century, money ceases to exist and
> people work for the general improvement of mankind as its own payment.
What's even more shameful is that this isn't correct German.
"Das Kapital", aber "der Kapitalist"
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza wrote:
> EL Henry wrote:
>
>> Kenny Tilton <·······@nyc.rr.com> wrote in message
>> news:<···················@twister.nyc.rr.com>...
>>
>>>
>>> kenny das kapitalist?
>>
>>
>> Shame on you, Kenny. In the 24th century, money ceases to exist and
>> people work for the general improvement of mankind as its own payment.
>
>
> What's even more shameful is that this isn't correct German.
>
> "Das Kapital", aber "der Kapitalist"
:) What's even morer shameful is that correcting the German zaps the
"Das Kapital" resonance and spoils the pfun.
kenny the rekovering kapitalist
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Jacek Generowicz wrote:
> > I've been thinking about the possibilities of a "Lython" for ages.
>
> Think also about the actual outcome of Dylan.
> Your fear of the fear of others of parentheses is unjustified. The
> parens are /not/ the problem (see "Dylan").
Python is getting pretty widely known as a language which is easy to
learn, and yet is very powerful. It is already acceptable (and even
accepted) in many circles. AFAIK Dylan never reached this status.
Dylan's problem was that it took away good features (parentheses) from
those who appreciated Dylan's power, while at the same time was yet
another new language to those who did not. In this respect, Lython
has the advantage that it gives something that two camps know and
love, in one package.
The idea of Lython is to stealthily slide Lisp within reach of those
who already use Python.
> > But, looking at it from a different point of view, Lython would look
> > like Python, but it would run much faster, and it would actually _be_
> > Lisp.
>
> _be_ in what sense?
In the same sense that any language built on Lisp _is_ Lisp.
> Would you expose CL to the Lythonista?
I'd have one option which does its best to hide all trace of Lisp,
and another which allows you to mix the two easily. The hopeful
progression is to start with the former, try the latter, and
eventually drop the Python interface altogether :-)
> Cello. RSN.
I'm glad I wasn't holding my breath :-)
> > It is often said that Common Lisp is a language for experts.
>
> Methinks "often" does not entail "true that",
No, but I believe that it is largely true.
> and you are betting a huge effort on this myth.
It is also a "myth" which is kept alive by the more respected members
of this very NG. And I certainly don't see it as something negative.
> The way to save folks from C++ is to help CL grow, by doing FFI work
> to expose more libs.
While that would undeniably help, it wouldn't help everywhere. I know
that CL will never (well, certainly not within the next 2 decades) be
acceptable in my current environment. If I could interact with a
running CL image using Python's syntax, suddenly many of the major
obstacles disappear.
Python's popularity is largely a result of it being perceived as an
easy language. The set of Python users also contains a higher than
average proportion of good candidates for future Lisp users. A Lython
would bring more of the right sort of people into closer contact with
Lisp.
Jacek Generowicz <················@cern.ch> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>> Jacek Generowicz wrote:
>> > I've been thinking about the possibilities of a "Lython" for ages.
>>
>> Think also about the actual outcome of Dylan.
>
>> Your fear of the fear of others of parentheses is unjustified. The
>> parens are /not/ the problem (see "Dylan").
>
> Python is getting pretty widely known as a language which is easy to
> learn, and yet is very powerful. It is already acceptable (and even
> accepted) in many circles. AFAIK Dylan never reached this status.
There already seems to be a Lython:
<http://www.caddr.com/code/lython/>. This one appears to be the
converse of what you want: it seems to be an attempt at a Common Lisp
syntax onto Python.
[...]
>> Would you expose CL to the Lythonista?
>
> I'd have one option which does its best to hide all trace of Lisp,
> and another which allows you to mix the two easily. The hopeful
> progression is to start with the former, try the latter, and
> eventually drop the Python interface altogether :-)
This has been tried before. It seems like a logical idea, but doesn't
really seem to work, for whatever reasons. It was the idea behind
GEL, for example (which became Guile): build a nice compilable
language, and sit more familiar syntaxes on top of it, and then Tcl
people can use Tcl syntax, and Perl people can use Perl syntax.
[...]
Bruce Stephens <············@cenderis.demon.co.uk> writes:
> There already seems to be a Lython:
> <http://www.caddr.com/code/lython/>. This one appears to be the
> converse of what you want: it seems to be an attempt at a Common Lisp
> syntax onto Python.
Yes, I had noticed that one before, and yes, it strikes me as
completely upside down. If I _want_ a Lisp syntax why not just use
Lisp? Maybe it's a way of introducing macros into Python to easy your
own development process, while allowing you to deliver in Python.
Jacek Generowicz <················@cern.ch> writes:
> Bruce Stephens <············@cenderis.demon.co.uk> writes:
>
> > There already seems to be a Lython:
> > <http://www.caddr.com/code/lython/>. This one appears to be the
> > converse of what you want: it seems to be an attempt at a Common Lisp
> > syntax onto Python.
>
> Yes, I had noticed that one before, and yes, it strikes me as
> completely upside down. If I _want_ a Lisp syntax why not just use
> Lisp? Maybe it's a way of introducing macros into Python to easy your
> own development process, while allowing you to deliver in Python.
It's the libraries.
The advantage of a Lisp on top of Python would be that you have all of
Python's libs immediately available. That would make it a really
interesting platform for Lisp-scripting. The big question is whether
runtime performance would be acceptable.
Matthias <··@spam.pls> writes:
> The advantage of a Lisp on top of Python would be that you have all of
> Python's libs immediately available. That would make it a really
> interesting platform for Lisp-scripting. The big question is whether
> runtime performance would be acceptable.
So, it's all about adding code-as-data to Python ?
Jacek Generowicz <················@cern.ch> writes:
> Matthias <··@spam.pls> writes:
>
> > The advantage of a Lisp on top of Python would be that you have all of
> > Python's libs immediately available. That would make it a really
> > interesting platform for Lisp-scripting. The big question is whether
> > runtime performance would be acceptable.
>
> So, it's all about adding code-as-data to Python ?
Don't know. You asked two posts ago: "If I _want_ a Lisp syntax why not
just use Lisp?"
For me, the number one reason not to use Lisp more often is that the
libs I need aren't there [1]. Conversely, my number one reason not to
use Python more often is that it's too slow...
----
[1] I've tried UFFI twice but never came much beyond trying to get the
general picture by reading its documentation or searching for code
samples.
On 12 Feb 2004 15:23:15 +0100, Matthias <··@spam.pls> wrote:
> I've tried UFFI twice but never came much beyond trying to get the
> general picture by reading its documentation or searching for code
> samples.
<http://uffi.b9.com/links.html>
lists a bunch of libraries which use UFFI. This might be a good place
to start.
Edi.
Edi Weitz <···@agharta.de> writes:
> On 12 Feb 2004 15:23:15 +0100, Matthias <··@spam.pls> wrote:
> > I've tried UFFI twice but never came much beyond trying to get the
> > general picture by reading its documentation or searching for code
> > samples.
>
> <http://uffi.b9.com/links.html>
>
> lists a bunch of libraries which use UFFI. This might be a good place
> to start.
Thank you.
Matthias wrote:
> For me, the number one reason not to use Lisp more often is that the
> libs I need aren't there [1]. Conversely, my number one reason not to
> use Python more often is that it's too slow...
>
> ----
> [1] I've tried UFFI twice but never came much beyond trying to get the
> general picture by reading its documentation or searching for code
> samples.
What got me jump-started on FFI was th cl-sdl project (and gracious help
from Matthew Danish), which uses UFFI (tho IIRC they do something fancy
like have macros targeted at a specific FFI which write the UFFI which
writes....), so you have to do some macro-expanding. Sorry if I botched
all that.
Cello has a weird layer of simple macros which let one do
straightforward global editing of .h files (such as simply deleting all
commas) such that the macros expand into UFFI code. It is half
automatic, half manual, and I just duck the hard API calls, but I am
happily using lotsa libs now. Really great libs. :)
Assuming the pinko commie impulse in me prevails, you can check out
Cello RSN if only for the UFFI and UFFI wrappers.
kenny
ps. It does help to know C. And I hate to say anything positive about
MS, but if I build a DLL with VC++ in debug and then stick
"assert(false)" at the start of a C function called from Lisp (well, ACL
is the one I have done this with, probably others too) then the VC++
debugger will open up when I hit that so I can check out the parameters
I just passed in. I even cooked up a test function to pass in a dozen
parameters of different kinds to quickly verify my FFI was working.
pps. I did not die on the treadmill, but I did decide to re-engineer
sliders so I could have a 2D slider. 1D sliders almost back, then 2D,
and then the lighting panel will let you move the lights around as well
as tweak their ambience, diffusion, and specular. If I am able to resist
the temptation to do a 3D slider, screenshots by tonight.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: Erik Winkels
Subject: Re: The Joy of UFFI [was Re: An implementation of Python in Common Lisp]
Date:
Message-ID: <87ptckp8lf.fsf@xs4all.nl>
Kenny Tilton <·······@nyc.rr.com> wrote on Thu, 12 Feb 2004 16:04:14 GMT:
>
> What got me jump-started on FFI was th cl-sdl project (and gracious
> help from Matthew Danish), which uses UFFI (tho IIRC they do
> something fancy like have macros targeted at a specific FFI which
> write the UFFI which writes....), so you have to do some
> macro-expanding. Sorry if I botched all that.
They might do that now, but as far as I can recall the first UFFI
version of cl-sdl was pretty straight-forward (at least the one I made
and I think you got started with that one). I've still got that
version somewhere on my harddisk of the OP is interested.
As someone else mentioned in this thread: just grab some projects that
use UFFI, it's the best way to learn it. It's not that difficult.
You might also use the CMUCL FFI as a stepping stone and learn that
first. That's what I did, because the documentation was pretty okey:
http://www.ljosa.com/~ljosa/doc/encycmuclopedia/devenv/cmu-user/aliens.html
http://www.ljosa.com/~ljosa/doc/encycmuclopedia/index.html#userman
BTW. is there a step by step example of using a foreign code with UFFI
available? (I haven't looked yet, sorry, I really have to get
back to work :) If not, I volunteer to write one.
cheers,
Erik
From: rmagere
Subject: Re: The Joy of UFFI [was Re: An implementation of Python in Common Lisp]
Date:
Message-ID: <c0gct6$e5s$1@news.ox.ac.uk>
Erik Winkels wrote:
> BTW. is there a step by step example of using a foreign code with UFFI
> available? (I haven't looked yet, sorry, I really have to get
> back to work :) If not, I volunteer to write one.
>
By the way does the latest version of UFFI not work with ACL v5.0.1 under
WindowsXP (the website says that it's compatible with ACL v6.2 under
WindowsXP).
As when I run: (asdf:operate 'asdf:load-op :uffi)
I get the following error message:
Error: keyword list (:RETURNING :UNSIGNED-INT :CALL-DIRECT T
:STRINGS-CONVERT NIL) should only contain keys (:OPTIMIZE-FOR-SPACE
:ARG-CHECKING :RELEASE-HEAP :METHOD-INDEX :RETURNING :CONVENTION :CALLBACK
:CALL-DIRECT)
[condition type: PROGRAM-ERROR]
Jacek Generowicz wrote:
> The idea of Lython is to stealthily slide Lisp within reach of those
> who already use Python.
Do you think it would be acceptable to change some things in Lython? For
example, using lists instead of vectors for what they call lists? Or,
for example, switch to CLOS classes instead of hashtable-based classes?
Switch to a Lisp-2?
How much porting work would the typical Pythonista accept? For example,
is it possible in JPython to change the superclass of an object at
runtime? Or did they stick to the Java object model? Does this bother
Python fans?
Or would they rather prefer to have exactly the same features and
semantics as they are used to in the original Python implementation?
Here's another question: Should something like Lython be a JIT compiler
for Python bytecode, or rather a Python-2-CL compiler?
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> writes:
[...]
> How much porting work would the typical Pythonista accept?
It would depend, I guess. People who want a better (faster, etc.)
Python to replace CPython would typically want no porting, I imagine.
Someone coming to a new application, and wanting to extend it with a
familiar syntax would probably worry less. As I said, however this
has been proposed before, and (for several reasons, I suspect) it just
never seemed to catch on.
[...]
Pascal Costanza <········@web.de> writes:
> Jacek Generowicz wrote:
>
> > The idea of Lython is to stealthily slide Lisp within reach of those
> > who already use Python.
>
> Do you think it would be acceptable to change some things in Lython?
These sorts of questions have been popping up in my mind too, and I
don't have any good answers for most of them.
> For example, using lists instead of vectors for what they call lists?
In this case, no. What they call lists really are vectors. Let's not
get fooled by the name.
> Or, for example, switch to CLOS classes instead of hashtable-based
> classes? Switch to a Lisp-2?
Probably not. This "simplicity" and transparency of the Python object
model is what so many people find attractive about it.
> Or would they rather prefer to have exactly the same features and
> semantics as they are used to in the original Python implementation?
If popularity is your aim, then I suspect that this is the way to go.
> Here's another question: Should something like Lython be a JIT
> compiler for Python bytecode, or rather a Python-2-CL compiler?
I suspect that there are good arguments for both. Though I was
thinking more along the lines of the latter.
Jacek Generowicz wrote:
> Pascal Costanza <········@web.de> writes:
>
>>Do you think it would be acceptable to change some things in Lython?
>
> These sorts of questions have been popping up in my mind too, and I
> don't have any good answers for most of them.
>
>>For example, using lists instead of vectors for what they call lists?
>
> In this case, no. What they call lists really are vectors. Let's not
> get fooled by the name.
ok
>>Or, for example, switch to CLOS classes instead of hashtable-based
>>classes? Switch to a Lisp-2?
>
> Probably not. This "simplicity" and transparency of the Python object
> model is what so many people find attractive about it.
Hmm, it's probably relatively easy to make this switchable, or even
interoperable.
>>Or would they rather prefer to have exactly the same features and
>>semantics as they are used to in the original Python implementation?
>
> If popularity is your aim, then I suspect that this is the way to go.
Yes, probably. I guess that Jython is probably not compatible in some
respects, but people are probably more willing to put up with this. They
wouldn't be as forgiving in the case of a Common Lisp-based Python.
>>Here's another question: Should something like Lython be a JIT
>>compiler for Python bytecode, or rather a Python-2-CL compiler?
>
> I suspect that there are good arguments for both. Though I was
> thinking more along the lines of the latter.
One of the hard things seems to be that there is no real good
documentation of the Python bytecode. How likely is it that they change
details of the bytecode between versions? Is the Python compiler written
in Python or in C? (If it is written in Python, it would probably be
better to base such a thing on bytecode instead of source code.)
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> writes:
> One of the hard things seems to be that there is no real good
> documentation of the Python bytecode. How likely is it that they
> change details of the bytecode between versions? Is the Python
> compiler written in Python or in C? (If it is written in Python, it
> would probably be better to base such a thing on bytecode instead of
> source code.)
It is written in C, but the Python distribution also contains
a Python version, in the "compiler" package. compiler.parseFile()
creates an abstract syntax tree, which can then be traversed. There
are also predefined traversers for analysis and code generation.
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
Raymond Wiker wrote:
> Pascal Costanza <········@web.de> writes:
>
>
>>One of the hard things seems to be that there is no real good
>>documentation of the Python bytecode. How likely is it that they
>>change details of the bytecode between versions? Is the Python
>>compiler written in Python or in C? (If it is written in Python, it
>>would probably be better to base such a thing on bytecode instead of
>>source code.)
>
> It is written in C, but the Python distribution also contains
> a Python version, in the "compiler" package. compiler.parseFile()
> creates an abstract syntax tree, which can then be traversed. There
> are also predefined traversers for analysis and code generation.
If these compilers are compatible to each other, then it's probably
better to make Lython bytecode-based.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> writes:
> Jacek Generowicz wrote:
>
> > Pascal Costanza <········@web.de> writes:
> >
>
> >>Or, for example, switch to CLOS classes instead of hashtable-based
> >>classes? Switch to a Lisp-2?
> >
> > Probably not. This "simplicity" and transparency of the Python object
> > model is what so many people find attractive about it.
>
> Hmm, it's probably relatively easy to make this switchable, or even
> interoperable.
Do you have any specific ideas about this, or is it just a hunch? I
don't even start to see how you would make them interoperable.
> >>Or would they rather prefer to have exactly the same features and
> >>semantics as they are used to in the original Python implementation?
> > If popularity is your aim, then I suspect that this is the way to go.
>
> Yes, probably. I guess that Jython is probably not compatible in some
> respects, but people are probably more willing to put up with
> this. They wouldn't be as forgiving in the case of a Common Lisp-based
> Python.
Yes, but even in the case of Jython, I suspect that every
incompatibility translates into a reduction of users (although every
incompatibility with Java could also translate into a reduction of users).
> One of the hard things seems to be that there is no real good
> documentation of the Python bytecode.
There is at least
http://www.python.org/doc/current/lib/bytecodes.html
> How likely is it that they change details of the bytecode between
> versions?
I suspect that they only add to it ... such as LOAD_CLOSURE, which, I
guess, appeared when nested scopes were introduced.
Having said that, there is one bytecode marked as obsolete. (Elsewhere
I read that the parse trees are typically incompatible between
versions.)
> Is the Python compiler written in Python or in C?
A quick scan of the source tree suggests that its core is written in C.
Jacek Generowicz wrote:
> Pascal Costanza <········@web.de> writes:
>
>>Jacek Generowicz wrote:
>>
>>>Pascal Costanza <········@web.de> writes:
>>
>>>>Or, for example, switch to CLOS classes instead of hashtable-based
>>>>classes? Switch to a Lisp-2?
>>>
>>>Probably not. This "simplicity" and transparency of the Python object
>>>model is what so many people find attractive about it.
>>
>>Hmm, it's probably relatively easy to make this switchable, or even
>>interoperable.
>
> Do you have any specific ideas about this, or is it just a hunch? I
> don't even start to see how you would make them interoperable.
With a working MOP, you can define a metaclass that stores slots in a
"hidden" hashtable. There is a section on how to do this in AMOP. I have
experimented with this a little, and it is very likely also feasible to
build a metaclass that allows to mix several slot allocation styles. It
would boil down to have another slot allocation option in addition to
:class and :instance.
The LispWorks Documentation also has an example that is relatively close.
Of course, things would break when there is no MOP, or it misses certain
features. But again, it should be possible to make this configurable, so
that you have one version that supports interoperability and one that
doesn't.
If you're interested I can send you what I already have via email.
>>>>Or would they rather prefer to have exactly the same features and
>>>>semantics as they are used to in the original Python implementation?
>>>
>>>If popularity is your aim, then I suspect that this is the way to go.
>>
>>Yes, probably. I guess that Jython is probably not compatible in some
>>respects, but people are probably more willing to put up with
>>this. They wouldn't be as forgiving in the case of a Common Lisp-based
>>Python.
>
> Yes, but even in the case of Jython, I suspect that every
> incompatibility translates into a reduction of users (although every
> incompatibility with Java could also translate into a reduction of users).
I guess that many Jython users want to leverage the Java platform but
want to use a more convenient language. In the case of Lython,
leveraging the Common Lisp "platform" wouldn't be an important feature.
Otherwise, they would already have switched to Common Lisp.
>>One of the hard things seems to be that there is no real good
>>documentation of the Python bytecode.
>
> There is at least
>
> http://www.python.org/doc/current/lib/bytecodes.html
Yes, but that's very sparse. For example, the JVM spec is much better in
this regard.
There are other alternatives that come to mind. What about CL-Ruby? An
advantage of Ruby would be that it is even closer in spirit to Lisp and
that it is purely based on source code. However, it seems to be even
more unstable wrt changes to the language spec. It also seems to have a
smaller user base.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> writes:
> With a working MOP, you can define a metaclass that stores slots in a
> "hidden" hashtable. There is a section on how to do this in AMOP. I
> have experimented with this a little, and it is very likely also
> feasible to build a metaclass that allows to mix several slot
> allocation styles. It would boil down to have another slot allocation
> option in addition to :class and :instance.
>
> The LispWorks Documentation also has an example that is relatively close.
>
> Of course, things would break when there is no MOP, or it misses
> certain features. But again, it should be possible to make this
> configurable, so that you have one version that supports
> interoperability and one that doesn't.
I think you can do this without MOP, by using
#'slot-missing... for Python, it is possible to add slots to an object
at any time, which seems like a good fit for hashtable allocation (of
some slots, at least).
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
Raymond Wiker wrote:
> Pascal Costanza <········@web.de> writes:
>
>
>>With a working MOP, you can define a metaclass that stores slots in a
>>"hidden" hashtable. There is a section on how to do this in AMOP. I
>>have experimented with this a little, and it is very likely also
>>feasible to build a metaclass that allows to mix several slot
>>allocation styles. It would boil down to have another slot allocation
>>option in addition to :class and :instance.
>>
>>The LispWorks Documentation also has an example that is relatively close.
>>
>>Of course, things would break when there is no MOP, or it misses
>>certain features. But again, it should be possible to make this
>>configurable, so that you have one version that supports
>>interoperability and one that doesn't.
>
> I think you can do this without MOP, by using
> #'slot-missing... for Python, it is possible to add slots to an object
> at any time, which seems like a good fit for hashtable allocation (of
> some slots, at least).
That's probably a good solution when there's no MOP around. However, one
would also need to think about shadowing of slots in subclasses. I don't
think you can get around the MOP for that. But I am not sure...
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza wrote:
> Raymond Wiker wrote:
>
>> I think you can do this without MOP, by using
>> #'slot-missing... for Python, it is possible to add slots to an object
>> at any time, which seems like a good fit for hashtable allocation (of
>> some slots, at least).
>
> That's probably a good solution when there's no MOP around. However, one
> would also need to think about shadowing of slots in subclasses. I don't
> think you can get around the MOP for that. But I am not sure...
Correction: You are right, I was wrong. SLOT-MISSING is the most
straightforward solution for adding new slots to objects. The MOP allows
adding new slots to classes. SLOT-VALUE-USING-CLASS and the like don't
help implementing the Python model because they rely on existing
SLOT-DEFINITION metaobjects, which can only be added by redefining a
class, AFAICS.
I have been misled by LispWork's MOP which deviates from the "official"
MOP for the slot-related functions.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> writes:
> There is a section on how to do this in AMOP.
3.7, or did you have something more specific in mind ?
> If you're interested I can send you what I already have via email.
Please.
> I guess that many Jython users want to leverage the Java platform but
> want to use a more convenient language. In the case of Lython,
> leveraging the Common Lisp "platform" wouldn't be an important
> feature. Otherwise, they would already have switched to Common Lisp.
Exactly, I see it more as CL developers leveraging the Python syntax
to present their work to a wider audience ... or providers of Python
functionality leveraging the CL platform. In either case, Lython
really must look and behave as much as CPython as possible.
> > http://www.python.org/doc/current/lib/bytecodes.html
>
> Yes, but that's very sparse.
No argument there :-)
> There are other alternatives that come to mind. What about CL-Ruby?
For technical reasons this might be a good idea. But if _I_ were to
play with something like this, then it would have to be Python, as I
know Python much better, and it actually has more than a passing
relevance to my day job. My lack of time to play with these ideas
means that greater overlap with my day job vastly increases the chance
of making any progress at all.
Pascal Costanza <········@web.de> writes:
> One of the hard things seems to be that there is no real good
> documentation of the Python bytecode. How likely is it that they
> change details of the bytecode between versions?
"they" do change the bytecode between "major" (i.e. 2.X vs 2.Y)
versions, but usually in minor ways.
> Is the Python compiler written in Python or in C?
There is *a* Python compiler written in Python, but as others have
said it's not the one used by default (it's slooow).
> (If it is written in Python, it would probably be better to base
> such a thing on bytecode instead of source code.)
?
Cheers,
mwh
--
ZAPHOD: Listen three eyes, don't try to outwierd me, I get stranger
things than you free with my breakfast cereal.
-- The Hitch-Hikers Guide to the Galaxy, Episode 7
Michael Hudson wrote:
> Pascal Costanza <········@web.de> writes:
>
>>One of the hard things seems to be that there is no real good
>>documentation of the Python bytecode. How likely is it that they
>>change details of the bytecode between versions?
>
> "they" do change the bytecode between "major" (i.e. 2.X vs 2.Y)
> versions, but usually in minor ways.
ok
>>Is the Python compiler written in Python or in C?
>
> There is *a* Python compiler written in Python, but as others have
> said it's not the one used by default (it's slooow).
Performance shouldn't be an issue. If the performance between the Python
compiler and the CPython compiler is the only difference, then executing
Python bytecode on top of Common Lisp will probably solve that problem.
>>(If it is written in Python, it would probably be better to base
>>such a thing on bytecode instead of source code.)
>
> ?
see above
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> writes:
> Michael Hudson wrote:
>
> > Pascal Costanza <········@web.de> writes:
> >>Is the Python compiler written in Python or in C?
> > There is *a* Python compiler written in Python, but as others have
> > said it's not the one used by default (it's slooow).
>
> Performance shouldn't be an issue. If the performance between the
> Python compiler and the CPython compiler is the only difference, then
> executing Python bytecode on top of Common Lisp will probably solve
> that problem.
People keep saying this and I keep failing to believe them. Please
prove me wrong.
Cheers,
mwh
--
... when all the programmes on all the channels actually were made
by actors with cleft pallettes speaking lines by dyslexic writers
filmed by blind cameramen instead of merely seeming like that, it
somehow made the whole thing more worthwhile. -- HHGTG, Episode 11
Michael Hudson wrote:
> Pascal Costanza <········@web.de> writes:
>
>
>>Michael Hudson wrote:
>>
>>
>>>Pascal Costanza <········@web.de> writes:
>>>
>>>>Is the Python compiler written in Python or in C?
>>>
>>>There is *a* Python compiler written in Python, but as others have
>>>said it's not the one used by default (it's slooow).
>>
>>Performance shouldn't be an issue. If the performance between the
>>Python compiler and the CPython compiler is the only difference, then
>>executing Python bytecode on top of Common Lisp will probably solve
>>that problem.
>
>
> People keep saying this and I keep failing to believe them. Please
> prove me wrong.
Not this week. ;)
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Jacek Generowicz wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>>Cello. RSN.
>
>
> I'm glad I wasn't holding my breath :-)
You don't like vaporware? :) Careful, anyone picking on me is
automatically volunteered* to work on their choice of:
- puzzling out one of the two problems with Freeglut (C required)
- puzzling out one of the two problems with Lispworks (tho I am happy to
see one of the problems occasionally popping up under ACL, so how tough
can it be?)
- porting to OS X under the CL of your choice. Using Apple's Aqua GLUT
gets you brownie points
- porting to Linux under the CL of your choice
- beating on your choice of CLisp or CormanCL until they agree to run Cello.
- OpenGL tuning
I would say graphic design, but now that I have the lighting panel
working and a snazzy texture for the skin, I feel like the Wiz just gave
me an MFA. New screen shots tonight if I do not die on the treadmill at
the gym.
kt
* yes, the kommie in me is regaining ascendancy
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Jacek Generowicz <················@cern.ch> wrote in message news:<···············@pcepsft001.cern.ch>...
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > Jacek Generowicz wrote:
> > > I've been thinking about the possibilities of a "Lython" for ages.
> >
> > Think also about the actual outcome of Dylan.
>
> > Your fear of the fear of others of parentheses is unjustified. The
> > parens are /not/ the problem (see "Dylan").
>
> Python is getting pretty widely known as a language which is easy to
> learn, and yet is very powerful. It is already acceptable (and even
> accepted) in many circles. AFAIK Dylan never reached this status.
>
> Dylan's problem was that it took away good features (parentheses) from
> those who appreciated Dylan's power, while at the same time was yet
> another new language to those who did not. In this respect, Lython
> has the advantage that it gives something that two camps know and
> love, in one package.
>
> The idea of Lython is to stealthily slide Lisp within reach of those
> who already use Python.
>
> > > But, looking at it from a different point of view, Lython would look
> > > like Python, but it would run much faster, and it would actually _be_
> > > Lisp.
> >
> > _be_ in what sense?
>
> In the same sense that any language built on Lisp _is_ Lisp.
>
The whole problem is the hype factor and people absolutely refusing
to learn and go read. This is a social problem, not a language
problem.
On the reading side, there aren't really any Lisp "for _real
newbies_" (I don't wnat to say "dummies" because it is a derogatory
term for beginners) books with very didactical things like: "Excercise
3: create an array, extract the main diagonal. Then, save that to a
file. Open the array from the file and multiply it by 4." You find a
profusion of those in C, Pascal, etc.
But that isn't a real problem either, _except_ that you can't expect
Common Lisp to be people's first programming language (Scheme has
succeeded in that camp due to efforts like the "How to Design
Programs" book and TeachScheme.org). Add the fact that you have
TIMTOWDI in Lisp, and the learning curve gets bigger.
Cheers,
Henry
Matthias wrote:
> It would require a huge marketing effort and strong arguments to
> /create a new community/ for the new-and-better scripting language. I
> would guess that the chances that this fails are noticeably larger
> than if you just say: "Oh, by the way, I implemented CLPython. It's
> exactly like Python or JPython but 10-100 times faster. I could use a
> helping hand porting some libs to <CL implementation> so that I can
> use them within CLPython."
You're probably right.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
jan wrote:
> Just what the Lisp world needs ... a better C compiler ?!
Hey, it would be a major win for Lisp if this little
fantasy were to become reality.
Paul
Paul Dietz <············@motorola.com> writes:
> jan wrote:
>
> > Just what the Lisp world needs ... a better C compiler ?!
>
> Hey, it would be a major win for Lisp if this little
> fantasy were to become reality.
Preferably in a Lisp that compiled to C :-)
Mario S. Mommer <········@yahoo.com> writes:
> Paul Dietz <············@motorola.com> writes:
> > jan wrote:
> >
> > > Just what the Lisp world needs ... a better C compiler ?!
> >
> > Hey, it would be a major win for Lisp if this little
> > fantasy were to become reality.
>
> Preferably in a Lisp that compiled to C :-)
Nah! What could be acceptable, is a C/C++ compiler that would
generate Lisp code. Of course, since a naive implementation would
give unmaintainable code, what's needed is some AI to understant the
intentions of the C programmer, and implement them in Lisp, thus
obtaining a better and bugless Lisp program.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Hello!
jan <······@iprimus.com.au> wrote:
>Just what the Lisp world needs ... a better C compiler ?!
Not the Lisp world, but at least me. I'm not in the fortunate
position to earn money w/o using C++.
Kind regards,
Hannah.
······@schlund.de (Hannah Schroeter) writes:
> >Just what the Lisp world needs ... a better C compiler ?!
>
> Not the Lisp world, but at least me. I'm not in the fortunate
> position to earn money w/o using C++.
Fine, but creating better C++ tools reduces Lisp's competitive
advantage, making it less likely the Lisp job market will improve.
Rather than working for the enemy, I'd prefer to see the effort go
into making Lisp better.
A better C++ will still be crap, and therefore, should not be written
(in any language).
--
jan
jan wrote:
> Fine, but creating better C++ tools reduces Lisp's competitive
> advantage, making it less likely the Lisp job market will improve.
Not really. A better C++ compiler is still a C++ compiler.
Paul
jan wrote:
> Just what the Lisp world needs ... a better C compiler ?!
The Lisp world could use some widespread kick-ass applications.
In this fantasy scenario, this would be one of them.
Paul
"Paul F. Dietz" <·····@dls.net> writes:
> jan wrote:
> > Just what the Lisp world needs ... a better C compiler ?!
>
> The Lisp world could use some widespread kick-ass applications.
> In this fantasy scenario, this would be one of them.
The last time this was tried, it was less than a stellar success. In
fact, the project brought down Lucid, the third big Lisp company.
Although the C compiler was not the problem. However, as I
understand, the speed was not supposed to come from a blindingly fast
C compiler, but the ability of the Energize environment to do
incremental compilation and linking.
--
Pekka P. Pirinen
Don't force it, get a larger hammer.
"Pekka P. Pirinen" wrote:
> The last time this was tried, it was less than a stellar success. In
> fact, the project brought down Lucid, the third big Lisp company.
> Although the C compiler was not the problem. However, as I
> understand, the speed was not supposed to come from a blindingly fast
> C compiler, but the ability of the Energize environment to do
> incremental compilation and linking.
As I understand it, that was a rather different thing,
using Lisp as a C development environment. Moreover, this
is about a replacement for a free compiler, not a commercial
product.
Paul
Duane Rettig <·····@franz.com> wrote:
+---------------
| I think that Lispers just don't associate the capability
| of targeted software with Lisp...
+---------------
I suppose I'm also really a hardware guy at heart, and have used
Lisp[1] once or twice to write what could be considered assemblers
for targeted hardware (mostly state machines, but in at least one case
it was a small nearly-GP microprocessor). It was so simple, the usual
Lisp thing: pick an s-expr representation for what you want to say,
and process it with a simple backend. Very straightforward, actually.
+---------------
| ...and that's a shame, because Lisp is such a great language for
| doing such work.
+---------------
Absolutely!!
-Rob
[1] Well, Scheme, actually, since that's what I was using at the time.
But these days it would be in CL...
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Duane Rettig <·····@franz.com> wrote in message news:<·············@franz.com>...
[I'm ruthlessly, and probably unfairly, excerpting from your article
to make a point. I don't think I disagree with anything you say, in
fact!]
> I went out of the hardware industry with the
> belief that the commodity markets would shift more and more toward
> general-purpose computing, and I have been right, so far. Obviously,
> the specialized hardware industry is not going to go away, but GP
> hardware is definitely on the rise, even in problem set areas that
> used to be thought of as specialized.
I think that a continuing shift towards general-purpose computing is
compatible with a large number (and I think, probably a large absolute
majority) of `systems' which are not suitable for *any* high-level
language existing for the forseeable furure (with the possible
exception of a restricted subset of a C-family language with a very
small standard library and possibly language features, such as
floating point, missing).
The reason for this is that there's a continual fringe where
custom-logic designs are giving way to embedded processor designs, and
large parts of this fringe are in very small systems. A good (but old)
example of this is the preamplifier for my HiFi. This is a 70s design
(a Quad 44), and it has a little custom logic to deal with input and
output switching. There is almost none of this - literally a few
gates I think, as I think all the actual switching of audio is done by
relays. Nowadays this kind of thing would undoubtedly be controlled
by some tiny embedded processor, which would do all the key debouncing
and sanity-ensuring (don't construct feebdack loops) and probably sit
in a package with all the switches &c as well. Another, more recent
example, is credit cards - all the replacement cards I've had recently
have had little contacts on them, and I bet there's a processor in
there.
At present, I think this fringe is enormous - there are very many
applications where tiny processors are replacing tiny embedded logic.
In particular I think that the numbers of processors in devices in (or
near) this fringe may be much larger than the numbers of processors in
larger devices such as the CPUs in phones and things like that (and in
turn there are probably many more processors in phones and other such
devices than there are in things we think of as computers, although
you have to be careful here, because a modern PC could easily have 10s
of CPUs in the keyboard, disks, network card, &c &c, which I'm
thinking of as embedded CPUs). It may even be that the *value* of
this tiny-processor market is larger than the bigger-processor
markets. It's just rather invisible to most people.
The spread of these tiny systems *is* the spread of general-purpose,
or *more* general-purpose systems, as they're displacing custom logic,
but they still aren't `general purpose enough' to be viable targets
for HLLs. Although the lisp-based assembler/config system idea is
pretty interesting!
--tim
On Wed, 04 Feb 2004 10:50:42 -0800, Tim Bradshaw wrote:
> I suspect it does exist, still, although not in general machines. I
> admit to not having looked that recently (say within the last 2
> years), but there certainly were an awful lot of microcontrollers sold
> which had maybe a couple of K of ROM and some small number of bytes of
> RAM. I'd guess that these things are still used, and possibly used in
> enormous numbers, since in the market they're aimed at getting things
> very cheap is a significant win, and the computastional requirements
> are not very large. It may be though that you can put hundreds of K
> of ROM on them for nothing (literally...) now though.
You can now get 64K of RAM with little cost and the lowest amount of RAM
(other than for very specialized SoC custom designs) that I could find
was about 4K. Most also come with external mem I/F's and enough ROM to
hold a fairly comlete Lisp system. My gut feel says that you could keep
an entire Lisp runtime (ANSI compliant, sans #'compile & friends) on a
sub-$5 chip (in quantities of 10,000 or more :-) these days. Now what
you'd want to do with it that didn't require more RAM (other than gretting
your system's code out quickly - which is probably a win in itself) is, of
course, another question.
faa
From: Tim Bradshaw
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <ey3fzdpuh4b.fsf@cley.com>
* Frank A Adrian wrote:
> My gut feel says that you could keep
> an entire Lisp runtime (ANSI compliant, sans #'compile & friends) on a
> sub-$5 chip (in quantities of 10,000 or more :-) these days.
Yes, I agree. But I was thinking of parts in the few cent price
range.
--tim
On Fri, 06 Feb 2004 01:33:08 +0000, Tim Bradshaw wrote:
> Yes, I agree. But I was thinking of parts in the few cent price
> range.
<fake-texas-accent>
Well! Ain't you the frugal one!
Actually, I cain't even think of what one could do in less than 4K where
you wouldn't just go ahead and write the code in assembler, but I guess
that's a result of my upbringin' doin' programmin' close to the iron.
Shoot! If a programmer cain't turn out 4K worth of tested assembler
functionality in a month, he ought to be turned out anyhow. 'Sides, the
mech design monkeys will take at least that long to uglify... uh, I mean
"design"... the casing.
</fake-texas-accent>
faa
P.S. I know embedded software design is difficult - I'm just joshin' here :-).
"Frank A. Adrian" <·······@ancar.org> writes:
> On Fri, 06 Feb 2004 01:33:08 +0000, Tim Bradshaw wrote:
>
>> Yes, I agree. But I was thinking of parts in the few cent price
>> range.
>
> <fake-texas-accent>
> Well! Ain't you the frugal one!
>
> Actually, I cain't even think of what one could do in less than 4K where
> you wouldn't just go ahead and write the code in assembler, but I guess
> that's a result of my upbringin' doin' programmin' close to the iron.
> Shoot! If a programmer cain't turn out 4K worth of tested assembler
> functionality in a month, he ought to be turned out anyhow. 'Sides, the
> mech design monkeys will take at least that long to uglify... uh, I mean
> "design"... the casing.
> </fake-texas-accent>
Well, you can write an assembler in lisp. For simple chips like this
with no mmu or scheduling issues or executable file formats it's just
a matter of translating a data-sheet into lisp. Write your assembler
so that it accepts s-exprs as assembly source. Then you have the full
power of lisp available to massage your code. Think about that. What
can a lisp macro do in a situation like this? Furthermore, you don't
have to wait for a new C-compiler to be available to go with new
versions of the chip. Porting to a new chip is bound to be easier as
well, since you can use lisp to automate the porting.
There, I've gone and given away the secret :-)
--
H�kon Alstadheim, hjemmepappa.
From: Christopher C. Stacy
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <uk733ndw3.fsf@news.dtpq.com>
>>>>> On 03 Feb 2004 21:29:45 -0800, Duane Rettig ("Duane") writes:
Duane> The "troll" you responded to had a good point, and never
Duane> mentioned any actual sizes. And your response was:
He was rejecting the information given him about the small sizes and
formats of the deliverables that most implementations do generate.
From: Duane Rettig
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <4broeq3ci.fsf@franz.com>
······@news.dtpq.com (Christopher C. Stacy) writes:
> >>>>> On 03 Feb 2004 21:29:45 -0800, Duane Rettig ("Duane") writes:
> Duane> The "troll" you responded to had a good point, and never
> Duane> mentioned any actual sizes. And your response was:
>
> He was rejecting the information given him about the small sizes and
> formats of the deliverables that most implementations do generate.
I entertained the possibility that my rememberance of how this
thread started was in error, since my news reader doesn't have
a previous article for the one by Cameron MacKinnon to which you
responded. So I went back to Google, and it looks like Google's
memory of it is similar to mine; his article was the first one
in this thread.
Actually, I was incorrect on one point; he did mention two actual
sizes:
- He mentioned that lispers tell him that his application
would be 11 Mb (it's probably true that he is told that,
and it is completely unnecessary).
- He talked about the original size of Perl, which was probably
also accurate, though it was probably only binary size that
he was describing.
So if it is the 11Mb lower limit that you are talking about him
rejecting, then OK, but I agree with him; it is possible in Allegro
CL to create much smaller lisp images, and the in-memory usage
can also be made much smaller, as well. It is also true that we've
had some bugs where modules get inadvertently loaded in when
undesired, but the point there is that we consider these to be bugs,
and fix them as quickly as possible.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Christopher C. Stacy
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <ud68uzr6m.fsf@news.dtpq.com>
>>>>> On 04 Feb 2004 07:19:41 -0800, Duane Rettig ("Duane") writes:
Duane> ······@news.dtpq.com (Christopher C. Stacy) writes:
>> >>>>> On 03 Feb 2004 21:29:45 -0800, Duane Rettig ("Duane") writes:
Duane> The "troll" you responded to had a good point, and never
Duane> mentioned any actual sizes. And your response was:
>>
>> He was rejecting the information given him about the small sizes and
>> formats of the deliverables that most implementations do generate.
Duane> So if it is the 11Mb lower limit that you are talking about him
Duane> rejecting, then OK,
He was persisting in his arguments after people pointed out that:
Duane> it is possible in Allegro CL to create much smaller lisp images
Did you notice that he went away after he was all done trolling?
Christopher C. Stacy wrote:
> Common Lisp was not designed for delivering small applications
> and most of the vendors are not interested in that market.
It's difficult to see how vendors can grow the market if they ignore the
small end. Development shops want experienced programmers, and
inexperienced programmers don't start out by building large
applications. So there will always be a bigger pool of developers
working in the languages that are suitable for small apps, leading to
development shops picking those languages for larger apps.
The other languages that aimed at large systems were Ada and PL/1.
> I don't know why you would think that people who have written
> small applications as you describe are industry "trend setters".
"Industry" calls IBM and asks what the safe choice is this year, thus
coding in Java and XML. People learn a programming language because:
1. MS/Sun/IBM shilling it to abet or avoid platform lock-in
2. Taught in school. See 1.
3. The US DoD says so
4. UNIX is written in it
5. A kid/grad student writes a nifty app and posts the source
If you're trying to increase the popularity of a language and you're not
one of the above named entities, #5 is your only hope.
> If they are focused on delivering toy programs, and don't have
> the patience to study and learn to understand the benefits of
> something that is too complex to be easily absorbed, then it
> seems to me that they are more likely to just be following
> whatever trends are popular.
Most large programs start small, but there are many small programs that
don't aspire to be large. To disparage these as toys is to disparage the
vast majority of software. And anybody who shows up in c.l.l sure isn't
following a popular trend.
> We're not interested in "Lisp For Dummies In 21 Days".
> In over four decades, we have seen languages come and languages go,
> and are not very worried about popularity contests. Lisp is not well
> suited to be the most popular language available, and that's fine.
It's not the dummies you need to worry about. It's the people who've
heard such great things, decide to check it out and are appalled to
discover that nearly a decade after "The Internet's a passing fad" Gates
threw in the towel and wired his OS for TCP/IP, Lisp still has no
standard network API. It was difficult for me to reconcile this with a
living language.
The kids that come to c.l.l asking how to package their apps are the
future of Lisp. Or some other language. Treat them well.
I do appreciate the pointer to ECL and other lisps which can generate
small footprint executables, Christopher. But I did look at a
representative sample of prior threads, dating back about six months,
before my original post. And I wouldn't say that those who ask get a
warm welcome.
From: Christopher C. Stacy
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <u65eoy02f.fsf@news.dtpq.com>
>>>>> On Tue, 03 Feb 2004 03:16:34 -0500, Cameron MacKinnon ("Cameron") writes:
Cameron> Christopher C. Stacy wrote:
>> Common Lisp was not designed for delivering small applications and
>> most of the vendors are not interested in that market.
Cameron> It's difficult to see how vendors can grow the market if they ignore
Cameron> the small end. Development shops want experienced programmers, and
Cameron> inexperienced programmers don't start out by building large
Cameron> applications.
1. The size and format of the executable program image
have nothing to do with the scenario you are presenting,
unless you are postulating a company that ships "hello world"
class programs written by inexperienced programmers.
2.Where I come from, inexperienced programmers are supervised
and are given a small confined piece of a (large) product
to work on. The image size is irrelelvent.
If you're argument is that the language is too complex for
beginners to master, that's another matter entirely.
In that case, use some other language, or invest in
properly training your programmers.
Cameron> "Industry" calls IBM and asks what the safe choice is this year, thus
Cameron> coding in Java and XML. People learn a programming language because:
Cameron> 1. MS/Sun/IBM shilling it to abet or avoid platform lock-in
Cameron> 2. Taught in school. See 1.
Cameron> 3. The US DoD says so
Cameron> 4. UNIX is written in it
Cameron> 5. A kid/grad student writes a nifty app and posts the source
Cameron> If you're trying to increase the popularity of a language and you're
Cameron> not one of the above named entities, #5 is your only hope.
Kids writing "nifty apps" in their spare time and giving them away for
free are not industry movers and shakers. Maybe when they grow up
they will learn Common Lisp and write something significant.
Cameron> It's not the dummies you need to worry about. It's the people who've
Cameron> heard such great things, decide to check it out and are appalled to
Cameron> discover that nearly a decade after "The Internet's a passing fad"
Cameron> Gates threw in the towel and wired his OS for TCP/IP, Lisp still has
Cameron> no standard network API. It was difficult for me to reconcile this
Cameron> with a living language.
I have a standard network API I use portably on two platforms and two
different Lisp implementations. It took me about two hours to write it.
I didn't like the ones that were available for free downloading.
Cameron> And I wouldn't say that those who ask get a warm welcome.
I just spent about $300 of my own money helping you with advice.
Sorry I wasn't warm enough; I have to get back to work now.
Christopher C. Stacy wrote:
> Cameron> It's difficult to see how vendors can grow the market if they ignore
> Cameron> the small end. Development shops want experienced programmers, and
> Cameron> inexperienced programmers don't start out by building large
> Cameron> applications.
>
> 1. The size and format of the executable program image
> have nothing to do with the scenario you are presenting,
> unless you are postulating a company that ships "hello world"
> class programs written by inexperienced programmers.
*Precisely*
Where "company" is a high school kid, and "hello world" is the next
great Internet app, which *you* could have written in about 20 hours, if
only you'd thought of it first.
> 2.Where I come from, inexperienced programmers are supervised
> and are given a small confined piece of a (large) product
> to work on. The image size is irrelelvent.
Where I come from, they're unemployed, or still in school. And more
interested in singlehandedly writing some odd app (that I'll find
utterly banal, but which will appeal to the teenage mind) than signing
up for a death march in a cube farm.
> Kids writing "nifty apps" in their spare time and giving them away for
> free are not industry movers and shakers. Maybe when they grow up
> they will learn Common Lisp and write something significant.
Shaun Fanning. Linus Torvalds. Richard Stallman. Justin Frankel. Marc
Andreessen.
I guess there's hope for Stallman, if you can convince him that lexical
scoping is the way to go.
The next generation is out there somewhere, coding who knows what.
Likely not in CL.
> I have a standard network API I use portably on two platforms and two
> different Lisp implementations. It took me about two hours to write it.
> I didn't like the ones that were available for free downloading.
This sounds neither standard nor portable. And only two hours work!
> Cameron> And I wouldn't say that those who ask get a warm welcome.
>
> I just spent about $300 of my own money helping you with advice.
Had I asked for any advice, I'd be grateful, I'm sure.
> Sorry I wasn't warm enough; I have to get back to work now.
Had I been referring to myself, I'd have used the personal pronoun.
Cameron MacKinnon <··········@clearspot.net> writes:
> I guess there's hope for Stallman, if you can convince him that
> lexical scoping is the way to go.
Actually, there's work on lexical scoping in Emacs going on, and RMS
seems amenable. There are cases in Emacs where dynamic is good, and
it'll stick around, but I think long-term lexical will be used for
most places it is in CL.
AFAIK, RMS's objection to CL is that he thinks it's just too big of a
language to embed in Emacs, and not worth it....
--
Alan Shutko <···@acm.org> - I am the rocks.
Reflected by the ever-burning sign of the god who happened by.
From: Christopher C. Stacy
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <usmhsvsos.fsf@news.dtpq.com>
>>>>> On Tue, 03 Feb 2004 07:04:22 -0500, Cameron MacKinnon ("Cameron") writes:
>> Kids writing "nifty apps" in their spare time and giving them away for
>> free are not industry movers and shakers. Maybe when they grow up
>> they will learn Common Lisp and write something significant.
Cameron> Shaun Fanning. Linus Torvalds. Richard Stallman.
Cameron> Justin Frankel. Marc Andreessen.
The only person in your list who I know enough about to make a
comparison is Richard Stallman. He was not writing toy programs
in high school. He matriculated from Harvard and then went to work
at MIT in the research lab there, where he wrote his programs in Lisp
(and also assembly language and TECO. My own background involves no
formal education, but a few years later I joined him at that lab,
so I am quite familiar with the people and what the environment
was like there. It did not correspond to what you seem to be imagining.
From: Christopher C. Stacy
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <un080vsmp.fsf@news.dtpq.com>
>>>>> On Tue, 03 Feb 2004 07:04:22 -0500, Cameron MacKinnon ("Cameron") writes:
Cameron> Had I asked for any advice, I'd be grateful, I'm sure.
So you admit that you are a troll.
Plonk.
On Tue, 03 Feb 2004 03:16:34 -0500, Cameron MacKinnon
<··········@clearspot.net> wrote:
>It's difficult to see how vendors can grow the market if they ignore the
>small end. Development shops want experienced programmers, and
>inexperienced programmers don't start out by building large
>applications. So there will always be a bigger pool of developers
>working in the languages that are suitable for small apps, leading to
>development shops picking those languages for larger apps.
(Mrrrf, the word is "program", not "app".)
But what of it? By all means write a 10 line program to get started
with a language. Who cares how many megabytes of binary that ends up
as? As Joel pointed out, concern about "bloatware" nowadays is a
_mental illness_. Fiddling with software to trim a few megabytes off
the size of a program is merely pandering to neurosis; the right way
to help someone who's worried about that nowadays is by giving them
the phone number of a good psychoanalyst.
>The kids that come to c.l.l asking how to package their apps are the
>future of Lisp. Or some other language. Treat them well.
I agree it's good to be polite, and it's also important to have
convenient ways to package programs. But people exhibiting signs of
mental illness need to be told so, albeit politely.
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
From: Christopher C. Stacy
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <u3c9oy6fp.fsf@news.dtpq.com>
>>>>> On Fri, 06 Feb 2004 07:15:58 GMT, Russell Wallace ("Russell") writes:
Russell> Who cares how many megabytes of binary that ends up as?
Russell> Fiddling with software to trim a few megabytes off the size
Russell> of a program is merely pandering to neurosis
I only partly agree with you here. The attitude that memory and
CPU resources are infinite is one of the causes of bloatware (but
not the only factor, and perhaps not even the most important one).
To decide whether image size is important, the application's environment
needs to be considered. This includes delivery and installation, as well
as runtime performance issues. Download times and disk space requirements
may be important. Program startup time may be important. Total memory
requirements may be important (and may be relative to what other programs
are expected to be sharing the computer). Shared memory pages may be
important. But these are all about Lisp compiler/runtime implementations
and how they interact with the operating system. Unless you are concerned
with very tiny special-purpose computers, these issues are not very much
about the Common Lisp language.
For most programs that people run on typical desktop computers and
servers today, the analysis is pretty straightforward: resources are
so plentiful that if you have to think about this for more than five
seconds, then you're probably being neurotic. Without a second thought,
Lisp is perfectly good for delivering most kinds of programs.
These concern in a vacuum over small image sizes is an example of
inappropriately premature optimization, or else a total misunderstanding
of how the current Lisp implementations perform.
You can't get the most useful answer by totally divoring these
performance considerations from actual programs. Just looking
at a blank Lisp "executable" (empty run-time image or something)
is not sufficient to make generalizations about how programs
in that implementation will perform, let alone any assertions
about the characteristics of an abstract programming language.
Something that would be interesting would be a thorough analysis of
the performance characteristics of a variety of classes of Lisp
programs on different implementations, operating systems, hardware,
and Lisp and OS tunings. The analysis should including timings for
process creation and startup (including resources and time used in
the different phases of the program, such as bringing up the GUI
and being ready to accept commands), and resource requirements
for the program as it allocates memory to start getting work done.
(In other words, identifying the time variant resource requirements
to understand the performance implications... for example, whether
there are inappropriately front-loaded demands.) Alone, this might
be interesting information for Lisp and library implementors, if they
feel that there might be important optimizations they are mising.
Also very interesting would be a comparative analysis against the
other languages and their implementations.
Absent such a thorough analysis, it's all just really bullshit,
and sufficient offhand analysis is: "Gee, my Lisp programs seem to
download, launch, do work, using memory and CPU that are comparable
(often better) than any programs I'm using. that were written in
other languages. So what's your major malfunction, luser?"
On Fri, 06 Feb 2004 08:10:18 GMT, ······@news.dtpq.com (Christopher C.
Stacy) wrote:
>Absent such a thorough analysis, it's all just really bullshit,
>and sufficient offhand analysis is: "Gee, my Lisp programs seem to
>download, launch, do work, using memory and CPU that are comparable
>(often better) than any programs I'm using. that were written in
>other languages. So what's your major malfunction, luser?"
*grin* Well put!
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
Russell Wallace wrote:
> But what of it? By all means write a 10 line program to get started
> with a language. Who cares how many megabytes of binary that ends up
> as? As Joel pointed out, concern about "bloatware" nowadays is a
> _mental illness_. Fiddling with software to trim a few megabytes off
> the size of a program is merely pandering to neurosis; the right way
> to help someone who's worried about that nowadays is by giving them
> the phone number of a good psychoanalyst.
I see no Joel here. So I checked whether you meant Spolsky, and read his
article. His company ships two products, both designed to be deployed on
servers and used via web the web. So to his ultimate end users, his
application size is zero.
The Java guys designed a compact byte code representation, even though
all those unaligned integers ruined performance on their RISC hardware
until they could get JIT compilers going. Further, the byte code is
delivered zipped.
UPX seems to be the most talked about of a number of new executable
packers. Rather like Sea Monkeys, the executables self-inflate to full
size after being loaded into RAM.
"The DSL Forum has completed a new survey showing that South Korea has
the highest broadband penetration rate with almost 30%.
No other country managed to pass the 20% mark although Japan, Germany,
Canada, Italy, France, Iceland and Estonia all make it into the top 20.
The organisation claimed that neither the US nor the UK were in the top
20."
http://www.findarticles.com/cf_dls/m0ECZ/2003_Sept_15/107767020/p1/article.jhtml
September, 2003
So 70-80% of users (worst case, for applications targeting home users)
will be downloading at 56k. Yes, that fraction is dropping every day.
But it's still very significant.
--
Cameron MacKinnon
Toronto, Canada
"I may be paranoid, but there's millions, wait, billions like me."
Cameron MacKinnon <··········@clearspot.net> writes:
> "The DSL Forum has completed a new survey showing that South Korea has
> the highest broadband penetration rate with almost 30%.
That's what the article says, that's not what the survey actually
says.
If you look at http://www.dslforum.org/PressRoom/news_9.09.2003.html
you'll find that that number is the percent of phone lines with DSL on
them, compared to the total number of phone lines. It doesn't take
into account other broadband providers, or even whether the phone
lines counted without DSL even had computers attached.
So your statement:
> So 70-80% of users (worst case, for applications targeting home users)
> will be downloading at 56k.
is completely unfounded.
--
Alan Shutko <···@acm.org> - I am the rocks.
I backed up my hard drive ... and smashed into the bus!
Alan Shutko wrote:
> Cameron MacKinnon <··········@clearspot.net> writes:
>>"The DSL Forum has completed a new survey showing that South Korea has
>>the highest broadband penetration rate with almost 30%.
>
> That's what the article says, that's not what the survey actually
> says.
...
> So your statement:
>
>>So 70-80% of users (worst case, for applications targeting home users)
>>will be downloading at 56k.
>
> is completely unfounded.
>
My methodology was sloppy. I typed some stuff into google and picked the
first likely source that came up, without checking it.
Here's the Pew Internet and American Life Project:
"31% of [American] Internet users who go online from home have broadband
as of August 2003."
http://www.pewinternet.org/reports/reports.asp?Report=106&Section=ReportLevel1&Field=Level1ID&ID=463
If you know of a large survey with good methodology and different
numbers, by all means share.
--
Cameron MacKinnon
Toronto, Canada
Cameron, I agree. I look with interest when this question is asked
hoping that some gem will be revealed. Something to Lisp like
freepascal is to pascal. For the people that find these threads
annoying, easy solution, don't read them.
Now, didn't Lisp have origins on very low end hardware? Doesn't that
mean that the essence of the language can be implemented in a small EXE?
Could some type of linker strip out portions of the runtime library
that aren't required?
Cheers.
Cameron MacKinnon <··········@clearspot.net> wrote in
···························@golden.net:
> At least once a month, someone asks how to deliver a "standalone"
> executable of a Lisp application. It's often his first post, and often
> his last.
On 2004-02-02 21:59:53 -0800, Henry Hansen <······@h-o-t-m-a-i-l.com> said:
> Cameron, I agree. I look with interest when this question is asked
> hoping that some gem will be revealed. Something to Lisp like
> freepascal is to pascal. For the people that find these threads
> annoying, easy solution, don't read them.
>
> Now, didn't Lisp have origins on very low end hardware? Doesn't that
> mean that the essence of the language can be implemented in a small EXE?
> Could some type of linker strip out portions of the runtime library
> that aren't required?
It's easy (even without intending to) to write Lisp code that makes it very
hard to tell which parts of the runtime aren't required.
mikel <··········@sbcglobal.net> wrote in
···············@news.athenanews.com:
> It's easy (even without intending to) to write Lisp code that makes it
> very hard to tell which parts of the runtime aren't required.
I think I see your point: a macro driven indirection of sorts makes it
difficult to trace dependencies. Do some Lisp programs dynamically
modify their runtimes, morphing in a sense?
also ...
Are you aware of any Lisp interpreters that manifest themselves inside a
database? For example, similar to stored procedures in SQL Server.
Seems to me this macro capability would work very well in this context.
Thanks!
From: Joe Marshall
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <llnh8py1.fsf@comcast.net>
Henry Hansen <······@h-o-t-m-a-i-l.com> writes:
> mikel <··········@sbcglobal.net> wrote in
> ···············@news.athenanews.com:
>
>> It's easy (even without intending to) to write Lisp code that makes it
>> very hard to tell which parts of the runtime aren't required.
>
> I think I see your point: a macro driven indirection of sorts makes it
> difficult to trace dependencies. Do some Lisp programs dynamically
> modify their runtimes, morphing in a sense?
Some do. Some do it unintentionally. Some problems can be difficult
to solve without dynamically modifying the runtime. You have to weigh
the advantages of doing so (possibly easier development) against the
disadvantages (unintended interdependencies, deployment issues).
Those with less experience at doing this are more likely to make
mistakes.
--
~jrm
Henry Hansen wrote:
> Cameron, I agree. I look with interest when this question is asked
> hoping that some gem will be revealed. Something to Lisp like
> freepascal is to pascal. For the people that find these threads
> annoying, easy solution, don't read them.
>
> Now, didn't Lisp have origins on very low end hardware? Doesn't that
> mean that the essence of the language can be implemented in a small EXE?
> Could some type of linker strip out portions of the runtime library
> that aren't required?
The important point here is that Lisp is a dynamic language. People who
ask for compilability to .EXE files are expecting Lisp to behave like
static languages they already know. That's not the right model to
approach something like Lisp. You won't get the important aspects when
you start with such a mindset.
As others have already pointed out, someone who has already implemented
a considerable program in Lisp wouldn't ask this kind of question,
because it becomes clearer the more experienced you get how to deal with
these things.
The situation is not unlike the situation in Java: The only platform on
which you can deploy a Java program without shipping an additional JVM
and/or requiring more installation work from the user is Mac OS X. On
all other platforms, a Java program is far away from being a
double-clickable .EXE file. Yet this didn't prevent Java from succeeding.
It's just one of those typical hurdles a Lisp newbie has to face with.
There's no way around this. IMHO.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza wrote:
> The important point here is that Lisp is a dynamic language. People who
> ask for compilability to .EXE files are expecting Lisp to behave like
> static languages they already know. That's not the right model to
> approach something like Lisp. You won't get the important aspects when
> you start with such a mindset.
We agree that a complete CL application with a REPL has tremendous power
and extensibility. And that people who show up on c.l.l asking "how to
compile?" almost certainly aren't using all of that power, and probably
don't even realize it.
But they know what they want, or think they do -- one file, which they
can send to an end user, whose operating system will do the right thing.
If we say to them "you don't want to do that" or "you could do that in
C", then they will go back to C.
Not every program needs the full, dynamic power of Lisp. Some programs
need to be reasonably small.
AND (key point) if these people get a lecture and some sarcasm instead
of (or in addition to) what they ask for, they're just going to quit Lisp.
There are several people whose *only* post on c.l.l was to ask "the
question". Either they're now happy lurkers (speak up, please!) or that
was their one and only question and they left happy, or they left
disgusted and went back to [your inferior language here].
Several more people basically said "hear, hear" in this very thread.
Perhaps an improvement to the FAQ? Explaining what they'll lose,
pointing at some incisive article or example, but then saying "and if
you still really want to do this, here's the lisps that give the
smallest executables, and how to go about it."
Cameron MacKinnon wrote:
> Pascal Costanza wrote:
>
>> The important point here is that Lisp is a dynamic language. People
>> who ask for compilability to .EXE files are expecting Lisp to behave
>> like static languages they already know. That's not the right model to
>> approach something like Lisp. You won't get the important aspects when
>> you start with such a mindset.
>
> We agree that a complete CL application with a REPL has tremendous power
> and extensibility. And that people who show up on c.l.l asking "how to
> compile?" almost certainly aren't using all of that power, and probably
> don't even realize it.
>
> But they know what they want, or think they do -- one file, which they
> can send to an end user, whose operating system will do the right thing.
>
> If we say to them "you don't want to do that" or "you could do that in
> C", then they will go back to C.
>
> Not every program needs the full, dynamic power of Lisp. Some programs
> need to be reasonably small.
Sure, and there is clisp, ECL, OpenLisp, and the like to do these things.
The point is that there is no single right answer to this question.
Small programs are different than big programs. Some programs are better
provided as source code while others are better provided as compiled
libraries and/or .EXEs. And so forth.
In the non-Lisp world, these different deployment scenarios are offered
by different languages. In Lisp, you can get everything from a single
environment. It's very likely that you will shift your ideas what should
be deployed how in Lisp.
The typical answer here to the question whether one can create .EXE
files is not "No, because you don't need this.", but "Yes, but you will
probably change your ideas whether you really want this or not."
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Henry Hansen <······@h-o-t-m-a-i-l.com> writes:
> Cameron, I agree. I look with interest when this question is asked
> hoping that some gem will be revealed. Something to Lisp like
The implementation notes document included in GNU CLISP provides
interesting information on this. The ideas about application delivery
may be useful even with other Common Lisp implementations.
> Now, didn't Lisp have origins on very low end hardware? Doesn't that
> mean that the essence of the language can be implemented in a small EXE?
What about Lisp Machines? :)
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Cameron MacKinnon wrote:
>
> At least once a month, someone asks how to deliver a "standalone"
> executable of a Lisp application. It's often his first post, and often
> his last.
>
> I suspect that a lot of these people have written small applications and
> want to share them on the net. They're likely to be some of the most
> effective proselytizers of Lisp, introducing compelling apps to others,
> some of whom will get the source and become lispers themselves. What do
> they hear?
> - You can't do that
> - You can only do it with the commercial lisps
> - You can do it, but the binary will be 11MB
>
This is one case where Scheme is a lot better than Common Lisp.
As a much smaller language, it's easy to make small scheme
runtimes.
There are also a number of good free Scheme-to-c systems that
produce compilable C code, and at least one good free all-the-
way-to-machine-code compiler.
So if you want to write in a lispy langauge and deliver small
or medium-sized executables, the easiest way is to write in
Scheme.
Bear
Ray Dillinger wrote:
> This is one case where Scheme is a lot better than Common Lisp.
> As a much smaller language, it's easy to make small scheme
> runtimes.
Agreed. If only Scheme, rather than Java, had become the lingua franca
of cellphones! But having read about tree walking and tree shaking, I
wonder why it isn't more often used. Having the huge language and then
removing everything you don't need gives the best of both worlds.
I haven't yet declared my fealty to either the Scheme or Lisp camps. To
one looking at the whole continuum of computer languages, Lisp and
Scheme appear so far from everything else, and so close to each other,
that the constantly erupting flamefests seem quite comical.
--
Cameron MacKinnon
Toronto, Canada
"[the] politics are so vicious precisely because the stakes are so small."
From: Joe Marshall
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <isiobhtn.fsf@comcast.net>
Cameron MacKinnon <··········@clearspot.net> writes:
> Agreed. If only Scheme, rather than Java, had become the lingua franca
> of cellphones! But having read about tree walking and tree shaking, I
> wonder why it isn't more often used. Having the huge language and then
> removing everything you don't need gives the best of both worlds.
It is difficult to determine what you don't need even from the
sources. Since FUNCALL and APPLY can call anything passed to them,
you have to compute what might be passed. If you have a call to
INTERN or READ anywhere, you can generate arbitrary symbols at
runtime, and unless you can prove that they do *not* end up being
FUNCALLED, then the entire lisp system is accessible.
> I haven't yet declared my fealty to either the Scheme or Lisp
> camps. To one looking at the whole continuum of computer languages,
> Lisp and Scheme appear so far from everything else, and so close to
> each other, that the constantly erupting flamefests seem quite comical.
Agreed.
--
~jrm
Joe Marshall <·············@comcast.net> writes:
> If you have a call to INTERN or READ anywhere, you can generate
> arbitrary symbols at runtime, and unless you can prove that they do
> *not* end up being FUNCALLED, then the entire lisp system is
> accessible.
Are there Lisp systems that allow one to disable INTERN and READ after
the code has been compiled, so that no new, "unexpected" code paths
could be introduced? While I appreciate that one usually has the full
power of the reader and compiler available in a Lisp program, I can
imagine many programs for which these facilities wouldn't be
necessary at deployment time.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
"Steven E. Harris" <········@raytheon.com> writes:
> > If you have a call to INTERN or READ anywhere, you can generate
> > arbitrary symbols at runtime, and unless you can prove that they do
> > *not* end up being FUNCALLED, then the entire lisp system is
> > accessible.
>
> Are there Lisp systems that allow one to disable INTERN and READ after
> the code has been compiled, so that no new, "unexpected" code paths
> could be introduced? While I appreciate that one usually has the full
> power of the reader and compiler available in a Lisp program, I can
> imagine many programs for which these facilities wouldn't be
> necessary at deployment time.
There certainly are Lisps which allow (or require, for licensing
reasons) the (file-)compiler to be absent from a deployed image. The
situation is basically the same - the deployed Lisp program does not
run in a conforming Lisp implementation any more.
Henrik Motakef <············@henrik-motakef.de> writes:
> The situation is basically the same - the deployed Lisp program does
> not run in a conforming Lisp implementation any more.
It's non-conforming in the sense that it doesn't provide services that
the program doesn't use? That sounds tolerable.
Let me be more clear: If one could remove all the functions and data
from an image that are not required by a given program, the image
could be made much smaller. Consider, for example, a program that adds
a few numbers and prints a result. Surely such a program wouldn't need
much of Common Lisp to get its work done. Maybe the "printing a
result" part would involve streams, which might involve CLOS, and the
dependencies would climb from there.
Is this kind of pruning of unused capability what "tree shaking"
refers to?
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
"Steven E. Harris" <········@raytheon.com> writes:
> Henrik Motakef <············@henrik-motakef.de> writes:
>
> > The situation is basically the same - the deployed Lisp program does
> > not run in a conforming Lisp implementation any more.
>
> It's non-conforming in the sense that it doesn't provide services that
> the program doesn't use? That sounds tolerable.
Of course, in many cases it is. Otherwise nobody would use this
feature.
> Let me be more clear: If one could remove all the functions and data
> from an image that are not required by a given program, the image
> could be made much smaller. Consider, for example, a program that adds
> a few numbers and prints a result. Surely such a program wouldn't need
> much of Common Lisp to get its work done. Maybe the "printing a
> result" part would involve streams, which might involve CLOS, and the
> dependencies would climb from there.
>
> Is this kind of pruning of unused capability what "tree shaking"
> refers to?
Yes, at least as I understand it. But to make this possible, the
program has to be written in a specific way from the beginning. For
example, a general "plugin" mechanism where each plugin can internally
use all of CL (as discussed in another recent thread) would probably
be impossible.
This may or may not be a worthwhile tradeoff. There are other
tradeoffs between, say, speed and genericity, like whether you
implement something with a generic or an ordinary function. Generally,
it seems to be best to allow both styles, but in the case of
genericity vs. image size, it seems to me that you have to decide
pretty early in the development cycle - a CL program meant to run in a
size-optimized, functionally restricted environment will probably be
quite different from one that can assume all of Common Lisp being
available.
From: Joe Marshall
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <7jz3bprc.fsf@comcast.net>
"Steven E. Harris" <········@raytheon.com> writes:
> Joe Marshall <·············@comcast.net> writes:
>
>> If you have a call to INTERN or READ anywhere, you can generate
>> arbitrary symbols at runtime, and unless you can prove that they do
>> *not* end up being FUNCALLED, then the entire lisp system is
>> accessible.
>
> Are there Lisp systems that allow one to disable INTERN and READ after
> the code has been compiled, so that no new, "unexpected" code paths
> could be introduced?
Er, sort of.
It would have to have `load' and `fasload' disabled as well, and of
course the debugger, too. The problem is that even something as
simple as (+ a b) *could* end up running any piece of arbitrary code
(consider if A isn't a number) and the tree shaker has no reason to
believe that it won't.
--
~jrm
From: Tim Bradshaw
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <ey3oesgeeqr.fsf@cley.com>
* Cameron MacKinnon wrote:
> Maybe it would be instructive to look at how other languages handled
> this chicken-and-egg problem:
Yes, I think so
>[...]
> Sun sued Microsoft to stop the distribution of a buggy and
> incompatible Java, tried to get the court to compel Microsoft to
> distribute an updated version, and paid HP and others (presumably)
> lots so they would distribute Java with new PCs.
Let's take this one. Sun and others started with an acceptably good
language, with an acceptably designed set of libraries, then did some
very clever marketing (applets, gradually shifting to server side
stuff with a couple of strong sidelines based around being a language
that average programmers could actually reliably use (unlike C/C++),
portable GUIs, and not getting screwed by MS), and throughout this
whole process they spent lots and lots of money, which they had to
spend.
I suggest precisely this strategy for Lisp. We have the decent
language and possibly enough libraries to start. We need the
marketing, and the money. Cheques, in sterling, should be made
payable to the `Bradshaw retirement fund', thanks.
--tim
On Mon, 02 Feb 2004 21:49:36 -0500, Cameron MacKinnon wrote:
> I think that the community is turning away trend setters and
> influencers, precisely the people it needs, with its attitude of "If you
> want to eat hippopotamus, you've got to pay the freight."
Why do you think that "the community" needs "trend setters and
influencers"? Are you so insecure that you need to be trendy or seen to
be influencial?
Let me put it another way - "the community" was hideously savaged by
association with this type of people in the early '80's. This type is
more interested in their image than in the substance of the technology or
the good of "the community" and will jetison the later at the drop of a
hat (or more precisely, the "introduction of the new, new thing").
P.S. What the hell do you mean by "the community", anyway?
> They come,
> they're mocked and they go away again, to continue dining on python,
> camel and java.
People stupid enough to do so deserve their fate.
faa
Cameron MacKinnon <··········@clearspot.net> writes:
> I suspect that a lot of these people have written small applications and
> want to share them on the net. They're likely to be some of the most
> effective proselytizers of Lisp, introducing compelling apps to others,
> some of whom will get the source and become lispers themselves. What do
> they hear?
> - You can't do that
> - You can only do it with the commercial lisps
> - You can do it, but the binary will be 11MB
I don't understand his. I make executables all the time.
They are:
1) completely standalone.
Much more standalone than any of the usual Windows stuff. It's a drag-
and-drop install on linux and Mac OS X. Unfortunately, Windows users
don't expect installing to be that easy, so while my application _can_
be installed by dragging and dropping a single binary on Windows too,
the users expect me to give them the usual installer thing, so I have
to go through the ordeal of using those crappy installer-makers. Sigh.
2) small if the application is small
Ok, they're not very small, almost 10MB gzipped, but then I build them
with all whistles and bells turned on so that I can deliver the next
version as a "automatic patch" (a fasl file downloaded and LOADed
at runtime). For less demanding programs which needn't be that dynamic,
the binaries are 2-3MB (compressed).
The catch? I'm using a commercial lisp (LispWorks). But IMHO it's well
worth its money, which includes free distribution of those "standalone
applications".
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> at runtime). For less demanding programs which needn't be that dynamic,
> the binaries are 2-3MB (compressed).
Or even less:
[··@merced:/tmp]$ ls -l lisp-hello.gz
-rwxr-xr-x 1 ev ev 1052828 Feb 3 09:36 lisp-hello.gz
[··@merced:/tmp]$ gunzip lisp-hello.gz
[··@merced:/tmp]$ ls -l lisp-hello
-rwxr-xr-x 1 ev ev 2883612 Feb 3 09:36 lisp-hello
[··@merced:/tmp]$ ./lisp-hello
(hello world)
[··@merced:/tmp]$
--
(espen)
Cameron MacKinnon <··········@clearspot.net> writes:
> I suspect that a lot of these people have written small applications and
> want to share them on the net. They're likely to be some of the most
> effective proselytizers of Lisp, introducing compelling apps to others,
> some of whom will get the source and become lispers themselves. What do
> they hear?
> - You can't do that
> - You can only do it with the commercial lisps
> - You can do it, but the binary will be 11MB
I don't understand this. I make executables all the time.
They are:
1) completely standalone.
Much more standalone than any of the usual Windows stuff. It's a drag-
and-drop install on linux and Mac OS X. Unfortunately, Windows users
don't expect installing to be that easy, so while my application _can_
be installed by dragging and dropping a single binary on Windows too,
the users expect me to give them the usual installer thing, so I have
to go through the ordeal of using those crappy installer-makers. Sigh.
2) small if the application is small
Ok, they're not very small, almost 10MB gzipped, but then I build them
with all whistles and bells turned on so that I can deliver the next
version as a "automatic patch" (a fasl file downloaded and LOADed
at runtime). For less demanding programs which needn't be that dynamic,
the binaries are 2-3MB (compressed).
The catch? I'm using a commercial lisp (LispWorks). But IMHO it's well
worth its money, which includes free distribution of those "standalone
applications".
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> wrote in message news:<··············@merced.netfonds.no>...
>
> The catch? I'm using a commercial lisp (LispWorks). But IMHO it's well
> worth its money, which includes free distribution of those "standalone
> applications".
That's always the hidden subtext to these questions: you are not
allowed to use a commercial product to answer them. Remember that all
commercial software is evil, written by horrible, people who all want
to destroy the world while getting rich, crushing the proletariatand
who will generally be first up against the wall come the revolution.
Tim Bradshaw wrote:
> Espen Vestre <·····@*do-not-spam-me*.vestre.net> wrote in message news:<··············@merced.netfonds.no>...
>>The catch? I'm using a commercial lisp (LispWorks). But IMHO it's well
>>worth its money, which includes free distribution of those "standalone
>>applications".
>
> That's always the hidden subtext to these questions: you are not
> allowed to use a commercial product to answer them. Remember that all
> commercial software is evil, written by horrible, people who all want
> to destroy the world while getting rich, crushing the proletariatand
> who will generally be first up against the wall come the revolution.
I mentioned commercial Lisps in my original posting, which wasn't a
question.
For people whose business model (or hobby) is delivering small apps to a
comparatively large audience for free, I don't think commercial
offerings are precluded at all, provided that the runtime isn't licensed
on a per-user basis.
Perusing c.l.l[1], most posers of the question have either mentioned a
specific Lisp implementation (some commercial, some free), or explicitly
stated their price point with words like inexpensive or free.
Even if we say that all the rest of the posts have a "hidden subtext",
they'd still be a small minority. But I'm not willing to engage in this
sort of paranoia.
[1]
http://groups.google.com/groups?q=executable+group:comp.lang.lisp&hl=en&lr=&ie=UTF-8&start=10&sa=N
Cameron MacKinnon wrote:
> I mentioned commercial Lisps in my original posting, which wasn't a
> question.
My original post was, obviously, a question. But the question was "Why
does the lisp community abuse those who ask how to create executables?"
Cameron MacKinnon <··········@clearspot.net> writes:
> Cameron MacKinnon wrote:
> > I mentioned commercial Lisps in my original posting, which wasn't a
> > question.
>
> My original post was, obviously, a question. But the question was "Why
> does the lisp community abuse those who ask how to create executables?"
Your term "abuse" is certainly open to debate, but I'll assume for the
moment it's not too far off the mark. The reason people in
comp.lang.lisp react negatively to such questions is because they are
part of a class of questions which can be phrased something like the
following:
"Why is Lisp so weird?"
The most common variation on this is something like
"Why isn't Lisp more like XXXX?"
where XXXX is the latest horrid offering from the
programming-language-hype community.
The consensus among many Lisp aficionados is that Lisp is some kind of
local maximum in the programming universe, and when someone new comes
along and suggests "improvements" to make it more like the other
programming languagues, they are pessimizing rather than optimizing.
The other point is that people who come along asking questions like
the above often have the attitude that they are uttering profound
originalities, whereas because Lisp is so old, most everything that
can be tried has been tried in Lisp.
There's also the "cave man" view of Lisp:
"Ugh! Lisp different!! Me *suspicious*!!!"
This wears thin after a while.
Let's say someone comes, and says, "Can you make executables with
Lisp?" A perfectly correct answer would be "Yes, there are several
ways of doing it." But then you find that they really want something
just like what C does. But Lisp is different from C, and has a
different mind set. People who complain about that mark themselves as
poor candidates for learning Lisp, and probably not worth the trouble
of helping.
--
Fred Gilham ······@csl.sri.com
The nice thing about being a celebrity is that when you bore people,
they think it?s their fault. --- Henry Kissinger
That is certainly how most Common Lisp folks seem to feel, but counter
examples do exist. Siskind's stalin compiler is a beautiful example
of how lisp can do the right thing. It takes lisp source and gives
you a small, fast, native executable. No ideological arguments, just
great results!
Scott Schwartz <··········@usenet ·@bio.cse.psu.edu> writes:
> That is certainly how most Common Lisp folks seem to feel, but counter
> examples do exist. Siskind's stalin compiler is a beautiful example
> of how lisp can do the right thing. It takes lisp source and gives
> you a small, fast, native executable. No ideological arguments, just
> great results!
Great results? When my Stalin program destroys the material basis for
its rule ^[7^[^H crashes, can I pop into a debugger and *fix* it? I
am *not* willing to lose basic dynamicity! Give me C++ before a
"Lisp" that's not dynamic!
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
"Thomas F. Burdick" wrote:
>
> Scott Schwartz <··········@usenet ·@bio.cse.psu.edu> writes:
>
> > That is certainly how most Common Lisp folks seem to feel, but counter
> > examples do exist. Siskind's stalin compiler is a beautiful example
> > of how lisp can do the right thing. It takes lisp source and gives
> > you a small, fast, native executable. No ideological arguments, just
> > great results!
>
> Great results? When my Stalin program destroys the material basis for
> its rule ^[7^[^H crashes, can I pop into a debugger and *fix* it? I
> am *not* willing to lose basic dynamicity! Give me C++ before a
> "Lisp" that's not dynamic!
Wrong user set. We're programmers; we want the debugger, so we can
figure out why the crash happened and fix it. The rubber hits the
road when I deliver a system to a farmer in northern minnesota who's
using it to schedule his crop rotations and equipment maintenance.
What the hell is he going to do with a debugger window?
Bear
>>>>> "Ray" == Ray Dillinger <····@sonic.net> writes:
Ray> "Thomas F. Burdick" wrote:
>>
>> Scott Schwartz <··········@usenet ·@bio.cse.psu.edu> writes:
>>
>> > That is certainly how most Common Lisp folks seem to feel, but counter
>> > examples do exist. Siskind's stalin compiler is a beautiful example
>> > of how lisp can do the right thing. It takes lisp source and gives
>> > you a small, fast, native executable. No ideological arguments, just
>> > great results!
>>
>> Great results? When my Stalin program destroys the material basis for
>> its rule ^[7^[^H crashes, can I pop into a debugger and *fix* it? I
>> am *not* willing to lose basic dynamicity! Give me C++ before a
>> "Lisp" that's not dynamic!
Ray> Wrong user set. We're programmers; we want the debugger, so we can
Ray> figure out why the crash happened and fix it. The rubber hits the
Ray> road when I deliver a system to a farmer in northern minnesota who's
Ray> using it to schedule his crop rotations and equipment maintenance.
Ray> What the hell is he going to do with a debugger window?
Probably the same thing when your program without the debugger gets
the same error and crashes. The farmer restarts the program or
reboots his computer. Or worse yet, the program is confused and tells
him to plant his summer crops now.
Ray
Raymond Toy wrote:
>
> >>>>> "Ray" == Ray Dillinger <····@sonic.net> writes:
>
> Ray> Wrong user set. We're programmers; we want the debugger, so we can
> Ray> figure out why the crash happened and fix it. The rubber hits the
> Ray> road when I deliver a system to a farmer in northern minnesota who's
> Ray> using it to schedule his crop rotations and equipment maintenance.
> Ray> What the hell is he going to do with a debugger window?
>
> Probably the same thing when your program without the debugger gets
> the same error and crashes. The farmer restarts the program or
> reboots his computer. Or worse yet, the program is confused and tells
> him to plant his summer crops now.
No. He knows what crashes mean. He'll be annoyed by them but he
won't be unduly pissed off. If the program stops working by doing
something he doesn't understand, he will be much more upset than if
the program merely stops working. The debugger window, appearing
to end-users, is a bug, not a feature.
Bear
Ray Dillinger <····@sonic.net> writes:
> No. He knows what crashes mean. He'll be annoyed by them but he
> won't be unduly pissed off. If the program stops working by doing
> something he doesn't understand, he will be much more upset than if
> the program merely stops working. The debugger window, appearing
> to end-users, is a bug, not a feature.
(handler-bind ((condition (lambda (c)
(declare (ignore c))
(popup-window "Error ~D occured!" (random 1000))
(shutdown-system))))
(run-system))
the point is that in lisp you _can_ use the debugger, not that you
have to. where else do you get this choice?
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
Marco Baringer wrote:
>
> Ray Dillinger <····@sonic.net> writes:
>
> > No. He knows what crashes mean. He'll be annoyed by them but he
> > won't be unduly pissed off. If the program stops working by doing
> > something he doesn't understand, he will be much more upset than if
> > the program merely stops working. The debugger window, appearing
> > to end-users, is a bug, not a feature.
>
> (handler-bind ((condition (lambda (c)
> (declare (ignore c))
> (popup-window "Error ~D occured!" (random 1000))
> (shutdown-system))))
> (run-system))
>
> the point is that in lisp you _can_ use the debugger, not that you
> have to. where else do you get this choice?
>
The point is that linking to the runtime that gives that choice is
unsupportable on machines that don't have the runtime installed and
configured. I want it statically linked.
Bear
>>>>> On Sat, 07 Feb 2004 19:29:52 GMT, Ray Dillinger ("Ray") writes:
Ray> Marco Baringer wrote:
>>
>> Ray Dillinger <····@sonic.net> writes:
>>
>> > No. He knows what crashes mean. He'll be annoyed by them but he
>> > won't be unduly pissed off. If the program stops working by doing
>> > something he doesn't understand, he will be much more upset than if
>> > the program merely stops working. The debugger window, appearing
>> > to end-users, is a bug, not a feature.
>>
>> (handler-bind ((condition (lambda (c)
>> (declare (ignore c))
>> (popup-window "Error ~D occured!" (random 1000))
>> (shutdown-system))))
>> (run-system))
>>
>> the point is that in lisp you _can_ use the debugger, not that you
>> have to. where else do you get this choice?
>>
Ray> The point is that linking to the runtime that gives that choice is
Ray> unsupportable on machines that don't have the runtime installed and
Ray> configured. I want it statically linked.
What are you talking about? All the Lisp executables that I have ever
delivered were statically linked, and you can do that on any platform.
* Ray Dillinger wrote:
> No. He knows what crashes mean. He'll be annoyed by them but he
> won't be unduly pissed off. If the program stops working by doing
> something he doesn't understand, he will be much more upset than if
> the program merely stops working. The debugger window, appearing
> to end-users, is a bug, not a feature.
This kind of complaining reminds me of Java. I've seen a fair number
of Java applications which, when they get a fairly straightforward
error, produce a large and almost completely uninformative stacktrace
and then exit. Is this Java's fault? No, of course it's not: it's the
fault of whoever wrote the application and didn't bother to handle the
error properly but let it fall through into some fallback handler
useful in development but not production. It's unfortunate that
languages with better exception-handling and debugging features (you
don't generally get a stacktrace from C runtimes) require some work to
produce `production' applications, but it's not their fault.
--tim (the error is almost always actually `you didn't set DISPLAY')
Ray Dillinger <····@sonic.net> writes:
> Wrong user set. We're programmers; we want the debugger, so we can
> figure out why the crash happened and fix it. The rubber hits the
> road when I deliver a system to a farmer in northern minnesota who's
> using it to schedule his crop rotations and equipment maintenance.
> What the hell is he going to do with a debugger window?
Exactly.
Ever see a "something crashed; strike any key to continue" dialog box
on kiosk with no keyboard? A lisp prompt would be just as amusing in
that situation. More importantly, many programs are not connected to
terminals at all; they may have standard input and output as a network
connection and standard error as a log file. You really don't want to
to pop up a debugger there.
* Scott Schwartz wrote:
> Ever see a "something crashed; strike any key to continue" dialog box
> on kiosk with no keyboard? A lisp prompt would be just as amusing in
> that situation. More importantly, many programs are not connected to
> terminals at all; they may have standard input and output as a network
> connection and standard error as a log file. You really don't want to
> to pop up a debugger there.
But you often do want an informative error to be logged:
`floating point underflow in ZOG, called from ZAG ... restarting thread'
is somewhat better than
`Something bad happened, no idea what it was or where, sorry'
Ray Dillinger <····@sonic.net> writes:
> "Thomas F. Burdick" wrote:
> >
> > Scott Schwartz <··········@usenet ·@bio.cse.psu.edu> writes:
> >
> > > That is certainly how most Common Lisp folks seem to feel, but counter
> > > examples do exist. Siskind's stalin compiler is a beautiful example
> > > of how lisp can do the right thing. It takes lisp source and gives
> > > you a small, fast, native executable. No ideological arguments, just
> > > great results!
> >
> > Great results? When my Stalin program destroys the material basis for
> > its rule ^[7^[^H crashes, can I pop into a debugger and *fix* it? I
> > am *not* willing to lose basic dynamicity! Give me C++ before a
> > "Lisp" that's not dynamic!
>
> Wrong user set. We're programmers; we want the debugger, so we can
> figure out why the crash happened and fix it. The rubber hits the
> road when I deliver a system to a farmer in northern minnesota who's
> using it to schedule his crop rotations and equipment maintenance.
> What the hell is he going to do with a debugger window?
I didn't say I deliver applications that drop you into the default
system debugger (I don't!). A delivered debugger might just be a
dialog explaining that something went wrong, but all maynot be lost;
click <here> to submit a bug report. Click <here> if you have
important data that you haven't saved yet. I can send a patch that
will let them resume working. I know that's not what the farmer
expects, but he should! Just because most software is crap, it's not
an excuse for producing crappy software when you can help it.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
"Thomas F. Burdick" <···@famine.OCF.Berkeley.EDU> wrote :
> I didn't say I deliver applications that drop you into the default
> system debugger (I don't!). A delivered debugger might just be a
> dialog explaining that something went wrong, but all maynot be lost;
> click <here> to submit a bug report. Click <here> if you have
> important data that you haven't saved yet. I can send a patch that
> will let them resume working. I know that's not what the farmer
> expects, but he should! Just because most software is crap, it's not
> an excuse for producing crappy software when you can help it.
In my web applications, I collect the error and stack data and then email it
to the admin and me.
This generally always enough for me to send a correcting patch.
Something like the data below.
Marc
****************************************************
Thu, 05 Feb 2004 23:35:00 Error : Can't open port 25 on host "127.0.0.1"
****************************************************
#<PACKAGE COMMON-LISP-USER>
[...]
Call to (SUBFUNCTION 1 OTFR::SEND-OPEN-EMAIL) (offset 1002)
*PRINT-PRETTY* : NIL
*PRINT-CIRCLE* : NIL
Binding frame:
OTFR::*EMAIL-LIST* : NIL
Call to OTFR::SEND-OPEN-EMAIL (offset 1008)
OTFR::PROCESS-GUICHET : <FC-Object PROCESS-GUICHET
9052959008838657161 (NIL)>
OTFR::REQUEST : <FC-Object REQUEST 5812257427814360200
(NIL)>
OTFR::SEND-LIST : NIL
DBG::NAME : "\"TransNet\"<····@xxxx.com>"
OTFR::*EMAIL-LIST* :
("\"xxxxxxxxxxxx\"<····@xxxxxxxxxxxxxx.com>"
"\"xxxxxxxxxxxxxxxx\"<···@xxxxxxxxxxxxx.com>")
DBG::HOST : "127.0.0.1"
DBG::PORT : 25
DBG::SUBJECT : "[D9352] Demande d'ouvertures
flux/routes - Escalade niveau 1"
DBG::EMAIL : "\"xxxxxx\"<·····@xxxxxxxxxxxxxxx.com>"
DBG::|tail-| : ("\"Trouv� ···········@xxxxxxxxxxx.com>" )
DBG::LOGGED-ERROR-FN : #<closure (SUBFUNCTION 1
OTFR::SEND-OPEN-EMAIL) 24A0F9CA>
CONDITIONS::*HANDLER-CLUSTERS* : (((ERROR .
CONDITIONS::NEW-IGNORE-ERRORS-HANDLER)) ((ERROR . #<function (SUBFUNCTION 1
UTILITY::CALL/BACKTRACE) 217D5C82>)) ((ERROR .
CONDITIONS::NEW-IGNORE-ERRORS-HANDLER)))
Call to (METHOD OTFR::PROCESS-TIMEOUTS (OTFR::PROCESS-OTFR T)) (offset 27)
OTFR::REQUEST : <FC-Object REQUEST 5812257427814360200 (NIL)>
TIME : 3285009298
CLOS::.ISL. : :DONT-KNOW
Thomas F. Burdick <···@famine.ocf.berkeley.edu> wrote:
> I didn't say I deliver applications that drop you into the default
> system debugger (I don't!). A delivered debugger might just be a
> dialog explaining that something went wrong, but all maynot be lost;
> click <here> to submit a bug report. Click <here> if you have
> important data that you haven't saved yet. I can send a patch that
> will let them resume working. I know that's not what the farmer
> expects, but he should! Just because most software is crap, it's not
> an excuse for producing crappy software when you can help it.
A basic model might be what Mac OS X does when a Cocoa application
throws its stack at you. Instead of a debugger or a core, you get a
dialog with the option to send the stack to Apple with a comment.
Exactly what sorts of comments most users send in when their application
goes kablooie, I'm not sure I want to know.
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
Ray Dillinger <····@sonic.net> writes:
> Wrong user set. We're programmers; we want the debugger, so we can
> figure out why the crash happened and fix it. The rubber hits the
> road when I deliver a system to a farmer in northern minnesota who's
> using it to schedule his crop rotations and equipment maintenance.
> What the hell is he going to do with a debugger window?
So if you have a use case where you don't want the debugger, you
deliver your system in such a way that it doesn't go into the
debugger, or without the debugger altogether. Duh.
But frankly it's nice to have the option, particularly since (as I
suspect you well know) not all delivered applications are quite as
isolated as the one you have used as an example.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
On Thu, Feb 05, 2004 at 01:56:54AM -0500, Scott Schwartz wrote:
> That is certainly how most Common Lisp folks seem to feel, but counter
> examples do exist. Siskind's stalin compiler is a beautiful example
> of how lisp can do the right thing. It takes lisp source and gives
> you a small, fast, native executable. No ideological arguments, just
> great results!
If, by the right thing, you mean the same thing that C programs do, then
perhaps. But most Lisp programmers are interested in better behavior
than what C programs exhibit.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish <·······@andrew.cmu.edu> writes:
> If, by the right thing, you mean the same thing that C programs do,
No, I didn't mention C.
> then
> perhaps. But most Lisp programmers are interested in better behavior
> than what C programs exhibit.
Some are, some aren't, and there seems to be some difference of
opinion about what constitutes better behavior. Not to mention some
angst about why python is more popular than Common Lisp, even though
the answer to that question is obvious.
Scott Schwartz <··········@usenet ·@bio.cse.psu.edu> writes:
> Matthew Danish <·······@andrew.cmu.edu> writes:
> > then perhaps. But most Lisp programmers are interested in better
> > behavior than what C programs exhibit.
>
> Some are, some aren't, and there seems to be some difference of
> opinion about what constitutes better behavior. Not to mention some
> angst about why python is more popular than Common Lisp, even though
> the answer to that question is obvious.
Must be because a file starting with
#!/usr/bin/env python
is a small standalone executable.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID #xEEFBA4AF
In article <··············@darkstar.cartan.de>,
+---------------
| Scott Schwartz <··········@usenet ·@bio.cse.psu.edu> writes:
| > ...angst about why python is more popular than Common Lisp, even though
| > the answer to that question is obvious.
|
| Must be because a file starting with
| #!/usr/bin/env python
| is a small standalone executable.
+---------------
But then, so is a file starting with:
#!/usr/local/bin/clisp
or, for that matter, starting with this:
":" ; exec cmucl -quiet -noinit -load "`which $0`" ······@"}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
> #!/usr/local/bin/clisp
Obviously if you write an interpreter that runs under unix you should
support the #! convention; it would be absurd not to. But it's not
enough to get just one thing right. Perl, python, ruby, etc, go to a
lot of effort to be good for writing unix programs, while Common Lisp
seems to have a different mission.
Scott Schwartz <··········@usenet ·@bio.cse.psu.edu> wrote in message news:<··············@galapagos.bx.psu.edu>...
> Matthew Danish <·······@andrew.cmu.edu> writes:
> > If, by the right thing, you mean the same thing that C programs do,
>
> No, I didn't mention C.
>
> > then
> > perhaps. But most Lisp programmers are interested in better behavior
> > than what C programs exhibit.
>
> Some are, some aren't, and there seems to be some difference of
> opinion about what constitutes better behavior. Not to mention some
> angst about why python is more popular than Common Lisp, even though
> the answer to that question is obvious.
Python is popular because it is new.
When something is new, it is accompanied by an absence of historic
criticism, so naive *have* to jump on it and try it rather than look
for ready-made excuses not to. Users and programmers are lazy; they
hate learning new stuff. When they find out about the existence of
something unfamiliar, their instinct is to look for excuses to avoid
learning about it. If that something is new, it's hard to find such
excuses so eventually they have to cave in and put in the real effort.
Then there is a cascading effect: second and additional waves of
adopters arrive who are more reluctant, but are forced in some way.
If Lisp didn't exist a few years ago and you introduced it today,
you'd see exactly the same effect. From the point of view of someone
who is scared of nested parentheses, XML is even worse. Yet XML is
popular simply because it's new. If XML were twenty, thirty years old,
it would not be popular today. Perhaps everyone would be using
S-expressions, the world long having realized its error and abandoned
the silly syntax. Someone hearing about XML for the first time would
immediately find exuses not to learn anything about it by doing a
search for any material that covers its disadvantages.
So this is the position that Lisp is in today. Newbie hears about
Lisp, newbie does net search that is biased toward finding a synopsis
that summarizes what is wrong with Lisp so he can have a ready-made
excuse for not knowing anything more. Newbie finds writing containing
biased, misleading or outright incorrect statements ranging from the
recent to deades old (e.g. ``Lisp has little support for data
structures other than lists'', ``Lisp is slow because of the
interpreter and big garbage collection pauses'', ``nested parentheses
are hard to understand and maintain'', etc). Newbie's search for his
excuse is satisfied, and that's it. Next time Lisp is mentioned in
newbie's presence, he is now armed with information! ``Oh that! I
don't use it because I'm very well aware that it has little support
for data structures other than lists.''
And that's how popularity works.
If you want to be a socially popular person, again, you have to look
and behave in such a way that diverse cateogries of people don't have
immediate excuse not to get to know you or like you. This doesn't
imply having a good character, merely a nice appearance (face, body,
clothes, grooming) and a consummately faked pleasant personality.
Again, it helps if you are new, in different senses: you posess youth,
or are unfamiliar, or both. Being young and unknown helps, because
there is either no record regarding flaws in your character, or it's
very brief. :)
···@ashi.footprints.net (Kaz Kylheku) writes:
> Python is popular because it is new.
More than 10 years old counts as new? Ok, whatever. But that's not
the reason.
Scott Schwartz <··········@usenet ·@bio.cse.psu.edu> wrote in message news:<··············@galapagos.bx.psu.edu>...
> ···@ashi.footprints.net (Kaz Kylheku) writes:
> > Python is popular because it is new.
>
> More than 10 years old counts as new? Ok, whatever.
When is something new? When a baby is born, it's nine months old
already.
It takes about a decade of gestation for something to be ``born'' in
computing. By then it's old to the creators and early adopters, but
new to the world.
> But that's not
> the reason.
Let's put it this way. Something that is not new can hardly become
popular. Novelty appears to be a necessary condition, though not
sufficient. In reality, the logic is fuzzy, so it's inappropriate to
use absolute terms like ``necessary condition''. More like, novelty is
an excellent predictor of popularity.
Something just has to appear new to be considered new, because people
don't bother to trace the true origin of something, relying instead on
name equivalence and shallow structural equivalence. Change the name,
revise some trivial structural details here and there, and the origin
becomes opaque to the masses, because it now requires work to unearth,
and it requires understanding to determine what correct statements
about the old entity are still correct about the new entity, never
mind determining which of the old statements are correct to begin
with.
···@ashi.footprints.net (Kaz Kylheku) writes:
> > Some are, some aren't, and there seems to be some difference of
> > opinion about what constitutes better behavior. Not to mention some
> > angst about why python is more popular than Common Lisp, even though
> > the answer to that question is obvious.
>
> Python is popular because it is new.
GvR started developing Python seriously in late 1989, the first public
release was in 1991 - three years before the release of ANSI common
Lisp, 4 years before the first public announcement of Java.
> If Lisp didn't exist a few years ago and you introduced it today,
> you'd see exactly the same effect. From the point of view of someone
> who is scared of nested parentheses, XML is even worse. Yet XML is
> popular simply because it's new.
XML is not new, it is a crippled variant of SGML, simple enough that
even Microsoft or Oracle could manage to write a mostly conforming
parser for it, not only small corporations and free software projects
(which, admittedly, tended to be called "James Clark" in case of SGML,
but that hasn't really changed). The general ideas, and a lot of the
thinks that can only be explained as historical arifacts, have their
roots in markup languages decades old.
> If you want to be a socially popular person, again, you have to look
> and behave in such a way that diverse cateogries of people don't have
> immediate excuse not to get to know you or like you. This doesn't
> imply having a good character, merely a nice appearance (face, body,
> clothes, grooming) and a consummately faked pleasant personality.
That I have to agree with.
Henrik Motakef <············@henrik-motakef.de> writes:
> ···@ashi.footprints.net (Kaz Kylheku) writes:
>
> > From the point of view of someone who is scared of nested
> > parentheses, XML is even worse. Yet XML is popular simply because
> > it's new.
>
> XML is not new, it is a crippled variant of SGML, [...]
And what percentage of XML users know that? XML is /perceived/ as
new, which is all that counts.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID #xEEFBA4AF
Henrik Motakef <············@henrik-motakef.de> wrote in message news:<··············@crocket.internal.henrik-motakef.de>...
> ···@ashi.footprints.net (Kaz Kylheku) writes:
>
> > > Some are, some aren't, and there seems to be some difference of
> > > opinion about what constitutes better behavior. Not to mention some
> > > angst about why python is more popular than Common Lisp, even though
> > > the answer to that question is obvious.
> >
> > Python is popular because it is new.
>
> GvR started developing Python seriously in late 1989, the first public
> release was in 1991 - three years before the release of ANSI common
> Lisp, 4 years before the first public announcement of Java.
>
> > If Lisp didn't exist a few years ago and you introduced it today,
> > you'd see exactly the same effect. From the point of view of someone
> > who is scared of nested parentheses, XML is even worse. Yet XML is
> > popular simply because it's new.
>
> XML is not new, it is a crippled variant of SGML, simple enough that
> even Microsoft or Oracle could manage to write a mostly conforming
But because of the name change, XML is disassociated from SGML.
> parser for it, not only small corporations and free software projects
> (which, admittedly, tended to be called "James Clark" in case of SGML,
> but that hasn't really changed). The general ideas, and a lot of the
> thinks that can only be explained as historical arifacts, have their
> roots in markup languages decades old.
That means nothing. People don't look at the genealogy of the ideas
when they determine whether something is old or new. That requires
work, and the deeper you trace, the more work it requires. It also
requires even more work to understand whether some criticism of an
ancestor applies to the descendant.
In the case of something whose name does not change, like Lisp, people
take criticisms of some very old ancestor to be true of the
descendant. The ancestor doesn't even have to be a true ancestor, but
some offshoot from the lineage. And because of the same name, the
material is not hard to find using that name as a search key. You
don't first have to traverse a genealogy tree to collect a myriad of
names, and then separately trace them all down. Here is how people
think: ``If those criticims are not true of the new entity, the people
who fixed them would have changed the name to disassociate the new
entity from the shortcomings of its ancestor.''
Humans are programmed by evolution to take inductive shortcuts in
order to deal with information in a timely way. When you are faced
with an animal wielding sharp claws an teeth, you run first. *Then*
you contemplate that perhaps not all such animals are necessarily
dangerous.
Matthew Danish wrote:
> On Thu, Feb 05, 2004 at 01:56:54AM -0500, Scott Schwartz wrote:
>>That is certainly how most Common Lisp folks seem to feel, but counter
>>examples do exist. Siskind's stalin compiler is a beautiful example
>>of how lisp can do the right thing. It takes lisp source and gives
>>you a small, fast, native executable. No ideological arguments, just
>>great results!
> If, by the right thing, you mean the same thing that C programs do, then
> perhaps. But most Lisp programmers are interested in better behavior
> than what C programs exhibit.
Stalin takes a Scheme program and compiles it to one (large)
C file importing code for the runtime. The C file is then compiled
to one standalone executable.
(If my memory serves me right)
--
Jens Axel S�gaard
Fred Gilham wrote:
> The consensus among many Lisp aficionados is that Lisp is some kind of
> local maximum in the programming universe, and when someone new comes
> along and suggests "improvements" to make it more like the other
> programming languagues, they are pessimizing rather than optimizing.
I don't think these posters are suggesting improvements when they ask
the question. They just want to ship code.
How long has the current Lisp "on disk" model been around, and what
other ideas were tried and discarded? I haven't seen any data on this in
my readings.
> Let's say someone comes, and says, "Can you make executables with
> Lisp?" A perfectly correct answer would be "Yes, there are several
> ways of doing it." But then you find that they really want something
> just like what C does. But Lisp is different from C, and has a
> different mind set. People who complain about that mark themselves as
> poor candidates for learning Lisp, and probably not worth the trouble
> of helping.
What's the difference between a Lisp generated executable and "something
just like what C does"? Could you cite an example of someone who was
told how to do the first and went on to ask for the second?
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon <··········@clearspot.net> writes:
> What's the difference between a Lisp generated executable and "something
> just like what C does"? Could you cite an example of someone who was
> told how to do the first and went on to ask for the second?
An example is that many common lisp runtime systems may write messages
to standard output, and may read from standard input, and thus are not
reliably usable in shell pipelines. It's a question of following the
conventions of the system, not imitating linguistic features of C.
>>>>> On 05 Feb 2004 18:01:19 -0500, Scott Schwartz ("Scott") writes:
Scott> Cameron MacKinnon <··········@clearspot.net> writes:
>> What's the difference between a Lisp generated executable and "something
>> just like what C does"? Could you cite an example of someone who was
>> told how to do the first and went on to ask for the second?
Scott> An example is that many common lisp runtime systems may write messages
Scott> to standard output, and may read from standard input, and thus are not
Scott> reliably usable in shell pipelines. It's a question of following the
Scott> conventions of the system, not imitating linguistic features of C.
Are you saying that Lisp randomly decides to do I/O on the
implementation's standard input and output streams without
the programmer having called for that?
I would consider that a serious bug in the Lisp implementation.
If you're saying that Common Lisp programers write programs that
perform IO that you were not expecting, then I'd suggest shooting
the programmer.
My programs don't do that. In fact, the program I am writing at this
very moment happens to be a replacement for a C command-line program
that runs on Unix and does its work through stdin/stdout.
······@news.dtpq.com (Christopher C. Stacy) writes:
> Are you saying that Lisp randomly decides to do I/O on the
> implementation's standard input and output streams without
> the programmer having called for that?
Yes. To take one example, in the event of stack overflow clisp's
runtime system will write error messages to file descriptor number
one. To take another example, cmucl will write informative messages
about file loading, etc, to stdout. There's a command line option to
suppress "most unnecessary noise", but it doesn't say all, and it
shouldn't go to stdout in the first place. And of course, the
debugger will read from stdin unless you take steps to prevent it,
with handler-case or something.
> My programs don't do that. In fact, the program I am writing at this
> very moment happens to be a replacement for a C command-line program
> that runs on Unix and does its work through stdin/stdout.
That's a useful thing for the FAQ: an implementation of
(with-normal-unix-behavior (main argv))
so that everyone doesn't have to reinvent it all the time.
>>>>> On 06 Feb 2004 23:40:35 -0500, Scott Schwartz ("Scott") writes:
Scott> Yes. To take one example, in the event of stack overflow
Scott> clisp's runtime system will write error messages to file
Scott> descriptor number one.
Common Lisp does not define any behaviour in terms of Unix file
descriptors. Perhaps there is a bug in the implementation of CLISP,
or perhaps your understanding of the language is incomplete and
you are jumping to conclusions about what's going on.
Scott> To take another example, cmucl will write informative
Scott> messages Scott> about file loading, etc, to stdout.
I bet that it really writes it to whatever stream bound to the Lisp
variable *standard-output* (or some other stream) which is not
necessarily connected to the Unix stdout file descriptor.
If you are using some implementation that connects *standard-output*
to stdout, but you want to use stdout for some other purpose,
maybe you should consider disconnecting them from each other?
If you are unable to do that, I'd consider that a bug.
Scott> That's a useful thing for the FAQ: an implementation of
Scott> (with-normal-unix-behavior (main argv))
Awww, I'm just going to leave that straight-line alone, today...
······@news.dtpq.com (Christopher C. Stacy) writes:
>>>>>> On 06 Feb 2004 23:40:35 -0500, Scott Schwartz ("Scott") writes:
>
> Scott> Yes. To take one example, in the event of stack overflow
> Scott> clisp's runtime system will write error messages to file
> Scott> descriptor number one.
>
> Common Lisp does not define any behaviour in terms of Unix file
> descriptors. Perhaps there is a bug in the implementation of CLISP,
To be fair, it doesn't define much in the way of behaviour in the case
of stack overflow either. In SBCL - at least, in versions where this
is not broken - we signal a STORAGE-CONDITION, but you have to be
quite careful to handle this safely without using much stack (there's
a guard zone, but obviously it's smaller than the usual stack)
Traditional unix behaviour at this point would be to thrash the disk
for a bit while dumping core and then to die. We could do this instead,
if people would find it more useful behaviour?
-dan
--
"please make sure that the person is your friend before you confirm"
Daniel Barlow <···@telent.net> writes:
...
> Traditional unix behaviour at this point would be to thrash the disk
> for a bit while dumping core and then to die. We could do this instead,
> if people would find it more useful behaviour?
Now _that's_ funny.
-Tim
······@news.dtpq.com (Christopher C. Stacy) writes:
> Scott> Yes. To take one example, in the event of stack overflow
> Scott> clisp's runtime system will write error messages to file
> Scott> descriptor number one.
>
> Common Lisp does not define any behaviour in terms of Unix file
> descriptors. Perhaps there is a bug in the implementation of CLISP,
> or perhaps your understanding of the language is incomplete and
> you are jumping to conclusions about what's going on.
No, it's an actual bug in the runtime system. In fact, it appears to
be fixed in the current release.
Scott Schwartz <··········@usenet ·@bio.cse.psu.edu> writes:
> Cameron MacKinnon <··········@clearspot.net> writes:
> > What's the difference between a Lisp generated executable and "something
> > just like what C does"? Could you cite an example of someone who was
> > told how to do the first and went on to ask for the second?
>
> An example is that many common lisp runtime systems may write messages
> to standard output, and may read from standard input, and thus are not
> reliably usable in shell pipelines. It's a question of following the
> conventions of the system, not imitating linguistic features of C.
That's not exactly correct. They read from *standard-input* and write
to *standard-output*, and to/from *trace-io*, *query-io*,
*terminal-io*, *debug-io* and *error-output*, all of which are special
variable so you can easily redirect them to wherever you want (while
still being able to control what goes to/from the unix standard file
descriptors.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Fred Gilham wrote:
>
> Let's say someone comes, and says, "Can you make executables with
> Lisp?" A perfectly correct answer would be "Yes, there are several
> ways of doing it." But then you find that they really want something
> just like what C does. But Lisp is different from C, and has a
> different mind set. People who complain about that mark themselves as
> poor candidates for learning Lisp, and probably not worth the trouble
> of helping.
Excuse me. I have not made such a request on the newsgroup, and I
am not a newbie, but "just like what C does" *IS* the expectation
that I have to conform to in order to produce software that other
people can use. I have to deliver an executable that my customer,
client, or user can use and treat in exactly the same way that he
or she treats all other executables - most of which are built
with C++ systems - or my user base will ignore my program to death.
That means it needs to be statically linked machine code that they
can invoke from a unix command line in exactly the same way they invoke
other statically linked machine code executables.
I can't ask my user base to install strange packages and configure
runtimes, or enter commands into an unfamiliar CLI (the lisp shell)
etc just to use my little program; Every thing they need to do, no
matter how insignificant to me, is something that can go wrong for
them making it unusable.
I can afford dynamic links to Libc, perhaps, or other libraries that
exist on every unix system. But if there are lots of systems out
there that don't have it, or configuration that homer husband and
harriet housewife can mess it up by doing wrong or failing to do,
then I want it statically linked.
Bear
Ray Dillinger <····@sonic.net> writes:
> Fred Gilham wrote:
> >
> > Let's say someone comes, and says, "Can you make executables with
> > Lisp?" A perfectly correct answer would be "Yes, there are several
> > ways of doing it." But then you find that they really want something
> > just like what C does. But Lisp is different from C, and has a
> > different mind set. People who complain about that mark themselves as
> > poor candidates for learning Lisp, and probably not worth the trouble
> > of helping.
>
> Excuse me. I have not made such a request on the newsgroup, and I
> am not a newbie, but "just like what C does" *IS* the expectation
> that I have to conform to in order to produce software that other
> people can use. I have to deliver an executable that my customer,
> client, or user can use and treat in exactly the same way that he
> or she treats all other executables - most of which are built
> with C++ systems - or my user base will ignore my program to death.
>
> That means it needs to be statically linked machine code that they
> can invoke from a unix command line in exactly the same way they invoke
> other statically linked machine code executables.
Have you tried my CMUCL version that makes executables? :-)
No, it doesn't make statically linked binaries, I admit.
Here's one I built for a project that's running right now....
pipe# ls -la sdlp-app
-rwxr-xr-x 1 sdlpipe sdlpipe 21309797 Oct 29 16:10 sdlp-app
pipe# file sdlp-app
sdlp-app: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 4.8, dynamically linked (uses shared libs), not stripped
pipe# ldd sdlp-app
sdlp-app:
libm.so.2 => /usr/lib/libm.so.2 (0x2807d000)
libc.so.4 => /usr/lib/libc.so.4 (0x2809a000)
pipe#
It's a web application for some internal tracking we want to do. It
is self-starting. You just type "sdlp-app" and you're up and running.
And there's no trickery, it's a genuine ELF binary. The Lisp image is
built into some extra ELF sections that get mapped by the startup
code.
You create these using the following invocation:
(save-lisp "sdlp-app" :executable t)
Unfortunately the hack that I use to do this is unportable, and I
haven't had time to do the more portable version I've envisioned. But
it's not that far away from being a reasonable application delivery
system.
I wrote code to do the above, and there is also GCL that builds
executable applications, and others. So Lisp has ways to do this;
they are a little different but they still seem to serve the purpose.
--
Fred Gilham ······@csl.sri.com
We have a two party system. One party wants to drive the country
full-speed off a cliff. The other party wants to drive off the same
cliff, but insists on obeying the posted speed-limit.
Cameron MacKinnon <··········@clearspot.net> writes:
> My original post was, obviously, a question. But the question
> was "Why does the lisp community abuse those who ask how to
> create executables?"
"how can i cover up, or otherwise hide
and keep undisclosed, my experiments inside?"
"experiment? or experience? is there no locus
whereby these concepts may share spotlight, focus?"
"wtf! back off! i just wanna deliver a package.
(my users don't grok w/ the low-level hackage.)"
"what is the high high? where is the low low?
truth and fidelity are less if you go slow?"
"it's sad that i have to join the accusers:
those who have wisdom are the self-same abusers."
"but how should i cover up, or otherwise feign
and keep undisclosed, my experience gained?"
"experience? or excrement? is there no forum
where politely put questions are met w/ decorum?"
"wtf! back off! my name is not Abigail.
maybe this OT spew we can take to private mail?"
"how does the lie lie? why does the flow flow?
are you afraid to admit that you really don't know?"
"too bad we've botched our chance at self-censorship.
some idiot poet has made an attempt at svelte mentor quips."
··········@tfeb.org (Tim Bradshaw) writes:
> That's always the hidden subtext to these questions: you are not
> allowed to use a commercial product to answer them. Remember that all
> commercial software is evil, written by horrible, people who all want
> to destroy the world while getting rich, crushing the proletariatand
> who will generally be first up against the wall come the revolution.
Oh come on. There is not always this hidden subtext, and you should
know perfectly well that the strawman you make up does not reflect the
position of most users (or implementors) of free/open source Lisps, at
least not of those who speak up in cll.
The CMUCL/SBCL/ECL/CLISP guys do not seem to be on a Djihad against
commercial software vendors for all I can tell. Neither is Franz,
Inc. I guess, who wrote a lot of free Lisp stuff, and a GNU-derived
license for it to boot. Neither can I imagine most of the authors of
asdf-installable free libraries, or much of the stuff available in the
CMU AI repo for that matter, to secretly be members of stalinist
organizations.
Did it ever occur to you that people who just want to try Lisp, not
doing anything too serious and hence not willing to spend a lot of
money (it has become quite unusual to have to pay anything before you
can use a language; except for Delphi and VB6, I can't think of many
popular languages that do not have a free implementation) and who
already decided to use a Unix platform (which today basically means
"any non-windows platform") could indeed be better served by a free
implementation than with, say, a trial version of Lispworks or
Allegro? It can be just a simple, completely rational decision - can
you live with heap-size/time/delivery/whatever restrictions, or would
it be better to ignore the "upgrade" path to a fully supported version
and use a fully functional version of a Lisp system that has more
features right now, for zero cost, but might not have all the features
you'll get once you shell out the money for a full version? This is
something that everyone has to decide based on the specific
requirements for a concrete project, neither decision is morally right
or wrong.
There are good arguments for free software, and they do not have much
to do with the stereotypical raving zealot you imply, and there are
good arguments against it. There are also stupid arguments on both
sides, but I'd rather not have these discussed on cll frequently, and
so far my impression is that the discussion style of the resident
free-software camp has been pretty civilized (the occasional die-hard
GNU troll did happen, but went away quickly, without getting too much
support). Please keep it at that level. The "Lisp community" might be
small (or non-existing as such), but there is room for both views.
From: Joe Marshall
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <llnkgp1o.fsf@ccs.neu.edu>
Cameron MacKinnon <··········@clearspot.net> writes:
> At least once a month, someone asks how to deliver a "standalone"
> executable of a Lisp application. It's often his first post, and often
> his last.
>
> I suspect that a lot of these people have written small applications and
> want to share them on the net. They're likely to be some of the most
> effective proselytizers of Lisp, introducing compelling apps to others,
> some of whom will get the source and become lispers themselves. What do
> they hear?
> - You can't do that
> - You can only do it with the commercial lisps
> - You can do it, but the binary will be 11MB
>
> And those are just the serious answers. Some comedians try to convince
> the OP that he should be comparing the download size with all the C
> libraries that his users wouldn't have to download if the app was in C.
> Others suggest that what he really wants is a batch file, a lisp
> environment and a hassle, um, fasl file.
Often, these posters aren't interested in solving a problem but are
rather more interested in trolling.
If someone wants to distribute a C program, they zip up the executable
with the dll's and the lastest version of MFC and put it into a
install script.
If someone wants to distribute a Java program, they take the hierarchy
of class files, turn it into a JAR file and tell the user to get the
latest JRE from Sun.
So why are these acceptable, but the notion of zipping up a fasl file
and asking the user to get a lisp runtime is such a burden? Why is it
unacceptable to launch a program via a batch script, but perfectly
fine to launch it via a `shortcut'? Why is it unacceptable to simply
paste the lisp image onto the tail end of the launcher program?
Why does anyone *care* what the deliverable format is if they are
going to zip it all up anyway?
Joe Marshall wrote:
> Cameron MacKinnon <··········@clearspot.net> writes:
>>At least once a month, someone asks how to deliver a "standalone"
>>executable of a Lisp application. It's often his first post, and often
>>his last.
>
> Often, these posters aren't interested in solving a problem but are
> rather more interested in trolling.
I have to emphatically disagree. There are trolls out there, but these
people aren't them. Their question is quite a reasonable one, given a
background in other programming languages. And the fact that a
continuing stream of people shows up here and asks more or less the same
question ought to highlight an area where the documentation could use
improvement.
> If someone wants to distribute a C program, they zip up the executable
> with the dll's and the lastest version of MFC and put it into a
> install script.
It should be remembered how this process came about: In the Windows
world, where the dll search path was short and hardcoded, the namespace
was 8.3 (with the last 3 being .dll) and the libraries in rapid flux and
buggy, this led to "DLL Hell" - installing or removing application B
made application A buggy or unusable, for reasons unclear to the end user.
Early install "shield" programs were as bad as the disease, but the name
of the market leader gives a clue as to the origin - to shield users and
developers from the pain of a poorly designed shared library model.
On the UNIX side, many developers, even today, continue to ship
monolithic, static binaries. This avoids support calls caused by the
user having subtly different library versions. The user pays, because
his two apps, both statically linked with e.g. Motif, can't share memory.
This is not to say that Lisp developers can't or shouldn't use
installers as well. As other posters have pointed out, some Windows
users are now so comfortable with the process that they're suspicious of
apps which don't provide one. And in recent years, progress has been
made - you don't always have to shut down all other applications before
and reboot the operating system after installing a minor app.
But it should be remembered that these installers were created to solve
problems that Lisp doesn't necessarily have.
> If someone wants to distribute a Java program, they take the hierarchy
> of class files, turn it into a JAR file and tell the user to get the
> latest JRE from Sun.
Or, if it's an applet, the browser walks the user through the process.
> So why are these acceptable, but the notion of zipping up a fasl file
> and asking the user to get a lisp runtime is such a burden? Why is it
> unacceptable to launch a program via a batch script, but perfectly
> fine to launch it via a `shortcut'? Why is it unacceptable to simply
> paste the lisp image onto the tail end of the launcher program?
It depends on the size and utility of the application. For a big enough
app, "get and install an Oracle DBMS" isn't considered an unreasonable
additional requirement. But for stuff at the smaller end, distributed
free for the asking over the 'net, every extra megabyte, prerequisite or
installation step will cause a significant fraction of end-users to
disqualify themselves.
To a certain extent, this is true of developers as well. Clicking on
"Build EXE" (is that what Windows IDE folks do these days?) or typing
"make" is universally acceptable. Finding and using an install wizard
somewhat less so. And so on.
Joe Marshall <···@ccs.neu.edu> writes:
> Often, these posters aren't interested in solving a problem but are
> rather more interested in trolling.
This is also my impression. A nice way of dealing with this class of
questions would be a FAQ with an "Why is CL not popular?" item. This
item would discuss
* The exe-thing. (Counterexamples: Java, Pearl, Python /are/ popular
but you can't generate exes either. The last time an exe-only
application was shipped by a major software company was in 1982 [1].)
* The speed thing.
(Maybe that's outdated: once some people believed if CL does
numerics as speedy as Fortran all Fortran developers would switch to
CL. Counterexamples are again: Java, Pearl, Python which /are/
popular but typically much slower than CL.)
* The garbage collection thing.
(Nobody buys that anymore. If anyone does: Counterexamples are...)
* Maybe a personal anecdote. (But CL is /extremely/ popular! I like
it a lot. And so does my colleague. Better of course would be a
link to a collection of success stories.)
If information like this was available in a FAQ one could easily point
newcomers there: They'd have their answers and people would save time.
When I google for "LISP FAQ" I get a number of results. Is any FAQ
considered especially relevant? Could one transfer that to a Wiki and
work together in creating a useful and up-to-date FAQ? Has it already
been done?
---
[1] The figure 1982 is made up.
Hello!
Matthias <··@spam.pls> wrote:
>Joe Marshall <···@ccs.neu.edu> writes:
>> Often, these posters aren't interested in solving a problem but are
>> rather more interested in trolling.
>This is also my impression. A nice way of dealing with this class of
>questions would be a FAQ with an "Why is CL not popular?" item. This
>item would discuss
>* The exe-thing. (Counterexamples: Java, Pearl, Python /are/ popular
> but you can't generate exes either. The last time an exe-only
> application was shipped by a major software company was in 1982 [1].)
The "Pearl" you probably mean is written "Perl". There's a programming
language which is written "Pearl" but you probably don't mean it
(it's some kind of mostly event based realtime programming language
thing, and there are IIRC compiled implementations where at least the
code efficiency will probably be better than that of Perl).
>* The speed thing.
> (Maybe that's outdated: once some people believed if CL does
> numerics as speedy as Fortran all Fortran developers would switch to
> CL. Counterexamples are again: Java, Pearl, Python which /are/
> popular but typically much slower than CL.)
>[...]
Kind regards,
Hannah.
······@schlund.de (Hannah Schroeter) writes:
> >* The exe-thing. (Counterexamples: Java, Pearl, Python /are/ popular
> > but you can't generate exes either. The last time an exe-only
> > application was shipped by a major software company was in 1982 [1].)
>
> The "Pearl" you probably mean is written "Perl". There's a programming
> language which is written "Pearl" but you probably don't mean it
> (it's some kind of mostly event based realtime programming language
> thing, and there are IIRC compiled implementations where at least the
> code efficiency will probably be better than that of Perl).
I meant Perl. Thanks for the correction. My subconsciousness somehow
believed that this language should be spelled more complicated than it
actually is. ;-)
Matthias <··@spam.pls> writes:
> This is also my impression. A nice way of dealing with this class of
> questions would be a FAQ with an "Why is CL not popular?" item. This
> item would discuss
I think this (a) has been done to death already, and (b) is a very
good way of telling the prospective new user that Lispers are
defensive and feel themselves to be persecuted. So, I propose an
alternative -
Q: Why is CL not popular?
A: Because not very many people know about it yet.
and if the questioner looks disbelieving and starts muttering about
stuff he was forcefed in college, just roll your eyes and add "hell,
that was years ago".
> When I google for "LISP FAQ" I get a number of results. Is any FAQ
> considered especially relevant? Could one transfer that to a Wiki and
> work together in creating a useful and up-to-date FAQ? Has it already
> been done?
There's no canonical and up-to-date FAQ that I'm aware of. I created
a page on the ALU Wiki some time ago, to which all new contributions
(and some selective stealing from the old CLL FAQ, omitting for
example "where can I get PCL" or anything which refers CLTL2 as a
language reference) are welcome
-dan
Cameron MacKinnon <··········@clearspot.net> wrote in message news:<······················@golden.net>...
> At least once a month, someone asks how to deliver a "standalone"
> executable of a Lisp application. It's often his first post, and often
> his last.
>
> I suspect that a lot of these people have written small applications and
> want to share them on the net. They're likely to be some of the most
> effective proselytizers of Lisp, introducing compelling apps to others,
> some of whom will get the source and become lispers themselves. What do
> they hear?
> - You can't do that
> - You can only do it with the commercial lisps
> - You can do it, but the binary will be 11MB
Say I'd like to make a demo (http://www.scene.org/) in Common Lisp. I
haven't yet tried, but it poses an interesting problem to the
implementations i've seen, because to be allowed in a competition, a
demo must be:
- standalone
- below a certain size (64k for the intro category, 10M - 20M for a
demo), counting the media assets used (music, sound, textures,
models)
- reasonably fast
It's a rather niche market, but it's a shame, Common Lisp would seem
like an ideal environment to 'grow' a demo in. As a demo is an
artistical product, it would benefit from a shortened feedback loop
between the act of coding (poiesic process) and the act of
experiencing its results (esthesic process)
One very messy way to still use common lisp would be to use it for
prototyping, and somehow, from the same code, produce a c
representation of it for releasing, with just the proper dependencies.
From: Wade Humeniuk
Subject: Re: Executables: Why all the abuse?
Date:
Message-ID: <3JUTb.13$NG1.12@clgrps12>
n++k wrote:
>
> Say I'd like to make a demo (http://www.scene.org/) in Common Lisp. I
> haven't yet tried, but it poses an interesting problem to the
> implementations i've seen, because to be allowed in a competition, a
> demo must be:
> - standalone
> - below a certain size (64k for the intro category, 10M - 20M for a
> demo), counting the media assets used (music, sound, textures,
> models)
> - reasonably fast
I guess that leaves Java out. Common Lisp is a shoe in though, but
watch out for those media assets, they can suck a ton of space.
Wade
Wade Humeniuk <····································@telus.net> wrote in message news:<···············@clgrps12>...
> n++k wrote:
>
> >
> > Say I'd like to make a demo (http://www.scene.org/) in Common Lisp. I
> > haven't yet tried, but it poses an interesting problem to the
> > implementations i've seen, because to be allowed in a competition, a
> > demo must be:
> > - standalone
> > - below a certain size (64k for the intro category, 10M - 20M for a
> > demo), counting the media assets used (music, sound, textures,
> > models)
> > - reasonably fast
>
> I guess that leaves Java out. Common Lisp is a shoe in though, but
> watch out for those media assets, they can suck a ton of space.
>
> Wade
The languages of implementation are indeed typically C and C++ (with
some odd bit of asm for the 4k intro competitions, even though quite a
few manage to do them in C/C++)
Java has been occasionally allowed, when the jvm was part of the
operating system the competition targeted. Competitions are targeting
consumer operating systems as a general rule, so it means having to
cooperate with C libraries or with the few runtimes already present.
UPX (http://upx.sourceforge.net/) can help with big executable sizes,
but you have to start from a reasonable point
Cameron MacKinnon <··········@clearspot.net> writes:
> At least once a month, someone asks how to deliver a "standalone"
> executable of a Lisp application. It's often his first post, and often
> his last.
>
> I suspect that a lot of these people have written small applications and
> want to share them on the net. They're likely to be some of the most
> effective proselytizers of Lisp, introducing compelling apps to others,
> some of whom will get the source and become lispers themselves. What do
> they hear?
> - You can't do that
> - You can only do it with the commercial lisps
> - You can do it, but the binary will be 11MB
I've got two small CGI in Common-Lisp that are around 1MB:
$ du -shc /local/html/cgi/vacation*
12K /local/html/cgi/vacation
1017K /local/html/cgi/vacation-clisp
1.1M total
$ du -shc /local/html/cgi/en-ligne*
24K /local/html/cgi/en-ligne
897K /local/html/cgi/en-ligne-clisp
921K total
Granted, 99% of that is the clisp image and executable, they're small
programs, and 1MB for a Hello World may still seem big, but that's
quite acceptable, for a stand-alone program.
With clisp you can also concatenate all .fas files needed for your
program in load order and prefix it with a #!/bin/clisp line to get a
very small "executable".
$ ls -lh tar-backup
-rwxrwxr-x 1 pascal regular 74K 2004-01-17 21:11 tar-backup*
$ head tar-backup
#!/usr/local/bin/clisp -q -ansi -K full
(SYSTEM::VERSION '(20020129.))
#0Y UTF-8
#Y(#:|(DEFINE-PACKAGE COM.INFORMATIMAGO.CLISP.TAR-BACKUP
#16Y(00 00 00 00 00 00 00 00 00 01 DA DB 30 02 19 01)
...
The problem is that Unix (and MS-Windows) is C centric. We'd need to
have the distributions integrate a Common-Lisp runtime along with
glibc. Perhaps having a libcl.{so,dll} containing the run-time and
image? It would be probably easier to generate from a Common-Lisp
implemenation in C, such as gcl, ecl or clisp than from those that are
implemented in Common-Lisp such as cmucl, sbcl or openmcl.
$ ls -lh /lib/libc.so.6
-rwxr-xr-x 1 root root 1.5M 2003-03-27 21:39 /lib/libc.so.6*
A compressed clisp runtime and base image library is 1.8M.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Cameron MacKinnon <··········@clearspot.net> writes:
[ SNIP ]
> And those are just the serious answers. Some comedians try to convince
> the OP that he should be comparing the download size with all the C
> libraries that his users wouldn't have to download if the app was in C.
> Others suggest that what he really wants is a batch file, a lisp
> environment and a hassle, um, fasl file.
>
> Coders might not have that much web space or transfer available. End
> users might not want an 11MB download. Even though that's only two or
> three mp3 tracks, I think people expect a certain amount of
> functionality out of code that size, and a minor app is likely to be
> viewed as hopelessly bloated.
If we look at typical sizes of what people (seemingly) are happy to
download, "for checking things out", look at the size of current PC
game demos. Admittedly, this is not a "small example", but that should
(ideally) be downloadable either as "lisp + demo" and "demo", in
program bundles (zip files, tar.gz or whatever is convenient), with
either a "install" or "load" script and/or as a "runnable compressed
archive" (probably only relevant for Windows) that unpack the relevant
files into the relevant directories and works "with a single click".
Hexen II - 11.6 MB
Quake III Arena - 46 MB
These are (probably) self-extracting archives inside a .EXE file
prepared with InstallShield.
//Ingvar
--
(defun m (f)
(let ((db (make-hash-table :test #'equal)))
#'(lambda (&rest a)
(or (gethash a db) (setf (gethash a db) (apply f a))))))
Cameron MacKinnon <··········@clearspot.net> writes:
> Coders might not have that much web space or transfer available. End
You might want to check SourceForge.net, Savannah.org and
Common-Lisp.net.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Cameron MacKinnon wrote:
> At least once a month, someone asks how to deliver a "standalone"
> executable of a Lisp application. It's often his first post, and often
> his last.
(...SNIP...)
> Maybe it would be instructive to look at how other languages handled
> this chicken-and-egg problem:
>
> Perl started small (even Perl 4 was only a few hundred k) and
> ingratiated itself with the sysadmin crowd. It didn't bulk up until it
> was in the indispensable category.
>
(...SNIP..)
PERL indispensable? Apparently, the FreeBSD crowd didn't think so...
But I inderstand what you mean...
> Java, Macromedia Flash, Realaudio and other applets benefit from
> Netscape's plugin paradigm - if the end user doesn't have the plugin,
> the content creator can direct the browser to get it from the plugin
> creator's website. The end user only downloads it once, the content
> creator doesn't pay for the bandwidth, and the process is sometimes
> painless.
>
From what I've read on XUL, it seems to be /theoretically/ possible to
ship a Common Lisp plug-in, provided you use something really portable
like CLISP, which is smaller than the JVM. It might even be possible
using XUL as some sort of GUI. But the problem is: do you want to work
through all that XUL/JavaScript/C++ framework?
Regs,
Henry