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

Bob Arning arning315 at comcast.net
Wed Sep 25 12:59:33 UTC 2013




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

-------------- next part --------------
Skipped content of type multipart/related


More information about the Squeak-dev mailing list