<div dir="ltr">Nah, I'm cheating.<br>I just opened a recent artifact from CI server one or two days ago.<br>It has the same kind of debugger opened<br><a href="http://build.squeak.org/job/SqueakTrunk/537/">http://build.squeak.org/job/SqueakTrunk/537/</a><br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/9/25 Bob Arning <span dir="ltr"><<a href="mailto:arning315@comcast.net" target="_blank">arning315@comcast.net</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<font face="Georgia">Are you able to tell what's in the script he's
running simply from the stack trace? Or some other way?<br>
<br>
Cheers,<br>
Bob<br>
<br>
</font><div><div class="h5">
<div>On 9/25/13 9:12 AM, Nicolas Cellier
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>The problem is that the script you evaluate will
update the Compiler...<br>
New updates will remove unused variables before the
script is finished...<br>
I tried to solve the problem by introducing an
intermediate step:<br>
</div>
- 1) publish the modified methods in an update.mcm (I
reintroduced the missing vars)<br>
</div>
- 2) only then remove the inst. var.<br>
</div>
<div>(See the recent serie of Compiler versions 270->274<br>
<br>
</div>
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)<br>
</div>
<div>The same old Compiler instance is used during all the
process and it must be unmodified during the process,
otherwise, undefined behavior (SEGV included)...<br>
<br>
</div>
<div>I see one way to workaround this:<br>
</div>
<div>1) clone the Compiler class<br>
</div>
<div>2) instantiate the clone<br>
</div>
<div>3) let the clone evaluate<br>
<br>
</div>
<div>In fact, to be safer we should clone the whole hierarchy,
but you could 1st try simply with Compiler...<br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2013/9/25 Bob Arning <span dir="ltr"><<a href="mailto:arning315@comcast.net" target="_blank">arning315@comcast.net</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <font face="Georgia">Just
type<br>
<br>
PositionableStream>>#fileInAnnouncing:<br>
<br>
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?<br>
<br>
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?<br>
<br>
<br>
Also, you could do<br>
<br>
Behavior allSubInstances select: [ :e | (e asString
findString: 'Compiler') > 0] <br>
<br>
Do you get: an OrderedCollection(ClosureCompilerTest
CompilerTest CompilerExceptionsTest
CompilerNotifyingTest CompilerSyntaxErrorNotifyingTest
Compiler ClosureCompilerTest class CompilerTest class
CompilerExceptionsTest class CompilerNotifyingTest class
CompilerSyntaxErrorNotifyingTest class Compiler class)<br>
<br>
<br>
Cheers,<br>
Bob<br>
<br>
</font>
<div>
<div>
<div>On 9/25/13 7:31 AM, Frank Shearar wrote:<br>
</div>
<blockquote type="cite">
<pre>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 <a href="mailto:arning315@comcast.net" target="_blank"><arning315@comcast.net></a> wrote:
</pre>
<blockquote type="cite">
<pre>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.
</pre>
</blockquote>
</blockquote>
<br>
</div>
</div>
</div>
<br>
<br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre></pre>
</blockquote>
<br>
</div></div></div>
<br><br>
<br></blockquote></div><br></div>