[3.9] Invisible method, missing changeset, backporting?

I just downloaded 3.9a-7013 to have a look at Adrian's MC speed-up  
that Marcus put into 3.9a - thanks for finding this :)

However, when browsing around, it's a bit hard to follow what changed  
how, and there are some inconsistencies:

- the speed-up comes from the new category/basicCategory in Class
- introduced in 7012updateFromMC, which loaded ScriptLoader-md.153,  
which resulted in changeset MC36 (*).
- however, Class>>category and Class>>category: are not in that (nor  
any) changeset
- more worryingly, Class>>category: is invisible in the  
SystemBrowser, because it is not in any method category.
- it might be a good idea to run a consistency check on the whole  
system to make sure all methods in the method dicts are also categorized
- there is no history on Class>>category, is that because it moved  
from ClassDescription (where it was in 3.8)?

What would be needed to backport this speed-up to 3.8(.1)? How did  
this change get into the system? Why wasn't it recorded in a changeset?

- Bert -

(*) I added a MCVersionLoader>>loadWithNameLike: method in Monticello-
bf.279.mcz (http://source.impara.de/mc.html) which could be used to  
have a more meaningful name than "MC36"

Hi Bert,

indeed, there is something strange going on when loading the two  
packages (Traits-al.214 and Kernel-al.109). Thanks for pointing that  
out.

On Mar 20, 2006, at 12:05 , Bert Freudenberg wrote:

[...]

> What would be needed to backport this speed-up to 3.8(.1)? How did  
> this change get into the system? Why wasn't it recorded in a  
> changeset?


The change is quite simple, for pre 3.9, the attached changeset  
should work (note, #category: duplicates the implementation in  
ClassDescription, hence should probably be removed there).

The actual trick is to implement #category as follows in Class:

category
        category ifNotNil: [
                ((SystemOrganization listAtCategoryNamed: category) includes: self  
name)
                        ifTrue: [ ^category ] ].
        category := super category.
        ^category

It uses the ivar as a cache to make a guess (which is quite fast) and  
only falls back to the old, slow behavior of looking through the  
whole system category list if this fails.

The change in 3.9 does the same but also for the class Trait. To do  
this, there is a trait that is shared between Class and Trait. Latter  
additionally has a new ivar (Class had this already defined, but was  
not used, why?).


HTH,
Adrian

Am 20.03.2006 um 16:25 schrieb Adrian Lienhard:
>
> The change is quite simple, for pre 3.9, the attached changeset  
> should work (note, #category: duplicates the implementation in  
> ClassDescription, hence should probably be removed there).

Better not - who knows who patched that in 3.8 ;-)
No idea ... maybe the environments work needed it?

Interestingly, in my 3.8 image there are a handful of classes having  
that inst var set:

        Class allSubInstances select: [:ea | (ea instVarNamed: #category)  
notNil]

        (CodeHolder Environment InflateStream ClassDescription Class  
MarqueeMorph FishEyeMorph FatBitsPaint ColorPickerMorph TextStyle  
DigitalSignatureAlgorithm SecureHashAlgorithm ThirtyTwoBitRegister)

> <categoryspeedup.cs>

In Class>>category:, shouldn't the category be stored as Symbol?  
Also, we could just call super, as in #category. I attached a  
changeset which does this.

- Bert -

Hi Bert,

On Mar 20, 2006, at 19:19 , Bert Freudenberg wrote:

> [...]
>
>> <categoryspeedup.cs>
>
> In Class>>category:, shouldn't the category be stored as Symbol?

yes. I changed that already for the 3.9a but apparently the change  
set I sent you was older than that..

>  Also, we could just call super, as in #category. I attached a  
> changeset which does this.

jep, looks good. In 3.9 I removed the version of category in  
ClassDescription, so the super send is not needed there anymore.

Adrian