Jenkins build is still unstable: moose-latest-dev #960

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
56 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Build failed in Jenkins: moose-latest-dev #977

admin-2
See <http://hudson.moosetechnology.org/job/moose-latest-dev/977/>

------------------------------------------
[...truncated 748 lines...]
  BlockClosure>>on:do:
  MetacelloFetchingMCSpecLoader>>resolveDependencies:nearest:into:
  [| references nearestReference cachedReference externalReference loadedVersionInfos mcVersion |
  self flag: #cleanup.
  cachedReference := self resolvePackageSpec: packageSpec cachedGofer: self loaderPolicy cacheGofer.
  (cachedReference ~~ nil
  and: [packageSpec getFile ~~ nil])
  ifTrue: [cachedReference name = packageSpec file
  ifTrue: [^ self]].
  references := self retryingResolvePackageSpecReferences: packageSpec gofer: gofer.
  nearestReference := references last asMetacelloCachingResolvedReference.
  (cachedReference ~~ nil
  and: [cachedReference name = nearestReference name])
  ifTrue: [^ self].
  (self ignoreImage not
  and: [(loadedVersionInfos := self ancestorsFor: packageSpec) ~~ nil])
  ifTrue: [loadedVersionInfos
  do: [:info |
  info name = nearestReference name
  ifTrue: [^ self].
  nil]].
  externalReference := (references
  select: [:ref | ref name = nearestReference name]) first asMetacelloCachingResolvedReference.
  self repositoryMap at: externalReference name put: externalReference repository.
  (self
  resolveDependencies: externalReference
  nearest: nearestReference
  into: (OrderedCollection with: nearestReference))
  do: [:reference |
  | pSpec l |
  mcVersion := reference version.
  (l := (GoferVersionReference name: reference name)
  resolveAllWith: self loaderPolicy cacheGofer) isEmpty
  ifTrue: [self cacheRepository storeVersion: mcVersion.
  reference == nearestReference
  ifTrue: [pSpec := packageSpec]
  ifFalse: [pSpec := packageSpec project packageSpec.
  pSpec name: mcVersion info].
  self loadData
  addVersion: mcVersion
  versionInfo: mcVersion info
  resolvedReference: reference
  packageSpec: pSpec]].
  self loaderPolicy resetCacheGofer.
  self preLoad: packageSpec.
  (MetacelloDirective
  loadPackage: packageSpec
  externalReference: externalReference
  loader: self)
  addTo: self loadDirective.
  self postLoad: packageSpec.
  Transcript cr; show: 'Fetched -> ' , externalReference name , ' --- ' , externalReference repository description , ' --- ' , nearestReference repository description] in MetacelloFetchingMCSpecLoader>>linearLoadPackageSpec:gofer:
  [:bar |
  bar value: 1.
  aBlock value.
  bar value: 2] in MetacelloPharoPlatform>>do:displaying:
  NonInteractiveUIManager(CommandLineUIManager)>>progressInitiationExceptionDefaultAction:
  ProgressInitiationException>>defaultAction
  UndefinedObject>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  ProgressInitiationException(Exception)>>signal
  ProgressInitiationException>>display:at:from:to:during:
  ProgressInitiationException class>>display:at:from:to:during:
  ByteString(String)>>displayProgressAt:from:to:during:
  MetacelloPharoPlatform>>do:displaying:
  MetacelloFetchingMCSpecLoader>>linearLoadPackageSpec:gofer:
  MetacelloPackageSpec>>loadUsing:gofer:
  [:pkg | pkg loadUsing: self gofer: gofer] in MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>linearLoadPackageSpecs:repositories:
  OrderedCollection>>do:
  MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>linearLoadPackageSpecs:repositories:
  [super linearLoadPackageSpecs: packageSpecs repositories: repositories] in MetacelloFetchingMCSpecLoader>>atomicLoadPackageSpecs:repositories:
  BlockClosure>>ensure:
  MetacelloLoaderPolicy>>pushLoadDirective:during:
  MetacelloLoaderPolicy>>pushAtomicLoadDirectivesDuring:for:
  MetacelloFetchingMCSpecLoader>>atomicLoadPackageSpecs:repositories:
  MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>load
  MetacelloMCVersionSpecLoader>>load
  MetacelloMCVersion>>executeLoadFromArray:
  [:dict | ^ self executeLoadFromArray: anArray] in [self versionSpec loader: newLoader.
  MetacelloPlatform current
  useStackCacheDuring: [:dict | ^ self executeLoadFromArray: anArray]
  defaultDictionary: Dictionary new] in [[self versionSpec loader: newLoader.
  MetacelloPlatform current
  useStackCacheDuring: [:dict | ^ self executeLoadFromArray: anArray]
  defaultDictionary: Dictionary new]
  ensure: [self versionSpec loader: originalLoader]] in MetacelloMCVersion>>fetchRequiredFromArray:
  [^ aBlock value: dict] in MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary:
  BlockClosure>>on:do:
  MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary:
  [self versionSpec loader: newLoader.
  MetacelloPlatform current
  useStackCacheDuring: [:dict | ^ self executeLoadFromArray: anArray]
  defaultDictionary: Dictionary new] in [[self versionSpec loader: newLoader.
  MetacelloPlatform current
  useStackCacheDuring: [:dict | ^ self executeLoadFromArray: anArray]
  defaultDictionary: Dictionary new]
  ensure: [self versionSpec loader: originalLoader]] in MetacelloMCVersion>>fetchRequiredFromArray:
  BlockClosure>>ensure:
  [[self versionSpec loader: newLoader.
  MetacelloPlatform current
  useStackCacheDuring: [:dict | ^ self executeLoadFromArray: anArray]
  defaultDictionary: Dictionary new]
  ensure: [self versionSpec loader: originalLoader]] in MetacelloMCVersion>>fetchRequiredFromArray:
  [:bar |
  bar value: 1.
  aBlock value.
  bar value: 2] in MetacelloPharoPlatform>>do:displaying:
  NonInteractiveUIManager(CommandLineUIManager)>>progressInitiationExceptionDefaultAction:
  ProgressInitiationException>>defaultAction
  UndefinedObject>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  ProgressInitiationException(Exception)>>signal
  ProgressInitiationException>>display:at:from:to:during:
  ProgressInitiationException class>>display:at:from:to:during:
  ByteString(String)>>displayProgressAt:from:to:during:
  MetacelloPharoPlatform>>do:displaying:
  MetacelloMCVersion>>fetchRequiredFromArray:
  [:dict |
  | projectCache |
  projectCache := dict
  at: self projectClass
  ifAbsent: [dict at: self projectClass put: Dictionary new].
  (projectCache
  at: vrsn
  ifAbsent: [])
  ifNil: [projectCache at: vrsn put: list]
  ifNotNil: [:cachedList |
  (cachedList size = list size
  and: [cachedList includesAllOf: list])
  ifTrue: [^ self].
  projectCache at: vrsn put: list].
  mcLoader preLoad: self.
  vrsn fetchRequiredFromArray: list.
  mcLoader postLoad: self] in MetacelloMCProjectSpec>>loadVersion:
  [^ aBlock value: dict] in MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary:
  BlockClosure>>on:do:
  MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary:
  MetacelloMCProjectSpec>>loadVersion:
  MetacelloMCProjectSpec>>load
  MetacelloProjectReferenceSpec>>loadUsing:gofer:
  [:pkg | pkg loadUsing: self gofer: gofer] in MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>linearLoadPackageSpecs:repositories:
  OrderedCollection>>do:
  MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>linearLoadPackageSpecs:repositories:
  [super linearLoadPackageSpecs: packageSpecs repositories: repositories] in MetacelloFetchingMCSpecLoader>>atomicLoadPackageSpecs:repositories:
  BlockClosure>>ensure:
  MetacelloLoaderPolicy>>pushLoadDirective:during:
  MetacelloLoaderPolicy>>pushAtomicLoadDirectivesDuring:for:
  MetacelloFetchingMCSpecLoader>>atomicLoadPackageSpecs:repositories:
  MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>load
  MetacelloMCVersionSpecLoader>>load
  MetacelloMCVersion>>executeLoadFromArray:
  [:dict | ^ self executeLoadFromArray: anArray] in [self versionSpec loader: newLoader.
  MetacelloPlatform current
  useStackCacheDuring: [:dict | ^ self executeLoadFromArray: anArray]
  defaultDictionary: Dictionary new] in [[self versionSpec loader: newLoader.
  MetacelloPlatform current
  useStackCacheDuring: [:dict | ^ self executeLoadFromArray: anArray]
  defaultDictionary: Dictionary new]
  ensure: [self versionSpec loader: originalLoader]] in MetacelloMCVersion>>fetchRequiredFromArray:
  [^ aBlock value: dict] in MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary:
  BlockClosure>>on:do:
  MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary:
  [self versionSpec loader: newLoader.
  MetacelloPlatform current
  useStackCacheDuring: [:dict | ^ self executeLoadFromArray: anArray]
  defaultDictionary: Dictionary new] in [[self versionSpec loader: newLoader.
  MetacelloPlatform current
  useStackCacheDuring: [:dict | ^ self executeLoadFromArray: anArray]
  defaultDictionary: Dictionary new]
  ensure: [self versionSpec loader: originalLoader]] in MetacelloMCVersion>>fetchRequiredFromArray:
  BlockClosure>>ensure:
  [[self versionSpec loader: newLoader.
  MetacelloPlatform current
  useStackCacheDuring: [:dict | ^ self executeLoadFromArray: anArray]
  defaultDictionary: Dictionary new]
  ensure: [self versionSpec loader: originalLoader]] in MetacelloMCVersion>>fetchRequiredFromArray:
  [:bar |
  bar value: 1.
  aBlock value.
  bar value: 2] in MetacelloPharoPlatform>>do:displaying:
  NonInteractiveUIManager(CommandLineUIManager)>>progressInitiationExceptionDefaultAction:
  ProgressInitiationException>>defaultAction
  UndefinedObject>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  ProgressInitiationException(Exception)>>signal
  ProgressInitiationException>>display:at:from:to:during:
  ProgressInitiationException class>>display:at:from:to:during:
  ByteString(String)>>displayProgressAt:from:to:during:
  MetacelloPharoPlatform>>do:displaying:
  MetacelloMCVersion>>fetchRequiredFromArray:
  [| fetchLoader |
  fetchLoader := self
  fetchRequiredFromArray: (self defaultPackageNamesToLoad: anArray).
  MetacelloPlatform current
  do: [fetchLoader doLoad]
  displaying: 'Loading ' , displayString.
  Transcript cr; show: '...finished ' , self versionNumber printString.
  ^ fetchLoader] in MetacelloMCVersion>>doLoadRequiredFromArray:
  BlockClosure>>ensure:
  MetacelloMCVersion>>doLoadRequiredFromArray:
  MetacelloMCVersion>>load
  ConfigurationOfMoose class>>loadDefault
  UndefinedObject>>DoIt
  Compiler>>evaluate:in:to:notifying:ifFail:logged:
  Compiler class>>evaluate:for:notifying:logged:
  -- and more not shown ---------------------------------------------------------------------------------
 
  THERE_BE_DRAGONS_HERE
  Got startup errors:
  -------------------------------------------------------------------------------
 
  THERE_BE_DRAGONS_HERE
      ZnHttpUnsuccessful: 502 Bad Gateway
  -------------------------------------------------------------------------------
 
Recording test results
Archiving artifacts

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Build failed in Jenkins: moose-latest-dev #978

admin-2
See <http://hudson.moosetechnology.org/job/moose-latest-dev/978/>

