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.