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/92b49fcaf9624b2ba57909...
- 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@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@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@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@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@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@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@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@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. >> >> >> >> >> >> >> >> >> > > > > > > >