[squeak-dev] MNU: Parser >> #contents

Frank Shearar frank.shearar at gmail.com
Thu Oct 3 10:44:53 UTC 2013


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


More information about the Squeak-dev mailing list