> 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:
>>
https://sourceforge.net/tracker/?func=detail&atid=301355&aid=1446245&group_i
>> d=1355
>>
>> 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,
so
>> 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.
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.
Best,
Klaus

DMac <dvmacd <at> yahoo.com> writes:
>
> I am new to Clisp and wanted to see if I could create a simple gui hello
world
> on Windows XP.
>
> >From the FAQ at http://clisp.cons.org/impnotes/faq.html
>
> <Quote>
>
> How do I create a GUI for my CLISP program?
>
> Use module gtk2: create ui.glade with Glade, then do
>
> $ ./configure --with-module=gtk2 --cbc build-gtk
> $ ./build-gtk/clisp -K full -x '(gtk:run-glade-file "ui.glade")'
>
> <\Quote>
>
> I downloaded Glade for Win32.
> I created a ui.glade.
> I opened VisualCLisp and pasted the two code lines into the editor saved and
> attempted to (load "") it.
>
> REPL does not recognize the "$"
>
> Can anyone tell me how to use the gtk2 module in Windows?
>
> Regards,
> DMac
>
I know that the gtk for windows is working on my box.
I got an example to work that used a precursor to the gtk2 module.
I guess the question should have been "how do I load this gtk2 module into my
image?"
CL-USER> *features*
(:ASDF :DIRKEY :REGEXP :SYSCALLS :CLOS :LOOP :COMPILER :CLISP :ANSI-CL
:COMMON-LISP :LISP=CL :INTERPRETER :SOCKETS :GENERIC-STREAMS
:LOGICAL-PATHNAMES :SCREEN :FFI :UNICODE :BASE-CHAR=CHARACTER :PC386 :WIN32)
CL-USER>
I had a look at the repository
http://clisp.cvs.sourceforge.net/clisp/clisp/modules/gtk2
and figured that I needed
gtk.lisp
gtk-server.cfg
I am not sure about the other stuff.
How on windows do I get this into the *features*?
regards,
DMac

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details