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(a)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(a)gmail.com> writes:
> > On Sun, Apr 5, 2015 at 3:31 PM, Tomas Hlavaty <tom(a)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
