Hi, On Dec 17, 2009, at 10:22 , Henrik Johansen wrote:
> I agree it seems to belong more in SmalltalkImage current than Smalltalk . > > TBH, I wouldn't mind if we split off a SmalltalkVM class as well :) > > I'm wondering about the comment in vmParameterAt: though, which states 40 is > "VM word size - 4 or 8 (read only)" > > 1) Jannik provided a wordSize: method for setting... Does this work? Yes it works :) > 2) In Interpreter >> primitiveVMParameter, the comment reads "40 BytesPerWord > for this image" > > I'd recon the VM comment is the correct one, and this is dependant on the > image and not the VM, seeing as how it returns 4 for a 32bit image on the > 64bit VM. > In which case, I definately feel wordSize semantically belongs to > SmalltalkImage (and thus should be cached there rather than SystemDictionary) > ;) So, we could do a cache class variable in SmalltalkImage instead of SystemDictonary. This is just a structural problem, not technical. I would do the better for pharo :) Jannik > > Cheers, > Henry > > On Dec 17, 2009, at 8:44 46AM, Stéphane Ducasse wrote: > >>> excellent >>> can you sync with marcus? >>> We will have to clean SystemDictionary because this is not a namespace but >>> a kind of clean trash. (when I compared to what is was). >>> I will start to think about what we want. but in a nutshell >>> >>> - a namespace class that only deals with binding (may be class >>> Smalltalk) >>> - a class that deals with image and VM code (may be called >>> SmalltalkImage) >>> >>> Stef >>> >>> On Dec 17, 2009, at 7:44 AM, Laval Jannik wrote: >>> >>>> Hi, >>>> >>>> I modify the variable in the method "clonePreStartup". >>>> So, it works fine. >>>> >>>> ===== >>>> !SystemTracer2 methodsFor: 'clone startup' stamp: 'ajh 8/22/2002 11:15'! >>>> clonePreStartup >>>> "This will be executed right away when the new clone starts up, before >>>> processStartup. Subclasses may want to rehash all objects or something" >>>> SystemDictionary wordSize: self wordSize.! ! >>>> ===== >>>> >>>> Now, there are some tests which does not pass. >>>> So, I will publish the code and the pharoImage64, and with the community, >>>> we can check this. >>>> >>>> Cheers, >>>> Jannik >>>> >>>> >>>> On Dec 17, 2009, at 02:32 , John M McIntosh wrote: >>>> >>>>> Ok, well I created Mantis >>>>> http://bugs.squeak.org/view.php?id=7430 >>>>> to document. >>>>> >>>>> Personally I would do >>>>> Smalltalk wordSize >>>>> versus >>>>> SystemDictionary wordSize >>>>> >>>>> Also the issue is when to change the WordSize variable. >>>>> >>>>> I think in >>>>> SmalltalkImage>>snapshot: andQuit: embedded: >>>>> right at the >>>>> ifTrue: [self quitPrimitive]. >>>>> Cursor normal show. >>>>> you want to set things so that wordSize is reset. >>>>> >>>>> At quit time you could do the reset before the >>>>> "self quitPrimitive" >>>>> then you know the value is reset and needs to be recalculated at startup >>>>> time. >>>>> or you can reset it before the >>>>> Cursor normal show. >>>>> which runs after startup time >>>>> >>>>> Somehow I think there is more risk resetting it after startup since I'm >>>>> not sure >>>>> when something could leap in wanting a valid value. >>>>> >>>>> >>>>> >>>>> On 2009-12-16, at 2:44 PM, Laval Jannik wrote: >>>>> >>>>>> Hi Eliot, hi John, >>>>>> >>>>>> This is what I do: >>>>>> - create a class var in SystemDictionary >>>>>> - accessors (wordSize and wordSize:), the first one can initialize the >>>>>> variable if nil, the second is to modify the value in case of 64bits >>>>>> image. >>>>>> Maybe the second one could be integrated in System-Tracing file. >>>>>> - in CompiledMethod, initialPC use it. >>>>>> >>>>>> Maybe we could integrate it in pharoCore. >>>>>> >>>>> >>>>> -- >>>>> =========================================================================== >>>>> John M. McIntosh <[email protected]> Twitter: >>>>> squeaker68882 >>>>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>>>> =========================================================================== >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