------------------------------------------
Started by user girba
[workspace] $ /bin/sh -xe /tmp/hudson7993064719538790799.sh
+ rm -rf <http://hudson.moosetechnology.org/job/moose-latest-dev/ws/moose>
+ /srv/hudson.moosetechnology.org/builder/build.sh -i Pharo-1.4 -s nautilus -s moose -s glamorous-theme -s moose-clean -s glamorous-toolkit -s cleanupforrelease -o moose

===============================================================================
Notice: Errors in script loaded from <http://hudson.moosetechnology.org/job/moose-latest-dev/978/artifact/moose/moose.st>
===============================================================================
==== Startup Error: DuplicatedVariableError: window is already defined in ComposableModel
ClassBuilder>>validateInstvars:from:forSuper: in Block: [:iv | ...
Array(SequenceableCollection)>>do:
ClassBuilder>>validateInstvars:from:forSuper:
ClassBuilder>>name:inEnvironment:subclassOf:type:instanceVariableNames:classVariableNames:poolDictionaries:category:unsafe: in Block: [| newCategory oldCategory needNew force organizat...etc...
BlockClosure>>ensure:
ClassBuilder>>name:inEnvironment:subclassOf:type:instanceVariableNames:classVariableNames:poolDictionaries:category:unsafe:
ClassBuilder>>name:inEnvironment:subclassOf:type:instanceVariableNames:classVariableNames:poolDictionaries:category:
MCClassDefinition>>createClass
MCClassDefinition>>load
MCClassDefinition(MCDefinition)>>addMethodAdditionTo:
Got startup errors:
    DuplicatedVariableError: window is already defined in ComposableModel

blockNoContextSwitchOffset != null 9102
+ /srv/hudson.moosetechnology.org/builder/build.sh -i moose -s patch-inputsensor -s testrunner -s moose-tests -o moose-tests

===============================================================================
Notice: Errors in script loaded from <http://hudson.moosetechnology.org/job/moose-latest-dev/ws/moose-tests/moose-tests.st>
===============================================================================
==== Startup Error: MessageNotUnderstood: receiver of "new" is nil
UndefinedObject(Object)>>doesNotUnderstand: #new
UndefinedObject>>DoIt
Compiler>>evaluate:in:to:notifying:ifFail:logged:
Compiler class>>evaluate:for:notifying:logged:
Compiler class>>evaluate:for:logged:
Compiler class>>evaluate:logged:
FileSystemFileStream(PositionableStream)>>fileInAnnouncing: in Block: [| chunk | val := (self peekFor: $!)...
BlockClosure>>on:do:
FileSystemFileStream(PositionableStream)>>fileInAnnouncing: in Block: [:bar | ...
NonInteractiveUIManager(CommandLineUIManager)>>progressInitiationExceptionDefaultAction:
Got startup errors:
    MessageNotUnderstood: receiver of "new" is nil

blockNoContextSwitchOffset != null 9102
+ /srv/hudson.moosetechnology.org/builder/build-oneclick.sh -i moose -o moose_suite-4_7_dev -n Moose -t 'Moose Suite 4.7 Development ' -v 4.7 -c Moose
cp: cannot stat `/srv/ci.moosetechnology.org/builder/oneclick-icons/Moose.png': No such file or directory
cp: cannot stat `/srv/ci.moosetechnology.org/builder/oneclick-icons/Moose.ico': No such file or directory
cp: cannot stat `/srv/ci.moosetechnology.org/builder/oneclick-icons/Moose.icns': No such file or directory
Recording test results
No test report files were found. Configuration error?
Archiving artifacts


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Build failed in Jenkins: moose-latest-dev #979

admin-2
See <http://hudson.moosetechnology.org/job/moose-latest-dev/979/>

------------------------------------------
[...truncated 742 lines...]
  handlerAction: [:e | self handleError: e reference: aReference]
  handlerActive: false
  Receiver's instance variables:
  outerContext: [:stream | [^ (FileSystemFileStream with: stream contents asStrin...etc...
  startpc: 72
  numArgs: 0
 
 
  [:stream | [^ (FileSystemFileStream with: stream contents asString) reset fileIn]
  on: Error , ParserNotification
  do: [:e | self handleError: e reference: aReference]] in BasicCodeLoader>>installSourceFile:
  Receiver: a BasicCodeLoader
  Arguments and temporary variables:
  aReference: a FileSystemReadStream
  stream: <http://hudson.moosetechnology.org/job/moose-latest-dev/ws/moose/m...etc...>
  Receiver's instance variables:
  sourceFiles: an Array(/srv/ci.moosetechnology.org/app/jobs/moose-latest-dev/wor...etc...
 
 
  [aBlock value: stream] in FileReference>>readStreamDo:
  Receiver: <http://hudson.moosetechnology.org/job/moose-latest-dev/979/artifact/moose/moose.st>
  Arguments and temporary variables:
  aBlock: [:stream | [^ (FileSystemFileStream with: stream contents asString) res...etc...
  stream: a FileSystemReadStream
  Receiver's instance variables:
  filesystem: a FileSystem
  path: Path / 'srv' / 'ci.moosetechnology.org' / 'app' / 'jobs' / 'moose-latest-...etc...
 
 
  BlockClosure>>ensure:
  Receiver: [aBlock value: stream]
  Arguments and temporary variables:
  aBlock: [stream close]
  complete: nil
  returnValue: nil
  Receiver's instance variables:
  outerContext: FileReference>>readStreamDo:
  startpc: 34
  numArgs: 0
 
 
  FileReference>>readStreamDo:
  Receiver: <http://hudson.moosetechnology.org/job/moose-latest-dev/979/artifact/moose/moose.st>
  Arguments and temporary variables:
  aBlock: [:stream | [^ (FileSystemFileStream with: stream contents asString) res...etc...
  stream: a FileSystemReadStream
  Receiver's instance variables:
  filesystem: a FileSystem
  path: Path / 'srv' / 'ci.moosetechnology.org' / 'app' / 'jobs' / 'moose-latest-...etc...
 
 
  BasicCodeLoader>>installSourceFile:
  Receiver: a BasicCodeLoader
  Arguments and temporary variables:
  aReference: <http://hudson.moosetechnology.org/job/moose-latest-dev/ws/moo...etc...>
  Receiver's instance variables:
  sourceFiles: an Array(/srv/ci.moosetechnology.org/app/jobs/moose-latest-dev/wor...etc...
 
 
  [:reference | self installSourceFile: reference] in [sourceFiles
  do: [:reference | self installSourceFile: reference]] in BasicCodeLoader>>installSourceFiles
  Receiver: a BasicCodeLoader
  Arguments and temporary variables:
  reference: <http://hudson.moosetechnology.org/job/moose-latest-dev/ws/moos...etc...>
  Receiver's instance variables:
  sourceFiles: an Array(/srv/ci.moosetechnology.org/app/jobs/moose-latest-dev/wor...etc...
 
 
  Array(SequenceableCollection)>>do:
  Receiver: an Array(<http://hudson.moosetechnology.org/job/moose-latest-dev/ws/moose/moose.st)>
  Arguments and temporary variables:
  aBlock: [:reference | self installSourceFile: reference]
  index: 1
  indexLimiT: 1
  Receiver's instance variables:
  an Array(<http://hudson.moosetechnology.org/job/moose-latest-dev/ws/moose/moose.st)>
 
 
  --- The full stack ---
  Parser>>notify:at:
  Parser>>expected:
  Parser>>cascade
  Parser>>expression
  Parser>>statements:innerBlock:blockNode:
  Parser>>statements:innerBlock:
  Parser>>method:context:
  [methNode := self method: noPattern context: ctxt] in Parser>>parse:class:category:noPattern:context:notifying:ifFail:
  BlockClosure>>on:do:
  Parser>>parse:class:category:noPattern:context:notifying:ifFail:
  Compiler>>translate:noPattern:ifFail:
  Compiler>>evaluate:in:to:notifying:ifFail:logged:
  Compiler class>>evaluate:for:notifying:logged:
  Compiler class>>evaluate:for:logged:
  Compiler class>>evaluate:logged:
  [| chunk | val := (self peekFor: $!)
  ifTrue: [(self class evaluatorClass evaluate: self nextChunk logged: false)
  scanFrom: self]
  ifFalse: [chunk := self nextChunk.
  self checkForPreamble: chunk.
  self class evaluatorClass evaluate: chunk logged: true]] in [:bar |
  [self atEnd]
  whileFalse: [bar value: self position.
  self skipSeparators.
  [| chunk | val := (self peekFor: $!)
  ifTrue: [(self class evaluatorClass evaluate: self nextChunk logged: false)
  scanFrom: self]
  ifFalse: [chunk := self nextChunk.
  self checkForPreamble: chunk.
  self class evaluatorClass evaluate: chunk logged: true]]
  on: InMidstOfFileinNotification
  do: [:ex | ex resume: true].
  self skipStyleChunk].
  self close] in FileSystemFileStream(PositionableStream)>>fileInAnnouncing:
  BlockClosure>>on:do:
  [:bar |
  [self atEnd]
  whileFalse: [bar value: self position.
  self skipSeparators.
  [| chunk | val := (self peekFor: $!)
  ifTrue: [(self class evaluatorClass evaluate: self nextChunk logged: false)
  scanFrom: self]
  ifFalse: [chunk := self nextChunk.
  self checkForPreamble: chunk.
  self class evaluatorClass evaluate: chunk logged: true]]
  on: InMidstOfFileinNotification
  do: [:ex | ex resume: true].
  self skipStyleChunk].
  self close] in FileSystemFileStream(PositionableStream)>>fileInAnnouncing:
  NonInteractiveUIManager(CommandLineUIManager)>>progressInitiationExceptionDefaultAction:
  ProgressInitiationException>>defaultAction
  UndefinedObject>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  ProgressInitiationException(Exception)>>signal
  ProgressInitiationException>>display:at:from:to:during:
  ProgressInitiationException class>>display:at:from:to:during:
  ByteString(String)>>displayProgressFrom:to:during:
  FileSystemFileStream(PositionableStream)>>fileInAnnouncing:
  FileSystemFileStream(PositionableStream)>>fileIn
  [^ (FileSystemFileStream with: stream contents asString) reset fileIn] in [:stream | [^ (FileSystemFileStream with: stream contents asString) reset fileIn]
  on: Error , ParserNotification
  do: [:e | self handleError: e reference: aReference]] in BasicCodeLoader>>installSourceFile:
  BlockClosure>>on:do:
  [:stream | [^ (FileSystemFileStream with: stream contents asString) reset fileIn]
  on: Error , ParserNotification
  do: [:e | self handleError: e reference: aReference]] in BasicCodeLoader>>installSourceFile:
  [aBlock value: stream] in FileReference>>readStreamDo:
  BlockClosure>>ensure:
  FileReference>>readStreamDo:
  BasicCodeLoader>>installSourceFile:
  [:reference | self installSourceFile: reference] in [sourceFiles
  do: [:reference | self installSourceFile: reference]] in BasicCodeLoader>>installSourceFiles
  Array(SequenceableCollection)>>do:
   - - - - - - - - - - - - - - -  
  - - - - - - - - - - - - - - - - - -
  [sourceFiles
  do: [:reference | self installSourceFile: reference]] in BasicCodeLoader>>installSourceFiles
  BlockClosure>>ensure:
  BasicCodeLoader>>installSourceFiles
  BasicCodeLoader class>>commandLineHandlerAction:
  [:commandLine | BasicCodeLoader commandLineHandlerAction: commandLine] in BasicCodeLoader class>>initialize
  [:each |
  | actionBlock conditionBlock |
  conditionBlock := each key.
  actionBlock := each value.
  (conditionBlock value: anUserInput)
  ifTrue: [actionBlock value: anUserInput]] in CommandLine class(AbstractUserInput class)>>dispatch:
  [:association | aBlock value: association value] in Dictionary>>valuesDo:
  [:each | each
  ifNotNil: [aBlock value: each]] in Dictionary>>associationsDo:
  Array(SequenceableCollection)>>do:
  Dictionary>>associationsDo:
  Dictionary>>valuesDo:
  Dictionary>>do:
  CommandLine class(AbstractUserInput class)>>dispatch:
  [self dispatch: singleton] in CommandLine class>>dispatch
  BlockClosure>>cull:
  [each cull: resuming] in [:each | self
  logStartUpErrorDuring: [each cull: resuming]
  into: errors
  tryDebugger: self isInteractive] in SmalltalkImage>>executeDeferredStartupActions:
  BlockClosure>>on:do:
  SmalltalkImage>>logStartUpErrorDuring:into:tryDebugger:
  [:each | self
  logStartUpErrorDuring: [each cull: resuming]
  into: errors
  tryDebugger: self isInteractive] in SmalltalkImage>>executeDeferredStartupActions:
  OrderedCollection>>do:
  SmalltalkImage>>executeDeferredStartupActions:
  SmalltalkImage>>snapshot:andQuit:
  [Smalltalk snapshot: true andQuit: true] in WorldState class>>saveAndQuit
  BlockClosure>>ensure:
  CursorWithMask(Cursor)>>showWhile:
  WorldState class>>saveAndQuit
  [| selArgCount |
  (selArgCount := selector numArgs) = 0
  ifTrue: [target perform: selector]
  ifFalse: [selArgCount = arguments size
  ifTrue: [target perform: selector withArguments: arguments]
  ifFalse: [target
  perform: selector
  withArguments: (arguments copyWith: evt)]].
  self changed] in ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent:
  BlockClosure>>ensure:
  CursorWithMask(Cursor)>>showWhile:
  ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent:
  ToggleMenuItemMorph(MenuItemMorph)>>mouseUp:
  ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp:
  MouseButtonEvent>>sentTo:
  ToggleMenuItemMorph(Morph)>>handleEvent:
  MorphicEventDispatcher>>dispatchDefault:with:
  MorphicEventDispatcher>>dispatchEvent:with:
  ToggleMenuItemMorph(Morph)>>processEvent:using:
  MorphicEventDispatcher>>dispatchDefault:with:
  MorphicEventDispatcher>>dispatchEvent:with:
  MenuMorph(Morph)>>processEvent:using:
  MenuMorph(Morph)>>processEvent:
  MenuMorph>>handleFocusEvent:
  [ActiveHand := self.
  ActiveEvent := anEvent.
  result := focusHolder
  handleFocusEvent: (anEvent
  transformedBy: (focusHolder transformedFrom: self))] in HandMorph>>sendFocusEvent:to:clear:
  [aBlock value] in PasteUpMorph>>becomeActiveDuring:
  BlockClosure>>on:do:
  PasteUpMorph>>becomeActiveDuring:
  HandMorph>>sendFocusEvent:to:clear:
  HandMorph>>sendEvent:focus:clear:
  HandMorph>>sendMouseEvent:
  HandMorph>>handleEvent:
  HandMorph>>processEvents
  [:h |
  ActiveHand := h.
  h processEvents.
  ActiveHand := nil] in WorldState>>doOneCycleNowFor:
  Array(SequenceableCollection)>>do:
  WorldState>>handsDo:
  WorldState>>doOneCycleNowFor:
  WorldState>>doOneCycleFor:
  PasteUpMorph>>doOneCycle
  [[World doOneCycle.
  Processor yield.
  false] whileFalse.
  nil] in MorphicUIManager>>spawnNewProcess
  [self value.
  Processor terminateActive] in BlockClosure>>newProcess
Recording test results
Archiving artifacts

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Jenkins build is unstable: moose-latest-dev #980

admin-2
Reply | Threaded
Open this post in threaded view
|

Build failed in Jenkins: moose-latest-dev #981

admin-2
See <http://hudson.moosetechnology.org/job/moose-latest-dev/981/>

------------------------------------------
[...truncated 772 lines...]
  resolveAllWith: self loaderPolicy cacheGofer) isEmpty
  ifTrue: [self cacheRepository storeVersion: mcVersion.
  reference == nearestReference
  ifTrue: [pSpec := packageSpec]
  ifFalse: [pSpec := packageSpec project packageSpec.
  pSpec name: mcVersion info].
  self loadData
  addVersion: mcVersion
  versionInfo: mcVersion info
  resolvedReference: reference
  packageSpec: pSpec]].
  self loaderPolicy resetCacheGofer.
  self preLoad: packageSpec.
  (MetacelloDirective
  loadPackage: packageSpec
  externalReference: externalReference
  loader: self)
  addTo: self loadDirective.
  self postLoad: packageSpec.
  Transcript cr; show: 'Fetched -> ' , externalReference name , ' --- ' , externalReference repository description , ' --- ' , nearestReference repository description] in MetacelloFetchingMCSpecLoader>>linearLoadPackageSpec:gofer:
  [:bar |
  bar value: 1.
  aBlock value.
  bar value: 2] in MetacelloPharoPlatform>>do:displaying:
  NonInteractiveUIManager(CommandLineUIManager)>>progressInitiationExceptionDefaultAction:
  ProgressInitiationException>>defaultAction
  UndefinedObject>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  ProgressInitiationException(Exception)>>signal
  ProgressInitiationException>>display:at:from:to:during:
  ProgressInitiationException class>>display:at:from:to:during:
  ByteString(String)>>displayProgressAt:from:to:during:
  MetacelloPharoPlatform>>do:displaying:
  MetacelloFetchingMCSpecLoader>>linearLoadPackageSpec:gofer:
  MetacelloPackageSpec>>loadUsing:gofer:
  [:pkg | pkg loadUsing: self gofer: gofer] in MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>linearLoadPackageSpecs:repositories:
  OrderedCollection>>do:
  MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>linearLoadPackageSpecs:repositories:
  [super linearLoadPackageSpecs: packageSpecs repositories: repositories] in MetacelloFetchingMCSpecLoader>>atomicLoadPackageSpecs:repositories:
  BlockClosure>>ensure:
  MetacelloLoaderPolicy>>pushLoadDirective:during:
  MetacelloLoaderPolicy>>pushAtomicLoadDirectivesDuring:for:
  MetacelloFetchingMCSpecLoader>>atomicLoadPackageSpecs:repositories:
  MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>load
  MetacelloMCVersionSpecLoader>>load
  MetacelloMCVersion>>executeLoadFromArray:
  [:dict | ^ self executeLoadFromArray: anArray] in [self versionSpec loader: newLoader.
  MetacelloPlatform current
  useStackCacheDuring: [:dict | ^ self executeLoadFromArray: anArray]
  defaultDictionary: Dictionary new] in [[self versionSpec loader: newLoader.
  MetacelloPlatform current
  useStackCacheDuring: [:dict | ^ self executeLoadFromArray: anArray]
  defaultDictionary: Dictionary new]
  ensure: [self versionSpec loader: originalLoader]] in MetacelloMCVersion>>fetchRequiredFromArray:
  [^ aBlock value: dict] in MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary:
  BlockClosure>>on:do:
  MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary:
  [self versionSpec loader: newLoader.
  MetacelloPlatform current
  useStackCacheDuring: [:dict | ^ self executeLoadFromArray: anArray]
  defaultDictionary: Dictionary new] in [[self versionSpec loader: newLoader.
  MetacelloPlatform current
  useStackCacheDuring: [:dict | ^ self executeLoadFromArray: anArray]
  defaultDictionary: Dictionary new]
  ensure: [self versionSpec loader: originalLoader]] in MetacelloMCVersion>>fetchRequiredFromArray:
  BlockClosure>>ensure:
  [[self versionSpec loader: newLoader.
  MetacelloPlatform current
  useStackCacheDuring: [:dict | ^ self executeLoadFromArray: anArray]
  defaultDictionary: Dictionary new]
  ensure: [self versionSpec loader: originalLoader]] in MetacelloMCVersion>>fetchRequiredFromArray:
  [:bar |
  bar value: 1.
  aBlock value.
  bar value: 2] in MetacelloPharoPlatform>>do:displaying:
  NonInteractiveUIManager(CommandLineUIManager)>>progressInitiationExceptionDefaultAction:
  ProgressInitiationException>>defaultAction
  UndefinedObject>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  ProgressInitiationException(Exception)>>signal
  ProgressInitiationException>>display:at:from:to:during:
  ProgressInitiationException class>>display:at:from:to:during:
  ByteString(String)>>displayProgressAt:from:to:during:
  MetacelloPharoPlatform>>do:displaying:
  MetacelloMCVersion>>fetchRequiredFromArray:
  [| fetchLoader |
  fetchLoader := self
  fetchRequiredFromArray: (self defaultPackageNamesToLoad: anArray).
  MetacelloPlatform current
  do: [fetchLoader doLoad]
  displaying: 'Loading ' , displayString.
  Transcript cr; show: '...finished ' , self versionNumber printString.
  ^ fetchLoader] in MetacelloMCVersion>>doLoadRequiredFromArray:
  BlockClosure>>ensure:
  MetacelloMCVersion>>doLoadRequiredFromArray:
  MetacelloMCVersion>>load
  ConfigurationOfMoose class>>loadDefault
  UndefinedObject>>DoIt
  Compiler>>evaluate:in:to:notifying:ifFail:logged:
  Compiler class>>evaluate:for:notifying:logged:
  Compiler class>>evaluate:for:logged:
  Compiler class>>evaluate:logged:
  [| chunk | val := (self peekFor: $!)
  ifTrue: [(self class evaluatorClass evaluate: self nextChunk logged: false)
  scanFrom: self]
  ifFalse: [chunk := self nextChunk.
  self checkForPreamble: chunk.
  self class evaluatorClass evaluate: chunk logged: true]] in [:bar |
  [self atEnd]
  whileFalse: [bar value: self position.
  self skipSeparators.
  [| chunk | val := (self peekFor: $!)
  ifTrue: [(self class evaluatorClass evaluate: self nextChunk logged: false)
  scanFrom: self]
  ifFalse: [chunk := self nextChunk.
  self checkForPreamble: chunk.
  self class evaluatorClass evaluate: chunk logged: true]]
  on: InMidstOfFileinNotification
  do: [:ex | ex resume: true].
  self skipStyleChunk].
  self close] in FileSystemFileStream(PositionableStream)>>fileInAnnouncing:
  BlockClosure>>on:do:
  [:bar |
  [self atEnd]
  whileFalse: [bar value: self position.
  self skipSeparators.
  [| chunk | val := (self peekFor: $!)
  ifTrue: [(self class evaluatorClass evaluate: self nextChunk logged: false)
  scanFrom: self]
  ifFalse: [chunk := self nextChunk.
  self checkForPreamble: chunk.
  self class evaluatorClass evaluate: chunk logged: true]]
  on: InMidstOfFileinNotification
  do: [:ex | ex resume: true].
  self skipStyleChunk].
  self close] in FileSystemFileStream(PositionableStream)>>fileInAnnouncing:
  NonInteractiveUIManager(CommandLineUIManager)>>progressInitiationExceptionDefaultAction:
  ProgressInitiationException>>defaultAction
  UndefinedObject>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  MethodContext(ContextPart)>>handleSignal:
  ProgressInitiationException(Exception)>>signal
  ProgressInitiationException>>display:at:from:to:during:
  ProgressInitiationException class>>display:at:from:to:during:
  ByteString(String)>>displayProgressFrom:to:during:
  FileSystemFileStream(PositionableStream)>>fileInAnnouncing:
  FileSystemFileStream(PositionableStream)>>fileIn
  [^ (FileSystemFileStream with: stream contents asString) reset fileIn] in [:stream | [^ (FileSystemFileStream with: stream contents asString) reset fileIn]
  on: Error , ParserNotification
  do: [:e | self handleError: e reference: aReference]] in BasicCodeLoader>>installSourceFile:
  BlockClosure>>on:do:
  [:stream | [^ (FileSystemFileStream with: stream contents asString) reset fileIn]
  on: Error , ParserNotification
  do: [:e | self handleError: e reference: aReference]] in BasicCodeLoader>>installSourceFile:
  [aBlock value: stream] in FileReference>>readStreamDo:
  BlockClosure>>ensure:
  FileReference>>readStreamDo:
  BasicCodeLoader>>installSourceFile:
  [:reference | self installSourceFile: reference] in [sourceFiles
  do: [:reference | self installSourceFile: reference]] in BasicCodeLoader>>installSourceFiles
  Array(SequenceableCollection)>>do:
  [sourceFiles
  do: [:reference | self installSourceFile: reference]] in BasicCodeLoader>>installSourceFiles
  BlockClosure>>ensure:
  BasicCodeLoader>>installSourceFiles
  BasicCodeLoader class>>commandLineHandlerAction:
  [:commandLine | BasicCodeLoader commandLineHandlerAction: commandLine] in BasicCodeLoader class>>initialize
  [:each |
  | actionBlock conditionBlock |
  conditionBlock := each key.
  actionBlock := each value.
  (conditionBlock value: anUserInput)
  ifTrue: [actionBlock value: anUserInput]] in CommandLine class(AbstractUserInput class)>>dispatch:
  [:association | aBlock value: association value] in Dictionary>>valuesDo:
  [:each | each
  ifNotNil: [aBlock value: each]] in Dictionary>>associationsDo:
  Array(SequenceableCollection)>>do:
  Dictionary>>associationsDo:
  Dictionary>>valuesDo:
  Dictionary>>do:
  CommandLine class(AbstractUserInput class)>>dispatch:
  [self dispatch: singleton] in CommandLine class>>dispatch
  BlockClosure>>cull:
  [each cull: resuming] in [:each | self
  logStartUpErrorDuring: [each cull: resuming]
  into: errors
  tryDebugger: self isInteractive] in SmalltalkImage>>executeDeferredStartupActions:
  BlockClosure>>on:do:
  SmalltalkImage>>logStartUpErrorDuring:into:tryDebugger:
  [:each | self
  logStartUpErrorDuring: [each cull: resuming]
  into: errors
  tryDebugger: self isInteractive] in SmalltalkImage>>executeDeferredStartupActions:
  OrderedCollection>>do:
  SmalltalkImage>>executeDeferredStartupActions:
  SmalltalkImage>>snapshot:andQuit:
  [Smalltalk snapshot: true andQuit: true] in WorldState class>>saveAndQuit
  BlockClosure>>ensure:
  CursorWithMask(Cursor)>>showWhile:
  WorldState class>>saveAndQuit
  [| selArgCount |
  (selArgCount := selector numArgs) = 0
  ifTrue: [target perform: selector]
  ifFalse: [selArgCount = arguments size
  ifTrue: [target perform: selector withArguments: arguments]
  ifFalse: [target
  perform: selector
  withArguments: (arguments copyWith: evt)]].
  self changed] in ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent:
  BlockClosure>>ensure:
  CursorWithMask(Cursor)>>showWhile:
  ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent:
  ToggleMenuItemMorph(MenuItemMorph)>>mouseUp:
  ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp:
  MouseButtonEvent>>sentTo:
  ToggleMenuItemMorph(Morph)>>handleEvent:
  MorphicEventDispatcher>>dispatchDefault:with:
  MorphicEventDispatcher>>dispatchEvent:with:
  ToggleMenuItemMorph(Morph)>>processEvent:using:
  MorphicEventDispatcher>>dispatchDefault:with:
  MorphicEventDispatcher>>dispatchEvent:with:
  MenuMorph(Morph)>>processEvent:using:
  MenuMorph(Morph)>>processEvent:
  MenuMorph>>handleFocusEvent:
  [ActiveHand := self.
  ActiveEvent := anEvent.
  result := focusHolder
  handleFocusEvent: (anEvent
  transformedBy: (focusHolder transformedFrom: self))] in HandMorph>>sendFocusEvent:to:clear:
  -- and more not shown ---------------------------------------------------------------------------------
 
  THERE_BE_DRAGONS_HERE
  Got startup errors:
  -------------------------------------------------------------------------------
 
  THERE_BE_DRAGONS_HERE
      ZnHttpUnsuccessful: 502 Bad Gateway
  -------------------------------------------------------------------------------
 
Recording test results
Archiving artifacts

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Jenkins build is unstable: moose-latest-dev #982

admin-2
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins build is still unstable: moose-latest-dev #972

abergel
In reply to this post by Ben Coman
I've seen you committed in the Mondrian rep about the rubber band drag and drop facilities. This is indeed an interesting feature. However, I feel a bit more work is necessary. Here are my suggestions:
  - can you make sure all the Mondrian tests are green. Apparently MORoot>>resetFormCacheResursively disappeared. 
Do you mean MONode>>resetFormCacheResursively which was renamed in Mondrian-Core-AlexandreBergel.79 ?
I've searched back a few Mondrian-Core mcz files and not found MORoot>>resetFormCacheResursively.
I fixed a few remaining references to this in Mondrian-Core-BenComan.80 et al.
Ok, I've produced a new version of Mondrian that includes your changes. 

I fixed MOLayoutTest>>testTreeLayout failure in Mondrian-Tests-BenComan.101.
There is one remaining failure that I can't work out. TestRunner cannot open a debugger on it and after inserting 'self halt' it steps through to the end of the method without a failure.  Makes no sense to me.  I need to leave this one to others. 
The tree layout seems to randomly order the nodes. Type the following script in an easel: 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
view shape rectangle withText.
view nodes: #(1 2 3 4 ).
view edgesFromAssociations: { 1 -> 2. 1 ->3 . 3 -> 4}.
view treeLayout
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Times to times it produces:

times to times it produces:

A few weeks ago, it had always produced the same rendering, and tests had been written accordingly. Now it varies, so tests have to be adjusted. I fixed this. 
The test is now green.
  - add new tests that capture your change of MOCanvas>>mouseUp: , MOCanvas>>mouseOver:, and possibly for MOCanvas>>drawOn:. Those methods are central to Mondrian, they need to be robust.
I will now start thinking about some tests for these.

Cool!

Alexandre


Let me know how it goes. Currently the tests of Mondrian are yellow.

Cheers,
Alexandre


On 8 May 2012, at 16:42, [hidden email] wrote:

  
See <http://hudson.moosetechnology.org/job/moose-latest-dev/972/>


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
    

  

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins build is still unstable: moose-latest-dev #972

Tudor Girba-2
Thanks, Alex.

But, it is not good in this case to fix the tests because the rendering should remain the same :(.

For example, in the MetaBrowser I rely on the fact that the tree rendering remains the same to highlight the currently selected property.

We need to investigate this issue closer because it is an important bug.

Cheers,
Doru


On 14 May 2012, at 04:04, Alexandre Bergel wrote:

>>> I've seen you committed in the Mondrian rep about the rubber band drag and drop facilities. This is indeed an interesting feature. However, I feel a bit more work is necessary. Here are my suggestions:
>>>   - can you make sure all the Mondrian tests are green. Apparently MORoot>>resetFormCacheResursively disappeared.
>>>
>> Do you mean MONode>>resetFormCacheResursively which was renamed in Mondrian-Core-AlexandreBergel.79 ?
>> I've searched back a few Mondrian-Core mcz files and not found MORoot>>resetFormCacheResursively.
>> I fixed a few remaining references to this in Mondrian-Core-BenComan.80 et al.
>>
> Ok, I've produced a new version of Mondrian that includes your changes.
>
>> I fixed MOLayoutTest>>testTreeLayout failure in Mondrian-Tests-BenComan.101.
>> There is one remaining failure that I can't work out. TestRunner cannot open a debugger on it and after inserting 'self halt' it steps through to the end of the method without a failure.  Makes no sense to me.  I need to leave this one to others.
>>
> The tree layout seems to randomly order the nodes. Type the following script in an easel:
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> view shape rectangle withText.
> view nodes: #(1 2 3 4 ).
> view edgesFromAssociations: { 1 -> 2. 1 ->3 . 3 -> 4}.
> view treeLayout
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> Times to times it produces:
> <Screen Shot 2012-05-13 at 10.02.08 PM.png>
>
> times to times it produces:
> <Screen Shot 2012-05-13 at 10.02.16 PM.png>
>
> A few weeks ago, it had always produced the same rendering, and tests had been written accordingly. Now it varies, so tests have to be adjusted. I fixed this.
> The test is now green.
>>>   - add new tests that capture your change of MOCanvas>>mouseUp: , MOCanvas>>mouseOver:, and possibly for MOCanvas>>drawOn:. Those methods are central to Mondrian, they need to be robust.
>> I will now start thinking about some tests for these.
>>
>
> Cool!
>
> Alexandre
>
>>> Let me know how it goes. Currently the tests of Mondrian are yellow.
>>>
>>> Cheers,
>>> Alexandre
>>>
>>>
>>> On 8 May 2012, at 16:42,
>>> [hidden email]
>>>  wrote:
>>>
>>>  
>>>
>>>> See <http://hudson.moosetechnology.org/job/moose-latest-dev/972/>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>>
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>>    
>>>>
>>>
>>>  
>>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"Don't give to get. Just give."






_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins build is still unstable: moose-latest-dev #972

Ben Coman
I hit a similar problem back in July 2011 when I was trialling Aconcagua for attaching units of measure to measured values.  In case there is any chance it is related, I have trawled back through my diaries and refined my isolation test to be more generic. Defining the following class and methods...

Object subclass: #MyTest
    instanceVariableNames: 'myname'
    classVariableNames: ''
    poolDictionaries: ''
    category: 'MyPlay'

MyTest>>myname: x
    myname := x.

MyTest>>printOn: aStream
    myname printOn: aStream.

Then executing the following in Workspace...
10 timesRepeat: [
    one := MyTest new myname: '1'.
    two := MyTest new myname: '2'.
    collection := (OrderedCollection with: one with: two).
    Transcript crShow: collection asBag sortedCounts.


In Moose_4.7 downloaded 2012-05-06 I get the following result...
an Array(1->'1' 1->'2')
an Array(1->'1' 1->'2')
an Array(1->'1' 1->'2')
an Array(1->'1' 1->'2')
an Array(1->'2' 1->'1')
an Array(1->'1' 1->'2')
an Array(1->'2' 1->'1')
an Array(1->'1' 1->'2')
an Array(1->'1' 1->'2')
an Array(1->'2' 1->'1')

cheers, Ben  

Tudor Girba wrote:
Thanks, Alex.

But, it is not good in this case to fix the tests because the rendering should remain the same :(.

For example, in the MetaBrowser I rely on the fact that the tree rendering remains the same to highlight the currently selected property.

We need to investigate this issue closer because it is an important bug.

Cheers,
Doru


On 14 May 2012, at 04:04, Alexandre Bergel wrote:

  
I've seen you committed in the Mondrian rep about the rubber band drag and drop facilities. This is indeed an interesting feature. However, I feel a bit more work is necessary. Here are my suggestions:
  - can you make sure all the Mondrian tests are green. Apparently MORoot>>resetFormCacheResursively disappeared. 

        
Do you mean MONode>>resetFormCacheResursively which was renamed in Mondrian-Core-AlexandreBergel.79 ?
I've searched back a few Mondrian-Core mcz files and not found MORoot>>resetFormCacheResursively.
I fixed a few remaining references to this in Mondrian-Core-BenComan.80 et al.

      
Ok, I've produced a new version of Mondrian that includes your changes. 

    
I fixed MOLayoutTest>>testTreeLayout failure in Mondrian-Tests-BenComan.101.
There is one remaining failure that I can't work out. TestRunner cannot open a debugger on it and after inserting 'self halt' it steps through to the end of the method without a failure.  Makes no sense to me.  I need to leave this one to others. 

      
The tree layout seems to randomly order the nodes. Type the following script in an easel: 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
view shape rectangle withText.
view nodes: #(1 2 3 4 ).
view edgesFromAssociations: { 1 -> 2. 1 ->3 . 3 -> 4}.
view treeLayout
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Times to times it produces:
<Screen Shot 2012-05-13 at 10.02.08 PM.png>

times to times it produces:
<Screen Shot 2012-05-13 at 10.02.16 PM.png>

A few weeks ago, it had always produced the same rendering, and tests had been written accordingly. Now it varies, so tests have to be adjusted. I fixed this. 
The test is now green.
    
  - add new tests that capture your change of MOCanvas>>mouseUp: , MOCanvas>>mouseOver:, and possibly for MOCanvas>>drawOn:. Those methods are central to Mondrian, they need to be robust.
        
I will now start thinking about some tests for these.

      
Cool!

Alexandre

    
Let me know how it goes. Currently the tests of Mondrian are yellow.

Cheers,
Alexandre


On 8 May 2012, at 16:42, 
[hidden email]
 wrote:

  

        
See <http://hudson.moosetechnology.org/job/moose-latest-dev/972/>



_______________________________________________
Moose-dev mailing list

[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

    

          
  

        
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
      
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
    

--
www.tudorgirba.com

"Don't give to get. Just give."






_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

  


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Jenkins build is still unstable: moose-latest-dev #983

admin-2
In reply to this post by admin-2
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins build is still unstable: moose-latest-dev #972

abergel
In reply to this post by Tudor Girba-2
Well… this happens since the changes in the collection hierarchy a few weeks ago.
The tree layout should indeed preserver the order. I spent some time but I could not see where the problem came from. I should spent some more time on this.

Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



On May 13, 2012, at 11:21 PM, Tudor Girba wrote:

Thanks, Alex.

But, it is not good in this case to fix the tests because the rendering should remain the same :(.

For example, in the MetaBrowser I rely on the fact that the tree rendering remains the same to highlight the currently selected property.

We need to investigate this issue closer because it is an important bug.

Cheers,
Doru


On 14 May 2012, at 04:04, Alexandre Bergel wrote:

I've seen you committed in the Mondrian rep about the rubber band drag and drop facilities. This is indeed an interesting feature. However, I feel a bit more work is necessary. Here are my suggestions:
 - can you make sure all the Mondrian tests are green. Apparently MORoot>>resetFormCacheResursively disappeared.

Do you mean MONode>>resetFormCacheResursively which was renamed in Mondrian-Core-AlexandreBergel.79 ?
I've searched back a few Mondrian-Core mcz files and not found MORoot>>resetFormCacheResursively.
I fixed a few remaining references to this in Mondrian-Core-BenComan.80 et al.

Ok, I've produced a new version of Mondrian that includes your changes.

I fixed MOLayoutTest>>testTreeLayout failure in Mondrian-Tests-BenComan.101.
There is one remaining failure that I can't work out. TestRunner cannot open a debugger on it and after inserting 'self halt' it steps through to the end of the method without a failure.  Makes no sense to me.  I need to leave this one to others.

The tree layout seems to randomly order the nodes. Type the following script in an easel:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
view shape rectangle withText.
view nodes: #(1 2 3 4 ).
view edgesFromAssociations: { 1 -> 2. 1 ->3 . 3 -> 4}.
view treeLayout
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Times to times it produces:
<Screen Shot 2012-05-13 at 10.02.08 PM.png>

times to times it produces:
<Screen Shot 2012-05-13 at 10.02.16 PM.png>

A few weeks ago, it had always produced the same rendering, and tests had been written accordingly. Now it varies, so tests have to be adjusted. I fixed this.
The test is now green.
 - add new tests that capture your change of MOCanvas>>mouseUp: , MOCanvas>>mouseOver:, and possibly for MOCanvas>>drawOn:. Those methods are central to Mondrian, they need to be robust.
I will now start thinking about some tests for these.


Cool!

Alexandre

Let me know how it goes. Currently the tests of Mondrian are yellow.

Cheers,
Alexandre


On 8 May 2012, at 16:42,
[hidden email]
wrote:



See <http://hudson.moosetechnology.org/job/moose-latest-dev/972/>



_______________________________________________
Moose-dev mailing list

[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev







_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"Don't give to get. Just give."






_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins build is still unstable: moose-latest-dev #972

Tudor Girba-2
Could it be a Pharo issue, because I think it happened since we moved to Pharo 1.4.

Doru


On 15 May 2012, at 21:51, Alexandre Bergel wrote:

> Well… this happens since the changes in the collection hierarchy a few weeks ago.
> The tree layout should indeed preserver the order. I spent some time but I could not see where the problem came from. I should spent some more time on this.
>
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
> On May 13, 2012, at 11:21 PM, Tudor Girba wrote:
>
>> Thanks, Alex.
>>
>> But, it is not good in this case to fix the tests because the rendering should remain the same :(.
>>
>> For example, in the MetaBrowser I rely on the fact that the tree rendering remains the same to highlight the currently selected property.
>>
>> We need to investigate this issue closer because it is an important bug.
>>
>> Cheers,
>> Doru
>>
>>
>> On 14 May 2012, at 04:04, Alexandre Bergel wrote:
>>
>>>>> I've seen you committed in the Mondrian rep about the rubber band drag and drop facilities. This is indeed an interesting feature. However, I feel a bit more work is necessary. Here are my suggestions:
>>>>>  - can you make sure all the Mondrian tests are green. Apparently MORoot>>resetFormCacheResursively disappeared.
>>>>>
>>>> Do you mean MONode>>resetFormCacheResursively which was renamed in Mondrian-Core-AlexandreBergel.79 ?
>>>> I've searched back a few Mondrian-Core mcz files and not found MORoot>>resetFormCacheResursively.
>>>> I fixed a few remaining references to this in Mondrian-Core-BenComan.80 et al.
>>>>
>>> Ok, I've produced a new version of Mondrian that includes your changes.
>>>
>>>> I fixed MOLayoutTest>>testTreeLayout failure in Mondrian-Tests-BenComan.101.
>>>> There is one remaining failure that I can't work out. TestRunner cannot open a debugger on it and after inserting 'self halt' it steps through to the end of the method without a failure.  Makes no sense to me.  I need to leave this one to others.
>>>>
>>> The tree layout seems to randomly order the nodes. Type the following script in an easel:
>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>>> view shape rectangle withText.
>>> view nodes: #(1 2 3 4 ).
>>> view edgesFromAssociations: { 1 -> 2. 1 ->3 . 3 -> 4}.
>>> view treeLayout
>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>>>
>>> Times to times it produces:
>>> <Screen Shot 2012-05-13 at 10.02.08 PM.png>
>>>
>>> times to times it produces:
>>> <Screen Shot 2012-05-13 at 10.02.16 PM.png>
>>>
>>> A few weeks ago, it had always produced the same rendering, and tests had been written accordingly. Now it varies, so tests have to be adjusted. I fixed this.
>>> The test is now green.
>>>>>  - add new tests that capture your change of MOCanvas>>mouseUp: , MOCanvas>>mouseOver:, and possibly for MOCanvas>>drawOn:. Those methods are central to Mondrian, they need to be robust.
>>>> I will now start thinking about some tests for these.
>>>>
>>>
>>> Cool!
>>>
>>> Alexandre
>>>
>>>>> Let me know how it goes. Currently the tests of Mondrian are yellow.
>>>>>
>>>>> Cheers,
>>>>> Alexandre
>>>>>
>>>>>
>>>>> On 8 May 2012, at 16:42,
>>>>> [hidden email]
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> See <http://hudson.moosetechnology.org/job/moose-latest-dev/972/>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>>
>>>>>> [hidden email]
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "Don't give to get. Just give."
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

Innovation comes in least expected form.
That is, if it is expected, it already happened.


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Jenkins build is still unstable: moose-latest-dev #984

admin-2
In reply to this post by admin-2
Reply | Threaded
Open this post in threaded view
|

Collection>>difference: behaviour in 1.4 (was Re: Jenkins build is still unstable: moose-latest-dev #972 )

Ben Coman
In reply to this post by Tudor Girba-2
This discussion originates from Mondrian on Moose 4.7 where layouts which previously were exactly reproducible now randomly alternate between two arrangements.  I have cross-posted since upstream behaviour of Collection>>difference: has changed between Pharo 1.3 and 1.4.  

The issue in Mondrian has been isolated so that it can be observed using the attached changeset 'isolate-unstable-972.2.cs' against a fresh Moose 4.7 image downloaded a few moments ago.
After loading the cs, open a Transcript and then <Generate> the following script in Modrian Easel a dozen times.
            view shape label.
            view nodes: #(1 2 3 4 ).
            view edgesFromAssociations: { 1 -> 2. 1 ->3 . 3 -> 4}.
            view treeLayout

At some point you will see a change in the order that nodes are drawn between runs as reflected in lines B2 and A2 shown below...
------------------------------RUN 1
B1>an OrderedCollection(a MONode model: 2 a MONode model: 3)
B2>an OrderedCollection(a MONode model: 3 a MONode model: 2)
A2>a MONode model: 1
A2>a MONode model: 3
A2>a MONode model: 4
A2>a MONode model: 2
------------------------------RUN 2
B1>an OrderedCollection(a MONode model: 2 a MONode model: 3)
B2>an OrderedCollection(a MONode model: 2 a MONode model: 3)
A2>a MONode model: 1
A2>a MONode model: 2
A2>a MONode model: 3
A2>a MONode model: 4
------------------------------END


The cause of this is a change in behaviour of Collection>>#difference: between Pharo 1.3 & 1.4.  This can be observed by executing the following in Workspace...
    20 timesRepeat:
    [
        one := TextMorph new newContents: '1'.
        two := TextMorph new newContents: '2'.
        collection := (OrderedCollection with: one with: two).
        diff := collection difference: OrderedCollection new.
       Transcript crShow: diff first text, diff second text.
    ]

In Pharo 1.3 the result never deviates from '12'.
In Pharo 1.4 the result is sometimes '21'.

Pharo 1.3 has...
Collection>>difference: aCollection
    "Answer the set theoretic difference of two collections."
    ^ self reject: [:each | aCollection includes: each]

Pharo 1.4 has...
Collection>>difference: aCollection
    "Answer the set theoretic difference of two collections."
    | set| 
    set := self asSet.
    aCollection do: [ :each|
        set remove: each ifAbsent: []].
    ^ self species withAll: set asArray


Your thoughts?

cheers -ben


Tudor Girba wrote:
Could it be a Pharo issue, because I think it happened since we moved to Pharo 1.4.

Doru


On 15 May 2012, at 21:51, Alexandre Bergel wrote:

  
Well… this happens since the changes in the collection hierarchy a few weeks ago.
The tree layout should indeed preserver the order. I spent some time but I could not see where the problem came from. I should spent some more time on this.

Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



On May 13, 2012, at 11:21 PM, Tudor Girba wrote:

    
Thanks, Alex.

But, it is not good in this case to fix the tests because the rendering should remain the same :(.

For example, in the MetaBrowser I rely on the fact that the tree rendering remains the same to highlight the currently selected property.

We need to investigate this issue closer because it is an important bug.

Cheers,
Doru


On 14 May 2012, at 04:04, Alexandre Bergel wrote:

      
I've seen you committed in the Mondrian rep about the rubber band drag and drop facilities. This is indeed an interesting feature. However, I feel a bit more work is necessary. Here are my suggestions:
 - can you make sure all the Mondrian tests are green. Apparently MORoot>>resetFormCacheResursively disappeared. 

            
Do you mean MONode>>resetFormCacheResursively which was renamed in Mondrian-Core-AlexandreBergel.79 ?
I've searched back a few Mondrian-Core mcz files and not found MORoot>>resetFormCacheResursively.
I fixed a few remaining references to this in Mondrian-Core-BenComan.80 et al.

          
Ok, I've produced a new version of Mondrian that includes your changes. 

        
I fixed MOLayoutTest>>testTreeLayout failure in Mondrian-Tests-BenComan.101.
There is one remaining failure that I can't work out. TestRunner cannot open a debugger on it and after inserting 'self halt' it steps through to the end of the method without a failure.  Makes no sense to me.  I need to leave this one to others. 

          
The tree layout seems to randomly order the nodes. Type the following script in an easel: 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
view shape rectangle withText.
view nodes: #(1 2 3 4 ).
view edgesFromAssociations: { 1 -> 2. 1 ->3 . 3 -> 4}.
view treeLayout
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Times to times it produces:
<Screen Shot 2012-05-13 at 10.02.08 PM.png>

times to times it produces:
<Screen Shot 2012-05-13 at 10.02.16 PM.png>

A few weeks ago, it had always produced the same rendering, and tests had been written accordingly. Now it varies, so tests have to be adjusted. I fixed this. 
The test is now green.
        
 - add new tests that capture your change of MOCanvas>>mouseUp: , MOCanvas>>mouseOver:, and possibly for MOCanvas>>drawOn:. Those methods are central to Mondrian, they need to be robust.
            
I will now start thinking about some tests for these.

          
Cool!

Alexandre

        
Let me know how it goes. Currently the tests of Mondrian are yellow.

Cheers,
Alexandre


On 8 May 2012, at 16:42, 
[hidden email]
wrote:



            
See <http://hudson.moosetechnology.org/job/moose-latest-dev/972/>



_______________________________________________
Moose-dev mailing list

[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev



              

            
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
          
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
        
--
www.tudorgirba.com

"Don't give to get. Just give."






_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
      
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
    

--
www.tudorgirba.com

Innovation comes in least expected form. 
That is, if it is expected, it already happened.


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

  


'From Pharo1.4 of 18 April 2012 [Latest update: #14438] on 16 May 2012 at 11:15:20 pm'!

!MOAbstractRegularTreeLayout methodsFor: 'hook' stamp: 'BenComan 5/16/2012 23:14'!
doExecute: node
        | rootNodes btcdebug|
        alreadyLayoutedNodes := OrderedCollection new.
        rootNodes := self rootNodesFor: node nodes.
        nodesByLayer := OrderedCollection new.

        self flag: #btcdebug.  
                "Regarding [hidden email] emails 'Jenkins build is still unstable: moose-latest-dev #972'
                To isolate the issue, open a Transcript then generate the following in Mondrian Easel twenty times
                        view shape label.
                        view nodes: #(1 2 3 4 ).
                        view edgesFromAssociations: { 1 -> 2. 1 ->3 . 3 -> 4}.
                        view treeLayout.
                "
                btcdebug := rootNodes first.
                Transcript cr; crShow: '------------------------------'.
                Transcript crShow: 'B1>', (self childrenFor: btcdebug) asString.
                Transcript crShow: 'B2>', (self computeChildrenFor: btcdebug) asString.

        self
                layout: rootNodes
                atPoint: self leftGap @ self topGap
                atLayer: 1.
        self isLayered ifTrue: [
                self rearrangeByLayers: node ]! !


!MOAbstractVerticalTreeLayout methodsFor: 'hook-private' stamp: 'BenComan 5/16/2012 23:02'!
layout: aNodeCollection atPoint: aPoint atLayer: aNumber
        | treeSize childrenPosition x y middleOfTree |
        aNodeCollection isEmpty ifTrue: [ ^ 0 ].
        x := aPoint x.
        y := aPoint y.
        alreadyLayoutedNodes addAll: aNodeCollection.
        self atLayer: aNumber add: aNodeCollection.
        aNodeCollection do: [ :each |
                self flag: #btcdebug. Transcript crShow: 'A2>', each asString.
                childrenPosition := y + each height + self verticalGap.
                treeSize := each width
                        max: (self layout: (self computeChildrenFor: each) atPoint: x @ childrenPosition atLayer: aNumber + 1).
                middleOfTree := x + (treeSize / 2.0) - (each width / 2.0).
                each translateTo: middleOfTree @ y.
                x := x + treeSize + self horizontalGap ].
        ^ x - aPoint x - self horizontalGap! !


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Collection>>difference: behaviour in 1.4 (was Re: Jenkins build is still unstable: moose-latest-dev #972 )

Tudor Girba-2
Excellent hunting!

I think this is a conceptual bug in the current Pharo implementation.

Anyway, I fixed it now (and added a comment):

MOAbstractGraphLayout>>childrenFor: aNode except: aNodeCollection
       
        ^(self childrenFor: aNode)
                reject: [:each | aNodeCollection includes: each]
       
        "we are explicitly not using the default Collection>>difference: behavior here because we want to preserve the order of the collection"

Thanks,
Doru



On 16 May 2012, at 18:22, Ben Coman wrote:

> This discussion originates from Mondrian on Moose 4.7 where layouts which previously were exactly reproducible now randomly alternate between two arrangements.  I have cross-posted since upstream behaviour of Collection>>difference: has changed between Pharo 1.3 and 1.4.  
>
> The issue in Mondrian has been isolated so that it can be observed using the attached changeset 'isolate-unstable-972.2.cs' against a fresh Moose 4.7 image downloaded a few moments ago.
> After loading the cs, open a Transcript and then <Generate> the following script in Modrian Easel a dozen times.
>             view shape label.
>             view nodes: #(1 2 3 4 ).
>             view edgesFromAssociations: { 1 -> 2. 1 ->3 . 3 -> 4}.
>             view treeLayout
>
> At some point you will see a change in the order that nodes are drawn between runs as reflected in lines B2 and A2 shown below...
> ------------------------------RUN 1
> B1>an OrderedCollection(a MONode model: 2 a MONode model: 3)
> B2>an OrderedCollection(a MONode model: 3 a MONode model: 2)
> A2>a MONode model: 1
> A2>a MONode model: 3
> A2>a MONode model: 4
> A2>a MONode model: 2
> ------------------------------RUN 2
> B1>an OrderedCollection(a MONode model: 2 a MONode model: 3)
> B2>an OrderedCollection(a MONode model: 2 a MONode model: 3)
> A2>a MONode model: 1
> A2>a MONode model: 2
> A2>a MONode model: 3
> A2>a MONode model: 4
> ------------------------------END
>
>
> The cause of this is a change in behaviour of Collection>>#difference: between Pharo 1.3 & 1.4.  This can be observed by executing the following in Workspace...
>     20 timesRepeat:
>     [
>         one := TextMorph new newContents: '1'.
>         two := TextMorph new newContents: '2'.
>         collection := (OrderedCollection with: one with: two).
>         diff := collection difference: OrderedCollection new.
>        Transcript crShow: diff first text, diff second text.
>     ]
>
> In Pharo 1.3 the result never deviates from '12'.
> In Pharo 1.4 the result is sometimes '21'.
>
> Pharo 1.3 has...
> Collection>>difference: aCollection
>     "Answer the set theoretic difference of two collections."
>     ^ self reject: [:each | aCollection includes: each]
>
> Pharo 1.4 has...
> Collection>>difference: aCollection
>     "Answer the set theoretic difference of two collections."
>     | set|
>     set := self asSet.
>     aCollection do: [ :each|
>         set remove: each ifAbsent: []].
>     ^ self species withAll: set asArray
>
>
> Your thoughts?
>
> cheers -ben
>
>
> Tudor Girba wrote:
>> Could it be a Pharo issue, because I think it happened since we moved to Pharo 1.4.
>>
>> Doru
>>
>>
>> On 15 May 2012, at 21:51, Alexandre Bergel wrote:
>>
>>  
>>
>>> Well… this happens since the changes in the collection hierarchy a few weeks ago.
>>> The tree layout should indeed preserver the order. I spent some time but I could not see where the problem came from. I should spent some more time on this.
>>>
>>> Alexandre
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  
>>> http://www.bergel.eu
>>>
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>> On May 13, 2012, at 11:21 PM, Tudor Girba wrote:
>>>
>>>    
>>>
>>>> Thanks, Alex.
>>>>
>>>> But, it is not good in this case to fix the tests because the rendering should remain the same :(.
>>>>
>>>> For example, in the MetaBrowser I rely on the fact that the tree rendering remains the same to highlight the currently selected property.
>>>>
>>>> We need to investigate this issue closer because it is an important bug.
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>> On 14 May 2012, at 04:04, Alexandre Bergel wrote:
>>>>
>>>>      
>>>>
>>>>>>> I've seen you committed in the Mondrian rep about the rubber band drag and drop facilities. This is indeed an interesting feature. However, I feel a bit more work is necessary. Here are my suggestions:
>>>>>>>  - can you make sure all the Mondrian tests are green. Apparently MORoot>>resetFormCacheResursively disappeared.
>>>>>>>
>>>>>>>            
>>>>>>>
>>>>>> Do you mean MONode>>resetFormCacheResursively which was renamed in Mondrian-Core-AlexandreBergel.79 ?
>>>>>> I've searched back a few Mondrian-Core mcz files and not found MORoot>>resetFormCacheResursively.
>>>>>> I fixed a few remaining references to this in Mondrian-Core-BenComan.80 et al.
>>>>>>
>>>>>>          
>>>>>>
>>>>> Ok, I've produced a new version of Mondrian that includes your changes.
>>>>>
>>>>>        
>>>>>
>>>>>> I fixed MOLayoutTest>>testTreeLayout failure in Mondrian-Tests-BenComan.101.
>>>>>> There is one remaining failure that I can't work out. TestRunner cannot open a debugger on it and after inserting 'self halt' it steps through to the end of the method without a failure.  Makes no sense to me.  I need to leave this one to others.
>>>>>>
>>>>>>          
>>>>>>
>>>>> The tree layout seems to randomly order the nodes. Type the following script in an easel:
>>>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>>>>> view shape rectangle withText.
>>>>> view nodes: #(1 2 3 4 ).
>>>>> view edgesFromAssociations: { 1 -> 2. 1 ->3 . 3 -> 4}.
>>>>> view treeLayout
>>>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>>>>>
>>>>> Times to times it produces:
>>>>> <Screen Shot 2012-05-13 at 10.02.08 PM.png>
>>>>>
>>>>> times to times it produces:
>>>>> <Screen Shot 2012-05-13 at 10.02.16 PM.png>
>>>>>
>>>>> A few weeks ago, it had always produced the same rendering, and tests had been written accordingly. Now it varies, so tests have to be adjusted. I fixed this.
>>>>> The test is now green.
>>>>>        
>>>>>
>>>>>>>  - add new tests that capture your change of MOCanvas>>mouseUp: , MOCanvas>>mouseOver:, and possibly for MOCanvas>>drawOn:. Those methods are central to Mondrian, they need to be robust.
>>>>>>>            
>>>>>>>
>>>>>> I will now start thinking about some tests for these.
>>>>>>
>>>>>>          
>>>>>>
>>>>> Cool!
>>>>>
>>>>> Alexandre
>>>>>
>>>>>        
>>>>>
>>>>>>> Let me know how it goes. Currently the tests of Mondrian are yellow.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Alexandre
>>>>>>>
>>>>>>>
>>>>>>> On 8 May 2012, at 16:42,
>>>>>>>
>>>>>>> [hidden email]
>>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>            
>>>>>>>
>>>>>>>> See <http://hudson.moosetechnology.org/job/moose-latest-dev/972/>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Moose-dev mailing list
>>>>>>>>
>>>>>>>>
>>>>>>>> [hidden email]
>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>              
>>>>>>>>
>>>>>>>
>>>>>>>            
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>>
>>>>>> [hidden email]
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>
>>>>>>          
>>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>>
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>>        
>>>>>
>>>> --
>>>>
>>>> www.tudorgirba.com
>>>>
>>>>
>>>> "Don't give to get. Just give."
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>>
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>>      
>>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>>
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>    
>>>
>>
>> --
>>
>> www.tudorgirba.com
>>
>>
>> Innovation comes in least expected form.
>> That is, if it is expected, it already happened.
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>>
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>>  
>>
>
> 'From Pharo1.4 of 18 April 2012 [Latest update: #14438] on 16 May 2012 at 11:15:20 pm'!
>
> !MOAbstractRegularTreeLayout methodsFor: 'hook' stamp: 'BenComan 5/16/2012 23:14'!
> doExecute: node
> | rootNodes btcdebug|
> alreadyLayoutedNodes := OrderedCollection new.
> rootNodes := self rootNodesFor: node nodes.
> nodesByLayer := OrderedCollection new.
>
> self flag: #btcdebug.  
> "Regarding [hidden email] emails 'Jenkins build is still unstable: moose-latest-dev #972'
> To isolate the issue, open a Transcript then generate the following in Mondrian Easel twenty times
> view shape label.
> view nodes: #(1 2 3 4 ).
> view edgesFromAssociations: { 1 -> 2. 1 ->3 . 3 -> 4}.
> view treeLayout.
> "
> btcdebug := rootNodes first.
> Transcript cr; crShow: '------------------------------'.
> Transcript crShow: 'B1>', (self childrenFor: btcdebug) asString.
> Transcript crShow: 'B2>', (self computeChildrenFor: btcdebug) asString.
>
> self
> layout: rootNodes
> atPoint: self leftGap @ self topGap
> atLayer: 1.
> self isLayered ifTrue: [
> self rearrangeByLayers: node ]! !
>
>
> !MOAbstractVerticalTreeLayout methodsFor: 'hook-private' stamp: 'BenComan 5/16/2012 23:02'!
> layout: aNodeCollection atPoint: aPoint atLayer: aNumber
> | treeSize childrenPosition x y middleOfTree |
> aNodeCollection isEmpty ifTrue: [ ^ 0 ].
> x := aPoint x.
> y := aPoint y.
> alreadyLayoutedNodes addAll: aNodeCollection.
> self atLayer: aNumber add: aNodeCollection.
> aNodeCollection do: [ :each |
> self flag: #btcdebug. Transcript crShow: 'A2>', each asString.
> childrenPosition := y + each height + self verticalGap.
> treeSize := each width
> max: (self layout: (self computeChildrenFor: each) atPoint: x @ childrenPosition atLayer: aNumber + 1).
> middleOfTree := x + (treeSize / 2.0) - (each width / 2.0).
> each translateTo: middleOfTree @ y.
> x := x + treeSize + self horizontalGap ].
> ^ x - aPoint x - self horizontalGap! !
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"We cannot reach the flow of things unless we let go."




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Collection>>difference: behaviour in 1.4 (was Re: Jenkins build is still unstable: moose-latest-dev #972 )

Stéphane Ducasse
In reply to this post by Ben Coman
can you open a bug entry?

Stef

On May 16, 2012, at 6:22 PM, Ben Coman wrote:

> This discussion originates from Mondrian on Moose 4.7 where layouts which previously were exactly reproducible now randomly alternate between two arrangements.  I have cross-posted since upstream behaviour of Collection>>difference: has changed between Pharo 1.3 and 1.4.  
>
> The issue in Mondrian has been isolated so that it can be observed using the attached changeset 'isolate-unstable-972.2.cs' against a fresh Moose 4.7 image downloaded a few moments ago.
> After loading the cs, open a Transcript and then <Generate> the following script in Modrian Easel a dozen times.
>             view shape label.
>             view nodes: #(1 2 3 4 ).
>             view edgesFromAssociations: { 1 -> 2. 1 ->3 . 3 -> 4}.
>             view treeLayout
>
> At some point you will see a change in the order that nodes are drawn between runs as reflected in lines B2 and A2 shown below...
> ------------------------------RUN 1
> B1>an OrderedCollection(a MONode model: 2 a MONode model: 3)
> B2>an OrderedCollection(a MONode model: 3 a MONode model: 2)
> A2>a MONode model: 1
> A2>a MONode model: 3
> A2>a MONode model: 4
> A2>a MONode model: 2
> ------------------------------RUN 2
> B1>an OrderedCollection(a MONode model: 2 a MONode model: 3)
> B2>an OrderedCollection(a MONode model: 2 a MONode model: 3)
> A2>a MONode model: 1
> A2>a MONode model: 2
> A2>a MONode model: 3
> A2>a MONode model: 4
> ------------------------------END
>
>
> The cause of this is a change in behaviour of Collection>>#difference: between Pharo 1.3 & 1.4.  This can be observed by executing the following in Workspace...
>     20 timesRepeat:
>     [
>         one := TextMorph new newContents: '1'.
>         two := TextMorph new newContents: '2'.
>         collection := (OrderedCollection with: one with: two).
>         diff := collection difference: OrderedCollection new.
>        Transcript crShow: diff first text, diff second text.
>     ]
>
> In Pharo 1.3 the result never deviates from '12'.
> In Pharo 1.4 the result is sometimes '21'.
>
> Pharo 1.3 has...
> Collection>>difference: aCollection
>     "Answer the set theoretic difference of two collections."
>     ^ self reject: [:each | aCollection includes: each]
>
> Pharo 1.4 has...
> Collection>>difference: aCollection
>     "Answer the set theoretic difference of two collections."
>     | set|
>     set := self asSet.
>     aCollection do: [ :each|
>         set remove: each ifAbsent: []].
>     ^ self species withAll: set asArray
>
>
> Your thoughts?
>
> cheers -ben
>
>
> Tudor Girba wrote:
>> Could it be a Pharo issue, because I think it happened since we moved to Pharo 1.4.
>>
>> Doru
>>
>>
>> On 15 May 2012, at 21:51, Alexandre Bergel wrote:
>>
>>  
>>
>>> Well… this happens since the changes in the collection hierarchy a few weeks ago.
>>> The tree layout should indeed preserver the order. I spent some time but I could not see where the problem came from. I should spent some more time on this.
>>>
>>> Alexandre
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  
>>> http://www.bergel.eu
>>>
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>> On May 13, 2012, at 11:21 PM, Tudor Girba wrote:
>>>
>>>    
>>>
>>>> Thanks, Alex.
>>>>
>>>> But, it is not good in this case to fix the tests because the rendering should remain the same :(.
>>>>
>>>> For example, in the MetaBrowser I rely on the fact that the tree rendering remains the same to highlight the currently selected property.
>>>>
>>>> We need to investigate this issue closer because it is an important bug.
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>> On 14 May 2012, at 04:04, Alexandre Bergel wrote:
>>>>
>>>>      
>>>>
>>>>>>> I've seen you committed in the Mondrian rep about the rubber band drag and drop facilities. This is indeed an interesting feature. However, I feel a bit more work is necessary. Here are my suggestions:
>>>>>>>  - can you make sure all the Mondrian tests are green. Apparently MORoot>>resetFormCacheResursively disappeared.
>>>>>>>
>>>>>>>            
>>>>>>>
>>>>>> Do you mean MONode>>resetFormCacheResursively which was renamed in Mondrian-Core-AlexandreBergel.79 ?
>>>>>> I've searched back a few Mondrian-Core mcz files and not found MORoot>>resetFormCacheResursively.
>>>>>> I fixed a few remaining references to this in Mondrian-Core-BenComan.80 et al.
>>>>>>
>>>>>>          
>>>>>>
>>>>> Ok, I've produced a new version of Mondrian that includes your changes.
>>>>>
>>>>>        
>>>>>
>>>>>> I fixed MOLayoutTest>>testTreeLayout failure in Mondrian-Tests-BenComan.101.
>>>>>> There is one remaining failure that I can't work out. TestRunner cannot open a debugger on it and after inserting 'self halt' it steps through to the end of the method without a failure.  Makes no sense to me.  I need to leave this one to others.
>>>>>>
>>>>>>          
>>>>>>
>>>>> The tree layout seems to randomly order the nodes. Type the following script in an easel:
>>>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>>>>> view shape rectangle withText.
>>>>> view nodes: #(1 2 3 4 ).
>>>>> view edgesFromAssociations: { 1 -> 2. 1 ->3 . 3 -> 4}.
>>>>> view treeLayout
>>>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>>>>>
>>>>> Times to times it produces:
>>>>> <Screen Shot 2012-05-13 at 10.02.08 PM.png>
>>>>>
>>>>> times to times it produces:
>>>>> <Screen Shot 2012-05-13 at 10.02.16 PM.png>
>>>>>
>>>>> A few weeks ago, it had always produced the same rendering, and tests had been written accordingly. Now it varies, so tests have to be adjusted. I fixed this.
>>>>> The test is now green.
>>>>>        
>>>>>
>>>>>>>  - add new tests that capture your change of MOCanvas>>mouseUp: , MOCanvas>>mouseOver:, and possibly for MOCanvas>>drawOn:. Those methods are central to Mondrian, they need to be robust.
>>>>>>>            
>>>>>>>
>>>>>> I will now start thinking about some tests for these.
>>>>>>
>>>>>>          
>>>>>>
>>>>> Cool!
>>>>>
>>>>> Alexandre
>>>>>
>>>>>        
>>>>>
>>>>>>> Let me know how it goes. Currently the tests of Mondrian are yellow.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Alexandre
>>>>>>>
>>>>>>>
>>>>>>> On 8 May 2012, at 16:42,
>>>>>>>
>>>>>>> [hidden email]
>>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>            
>>>>>>>
>>>>>>>> See <http://hudson.moosetechnology.org/job/moose-latest-dev/972/>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Moose-dev mailing list
>>>>>>>>
>>>>>>>>
>>>>>>>> [hidden email]
>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>              
>>>>>>>>
>>>>>>>
>>>>>>>            
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>>
>>>>>> [hidden email]
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>
>>>>>>          
>>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>>
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>>        
>>>>>
>>>> --
>>>>
>>>> www.tudorgirba.com
>>>>
>>>>
>>>> "Don't give to get. Just give."
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>>
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>>      
>>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>>
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>    
>>>
>>
>> --
>>
>> www.tudorgirba.com
>>
>>
>> Innovation comes in least expected form.
>> That is, if it is expected, it already happened.
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>>
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>>  
>>
>
> 'From Pharo1.4 of 18 April 2012 [Latest update: #14438] on 16 May 2012 at 11:15:20 pm'!
>
> !MOAbstractRegularTreeLayout methodsFor: 'hook' stamp: 'BenComan 5/16/2012 23:14'!
> doExecute: node
> | rootNodes btcdebug|
> alreadyLayoutedNodes := OrderedCollection new.
> rootNodes := self rootNodesFor: node nodes.
> nodesByLayer := OrderedCollection new.
>
> self flag: #btcdebug.  
> "Regarding [hidden email] emails 'Jenkins build is still unstable: moose-latest-dev #972'
> To isolate the issue, open a Transcript then generate the following in Mondrian Easel twenty times
> view shape label.
> view nodes: #(1 2 3 4 ).
> view edgesFromAssociations: { 1 -> 2. 1 ->3 . 3 -> 4}.
> view treeLayout.
> "
> btcdebug := rootNodes first.
> Transcript cr; crShow: '------------------------------'.
> Transcript crShow: 'B1>', (self childrenFor: btcdebug) asString.
> Transcript crShow: 'B2>', (self computeChildrenFor: btcdebug) asString.
>
> self
> layout: rootNodes
> atPoint: self leftGap @ self topGap
> atLayer: 1.
> self isLayered ifTrue: [
> self rearrangeByLayers: node ]! !
>
>
> !MOAbstractVerticalTreeLayout methodsFor: 'hook-private' stamp: 'BenComan 5/16/2012 23:02'!
> layout: aNodeCollection atPoint: aPoint atLayer: aNumber
> | treeSize childrenPosition x y middleOfTree |
> aNodeCollection isEmpty ifTrue: [ ^ 0 ].
> x := aPoint x.
> y := aPoint y.
> alreadyLayoutedNodes addAll: aNodeCollection.
> self atLayer: aNumber add: aNodeCollection.
> aNodeCollection do: [ :each |
> self flag: #btcdebug. Transcript crShow: 'A2>', each asString.
> childrenPosition := y + each height + self verticalGap.
> treeSize := each width
> max: (self layout: (self computeChildrenFor: each) atPoint: x @ childrenPosition atLayer: aNumber + 1).
> middleOfTree := x + (treeSize / 2.0) - (each width / 2.0).
> each translateTo: middleOfTree @ y.
> x := x + treeSize + self horizontalGap ].
> ^ x - aPoint x - self horizontalGap! !
>


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Jenkins build is still unstable: moose-latest-dev #985

admin-2
In reply to this post by admin-2
Reply | Threaded
Open this post in threaded view
|

Re: Collection>>difference: behaviour in 1.4 (was Re: Jenkins build is still unstable: moose-latest-dev #972 )

abergel
In reply to this post by Tudor Girba-2
Well done Ben!!! 
Thanks Doru for producing a new version of of the layout. It is now in the version 2.157 of Mondrian.

Cheers,
Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



On May 16, 2012, at 2:44 PM, Tudor Girba wrote:

Excellent hunting!

I think this is a conceptual bug in the current Pharo implementation.

Anyway, I fixed it now (and added a comment):

MOAbstractGraphLayout>>childrenFor: aNode except: aNodeCollection

^(self childrenFor: aNode)
reject: [:each | aNodeCollection includes: each]

"we are explicitly not using the default Collection>>difference: behavior here because we want to preserve the order of the collection"

Thanks,
Doru



On 16 May 2012, at 18:22, Ben Coman wrote:

This discussion originates from Mondrian on Moose 4.7 where layouts which previously were exactly reproducible now randomly alternate between two arrangements.  I have cross-posted since upstream behaviour of Collection>>difference: has changed between Pharo 1.3 and 1.4.   

The issue in Mondrian has been isolated so that it can be observed using the attached changeset 'isolate-unstable-972.2.cs' against a fresh Moose 4.7 image downloaded a few moments ago.
After loading the cs, open a Transcript and then <Generate> the following script in Modrian Easel a dozen times.
           view shape label.
           view nodes: #(1 2 3 4 ).
           view edgesFromAssociations: { 1 -> 2. 1 ->3 . 3 -> 4}.
           view treeLayout

At some point you will see a change in the order that nodes are drawn between runs as reflected in lines B2 and A2 shown below...
------------------------------RUN 1
B1>an OrderedCollection(a MONode model: 2 a MONode model: 3)
B2>an OrderedCollection(a MONode model: 3 a MONode model: 2)
A2>a MONode model: 1
A2>a MONode model: 3
A2>a MONode model: 4
A2>a MONode model: 2
------------------------------RUN 2
B1>an OrderedCollection(a MONode model: 2 a MONode model: 3)
B2>an OrderedCollection(a MONode model: 2 a MONode model: 3)
A2>a MONode model: 1
A2>a MONode model: 2
A2>a MONode model: 3
A2>a MONode model: 4
------------------------------END


The cause of this is a change in behaviour of Collection>>#difference: between Pharo 1.3 & 1.4.  This can be observed by executing the following in Workspace...
   20 timesRepeat:
   [
       one := TextMorph new newContents: '1'.
       two := TextMorph new newContents: '2'.
       collection := (OrderedCollection with: one with: two).
       diff := collection difference: OrderedCollection new.
      Transcript crShow: diff first text, diff second text.
   ]

In Pharo 1.3 the result never deviates from '12'.
In Pharo 1.4 the result is sometimes '21'.

Pharo 1.3 has...
Collection>>difference: aCollection
   "Answer the set theoretic difference of two collections."
   ^ self reject: [:each | aCollection includes: each]

Pharo 1.4 has...
Collection>>difference: aCollection
   "Answer the set theoretic difference of two collections."
   | set|
   set := self asSet.
   aCollection do: [ :each|
       set remove: each ifAbsent: []].
   ^ self species withAll: set asArray


Your thoughts?

cheers -ben


Tudor Girba wrote:
Could it be a Pharo issue, because I think it happened since we moved to Pharo 1.4.

Doru


On 15 May 2012, at 21:51, Alexandre Bergel wrote:



Well… this happens since the changes in the collection hierarchy a few weeks ago.
The tree layout should indeed preserver the order. I spent some time but I could not see where the problem came from. I should spent some more time on this.

Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  
http://www.bergel.eu

^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



On May 13, 2012, at 11:21 PM, Tudor Girba wrote:



Thanks, Alex.

But, it is not good in this case to fix the tests because the rendering should remain the same :(.

For example, in the MetaBrowser I rely on the fact that the tree rendering remains the same to highlight the currently selected property.

We need to investigate this issue closer because it is an important bug.

Cheers,
Doru


On 14 May 2012, at 04:04, Alexandre Bergel wrote:



I've seen you committed in the Mondrian rep about the rubber band drag and drop facilities. This is indeed an interesting feature. However, I feel a bit more work is necessary. Here are my suggestions:
- can you make sure all the Mondrian tests are green. Apparently MORoot>>resetFormCacheResursively disappeared.



Do you mean MONode>>resetFormCacheResursively which was renamed in Mondrian-Core-AlexandreBergel.79 ?
I've searched back a few Mondrian-Core mcz files and not found MORoot>>resetFormCacheResursively.
I fixed a few remaining references to this in Mondrian-Core-BenComan.80 et al.



Ok, I've produced a new version of Mondrian that includes your changes.



I fixed MOLayoutTest>>testTreeLayout failure in Mondrian-Tests-BenComan.101.
There is one remaining failure that I can't work out. TestRunner cannot open a debugger on it and after inserting 'self halt' it steps through to the end of the method without a failure.  Makes no sense to me.  I need to leave this one to others.



The tree layout seems to randomly order the nodes. Type the following script in an easel:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
view shape rectangle withText.
view nodes: #(1 2 3 4 ).
view edgesFromAssociations: { 1 -> 2. 1 ->3 . 3 -> 4}.
view treeLayout
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Times to times it produces:
<Screen Shot 2012-05-13 at 10.02.08 PM.png>

times to times it produces:
<Screen Shot 2012-05-13 at 10.02.16 PM.png>

A few weeks ago, it had always produced the same rendering, and tests had been written accordingly. Now it varies, so tests have to be adjusted. I fixed this.
The test is now green.


- add new tests that capture your change of MOCanvas>>mouseUp: , MOCanvas>>mouseOver:, and possibly for MOCanvas>>drawOn:. Those methods are central to Mondrian, they need to be robust.


I will now start thinking about some tests for these.



Cool!

Alexandre



Let me know how it goes. Currently the tests of Mondrian are yellow.

Cheers,
Alexandre


On 8 May 2012, at 16:42,

[hidden email]

wrote:





See <http://hudson.moosetechnology.org/job/moose-latest-dev/972/>




_______________________________________________
Moose-dev mailing list


[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev









_______________________________________________
Moose-dev mailing list

[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev



_______________________________________________
Moose-dev mailing list

[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev



--

www.tudorgirba.com


"Don't give to get. Just give."






_______________________________________________
Moose-dev mailing list

[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev



_______________________________________________
Moose-dev mailing list

[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--

www.tudorgirba.com


Innovation comes in least expected form.
That is, if it is expected, it already happened.


_______________________________________________
Moose-dev mailing list

[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev





'From Pharo1.4 of 18 April 2012 [Latest update: #14438] on 16 May 2012 at 11:15:20 pm'!

!MOAbstractRegularTreeLayout methodsFor: 'hook' stamp: 'BenComan 5/16/2012 23:14'!
doExecute: node
| rootNodes btcdebug|
alreadyLayoutedNodes := OrderedCollection new.
rootNodes := self rootNodesFor: node nodes.
nodesByLayer := OrderedCollection new.

self flag: #btcdebug.  
"Regarding [hidden email] emails 'Jenkins build is still unstable: moose-latest-dev #972'
To isolate the issue, open a Transcript then generate the following in Mondrian Easel twenty times
view shape label.
view nodes: #(1 2 3 4 ).
view edgesFromAssociations: { 1 -> 2. 1 ->3 . 3 -> 4}.
view treeLayout.
"
btcdebug := rootNodes first.
Transcript cr; crShow: '------------------------------'.
Transcript crShow: 'B1>', (self childrenFor: btcdebug) asString.
Transcript crShow: 'B2>', (self computeChildrenFor: btcdebug) asString.

self
layout: rootNodes
atPoint: self leftGap @ self topGap
atLayer: 1.
self isLayered ifTrue: [
self rearrangeByLayers: node ]! !


!MOAbstractVerticalTreeLayout methodsFor: 'hook-private' stamp: 'BenComan 5/16/2012 23:02'!
layout: aNodeCollection atPoint: aPoint atLayer: aNumber
| treeSize childrenPosition x y middleOfTree |
aNodeCollection isEmpty ifTrue: [ ^ 0 ].
x := aPoint x.
y := aPoint y.
alreadyLayoutedNodes addAll: aNodeCollection.
self atLayer: aNumber add: aNodeCollection.
aNodeCollection do: [ :each |
self flag: #btcdebug. Transcript crShow: 'A2>', each asString.
childrenPosition := y + each height + self verticalGap.
treeSize := each width
max: (self layout: (self computeChildrenFor: each) atPoint: x @ childrenPosition atLayer: aNumber + 1).
middleOfTree := x + (treeSize / 2.0) - (each width / 2.0).
each translateTo: middleOfTree @ y.
x := x + treeSize + self horizontalGap ].
^ x - aPoint x - self horizontalGap! !

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"We cannot reach the flow of things unless we let go."




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Jenkins build is still unstable: moose-latest-dev #986

admin-2
In reply to this post by admin-2
Reply | Threaded
Open this post in threaded view
|

Jenkins build is still unstable: moose-latest-dev #987

admin-2
123