On 28 October 2013 22:59, Levente Uzonyi leves@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/92b49fcaf9624b2ba57909...
- 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@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.