<div class="gmail_quote">On Tue, Jun 9, 2009 at 6:50 PM, Tobias C. Rittweiler <span dir="ltr"><<a href="mailto:tcr@freebits.de" target="_blank">tcr@freebits.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


<div>Juan Jose Garcia-Ripoll wrote:<br>
<br>
> I was also made aware that using form number is not really useful when<br>
> the code changes the readtable or use #+ or #-. Indeed, this is the<br>
> case in a couple of libraries and should be a major problem debugging<br>
> them.<br>
<br>
</div>Examples? People may have to adapt SWANK:*READTABLE-ALIST*, or<br>
alternatively use named-readtables at<br>
<br>
 <a href="http://common-lisp.net/%7Etrittweiler/darcs/editor-hints/named-readtables/" target="_blank">http://common-lisp.net/~trittweiler/darcs/editor-hints/named-readtables/</a><br>
<div><br>
<br>
> Things are as follows. First, Slime will have to be upgraded to<br>
> understand the environment produced by C functions (basically it<br>
> involves calling si::decode-ihs-env)<br>
<br>
</div>Are the new changes on the debugger and inspector documented? What can<br>
be used to discriminate the current version from what was there before?<br>
<div><br>
<br>
> Second, ECL is being changed to record not the form number, but the<br>
> precise file position at which the form was read. Please understand<br>
> that this is a complicated change -- we might not get it right the<br>
> first time -- since it involves detecting forms that are ignorable<br>
> (#+/- conditionals, comments, etc).<br>
<br>
</div>In my experience, form numbers work better than file positions because<br>
there's somewhat less chance that they turn wrong on interactive<br>
modification of the files.<br>
<br>
Notice, now that you're working on it, that Slime can first go to a<br>
tentative position (computed from form number, or given by file/line<br>
position), and then search for a given snippet in a short region around<br>
that position. The snippet comes from the Lisp implementation, e.g. the<br>
first, say, 128 characters of a toplevel form.<br>
<br>
Notice further, that Slime can cope with form paths. A form path is the<br>
path into the tree that the source of a toplevel form represents. This<br>
way, you can get various highlighting of the actual offending subforms<br>
rather than the whole toplevel form.<br>
<font color="#888888"><br>
  -T.<br>
</font><div><div></div><div><br>
<br>
------------------------------------------------------------------------------<br>
Crystal Reports - New Free Runtime and 30 Day Trial<br>
Check out the new simplified licensing option that enables unlimited<br>
royalty-free distribution of the report engine for externally facing<br>
server and web deployment.<br>
<a href="http://p.sf.net/sfu/businessobjects" target="_blank">http://p.sf.net/sfu/businessobjects</a><br>
_______________________________________________<br>
Ecls-list mailing list<br>
<a href="mailto:Ecls-list@lists.sourceforge.net" target="_blank">Ecls-list@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/ecls-list" target="_blank">https://lists.sourceforge.net/lists/listinfo/ecls-list</a><br>
</div></div></blockquote></div><br>I'd like to thank everyone for their help. <br><br>I finally discovered the problem was Maxima's slightly outdated defsystem.lisp library. I have submitted a patch to the Maxima team.<br>

<br>On a side point. I noticed that ECL does not build correctly on Windows in folders that contain a white space character. Would it be possible to update the documentation to warn other developers attempting to compile ECL on this platform?<br>

<br>