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.