On Fri, Jul 11, 2008 at 2:17 AM, Klaus Grue <grue@...> wrote:
>> Parth Malwankar wrote:
>>> Basically, I am trying to create an executable using saveinitmem
>>> to accept args from the command line. I was a little confused about
>>> it and ':script nil' seems to do what I want. The only nit being that
>>> if the option passed is already used by clisp (prefixed by - ?), then
>>> clisp seems to be processing it.
>> Sam Steingold wrote:
>>> Digging into clisp mail archives I came across the patch:
>>> this patch indeed does what you appear to want, but I want to make sure
>>> that any clisp executable lets the users access the underlying clisp,
>>> I rejected that patch.
>>> Pascal J. Bourguignon wrote:
>> What about if the underlying clisp would be get at when there is a
>> trailing option such as:
>> foo --foo-option -- --other-foo-option --- --clisp-option
>> That would leave everybody happy.
> The patch mentioned above (which I suggested) has two things in it.
> If you look at Implementation Notes for GNU CLISP, Section 31.1.1:
> Cradle to Grave, you will see that CLISP parses command line arguments
> as the very first thing. It does so for several reasons.
> In the patch I suggested a way to communicate data
> from saveinitmem to the initialization process which allowed
> saveinitmem to store data in the dumped executable in
> such a way that the initialization process could read them as the
> very *very* first thing, i.e. before processing command line arguments.
> Having such a communication channel from saveinitmem to the initialization
> process allows to store information in the executable about how
> command line arguments should be processed.
> The patch I suggested used this to store a Boolean which essentially
> switched between what Parth Malwankar wants and what Sam Steingold
> wants. As I understand it, the patch was rejected because it allows
> saveinitmem to lock out the user from gaining access to the CLISP
> prompt. I was not too fond of it myself, but that was because it
> locked me out from the -m command line option.
> But the idea in the patch could be used more in line with what Pascal
> Bourguignon suggests, namely to try to make everybody happy. But my
> suggestion would be thus:
> Introduce a number of new CLISP options called --clisp-h --clisp--help
> --clisp--version --clisp--licence --clisp-m and so on whose semantics
> cannot be changed.
Or clisp could have a 'reserved' optional bool flag for running saved
This would enable processing of args in exactly the same way its
foo --clisp-args-enable -m 10M ... -- --app-arg0 --app-arg1 ...
Normat usage for the user could be:
foo --app-arg0 --app-arg1 ... ;no 10M here. default used
This would make the normal usage consistent will standard apps
while still giving a more advanced user access to clisp prompt.
> Then use something like the trick in the patch to store information
> in the executable about how to interpret other arguments. As an example,
> one could store the information that -h means --clisp-h, that -memory
> means --clisp-m, or whatever. And then one could, as default, map
> all options mentioned in the Synopsis of the CLISP man page to their
> --clisp equivalents (mapping -h to --clisp-h and so on systematically).
> But doing so should not affect the meaning of e.g. --clisp-h.
> --clisp-h should give help on clisp even if -h also gave help on clisp.
> But it all boils down to this: the current CLISP command line handling
> has some properties which not everybody wants, and that is so because
> there is no communication channel from saveinitmem to the very beginning
> of the initialization process in the craddle-to-grave sequence.
> Having a communication channel gives more freedom to design command
> line handling.
> Just to recall: the trick in the patch was to declare an array, put a
> fixed, magic number in its first eight bytes, and then let saveinitmem
> store whatever it wants in the remainder of the array. Then, as the
> first step of the craddle-to-grave sequence, scan the executable for
> the magic number. If the magic number is not found or is found more
> than once, panic. Else, read the bytes that follow the magic number
> since those bytes contain the message that saveinitmem wants to send
> to the initialization process.
>> 29 Jan 2008 Sam Steingold wrote:
>>> please file an RFE on SF.
> Sorry for not doing so. I just left academia in favour of the space
> industry (where I have been before, actually that was where I learned
> about CLISP somewhere around 1990). A downside is that I have had
> less time for following up on the CLISP command line issue.
> But I hope someone can make use/sense of the suggestions above.
> I think it would make the very good CLISP system even better.
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> clisp-list mailing list