all of this started out with the following goal:
it should be _easy_ to ask a live lisp image what's in it, it should be _easy_ to access the associated doc strings and inspect associated "things" like the slots of a class or the symbols in a package. developers should have the option of telling users to inspect the various functions and symbols in a library instead of having to produce api documentation in another form (though that's never a bad idea).
the attached patch changes, rather radically, the inspector. the lisp side now deals with formatting and can create "buttons" (certain pieces of text which when clicked call a lambda). this is used to, among other things, implement a simple method deleter.
currently it has inspectors for: standard-class, standard-generic-function, standard-method, standard-slot-definiton, array, hash-table, package and cons cells (ciruclar lists, proper lists and "regular" cons cells),
features:
- access docstrings associated with classes, slots, generic functions, methods, functions and global variables/constants.
- makunbound, fmakunbound, remove-method from within inspector.
todo:
- lots of custom inspectors (strings, ).
- improve inspection of arrays (in particular it'd be nice to distinguish between strings, vectors, matrixes and other n-dimensional arrays).
- re-implement the list vieweing (don't inspect the entire list at once).
- invent some simple syntax for doc strings which will allow the developer to write "See Also" fields and have those "clikable."
- distinguish between classes, structs.
- types (deftype)
- figure out how to distinguish between a defvar/defparameter and defcontstant symbol.
- figure out how to access non portable system specific "extras"
- compiler-macros. how should this work?
- [not sure about this one] have slime-describe-function go to an inspector buffer, have slime-describe-variable inspect the symbol.
marco mb@bese.it writes:
all of this started out with the following goal:
it should be _easy_ to ask a live lisp image what's in it, it should be _easy_ to access the associated doc strings and inspect associated "things" like the slots of a class or the symbols in a package. developers should have the option of telling users to inspect the various functions and symbols in a library instead of having to produce api documentation in another form (though that's never a bad idea).
the attached patch changes, rather radically, the inspector. the lisp side now deals with formatting and can create "buttons" (certain pieces of text which when clicked call a lambda). this is used to, among other things, implement a simple method deleter.
Great!
todo:
- figure out how to distinguish between a defvar/defparameter and defcontstant symbol.
How about CONSTANTP?
-Peter
Peter Seibel writes:
- figure out how to distinguish between a defvar/defparameter and defcontstant symbol.
This should be implementation dependant.
How about CONSTANTP?
CONSTANTP does not do what you think!
[22]> (defvar x 1) X [23]> (defvar c 1) C [24]> (constantp c) T [25]> (constantp c) T [26]> (constantp 'x) T [27]> (constantp 'x) NIL [28]> (constantp 'c) NIL [29]> (constantp #(1 2 3)) T [30]> (constantp '(1 2 3)) NIL [31]> (constantp (list 1 2 3)) NIL
CONSTANTP could be useful when writting a macro or a compiler macro, but that's about all.
On Mon, 13 Sep 2004 09:14:19 +0200, "Pascal J.Bourguignon" pjb@informatimago.com said:
Pascal> Peter Seibel writes:
- figure out how to distinguish between a defvar/defparameter and defcontstant symbol.
Pascal> This should be implementation dependant.
How about CONSTANTP?
Pascal> CONSTANTP does not do what you think!
Pascal> [22]> (defvar x 1) Pascal> X Pascal> [23]> (defvar c 1) Pascal> C Pascal> [24]> (constantp c) Pascal> T Pascal> [25]> (constantp c) Pascal> T Pascal> [26]> (constantp 'x) Pascal> T Pascal> [27]> (constantp 'x) Pascal> NIL Pascal> [28]> (constantp 'c) Pascal> NIL Pascal> [29]> (constantp #(1 2 3)) Pascal> T Pascal> [30]> (constantp '(1 2 3)) Pascal> NIL Pascal> [31]> (constantp (list 1 2 3)) Pascal> NIL
Pascal> CONSTANTP could be useful when writting a macro or a compiler macro, Pascal> but that's about all.
Is the above really the output from a running Common Lisp, with CONSTANTP returning both T and NIL for the symbol X? Was C supposed to be DEFCONTSTANT?
Maybe you didn't type what you think :-)
__Martin
Martin Simmons writes:
On Mon, 13 Sep 2004 09:14:19 +0200, "Pascal J.Bourguignon" pjb@informatimago.com said:
Pascal> Peter Seibel writes:
- figure out how to distinguish between a defvar/defparameter and defcontstant symbol.
Pascal> This should be implementation dependant.
How about CONSTANTP?
Pascal> CONSTANTP does not do what you think!
Pascal> [22]> (defvar x 1) Pascal> X Pascal> [23]> (defvar c 1) Pascal> C
Ooooops. I thought really very strongly DEFCONSTANT, but I forgot to activate the telephatic module of my computer :-(
[32]> (defconstant c 1) C [33]> (constantp 'c) T [34]> (constantp 'x) NIL
Is the above really the output from a running Common Lisp, with CONSTANTP returning both T and NIL for the symbol X? Was C supposed to be DEFCONTSTANT?
Maybe you didn't type what you think :-)
Indeed. Sorry. So CONSTANTP can be used.
[Sorry, Marco, you're getting this twice, my mail-client doesn't reply to the mailing list by default]
Nice Work!!!
I ported it to acl62, see the attached diff
marco wrote:
features:
access docstrings associated with classes, slots, generic functions, methods, functions and global variables/constants.
makunbound, fmakunbound, remove-method from within inspector.
hm, removing method has one problem though: it doesn't remove the method at point (instead it always removes the last method.)
Also warning when the last normal method (ie. w/o qualifiers) is about to be removed would be nice. (though that's just a minor feature)
Nevertheless, I repeat myself: Nice work!!
todo:
[...]
- invent some simple syntax for doc strings which will allow the developer to write "See Also" fields and have those "clikable."
How about Emacs `foo' style? I already use it in my docs sometimes (if just for the colouring effect) but not so often since ` is quite hard to insert on german keyboards, because it waits for another char being inserted. And in case of a vocal this may becom ì or ù or è. But if it spices up my docs I think I can get used to it ;).
[to Marco only: Also how about some nice (customizable) coloring to indicate what's clickable and what not? But maybe it's already possible and I haven't customized it appropriately. - I just found `slime-inspector-action-face ;) ]
-ts
"Thomas Schilling" tjs_ng@yahoo.de writes:
How about Emacs `foo' style? I already use it in my docs sometimes (if just for the colouring effect) but not so often since ` is quite hard to insert on german keyboards, because it waits for another char being inserted. And in case of a vocal this may becom ì or ù or è. But if it spices up my docs I think I can get used to it ;).
You can use the "nodead" feature of your X Server. On Windows I do not know how this can be accomplished. But perhaps (X)Emacs can be convinced not to use x-compose?
Regards,
On Sun, 12 Sep 2004 22:32:30 +0200, Julian Stecklina der_julian@web.de wrote:
"Thomas Schilling" tjs_ng@yahoo.de writes:
since ` is quite hard to insert on german keyboards, because it waits for another char being inserted.
You can use the "nodead" feature of your X Server. On Windows I do not know how this can be accomplished. But perhaps (X)Emacs can be convinced not to use x-compose?
I've always hated the fact that I can't (or don't know how to) make the ` key a dead key on Windows. If someone here happens to know how to do this please go ahead...
Thanks, Edi.
On 2004-09-13, Edi Weitz edi@agharta.de wrote:
On Sun, 12 Sep 2004 22:32:30 +0200, Julian Stecklina der_julian@web.de wrote:
"Thomas Schilling" tjs_ng@yahoo.de writes:
since ` is quite hard to insert on german keyboards, because it waits for another char being inserted.
You can use the "nodead" feature of your X Server. On Windows I do not know how this can be accomplished. But perhaps (X)Emacs can be convinced not to use x-compose?
I've always hated the fact that I can't (or don't know how to) make the ` key a dead key on Windows. If someone here happens to know how to do this please go ahead...
Well. The belgian keyboard also has deadkeys, that is why I use a us keyboard layout :-).
Seriously, M$ has a utility called " The Microsoft Keyboard Layout Creator" (http://www.microsoft.com/globaldev/tools/msklc.mspx) that should allow you to change your keyboard at will. I would:
- change control/caplock round - change [] with ()
to start off with...
Groetjes, Peter
Am Sun, 12 Sep 2004 21:50:37 +0200 schrieb Thomas Schilling tjs_ng@yahoo.de:
- makunbound, fmakunbound, remove-method from within inspector.
hm, removing method has one problem though: it doesn't remove the method at point (instead it always removes the last method.)
fixed it. Looks like an Allegro bug. (No diff cause I don't know how to diff to your applied patch.)
In
(defmethod inspected-parts ((gf standard-generic-function))
the line
collect `(:action "[remove method]" ,(lambda () (remove-method gf method)))
must be replaced with
collect `(:action "[remove method]" ,(create-method-remover gf method))
and this must be added
(defun create-method-remover (gf m) ;; acl62 didn't treat the inlined lambda correctly (lambda () (remove-method gf m)))
because the inlined closure was modified in each loop. Dunno, if this is a bug or a feature or simply depends on the loop implementation (in which case it would probably also be a bug).
In order to handle unfinalized classes i modified inspected-parts (standard-class) a little bit. See attachment (note: it also is no diff)
Furthermore, we need a method for inspected-parts for cl:structure-class (i simply copied the one for standard-class) and for excl::structure-direct-slot-definition (allegro package), though I don't know how to do this portably. Maybe we can just add it to swank-mop and create a dummy class for all implementations that don't support/need this class.
-ts
"Thomas Schilling" tjs_ng@yahoo.de writes:
because the inlined closure was modified in each loop. Dunno, if this is a bug or a feature or simply depends on the loop implementation (in which case it would probably also be a bug).
no, this is exactly how things should work. closures close over bindings, not values. the "fix" was just to change the lambda to (let ((meth method)) (lambda ... meth ...)), so that a new binding is created for each lambda.
In order to handle unfinalized classes i modified inspected-parts (standard-class) a little bit. See attachment (note: it also is no diff)
thanks. i'm going to commit what i have so far and then take a look at your changes.
Furthermore, we need a method for inspected-parts for cl:structure-class (i simply copied the one for standard-class) and for excl::structure-direct-slot-definition (allegro package), though I don't know how to do this portably. Maybe we can just add it to swank-mop and create a dummy class for all implementations that don't support/need this class.
structs have lots of implementation specific stuff about them. i think it'd be best to just implement (inspected-parts structure-class) in swank-allegro, swank-openmcl, etc.
marco mb@bese.it writes:
thanks. i'm going to commit what i have so far and then take a look at your changes.
i just commited the new inspector. this means that sbcl, openmcl and allegro have access to a better inspector and cmucl, lispworks, clisp and abcl have no inspector at all :(
how to port the inspector in 3 (or 4) easy steps:
1) just cut 'n paste the swank-mop from swank-openmcl.lisp then change the package prefix of the various symbols to point to where ever your implementation exports the mop.
1b) implement swank-mop:slot-definition-documentation
2) implement a method on swank-backend:arglist specialized on function objects.
3) implement swank-backend:function-name.
since we're post 1.0 i figured breaking things like this was ok. should it not be just yell at me, it won't change anything, but you'll feel better. :)
On Mon, 13 Sep 2004 02:03:08 +0200, "Marco Baringer" mb@bese.it said:
Marco> marco mb@bese.it writes:
thanks. i'm going to commit what i have so far and then take a look at your changes.
Marco> i just commited the new inspector. this means that sbcl, openmcl and Marco> allegro have access to a better inspector and cmucl, lispworks, clisp Marco> and abcl have no inspector at all :(
Marco> how to port the inspector in 3 (or 4) easy steps:
Marco> 1) just cut 'n paste the swank-mop from swank-openmcl.lisp then change Marco> the package prefix of the various symbols to point to where ever your Marco> implementation exports the mop.
Marco> 1b) implement swank-mop:slot-definition-documentation
Marco> 2) implement a method on swank-backend:arglist specialized on function Marco> objects.
Marco> 3) implement swank-backend:function-name.
Done for LispWorks.
A couple of questions:
1) Why do you have both a DEFGENERIC and a DEFIMPLEMENTATION for SWANK-BACKEND:INSPECTED-PARTS? Likewise, there are two real definitions of the SWANK-BACKEND:INSPECTED-PARTS method specializing on T. Should it be removed from the backends?
2) Is it necessary to import CL symbols (e.g. METHOD) into SWANK-MOP?
__Martin
Martin Simmons martin@xanalys.com writes:
- Why do you have both a DEFGENERIC and a DEFIMPLEMENTATION for
SWANK-BACKEND:INSPECTED-PARTS? Likewise, there are two real definitions of the SWANK-BACKEND:INSPECTED-PARTS method specializing on T. Should it be removed from the backends?
those are both over sights. i'd just kill the definterface form at this point.
- Is it necessary to import CL symbols (e.g. METHOD) into SWANK-MOP?
no, but at the same time a lot of those symbols aren't neccessary for the functionaliy the inspector offers, it was just easier to cut 'n paste from the MOP spec than to sit down and decide exactly what symbols we use. (this same arugments holds for find-class and class-name).
marco mb@bese.it wrote:
because the inlined closure was modified in each loop. Dunno, if this is a bug or a feature or simply depends on the loop implementation (in which case it would probably also be a bug).
no, this is exactly how things should work. closures close over bindings, not values. the "fix" was just to change the lambda to (let ((meth method)) (lambda ... meth ...)), so that a new binding is created for each lambda.
Yes, that's even shorter. In retrospect I agree that it's no bug (but a feature). I was just assuming that it worked correctly on SBCL and MCL. ;)
structs have lots of implementation specific stuff about them. i think it'd be best to just implement (inspected-parts structure-class) in swank-allegro, swank-openmcl, etc.
I agree.
-ts
"Thomas Schilling" tjs_ng@yahoo.de writes:
In order to handle unfinalized classes i modified inspected-parts (standard-class) a little bit. See attachment (note: it also is no diff)
applied, thanks.
"Thomas Schilling" tjs_ng@yahoo.de writes:
I ported it to acl62, see the attached diff
wow, that was quick. thanks!
hm, removing method has one problem though: it doesn't remove the method at point (instead it always removes the last method.)
fixed.
Also warning when the last normal method (ie. w/o qualifiers) is about to be removed would be nice. (though that's just a minor feature)
currently the actions can't interact with emacs. i'd really like to change this so that, other than this, you could change the values of the inspected objects (by reading and evaling from an emacs minibuffer). however i'm not sure how to actually implement this.
Also how about some nice (customizable) coloring to indicate what's clickable and what not? But maybe it's already possible and I haven't customized it appropriately.
there's a slime-inspector-action-face which defaults to just italics, suggestions welcome (blue maybe?)
I wrote:
[to Marco only: Also how about some nice (customizable) coloring to indicate what's clickable and what not? But maybe it's already possible and I haven't customized it appropriately.
- I just found `slime-inspector-action-face ;) ]
Actually I wanted this modification (could someone please apply):
Index: slime.el =================================================================== RCS file: /project/slime/cvsroot/slime/slime.el,v retrieving revision 1.399 diff -u -r1.399 slime.el --- slime.el 13 Sep 2004 05:36:27 -0000 1.399 +++ slime.el 14 Sep 2004 19:56:37 -0000 @@ -6506,7 +6506,7 @@ (:value (destructuring-bind (string id) (cdr part) (slime-propertize-region `(slime-part-number ,id) - (insert (fontify label string))))) + (insert (fontify value string))))) (:action (destructuring-bind (string id) (cdr part) (slime-propertize-region `(slime-action-number ,id)
todo:
[...]
- distinguish between classes, structs.
At least in acl62:
(typep (find-class 'my-struct) 'standard-class) => NIL (typep (find-class 'my-struct) 'structure-class) => T
Oh, just seeing that there's even no handler for a structure-class. But I guess that's Allegro-specific.
-ts
Added acl62 support for structures and function objects (acl has some strange non-conformance in the implementation of (documentation fn-obj t) )
-ts
"Thomas Schilling" tjs_ng@yahoo.de writes:
Added acl62 support for structures and function objects (acl has some strange non-conformance in the implementation of (documentation fn-obj t) )
applied.
-
Edi Weitz -
Julian Stecklina -
marco -
Marco Baringer
-
Martin Simmons -
Pascal J.Bourguignon -
Peter Seibel -
Peter Van Eynde -
Thomas Schilling