Menu
▾
▴
clisp-list
|
From: Sam S. <sd...@gn...> - 2006-01-26 17:02:58
|
I modified CVS head to do the following: SAVEINITMEM now accepts :SCRIPT that defaults to (NOT INIT-FUNCTION) When the image created with :SCRIPT T (default) is invoked, the tradition behavior is exhibited: first positional argument is the script file name, the rest is placed into *ARGS* When the image created with :SCRIPT NIL is invoked, all positional arguments go into *ARGS*. this means: $ ./clisp -q -K boot -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 $ I want "./adder -help" to print the function doc for init-function too. I appreciate feedback. -- Sam Steingold (http://www.podval.org/~sds) running w2k http://www.jihadwatch.org http://www.iris.org.il http://ffii.org http://www.openvotingconsortium.org http://www.dhimmi.com http://truepeace.org The only substitute for good manners is fast reflexes. |
|
From: Klaus W. <kw...@w-...> - 2006-01-26 17:43:55
|
On Thu, Jan 26, 2006 at 12:01:28PM -0500, Sam Steingold wrote:
> I modified CVS head to do the following:
>
> SAVEINITMEM now accepts :SCRIPT that defaults to (NOT INIT-FUNCTION)
> When the image created with :SCRIPT T (default) is invoked,
> the tradition behavior is exhibited: first positional argument is the
> script file name, the rest is placed into *ARGS*
> When the image created with :SCRIPT NIL is invoked,
> all positional arguments go into *ARGS*.
Thank you - but I would suggest going a bit further by using a tristate
parameter, for example:
:argument-handler :script
(This is the default behavior when no INIT-FUNCTION is
specified.) The CLISP runtime handles flag arguments, and the
first positional parameter is treated as a script file name.
Argument processing ends when a blank parameter ("") or double
minus (--) is encountered, and any remaining arguments are placed
into the EXT:*ARGS* variable.
:argument-handler :standalone
All arguments, including flags starting with '-', are placed into
the EXT:*ARGS* variable. This allows standalone executables to
fully handle all argument processing. The application is
responsible for handling any flag arguments normally handled
by the CLISP runtime if that functionality is required.
:argument-handler :hybrid
(This is the default behavior when an INIT-FUNCTION is
specified.) The CLISP runtime handles flag arguments. All
positional parameters (starting with the first non-flag argument)
are placed into the EXT:*ARGS* variable for processing by the
application. Flag arguments intended for the application must be
placed after a blank argument ("") or double minus (--).
The names are just suggestions of course.
This would allow fully emulating the standard behavior of C applications.
-Klaus
|
|
From: Steven E. H. <se...@pa...> - 2006-01-26 21:55:21
|
Sam Steingold <sd...@gn...> writes: > Nevertheless, I believe it is important that someone who receives a > clisp-based application can get a clisp repl by merely typing I would expect it to be the prerogative of the author to make the implementation decision to use CLISP or some other system, and that decision here is not meant to be the business of the end-user. Why must every application created with CLISP also /be/ CLISP? -- Steven E. Harris |
|
From: Pascal B. <pj...@in...> - 2006-01-27 10:54:50
|
Sam Steingold writes: > > * Steven E.Harris <fru@cnavk.pbz> [2006-01-26 13:55:13 -0800]: > > > > Sam Steingold <sd...@gn...> writes: > > > >> Nevertheless, I believe it is important that someone who receives a > >> clisp-based application can get a clisp repl by merely typing > > > > I would expect it to be the prerogative of the author to make the > > implementation decision to use CLISP or some other system, and that > > decision here is not meant to be the business of the end-user. Why > > must every application created with CLISP also /be/ CLISP? > > because the what you are distributing (e.g., clisp executable image) > does include full clisp (compiler, debugger &c) and I see no reason to > prevent the user from easily accessing it. > > if you want full control over your application's options, you can use a > script. I was thinking of legal considerations. IIUC, the GPL implies that a user must be able to extract the image, and to compile a patched version of clisp (eg. with added modules), and to save a new executable with the extracted image and the patched clisp. Similarly, he should be able to patch any clisp lisp function (ie. needs a REPL in the saved image). All this even without considering the license of the application in this image. -- __Pascal Bourguignon__ http://www.informatimago.com/ Un chat errant se soulage dans le jardin d'hiver Shiki |
|
From: Sam S. <sd...@gn...> - 2006-01-26 18:26:11
|
> * Klaus Weidner <xj@j-z-c.pbz> [2006-01-26 11:43:47 -0600]: > > :argument-handler :standalone > > All arguments, including flags starting with '-', are placed into > the EXT:*ARGS* variable. This allows standalone executables to > fully handle all argument processing. The application is > responsible for handling any flag arguments normally handled > by the CLISP runtime if that functionality is required. this will disable -M and -x. I understand that someone might want to re-implement "ls" with clisp and this will prevent him. Nevertheless, I believe it is important that someone who receives a clisp-based application can get a clisp repl by merely typing $ app -x '(saveinitmem)' $ app -M lispinit.mem or just $ app -x '(saveinitmem "clisp" :executable t)' $ ./clisp -- Sam Steingold (http://www.podval.org/~sds) running w2k http://www.memri.org http://pmw.org.il http://www.mideasttruth.com http://www.dhimmi.com http://www.camera.org http://www.honestreporting.com (when (or despair hope) (cerror "Accept life as is." "Bad attitude.")) |
|
From: Klaus W. <kw...@w-...> - 2006-01-27 00:20:27
|
On Thu, Jan 26, 2006 at 01:24:43PM -0500, Sam Steingold wrote: > > * Klaus Weidner <xj@j-z-c.pbz> [2006-01-26 11:43:47 -0600]: > > :argument-handler :standalone > > > > All arguments, including flags starting with '-', are placed into > > the EXT:*ARGS* variable. This allows standalone executables to > > fully handle all argument processing. The application is > > responsible for handling any flag arguments normally handled > > by the CLISP runtime if that functionality is required. > > this will disable -M and -x. > I understand that someone might want to re-implement "ls" with clisp and > this will prevent him. My understanding is that you can't use any flags introduced with "-" if the default argument handling is active, since they'll get parsed by the clisp runtime and it'll produce the "invalid command-line option" message before your application even gets a chance to look at them. I guess I could live with a mixed mode where the clisp runtime would look at the arguments and then extracts and handles those it knows, leaving the rest for the application. But the default clisp argument set would cause far too many collisions, it uses many single-letter flags for its own purposes. It would cause less collisions if, in :standalone mode, clisp would handle only -M and -x, or (preferably) only long-form versions --mem-size and --expressions, and pass all others to ext:*args*. > Nevertheless, I believe it is important that someone who receives a > clisp-based application can get a clisp repl by merely typing [...] > $ app -x '(saveinitmem "clisp" :executable t)' > $ ./clisp Would one of these alternatives also be acceptable? app --clisp-args -x '(saveinitmem "clisp" :executable t)' (a magic --clisp-args switch which, if it's the first argument, overrides the :standalone flag and gives argument handling control back to the CLISP runtime) CLISP_EXPRESSIONS='(saveinitmem "clisp" :executable t)' ./app BTW, the new standalone SAVEINITMEM produces programs whose mechanics don't quite match the discussion in the COPYRIGHT file. They are produced with SAVEINITMEM but don't allow easy rebuilding using a CLISP rebuilt from source. I think the spirit of the COPYRIGHT file could be maintained if there'd be a flag "--detach-image" (non-overridable) or comparable functionality so you could do something like this to run it against a home built clisp: ./app --clisp-args --detach-image "exe.mem" my-own-clisp -M exe.mem -x ... Would this be reasonably easy (in other words, are they essentially just concatenated) or would it involve a lot of processing? -Klaus |
|
From: Roman B. <rbe...@ya...> - 2006-01-27 08:47:05
|
Sam Steingold <sd...@gn...> writes: > Nevertheless, I believe it is important that someone who receives a > clisp-based application can get a clisp repl by merely typing > $ app -x '(saveinitmem)' > $ app -M lispinit.mem > or just > $ app -x '(saveinitmem "clisp" :executable t)' > $ ./clisp IMHO it is up to the application author to decide whether to provide repl to users; although it is definitely up to you to decide whether to provide application authors this freedom. -- With regards, Roman. |
|
From: Pascal B. <pj...@in...> - 2006-01-27 10:48:16
|
Sam Steingold writes: > > * Klaus Weidner <xj@j-z-c.pbz> [2006-01-26 11:43:47 -0600]: > > > > :argument-handler :standalone > > > > All arguments, including flags starting with '-', are placed into > > the EXT:*ARGS* variable. This allows standalone executables to > > fully handle all argument processing. The application is > > responsible for handling any flag arguments normally handled > > by the CLISP runtime if that functionality is required. > > this will disable -M and -x. > I understand that someone might want to re-implement "ls" with clisp and > this will prevent him. > > Nevertheless, I believe it is important that someone who receives a > clisp-based application can get a clisp repl by merely typing > $ app -x '(saveinitmem)' > $ app -M lispinit.mem > or just > $ app -x '(saveinitmem "clisp" :executable t)' > $ ./clisp Couldn't this be archived with an environment variable? $ app -x I am app and I print 'X'. $ CLISP_ARGUMENTS="-x '(progn (princ (lisp-implementation-version)) (ext:quit 0))'" app -x 2.38 (2006-01-24) (built 3347193361) (memory 3347193797) $ CLISP_ARGUMENTS="-x ' (princ (lisp-implementation-version))'" app -x 2.38 (2006-01-24) (built 3347193361) (memory 3347193797) I am app and I print 'X'. $ -- __Pascal Bourguignon__ http://www.informatimago.com/ What is this talk of 'release'? Klingons do not make software 'releases'. Our software 'escapes' leaving a bloody trail of designers and quality assurance people in it's wake. |
|
From: Sam S. <sd...@gn...> - 2006-01-26 22:02:54
|
> * Steven E.Harris <fru@cnavk.pbz> [2006-01-26 13:55:13 -0800]: > > Sam Steingold <sd...@gn...> writes: > >> Nevertheless, I believe it is important that someone who receives a >> clisp-based application can get a clisp repl by merely typing > > I would expect it to be the prerogative of the author to make the > implementation decision to use CLISP or some other system, and that > decision here is not meant to be the business of the end-user. Why > must every application created with CLISP also /be/ CLISP? because the what you are distributing (e.g., clisp executable image) does include full clisp (compiler, debugger &c) and I see no reason to prevent the user from easily accessing it. if you want full control over your application's options, you can use a script. -- Sam Steingold (http://www.podval.org/~sds) running w2k http://www.camera.org http://www.dhimmi.com http://pmw.org.il http://www.honestreporting.com http://www.openvotingconsortium.org Democrats, get out of my wallet! Republicans, get out of my bedroom! |
|
From: Roman B. <rbe...@ya...> - 2006-01-30 09:04:43
|
Pascal Bourguignon <pj...@in...> writes: > IIUC, the GPL implies that a user must be able to extract the image, > and to compile a patched version of clisp (eg. with added modules), > and to save a new executable with the extracted image and the patched > clisp. IMHO GPL requires only the source availability, so pointers to the source of the clisp and the application (giving the user the possibility to create the image himself) should be sufficient (and they are required anyway). > Similarly, he should be able to patch any clisp lisp function > (ie. needs a REPL in the saved image). Having the source gives user the possibility to enable repl even if application author/maintainer hided it. > All this even without considering the license of the application in this > image. Relationship between clisp and clisp-based application seems to be close enough to propagate GPL to the app. -- With regards, Roman. |
|
From: Pascal B. <pj...@in...> - 2006-01-30 11:44:24
|
Roman Belenov writes: > Pascal Bourguignon <pj...@in...> writes: > > > IIUC, the GPL implies that a user must be able to extract the image, > > and to compile a patched version of clisp (eg. with added modules), > > and to save a new executable with the extracted image and the patched > > clisp. > > IMHO GPL requires only the source availability, so pointers to the source of > the clisp and the application (giving the user the possibility to create the > image himself) should be sufficient (and they are required anyway). > > > Similarly, he should be able to patch any clisp lisp function > > (ie. needs a REPL in the saved image). > > Having the source gives user the possibility to enable repl even if > application author/maintainer hided it. Indeed, the sources of clisp, the .fas of the application and a script to build the image anew. Then the user can modify it to generate a version of the image with REPL. > > All this even without considering the license of the application in this > > image. > > Relationship between clisp and clisp-based application seems to be close > enough to propagate GPL to the app. Not necessarily. -- __Pascal Bourguignon__ http://www.informatimago.com/ This is a signature virus. Add me to your signature and help me to live. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X