"PA" == Paolo Amoroso amoroso@mclink.it writes:
PA> rpgoldman@real-time.com writes: >> Is there some reason to do this instead of a Bugzilla? Is the latter >> just too much of a pain to maintain?
PA> This was discussed here in the past, but I don't have links handy. I PA> seem to remember that this is because such tools make reporting bugs PA> too much a hassle.
>> Would you consider writing up a McCLIM cliki page describing what you >> do when you play with the lisp listener? This is the only application
PA> I execute this command, which shakes the Listener a bit:
PA> Show Class Subclasses (class) t
PA> Then I walk the file system a bit by clicking on pathnames.
OK, that crashes for me! The problem is that it tries to use a TREE style graph formatting while also setting the merge-duplicates argument to true. When I patched the code to allow actual duplicate merging (AFAICT, this was just ignored before), I made it a violation to have :tree layout and :merge-duplicates = t.
When the lisp-listener crashed, I was wondering if this was The Right Thing or not. Alas, the CLIM specification seems unhelpful and possibly even garbled on this point:
"If the boolean merge-duplicates is true, then duplicate objects in the graph will share the same node in the display of the graph. That is, when merge-duplicates is true, THE RESULTING GRAPH WILL BE A TREE [emphasis added -rpg]. If merge-duplicates is false (the default), then duplicate objects will be displayed in separate nodes. duplicate-key is a function of one argument that is used to extract the node object component used for duplicate comparison; the default is identity. duplicate-test is a function of two arguments that is used to compare two objects to see if they are duplicates; the default is eql. duplicate-key and duplicate-test have dynamic extent."
The material in all caps above seems to be a flat-out mistake --- if you merge duplicates, you can introduce cycles. So it is specifically if merge-duplicates is FALSE that you get a tree, right?
I tried temporarily changing :merge-duplicates to NIL Any reason not to do that?
As far as I can tell
Then when I clicked on an item, the listener crashed for me:
Error: Class #<STANDARD-CLASS CLIM:BOUNDING-RECTANGLE> is not yet finalized. [condition type: PROGRAM-ERROR]
in COM-SHOW-CLASS-SLOTS...
I get a number of meta-object related bugs when I do this. Seems like perhaps ACL's MOP implementation is not particularly happy with the class browser. :-(
I probably don't have too much time to spend on that, alas.
>> As an aside, can anyone point me to a sample application that has some >> pane devoted to displaying information about the state of the >> application (e.g., a filename that is the current document, mode of
PA> Do you mean something like a status bar?
Yes, that sort of thing. Probably one in CLIMACS, I figure. Seems to be one in the clim-listener I could probably copy.
There are two interesting things about the clim-listener "wholine" statusbar:
1. CLIM's layout algorithm seems inadequate --- it seems to require special help to manage the wholine, since there needs to be special compose-space and allocate-space methods. Anyone have any idea why that is? Does this reflect problems with CLIM?
2. Doesn't use incremental redisplay. I would have thought that the wholine, for example, would be a good application for this, since most of the time the user ID won't change, and even the package name is probably pretty stable. Is this because of problems with incremental redisplay? Or is it just that rendering the wholine is so cheap it's not worth the trouble?
Thanks, R