a few issues

[Jean-Claude Beaudoin]

Hello Tomas,

On Sun, Apr 12, 2015 at 5:32 PM, Tomas Hlavaty <tom at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/mkcl-devel/attachments/20150412/1ba17fe4/attachment.html>