<div dir="ltr">Hello Tomas,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 12, 2015 at 5:32 PM, Tomas Hlavaty <span dir="ltr"><<a href="mailto:tom@logand.com" target="_blank">tom@logand.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> Pressing C-c C-c on a function (compile function in slime),<br>
> I get:<br>
><br>
> 1462 is not of type STREAM.<br>
> [Condition of type TYPE-ERROR]<br>
><br>
</span><span class="">> Should be fixed in git head.<br>
<br>
</span>I still get this error.<br></blockquote><div><br></div><div>You are most probably still using some other version of slime instead<br></div><div>of the one provided by latest mkcl git master head (the one I just fixed).<br></div><div>Please have a look at <a href="https://github.com/jcbeaudoin/MKCL/commit/64c3770ad9ce12fbadc3b24bffef43653e66aab5">this commit</a>, and remove the corresponding call<br></div><div>to #'cl:file-position in the version you currently use. I still need to push<br></div><div>this to slime git head...<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> BTW, are you sure you turned off any "trace preventing" optimization<br>
> before trying cl:trace? You need to have done the equivalent of<br>
> (proclaim '(optimize (debug 3) (safety 3) (speed 1)) before<br>
> compilation of any code that you expect to trace through, otherwise<br>
> there may be some inlining or "fast-call" done by the compiler that<br>
> will prevent good use of cl:trace.<br>
<br>
</span>This seem to do something, but not always. I haven't identified the<br>
problem yet.<br></blockquote><div><br></div><div>I will need much more detailed and precise information here if you<br></div><div>want me to help you further on this.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> I more carefully re-read the code of mkcl:run-program and I can now<br>
> say that NIL as third value is indeed a "feature" of asynchronous<br>
> execution (:wait nil). But what I cannot understand is NIL as second<br>
> value of mkcl:run-program; It should be impossible to get that, ever,<br>
> by construction. Do you have an easy way to reproduce that case?<br>
<br>
</span>I suspect that is has something to do with optimisation settings.<br>
<br>
CL-USER> (compile-file "/tmp/bug.lisp")<br>
#P"/tmp/bug.fas"<br>
NIL<br>
NIL<br>
CL-USER> (load "/tmp/bug.fas")<br>
#P"/tmp/bug.fas"<br>
CL-USER> (funcall (bug::foo nil :stream "sha1sum" '("/etc/passwd")))<br>
#<two-way stream 7f86ff69abe0><br>
NIL<br>
NIL<br>
CL-USER> (proclaim '(optimize (debug 3) (safety 3) (speed 1)))<br>
NIL<br>
CL-USER> (compile-file "/tmp/bug.lisp")<br>
#P"/tmp/bug.fas"<br>
NIL<br>
NIL<br>
CL-USER> (load "/tmp/bug.fas")<br>
#P"/tmp/bug.fas"<br>
CL-USER> (funcall (bug::foo nil :stream "sha1sum" '("/etc/passwd")))<br>
#<two-way stream 7f86ffaaa460><br>
#<process "sha1sum" 7f86ff8e31e0><br>
NIL<br>
CL-USER><br>
<br>
where /tmp/bug.lisp is<br>
<br>
(defpackage :bug<br>
(:use :cl))<br>
<br>
(in-package :bug)<br>
<br>
(defun foo (input output cmd args)<br>
(multiple-value-bind (io p x)<br>
(mkcl:run-program cmd<br>
args<br>
:input input<br>
:output output<br>
:error nil<br>
:wait (not (or input output))<br>
:search t)<br>
(lambda () (values io p x))))<br>
<br>
Without doing anything special, I get the second value NIL (unless<br>
entered via slime repl). After (proclaim '(optimize (debug 3) (safety<br>
3) (speed 1)), I haven't seen this issue.<br></blockquote><div><br></div><div>I can reproduce the problem now, thank you very much.<br></div><div>It is a bug in the code generated by the "Lisp to C" compiler for<br></div><div>form "multiple-value-bind" (and probably also multiple-value-setq)<br></div><div>but only when (optimize (debug 2)) is in effect. Any other value<br></div><div>of "debug" makes the problem disappear. Your slime setup has<br></div><div>most probably changed the effective global "debug" value<br></div><div>through some call to #'cl:proclaim at some point.<br></div><div>(BTW, the effective global "debug" value is stored in si::*debug*)<br><br></div><div>I am working on a fix for the bug...<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
One more question: is there something like octets-to-string and<br>
string-to-octets functions?<br></blockquote><div><br></div><div>Not in their general form but there is an MKCL equivalent for<br></div><div>the most useful encoding special case (utf8). Have a look at<br></div><div>string-to-utf8 and utf8-to-string in swank-mkcl.lisp.<br></div><div> </div><br></div></div></div></div>