[squeak-dev] MNU: Parser >> #contents

Frank Shearar frank.shearar at gmail.com
Wed Sep 25 12:11:49 UTC 2013


On 25 September 2013 13:02, Bob Arning <arning315 at 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 at 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.)


More information about the Squeak-dev mailing list