Hello Tomas,
Most of your issues should be fixed now in git master head (on github).
On Mon, Apr 6, 2015 at 2:50 AM, Tomas Hlavaty tom@logand.com wrote:
Hi Jean-Claude,
thanks for your quick reply. I have tried with the latest git commit 7ac4fb07d43418c1b8ce3876584aadb22850b1da again and here are some notes.
Jean-Claude Beaudoin jean.claude.beaudoin@gmail.com writes:
On Sun, Apr 5, 2015 at 3:31 PM, Tomas Hlavaty tom@logand.com 1) there is a bug in coerce:
(coerce #(1 2 3) 'list) => (3 2 1)This is a known bug in mkcl-1.1.9 (and a few previous minor versions). Fixed in current git head (future mkcl-1.1.10).
This now works, thank you!
2) what is the status of slime with mkcl? The swank backend which comes with the latest slime works except a few things: a) when I recompile a function/macro (C-c C-c), i get an error about an integer not being a stream; maybe stream/fd issue? 15482 is not of type STREAM.Sounds bad. I'll try to look into it. Do you have a more precise /concise test case code for this? (BTW, I usually recompile a whole file at a time since it generates better code through file scoped optimizations)
With the latest mkcl, after starting mkcl from slime, i now get
#<a SWANK/GRAY::SLIME-OUTPUT-STREAM 140431551121664> is not of type STREAM. [Condition of type TYPE-ERROR]
Restarts: 0: [ABORT] Abort this computation: (SI:TOP-APPLY #<compiled-closure 7fb8bd2cb3c0>). 1: [TERMINATE-THREAD] Terminate this thread: #<thread "auto-flush-thread" active detached (14806) 0x7fb88b7ae700 7fb8bd5b6000>.
Backtrace: 0: DEBUG-IN-EMACS 1: LAMBDA, closure generated from INVOKE-SLIME-DEBUGGER 2: LAMBDA, closure generated from INVOKE-SLIME-DEBUGGER 3: CALL-WITH-BINDINGS 4: INVOKE-SLIME-DEBUGGER 5: LAMBDA, closure generated from SWANK-DEBUGGER-HOOK 6: SWANK-DEBUGGER-HOOK 7: AUTO-FLUSH-LOOP 8: LAMBDA, closure generated from OPEN-STREAMS 9: LAMBDA, closure generated from SPAWN 10: NIL
but after hitting #\q the slime debugger closes and slime works. This error did not pop up with mkcl 1.1.9 and is new on the HEAD.
Should be fixed in git head. Not really a new bug, just revealed itself on that occasion...
Pressing C-c C-c on a function (compile function in slime), I get:
1462 is not of type STREAM. [Condition of type TYPE-ERROR]
Restarts: 0: [ABORT] Abort compilation. 1: [*ABORT] Return to SLIME's top level. 2: [ABORT] Abort this computation: (SI:TOP-APPLY #<compiled-closure 7fb8a4c95d20>). 3: [TERMINATE-THREAD] Terminate this thread: #<thread "worker" active detached (17554) 0x7fb89e70c700 7fb8a460b000>.
Backtrace: 0: DEBUG-IN-EMACS 1: INVOKE-SLIME-DEBUGGER 2: LAMBDA, closure generated from SWANK-DEBUGGER-HOOK 3: SWANK-DEBUGGER-HOOK 4: LAMBDA, closure generated from SWANK-COMPILE-STRING 5: LAMBDA, closure generated from LAMBDA 6: LAMBDA, closure generated from COLLECT-NOTES 7: MEASURE-TIME-INTERVAL 8: COLLECT-NOTES 9: LAMBDA, closure generated from COMPILE-STRING-FOR-EMACS 10: CALL-WITH-BUFFER-SYNTAX 11: COMPILE-STRING-FOR-EMACS 12: BYTECODE [Evaluation of: ] 13: EVAL-FOR-EMACS 14: LAMBDA, closure generated from LAMBDA 15: CALL-WITH-BINDINGS 16: LAMBDA, closure generated from LAMBDA 17: CALL-WITH-BINDINGS 18: LAMBDA, closure generated from SPAWN-WORKER-THREAD 19: LAMBDA, closure generated from SPAWN 20: NIL
I usually recompile functions only, as optimisations are not interessant for me during development and also compiling the whole file via slime leaves fasls around in the wrong places.
I am not sure how could I make the test case more precise. Simply hit C-c C-c on a lisp function when in slime-mode and this will pop up.
Should be fixed in git head.
b) trace doesn't seem to work; maybe not a slime issue but a general mkcl issue?cl:trace is tied to the bytecode compiler (more or less a.k.a. "the interpreter") which in turn is currently on the chopping block. The future of the current cl:trace code is therefore quite bleak. (It is pretty much a bad piece of legacy that really needs to be redone if you want my opinion.)
OK but it is a shame, because cl:trace is one of the most useful debugging tools in Lisp.
BTW, are you sure you turned off any "trace preventing" optimization before trying cl:trace? You need to have done the equivalent of (proclaim '(optimize (debug 3) (safety 3) (speed 1)) before compilation of any code that you expect to trace through, otherwise there may be some inlining or "fast-call" done by the compiler that will prevent good use of cl:trace.
I know that there is a slime in the mkcl sources (does it work better than the latest slime from git?), but it is really inconvenient to have separate slime just for mkcl.The code of my adaptation of slime for mkcl (the one in mkcl sources) got partially pushed into the main slime git repository a few months ago without my personal involvement, I discovered this situation while reading the slime release notes. I have yet to audit the merged code and try to get the missing pieces accepted into the main slime code line. I'll try to do this for the release of mkcl-1.1.10.
I see. That would be great.
3) I have issues with mkcl:run-program; which somehow returns (values #<two-way stream> nil nil)What is the exact code that produces this result? Somehow I cannot remember how to get "nil" as second and third value. For my part I always get a process tracking object as second value and a fixnum as third value.
which seems rather odd. I haven't debugged the issue completely yet, as tracing doesn't seem to work on mkcl:run-program but if i run the same command from the slime repl with multiple-value-list, i get (values #<two-way stream> #<process> nil) Are there known issues with mkcl:run-program?Again, how do you get "nil" as third value? All I get is a fixnum in that position. Your exact testcase code?
I think specifying ":wait nil" will get you NIL as third value:
(multiple-value-list (RUN-PROGRAM "sha1sum" '("/etc/passwd") :INPUT NIL :OUTPUT :STREAM :ERROR NIL :WAIT NIL :SEARCH T))
The problem I am seing is that I get nil as the second value. I haven't identified the issue yet.
I more carefully re-read the code of mkcl:run-program and I can now say that NIL as third value is indeed a "feature" of asynchronous execution (:wait nil). But what I cannot understand is NIL as second value of mkcl:run-program; It should be impossible to get that, ever, by construction. Do you have an easy way to reproduce that case?
Regards,
Jean-Claude
Hi Jean-Claude,
Most of your issues should be fixed now in git master head (on github).
thanks a lot!
#<a SWANK/GRAY::SLIME-OUTPUT-STREAM 140431551121664> is not of type STREAM. [Condition of type TYPE-ERROR]Should be fixed in git head. Not really a new bug, just revealed itself on that occasion...
I confirm that this is now fixed.
Pressing C-c C-c on a function (compile function in slime), I get: 1462 is not of type STREAM. [Condition of type TYPE-ERROR]Should be fixed in git head.
I still get this error.
BTW, are you sure you turned off any "trace preventing" optimization before trying cl:trace? You need to have done the equivalent of (proclaim '(optimize (debug 3) (safety 3) (speed 1)) before compilation of any code that you expect to trace through, otherwise there may be some inlining or "fast-call" done by the compiler that will prevent good use of cl:trace.
This seem to do something, but not always. I haven't identified the problem yet.
I more carefully re-read the code of mkcl:run-program and I can now say that NIL as third value is indeed a "feature" of asynchronous execution (:wait nil). But what I cannot understand is NIL as second value of mkcl:run-program; It should be impossible to get that, ever, by construction. Do you have an easy way to reproduce that case?
I suspect that is has something to do with optimisation settings.
CL-USER> (compile-file "/tmp/bug.lisp") #P"/tmp/bug.fas" NIL NIL CL-USER> (load "/tmp/bug.fas") #P"/tmp/bug.fas" CL-USER> (funcall (bug::foo nil :stream "sha1sum" '("/etc/passwd"))) #<two-way stream 7f86ff69abe0> NIL NIL CL-USER> (proclaim '(optimize (debug 3) (safety 3) (speed 1))) NIL CL-USER> (compile-file "/tmp/bug.lisp") #P"/tmp/bug.fas" NIL NIL CL-USER> (load "/tmp/bug.fas") #P"/tmp/bug.fas" CL-USER> (funcall (bug::foo nil :stream "sha1sum" '("/etc/passwd"))) #<two-way stream 7f86ffaaa460> #<process "sha1sum" 7f86ff8e31e0> NIL CL-USER>
where /tmp/bug.lisp is
(defpackage :bug (:use :cl))
(in-package :bug)
(defun foo (input output cmd args) (multiple-value-bind (io p x) (mkcl:run-program cmd args :input input :output output :error nil :wait (not (or input output)) :search t) (lambda () (values io p x))))
Without doing anything special, I get the second value NIL (unless entered via slime repl). After (proclaim '(optimize (debug 3) (safety 3) (speed 1)), I haven't seen this issue.
One more question: is there something like octets-to-string and string-to-octets functions?
Thank you,
Tomas
Hello Tomas,
On Sun, Apr 12, 2015 at 5:32 PM, Tomas Hlavaty tom@logand.com wrote:
Pressing C-c C-c on a function (compile function in slime), I get: 1462 is not of type STREAM. [Condition of type TYPE-ERROR]Should be fixed in git head.
I still get this error.
You are most probably still using some other version of slime instead of the one provided by latest mkcl git master head (the one I just fixed). Please have a look at this commit https://github.com/jcbeaudoin/MKCL/commit/64c3770ad9ce12fbadc3b24bffef43653e66aab5, and remove the corresponding call to #'cl:file-position in the version you currently use. I still need to push this to slime git head...
BTW, are you sure you turned off any "trace preventing" optimization before trying cl:trace? You need to have done the equivalent of (proclaim '(optimize (debug 3) (safety 3) (speed 1)) before compilation of any code that you expect to trace through, otherwise there may be some inlining or "fast-call" done by the compiler that will prevent good use of cl:trace.
This seem to do something, but not always. I haven't identified the problem yet.
I will need much more detailed and precise information here if you want me to help you further on this.
I more carefully re-read the code of mkcl:run-program and I can now say that NIL as third value is indeed a "feature" of asynchronous execution (:wait nil). But what I cannot understand is NIL as second value of mkcl:run-program; It should be impossible to get that, ever, by construction. Do you have an easy way to reproduce that case?
I suspect that is has something to do with optimisation settings.
CL-USER> (compile-file "/tmp/bug.lisp") #P"/tmp/bug.fas" NIL NIL CL-USER> (load "/tmp/bug.fas") #P"/tmp/bug.fas" CL-USER> (funcall (bug::foo nil :stream "sha1sum" '("/etc/passwd"))) #<two-way stream 7f86ff69abe0> NIL NIL CL-USER> (proclaim '(optimize (debug 3) (safety 3) (speed 1))) NIL CL-USER> (compile-file "/tmp/bug.lisp") #P"/tmp/bug.fas" NIL NIL CL-USER> (load "/tmp/bug.fas") #P"/tmp/bug.fas" CL-USER> (funcall (bug::foo nil :stream "sha1sum" '("/etc/passwd"))) #<two-way stream 7f86ffaaa460> #<process "sha1sum" 7f86ff8e31e0> NIL CL-USER>
where /tmp/bug.lisp is
(defpackage :bug (:use :cl))
(in-package :bug)
(defun foo (input output cmd args) (multiple-value-bind (io p x) (mkcl:run-program cmd args :input input :output output :error nil :wait (not (or input output)) :search t) (lambda () (values io p x))))
Without doing anything special, I get the second value NIL (unless entered via slime repl). After (proclaim '(optimize (debug 3) (safety 3) (speed 1)), I haven't seen this issue.
I can reproduce the problem now, thank you very much. It is a bug in the code generated by the "Lisp to C" compiler for form "multiple-value-bind" (and probably also multiple-value-setq) but only when (optimize (debug 2)) is in effect. Any other value of "debug" makes the problem disappear. Your slime setup has most probably changed the effective global "debug" value through some call to #'cl:proclaim at some point. (BTW, the effective global "debug" value is stored in si::*debug*)
I am working on a fix for the bug...
One more question: is there something like octets-to-string and string-to-octets functions?
Not in their general form but there is an MKCL equivalent for the most useful encoding special case (utf8). Have a look at string-to-utf8 and utf8-to-string in swank-mkcl.lisp.
Hi Jean-Claude,
Jean-Claude Beaudoin jean.claude.beaudoin@gmail.com writes:
> 1462 is not of type STREAM. > [Condition of type TYPE-ERROR] > > Should be fixed in git head. I still get this error.You are most probably still using some other version of slime instead of the one provided by latest mkcl git master head (the one I just fixed). Please have a look at this commit, and remove the corresponding call to #'cl:file-position in the version you currently use. I still need to push this to slime git head...
yes, I do not use the mkcl slime so I missed this fix. Would be great if your changes make it into the official slime. Thank you for fixing these issues!
> BTW, are you sure you turned off any "trace preventing" optimization > before trying cl:trace? You need to have done the equivalent of > (proclaim '(optimize (debug 3) (safety 3) (speed 1)) before > compilation of any code that you expect to trace through, otherwise > there may be some inlining or "fast-call" done by the compiler that > will prevent good use of cl:trace. This seem to do something, but not always. I haven't identified the problem yet.I will need much more detailed and precise information here if you want me to help you further on this.
Yeah, I know. I have tried to make sense of it, but still have not found a pattern which I could report as a test case. When I know more, I will let you know.
I can reproduce the problem now, thank you very much. It is a bug in the code generated by the "Lisp to C" compiler for form "multiple-value-bind" (and probably also multiple-value-setq) but only when (optimize (debug 2)) is in effect. Any other value of "debug" makes the problem disappear. Your slime setup has most probably changed the effective global "debug" value through some call to #'cl:proclaim at some point. (BTW, the effective global "debug" value is stored in si::*debug*)
I am working on a fix for the bug...
Great!
One more question: is there something like octets-to-string and string-to-octets functions?Not in their general form but there is an MKCL equivalent for the most useful encoding special case (utf8). Have a look at string-to-utf8 and utf8-to-string in swank-mkcl.lisp.
Thank you for pointers, I will have a look.
Best Regards,
Tomas
On Mon, Apr 13, 2015 at 12:18 AM, Tomas Hlavaty tom@logand.com wrote:
Jean-Claude Beaudoin jean.claude.beaudoin@gmail.com writes:
I can reproduce the problem now, thank you very much. It is a bug in the code generated by the "Lisp to C" compiler for form "multiple-value-bind" (and probably also multiple-value-setq) but only when (optimize (debug 2)) is in effect. Any other value of "debug" makes the problem disappear. Your slime setup has most probably changed the effective global "debug" value through some call to #'cl:proclaim at some point. (BTW, the effective global "debug" value is stored in si::*debug*)
I am working on a fix for the bug...
Great!
The fix for this bug is now in github repo master head. Could you please confirm that it does work for you?
Thanks,
JCB
Hi Jean-Claude,
Jean-Claude Beaudoin jean.claude.beaudoin@gmail.com writes:
On Mon, Apr 13, 2015 at 12:18 AM, Tomas Hlavaty tom@logand.com wrote: Jean-Claude Beaudoin jean.claude.beaudoin@gmail.com writes: > I can reproduce the problem now, thank you very much. It is a bug in > the code generated by the "Lisp to C" compiler for form > "multiple-value-bind" (and probably also multiple-value-setq) but only > when (optimize (debug 2)) is in effect. Any other value of "debug" > makes the problem disappear. Your slime setup has most probably > changed the effective global "debug" value through some call to > #'cl:proclaim at some point. (BTW, the effective global "debug" value > is stored in si::*debug*) > > I am working on a fix for the bug...
Great!The fix for this bug is now in github repo master head. Could you please confirm that it does work for you?
It works now. Thank you very much!
Tomas
-
Jean-Claude Beaudoin -
Tomas Hlavaty