From: Andrew S. <ast...@ya...> - 2006-01-24 22:12:24
|
Hi, How can I build the standalone executable with the new release? (I couldn't find it in impnotes). Thank you, Andrei __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Sam S. <sd...@gn...> - 2006-01-24 23:32:33
|
> * Andrew Stebakov <nfgronxbi@lnubb.pbz> [2006-01-24 14:12:17 -0800]: > > How can I build the standalone executable with the new > release? > (I couldn't find it in impnotes). look for "executable" in http://www.gnu.org/software/clisp/impnotes/image.html -- Sam Steingold (http://www.podval.org/~sds) running w2k http://www.honestreporting.com http://truepeace.org http://www.mideasttruth.com http://www.iris.org.il http://www.memri.org http://pmw.org.il UNIX is as friendly to you as you are to it. Windows is hostile no matter what. |
From: Roman B. <rbe...@ya...> - 2006-01-25 14:04:24
|
Sam Steingold <sd...@gn...> writes: > look for "executable" in > http://www.gnu.org/software/clisp/impnotes/image.html BTW Is there a way to disable normal command-line processing (so that all arguments are just stored in EXT:*ARGS*) ? Haven't seen it in documentation, though it makes sense for standalone executables. -- With regards, Roman. |
From: Sam S. <sd...@gn...> - 2006-01-25 15:01:47
|
> * Roman Belenov <eoryrabi@lnaqrk.eh> [2006-01-25 17:03:57 +0300]: > > Sam Steingold <sd...@gn...> writes: > >> look for "executable" in >> http://www.gnu.org/software/clisp/impnotes/image.html > > BTW Is there a way to disable normal command-line processing (so that > all arguments are just stored in EXT:*ARGS*) ? Haven't seen it in > documentation, though it makes sense for standalone executables. look for "init-function" in http://clisp.cons.org/impnotes/image.html really people, this is just _one_ small page - why not read it all? CLISP documentation is searchable using google, see http://clisp.cons.org trust me, it has _everything_, just _read_ it. -- Sam Steingold (http://www.podval.org/~sds) running w2k http://pmw.org.il http://www.palestinefacts.org http://ffii.org http://www.honestreporting.com http://www.iris.org.il http://www.dhimmi.com "Complete Idiots Guide to Running LINUX Unleashed in a Nutshell for Dummies" |
From: Roman B. <rbe...@ya...> - 2006-01-25 15:45:23
|
Sam Steingold <sd...@gn...> writes: >> BTW Is there a way to disable normal command-line processing (so that >> all arguments are just stored in EXT:*ARGS*) ? Haven't seen it in >> documentation, though it makes sense for standalone executables. > > look for "init-function" in > http://clisp.cons.org/impnotes/image.html The arguments are processed before init-function is called, so that doesn't help. It would be possible to CUSTOM:*INIT-HOOKS* as a workaround if ext:*args* were initialized before calling the hooks, but it is not the case. -- With regards, Roman. |
From: Sam S. <sd...@gn...> - 2006-01-25 16:16:16
|
> * Roman Belenov <eoryrabi@lnaqrk.eh> [2006-01-25 18:45:12 +0300]: > > Sam Steingold <sd...@gn...> writes: > >>> BTW Is there a way to disable normal command-line processing (so that >>> all arguments are just stored in EXT:*ARGS*) ? Haven't seen it in >>> documentation, though it makes sense for standalone executables. >> >> look for "init-function" in >> http://clisp.cons.org/impnotes/image.html > > The arguments are processed before init-function is called, so that > doesn't help. It would be possible to CUSTOM:*INIT-HOOKS* as a > workaround if ext:*args* were initialized before calling the hooks, > but it is not the case. I don't understand what you want. suppose you want your program to add its arguments. you do this: $ clisp -norc -x '(saveinitmem "adder" :executable t :norc t :quiet t :init-function (lambda () (print (reduce (function +) ext:*args* :key (function read-from-string))) (ext:exit)))' $ ./adder "" 1 2 3 4 10 $ -- Sam Steingold (http://www.podval.org/~sds) running w2k http://ffii.org http://www.mideasttruth.com http://www.camera.org http://www.memri.org http://www.openvotingconsortium.org http://pmw.org.il Professionalism is being dispassionate about your work. |
From: Roman B. <rbe...@ya...> - 2006-01-26 07:22:14
|
Sam Steingold <sd...@gn...> writes: > suppose you want your program to add its arguments. > you do this: > > $ clisp -norc -x '(saveinitmem "adder" :executable t :norc t :quiet t > :init-function (lambda () (print (reduce (function +) ext:*args* :key > (function read-from-string))) (ext:exit)))' > > $ ./adder "" 1 2 3 4 What I want is to eliminate the need of "" (or --) as a first argument, so that ./adder 1 2 3 4 would do the job instead of treating 1 as name of Lisp file to load. As far as I understand, it's not currently supported and requires additional flag in the image and corresponding keyword argument in saveinitmem. -- With regards, Roman. |
From: Pascal B. <pj...@in...> - 2006-01-26 13:48:42
|
Roman Belenov writes: > Sam Steingold <sd...@gn...> writes: > > > suppose you want your program to add its arguments. > > you do this: > > > > $ clisp -norc -x '(saveinitmem "adder" :executable t :norc t :quiet t > > :init-function (lambda () (print (reduce (function +) ext:*args* :key > > (function read-from-string))) (ext:exit)))' > > > > $ ./adder "" 1 2 3 4 > > What I want is to eliminate the need of "" (or --) as a first argument, so that > ./adder 1 2 3 4 > would do the job instead of treating 1 as name of Lisp file to load. As far as > I understand, it's not currently supported and requires additional flag in > the image and corresponding keyword argument in saveinitmem. The workaround I suggested doesn't work: [pjb@thalassa tmp]$ clisp -norc -x '(saveinitmem "adder" :executable t :norc t :quiet t :init-function (lambda () (push *load-pathname* ext:*args*) (print (reduce (function +) ext:*args* :key (function read-from-string))) (ext:exit)))' clisp -norc -x '(saveinitmem "adder" :executable t :norc t :quiet t :init-function (lambda () (push *load-pathname* ext:*args*) (print (reduce (function +) ext:*args* :key (function read-from-string))) (ext:exit)))' [1]> 2587744 ; 646396 [pjb@thalassa tmp]$ file adder file adder adder: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped [pjb@thalassa tmp]$ ./adder 1 2 3 ./adder 1 2 3 *** - LOAD: A file with name 1 does not exist [pjb@thalassa tmp]$ -- __Pascal Bourguignon__ http://www.informatimago.com/ You never feed me. Perhaps I'll sleep on your face. That will sure show you. |
From: Klaus W. <kw...@w-...> - 2006-01-26 16:24:36
|
On Thu, Jan 26, 2006 at 02:48:27PM +0100, Pascal Bourguignon wrote: > The workaround I suggested doesn't work: > > [pjb@thalassa tmp]$ clisp -norc -x '(saveinitmem "adder" :executable t :norc t :quiet t :init-function (lambda () (push *load-pathname* ext:*args*) (print (reduce (function +) ext:*args* :key (function read-from-string))) (ext:exit)))' > clisp -norc -x '(saveinitmem "adder" :executable t :norc t :quiet t :init-function (lambda () (push *load-pathname* ext:*args*) (print (reduce (function +) ext:*args* :key (function read-from-string))) (ext:exit)))' [...] > [pjb@thalassa tmp]$ ./adder 1 2 3 > ./adder 1 2 3 > *** - LOAD: A file with name 1 does not exist I think you're misunderstanding the problem - the issue is that the clisp runtime handles the arguments in a predefined way before the saved memory image is even loaded, so there's nothing the init function can do about it. You don't need to put a filename into the first position of *argv*. The clisp runtime currently works roughly like this: - in "lisp" executable, step through the argument vector provided by the kernel - handle all "-foo" flags defined in the clisp man page for the runtime. All handled arguments are removed from argv. - if a blank argument ("") or -- is encountered, stop argument processing, leaving the remaining args (not the "" or --) in argv. - if a non-option argument is encountered, treat it as the name of a file to load, and discard it from the argument list. - bind the remaining argv contents to ext:*args* - after argv processing is complete, load the memory image specified with "-m" or the memory image attached to the "lisp" executable. - run an initfunc or the repl as appropriate The mechanism ensures that you can run Lisp scripts using the plain "lisp" runtime, but it makes it impossible to create binaries which want to handle arguments in a different way. To change this, you'd need to modify the order in which the actions are done - as far as I can tell the runtime argv handler doesn't even know yet if an image is attached, so it can't change its behavior based on a flag specified when saving the image. So you'd need to look for the attached image first before parsing the arguments. I was planning to look into making a patch for this, but I'm not sure if I understand well enough how things work to do this cleanly. -Klaus |
From: Tom E. <tr...@ba...> - 2006-01-26 16:37:12
|
Coming from the peanut gallery here, but it seems to me that the requirement for an "empty" argument could be handled by using a simple shell script wrapper around the invocation that hides the actual command being executed. This is done regularly in Java so that Java applications can be invoked as: % foo arg1 arg2 arg3 instead of % java -cp "some/class/path:additions/" com.foo.bar.fooApp arg1 arg2 arg3 Why fix something that isn't demonstratably broken when there is a simple work around? -tree -- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "You can't fake quality any more than you can fake a good meal." (W.S.B.) |
From: Roman B. <rbe...@ya...> - 2006-01-26 17:25:15
|
Tom Emerson <tr...@ba...> writes: > Coming from the peanut gallery here, but it seems to me that the > requirement for an "empty" argument could be handled by using a simple > shell script wrapper around the invocation that hides the actual > command being executed. IMHO the main point of creating a standalone executable is to eliminate the need of additional scripts, thus simplifying the deployment. > This is done regularly in Java so that Java > applications can be invoked as: > > % foo arg1 arg2 arg3 > > instead of > > % java -cp "some/class/path:additions/" com.foo.bar.fooApp arg1 arg2 arg3 This approach was available in clisp for ages; the question is how to use new functionality to make things more straightforward. > Why fix something that isn't demonstratably broken when there is a > simple work around? Workaround, whatever simple, is still a workaround, not a solution, -- With regards, Roman. |
From: Pascal B. <pj...@in...> - 2006-01-27 02:52:10
|
Tom Emerson writes: > Coming from the peanut gallery here, but it seems to me that the > requirement for an "empty" argument could be handled by using a simple > shell script wrapper around the invocation that hides the actual > command being executed. This is done regularly in Java so that Java > applications can be invoked as: > > % foo arg1 arg2 arg3 > > instead of > > % java -cp "some/class/path:additions/" com.foo.bar.fooApp arg1 arg2 arg3 > > Why fix something that isn't demonstratably broken when there is a > simple work around? We know and we agree, but this defeats the single executable objective. If you have to have an encapsulating script, they there's no need to put the lisp image in the same file as the lisp executable. Since users want to have only one file, then this only executable must be able to handle its arguments like any other program. -- __Pascal Bourguignon__ http://www.informatimago.com/ You never feed me. Perhaps I'll sleep on your face. That will sure show you. |
From: Douglas P. <dg...@ma...> - 2006-01-27 03:09:26
|
On 2006 Jan 26, at 9:51 PM, Pascal Bourguignon wrote: > Tom Emerson writes: <Java Example elided...> >> Why fix something that isn't demonstratably broken when there is a >> simple work around? > > We know and we agree, but this defeats the single executable > objective. > If you have to have an encapsulating script, they there's no need to > put the lisp image in the same file as the lisp executable. > > Since users want to have only one file, then this only executable must > be able to handle its arguments like any other program. Ok, so another shell from the peanut gallery "weighing in"... First, I am very emotionally sympathetic to the desire to have "one file" .exe (despite my distaste with/at Windows). And very much aghast at the idea that because a "program" is delivered with CLISP that the user should know/care/want to "get at" the underlying CLISP. Ugh. But, all that aside, I am very much impressed with the way that Mac OS X has diverged from the Windows (and Linux, last I looked) style of "application is one binary/executable" by going to a "well formed folder of coherent coupled files". As far as the GUI interface goes, an "application" is a single entity. Sure, there are ways and tools of 'unpacking' that "application", just as there are tools and ways of unpacking .ZIP files on Windows. So as a Mac OS X user, I am amused and saddened by this drive to have everything "in one file", esp. since there doesn't seem to be a Windows equivalent of "an application as folder presented as single entity". The saddest part of it is the complexity that has been put into "clisp" to make this abomination of one file (.EXE) happen. (And note: this is a completely orthogonal issue to the issue of "who gets the command-line 'first'".) Perhaps someone(s) more familiar with Windows can point to a solution that doesn't involve all the yuckyness that Sam (& co) have been putting in, but I fear not... --D'gou |
From: Frank B. <fb...@fr...> - 2006-01-27 04:27:07
|
Douglas Philips wrote: > Perhaps someone(s) more familiar with Windows can point to a > solution > that doesn't involve all the yuckyness that Sam (& co) have been > putting in, but I fear not... there is no yuckyness involved in having one executable, now CLISP has just measured up with GCC, which can create one executable file for all platforms (even on Mac) since the beginning. Lisp is a bit different and I like the image concept for developing, but this doesn't mean that delivering needs to be more complicated than with every other GCC program. Of course, adding the image to the end of the file is not the best solution. For Windows it would be better to use the capabilities of the EXE file format and include it as resources, but until someone wants to write this (and wants to mess with the differences on Linux and Mac for the ELF format), I can live with this solution. -- Frank Buss, fb...@fr... http://www.frank-buss.de, http://www.it4-systems.de |
From: Douglas P. <dg...@ma...> - 2006-01-27 05:26:48
|
On 2006 Jan 26, at 11:26 PM, Frank Buss indited: > Douglas Philips wrote: >> Perhaps someone(s) more familiar with Windows can point to a >> solution >> that doesn't involve all the yuckyness that Sam (& co) have been >> putting in, but I fear not... > ... > Of course, adding the image to the end of the file is not the best > solution. > For Windows it would be better to use the capabilities of the EXE file > format and include it as resources, but until someone wants to > write this > (and wants to mess with the differences on Linux and Mac for the ELF > format), I can live with this solution. Right. The real problem isn't that Lisp isn't like GCC, the real problem is that "a solution to a problem" isn't just one blob of executable code anymore. It wasn't back in the day of the OLD Mac OS's either, which probably had "resource forks" as early as or even earlier than Windows. So catching up to having "resources" now is chasing an faded shadow. And it still gets stuck in that little box of "one file", but oh wait, we'll put a dumb simple "resource" mechanism (i.e. dumb simple file system) inside the file. The whole mess of grunging around inside the executable image is a mess, I've seen (and averted my eyes from) the CVS changes that have been going in. It isn't that they are bad code, it is that the solution itself is bad. Maybe it is the best that can be done with Windows, but it is still ugly. And it isn't completely orthogonal to the command line issue after all, because if you could deliver a bundle of real files as "a solution", then there wouldn't be all this hand wringing about "oh, but a separate script that fixes the command line is bad because it isn't one file anymore" would truly be a non- issue. But hey, I've beat this sad horse enough. I'm just glad I don't have to use CLISP on Windows. :-) --D'gou |
From: root <da...@ax...> - 2006-01-25 19:21:13
|
Sam, I'm trying to build clisp from the sourceforge CVS as of about 2 hours ago. The configure complained that it could not find libsigsegv and gave instructions for installing and configuring it which I followed. Then I did the configure again with the --with-libsigsegv-prefix and it still complains. I read the configure script and it is checking a variable called ${cl_cv_lib_sigsegv} for the value 'yes' but this variable appears never to be set under any conditions. Suggestions? Tim Daly |
From: Sam S. <sd...@gn...> - 2006-01-25 22:13:43
|
> * root <qn...@nk...t> [2006-01-25 15:09:48 -0500]: > > The configure complained that it could not find libsigsegv and gave > instructions for installing and configuring it which I followed. > > Then I did the configure again with the --with-libsigsegv-prefix > and it still complains. > > I read the configure script and it is checking a variable called > ${cl_cv_lib_sigsegv} for the value 'yes' but this variable appears > never to be set under any conditions. it is set by src/configure in config.cache which is sourced by the top-level configure. are you getting errors loading config.cache? -- Sam Steingold (http://www.podval.org/~sds) running w2k http://www.dhimmi.com http://www.palestinefacts.org http://www.iris.org.il http://pmw.org.il http://www.savegushkatif.org Lisp: it's here to save your butt. |
From: root <da...@ax...> - 2006-01-25 22:55:58
|
no errors loading config.cache but i removed this file, started the process from the beginning and it appears to work fine. thanks. Tim Daly |
From: root <da...@ax...> - 2006-01-26 00:57:49
|
i might add a second vote to not expecting -- as the first argument of an executable file. i'm using this standalone feature to allow me to replace a C++ program and this will be an issue as soon as i push out the resulting change. it does make a "drop-in replacement" harder and is a non-standard way of handling command line arguments. i suppose 'scripting' uses of executables was a prior use and i can see why it works the way it does. however it is easier for someone to handle the extra initial arg if they plan to use it in a script than be forced to supply an arg you can't override. Tim Daly |