On 28 October 2013 22:59, Levente Uzonyi <leves at elte.hu> wrote:
> 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?

I mean repeating what I did before, so yes. Where "manual" means "by
running a script", at least. Then, once again, the output of the
SqueakTrunk job will be a semistripped image that the
ReleaseSqueakTrunk job will "re-inflate".

frank

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