Bijan Parsia <bpar...@email.unc.edu> writes: > On Sun, 16 Sep 2001, Erik Naggum wrote: > [snip] > > in Common Lisp. This means (their) Common Lisp is never used to build > > the kinds of toys that programmers need to build trust in their tools. > > Being able to dump a toy executable like you ask for is therefore highly > > desirable, but it is a completely useless exercise for anything other > > than such building of trust in your tools. You would never actually want > > to deploy an "application" in C, C++, or Java that did anything similarly > > trivial to the hello, world programs, but the model for building a simple > > program is similar in certain respects to building a large program, and > > that is why the hello, world program is useful in their context. > [snip]
> Y'know, I've taken this line for years, but reading this made me think of > CGIs. It seems to me that loads of actually deployed CGIs aren't *that* > much more complex than the hello, world program. For some reason this > never struck me as plausible when people brought up "trivial" shell utils.
> (I think for hello, world *per se* your analysis is spot on and I doubt > that people asking about it are asking about simple cgis.)
> It might be a worthwhile addition to a FAQ to have examples of very simple > CGIs, at least for raising the general trust in Common Lisp as a tool.
Ah, but CGIs are a different beast. If you're using CL to write CGI scripts, you presumably have more than one little hello world type script. You probably have a whole bunch. So you install the CL system just as you would perl, and then the cost to deliver each CGI script is the cost of a .lisp or .fasl file.
Aleksandr Skobelev <2...@mail.ru> writes: > Erik Naggum <e...@naggum.net> wrote:
> > So use C++, then. I completely fail to see the problem. If you want to > > use a different language, you actually have to buy the whole package > > deal, not just the bits and pieces you like and then keep some other > > language -- if you want that, build yourself a CL++ environment.
> So do I. There is no any problem. But I don't feel that I have to buy > something to use different language. At least at the beginning stage.
He was using "buy" in a metaphorical sense. If you want to use Common Lisp, you should try to do things the CL way and judge things using a CL value system. Then, once you understand why things are done the way they are, *then* you can try to improve on it. There are good reasons that CL does the things it does; if you understand those reasons, you may be able to improve it; if you don't understand why things are done as they are, you will be doomed to making a mess. And you'll end up fighting against the CL system and trying to recreate C++.
> I don't argee. Computers programs are intendent to be using but not > debugging by other people. So if your programm will be able to run only in > CL enviroment with all its really nice development features which are not > required by program's semantics, then you just shift off a cost of these > features on an user. Sometimes such features have to be in program, > sometimes have not. I like freedom to choose use or not such features in > a distributed program.
You can get rid of some things (IDE, etc.) quite easily. I completely disagree with the philosophy of shipping applications with no debugging ability. When something goes wrong, it sucks. Unless I *absolutely* need the speed and space savings, I leave a minimal debugging environment in all my C++ programs. CL gets that by default.
"Thomas F. Burdick" <t...@apocalypse.OCF.Berkeley.EDU> wrote
> Ah, but CGIs are a different beast. If you're using CL to write CGI > scripts, you presumably have more than one little hello world type > script. You probably have a whole bunch. So you install the CL > system just as you would perl, and then the cost to deliver each CGI > script is the cost of a .lisp or .fasl file.
I know somebody that makes CGI like scripts in Lisp with mod_lisp + Apache. Basically he processes URI like http://www.server.com/lisp/page1.lisp by loading the page.lisp file (or .fasl) and calling a function in it to process the request. That way the CGI scripts are very small and the starting time is very short as the Lisp process is already loaded in memory and running.
In article <3209668982240...@naggum.net> you wrote: > * Aleksandr Skobelev <2...@mail.ru> >> You are kidding. Need I explain you meaning of "standalone executable" >> term in my messages?
> Yes. Because if you compare a hello, world program that uses massively > optimized operating system facilities and shared libraries and all sorts > of other things that work very well to reduce the size of "executables", > you are looking at the wrong end of the stick. Look at what that small > executable is attached to: A huge set of libraries and support functions > from the operating system.
Yes. I've just wanted to get an estimation for minimal size of program that had been generated by commercail CL realization. I think I've got what I wanted.
> I mean, I could write a hello, world program in MACRO-10 for TOPS-10 that > consisted of three machine instructions and the string literal. That was > done at a time when small _actual_ executables were worth real money, but > these days, small executables are not small in memory imprint, any longer.
> Therefore, the _concept_ "standalone executable" is no longer valid.
An any concept is not valid in absolute sense. It is only valid in context of current discussion after all sides who take part in that discussion came to agree about the meaning of that concept and until the end of discussion.
And if your 'yes' concerns to need of explaining term "standalone executable" in the context of my messages, here it is.
I have used concept "standalone executable" as a well known in this newsgroup for signing an file which contains program in instructions of CPU, has a format of executable file for target OS, and can be running as a process by this OS. That concept has also included a requirement of independency (i.e. process can be running without) of any Lisp system or special Lisp's libraries (i. e. libraries that contains code providing functionality of Lisp system, because it is implied that all such code had been already statically linked in executable body). Such executable could, of course, be dynamically linked with libraries which are the part of OS (this libraies are always exist and it is just stupid to pay attention to them) and dynamically or statically linked with libraries which provides semantic program's functionality.
>> Computers programs are intendent to be using but not debugging by other >> people.
> This is so broad as to be utterly false by the very nature of the claim. > Please limit your statements to the assumptions that support them, then > always evaluate the assumptions for validity for broader claims. > Otherwise, you will always be stuck in using your observations from a > very limited context in a much broader context, and that never leads to > anything good.
OK. :) <IN-MY-OPINION> Computer's programs are intendent to be used but not debugged by users. (If it wasn't so then probaly they were called 'debuggers') :) For they use programs for solving their own problems but not for solving problems of programmers who have developed these programs. Debugging of broken programs is a task for programmers but not for users. Programmers only can ask users to help them but they can not force them to do it. </IN-MY-OPINION>
>> So if your programm will be able to run only in CL enviroment with all >> its really nice development features which are not required by program's >> semantics, then you just shift off a cost of these features on an user.
> How did you arrive at this strange conclusion?
OK. May be I have told that too sharp or incorrect. I've meant to say that user should paid for things he/she not needed.
<IN-MY-OPINION> There are situations when the user has to pay for presence of such features. This is an indirect payment. Because such features always requires additional resources which have to be paid. Such payment can be more or less. It is obviously chip when we talking about place on hard drives. But if program is intendent to be used on computers without HDD but with flush memory? Downloading files over Internet is also costs somewhat, and it is not always chip. </IN-MY-OPINION>
>> Sometimes such features have to be in program, sometimes have not. I >> like freedom to choose use or not such features in a distributed program.
> Sometimes, we do not get the freedoms we want, but instead may other ones > we did not know we wanted because we never asked for them.
No any objections.
But it is sounds like that there is something that can save the my life and I know nothing about it. Well, if you tell me about it, I might be much obliged to you the rest of all my life. :)
> You are way > too quick for my taste to dismiss what you do not know, yet. I find this > very annoying, in fact, and suspect that you will not want to invest the > time it takes to learn a new language. I suspect you will only learn C++ > with a new syntax if you learn Common Lisp in your present state of mind.
Excuse me, but, I think, you just give your dreams out to be my decisions. I didn't dismiss anything, especially, for your taste. :)
As far as I remember in this thread I only expressed my opinion, that it would be good for me and, probably, for Lisp, if some feature existed. And I've tried to explain my point, which, I agreed, might have been wrong. But I never wrote that CL have to be dropped because of absence of that or any other feature.
You, of course, have an absolute freedom to suspect anything you want. And your suspects can, of course, be very reasonable and come true. But could I, with my deep respect to you, ask you do not claim any of such suspections about me, please. Just because I wouldn't like to be an subject for discussion anywhere.
> _Please_ look at what you get, not at what you want. Somehow, you _did_ > do that when you came to C++ and found "small executable" a valid concern. > You have to be equall open-minded with _every_ language you approach, not > just the first.
I've just tried to understand what I get and how it is correlated with what I want. Where I can use it and where I can't.
Thomas F. Burdick <t...@apocalypse.ocf.berkeley.edu> wrote:
> He was using "buy" in a metaphorical sense. If you want to use Common > Lisp, you should try to do things the CL way and judge things using a > CL value system. Then, once you understand why things are done the > way they are, *then* you can try to improve on it. There are good > reasons that CL does the things it does; if you understand those > reasons, you may be able to improve it; if you don't understand why
This is what I trying to do.
> things are done as they are, you will be doomed to making a mess. And > you'll end up fighting against the CL system and trying to recreate C++.
Hmm... Or you don't read this thread from the begining but only Erik's message, or I have been explaning myself very bad. :( There were not any fighting against the CL. If not, of course, you consider that having own opinion about features which one'd like to have in CL is a fightning against the CL. :)
Aleksandr Skobelev <2...@mail.ru> writes: > Thomas F. Burdick <t...@apocalypse.ocf.berkeley.edu> wrote:
> > He was using "buy" in a metaphorical sense. If you want to use Common > > Lisp, you should try to do things the CL way and judge things using a > > CL value system. Then, once you understand why things are done the > > way they are, *then* you can try to improve on it. There are good > > reasons that CL does the things it does; if you understand those > > reasons, you may be able to improve it; if you don't understand why
> This is what I trying to do.
But it looks like your value system is heavily influenced by C++. At this point the choice is yours: either you drop your preconceptions and learn CL in its own terms or you try to cast CL into your C++ way of thinking and don't learn CL (but a CL++ as it has been called recently).
> There were not any fighting against the CL. If not, of course, you > consider that having own opinion about features which one'd like to > have in CL is a fightning against the CL. :)
You may of course think that it's just your opinion. But you have been brainwashed by C++ and might think that C++ is the one and only right way to do things. CL is a completely different world. C++ value system just doesn't make sense here.
Do you think my being faster, stronger has anything to do with my muscles in this place? Do you believe that's air you are breathing now? If you can free your mind, the body will follow. -- Morpheus, The Matrix
I just want to help you understand where the problem is.
-- Janis Dzerins
If million people say a stupid thing it's still a stupid thing.
> Posting the my first message, which started this thread I only wished to > get some information about size of binaries generated commercial Lisp > realisations. I've only got information about LWW. In all other messages > I've just explained why I had asked about size and why I had thought that > is was better if one was smaller. :)
> I want to say that I tried to explain my position as well as my level of > English is allowed me. Unfortunately it doesn't allow me very much. :) > Sorry if it misleads or annoys somebody.
Don't worry, I think you explained your position just fine. If people reacted a bit more, um.. emphatically.. than you might have expected it is just because this is a sore spot in the lisp community. Don't take it personally. This "problem" about lisp, that is in fact no problem at all, is frequently used as one of a few common but irrational excuses to dismiss the entire language out of hand.
> In article <3209668982240...@naggum.net> you wrote: > > * Aleksandr Skobelev <2...@mail.ru>
> >> Sometimes such features have to be in program, sometimes have not. I > >> like freedom to choose use or not such features in a distributed program.
> > Sometimes, we do not get the freedoms we want, but instead may other ones > > we did not know we wanted because we never asked for them.
> No any objections.
> But it is sounds like that there is something that can save the my life > and I know nothing about it. Well, if you tell me about it, I might be > much obliged to you the rest of all my life. :)
(Assuming a good natured joke in the line "something that can save my life" - ie I don't think you really believe a small executable is so important that you won't sacrifice it except to save your life)
No, you can not get a very small "Hello World" program in Common Lisp without a lot of the Lisp system included. This is a mark on the column of bad points. But what do you get in return?
* A *much* faster development cycle * A program that can be modified/enhanced/debugged while it is still running * The ability to use symbols as data * A macro system so powerful you can define your own programming language on top of CL * An object oriented development platform that allows you to redefine your classes at runtime, existing objects and all * A language that can easily produce, compile and execute it's own source code, again at runtime
This is just a start of a list of Common Lisp's good points, perhaps others will chime in with others. But I think it is quite enough to outweigh any disadvantage of a small executable for all but a very few and very specific situations.
I think the preferred syntax is (with-opinion (:mine t) ...)
> Computer's programs are intendent to be used but not debugged by users. > (If it wasn't so then probaly they were called 'debuggers') :) For they > use programs for solving their own problems but not for solving problems > of programmers who have developed these programs. Debugging of broken > programs is a task for programmers but not for users. Programmers only can > ask users to help them but they can not force them to do it.
Well, it's not just debugging, is it. Imagine a long-running mission-critical program, in which a bug is found. Now the traditional approach to this is stop the application, upgrade it, convert all the data to some new format, and restart. Maybe this takes you a few hours.
Now imagine a system which lets you load into it, while it's running, a patch file. The patch file contains the bug fix, but, even better, it also contains mechanisms that cause all the program's data to be converted on-the-fly (and almost certainly on-demand) tot he new format. There is no downtime. I think it's clear that this sort of thing would be nice to have - even C++ people are groping towards it though, last I read, they hadn't worked out the on-the-fly conversion. stuff yet.
CL systems provide this stuff as near-standard functionality (there are caveats but they're not a problem in practice). And the way they do this is by keeping various meta-information about stuff, so that there is enough information in the running system to do this magic. I'm not an implementor, but I bet you that a lot of this data is *the same* as the kind of thing you need for debugging.
Does this mean that minimal CL systems are slightly bigger than minimal C ones? Yes. Does it mean they aren't suitable for embedded controllers in washing machines? Probably it does (though they seem to work OK in embedded controllers in spacecraft). But not all systems are minimal, and having this kind of stuff can save you a lot of money in systems that aren't.
Aleksandr Skobelev <2...@mail.ru> wrote: > <IN-MY-OPINION> > Computer's programs are intendent to be used but not debugged by users. > (If it wasn't so then probaly they were called 'debuggers') :) For they > use programs for solving their own problems but not for solving problems > of programmers who have developed these programs. Debugging of broken > programs is a task for programmers but not for users. Programmers only can > ask users to help them but they can not force them to do it.
Have you ever tried to deal with bug reports for "standalone" programs in real life? (this is not a rethorical question).
User: "Gee, this program crashes sometimes. Here's a 40M core dump. No, sorry, my executable is stripped".
Even OS kernels have built-in debugging facilities, either a fully blown interactive debugger or at least enough of it to print a symbolic stack trace on panic. And (with my kernel hacker hat on) to say that it's very useful does not even start to describe just how much I appreciate it's there in the kernel.
And if you want to go even more down to the iron, consider that e.g. OpenFirmware comes with debugger as well. Re boot loaders ;) - this debugger helped me a great deal recently to debug a boot loader and kernel bootstrapping code (before kernel debugger is initialized).
> But if program is intendent to be used on computers without HDD but > with flush memory?
Yes, OpenFirmware resides in flash memory ;).
This low level stuff has nothing to do with CL directly, but I just want to show you that even at the bare iron level of "standalone-ness" people actually deploy code in production (even in the flash!) with debugging facilities built-in.
> As far as I remember in this thread I only expressed my opinion, > that it would be good for me and, probably, for Lisp, if some > feature existed. And I've tried to explain my point, which, I > agreed, might have been wrong.
And to quote Erik's reply:
> > Please limit your statements to the assumptions that support > > them, then always evaluate the assumptions for validity for > > broader claims.
IOW: why do you think it would be good for you (and for Lisp)?
Do the analysis of the problem you have at hands, calculate the costs, consider trade-offs and make an informed decision.
And as far as "don't pay for things you don't use" is concerned... IMO, C++, the language as whole paid a *huge* price to let its users think they do not pay for things they don't use. So when calculating your trade-offs you should take that price into account too.
> Thank you for reply. > As far as I understand they are statically linked binaries in contrast to > Basic's dynamically linked (to VB dlls) ones?
I would assume that you are correct. There is no CAPI DLL that one can link to, which I assume VB has DLL libraries for equivalent functionality. The comparison I am making is to other running log programs, written in VB, that have the approximate functionality that my program has. They are large with a 8 to 12MB self-installing exe.
I used to be concerned with the size of executables. It hardly crosses my mind anymore. There seems to be a minimum size that any delivered LWW exe can be (~2MB). This includes code essential to basic CL functionality (no compiler, loader, CAPI, multi-processing). Of course this could be greatly reduced but it would take vendor work, OR, some bright person out there could write their own compiler to generate very small exes for small programs like that. Totally doable (as evidenced by the post about stalin-0.8). The compiler would have to analyze the code, decide what functionality is needed, decide if garbage collection is needed, and emit an executable.
Though there is a minimum size to a LWW executable, I can say that for additional functionality that is added (for a more complex app) the executable size does not increase any more quickly compared to other languages.
> This low level stuff has nothing to do with CL directly, but I just > want to show you that even at the bare iron level of "standalone-ness" > people actually deploy code in production (even in the flash!) with > debugging facilities built-in.
It's always misleading to give examples from spacecraft because they're so weird, but I remember a story about some mars spacecraft (quite recent I think, and one of the ones that didn't crash), which suffered from system crashes due to <something>. The thing ran some embedded OS - perhaps OS9? - and the people, being sensible, had left all the debugging tools there. The description I read was a bit vague but it sounded suspiciously as if they essentially logged in to the spacecraft and edited parameters interactively to fix the problem. I thought this was really cool. What was sad was that they (the NASA people) got attacked for launching the thing with bugs, when in fact they'd done everything they needed to to make sure they could fix the bugs on the fly, while not missing the launch window due to testing).
Anyone whose run Unix machines has also, as you say, been very thankful for the interactive debugger that most of them have under the kernel: if only to be able to do something which causes the system to sync the disks before rebooting this is worth it (of course systems don't typically need to sync disks nowadays, but the point is still good I think).
Bijan Parsia <bpar...@email.unc.edu> writes: > Y'know, I've taken this line for years, but reading this made me think of > CGIs. It seems to me that loads of actually deployed CGIs aren't *that* > much more complex than the hello, world program. For some reason this > never struck me as plausible when people brought up "trivial" shell utils.
A lot of CGIs have been written in Perl. When people test this, CLISP starts up faster than Perl and is for a lot of things faster. So, there's no reason CLISP couldn't be used for CGIs.
-- Lieven Marchand <m...@wyrd.be> She says, "Honey, you're a Bastard of great proportion." He says, "Darling, I plead guilty to that sin." Cowboy Junkies -- A few simple words
Aleksandr Skobelev <2...@mail.ru> writes: > In article <3209668982240...@naggum.net> you wrote: > > * Aleksandr Skobelev <2...@mail.ru> > >> You are kidding. Need I explain you meaning of "standalone executable" > >> term in my messages?
> > Yes. Because if you compare a hello, world program that uses massively > > optimized operating system facilities and shared libraries and all sorts > > of other things that work very well to reduce the size of "executables", > > you are looking at the wrong end of the stick. Look at what that small > > executable is attached to: A huge set of libraries and support functions > > from the operating system.
> Yes. I've just wanted to get an estimation for minimal size of program that > had been generated by commercail CL realization. > I think I've got what > I wanted.
I don't think that's true, because not all of us have weighed in yet. You may have gotten at least one answer, but before we talk about how low we can go with Common Lisp, I want to know if you understand where your own bar is. I don't think you do yet. If you do, you certainly haven't communicated it to us to my satisfaction.
> > I mean, I could write a hello, world program in MACRO-10 for TOPS-10 that > > consisted of three machine instructions and the string literal. That was > > done at a time when small _actual_ executables were worth real money, but > > these days, small executables are not small in memory imprint, any longer.
> > Therefore, the _concept_ "standalone executable" is no longer valid.
> An any concept is not valid in absolute sense. It is only valid in > context of current discussion after all sides who take part in that > discussion came to agree about the meaning of that concept and until the > end of discussion.
> And if your 'yes' concerns to need of explaining term "standalone > executable" in the context of my messages, here it is.
> I have used concept "standalone executable" as a well known in this > newsgroup for signing an file which contains program in instructions of > CPU, has a format of executable file for target OS, and can be running as > a process by this OS. That concept has also included a requirement of > independency (i.e. process can be running without) of any Lisp system or > special Lisp's libraries (i. e. libraries that contains code providing > functionality of Lisp system, because it is implied that all such code had > been already statically linked in executable body). Such executable could, > of course, be dynamically linked with libraries which are the part of OS > (this libraies are always exist and it is just stupid to pay attention to > them) and dynamically or statically linked with libraries which provides > semantic program's functionality.
Thank you for finally giving us this definition. Incidentally, by this definition most C programs are not standalone. They do _not_ link in their library (libc.so) statically, and thus cannot run without library support. It is possible on some systems to link a program completely statically (e.g. Solaris has a -Bstatic option), but it gets harder and harder all the time. In fact, many third-party vendors provide only .so libraries, and not .a files for static linking.
[ ... ]
I have focussed in on this question, and I am staying away from the debugging/debggability question, because I think my specific size question will remain unanswered if it is not pursued specifically. So here is some background followed by my real question to you:
In this entire thread you have not told us yet what you are trying to do, and what your goals are in limiting the size of CL images. In my experience, there are only a couple of reasons why people want to limit a CL size:
- They have limited transfer capability. Usually the internet or the size of floppy-disks limits what can be transferred of a program. However, a lisp "program" is really a series of functions, which can be contained in a source or .fasl file. Others have mentioned this before. I can write a trivial lisp program and give its fasl file a magic-number that allows the program to run the lisp that is on the system and to load in its own fasl file and run it. Such a program can be only a few hundred bytes. We lispers seldom talk about such programs because it is too trivial, and we tend to think of it as cheating (i.e. it does not really show how much actual memory the program is using when it is running). And if the media you want to use is floppy disk, then I recommend that you rethink your distribution strategy and buy a cheap CD-rom burner; some systems don't even come with floppy drives anymore, though all come with CD-Rom drives.
You did mention wanting to be able to have lisps loaded on machines so that such small programs can be transferred via internet. But you do not state why; are you planning to sell products to customers who will not want to install a lisp system on their machines?
- They have limited memory space. Nowadays, the only things left that have less than a couple of megabytes of memory in them are the older embedded systems. Soon your refrigerator will have more memory than your vintage 1995 PC. My wife and I just went out looking for refrigerators, and were amazed at the sophistication of the electronics; I was tempted to look for a USB port, but knew it was useless because these refrigerators were made after Webvan went out of business :-) But the age of embedded systems is here, and the size of the embedded systems nowadays does not preclude CL from being ubiquitous, even in that arena.
So now for my question: Given the above background, can you explain to me a little of what you are trying to _do_, and help me to understand the reason or reasons why you want your CL system to be a specific size?
-- Duane Rettig Franz Inc. http://www.franz.com/ (www) 1995 University Ave Suite 275 Berkeley, CA 94704 Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
>>>>> "Tim" == Tim Bradshaw <t...@cley.com> writes:
Tim> Now imagine a system which lets you load into it, while it's running, Tim> a patch file. The patch file contains the bug fix, but, even better, Tim> it also contains mechanisms that cause all the program's data to be Tim> converted on-the-fly (and almost certainly on-demand) tot he new Tim> format. There is no downtime. I think it's clear that this sort of Tim> thing would be nice to have - even C++ people are groping towards it Tim> though, last I read, they hadn't worked out the on-the-fly conversion. Tim> stuff yet.
Can you describe how this works in a bit more detail? Is this a multithreaded Lisp so you can do patch in one thread without stopping the processing in the other threads? How does changing a function, say, interact with other running threads? (I don't use a threaded Lisp.)
* Raymond Toy wrote: > Can you describe how this works in a bit more detail? Is this a > multithreaded Lisp so you can do patch in one thread without stopping the > processing in the other threads? How does changing a function, say, > interact with other running threads? (I don't use a threaded Lisp.)
I think that it would really be interesting only for some multithreaded application, although I can imagine something event-driven as well (one source of events would be something that said `you have a patch, waiting, please load it'). For such a single-threaded application you wouldn't have the issue of other threads, but you would have the issue of whether redefining a function actually means that callers pick up the new version, which is I think not guaranteed by the standard (unless you declare everything NOTINLINE) but in practice it's easy enough to know what the implementation does that it is not a problem.
For a multithreaded application you'd have to do something that put the other threads into a good state, and this might involve essentially momentarily stopping the application while the patch loaded, but the interruption would be brief - and you can likely arrange things so that volatile state is not lost while this happens. On top of this you have the same redefinition caveats as above.
This is really what I meant by `near-standard functionality' - there are caveats but it's fairly clear that it's possible to do this kind of thing without extreme pain.
In the application I worked on until recently we were generally constrained by politics not to do this kind of thing (patches couldn't go into the live system without huge testing) but we did occasionally in desperate circumstances, and there was a mechanism of stopping the system to load the patch. This was a lot faster than the 20 minutes or so it took to come up from cold.
> > On Sun, 16 Sep 2001, Erik Naggum wrote: > > [snip] > > > in Common Lisp. This means (their) Common Lisp is never used to build > > > the kinds of toys that programmers need to build trust in their tools. > > > Being able to dump a toy executable like you ask for is therefore highly > > > desirable, but it is a completely useless exercise for anything other > > > than such building of trust in your tools. [snip] > > Y'know, I've taken this line for years, but reading this made me think of > > CGIs. It seems to me that loads of actually deployed CGIs aren't *that* > > much more complex than the hello, world program. For some reason this > > never struck me as plausible when people brought up "trivial" shell utils. [snip] > Ah, but CGIs are a different beast.
Not "in themselves". I.e., "building" many CGIs is not fundementally more complex than building hello, world.
> If you're using CL to write CGI > scripts, you presumably have more than one little hello world type > script. You probably have a whole bunch.
Sure.
> So you install the CL > system just as you would perl, and then the cost to deliver each CGI > script is the cost of a .lisp or .fasl file.
Absolutely, but I wasn't addressing the distributabilty issue, per se. That is, I was *only* thinking about the "toy" nature of hello, world. See my subsequent post for a similar view to what you express above.
A clean web archive of CL CGIs might also be a "friendly to the lost" thing. They would be simple programs, about familiar things, and are immediateately useable in a public way.
> > Y'know, I've taken this line for years, but reading this made me think of > > CGIs. It seems to me that loads of actually deployed CGIs aren't *that* > > much more complex than the hello, world program. For some reason this > > never struck me as plausible when people brought up "trivial" shell utils.
> A lot of CGIs have been written in Perl. When people test this, CLISP > starts up faster than Perl and is for a lot of things faster. So, > there's no reason CLISP couldn't be used for CGIs.
Never said otherwise. Indeed, that's one of CLISP's strong niches IMHO. Remember the context of the discussion: do people deploy "hello, world" like toys? Yes, they do. Of course, you don't need to assemble a super striped image to deploy 'em, you can follow the very standard Perl/Python/etc. practice of forcing the user to install the enivroment and then download the script files.
My comments were *very* targeted :) But it's good to re-bring up the actually use of CL for this sort of thing.
> >>>>> "Tim" == Tim Bradshaw <t...@cley.com> writes:
> Tim> Now imagine a system which lets you load into it, while it's running, > Tim> a patch file. The patch file contains the bug fix, but, even better, > Tim> it also contains mechanisms that cause all the program's data to be > Tim> converted on-the-fly (and almost certainly on-demand) tot he new > Tim> format. There is no downtime. I think it's clear that this sort of > Tim> thing would be nice to have - even C++ people are groping towards it > Tim> though, last I read, they hadn't worked out the on-the-fly conversion. > Tim> stuff yet.
> Can you describe how this works in a bit more detail? Is this a > multithreaded Lisp so you can do patch in one thread without stopping the > processing in the other threads? How does changing a function, say, > interact with other running threads? (I don't use a threaded Lisp.)
I did this kind of on-the-fly patching with a system I worked on a couple of jobs ago. This application was a server executing GUI requests one at a time. There was an administrative interface that could put special requests on the cue that was just any lisp code you cared to send (like new method definitions). The system start-up was ~3 hours and was used by airline crew controllers so that much down time was not an attractive option...
> An any concept is not valid in absolute sense. It is only valid in > context of current discussion after all sides who take part in that > discussion came to agree about the meaning of that concept and until the > end of discussion.
That is basically what I said. Please get rid of the silly arguments assuming anyone here are stupid enough here to argue about "valid in an absolute sense". Nobody has even given you cause to believe they think in such retarded terms. We all _know_ what context means and does to the validity of concepts and ideas. Please assume that people here are not lamebrained, OK?
Let me repeat myself:
Therefore, the _concept_ "standalone executable" is no longer valid.
_You_ are, in other words, trying to abuse the context of the validity of the concept "standalone executable" beyond what it once was able to withstand. Standandalone executables no longer exist, except those in embedded systems. Everything else depends on a lot of supporting software around them that you simply cannot ignore. (I was wrong about boot loaders -- they depend on the BIOS, which are not standalone, either.) It is a very good idea to rid yourself of the whole notion of "standalone" in dealing with executables. It marks you as completely outdated in the modern computer world.
> Computer's programs are intendent to be used but not debugged by users.
That depends on what you consider "debug". I consider the famous DOS query "Abort, Retry, Ignore" to be a debugger interface, for instance. _Really_ good programs actually allow users to decide the fate of the system in face of unhandled exceptional situations, not just _die_, like crappy software does. It is highly unlikely that really complex software will not encounter unhandled situtations. If they turn into disasters, you have bugs. If they turn into a query to an operator, they are not bugs. The former requires static-style debugging by an off-site crew. The latter allows an on-site operator to handle the situation nicely and get the system back up and running. This is what we have system admins for these days. I thus consider your views of what computer programs are intended to do alarmingly outdated. You argue as if you work on an embedded system in isolation from everything else. If you do, please say so in explicit terms, do not drag in all the old, invalid concepts from that mode of operation for computers -- it is _truly_ outdated.
> Debugging of broken programs is a task for programmers but not for users.
Your view of what debugging consists of reveals a lack of willingness to listen to what people are telling you. Please drop this arrogance and start to listen. That _is_ why you came to this newsgroup, is it not?
> As far as I remember in this thread I only expressed my opinion, that it > would be good for me and, probably, for Lisp, if some feature existed.
You have asked us to help you with more information. Your "opinions" are the vehicles on which we try to deliver the answers your questions, because they constitute the context in which communication with you can take place. Therefore, they are not _just_ your opinions, but the whole framework of your mind when you come here to receive information. If it is clear that you are not able or willing to listen to information that says that your "opinions" are misguided (i.e, that your context needs to be expanded), you will not learn anything and only frustrate everybody.
This is not mere suspicion. All newsgroups have "newbies" who come and ask questions in a context they are familiar with and refuse to listen to anything that does not work in their original context. It is one of the most annoying features of USENET. I actually expect people to _listen_ before they take the time to express any "opinions". A good USENET rule is to read a newsgroup for a couple weeks before you post anything. This may be too hard to do in some cases, but it is definitely not bad advice.
Please do not be coy with me. The way you have defined standalone executable is definitely a disk-space argument.
> By the way, I don't understand why my wish of Lisp system can generate > small applications is so horrible?
Look, I have already told you it is not, in fact, that it is a good thing for certain limited purposes. Please pay attention to what I say if you wish to talk with me. I am _trying_ to be patient with you, but you are turning out to be very, very annoying and persistent in repeating things that have been refuted by several people. Why are you doing this? My "USENET troll" sensor is peaking.
> You have missed my point here. I argue that some qualities of CL > realizations won't allowed me to start using it on my work very soon.
My argument is that those are not some qualities of CL, but some of _your_ qualities in interaction with some of the qualities of CL. You seem very persistent in ignoring your own background and argue as if you have some very fixed ideas about what is right and wrong. One of the best things about Common Lisp is that we learn the meaning and importance of tradeoffs in a much deeper and more profound way than any other language. Common Lisp people have to pay for their features. ("Pay" and "buy" do not necessarily refer to money, but to any resource.) Some other languages give you no choice, so it works just like taxation.
> I would prefer that CL environment has been preinstalled on any platform. :)
Well, this silly response may actually be the core of your problems. You have to deal with reality as it exists. Asking people to deal with you in terms of your dreams is not at all inspiring to anybody but yourself.
> * Valeriy E Ushakov wrote: > > This low level stuff has nothing to do with CL directly, but I just > > want to show you that even at the bare iron level of "standalone-ness" > > people actually deploy code in production (even in the flash!) with > > debugging facilities built-in.
> It's always misleading to give examples from spacecraft because > they're so weird, but I remember a story about some mars spacecraft > (quite recent I think, and one of the ones that didn't crash), which > suffered from system crashes due to <something>. The thing ran some > embedded OS - perhaps OS9? - and the people, being sensible, had left > all the debugging tools there. The description I read was a bit vague > but it sounded suspiciously as if they essentially logged in to the > spacecraft and edited parameters interactively to fix the problem. I > thought this was really cool. What was sad was that they (the NASA > people) got attacked for launching the thing with bugs, when in fact > they'd done everything they needed to to make sure they could fix the > bugs on the fly, while not missing the launch window due to testing).
>>>>> "Tim" == Tim Bradshaw <t...@cley.com> writes:
Tim> * Raymond Toy wrote: >> Can you describe how this works in a bit more detail? Is this a >> multithreaded Lisp so you can do patch in one thread without stopping the >> processing in the other threads? How does changing a function, say, >> interact with other running threads? (I don't use a threaded Lisp.)
Tim> I think that it would really be interesting only for some Tim> multithreaded application, although I can imagine something Tim> event-driven as well (one source of events would be something that Tim> said `you have a patch, waiting, please load it'). For such a Tim> single-threaded application you wouldn't have the issue of other Tim> threads, but you would have the issue of whether redefining a function Tim> actually means that callers pick up the new version, which is I think Tim> not guaranteed by the standard (unless you declare everything Tim> NOTINLINE) but in practice it's easy enough to know what the Tim> implementation does that it is not a problem.
Tim> For a multithreaded application you'd have to do something that put Tim> the other threads into a good state, and this might involve Tim> essentially momentarily stopping the application while the patch Tim> loaded, but the interruption would be brief - and you can likely Tim> arrange things so that volatile state is not lost while this happens. Tim> On top of this you have the same redefinition caveats as above.
Thanks for the example (and Coby Beck too). All of my lisp code has been simulations of a wireless radio link so if I goofed, that meant all previous results were wrong and the current state would very likely be wrong too ,so I would have to start over in any case. Startup times are on the order of seconds to maybe a minute.
Tim Bradshaw <t...@cley.com> wrote: > * Aleksandr Skobelev wrote: >> <IN-MY-OPINION>
> I think the preferred syntax is (with-opinion (:mine t) ...)
You have just read my thoughts! :) I've wanted to use something like that, but I haven't decided what to do with special characters in the body of such form. So I decided to went by beaten track. We could also use something like
> Well, it's not just debugging, is it. Imagine a long-running > mission-critical program, in which a bug is found. Now the > traditional approach to this is stop the application, upgrade it, > convert all the data to some new format, and restart. Maybe this > takes you a few hours.
> Now imagine a system which lets you load into it, while it's running, > a patch file. The patch file contains the bug fix, but, even better, > it also contains mechanisms that cause all the program's data to be > converted on-the-fly (and almost certainly on-demand) tot he new > format. There is no downtime. I think it's clear that this sort of > thing would be nice to have - even C++ people are groping towards it > though, last I read, they hadn't worked out the on-the-fly conversion. > stuff yet.
> CL systems provide this stuff as near-standard functionality (there > are caveats but they're not a problem in practice). And the way > they do this is by keeping various meta-information about stuff, so > that there is enough information in the running system to do this > magic. I'm not an implementor, but I bet you that a lot of this data > is *the same* as the kind of thing you need for debugging.
> Does this mean that minimal CL systems are slightly bigger than > minimal C ones? Yes. Does it mean they aren't suitable for embedded > controllers in washing machines? Probably it does (though they seem > to work OK in embedded controllers in spacecraft). But not all > systems are minimal, and having this kind of stuff can save you a lot > of money in systems that aren't.
>> much obliged to you the rest of all my life. :)
> (Assuming a good natured joke in the line "something that can save my life" - > ie I don't think you really believe a small executable is so important that you > won't sacrifice it except to save your life)
If you look at the end of my phrase more carefully, you will find there a little sign, which is used to mark this phrase as a joke and, of course, good natured joke. :)
> No, you can not get a very small "Hello World" program in Common Lisp without a > lot of the Lisp system included. This is a mark on the column of bad points.
> * A *much* faster development cycle > * A program that can be modified/enhanced/debugged while it is still running > * The ability to use symbols as data > * A macro system so powerful you can define your own programming language on > top of CL > * An object oriented development platform that allows you to redefine your > classes at runtime, existing objects and all > * A language that can easily produce, compile and execute it's own source code, > again at runtime
> This is just a start of a list of Common Lisp's good points, perhaps others > will chime in with others. But I think it is quite enough to outweigh any > disadvantage of a small executable for all but a very few and very specific > situations.
Thank you for propaganda. :) It is always useful to speak some good words about advantages of CL.
