This one's from comp.lang.lisp..
Artem Baguinski artm@v2.nl writes:
hi
if i try to load something with defsystem it'll *always* say that compiled files are too old or absent. it refers to correct path of new compiled 10 min ago files though. where should i dig?
Don't know about that part, but..
NB: these are the questions it asks:
; - Binary file /usr/src/lisp/McCLIM/patch.x86f is old or does not exist. ; Compile (and load) source file /usr/src/lisp/McCLIM/patch.lisp instead? ; - Should I bother you if this happens again? ; - Should I compile and load or not?
also, when i'm trying to do that in slime and defsystem asks if i want stuff recompiled i can't seem to be able to answer. i guess slime treats my pressing Return key specially and it never reaches the defsystem. is there a solution to this?
This is a bit tricky.
In general SLIME works with user input. When Lisp tries to read input, a message goes to Emacs saying "I want some user input", and while Lisp is expecting input pressing return in the REPL will do the right thing.
The difficulty here is that defsystem wants to read with a timeout so it is actually _polling_ for input, i.e. most of the time it is not actually trying to read, but is waiting a while before checking if input is available. That means that most of the time Emacs thinks Lisp doesn't want input and so it interprets user input as a REPL expression to be evaluated instead (since our REPL supports issuing commands in parallel).
One solution could be to add some flow-control to the REPL and disable request piplining. Then we would buffer up user input until Lisp tells us whether it wants user input or the next REPL command. Maybe there's a better way.
The workaround for now is to hack defsystem so that it does a blocking read instead of polling. This loses the timeout feature:
(defun mk::read-char-wait (&optional (timeout 20) input-stream (eof-error-p t) eof-value) (declare (ignore timeout)) (read-char input-stream eof-error-p eof-value))
-Luke
"Luke" == Luke Gorrie luke@bluetail.com writes:
Luke> This one's from comp.lang.lisp..
>> also, when i'm trying to do that in slime and defsystem asks if >> i want stuff recompiled i can't seem to be able to answer. i >> guess slime treats my pressing Return key specially and it >> never reaches the defsystem. is there a solution to this?
Luke> This is a bit tricky.
Luke> In general SLIME works with user input. When Lisp tries to Luke> read input, a message goes to Emacs saying "I want some user Luke> input", and while Lisp is expecting input pressing return in Luke> the REPL will do the right thing.
Luke> The difficulty here is that defsystem wants to read with a Luke> timeout so it is actually _polling_ for input, i.e. most of Luke> the time it is not actually trying to read, but is waiting a Luke> while before checking if input is available. That means that Luke> most of the time Emacs thinks Lisp doesn't want input and so Luke> it interprets user input as a REPL expression to be Luke> evaluated instead (since our REPL supports issuing commands Luke> in parallel).
aha, that clarifies the matters. thanks.
Luke> One solution could be to add some flow-control to the REPL Luke> and disable request piplining. Then we would buffer up user Luke> input until Lisp tells us whether it wants user input or the Luke> next REPL command. Maybe there's a better way.
Luke> The workaround for now is to hack defsystem so that it does Luke> a blocking read instead of polling. This loses the timeout Luke> feature:
Luke> (defun mk::read-char-wait (&optional (timeout 20) Luke> input-stream (eof-error-p t) eof-value) (declare (ignore Luke> timeout)) (read-char input-stream eof-error-p eof-value))
i see. how could i add this so that my lisp core has virgin version but slime "overloads" it with this one? is there some ~/.slime-init.lisp sort of thing?
Artem Baguinski artm@v2.nl writes:
i see. how could i add this so that my lisp core has virgin version but slime "overloads" it with this one? is there some ~/.slime-init.lisp sort of thing?
The filename is: ~/.swank.lisp. It is loaded after the rest of the swank code. The connection to Emacs is not yet ready at that time.
Helmut.