Ah, maybe it's time to use one of our dangerous superpowers...
What if you would start your script with:
    Compiler allInstances do: [:e | e becomeForward: (e as: Compiler copy)].


2013/10/3 Frank Shearar <frank.shearar at gmail.com>

> 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
> <nicolas.cellier.aka.nice at gmail.com> 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 <nicolas.cellier.aka.nice at gmail.com>
> >>
> >> 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 <arning315 at comcast.net>
> >>>
> >>> 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 <arning315 at comcast.net>
> >>>>
> >>>> 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 <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.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131003/f944f849/attachment.htm