Christophe Rhodes <cs...@cam.ac.uk> writes: > > If you don't like Stalin, have an option to do less optimization. But > > it's not optional to produce small standalone native a.out files.
> On the assumption that you're not just trolling... why?
Why would you want anything else? Smaller is better, because you don't waste space. On a real system you will have hundreds or thousands of independent processes in execution, so it would be bad to have them burn more memory than necessary. On a real system you want to take advantage of the system's basic mechanisms, so that means producing native format executables.
For example, suppose you want to profile your program. You've got a MIPS or Alpha so you say something like, "pixie a.out" and then run "a.out.pixie" and you get your results. Can't do that with some random byte code, or non-system binary.
> And just how standalone is a "native a.out" file?
I don't like shared libraries, but I guess they're a fact of life these days.
> How robust is a normal unix application?
Look at, say, qmail. Totally bullet proof.
> How easy is in-place maintenance?
Very. Just load a new rpm when the time comes.
> How long a downtime does making major changes to the > system entail?
Mere moments. You won't even have time to fire up emacs. :)
> And if your application uses 999MB of RAM, I'd guess > that the cost of an extra 512MB stick is lost in the noise,
Sure, if we had free slots, but when the current system (1024 processors with 1GB each) was purchased, we couldn't fit more than that. If we could, we'd run bigger jobs, and still not have any RAM to waste.
> even assuming that this runtime isn't being shared by any other process on > the system.
No, that would still be no excuse.
> Your attitude thus far seems to be that of someone who has only ever > seen hammers; then, given a Swiss Army knife, expresses frustration > when banging nails in seems to be harder. There are other ways of > assembling useful objects...
On the contrary. I've used and enjoyed a variety of systems. But I know a spork when I see it. (And perl is the canonical swiss army knife.)
* Scott Schwartz wrote: > I don't want a 128MB runtime system in my 128 line program. I > definately don't want a 128MB runtime system in my application that > uses 999MB of RAM.
I think you are confusing Lisp with that notoriously unpopular language, Java. Or maybe with some figment of your imagination, who can tell?
* Scott Schwartz | Smaller is better, because you don't waste space. On a real system you | will have hundreds or thousands of independent processes in execution, so | it would be bad to have them burn more memory than necessary.
This must be why the Linux kernels I build warn me that they too big for the floppy disk, even when they are compressed.
| Look at, say, qmail. Totally bullet proof.
*laugh*
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
* Scott Schwartz wrote: > On a real system you want to take advantage of the system's basic > mechanisms, so that means producing native format executables.
* Andre van Meulebrouck wrote:
> For instance, .Net isn't language centric; how about targeting .Net > with CL?
That's a native format executable. Made with Lisp. Usable from the Unix command line, starup time of a few hundredths of a second. It's 3MB because it doesn't use shared libraries other than libc (which Scott Schwartz abhors, so he'll be pleased it doesn't) and it uses CORBA.)
Erik Naggum <e...@naggum.no> writes: > * Scott Schwartz > | Smaller is better, because you don't waste space. On a real system you > | will have hundreds or thousands of independent processes in execution, so > | it would be bad to have them burn more memory than necessary.
> This must be why the Linux kernels I build warn me that they too big for > the floppy disk, even when they are compressed.
Sure, 1.44 MB is a lot. Linux at least has the excuse of supporting lots of devices. On a very vanilla system a kernel of a few hundred KB is easily managed.
How big did you say your lisp runtime was?
> | Look at, say, qmail. Totally bullet proof.
> *laugh*
If you can reimplement qmail in lisp, and do as well, I'd be amazed and delighted.
> * In message <8glm41409w....@galapagos.cse.psu.edu> > * On the subject of "Re: Lisp Machines considered Inferior" > * Sent on 10 Nov 2002 15:50:35 -0500 > * Honorable Scott Schwartz <"schwartz+@usenet "@bio.cse.psu.edu> writes:
> it's not optional to produce small standalone native a.out files.
this has been rehashed many times here - suffice it to say that the word "standalone" is largely meaningless (ever since libc.so appeared on the scene or even before that).
> I just filed a bug report for CLISP (for the second time). Nothing > complicated: if a non-interactive program gets a certain kind of > error, it pops into an interactive break loop, writing garbage to > standard output and consuming standard input and not quitting when you > hit ctrl-C. That's anti-unix engineering to an unthinkable degree.
how many programs would behave well when given /dev/zero as STDIN? (that's what you used as the standard input - /dev/zero, _not_ /dev/null) The small bug you did uncover has been already fixed.
* Scott Schwartz | Sure, 1.44 MB is a lot. Linux at least has the excuse of supporting lots | of devices. On a very vanilla system a kernel of a few hundred KB is | easily managed.
When built, /usr/src/linux is 3,569,040 bytes and /boot/vmlinuz is 1,303,242 bytes. I have no idea why it still complains about the floppy size, it should have fit. However, my machine now has 1,048,576K of memory, but systemt status reports say only 1,032,908K are available. As far as I can see, that is 15,668K of memory in the kernel alone.
| How big did you say your lisp runtime was?
The full Common Lisp environment with a lot of stuff pre-loaded consumes all of 8,576K of memory when it starts up. That is half the Linux kernel.
| If you can reimplement qmail in lisp, and do as well, I'd be amazed and | delighted.
WTF would I reimplement such a braindamaged design for?
Dude, your whole weltanschauung needs a serious readjustment. You have walked too far in the one direction you have chosen to see that any other direction you could have chosen would have brought you to places with no loss of convenience or quality of life, even if you had not walked as far, but from where you are now to any other such place is probably farther than it would have been from the common starting point. This is how people get trapped in the Valley of Death with Microsoft, too, for the farther they walk into that valley, the taller the mountains they would have to scale to get out of it. I always saw Unix as the Great Plains.
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
> However, my machine now has 1,048,576K of memory, but systemt status > reports say only 1,032,908K are available. As far as I can see, > that is 15,668K of memory in the kernel alone.
That's nothing. My kernel uses nearly half my memory for this thing top calls "cache". It's an outrage.
* "Johannes Grødem" <joh...@ifi.uio.no> | That's nothing. My kernel uses nearly half my memory for this thing | top calls "cache". It's an outrage.
Yeah, tell me about it. I upgraded from 524,288K to 1,048,576K because all the memory was in use, but after I upgraded, all the memory is still in use. And I am quite sure this is because of The Great Common Lisp Conspiracy to Consume All Available Memory. I think Common Lisp in space failed because there are far less atoms in space than here on earth, so when it started to consume atoms to use for memory, the Universe was in danger of being eaten up by it and the project just had to be aborted.
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
Sam Steingold <s...@gnu.org> writes: > how many programs would behave well when given /dev/zero as STDIN?
All correct ones. The one I sent you didn't even read from stdin, and there was no reason for CLISP to do so.
In response to a deliberately induced stack overflow in a non-interactive program (in other words, a minimal example constructed to demonstrate a large problem), clisp jumped into an interactive break loop and started talking to stdin/stdout. The only correct behaviour would have been to print a message to stderr and to exit, because there was no terminal, no user, no possibility for interaction. If stdin had been connected to a network server, this would have been a security problem of the highest order. The fact that the break loop was boggled by ascii NUL characters is wierd, but secondary, given that it had no right to be looking at them in the first place.
> (that's what you used as the standard input - /dev/zero, _not_ /dev/null)
Of course. It was a convenient source of input, to drive home the point that CLISP is reading stdin, when it stdin is connected to arbitrary user-supplied input.
> The small bug you did uncover has been already fixed.
Not by the patch you sent me. CLISP still writes garbage to standard output instead of standard error. It still assumes that debug_io is open and usable. It still assumes that the runtime system can read from standard-input whenever it wants to.
Christopher Browne <cbbro...@acm.org> writes: > If I need /two/ editors in order to: > a) wrap the Lisp environment, and > b) read news and mail,
Hmm, when I used to use GNU Emacs for CL editing, I usually started several separate emacs images anyway, so the problem is mainly one of different interfaces, right?
The only two real problems I have with the Lispworks editor is:
- I hate that c-x 2 brings up a second window It's a bit distracting - that I have to switch to my GNU Emacs window to do CVS interaction on my lisp files.
I can live with these small problems, since the tight integration with the development environment and its debugging tools is of really great value to me. -- (espen)
Erik Naggum <e...@naggum.no> writes: > than it would have been from the common starting point. This is how > people get trapped in the Valley of Death with Microsoft, too, for the > farther they walk into that valley, the taller the mountains they would > have to scale to get out of it.
No, it's because their brains are washed by the local priests until they actually believe that the world ends at thouse mountain ridges. -- (espen)
>>>>> "Paolo" == Paolo Amoroso <amor...@mclink.it> writes:
Paolo> By the way, how many people attended ILC 2002?
I have heard the number ~120 including the 40-50 speakers.
It was my first lisp conference so I do not have anything to compare with, but being there certainly gave me a warm fuzzy feeling, testifying to the continued viability of LISP.
------------------------+-------------------------------------------------- --- Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J Phone: +45 8938 5244 | email: christian.lynb...@ted.ericsson.se Fax: +45 8938 5101 | web: www.ericsson.com ------------------------+-------------------------------------------------- --- Hit the philistines three times over the head with the Elisp reference manual. - peto...@hal.com (Michael A. Petonic)
> >>>>> On Sat, 09 Nov 2002 16:49:31 GMT, Will Hartung ("Will") writes: > Will> However, for me, when I tried to switch from GNU Emacs to > Will> XEmacs on Windows, I simply gave up. XEmacs bindings are Different.
> I've been using XEmacs and GNU Emacs interchangably for > the last few weeks, and didn't notice anything different > (except that it has fonts).
beginning-of-buffer and end-of-buffer behave subtly different.
In GNU Emacs, they set point, in XEmacs they don't.
This has bitten me multiple times.
//Ingvar -- When in douFNORD! This signature has been hi-jacked by Fnord Information systems, to fnordprovide you with unfnordlimited information.
>>>>> On 11 Nov 2002 17:56:39 +0000, Ingvar Mattsson ("Ingvar") writes:
Ingvar> cst...@dtpq.com (Christopher C. Stacy) writes: >> >>>>> On Sat, 09 Nov 2002 16:49:31 GMT, Will Hartung ("Will") writes: Will> However, for me, when I tried to switch from GNU Emacs to Will> XEmacs on Windows, I simply gave up. XEmacs bindings are Different. >> >> I've been using XEmacs and GNU Emacs interchangably for >> the last few weeks, and didn't notice anything different >> (except that it has fonts).
Ingvar> beginning-of-buffer and end-of-buffer behave subtly different.
Ingvar> In GNU Emacs, they set point, in XEmacs they don't.
Ingvar> This has bitten me multiple times.
"Point" is where the cursor is, so of course they move the point. You must have meant to say "Mark". But you are incorrect anyway: those commands do set the mark. I tried it just now.
> >>>>> On 11 Nov 2002 17:56:39 +0000, Ingvar Mattsson ("Ingvar") writes:
> Ingvar> cst...@dtpq.com (Christopher C. Stacy) writes: > >> >>>>> On Sat, 09 Nov 2002 16:49:31 GMT, Will Hartung ("Will") writes: > Will> However, for me, when I tried to switch from GNU Emacs to > Will> XEmacs on Windows, I simply gave up. XEmacs bindings are Different.
> >> I've been using XEmacs and GNU Emacs interchangably for > >> the last few weeks, and didn't notice anything different > >> (except that it has fonts).
> Ingvar> beginning-of-buffer and end-of-buffer behave subtly different.
> Ingvar> In GNU Emacs, they set point, in XEmacs they don't.
> Ingvar> This has bitten me multiple times.
> "Point" is where the cursor is, so of course they move the point. > You must have meant to say "Mark". But you are incorrect anyway: > those commands do set the mark. I tried it just now.
Hrm, yes, I meant "sets mark". I was informed by an XEmacs user that said behaviour was still present in whatever version he was using as of "a few weeks ago".
>>>>> On 12 Nov 2002 14:50:24 +0000, Ingvar Mattsson ("Ingvar") writes:
Ingvar> cst...@dtpq.com (Christopher C. Stacy) writes: >> >>>>> On 11 Nov 2002 17:56:39 +0000, Ingvar Mattsson ("Ingvar") writes: >> Ingvar> cst...@dtpq.com (Christopher C. Stacy) writes: >> >> >>>>> On Sat, 09 Nov 2002 16:49:31 GMT, Will Hartung ("Will") writes: Will> However, for me, when I tried to switch from GNU Emacs to Will> XEmacs on Windows, I simply gave up. XEmacs bindings are Different. >> >> >> >> I've been using XEmacs and GNU Emacs interchangably for >> >> the last few weeks, and didn't notice anything different >> >> (except that it has fonts). >> Ingvar> beginning-of-buffer and end-of-buffer behave subtly different. >> Ingvar> In GNU Emacs, they set point, in XEmacs they don't. >> Ingvar> This has bitten me multiple times. >> >> "Point" is where the cursor is, so of course they move the point. >> You must have meant to say "Mark". But you are incorrect anyway: >> those commands do set the mark. I tried it just now.
Ingvar> Hrm, yes, I meant "sets mark". I was informed by an XEmacs user that Ingvar> said behaviour was still present in whatever version he was using as Ingvar> of "a few weeks ago".
>> I'm using XEmacs 21.4.10, and GNU Emacs 21.2.1.
>* Scott Schwartz wrote: >> Siskind's Stalin compiler is The Right Thing. Too bad it's such a >> notable rarity. >whole-program analysis is a nice way of ensuring your compile times >compete poorly even with typical C++ compilers. The right thing, if >your time is free and you don't like things like runtime patching, >maybe.
In fact, the whole-program optimizing compiler SmallEiffel is rather fast, compilation times are dominated by the gcc run times (SmallEiffel targets C). Even together, compiling an Eiffel program with SmallEiffel plus gcc (in the C mode) is faster than compiling some C++ program which heavily uses templates and such with gcc (in C++ mode).
That's crazy isn't it. Although, as a victim of long gcc C++ compile times, it's interesting.
It almost sounds like if you created a C++ -> C converter for gcc, it would run faster than the native C++ compilation.
If I remember correctly, the first C++ compilers used to work like that.
-- Justin Johnson
"Hannah Schroeter" <han...@schlund.de> wrote in message
news:aqu6c4$b36$4@c3po.schlund.de... | Hello! | | Tim Bradshaw <t...@cley.com> wrote: | >* Scott Schwartz wrote: | | >> Siskind's Stalin compiler is The Right Thing. Too bad it's such a | >> notable rarity. | | >whole-program analysis is a nice way of ensuring your compile times | >compete poorly even with typical C++ compilers. The right thing, if | >your time is free and you don't like things like runtime patching, | >maybe. | | In fact, the whole-program optimizing compiler SmallEiffel is rather | fast, compilation times are dominated by the gcc run times (SmallEiffel | targets C). Even together, compiling an Eiffel program with SmallEiffel | plus gcc (in the C mode) is faster than compiling some C++ program | which heavily uses templates and such with gcc (in C++ mode). | | Kind regards, | | Hannah.
In article <1037270823.1563...@iapetus.uk.clara.net>, "Justin Johnson"
<just...@mobiusent.com> wrote: >It almost sounds like if you created a C++ -> C converter for gcc, it would >run faster than the native C++ compilation.
>If I remember correctly, the first C++ compilers used to work like that.
* Ingvar Mattsson wrote: > Hrm, yes, I meant "sets mark". I was informed by an XEmacs user that > said behaviour was still present in whatever version he was using as > of "a few weeks ago".
I bet that the difference is that while both versions set the mark, xemacs does not make the region active, so many commands which work on the region will get an error. The change may be that the default value of zmacs-regions has changed from nil to t.
