On 13 December 2017 at 19:41, Ben Coman <btc@openinworld.com> wrote:

In a fresh 60528-64 image download with PharoLauncher on Ubuntu 16.04...
1. Open Playground
2. Evaluate... OpalCompler recompileAll
3. Try opening Iceberg, Playground or Spotter.
==>��Error: A class or trait does not properly resolve a conflict between multiple traits it uses.

System Browser, Test Runner and Monticello are okay.

60528 (32bit) is okay (what is different between 32bit and 64bit?)

60521-64 is broken
60520-64 is okay

https://pharo.manuscript.com/f/cases/20867/OpalCompiler-recompileAll-GLM-trait-conflict

cheers -ben

I've got to the limit of where I can go with this one, so I'm seeking help. Copied from issue...

Having isolated the build where the issue was introduced,

normally I'd search the mail list for "60521" to find reports like these...��

�� 60519 http://forum.world.st/update-6-0-60519-td5007498.html

�� 60522 http://forum.world.st/update-6-0-60522-td5056051.html

and try applying the modifications to 60521��

manually to 60520 to see if I can break it.

But 60520 and 60521 reports are missing.

Comparing file dates (http://files.pharo.org/image/60/)....

2017.11.07�� 60520

2017.11.29�� 60521

2017.11.29�� 60522

to Fogbuz...�� https://pharo.fogbugz.com/f/filters/?closedInLast=4&fClosedBugs=true&ixFixFor=22&sColumns=Category-Favorite-Case-TitleComment-Status-Priority-DateClosed-Milestone&sSorts=DateClosed.descending-LastUpdated.descending&sView=grid-flat

Issue�� Closed�� Note

18760�� 2017.11.29�� merged in 60522

20339�� 2017.11.29�� resolved Fix To Include - Monkey was failing - removed the testRenameClassUsingClass

20250�� 2017.11.28�� closed Fixed Upstream

20260�� 2017.11.28�� reopened, originally merged 2017.08.22��

20586�� 2017.11.23�� closed Wont Fix

20709�� 2017.11.18�� merged in ????�� (and there is no such Slice in Pharo6Inbox)

20119�� 2017.11.07�� merged in 60520�� (pull/492 ??)

applying Slice-20339 on top of 60520 doesn't break�� "OpalCompiler recompileAll".

So I'm at a loss how to continue.��

Maybe it was just a momentary glitch :(

and builds > 60520 need to be thrown out and their integrations re-run

with either same or newer build numbers.

So we don't create additional rework, there should be no further integrations to Pharo6,��

so I've tentatively moved priority to "Show. Stopper" (not that that will necessarily have any great effect with development moved to Pharo 7).��

============================================

Putting a halt in CompiledMethod class >> conflictMarker

prior to running "OpalCompiler recompileAll"

stops in...

�� GLMBrick(Behaviour)>>#updateMethodDictionarySelector: #innerBounds

where it calls...

�� methodDescription effectiveMethod

which is...

�� TraitDescription>>#effectiveMethod

�� "Return the effective compiled method of this method description."��

�� | method |

�� method := self providedMethod.

�� method isNil ifFalse: [^ method].

�� method := self conflictMethod. "<<<<<<<<<"

�� method isNil ifFalse: [^ method].

�� ^ self requiredMethod.

with ivar...

�� .locatedMethods={GLMBrickGeometryTrait>>#innerBounds .��

�� GLMBrickLayoutTrait>>#innerBounds}

and evaluting "self providedMethod"...

�� TraitMethodDescription>>#providedLocatedMethod

�� | locatedMethod aLocatedMethod refOrigin |

�� locatedMethod := nil.

�� self locatedMethods ifEmpty: [ ^ nil].

�� self locatedMethods size > 1

�� ifTrue: [��

�� aLocatedMethod := self locatedMethods anyOne.

�� refOrigin := (aLocatedMethod methodClass >> aLocatedMethod selector) origin.

�� (self locatedMethods allSatisfy: [:each | each origin == refOrigin])

�� ifTrue: [^ aLocatedMethod].

�� ].

�� self locatedMethods do: [:each |

�� each isProvided ifTrue: [

�� locatedMethod isNil ifFalse: [^nil].

�� locatedMethod := each]

�� ].

�� ^locatedMethod

shows...

��* all locatedMethods don't have the same origin��

�� i.e. self locatedMethods collect: [:e|e origin]

�� ==> {GLMBrickGeometryTrait, GLMBrickLayoutTrait}

��* all locatedMethods are provided

�� i.e. self asOrderedCollection collect: [:e|e isProvided]

�� ==> {true.true}��

Now System Browser shows these definitions...

1. (T)GLMBrickGeometeryTrait>>#innerBounds

�� ^ self wrappedBounds innerBounds

2. (T)GLMBrickLayoutTrait>>#innerBounds

�� ^ self explicitRequirement

3. GLMBrickedMorph subclass: #GLMBrick

�� uses: GLMBrickPropertiesTrait��

�� + GLMBrickLayoutTrait��

�� + GLMBrickStructureTrait��

�� + (GLMBrickGeometryTrait - {#privateBounds:})

�� instanceVariableNames: 'brickBounds brickApi'

�� classVariableNames: ''

�� package: 'Glamour-Morphic-Brick-Widgets-Core'

which from my limited understanding of Traits seems to have been

correctly flagged as a conflict.

But image 60520-64 similarly has...

1. (T)GLMBrickGeometeryTrait>>#innerBounds

�� ^ self wrappedBounds innerBounds

2. (T)GLMBrickLayoutTrait>>#innerBounds

�� ^ self explicitRequirement

3. GLMBrickedMorph subclass: #GLMBrick

�� uses: GLMBrickPropertiesTrait��

�� + GLMBrickLayoutTrait��

�� + GLMBrickStructureTrait��

�� + (GLMBrickGeometryTrait - {#privateBounds:})

�� instanceVariableNames: 'brickBounds brickApi'

�� classVariableNames: ''

�� package: 'Glamour-Morphic-Brick-Widgets-Core'

so is the question really why 60520 doesn't flag a conflict?

Also my meta question... why did I need to debug deep into the compiler��

to tune in on definitions [1.], [2.] & [3.] ?�� i.e why have...

��

�� TraitMethodDescription>>#conflictMethod

�� | binary numberOfArguments |

�� self isConflict ifFalse: [^nil].

�� binary := self isBinarySelector.

�� numberOfArguments := self numberOfArguments.

�� ^self

�� generateMethod: self selector

�� withMarker: CompiledMethod conflictMarker

�� forArgs: numberOfArguments

�� binary: binary

and not...

�� TraitMethodDescription>>#conflictMethod

�� self isConflict ifFalse: [^nil].

�� self raise: CompileTimeTraitErrorReportWithGUI

===================

P.S. Maybe not related, at various times stepping through "self providedMethod"

for ivar "locatedMethod" the pane inspector showed "error obtaining field value"��

(in the 60521 image)

Here's hoping some guru can pick it up from there.

cheers -ben