<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Apr 5, 2015 at 3:31 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">Hi,<br>
<br>
1) there is a bug in coerce:<br>
<br>
(coerce #(1 2 3) 'list) => (3 2 1)<br></blockquote><div><br></div><div>This is a known bug in mkcl-1.1.9 (and a few previous minor versions).<br></div><div>Fixed in current git head (future mkcl-1.1.10).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2) what is the status of slime with mkcl? The swank backend which comes<br>
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 about<br>
an integer not being a stream; maybe stream/fd issue?<br>
<br>
15482 is not of type STREAM.<br></blockquote><div><br></div><div>Sounds bad. I'll try to look into it. Do you have a more precise/concise<br></div><div>test case code for this?<br></div><div>(BTW, I usually recompile a whole file at a time since it generates better code<br></div><div>through file scoped optimizations)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
b) trace doesn't seem to work; maybe not a slime issue but a general<br>
mkcl issue?<br></blockquote><div><br></div><div>cl:trace is tied to the bytecode compiler (more or less a.k.a. "the interpreter")<br></div><div>which in turn is currently on the chopping block.<br></div><div>The future of the current cl:trace code is therefore quite bleak.<br></div><div>(It is pretty much a bad piece of legacy that really needs to be redone if you want my opinion.)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I know that there is a slime in the mkcl sources (does it work better<br>
than the latest slime from git?), but it is really inconvenient to<br>
have separate slime just for mkcl.<br></blockquote><div><br></div><div>The code of my adaptation of slime for mkcl (the one in mkcl sources) got<br></div><div>partially pushed into the main slime git repository a few months ago<br></div><div>without my personal involvement, I discovered this situation while reading<br></div><div>the slime release notes. I have yet to audit the merged code and try<br></div><div>to get the missing pieces accepted into the main slime code line.<br></div><div>I'll try to do this for the release of mkcl-1.1.10.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3) I have issues with mkcl:run-program; which somehow returns<br>
<br>
(values #<two-way stream> nil nil)<br></blockquote><div><br></div><div>What is the exact code that produces this result? Somehow I cannot<br></div><div>remember how to get "nil" as second and third value. For my part<br></div><div>I always get a process tracking object as second value and a fixnum<br></div><div>as third value.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
which seems rather odd. I haven't debugged the issue completely yet,<br>
as tracing doesn't seem to work on mkcl:run-program but if i run the<br>
same command from the slime 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></blockquote><div><br></div><div>Again, how do you get "nil" as third value? All I get is a fixnum in that position.<br></div><div>Your exact testcase code?<br><br></div><div>Cheers,<br><br></div><div>Jean-Claude<br> <br></div><div><br></div></div></div></div>