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.

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.

>        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.

>        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.