From: Sam S. <sd...@gn...> - 2008-11-09 18:41:29
|
Hi Bruno et al The historical behavior of CLISP wrt repeated (SAVEINITMEM :INIT-FUNCTION) has been to stack :INIT-FUNCTIONs: $ ./clisp -q -norc -x '(saveinitmem "1" :init-function (lambda () (print 1)))' $ ./clisp -M 1.mem -q -norc -x '(saveinitmem "2" :init-function (lambda () (print 2)))' $ ./clisp -M 2.mem -q -norc 2 1 [1]> I.e., successively saved images invoke all the INIT-FUNCTIONs from the previous images. What is the rationale? Does anyone use this feature? I find that this feature makes it hard to recover the original CLISP REPL without accessing the internal SYS package: (saveinitmem "orig" :init-function #'sys::main-loop) -- Sam Steingold (http://sds.podval.org/) on Ubuntu 8.04 (hardy) http://thereligionofpeace.com http://memri.org http://palestinefacts.org http://jihadwatch.org http://camera.org http://pmw.org.il All generalizations are wrong. Including this. |
From: Bruno H. <br...@cl...> - 2008-11-09 21:55:13
|
Sam Steingold wrote: > The historical behavior of CLISP wrt repeated (SAVEINITMEM > :INIT-FUNCTION) has been to stack :INIT-FUNCTIONs: > > $ ./clisp -q -norc -x '(saveinitmem "1" :init-function (lambda () (print 1)))' > $ ./clisp -M 1.mem -q -norc -x '(saveinitmem "2" :init-function (lambda () (print 2)))' > $ ./clisp -M 2.mem -q -norc > > 2 > 1 > [1]> > > I.e., successively saved images invoke all the INIT-FUNCTIONs from the > previous images. This is not wrong, is it? The idea of the :init-function is that 1) When you specify it, it takes control regardless what the :init-function of the previous image was. 2) When you don't specify it, the previous :init-function takes control. What you are observing is the behaviour when the init-function terminates after doing some initializations, without taking control. It is indeed a bit surprising then that the initializations are being done in "opposite" order of what one would expect. But this is not the main use-case. The main case is 1) above. > I find that this feature makes it hard to recover the original CLISP > REPL without accessing the internal SYS package: > (saveinitmem "orig" :init-function #'sys::main-loop) You're right. The default value of a public API should be public. It'd be good to make #'sys::main-loop public (either as a function, or as a constant, I don't mind.) Bruno |
From: Sam S. <sd...@gn...> - 2008-11-09 22:28:52
|
> * Bruno Haible <oe...@py...t> [2008-11-09 22:43:54 +0100]: > > Sam Steingold wrote: > >> I find that this feature makes it hard to recover the original CLISP >> REPL without accessing the internal SYS package: >> (saveinitmem "orig" :init-function #'sys::main-loop) > > You're right. The default value of a public API should be public. It'd > be good to make #'sys::main-loop public (either as a function, or as a > constant, I don't mind.) I made as explicit :INIT-FUNCTION NIL argument reset *DRIVER* to SYS::MAIN-LOOP. I think this is better than exposing MAIN-LOOP because it is counter-intuitive for an INIT-function to be called main-LOOP, while :INIT-FUNCTION NIL clearly means that there is no init, just the REPL. -- Sam Steingold (http://sds.podval.org/) on Ubuntu 8.04 (hardy) http://pmw.org.il http://dhimmi.com http://memri.org http://truepeace.org http://israelunderattack.slide.com http://openvotingconsortium.org To understand recursion, one has to understand recursion first. |
From: Bruno H. <br...@cl...> - 2008-11-09 22:56:32
|
Sam Steingold wrote: > > The default value of a public API should be public. It'd > > be good to make #'sys::main-loop public (either as a function, or as a > > constant, I don't mind.) > > I made as explicit :INIT-FUNCTION NIL argument reset *DRIVER* to > SYS::MAIN-LOOP. > I think this is better than exposing MAIN-LOOP because it is > counter-intuitive for an INIT-function to be called main-LOOP, > while :INIT-FUNCTION NIL clearly means that there is no init, just the REPL. What if the user wants an init function which does some initialization and then starts a REPL? :init-function (lambda () (my-init) (...what comes here??...)) Therefore I think we need to make the MAIN-LOOP function public. You are certainly right about the name. How about (defun ext:standard-read-eval-print-loop () (sys::main-loop)) or (defconstant ext:+standard-read-eval-print-loop+ #'sys::main-loop) ? Bruno |
From: Sam S. <sd...@gn...> - 2008-11-10 01:16:12
|
> * Bruno Haible <oe...@py...t> [2008-11-09 23:56:24 +0100]: > > Sam Steingold wrote: >> > The default value of a public API should be public. It'd >> > be good to make #'sys::main-loop public (either as a function, or as a >> > constant, I don't mind.) >> >> I made as explicit :INIT-FUNCTION NIL argument reset *DRIVER* to >> SYS::MAIN-LOOP. >> I think this is better than exposing MAIN-LOOP because it is >> counter-intuitive for an INIT-function to be called main-LOOP, >> while :INIT-FUNCTION NIL clearly means that there is no init, just the REPL. > > What if the user wants an init function which does some initialization > and then starts a REPL? > > :init-function (lambda () (my-init) (...what comes here??...)) in that case one can do it in two easy steps: 1. use :INIT-FUNCTION NIL to create a pristine CLISP REPL image 2. use :INIT-FUNCTION #'MY-INIT on that image to get what you are asking > Therefore I think we need to make the MAIN-LOOP function public. You are > certainly right about the name. How about > (defun ext:standard-read-eval-print-loop () (sys::main-loop)) > or > (defconstant ext:+standard-read-eval-print-loop+ #'sys::main-loop) > ? this looks like some extra complexity for a marginal win. let us not get carried away: most normal CLISP users have access to normal CLISP REPL images - either in their distribution or they build them themselves. this :INIT-FUNCTION NIL trick is for those people who have been given a CLISP-based application and who want to get a normal CLISP REPL out of it. I think these people are now well served. -- Sam Steingold (http://sds.podval.org/) on Ubuntu 8.04 (hardy) http://memri.org http://jihadwatch.org http://truepeace.org http://israelunderattack.slide.com http://palestinefacts.org http://camera.org Takeoffs are optional. Landings are mandatory. |
From: Bruno H. <br...@cl...> - 2008-11-10 02:44:58
|
Sam Steingold wrote: > > :init-function (lambda () (my-init) (...what comes here??...)) > > in that case one can do it in two easy steps: > > 1. use :INIT-FUNCTION NIL to create a pristine CLISP REPL image > > 2. use :INIT-FUNCTION #'MY-INIT on that image to get what you are asking > ,,, > > this looks like some extra complexity for a marginal win. Indeed. I didn't realize this is only a corner case. Bruno |
From: Hoehle, Joerg-C. <Joe...@t-...> - 2008-12-02 16:59:55
|
Hi, Sam Steingold wrote: > The historical behavior of CLISP wrt repeated (SAVEINITMEM > :INIT-FUNCTION) has been to stack :INIT-FUNCTIONs >> What if the user wants an init function which does some initialization >> and then starts a REPL? >in that case one can do it in two easy steps: >1. use :INIT-FUNCTION NIL to create a pristine CLISP REPL image >2. use :INIT-FUNCTION #'MY-INIT on that image to get what you > are asking Incidentally, does the above mean that a sequence of lisp.run -M foo1.mem ... savemem "foo2" lisp.run -M foo2.mem ... savemem "foo3" lisp.run -M foo3.mem ... savemem "foo4" piles up a series of loop drivers on the stack? What means does the user have to notice it? Just curious, Jorg. |
From: Sam S. <sd...@gn...> - 2008-12-02 17:21:21
|
Hi, Hoehle, Joerg-Cyril wrote: > Sam Steingold wrote: >> The historical behavior of CLISP wrt repeated (SAVEINITMEM >> :INIT-FUNCTION) has been to stack :INIT-FUNCTIONs >>> What if the user wants an init function which does some initialization >>> and then starts a REPL? >> in that case one can do it in two easy steps: >> 1. use :INIT-FUNCTION NIL to create a pristine CLISP REPL image >> 2. use :INIT-FUNCTION #'MY-INIT on that image to get what you >> are asking > > Incidentally, does the above mean that a sequence of > lisp.run -M foo1.mem ... savemem "foo2" > lisp.run -M foo2.mem ... savemem "foo3" > lisp.run -M foo3.mem ... savemem "foo4" > piles up a series of loop drivers on the stack? no. you can see that using (ext:show-stack) |