MNU: Parser >> #contents

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 [hidden email] 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:

- 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 <[hidden email]>

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 [hidden email] 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 <[hidden email]>

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 <[hidden email]>

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 [hidden email] 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

<[hidden email]> 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 <[hidden email]>
>>
>> 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 <[hidden email]>
>>>
>>> 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 <[hidden email]>
>>>>
>>>> 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 <[hidden email]> 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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
>
>