<div dir="ltr"><div><div><br></div>Hello Tomas,<br><br></div>Most of your issues should be fixed now in git master head (on github).<br><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 6, 2015 at 2:50 AM, 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">Hi Jean-Claude,<br>
<br>
thanks for your quick reply. I have tried with the latest git commit<br>
7ac4fb07d43418c1b8ce3876584aadb22850b1da again and here are some notes.<br>
<span class=""><br>
Jean-Claude Beaudoin <<a href="mailto:jean.claude.beaudoin@gmail.com">jean.claude.beaudoin@gmail.com</a>> writes:<br>
> On Sun, Apr 5, 2015 at 3:31 PM, Tomas Hlavaty <<a href="mailto:tom@logand.com">tom@logand.com</a>><br>
</span><span class="">> 1) there is a bug in coerce:<br>
><br>
> (coerce #(1 2 3) 'list) => (3 2 1)<br>
><br>
> This is a known bug in mkcl-1.1.9 (and a few previous minor versions).<br>
> Fixed in current git head (future mkcl-1.1.10). <br>
<br>
</span>This now works, thank you!<br>
<span class=""><br>
> 2) what is the status of slime with mkcl? The swank backend which<br>
> comes with the latest slime works except a few things:<br>
><br>
> a) when I recompile a function/macro (C-c C-c), i get an error<br>
> about an integer not being a stream; maybe stream/fd issue?<br>
><br>
> 15482 is not of type STREAM.<br>
><br>
> Sounds bad. I'll try to look into it. Do you have a more precise<br>
</span>> /concise test case code for this? (BTW, I usually recompile a whole<br>
<span class="">> file at a time since it generates better code through file scoped<br>
> optimizations)<br>
<br>
</span>With the latest mkcl, after starting mkcl from slime, i now get<br>
<br>
#<a SWANK/GRAY::SLIME-OUTPUT-STREAM 140431551121664> is not of type STREAM.<br>
[Condition of type TYPE-ERROR]<br>
<br>
Restarts:<br>
0: [ABORT] Abort this computation: (SI:TOP-APPLY #<compiled-closure 7fb8bd2cb3c0>).<br>
1: [TERMINATE-THREAD] Terminate this thread: #<thread "auto-flush-thread" active detached (14806) 0x7fb88b7ae700 7fb8bd5b6000>.<br>
<br>
Backtrace:<br>
0: DEBUG-IN-EMACS<br>
1: LAMBDA, closure generated from INVOKE-SLIME-DEBUGGER<br>
2: LAMBDA, closure generated from INVOKE-SLIME-DEBUGGER<br>
3: CALL-WITH-BINDINGS<br>
4: INVOKE-SLIME-DEBUGGER<br>
5: LAMBDA, closure generated from SWANK-DEBUGGER-HOOK<br>
6: SWANK-DEBUGGER-HOOK<br>
7: AUTO-FLUSH-LOOP<br>
8: LAMBDA, closure generated from OPEN-STREAMS<br>
9: LAMBDA, closure generated from SPAWN<br>
10: NIL<br>
<br>
but after hitting #\q the slime debugger closes and slime works. This<br>
error did not pop up with mkcl 1.1.9 and is new on the HEAD.<br>
<br></blockquote><div><br></div><div>Should be fixed in git head. Not really a new bug, just revealed itself on that occasion...<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Pressing C-c C-c on a function (compile function in slime), I get:<br>
<br>
1462 is not of type STREAM.<br>
[Condition of type TYPE-ERROR]<br>
<br>
Restarts:<br>
0: [ABORT] Abort compilation.<br>
1: [*ABORT] Return to SLIME's top level.<br>
2: [ABORT] Abort this computation: (SI:TOP-APPLY #<compiled-closure 7fb8a4c95d20>).<br>
3: [TERMINATE-THREAD] Terminate this thread: #<thread "worker" active detached (17554) 0x7fb89e70c700 7fb8a460b000>.<br>
<br>
Backtrace:<br>
0: DEBUG-IN-EMACS<br>
1: INVOKE-SLIME-DEBUGGER<br>
2: LAMBDA, closure generated from SWANK-DEBUGGER-HOOK<br>
3: SWANK-DEBUGGER-HOOK<br>
4: LAMBDA, closure generated from SWANK-COMPILE-STRING<br>
5: LAMBDA, closure generated from LAMBDA<br>
6: LAMBDA, closure generated from COLLECT-NOTES<br>
7: MEASURE-TIME-INTERVAL<br>
8: COLLECT-NOTES<br>
9: LAMBDA, closure generated from COMPILE-STRING-FOR-EMACS<br>
10: CALL-WITH-BUFFER-SYNTAX<br>
11: COMPILE-STRING-FOR-EMACS<br>
12: BYTECODE [Evaluation of: ]<br>
13: EVAL-FOR-EMACS<br>
14: LAMBDA, closure generated from LAMBDA<br>
15: CALL-WITH-BINDINGS<br>
16: LAMBDA, closure generated from LAMBDA<br>
17: CALL-WITH-BINDINGS<br>
18: LAMBDA, closure generated from SPAWN-WORKER-THREAD<br>
19: LAMBDA, closure generated from SPAWN<br>
20: NIL<br>
<br>
I usually recompile functions only, as optimisations are not interessant<br>
for me during development and also compiling the whole file via slime<br>
leaves fasls around in the wrong places.<br>
<br>
I am not sure how could I make the test case more precise. Simply hit<br>
C-c C-c on a lisp function when in slime-mode and this will pop up.<br></blockquote><div><br></div><div>Should be fixed in 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>
> b) trace doesn't seem to work; maybe not a slime issue but a<br>
> general mkcl issue?<br>
><br>
> cl:trace is tied to the bytecode compiler (more or less a.k.a. "the<br>
> interpreter") which in turn is currently on the chopping block. The<br>
> future of the current cl:trace code is therefore quite bleak. (It is<br>
> pretty much a bad piece of legacy that really needs to be redone if<br>
> you want my opinion.)<br>
<br>
</span>OK but it is a shame, because cl:trace is one of the most useful<br>
debugging tools in Lisp.<br></blockquote><div><br></div><div>BTW, are you sure you turned off any "trace preventing" optimization<br></div><div>before trying cl:trace? You need to have done the equivalent of<br></div><div>(proclaim '(optimize (debug 3) (safety 3) (speed 1)) before compilation<br></div><div>of any code that you expect to trace through, otherwise there may be<br></div><div>some inlining or "fast-call" done by the compiler that will prevent<br>good use of cl:trace.<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 know that there is a slime in the mkcl sources (does it work<br>
> better than the latest slime from git?), but it is really<br>
> inconvenient to have separate slime just for mkcl.<br>
><br>
> The code of my adaptation of slime for mkcl (the one in mkcl sources)<br>
> got partially pushed into the main slime git repository a few months<br>
> ago without my personal involvement, I discovered this situation while<br>
> reading the slime release notes. I have yet to audit the merged code<br>
> and try to get the missing pieces accepted into the main slime code<br>
> line. I'll try to do this for the release of mkcl-1.1.10. <br>
<br>
</span>I see. That would be great.<br>
<span class=""><br>
> 3) I have issues with mkcl:run-program; which somehow<br>
> returns<br>
><br>
> (values #<two-way stream> nil nil)<br>
><br>
> What is the exact code that produces this result? Somehow I cannot<br>
> remember how to get "nil" as second and third value. For my part I<br>
> always get a process tracking object as second value and a fixnum as<br>
> third value. <br>
><br>
> which seems rather odd. I haven't debugged the issue<br>
> completely yet, as tracing doesn't seem to work on<br>
> mkcl:run-program but if i run the same command from the slime<br>
> repl with multiple-value-list, i get<br>
><br>
> (values #<two-way stream> #<process> nil)<br>
><br>
> Are there known issues with mkcl:run-program?<br>
><br>
> Again, how do you get "nil" as third value? All I get is a<br>
> fixnum in that position.<br>
> Your exact testcase code?<br>
<br>
</span>I think specifying ":wait nil" will get you NIL as third value:<br>
<br>
(multiple-value-list (RUN-PROGRAM "sha1sum" '("/etc/passwd") :INPUT<br>
NIL :OUTPUT :STREAM :ERROR NIL :WAIT NIL :SEARCH T))<br>
<br>
The problem I am seing is that I get nil as the second value. I haven't<br>
identified the issue yet.<br></blockquote><div><br></div><div>I more carefully re-read the code of mkcl:run-program and I can now say that<br></div><div>NIL as third value is indeed a "feature" of asynchronous execution (:wait nil).<br></div><div>But what I cannot understand is NIL as second value of mkcl:run-program;<br></div><div>It should be impossible to get that, ever, by construction.<br></div><div>Do you have an easy way to reproduce that case?<br></div><div> </div>Regards,<br><br></div><div class="gmail_quote">Jean-Claude<br><br></div></div></div></div></div>