[slime-devel] swank:frame-locals
i would like to make a change to slime which isn't directly related to slime as an emacs lisp IDE but related to slime's (unexpected) use as a generic debugger interface. The function frame-locals currently returns the name and the value of a frame-local as strings, while this is great for emacs it makes it impossible for me[1] to usefully inspect those values in my debugging interface (built on slime but doesn't use emacs). The change i would like to propose is the make swank:frame-locals return, along with :value-string and :name, a :value and :name-value property. is this ok or is it important that slime remain concentrated on being an emacs interface and not a general common lisp implementation abstraction layer? This particular change would be rather trivial but I can see this being the start of a road slime may not want to take. [1] - i'm pretty sure i'm not the only person using slime without emacs, but i can't remeber who it was who said they were also doing this. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen
Marco Baringer <mb@bese.it> writes:
i would like to make a change to slime which isn't directly related to slime as an emacs lisp IDE but related to slime's (unexpected) use as a generic debugger interface.
The function frame-locals currently returns the name and the value of a frame-local as strings, while this is great for emacs it makes it impossible for me[1] to usefully inspect those values in my debugging interface (built on slime but doesn't use emacs). The change i would like to propose is the make swank:frame-locals return, along with :value-string and :name, a :value and :name-value property.
is this ok or is it important that slime remain concentrated on being an emacs interface and not a general common lisp implementation abstraction layer? This particular change would be rather trivial but I can see this being the start of a road slime may not want to take.
I think this is the right direction. The backend functions should use proper objects instead of strings and natural conventions, e.g., return multiple values instead of lists. The conversion to strings should be done in the frontend. E.g., FRAME-LOCALS should return a list of names (symbols) and a list of values. The current :id property is a CMUCLism and can probably be recreated from the list of names. Then we need a function in the front end, say SLDB-FRAME-LOCALS, to convert the values to a list of strings. It might even turn out that this separation removes some duplication in the various backends. Helmut.
On Venerdì, mar 5, 2004, at 14:33 Europe/Rome, Helmut Eller wrote:
I think this is the right direction. The backend functions should use proper objects instead of strings and natural conventions, e.g., return multiple values instead of lists. The conversion to strings should be done in the frontend.
:) i'll commit a patch for this shortly. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen
"Marco" == Marco Baringer <mb@bese.it> writes: [...] Marco> is this ok or is it important that slime remain concentrated on Marco> being an emacs interface and not a general common lisp Marco> implementation abstraction layer? This particular change would Marco> be rather trivial but I can see this being the start of a road Marco> slime may not want to take.
Marco> [1] - i'm pretty sure i'm not the only person using slime Marco> without emacs, but i can't remeber who it was who said they were Marco> also doing this. You are definitely not the only one thinking of using SLIME (or parts of it) as a general-purpose tool. I am thinking of using it for moving some of the stuff I'd normally write in Emacs Lisp into CL. Instead of developing my own (buggy) fancy interface, I can simply use what SLIME offers. --J.
participants (3)
-
Helmut Eller -
Jan Rychter -
Marco Baringer