Nile makes #testProvidedMethodBindingsWithConflicts fail in 3.9

Damien Cassou damien.cassou at gmail.com
Sat Jun 9 21:04:02 UTC 2007


Hi Daniel,

very good work. Could you please write some tests and a fix and attach
the changeset to the bug? I will then help the release team with the
inclusion into 3.10.

Bye

2007/6/9, Daniel Vainsencher <danielv at tx.technion.ac.il>:
> 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
> >>
> >
>
>
>


-- 
Damien Cassou



More information about the Squeak-dev mailing list