I'm running with Compiler-nice.274.
What's weirder is in that top stack frame (Compiler >> #evaluate:in:to:notifying:ifFailed:logged: the following all show up as red, because they're references to instvars that don't exist: class, sourceStream, context, requestor.
That's because the CompiledMethod that's running is not actually the right CompiledMethod! It's from some ancient pre-CompilationCue Compiler instance. Or at least so I suspect because that Compiler instance has a nil 'cue' instvar.
If it helps, the PointerFinder says this of the offending context:
globals: Environment declarations: IdentityDictionary #World -> PasteUpMorph submorphs: Array 1: SystemWindow model: ObjectExplorer currentSelection: ObjectExplorerWrapper item: CompiledMethod
In contrast, PointerFinder on: (Compiler >> #evaluate:in:to:notifying:ifFail:logged:) says:
CLASS: SmalltalkImage class superclass: Object class subclasses: Array 445: Compiler class methodDict: MethodDictionary array: Array 39: CompiledMethod.
Here's the stack trace:
25 September 2013 11:02:59.952 am
VM: unix - Smalltalk Image: Squeak4.5 [latest update: #13159]
SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir /home/frank/Documents/squeak-ci/target Trusted Dir /home/frank/Documents/squeak-ci/target/secure Untrusted Dir /home/frank/Documents/squeak-ci/target/My Squeak
Parser(Object)>>doesNotUnderstand: #contents Receiver: a Parser Arguments and temporary variables: aMessage: contents exception: MessageNotUnderstood: Parser>>contents resumeValue: nil Receiver's instance variables: source: a ReadStream mark: 3360 hereChar: $ aheadChar: $ token: #'' tokenType: #doIt currentComment: nil buffer: a WriteStream typeTable: #(#xBinary #xBinary #xBinary #xBinary #xBinary #xBinary #xBinary #xB...etc... here: #'' hereType: #doIt hereMark: 3360 hereEnd: 3359 prevMark: 3358 prevEnd: 3358 encoder: {an EncoderForV3PlusClosures} parseNode: {[^ [| config manifest | (FileDirectory default / '..' readOnlyFile...etc... failBlock: [closure] in Compiler>>translate:noPattern:ifFail: requestorOffset: 0 tempsMark: 1 doitFlag: true properties: an AdditionalMethodState (1229) queriedUnusedTemporaries: nil cue: nil
Compiler>>evaluate:in:to:notifying:ifFail:logged: Receiver: a Compiler Arguments and temporary variables: textOrStream: '[| config manifest | ((FileDirectory default / ''..'') readOnlyF...etc... aContext: nil receiver: nil aRequestor: nil failBlock: [closure] in Compiler class>>evaluate:for:notifying:logged: logFlag: true methodNode: DoIt ^ [| config manifest | (FileDirectory default / '..' readOnl...etc... method: (UndefinedObject>>#DoIt "a CompiledMethod(959)") value: WorldState toLog: nil itsSelection: nil itsSelectionString: nil Receiver's instance variables: parser: a Parser cue: nil
Compiler class>>evaluate:for:notifying:logged: Receiver: Compiler Arguments and temporary variables: textOrString: '[| config manifest | ((FileDirectory default / ''..'') readOnlyF...etc... anObject: nil aController: nil logFlag: true Receiver's instance variables: superclass: Object methodDict: a MethodDictionary(#compile:ifFail:->(Compiler>>#compile:ifFail: "a...etc... format: 134 instanceVariables: #('parser' 'cue') organization: ('public access' compile:ifFail: compile:in:notifying:ifFail: com...etc... subclasses: nil name: #Compiler classPool: a Dictionary() sharedPools: nil environment: Smalltalk category: #'Compiler-Kernel'
Compiler class>>evaluate:for:logged: Receiver: Compiler Arguments and temporary variables: textOrString: '[| config manifest | ((FileDirectory default / ''..'') readOnlyF...etc... anObject: nil logFlag: true Receiver's instance variables: superclass: Object methodDict: a MethodDictionary(#compile:ifFail:->(Compiler>>#compile:ifFail: "a...etc... format: 134 instanceVariables: #('parser' 'cue') organization: ('public access' compile:ifFail: compile:in:notifying:ifFail: com...etc... subclasses: nil name: #Compiler classPool: a Dictionary() sharedPools: nil environment: Smalltalk category: #'Compiler-Kernel'
Compiler class>>evaluate:logged: Receiver: Compiler Arguments and temporary variables: textOrString: '[| config manifest | ((FileDirectory default / ''..'') readOnlyF...etc... logFlag: true Receiver's instance variables: superclass: Object methodDict: a MethodDictionary(#compile:ifFail:->(Compiler>>#compile:ifFail: "a...etc... format: 134 instanceVariables: #('parser' 'cue') organization: ('public access' compile:ifFail: compile:in:notifying:ifFail: com...etc... subclasses: nil name: #Compiler classPool: a Dictionary() sharedPools: nil environment: Smalltalk category: #'Compiler-Kernel'
[] in [] in RWBinaryOrTextStream(PositionableStream)>>fileInAnnouncing: Receiver: a RWBinaryOrTextStream Arguments and temporary variables: <<error during printing> Receiver's instance variables: collection: '[| config manifest | ((FileDirectory default / ''..'') readOnlyFil...etc... position: 3359 readLimit: 3359 writeLimit: 3359 isBinary: false
BlockClosure>>on:do: Receiver: [closure] in [] in RWBinaryOrTextStream(PositionableStream)>>fileInAnnouncing: Arguments and temporary variables: exception: InMidstOfFileinNotification handlerAction: [closure] in [] in RWBinaryOrTextStream(PositionableStream)>>fil...etc... handlerActive: true Receiver's instance variables: outerContext: [] in RWBinaryOrTextStream(PositionableStream)>>fileInAnnouncing:...etc... startpc: 146 numArgs: 0
[] in RWBinaryOrTextStream(PositionableStream)>>fileInAnnouncing: Receiver: a RWBinaryOrTextStream Arguments and temporary variables: <<error during printing> Receiver's instance variables: collection: '[| config manifest | ((FileDirectory default / ''..'') readOnlyFil...etc... position: 3359 readLimit: 3359 writeLimit: 3359 isBinary: false
[] in [] in MorphicUIManager>>displayProgress:at:from:to:during: Receiver: a MorphicUIManager Arguments and temporary variables: <<error during printing> Receiver's instance variables: toolBuilder: nil
BlockClosure>>on:do: Receiver: [closure] in [] in MorphicUIManager>>displayProgress:at:from:to:during: Arguments and temporary variables: exception: ProgressNotification handlerAction: [closure] in [] in MorphicUIManager>>displayProgress:at:from:to:...etc... handlerActive: true Receiver's instance variables: outerContext: [] in MorphicUIManager>>displayProgress:at:from:to:during: startpc: 86 numArgs: 0
[] in MorphicUIManager>>displayProgress:at:from:to:during: Receiver: a MorphicUIManager Arguments and temporary variables: <<error during printing> Receiver's instance variables: toolBuilder: nil
BlockClosure>>ensure: Receiver: [closure] in MorphicUIManager>>displayProgress:at:from:to:during: Arguments and temporary variables: aBlock: [closure] in MorphicUIManager>>displayProgress:at:from:to:during: complete: nil returnValue: nil Receiver's instance variables: outerContext: MorphicUIManager>>displayProgress:at:from:to:during: startpc: 79 numArgs: 0
MorphicUIManager>>displayProgress:at:from:to:during: Receiver: a MorphicUIManager Arguments and temporary variables: titleString: 'Reading a stream' aPoint: 400@300 minVal: 0 maxVal: 3359 workBlock: [closure] in RWBinaryOrTextStream(PositionableStream)>>fileInAnnounc...etc... progress: [closure] in SystemProgressMorph>>position:label:min:max: result: #(nil) Receiver's instance variables: toolBuilder: nil
ProgressInitiationException>>defaultResumeValue Receiver: ProgressInitiationException: Arguments and temporary variables:
Receiver's instance variables: messageText: nil tag: nil signalContext: ProgressInitiationException(Exception)>>signal handlerContext: nil outerContext: nil workBlock: [closure] in RWBinaryOrTextStream(PositionableStream)>>fileInAnnounc...etc... maxVal: 3359 minVal: 0 aPoint: 400@300 progressTitle: 'Reading a stream'
ProgressInitiationException(Exception)>>resume Receiver: ProgressInitiationException: Arguments and temporary variables:
Receiver's instance variables: messageText: nil tag: nil signalContext: ProgressInitiationException(Exception)>>signal handlerContext: nil outerContext: nil workBlock: [closure] in RWBinaryOrTextStream(PositionableStream)>>fileInAnnounc...etc... maxVal: 3359 minVal: 0 aPoint: 400@300 progressTitle: 'Reading a stream'
ProgressInitiationException>>defaultAction Receiver: ProgressInitiationException: Arguments and temporary variables:
Receiver's instance variables: messageText: nil tag: nil signalContext: ProgressInitiationException(Exception)>>signal handlerContext: nil outerContext: nil workBlock: [closure] in RWBinaryOrTextStream(PositionableStream)>>fileInAnnounc...etc... maxVal: 3359 minVal: 0 aPoint: 400@300 progressTitle: 'Reading a stream'
UndefinedObject>>handleSignal: Receiver: nil Arguments and temporary variables: exception: ProgressInitiationException: Receiver's instance variables: nil
ProgressInitiationException(Exception)>>signal Receiver: ProgressInitiationException: Arguments and temporary variables:
Receiver's instance variables: messageText: nil tag: nil signalContext: ProgressInitiationException(Exception)>>signal handlerContext: nil outerContext: nil workBlock: [closure] in RWBinaryOrTextStream(PositionableStream)>>fileInAnnounc...etc... maxVal: 3359 minVal: 0 aPoint: 400@300 progressTitle: 'Reading a stream'
ProgressInitiationException>>display:at:from:to:during: Receiver: ProgressInitiationException: Arguments and temporary variables: argString: 'Reading a stream' argPoint: 400@300 argMinVal: 0 argMaxVal: 3359 argWorkBlock: [closure] in RWBinaryOrTextStream(PositionableStream)>>fileInAnno...etc... Receiver's instance variables: messageText: nil tag: nil signalContext: ProgressInitiationException(Exception)>>signal handlerContext: nil outerContext: nil workBlock: [closure] in RWBinaryOrTextStream(PositionableStream)>>fileInAnnounc...etc... maxVal: 3359 minVal: 0 aPoint: 400@300 progressTitle: 'Reading a stream'
--- The full stack --- Parser(Object)>>doesNotUnderstand: #contents Compiler>>evaluate:in:to:notifying:ifFail:logged: Compiler class>>evaluate:for:notifying:logged: Compiler class>>evaluate:for:logged: Compiler class>>evaluate:logged: [] in [] in RWBinaryOrTextStream(PositionableStream)>>fileInAnnouncing: BlockClosure>>on:do: [] in RWBinaryOrTextStream(PositionableStream)>>fileInAnnouncing: [] in [] in MorphicUIManager>>displayProgress:at:from:to:during: BlockClosure>>on:do: [] in MorphicUIManager>>displayProgress:at:from:to:during: BlockClosure>>ensure: MorphicUIManager>>displayProgress:at:from:to:during: ProgressInitiationException>>defaultResumeValue ProgressInitiationException(Exception)>>resume ProgressInitiationException>>defaultAction UndefinedObject>>handleSignal: ProgressInitiationException(Exception)>>signal ProgressInitiationException>>display:at:from:to:during: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ProgressInitiationException class>>display:at:from:to:during: ByteString(String)>>displayProgressAt:from:to:during: ByteString(String)>>displayProgressFrom:to:during: RWBinaryOrTextStream(PositionableStream)>>fileInAnnouncing: RWBinaryOrTextStream(PositionableStream)>>fileIn CodeLoader>>installSourceFile: [] in CodeLoader>>installSourceFiles Array(SequenceableCollection)>>do: CodeLoader>>installSourceFiles ProjectLauncher>>startUpAfterLogin ProjectLauncher>>startUp [] in [] in [] in AutoStart class>>startUp: WorldState>>runStepMethodsIn: PasteUpMorph>>runStepMethods WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: PasteUpMorph>>doOneCycle [] in Project class>>spawnNewProcess [] in BlockClosure>>newProcess
If you inspect
PositionableStream>>#fileInAnnouncing:
and look at the literal for Compiler, does it look to be pointing to the new or old Compiler?
Cheers, Bob
On 9/25/13 6:12 AM, Frank Shearar wrote:
I'm running with Compiler-nice.274.
What's weirder is in that top stack frame (Compiler >> #evaluate:in:to:notifying:ifFailed:logged: the following all show up as red, because they're references to instvars that don't exist: class, sourceStream, context, requestor.
That's because the CompiledMethod that's running is not actually the right CompiledMethod! It's from some ancient pre-CompilationCue Compiler instance. Or at least so I suspect because that Compiler instance has a nil 'cue' instvar.
If it helps, the PointerFinder says this of the offending context:
globals: Environment declarations: IdentityDictionary #World -> PasteUpMorph submorphs: Array 1: SystemWindow model: ObjectExplorer currentSelection: ObjectExplorerWrapper item: CompiledMethod
In contrast, PointerFinder on: (Compiler >> #evaluate:in:to:notifying:ifFail:logged:) says:
CLASS: SmalltalkImage class superclass: Object class subclasses: Array 445: Compiler class methodDict: MethodDictionary array: Array 39: CompiledMethod.
I don't know how I would do that. The bytecode just says pushLit: Compiler.
But if I say Compiler allInstances collect: [:c | c instVarNamed: 'cue'] I see {nil . a CompilationCue . a CompilationCue}. That first one's a problem! Further, my image has an ObjectExplorer (!) hanging onto that Compiler, coming from I don't know where.
frank
On 25 September 2013 11:53, Bob Arning arning315@comcast.net wrote:
If you inspect
PositionableStream>>#fileInAnnouncing:
and look at the literal for Compiler, does it look to be pointing to the new or old Compiler?
Cheers, Bob
On 9/25/13 6:12 AM, Frank Shearar wrote:
I'm running with Compiler-nice.274.
What's weirder is in that top stack frame (Compiler >> #evaluate:in:to:notifying:ifFailed:logged: the following all show up as red, because they're references to instvars that don't exist: class, sourceStream, context, requestor.
That's because the CompiledMethod that's running is not actually the right CompiledMethod! It's from some ancient pre-CompilationCue Compiler instance. Or at least so I suspect because that Compiler instance has a nil 'cue' instvar.
If it helps, the PointerFinder says this of the offending context:
globals: Environment declarations: IdentityDictionary #World -> PasteUpMorph submorphs: Array 1: SystemWindow model: ObjectExplorer currentSelection: ObjectExplorerWrapper item: CompiledMethod
In contrast, PointerFinder on: (Compiler >> #evaluate:in:to:notifying:ifFail:logged:) says:
CLASS: SmalltalkImage class superclass: Object class subclasses: Array 445: Compiler class methodDict: MethodDictionary array: Array 39: CompiledMethod.
Just type
PositionableStream>>#fileInAnnouncing:
and explore it. Look for the literal pointing to the compiler (literal8 here). Toggle that open and toggle open the value. Look at the instanceVariables - does it still have sourceStream?
As to the explorer, did you open one? Is it still open? (The PointerFinder says it is) Could it have been open when the image was last saved?
Also, you could do
Behavior allSubInstances select: [ :e | (e asString findString: 'Compiler') > 0]
Do you get: an OrderedCollection(ClosureCompilerTest CompilerTest CompilerExceptionsTest CompilerNotifyingTest CompilerSyntaxErrorNotifyingTest Compiler ClosureCompilerTest class CompilerTest class CompilerExceptionsTest class CompilerNotifyingTest class CompilerSyntaxErrorNotifyingTest class Compiler class)
Cheers, Bob
On 9/25/13 7:31 AM, Frank Shearar wrote:
I don't know how I would do that. The bytecode just says pushLit: Compiler.
But if I say Compiler allInstances collect: [:c | c instVarNamed: 'cue'] I see {nil . a CompilationCue . a CompilationCue}. That first one's a problem! Further, my image has an ObjectExplorer (!) hanging onto that Compiler, coming from I don't know where.
frank
On 25 September 2013 11:53, Bob Arning arning315@comcast.net wrote:
If you inspect
PositionableStream>>#fileInAnnouncing:
and look at the literal for Compiler, does it look to be pointing to the new or old Compiler?
Cheers, Bob
On 9/25/13 6:12 AM, Frank Shearar wrote:
I'm running with Compiler-nice.274.
What's weirder is in that top stack frame (Compiler >> #evaluate:in:to:notifying:ifFailed:logged: the following all show up as red, because they're references to instvars that don't exist: class, sourceStream, context, requestor.
That's because the CompiledMethod that's running is not actually the right CompiledMethod! It's from some ancient pre-CompilationCue Compiler instance. Or at least so I suspect because that Compiler instance has a nil 'cue' instvar.
If it helps, the PointerFinder says this of the offending context:
globals: Environment declarations: IdentityDictionary #World -> PasteUpMorph submorphs: Array 1: SystemWindow model: ObjectExplorer currentSelection: ObjectExplorerWrapper item: CompiledMethod
In contrast, PointerFinder on: (Compiler >> #evaluate:in:to:notifying:ifFail:logged:) says:
CLASS: SmalltalkImage class superclass: Object class subclasses: Array 445: Compiler class methodDict: MethodDictionary array: Array 39: CompiledMethod.
On 25 September 2013 13:02, Bob Arning arning315@comcast.net wrote:
Just type
PositionableStream>>#fileInAnnouncing:
and explore it. Look for the literal pointing to the compiler (literal8 here). Toggle that open and toggle open the value. Look at the instanceVariables - does it still have sourceStream?
Right. I might even have done that if my brain had been working. So exploring PositionableStream>>#fileInAnnouncing: tells me that Compiler resolves to the default environment's (so Smalltalk) Compiler, as it should. It _won't_ show the instvar though, because that's Compiler class, not an instance of Compiler. Following the chain though, that particular Compiler's #evaluate:in:to:notifying:ifFail:logged: shows the correct content.
As to the explorer, did you open one? Is it still open? (The PointerFinder says it is) Could it have been open when the image was last saved?
Also, you could do
Behavior allSubInstances select: [ :e | (e asString findString: 'Compiler')
0]
Do you get: an OrderedCollection(ClosureCompilerTest CompilerTest CompilerExceptionsTest CompilerNotifyingTest CompilerSyntaxErrorNotifyingTest Compiler ClosureCompilerTest class CompilerTest class CompilerExceptionsTest class CompilerNotifyingTest class CompilerSyntaxErrorNotifyingTest class Compiler class)
I get the same.
frank
Cheers, Bob
On 9/25/13 7:31 AM, Frank Shearar wrote:
I don't know how I would do that. The bytecode just says pushLit: Compiler.
But if I say Compiler allInstances collect: [:c | c instVarNamed: 'cue'] I see {nil . a CompilationCue . a CompilationCue}. That first one's a problem! Further, my image has an ObjectExplorer (!) hanging onto that Compiler, coming from I don't know where.
frank
On 25 September 2013 11:53, Bob Arning arning315@comcast.net wrote:
If you inspect
PositionableStream>>#fileInAnnouncing:
and look at the literal for Compiler, does it look to be pointing to the new or old Compiler?
Cheers, Bob
On 9/25/13 6:12 AM, Frank Shearar wrote:
I'm running with Compiler-nice.274.
What's weirder is in that top stack frame (Compiler >> #evaluate:in:to:notifying:ifFailed:logged: the following all show up as red, because they're references to instvars that don't exist: class, sourceStream, context, requestor.
That's because the CompiledMethod that's running is not actually the right CompiledMethod! It's from some ancient pre-CompilationCue Compiler instance. Or at least so I suspect because that Compiler instance has a nil 'cue' instvar.
If it helps, the PointerFinder says this of the offending context:
globals: Environment declarations: IdentityDictionary #World -> PasteUpMorph submorphs: Array 1: SystemWindow model: ObjectExplorer currentSelection: ObjectExplorerWrapper item: CompiledMethod
In contrast, PointerFinder on: (Compiler >> #evaluate:in:to:notifying:ifFail:logged:) says:
CLASS: SmalltalkImage class superclass: Object class subclasses: Array 445: Compiler class methodDict: MethodDictionary array: Array 39: CompiledMethod.
I didn't open an ObjectExplorer until I started digging. It's vaguely conceivable that there was an ObjectExplorer already existing, but that would mean that the official 4.4-12327 image has one. We can check that, but I doubt it will. (Context: this particular image is the official 4.4-12327, updated to trunk through the CI job's update-image.st, and then released through same's release.st. All automatic, no user input.)
By instanceVariables, I meant in the class definition, as above, that there are 2, not 3 variables.
Does the error happen again if you do something like
ProjectLauncher allInstances first startUp
Are you actually able to look at this in the debugger?
If so, does Compiler>>evaluate:in:to:notifying:ifFail:logged: actually send #contents in the debugger? What if you go back down the stack to ProjectLauncher>>startUp and restart from there?
Cheers, Bob
On 9/25/13 8:11 AM, Frank Shearar wrote:
On 25 September 2013 13:02, Bob Arning arning315@comcast.net wrote:
Just type
PositionableStream>>#fileInAnnouncing:
and explore it. Look for the literal pointing to the compiler (literal8 here). Toggle that open and toggle open the value. Look at the instanceVariables - does it still have sourceStream?
Right. I might even have done that if my brain had been working. So exploring PositionableStream>>#fileInAnnouncing: tells me that Compiler resolves to the default environment's (so Smalltalk) Compiler, as it should. It _won't_ show the instvar though, because that's Compiler class, not an instance of Compiler. Following the chain though, that particular Compiler's #evaluate:in:to:notifying:ifFail:logged: shows the correct content.
As to the explorer, did you open one? Is it still open? (The PointerFinder says it is) Could it have been open when the image was last saved? Also, you could do
Behavior allSubInstances select: [ :e | (e asString findString: 'Compiler')
0]
Do you get: an OrderedCollection(ClosureCompilerTest CompilerTest CompilerExceptionsTest CompilerNotifyingTest CompilerSyntaxErrorNotifyingTest Compiler ClosureCompilerTest class CompilerTest class CompilerExceptionsTest class CompilerNotifyingTest class CompilerSyntaxErrorNotifyingTest class Compiler class)
I get the same.
frank
Cheers, Bob
On 9/25/13 7:31 AM, Frank Shearar wrote:
I don't know how I would do that. The bytecode just says pushLit: Compiler.
But if I say Compiler allInstances collect: [:c | c instVarNamed: 'cue'] I see {nil . a CompilationCue . a CompilationCue}. That first one's a problem! Further, my image has an ObjectExplorer (!) hanging onto that Compiler, coming from I don't know where.
frank
On 25 September 2013 11:53, Bob Arning arning315@comcast.net wrote:
If you inspect
PositionableStream>>#fileInAnnouncing:
and look at the literal for Compiler, does it look to be pointing to the new or old Compiler?
Cheers, Bob
On 9/25/13 6:12 AM, Frank Shearar wrote:
I'm running with Compiler-nice.274.
What's weirder is in that top stack frame (Compiler >> #evaluate:in:to:notifying:ifFailed:logged: the following all show up as red, because they're references to instvars that don't exist: class, sourceStream, context, requestor.
That's because the CompiledMethod that's running is not actually the right CompiledMethod! It's from some ancient pre-CompilationCue Compiler instance. Or at least so I suspect because that Compiler instance has a nil 'cue' instvar.
If it helps, the PointerFinder says this of the offending context:
globals: Environment declarations: IdentityDictionary #World -> PasteUpMorph submorphs: Array 1: SystemWindow model: ObjectExplorer currentSelection: ObjectExplorerWrapper item: CompiledMethod
In contrast, PointerFinder on: (Compiler >> #evaluate:in:to:notifying:ifFail:logged:) says:
CLASS: SmalltalkImage class superclass: Object class subclasses: Array 445: Compiler class methodDict: MethodDictionary array: Array 39: CompiledMethod.
I didn't open an ObjectExplorer until I started digging. It's vaguely conceivable that there was an ObjectExplorer already existing, but that would mean that the official 4.4-12327 image has one. We can check that, but I doubt it will. (Context: this particular image is the official 4.4-12327, updated to trunk through the CI job's update-image.st, and then released through same's release.st. All automatic, no user input.)
The problem is that the script you evaluate will update the Compiler... New updates will remove unused variables before the script is finished... I tried to solve the problem by introducing an intermediate step: - 1) publish the modified methods in an update.mcm (I reintroduced the missing vars) - 2) only then remove the inst. var. (See the recent serie of Compiler versions 270->274
This did not solve anything because there are always cases when you launch the script from an older image (typically from Squeak 4.4, 4.3 or even older) The same old Compiler instance is used during all the process and it must be unmodified during the process, otherwise, undefined behavior (SEGV included)...
I see one way to workaround this: 1) clone the Compiler class 2) instantiate the clone 3) let the clone evaluate
In fact, to be safer we should clone the whole hierarchy, but you could 1st try simply with Compiler...
2013/9/25 Bob Arning arning315@comcast.net
Just type
PositionableStream>>#fileInAnnouncing:
and explore it. Look for the literal pointing to the compiler (literal8 here). Toggle that open and toggle open the value. Look at the instanceVariables - does it still have sourceStream?
As to the explorer, did you open one? Is it still open? (The PointerFinder says it is) Could it have been open when the image was last saved?
Also, you could do
Behavior allSubInstances select: [ :e | (e asString findString: 'Compiler') > 0]
Do you get: an OrderedCollection(ClosureCompilerTest CompilerTest CompilerExceptionsTest CompilerNotifyingTest CompilerSyntaxErrorNotifyingTest Compiler ClosureCompilerTest class CompilerTest class CompilerExceptionsTest class CompilerNotifyingTest class CompilerSyntaxErrorNotifyingTest class Compiler class)
Cheers, Bob
On 9/25/13 7:31 AM, Frank Shearar wrote:
I don't know how I would do that. The bytecode just says pushLit: Compiler.
But if I say Compiler allInstances collect: [:c | c instVarNamed: 'cue'] I see {nil . a CompilationCue . a CompilationCue}. That first one's a problem! Further, my image has an ObjectExplorer (!) hanging onto that Compiler, coming from I don't know where.
frank
On 25 September 2013 11:53, Bob Arning arning315@comcast.net arning315@comcast.net wrote:
If you inspect
PositionableStream>>#fileInAnnouncing:
and look at the literal for Compiler, does it look to be pointing to the new or old Compiler?
Cheers, Bob
On 9/25/13 6:12 AM, Frank Shearar wrote:
I'm running with Compiler-nice.274.
What's weirder is in that top stack frame (Compiler >> #evaluate:in:to:notifying:ifFailed:logged: the following all show up as red, because they're references to instvars that don't exist: class, sourceStream, context, requestor.
That's because the CompiledMethod that's running is not actually the right CompiledMethod! It's from some ancient pre-CompilationCue Compiler instance. Or at least so I suspect because that Compiler instance has a nil 'cue' instvar.
If it helps, the PointerFinder says this of the offending context:
globals: Environment declarations: IdentityDictionary #World -> PasteUpMorph submorphs: Array 1: SystemWindow model: ObjectExplorer currentSelection: ObjectExplorerWrapper item: CompiledMethod
In contrast, PointerFinder on: (Compiler >> #evaluate:in:to:notifying:ifFail:logged:) says:
CLASS: SmalltalkImage class superclass: Object class subclasses: Array 445: Compiler class methodDict: MethodDictionary array: Array 39: CompiledMethod.
Are you able to tell what's in the script he's running simply from the stack trace? Or some other way?
Cheers, Bob
On 9/25/13 9:12 AM, Nicolas Cellier wrote:
The problem is that the script you evaluate will update the Compiler... New updates will remove unused variables before the script is finished... I tried to solve the problem by introducing an intermediate step:
- publish the modified methods in an update.mcm (I reintroduced the
missing vars)
- only then remove the inst. var.
(See the recent serie of Compiler versions 270->274
This did not solve anything because there are always cases when you launch the script from an older image (typically from Squeak 4.4, 4.3 or even older) The same old Compiler instance is used during all the process and it must be unmodified during the process, otherwise, undefined behavior (SEGV included)...
I see one way to workaround this:
- clone the Compiler class
- instantiate the clone
- let the clone evaluate
In fact, to be safer we should clone the whole hierarchy, but you could 1st try simply with Compiler...
2013/9/25 Bob Arning <arning315@comcast.net mailto:arning315@comcast.net>
Just type PositionableStream>>#fileInAnnouncing: and explore it. Look for the literal pointing to the compiler (literal8 here). Toggle that open and toggle open the value. Look at the instanceVariables - does it still have sourceStream? As to the explorer, did you open one? Is it still open? (The PointerFinder says it is) Could it have been open when the image was last saved? Also, you could do Behavior allSubInstances select: [ :e | (e asString findString: 'Compiler') > 0] Do you get: an OrderedCollection(ClosureCompilerTest CompilerTest CompilerExceptionsTest CompilerNotifyingTest CompilerSyntaxErrorNotifyingTest Compiler ClosureCompilerTest class CompilerTest class CompilerExceptionsTest class CompilerNotifyingTest class CompilerSyntaxErrorNotifyingTest class Compiler class) Cheers, Bob On 9/25/13 7:31 AM, Frank Shearar wrote:I don't know how I would do that. The bytecode just says pushLit: Compiler. But if I say Compiler allInstances collect: [:c | c instVarNamed: 'cue'] I see {nil . a CompilationCue . a CompilationCue}. That first one's a problem! Further, my image has an ObjectExplorer (!) hanging onto that Compiler, coming from I don't know where. frank On 25 September 2013 11:53, Bob Arning<arning315@comcast.net> <mailto:arning315@comcast.net> wrote:If you inspect PositionableStream>>#fileInAnnouncing: and look at the literal for Compiler, does it look to be pointing to the new or old Compiler? Cheers, Bob On 9/25/13 6:12 AM, Frank Shearar wrote: I'm running with Compiler-nice.274. What's weirder is in that top stack frame (Compiler >> #evaluate:in:to:notifying:ifFailed:logged: the following all show up as red, because they're references to instvars that don't exist: class, sourceStream, context, requestor. That's because the CompiledMethod that's running is not actually the right CompiledMethod! It's from some ancient pre-CompilationCue Compiler instance. Or at least so I suspect because that Compiler instance has a nil 'cue' instvar. If it helps, the PointerFinder says this of the offending context: globals: Environment declarations: IdentityDictionary #World -> PasteUpMorph submorphs: Array 1: SystemWindow model: ObjectExplorer currentSelection: ObjectExplorerWrapper item: CompiledMethod In contrast, PointerFinder on: (Compiler >> #evaluate:in:to:notifying:ifFail:logged:) says: CLASS: SmalltalkImage class superclass: Object class subclasses: Array 445: Compiler class methodDict: MethodDictionary array: Array 39: CompiledMethod.
Nah, I'm cheating. I just opened a recent artifact from CI server one or two days ago. It has the same kind of debugger opened http://build.squeak.org/job/SqueakTrunk/537/
2013/9/25 Bob Arning arning315@comcast.net
Are you able to tell what's in the script he's running simply from the stack trace? Or some other way?
Cheers, Bob
On 9/25/13 9:12 AM, Nicolas Cellier wrote:
The problem is that the script you evaluate will update the Compiler... New updates will remove unused variables before the script is finished... I tried to solve the problem by introducing an intermediate step:
- publish the modified methods in an update.mcm (I reintroduced the
missing vars)
- only then remove the inst. var.
(See the recent serie of Compiler versions 270->274
This did not solve anything because there are always cases when you launch the script from an older image (typically from Squeak 4.4, 4.3 or even older) The same old Compiler instance is used during all the process and it must be unmodified during the process, otherwise, undefined behavior (SEGV included)...
I see one way to workaround this:
- clone the Compiler class
- instantiate the clone
- let the clone evaluate
In fact, to be safer we should clone the whole hierarchy, but you could 1st try simply with Compiler...
2013/9/25 Bob Arning arning315@comcast.net
Just type
PositionableStream>>#fileInAnnouncing:
and explore it. Look for the literal pointing to the compiler (literal8 here). Toggle that open and toggle open the value. Look at the instanceVariables - does it still have sourceStream?
As to the explorer, did you open one? Is it still open? (The PointerFinder says it is) Could it have been open when the image was last saved?
Also, you could do
Behavior allSubInstances select: [ :e | (e asString findString: 'Compiler') > 0]
Do you get: an OrderedCollection(ClosureCompilerTest CompilerTest CompilerExceptionsTest CompilerNotifyingTest CompilerSyntaxErrorNotifyingTest Compiler ClosureCompilerTest class CompilerTest class CompilerExceptionsTest class CompilerNotifyingTest class CompilerSyntaxErrorNotifyingTest class Compiler class)
Cheers, Bob
On 9/25/13 7:31 AM, Frank Shearar wrote:
I don't know how I would do that. The bytecode just says pushLit: Compiler.
But if I say Compiler allInstances collect: [:c | c instVarNamed: 'cue'] I see {nil . a CompilationCue . a CompilationCue}. That first one's a problem! Further, my image has an ObjectExplorer (!) hanging onto that Compiler, coming from I don't know where.
frank
On 25 September 2013 11:53, Bob Arning arning315@comcast.net arning315@comcast.net wrote:
If you inspect
PositionableStream>>#fileInAnnouncing:
and look at the literal for Compiler, does it look to be pointing to the new or old Compiler?
Cheers, Bob
On 9/25/13 6:12 AM, Frank Shearar wrote:
I'm running with Compiler-nice.274.
What's weirder is in that top stack frame (Compiler >> #evaluate:in:to:notifying:ifFailed:logged: the following all show up as red, because they're references to instvars that don't exist: class, sourceStream, context, requestor.
That's because the CompiledMethod that's running is not actually the right CompiledMethod! It's from some ancient pre-CompilationCue Compiler instance. Or at least so I suspect because that Compiler instance has a nil 'cue' instvar.
If it helps, the PointerFinder says this of the offending context:
globals: Environment declarations: IdentityDictionary #World -> PasteUpMorph submorphs: Array 1: SystemWindow model: ObjectExplorer currentSelection: ObjectExplorerWrapper item: CompiledMethod
In contrast, PointerFinder on: (Compiler >> #evaluate:in:to:notifying:ifFail:logged:) says:
CLASS: SmalltalkImage class superclass: Object class subclasses: Array 445: Compiler class methodDict: MethodDictionary array: Array 39: CompiledMethod.
Frank, could you retry to launch the script with Compiler copy evaluate: '...' instead of Compiler evaluate: ? I checked that Compiler copy methodDictionary ~~ Compiler methodDictionary so it might just work...
2013/9/25 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
Nah, I'm cheating. I just opened a recent artifact from CI server one or two days ago. It has the same kind of debugger opened http://build.squeak.org/job/SqueakTrunk/537/
2013/9/25 Bob Arning arning315@comcast.net
Are you able to tell what's in the script he's running simply from the stack trace? Or some other way?
Cheers, Bob
On 9/25/13 9:12 AM, Nicolas Cellier wrote:
The problem is that the script you evaluate will update the Compiler... New updates will remove unused variables before the script is finished... I tried to solve the problem by introducing an intermediate step:
- publish the modified methods in an update.mcm (I reintroduced the
missing vars)
- only then remove the inst. var.
(See the recent serie of Compiler versions 270->274
This did not solve anything because there are always cases when you launch the script from an older image (typically from Squeak 4.4, 4.3 or even older) The same old Compiler instance is used during all the process and it must be unmodified during the process, otherwise, undefined behavior (SEGV included)...
I see one way to workaround this:
- clone the Compiler class
- instantiate the clone
- let the clone evaluate
In fact, to be safer we should clone the whole hierarchy, but you could 1st try simply with Compiler...
2013/9/25 Bob Arning arning315@comcast.net
Just type
PositionableStream>>#fileInAnnouncing:
and explore it. Look for the literal pointing to the compiler (literal8 here). Toggle that open and toggle open the value. Look at the instanceVariables - does it still have sourceStream?
As to the explorer, did you open one? Is it still open? (The PointerFinder says it is) Could it have been open when the image was last saved?
Also, you could do
Behavior allSubInstances select: [ :e | (e asString findString: 'Compiler') > 0]
Do you get: an OrderedCollection(ClosureCompilerTest CompilerTest CompilerExceptionsTest CompilerNotifyingTest CompilerSyntaxErrorNotifyingTest Compiler ClosureCompilerTest class CompilerTest class CompilerExceptionsTest class CompilerNotifyingTest class CompilerSyntaxErrorNotifyingTest class Compiler class)
Cheers, Bob
On 9/25/13 7:31 AM, Frank Shearar wrote:
I don't know how I would do that. The bytecode just says pushLit: Compiler.
But if I say Compiler allInstances collect: [:c | c instVarNamed: 'cue'] I see {nil . a CompilationCue . a CompilationCue}. That first one's a problem! Further, my image has an ObjectExplorer (!) hanging onto that Compiler, coming from I don't know where.
frank
On 25 September 2013 11:53, Bob Arning arning315@comcast.net arning315@comcast.net wrote:
If you inspect
PositionableStream>>#fileInAnnouncing:
and look at the literal for Compiler, does it look to be pointing to the new or old Compiler?
Cheers, Bob
On 9/25/13 6:12 AM, Frank Shearar wrote:
I'm running with Compiler-nice.274.
What's weirder is in that top stack frame (Compiler >> #evaluate:in:to:notifying:ifFailed:logged: the following all show up as red, because they're references to instvars that don't exist: class, sourceStream, context, requestor.
That's because the CompiledMethod that's running is not actually the right CompiledMethod! It's from some ancient pre-CompilationCue Compiler instance. Or at least so I suspect because that Compiler instance has a nil 'cue' instvar.
If it helps, the PointerFinder says this of the offending context:
globals: Environment declarations: IdentityDictionary #World -> PasteUpMorph submorphs: Array 1: SystemWindow model: ObjectExplorer currentSelection: ObjectExplorerWrapper item: CompiledMethod
In contrast, PointerFinder on: (Compiler >> #evaluate:in:to:notifying:ifFail:logged:) says:
CLASS: SmalltalkImage class superclass: Object class subclasses: Array 445: Compiler class methodDict: MethodDictionary array: Array 39: CompiledMethod.
I'm not sure how I'd do that without making changes to Trunk (which creates a bootstrap problem in that the scripts start with an old image version), because I just throw the script at the image from the command line..
frank
On 2 October 2013 23:42, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Frank, could you retry to launch the script with Compiler copy evaluate: '...' instead of Compiler evaluate: ? I checked that Compiler copy methodDictionary ~~ Compiler methodDictionary so it might just work...
2013/9/25 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
Nah, I'm cheating. I just opened a recent artifact from CI server one or two days ago. It has the same kind of debugger opened http://build.squeak.org/job/SqueakTrunk/537/
2013/9/25 Bob Arning arning315@comcast.net
Are you able to tell what's in the script he's running simply from the stack trace? Or some other way?
Cheers, Bob
On 9/25/13 9:12 AM, Nicolas Cellier wrote:
The problem is that the script you evaluate will update the Compiler... New updates will remove unused variables before the script is finished... I tried to solve the problem by introducing an intermediate step:
- publish the modified methods in an update.mcm (I reintroduced the
missing vars)
- only then remove the inst. var.
(See the recent serie of Compiler versions 270->274
This did not solve anything because there are always cases when you launch the script from an older image (typically from Squeak 4.4, 4.3 or even older) The same old Compiler instance is used during all the process and it must be unmodified during the process, otherwise, undefined behavior (SEGV included)...
I see one way to workaround this:
- clone the Compiler class
- instantiate the clone
- let the clone evaluate
In fact, to be safer we should clone the whole hierarchy, but you could 1st try simply with Compiler...
2013/9/25 Bob Arning arning315@comcast.net
Just type
PositionableStream>>#fileInAnnouncing:
and explore it. Look for the literal pointing to the compiler (literal8 here). Toggle that open and toggle open the value. Look at the instanceVariables - does it still have sourceStream?
As to the explorer, did you open one? Is it still open? (The PointerFinder says it is) Could it have been open when the image was last saved?
Also, you could do
Behavior allSubInstances select: [ :e | (e asString findString: 'Compiler') > 0]
Do you get: an OrderedCollection(ClosureCompilerTest CompilerTest CompilerExceptionsTest CompilerNotifyingTest CompilerSyntaxErrorNotifyingTest Compiler ClosureCompilerTest class CompilerTest class CompilerExceptionsTest class CompilerNotifyingTest class CompilerSyntaxErrorNotifyingTest class Compiler class)
Cheers, Bob
On 9/25/13 7:31 AM, Frank Shearar wrote:
I don't know how I would do that. The bytecode just says pushLit: Compiler.
But if I say Compiler allInstances collect: [:c | c instVarNamed: 'cue'] I see {nil . a CompilationCue . a CompilationCue}. That first one's a problem! Further, my image has an ObjectExplorer (!) hanging onto that Compiler, coming from I don't know where.
frank
On 25 September 2013 11:53, Bob Arning arning315@comcast.net wrote:
If you inspect
PositionableStream>>#fileInAnnouncing:
and look at the literal for Compiler, does it look to be pointing to the new or old Compiler?
Cheers, Bob
On 9/25/13 6:12 AM, Frank Shearar wrote:
I'm running with Compiler-nice.274.
What's weirder is in that top stack frame (Compiler >> #evaluate:in:to:notifying:ifFailed:logged: the following all show up as red, because they're references to instvars that don't exist: class, sourceStream, context, requestor.
That's because the CompiledMethod that's running is not actually the right CompiledMethod! It's from some ancient pre-CompilationCue Compiler instance. Or at least so I suspect because that Compiler instance has a nil 'cue' instvar.
If it helps, the PointerFinder says this of the offending context:
globals: Environment declarations: IdentityDictionary #World -> PasteUpMorph submorphs: Array 1: SystemWindow model: ObjectExplorer currentSelection: ObjectExplorerWrapper item: CompiledMethod
In contrast, PointerFinder on: (Compiler >> #evaluate:in:to:notifying:ifFail:logged:) says:
CLASS: SmalltalkImage class superclass: Object class subclasses: Array 445: Compiler class methodDict: MethodDictionary array: Array 39: CompiledMethod.
Ah, maybe it's time to use one of our dangerous superpowers... What if you would start your script with: Compiler allInstances do: [:e | e becomeForward: (e as: Compiler copy)].
2013/10/3 Frank Shearar frank.shearar@gmail.com
I'm not sure how I'd do that without making changes to Trunk (which creates a bootstrap problem in that the scripts start with an old image version), because I just throw the script at the image from the command line..
frank
On 2 October 2013 23:42, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Frank, could you retry to launch the script with Compiler copy evaluate: '...' instead of Compiler evaluate: ? I checked that Compiler copy methodDictionary ~~ Compiler methodDictionary so it might just work...
2013/9/25 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
Nah, I'm cheating. I just opened a recent artifact from CI server one or two days ago. It has the same kind of debugger opened http://build.squeak.org/job/SqueakTrunk/537/
2013/9/25 Bob Arning arning315@comcast.net
Are you able to tell what's in the script he's running simply from the stack trace? Or some other way?
Cheers, Bob
On 9/25/13 9:12 AM, Nicolas Cellier wrote:
The problem is that the script you evaluate will update the Compiler... New updates will remove unused variables before the script is
finished...
I tried to solve the problem by introducing an intermediate step:
- publish the modified methods in an update.mcm (I reintroduced the
missing vars)
- only then remove the inst. var.
(See the recent serie of Compiler versions 270->274
This did not solve anything because there are always cases when you launch the script from an older image (typically from Squeak 4.4, 4.3
or
even older) The same old Compiler instance is used during all the process and it
must
be unmodified during the process, otherwise, undefined behavior (SEGV included)...
I see one way to workaround this:
- clone the Compiler class
- instantiate the clone
- let the clone evaluate
In fact, to be safer we should clone the whole hierarchy, but you could 1st try simply with Compiler...
2013/9/25 Bob Arning arning315@comcast.net
Just type
PositionableStream>>#fileInAnnouncing:
and explore it. Look for the literal pointing to the compiler
(literal8
here). Toggle that open and toggle open the value. Look at the instanceVariables - does it still have sourceStream?
As to the explorer, did you open one? Is it still open? (The PointerFinder says it is) Could it have been open when the image was
last
saved?
Also, you could do
Behavior allSubInstances select: [ :e | (e asString findString: 'Compiler') > 0]
Do you get: an OrderedCollection(ClosureCompilerTest CompilerTest CompilerExceptionsTest CompilerNotifyingTest CompilerSyntaxErrorNotifyingTest Compiler ClosureCompilerTest class CompilerTest class CompilerExceptionsTest class CompilerNotifyingTest
class
CompilerSyntaxErrorNotifyingTest class Compiler class)
Cheers, Bob
On 9/25/13 7:31 AM, Frank Shearar wrote:
I don't know how I would do that. The bytecode just says pushLit: Compiler.
But if I say Compiler allInstances collect: [:c | c instVarNamed: 'cue'] I see {nil . a CompilationCue . a CompilationCue}. That first one's a problem! Further, my image has an ObjectExplorer (!) hanging onto that Compiler, coming from I don't know where.
frank
On 25 September 2013 11:53, Bob Arning arning315@comcast.net wrote:
If you inspect
PositionableStream>>#fileInAnnouncing:
and look at the literal for Compiler, does it look to be pointing to
the
new or old Compiler?
Cheers, Bob
On 9/25/13 6:12 AM, Frank Shearar wrote:
I'm running with Compiler-nice.274.
What's weirder is in that top stack frame (Compiler >> #evaluate:in:to:notifying:ifFailed:logged: the following all show up as red, because they're references to instvars that don't exist: class, sourceStream, context, requestor.
That's because the CompiledMethod that's running is not actually the right CompiledMethod! It's from some ancient pre-CompilationCue Compiler instance. Or at least so I suspect because that Compiler instance has a nil 'cue' instvar.
If it helps, the PointerFinder says this of the offending context:
globals: Environment declarations: IdentityDictionary #World -> PasteUpMorph submorphs: Array 1: SystemWindow model: ObjectExplorer currentSelection: ObjectExplorerWrapper item: CompiledMethod
In contrast, PointerFinder on: (Compiler >> #evaluate:in:to:notifying:ifFail:logged:) says:
CLASS: SmalltalkImage class superclass: Object class subclasses: Array 445: Compiler class methodDict: MethodDictionary array: Array 39: CompiledMethod.
I just rolled a new attempt at a Squeak 4.5 image, just by updating and closing the debugger. I didn't try any fancy tricks. I'm just waiting for CI to beat on it: http://build.squeak.org/job/SqueakTrunk/573/
frank
On 3 October 2013 22:49, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Ah, maybe it's time to use one of our dangerous superpowers... What if you would start your script with: Compiler allInstances do: [:e | e becomeForward: (e as: Compiler copy)].
2013/10/3 Frank Shearar frank.shearar@gmail.com
I'm not sure how I'd do that without making changes to Trunk (which creates a bootstrap problem in that the scripts start with an old image version), because I just throw the script at the image from the command line..
frank
On 2 October 2013 23:42, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Frank, could you retry to launch the script with Compiler copy evaluate: '...' instead of Compiler evaluate: ? I checked that Compiler copy methodDictionary ~~ Compiler methodDictionary so it might just work...
2013/9/25 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
Nah, I'm cheating. I just opened a recent artifact from CI server one or two days ago. It has the same kind of debugger opened http://build.squeak.org/job/SqueakTrunk/537/
2013/9/25 Bob Arning arning315@comcast.net
Are you able to tell what's in the script he's running simply from the stack trace? Or some other way?
Cheers, Bob
On 9/25/13 9:12 AM, Nicolas Cellier wrote:
The problem is that the script you evaluate will update the Compiler... New updates will remove unused variables before the script is finished... I tried to solve the problem by introducing an intermediate step:
- publish the modified methods in an update.mcm (I reintroduced the
missing vars)
- only then remove the inst. var.
(See the recent serie of Compiler versions 270->274
This did not solve anything because there are always cases when you launch the script from an older image (typically from Squeak 4.4, 4.3 or even older) The same old Compiler instance is used during all the process and it must be unmodified during the process, otherwise, undefined behavior (SEGV included)...
I see one way to workaround this:
- clone the Compiler class
- instantiate the clone
- let the clone evaluate
In fact, to be safer we should clone the whole hierarchy, but you could 1st try simply with Compiler...
2013/9/25 Bob Arning arning315@comcast.net
Just type
PositionableStream>>#fileInAnnouncing:
and explore it. Look for the literal pointing to the compiler (literal8 here). Toggle that open and toggle open the value. Look at the instanceVariables - does it still have sourceStream?
As to the explorer, did you open one? Is it still open? (The PointerFinder says it is) Could it have been open when the image was last saved?
Also, you could do
Behavior allSubInstances select: [ :e | (e asString findString: 'Compiler') > 0]
Do you get: an OrderedCollection(ClosureCompilerTest CompilerTest CompilerExceptionsTest CompilerNotifyingTest CompilerSyntaxErrorNotifyingTest Compiler ClosureCompilerTest class CompilerTest class CompilerExceptionsTest class CompilerNotifyingTest class CompilerSyntaxErrorNotifyingTest class Compiler class)
Cheers, Bob
On 9/25/13 7:31 AM, Frank Shearar wrote:
I don't know how I would do that. The bytecode just says pushLit: Compiler.
But if I say Compiler allInstances collect: [:c | c instVarNamed: 'cue'] I see {nil . a CompilationCue . a CompilationCue}. That first one's a problem! Further, my image has an ObjectExplorer (!) hanging onto that Compiler, coming from I don't know where.
frank
On 25 September 2013 11:53, Bob Arning arning315@comcast.net wrote:
If you inspect
PositionableStream>>#fileInAnnouncing:
and look at the literal for Compiler, does it look to be pointing to the new or old Compiler?
Cheers, Bob
On 9/25/13 6:12 AM, Frank Shearar wrote:
I'm running with Compiler-nice.274.
What's weirder is in that top stack frame (Compiler >> #evaluate:in:to:notifying:ifFailed:logged: the following all show up as red, because they're references to instvars that don't exist: class, sourceStream, context, requestor.
That's because the CompiledMethod that's running is not actually the right CompiledMethod! It's from some ancient pre-CompilationCue Compiler instance. Or at least so I suspect because that Compiler instance has a nil 'cue' instvar.
If it helps, the PointerFinder says this of the offending context:
globals: Environment declarations: IdentityDictionary #World -> PasteUpMorph submorphs: Array 1: SystemWindow model: ObjectExplorer currentSelection: ObjectExplorerWrapper item: CompiledMethod
In contrast, PointerFinder on: (Compiler >> #evaluate:in:to:notifying:ifFail:logged:) says:
CLASS: SmalltalkImage class superclass: Object class subclasses: Array 445: Compiler class methodDict: MethodDictionary array: Array 39: CompiledMethod.
So if everyone can beat on this image - Squeak4.5.image in https://github.com/squeak-smalltalk/squeak-ci/archive/92b49fcaf9624b2ba57909... - then if it passes muster I'll start stripping it down.
frank
On 28 October 2013 22:01, Frank Shearar frank.shearar@gmail.com wrote:
I just rolled a new attempt at a Squeak 4.5 image, just by updating and closing the debugger. I didn't try any fancy tricks. I'm just waiting for CI to beat on it: http://build.squeak.org/job/SqueakTrunk/573/
frank
On 3 October 2013 22:49, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Ah, maybe it's time to use one of our dangerous superpowers... What if you would start your script with: Compiler allInstances do: [:e | e becomeForward: (e as: Compiler copy)].
2013/10/3 Frank Shearar frank.shearar@gmail.com
I'm not sure how I'd do that without making changes to Trunk (which creates a bootstrap problem in that the scripts start with an old image version), because I just throw the script at the image from the command line..
frank
On 2 October 2013 23:42, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Frank, could you retry to launch the script with Compiler copy evaluate: '...' instead of Compiler evaluate: ? I checked that Compiler copy methodDictionary ~~ Compiler methodDictionary so it might just work...
2013/9/25 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
Nah, I'm cheating. I just opened a recent artifact from CI server one or two days ago. It has the same kind of debugger opened http://build.squeak.org/job/SqueakTrunk/537/
2013/9/25 Bob Arning arning315@comcast.net
Are you able to tell what's in the script he's running simply from the stack trace? Or some other way?
Cheers, Bob
On 9/25/13 9:12 AM, Nicolas Cellier wrote:
The problem is that the script you evaluate will update the Compiler... New updates will remove unused variables before the script is finished... I tried to solve the problem by introducing an intermediate step:
- publish the modified methods in an update.mcm (I reintroduced the
missing vars)
- only then remove the inst. var.
(See the recent serie of Compiler versions 270->274
This did not solve anything because there are always cases when you launch the script from an older image (typically from Squeak 4.4, 4.3 or even older) The same old Compiler instance is used during all the process and it must be unmodified during the process, otherwise, undefined behavior (SEGV included)...
I see one way to workaround this:
- clone the Compiler class
- instantiate the clone
- let the clone evaluate
In fact, to be safer we should clone the whole hierarchy, but you could 1st try simply with Compiler...
2013/9/25 Bob Arning arning315@comcast.net > > Just type > > PositionableStream>>#fileInAnnouncing: > > and explore it. Look for the literal pointing to the compiler > (literal8 > here). Toggle that open and toggle open the value. Look at the > instanceVariables - does it still have sourceStream? > > As to the explorer, did you open one? Is it still open? (The > PointerFinder says it is) Could it have been open when the image was > last > saved? > > > Also, you could do > > Behavior allSubInstances select: [ :e | (e asString findString: > 'Compiler') > 0] > > Do you get: an OrderedCollection(ClosureCompilerTest CompilerTest > CompilerExceptionsTest CompilerNotifyingTest > CompilerSyntaxErrorNotifyingTest Compiler ClosureCompilerTest class > CompilerTest class CompilerExceptionsTest class CompilerNotifyingTest > class > CompilerSyntaxErrorNotifyingTest class Compiler class) > > > Cheers, > Bob > > On 9/25/13 7:31 AM, Frank Shearar wrote: > > I don't know how I would do that. The bytecode just says pushLit: > Compiler. > > But if I say Compiler allInstances collect: [:c | c instVarNamed: > 'cue'] I see {nil . a CompilationCue . a CompilationCue}. That first > one's a problem! Further, my image has an ObjectExplorer (!) hanging > onto that Compiler, coming from I don't know where. > > frank > > On 25 September 2013 11:53, Bob Arning arning315@comcast.net wrote: > > If you inspect > > PositionableStream>>#fileInAnnouncing: > > and look at the literal for Compiler, does it look to be pointing to > the > new > or old Compiler? > > Cheers, > Bob > > On 9/25/13 6:12 AM, Frank Shearar wrote: > > I'm running with Compiler-nice.274. > > What's weirder is in that top stack frame (Compiler >> > #evaluate:in:to:notifying:ifFailed:logged: the following all show up > as red, because they're references to instvars that don't exist: > class, sourceStream, context, requestor. > > That's because the CompiledMethod that's running is not actually the > right CompiledMethod! It's from some ancient pre-CompilationCue > Compiler instance. Or at least so I suspect because that Compiler > instance has a nil 'cue' instvar. > > If it helps, the PointerFinder says this of the offending context: > > globals: Environment > declarations: IdentityDictionary > #World -> PasteUpMorph > submorphs: Array > 1: SystemWindow > model: ObjectExplorer > currentSelection: ObjectExplorerWrapper > item: CompiledMethod > > In contrast, PointerFinder on: (Compiler >> > #evaluate:in:to:notifying:ifFail:logged:) says: > > CLASS: SmalltalkImage class > superclass: Object class > subclasses: Array > 445: Compiler class > methodDict: MethodDictionary > array: Array > 39: CompiledMethod. > > > > > > > > >
On Mon, 28 Oct 2013, Frank Shearar wrote:
So if everyone can beat on this image - Squeak4.5.image in https://github.com/squeak-smalltalk/squeak-ci/archive/92b49fcaf9624b2ba57909...
- then if it passes muster I'll start stripping it down.
Do you mean manually unloading packages?
Levente
frank
On 28 October 2013 22:01, Frank Shearar frank.shearar@gmail.com wrote:
I just rolled a new attempt at a Squeak 4.5 image, just by updating and closing the debugger. I didn't try any fancy tricks. I'm just waiting for CI to beat on it: http://build.squeak.org/job/SqueakTrunk/573/
frank
On 3 October 2013 22:49, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Ah, maybe it's time to use one of our dangerous superpowers... What if you would start your script with: Compiler allInstances do: [:e | e becomeForward: (e as: Compiler copy)].
2013/10/3 Frank Shearar frank.shearar@gmail.com
I'm not sure how I'd do that without making changes to Trunk (which creates a bootstrap problem in that the scripts start with an old image version), because I just throw the script at the image from the command line..
frank
On 2 October 2013 23:42, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Frank, could you retry to launch the script with Compiler copy evaluate: '...' instead of Compiler evaluate: ? I checked that Compiler copy methodDictionary ~~ Compiler methodDictionary so it might just work...
2013/9/25 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
Nah, I'm cheating. I just opened a recent artifact from CI server one or two days ago. It has the same kind of debugger opened http://build.squeak.org/job/SqueakTrunk/537/
2013/9/25 Bob Arning arning315@comcast.net > > Are you able to tell what's in the script he's running simply from the > stack trace? Or some other way? > > Cheers, > Bob > > On 9/25/13 9:12 AM, Nicolas Cellier wrote: > > The problem is that the script you evaluate will update the > Compiler... > New updates will remove unused variables before the script is > finished... > I tried to solve the problem by introducing an intermediate step: > - 1) publish the modified methods in an update.mcm (I reintroduced the > missing vars) > - 2) only then remove the inst. var. > (See the recent serie of Compiler versions 270->274 > > This did not solve anything because there are always cases when you > launch the script from an older image (typically from Squeak 4.4, 4.3 > or > even older) > The same old Compiler instance is used during all the process and it > must > be unmodified during the process, otherwise, undefined behavior (SEGV > included)... > > I see one way to workaround this: > 1) clone the Compiler class > 2) instantiate the clone > 3) let the clone evaluate > > In fact, to be safer we should clone the whole hierarchy, but you > could > 1st try simply with Compiler... > > > 2013/9/25 Bob Arning arning315@comcast.net >> >> Just type >> >> PositionableStream>>#fileInAnnouncing: >> >> and explore it. Look for the literal pointing to the compiler >> (literal8 >> here). Toggle that open and toggle open the value. Look at the >> instanceVariables - does it still have sourceStream? >> >> As to the explorer, did you open one? Is it still open? (The >> PointerFinder says it is) Could it have been open when the image was >> last >> saved? >> >> >> Also, you could do >> >> Behavior allSubInstances select: [ :e | (e asString findString: >> 'Compiler') > 0] >> >> Do you get: an OrderedCollection(ClosureCompilerTest CompilerTest >> CompilerExceptionsTest CompilerNotifyingTest >> CompilerSyntaxErrorNotifyingTest Compiler ClosureCompilerTest class >> CompilerTest class CompilerExceptionsTest class CompilerNotifyingTest >> class >> CompilerSyntaxErrorNotifyingTest class Compiler class) >> >> >> Cheers, >> Bob >> >> On 9/25/13 7:31 AM, Frank Shearar wrote: >> >> I don't know how I would do that. The bytecode just says pushLit: >> Compiler. >> >> But if I say Compiler allInstances collect: [:c | c instVarNamed: >> 'cue'] I see {nil . a CompilationCue . a CompilationCue}. That first >> one's a problem! Further, my image has an ObjectExplorer (!) hanging >> onto that Compiler, coming from I don't know where. >> >> frank >> >> On 25 September 2013 11:53, Bob Arning arning315@comcast.net wrote: >> >> If you inspect >> >> PositionableStream>>#fileInAnnouncing: >> >> and look at the literal for Compiler, does it look to be pointing to >> the >> new >> or old Compiler? >> >> Cheers, >> Bob >> >> On 9/25/13 6:12 AM, Frank Shearar wrote: >> >> I'm running with Compiler-nice.274. >> >> What's weirder is in that top stack frame (Compiler >> >> #evaluate:in:to:notifying:ifFailed:logged: the following all show up >> as red, because they're references to instvars that don't exist: >> class, sourceStream, context, requestor. >> >> That's because the CompiledMethod that's running is not actually the >> right CompiledMethod! It's from some ancient pre-CompilationCue >> Compiler instance. Or at least so I suspect because that Compiler >> instance has a nil 'cue' instvar. >> >> If it helps, the PointerFinder says this of the offending context: >> >> globals: Environment >> declarations: IdentityDictionary >> #World -> PasteUpMorph >> submorphs: Array >> 1: SystemWindow >> model: ObjectExplorer >> currentSelection: ObjectExplorerWrapper >> item: CompiledMethod >> >> In contrast, PointerFinder on: (Compiler >> >> #evaluate:in:to:notifying:ifFail:logged:) says: >> >> CLASS: SmalltalkImage class >> superclass: Object class >> subclasses: Array >> 445: Compiler class >> methodDict: MethodDictionary >> array: Array >> 39: CompiledMethod. >> >> >> >> >> >> >> >> >> > > > > > > >
On 28 October 2013 22:59, Levente Uzonyi leves@elte.hu wrote:
On Mon, 28 Oct 2013, Frank Shearar wrote:
So if everyone can beat on this image - Squeak4.5.image in
https://github.com/squeak-smalltalk/squeak-ci/archive/92b49fcaf9624b2ba57909...
- then if it passes muster I'll start stripping it down.
Do you mean manually unloading packages?
I mean repeating what I did before, so yes. Where "manual" means "by running a script", at least. Then, once again, the output of the SqueakTrunk job will be a semistripped image that the ReleaseSqueakTrunk job will "re-inflate".
frank
Levente
frank
On 28 October 2013 22:01, Frank Shearar frank.shearar@gmail.com wrote:
I just rolled a new attempt at a Squeak 4.5 image, just by updating and closing the debugger. I didn't try any fancy tricks. I'm just waiting for CI to beat on it: http://build.squeak.org/job/SqueakTrunk/573/
frank
On 3 October 2013 22:49, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Ah, maybe it's time to use one of our dangerous superpowers... What if you would start your script with: Compiler allInstances do: [:e | e becomeForward: (e as: Compiler copy)].
2013/10/3 Frank Shearar frank.shearar@gmail.com
I'm not sure how I'd do that without making changes to Trunk (which creates a bootstrap problem in that the scripts start with an old image version), because I just throw the script at the image from the command line..
frank
On 2 October 2013 23:42, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Frank, could you retry to launch the script with Compiler copy evaluate: '...' instead of Compiler evaluate: ? I checked that Compiler copy methodDictionary ~~ Compiler methodDictionary so it might just work...
2013/9/25 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com > > > Nah, I'm cheating. > I just opened a recent artifact from CI server one or two days ago. > It has the same kind of debugger opened > http://build.squeak.org/job/SqueakTrunk/537/ > > > 2013/9/25 Bob Arning arning315@comcast.net >> >> >> Are you able to tell what's in the script he's running simply from >> the >> stack trace? Or some other way? >> >> Cheers, >> Bob >> >> On 9/25/13 9:12 AM, Nicolas Cellier wrote: >> >> The problem is that the script you evaluate will update the >> Compiler... >> New updates will remove unused variables before the script is >> finished... >> I tried to solve the problem by introducing an intermediate step: >> - 1) publish the modified methods in an update.mcm (I reintroduced >> the >> missing vars) >> - 2) only then remove the inst. var. >> (See the recent serie of Compiler versions 270->274 >> >> This did not solve anything because there are always cases when you >> launch the script from an older image (typically from Squeak 4.4, >> 4.3 >> or >> even older) >> The same old Compiler instance is used during all the process and it >> must >> be unmodified during the process, otherwise, undefined behavior >> (SEGV >> included)... >> >> I see one way to workaround this: >> 1) clone the Compiler class >> 2) instantiate the clone >> 3) let the clone evaluate >> >> In fact, to be safer we should clone the whole hierarchy, but you >> could >> 1st try simply with Compiler... >> >> >> 2013/9/25 Bob Arning arning315@comcast.net >>> >>> >>> Just type >>> >>> PositionableStream>>#fileInAnnouncing: >>> >>> and explore it. Look for the literal pointing to the compiler >>> (literal8 >>> here). Toggle that open and toggle open the value. Look at the >>> instanceVariables - does it still have sourceStream? >>> >>> As to the explorer, did you open one? Is it still open? (The >>> PointerFinder says it is) Could it have been open when the image >>> was >>> last >>> saved? >>> >>> >>> Also, you could do >>> >>> Behavior allSubInstances select: [ :e | (e asString findString: >>> 'Compiler') > 0] >>> >>> Do you get: an OrderedCollection(ClosureCompilerTest CompilerTest >>> CompilerExceptionsTest CompilerNotifyingTest >>> CompilerSyntaxErrorNotifyingTest Compiler ClosureCompilerTest class >>> CompilerTest class CompilerExceptionsTest class >>> CompilerNotifyingTest >>> class >>> CompilerSyntaxErrorNotifyingTest class Compiler class) >>> >>> >>> Cheers, >>> Bob >>> >>> On 9/25/13 7:31 AM, Frank Shearar wrote: >>> >>> I don't know how I would do that. The bytecode just says pushLit: >>> Compiler. >>> >>> But if I say Compiler allInstances collect: [:c | c instVarNamed: >>> 'cue'] I see {nil . a CompilationCue . a CompilationCue}. That >>> first >>> one's a problem! Further, my image has an ObjectExplorer (!) >>> hanging >>> onto that Compiler, coming from I don't know where. >>> >>> frank >>> >>> On 25 September 2013 11:53, Bob Arning arning315@comcast.net >>> wrote: >>> >>> If you inspect >>> >>> PositionableStream>>#fileInAnnouncing: >>> >>> and look at the literal for Compiler, does it look to be pointing >>> to >>> the >>> new >>> or old Compiler? >>> >>> Cheers, >>> Bob >>> >>> On 9/25/13 6:12 AM, Frank Shearar wrote: >>> >>> I'm running with Compiler-nice.274. >>> >>> What's weirder is in that top stack frame (Compiler >> >>> #evaluate:in:to:notifying:ifFailed:logged: the following all show >>> up >>> as red, because they're references to instvars that don't exist: >>> class, sourceStream, context, requestor. >>> >>> That's because the CompiledMethod that's running is not actually >>> the >>> right CompiledMethod! It's from some ancient pre-CompilationCue >>> Compiler instance. Or at least so I suspect because that Compiler >>> instance has a nil 'cue' instvar. >>> >>> If it helps, the PointerFinder says this of the offending context: >>> >>> globals: Environment >>> declarations: IdentityDictionary >>> #World -> PasteUpMorph >>> submorphs: Array >>> 1: SystemWindow >>> model: ObjectExplorer >>> currentSelection: ObjectExplorerWrapper >>> item: CompiledMethod >>> >>> In contrast, PointerFinder on: (Compiler >> >>> #evaluate:in:to:notifying:ifFail:logged:) says: >>> >>> CLASS: SmalltalkImage class >>> superclass: Object class >>> subclasses: Array >>> 445: Compiler class >>> methodDict: MethodDictionary >>> array: Array >>> 39: CompiledMethod.
squeak-dev@lists.squeakfoundation.org
-
Bob Arning -
Frank Shearar -
Levente Uzonyi -
Nicolas Cellier