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&ixFixFo... 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