Nile makes #testProvidedMethodBindingsWithConflicts fail in 3.9

Daniel Vainsencher danielv at tx.technion.ac.il
Sat Jun 9 15:23:21 UTC 2007


A couple of conclusions:

1. It wasn't Nile's fault. Somehow loading Nile changed the order of 
execution, exposing this tricky bug.

2. I seriously doubt that generating the required and conflict method 
templates is so expensive and common that it really requires a cache. 
Maybe that cache can be simply removed? it also seems to be one of the 
causes behind bug 6445.

3. There's a whole bunch of bugs open on the Traits tools: 1764, 6411, 
3789, and implementation: 5526, 6445. Some of these are assigned to me, 
but I've been very inactive lately. Who's interested in giving Traits a 
little love?

4. I think that caches are a really evil necessity.  Maybe less 
theoretically interesting, but IMO far more practically interesting than 
the multiple inheritance problem. Anyone know of tool/language feature 
ideas to make them less evil?


Daniel

PS. The bug is that we update the ConflictMethods cache when we don't 
find what we need in the RequiredMethods cache, and with the wrong 
thing. The bug perversely doesn't affect the RequiredMethods semantics, 
while disabling completely any benefits of having a cache. Cute!


Daniel Vainsencher wrote:

> Hi Damien,
>
>
> I think I have found the bug, and it is in the following method:
>
> TraitMethodDescription>>requiredMethodForArguments: aNumber 
> ifAbsentPut: aBlock
>    "ConflictMethods is an array that caches the generated conflict
>    methods. At position 1: binary method; 2: unary method;
>    n+2: keywordmethod with n arguments."
>
>    ^(RequiredMethods at: aNumber)
>        ifNil: [ConflictMethods at: aNumber put: aBlock value]
>
>
> This results in the following easy to diagnose symptom:
>
>
> Print-it:
>
>
> ((TraitMethodDescription classPool at: #ConflictMethods) at: 2) 
> decompileString
>
> gives:
>
> 'm11
>    self requirement'
>
> instead of:
>
> 'm11
>    self traitConflict'
>
>
> But I'm a bit rusty, so please double check me, and then send in the 
> trivial fix. Ah, the wonders of caches/copy&paste...
>
> Daniel
>
>
> Damien Cassou wrote:
>
>> 2007/6/9, stephane ducasse <stephane.ducasse at free.fr>:
>>> can you add that to mantis and add also the problems you describe in
>>> the paper (about self requirement) taking precedence on ...
>>
>> http://bugs.squeak.org/view.php?id=6533
>> http://bugs.squeak.org/view.php?id=6534
>>
>




More information about the Squeak-dev mailing list