Re: slime

I'll take a look. Is it bleeding edge that I need to build? Tried  
that yesterday (with image from ftp site) but failed when loading ppc- 
callback-support. I've been out of the slime world/openmcl for a  
couple of months and am just starting to take a look again (350  
messages behind, scanned quickly in the last few days) . (BioPAX -  
http://biopax.sourceforge.net/cgi-bin/moin.cgi/ is another hobby)

There are a bunch of slime/debugging related things:

It would be really nice if I could also get frame-supplied-args  
functionality from somewhere that was supported, as well as having  
there be common code that accesses frame local variables so that I  
didn't have to guess when the probably unsupported code that I use  
becomes stale relative to that which is used in more current efforts  
with the ide.

I also have some more recent unreleased code that tries (sometimes  
successfully, sometimes not) to deal with an issue that came up a few  
months ago regarding getting the correct error context in slime's  
multithreaded world. I'll have to page that stuff in and see if  
recent slime changes have made the issue go away.

An earlier note made some reference to my code that associates source  
with compiled code. That's also been hooked up into slime, though not  
in the standard version - you need to download an extra package from  
me. It lets one jump from the backtrace to the form where the error  
occurred, to the extent this is possible given compilation. I can  
also see about making sure this works with the new version. It would  
be helpful if I could leave a few hooks in the released code so that  
I can make a distribution of that doesn't need to redefine any  
internal functions.

There's also code that saves xref info into fasl files, and code that  
uses some heuristics to name anonymous functions. Some of this has  
been discussed on the list in the past. It's all *really useful*, if  
not always implemented in a principled way. :) or :(, depending on  
how you view such things.

There's some recent work by Matthias Koeppe to help presentation  
related information make it through the pretty printer without  
messing up the spacing. He implemented it for CMUCL, I think. Haven't  
looked at the details of how it works, but it might be nice to try to  
get this to work for openmcl.

BTW, I always build a debugging version of MCL that turns on all this  
stuff while building openmcl itself (thought there are sometimes  
bootstrapping issues that have to be dealt with IIRC). I've thought  
for a long time that it would benefit the average user if the  
distribution included two images, one prebuilt for debugging, along  
with the usual build.

I would love to make these debugging-centric tools widely available  
but have hesitated because some of the hooks I use can't easily be  
maintained across updates. On the other hand, if there is some  
interest from y'all in helping me figuring out how to do these things  
in a reasonably supported manner, I can try to put some time into  
this next week, when I am on vacation. Let me know if there is  
interest, and if so, in which features.

-Alan

ps. (off topic, I know) You might give some thought to changing the  
release versioning scheme. 0.14.4 comes off as being a lot more  
preliminary that openmcl really is (it looks too much like 0.1.4.4).  
For me, openmcl has been a 1.x for a long time, and adding ppc64  
support strikes me as a 2.0 beta kind of thing.



On Aug 13, 2005, at 5:51 PM, Gary Byers wrote:


>
>
> On Sat, 13 Aug 2005, bryan o'connor wrote:
>
>
>> the problems seem to arise from the call to
>> swank-backend::maybe-method-location.  removing that
>> from find-definitions seems to work.
>>
>
> SWANK::MAYBE-METHOD-LOCATION calls SWANK::FUNCTION-SOURCE-LOCATION
> which calls CCL::EDIT-DEFINITION-P, which tries (in the DOCUMENTATION
> case) to call CLASS-NAME on an EQL specializer, and that signals
> an error.
>
> When I set *inferior-lisp-program* to a copy of 0.14.3 and run it
> under an unmodified SLIME, I get exactly the same behavior.
>
> If I comment out the call to SWANK::MAYBE-METHOD-LOCATION, doing
> M-. on DOCUMENTATION, I get a buffer full of method forms (the
> CAR of each is the symbol CCL::STANDARD-KERNEL-METHOD).  If I
> click on one of them, Emacs finds ... the wrong method in the
> right source file.  (It seems to jump to the first (DEFMETHOD
> DOCUMENTATION ...) form in the source file.)
>
> I don't use SLIME, so I don't know if this ever worked.   It does  
> appear that CCL::EDIT-DEFINITION-P has had a long-standing
> bug that's worth fixing, though it's not clear to me that
> CCL::EDIT-DEFINITION-P does anything particularly useful (that
> can't be done in other ways.)
>
>
>>
>> maybe it was solving a problem that is no longer
>> present?
>>
>>    ...bryan
>>
>>
>> On Aug 13, 2005, at 1:00 PM, Gary Byers wrote:
>>
>>>> one more thing that we should ensure works properly with
>>>> 0.14.4 is slime.
>>>> the only breakage that i've noticed is slime-edit-definition
>>>> (M-.) with methods.
>>>> adding some missing types (funcallable-standard-class) to the
>>>> etypecase in swank::specializer-name will fix it for some
>>>> methods.  others, like documentation, still don't work.
>>>> i'm not sure if this is strictly a slime problem with 0.14.4
>>>> or something with 0.14.4 itself.
>>>>    ...bryan
>>>>
>>> I'm not sure what would have changed in pre-0.14.4 that would  
>>> have affected
>>> this.
>>> The quasi-standard (not really documented, but it's the basis of  
>>> what
>>> ILISP uses) interface is CCL::%SOURCE-FILES; calling
>>> ? (CCL::%SOURCE-FILES 'DOCUMENTATION)
>>> seems to return essentially the same information in 0.14.3 and in  
>>> the
>>> current bleeding-edge version.
>>> A lot of DOCUMENTATION methods have EQL specializers.  Is that  
>>> significant ?
>>> I'll download SLIME, and see if I can remember how to invoke and  
>>> use it ...
>>>
>>
>> _______________________________________________
>> Bug-openmcl mailing list
>> [email protected]
>> http://clozure.com/mailman/listinfo/bug-openmcl
>>
>>
>>
> _______________________________________________
> Bug-openmcl mailing list
> [email protected]
> http://clozure.com/mailman/listinfo/bug-openmcl
>