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.)