On Mon, 28 Oct 2013, Frank Shearar wrote:

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

Do you mean manually unloading packages?


Levente

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