#browseDefinitionsOf: includes redundant item - time to panic?

Hello all,

My current image is older than dirt, and so it's long past time to
rebuild.  Today, I noticed that browsing definitions of a particular
method opens a method browser on a lot of correct stuff and to something
that looked like a compilation failure, though it's not one.  It instead
looks like a compiled method that has not be gc'd.  Double-clicking the
offending entry in the method browser opens a CHB on the correct method
with the correct source.  The method browser also includes a separate
line for the "same method" with the correct source; it too leads to a
CHB on the correct method/source.  I hope that makes sense.

My damage control so far includes taking a complete snapshot of
source/image/changes, and all packages (_before_ saving them<g>).  I
plan to load up a few recent backups to see which if any might not
suffer this same problem.

With backups safely in hand, I plan to save packages and build from a
clean image.  As I said, I am long overdue on that regardless of this
incident.

However, could there be a simple explanation for the (mis)behavior?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

>       Today, I noticed that browsing definitions of a particular method
> opens a method browser on a lot of correct stuff and to something that
> looked like a compilation failure, though it's not one.

It could be a method with a munged selector.  Try evaluating the following
and then visually checking at the two Boolean>>asParameter methods in the
ClassBrowser to spot the bad one :-)  Strange (interesting) that the CB
shows both of the methods as having superclass definitions!.

Boolean methodDictionary add: (#'asParameter ' -> (Boolean methodDictionary
at: #asParameter)).

The easiest way to check for something like this would probably be to look
at the classes method dictionary...

YourClass methodDictionary inspect

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Ian,

> It could be a method with a munged selector.  Try evaluating the following
> and then visually checking at the two Boolean>>asParameter methods in the
> ClassBrowser to spot the bad one :-)  Strange (interesting) that the CB
> shows both of the methods as having superclass definitions!.

Interesting idea!  Have you run into this before?  In my case, it
appears that the problem is not not multiple methods, but multiple
copies of the class.  This particular problem appears to have surfaced
two or three weeks ago, though there could naturally be something else
wrong that goes back even further.

Given that I am very close to completing a long overdue rebuild, I think
  I will simply continue with that effort and then attempt to verify
that it didn't "spread" to the new image.  I have backups of the
offending image and some (hopefully!) clean images before it.

Thanks!!!

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> Interesting idea!  Have you run into this before?

Not in that specific way, it was just intended as a demo of something that
can be done.  I have seen _similar_ problems, with screwed up
messageDictionaries, in the past but always caused by me whilst trying to do
"clever" things with the low level image.  I can't recall seeing it in
"normal" use.

I have seen the duplicated classes problem though and I _think_ it can be
caused while loading packages that throw an error.  If you ignore the error
and continue you can end up with two identical classes in the image.  This
is all from a very hazy memory though and may have been fixed in current
Dolphin versions.

I think a rebuild is certainly a better idea than trying to work out what
happened though :-)

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Ian, Bill,

> > Interesting idea!  Have you run into this before?
>
> Not in that specific way, it was just intended as a demo of something that
> can be done.  I have seen _similar_ problems, with screwed up
> messageDictionaries, in the past but always caused by me whilst trying to
> do "clever" things with the low level image.  I can't recall seeing it in
> "normal" use.

I have.  It seems to happen fairly often[*], but it does depend on what
"browse" option you choose.  Some of them (including "browse definitions",
IIRC) start by enumerating all the classes, and go from there, and so avoid the
"problem".  Some of the others (can't remember which) must work differently
(perhaps starting from CompiledMethod allInstances) since they can pick up
methods that are no longer "active".

([*] but /much/ less often that it used to back in D2-3 days)


> I have seen the duplicated classes problem though and I _think_ it can be
> caused while loading packages that throw an error.  If you ignore the
> error and continue you can end up with two identical classes in the
> image.  This is all from a very hazy memory though and may have been
> fixed in current Dolphin versions.

I've seen that twice in the last couple of years, in both cases it seemed to be
the result of attempting to file in stuff (actually via the Chunk Browser, but
it's obviously not the Chunk Browser's fault) which caused errors.
Unfortunately I didn't have time to work out exactly what was going wrong.
(Mainly because I was too busy trying to fix it ;-)

FWIW, it /is/ fixable (after backing-up, of course) by "manually" removing the
extraneous class definition from its superclass's #subclasses collection (and
similarly for the metaclass, but you have to check that the metaclass is
duplicated /too/ -- I seem to remember that it was shared between the two
versions of the instance class).  I agree that just rebuilding the image would
be a better choice than messing around, but in my case I needed to save out the
package first, but was worried that I might end up saving the wrong version of
the class.

    -- chris

Chris,

> I've seen that twice in the last couple of years, in both cases it seemed to be
> the result of attempting to file in stuff (actually via the Chunk Browser, but
> it's obviously not the Chunk Browser's fault) which caused errors.
> Unfortunately I didn't have time to work out exactly what was going wrong.
> (Mainly because I was too busy trying to fix it ;-)

I certainly did a lot of chunk recovery at around the time this appears
to have happened.


> FWIW, it /is/ fixable (after backing-up, of course) by "manually" removing the
> extraneous class definition from its superclass's #subclasses collection (and
> similarly for the metaclass, but you have to check that the metaclass is
> duplicated /too/ -- I seem to remember that it was shared between the two
> versions of the instance class).  I agree that just rebuilding the image would
> be a better choice than messing around, but in my case I needed to save out the
> package first, but was worried that I might end up saving the wrong version of
> the class.

Rebuilding was a good option, largely because it had been _much_ too
long since I did it.  I also got a few things fixed in package scripts,
so it was useful in that regard.  My clean load script is better for it
too.  However, I would not want to retreat as a habit.  Could we write
something that would test for and fix this?  I have a good image on
which to try it :)

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> I certainly did a lot of chunk recovery at around the time this appears to
> have happened.

Which version of the CB are you using?  Version 5l (May 2004) made some
changes to the way that errors during class restorations were handled.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Ian,

> Which version of the CB are you using?  Version 5l (May 2004) made some
> changes to the way that errors during class restorations were handled.

It reports being 5i, but I patched it for the clipboard opening feature.
Is there a published version with that included?

FWIW, I suspect the CB is innocent.  It seems likely that problem was
one of my filtered browsers vs. the SB.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> It reports being 5i, but I patched it for the clipboard opening feature.
> Is there a published version with that included?

Yes, it's in my current version, 5m, which I've uploaded to my web site at

http://www.idb.me.uk/files/cb5m.zip (25K)

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Ian,

>>It reports being 5i, but I patched it for the clipboard opening feature.
>>Is there a published version with that included?
>
>
> Yes, it's in my current version, 5m, which I've uploaded to my web site at
>
> http://www.idb.me.uk/files/cb5m.zip (25K)

It is now installed in my rebuilt image.  I uninstalled 5m, and then
installed the new package.  That gave me a warning about some methods
that were packaged with your diff browser and that might get moved to a
different package.  Should that concern me?

Thanks!!!!

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> It is now installed in my rebuilt image.  I uninstalled 5m, and then
> installed the new package.  That gave me a warning about some methods that
> were packaged with your diff browser and that might get moved to a
> different package.  Should that concern me?

I'm not sure what that could be.  The only connection between the two
packages is that the CB references a class included in the DB package.

To be on the safe side I'll create a new executable containing the current
version of all my goodies and upload it to the web site sometime tomorrow.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

> To be on the safe side I'll create a new executable containing the current
> version of all my goodies and upload it to the web site sometime tomorrow.

OK, version 5k of the goodies is now available on my Dolphin web pages.

http://www.idb.me.uk

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.