So if everyone can beat on this image - Squeak4.5.image in
https://github.com/squeak-smalltalk/squeak-ci/archive/92b49fcaf9624b2ba57909d7eacced17056f8d65.zip
- then if it passes muster I'll start stripping it down.

frank

On 28 October 2013 22:01, Frank Shearar <frank.shearar at gmail.com> wrote:
> I just rolled a new attempt at a Squeak 4.5 image, just by updating
> and closing the debugger. I didn't try any fancy tricks. I'm just
> waiting for CI to beat on it:
> http://build.squeak.org/job/SqueakTrunk/573/
>
> frank
>
> On 3 October 2013 22:49, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
>> 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.
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>
>>> >
>>> >
>>> >
>>> >
>>>
>>
>>
>>
>>