April 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] Re: [Vm-dev] Fwd: is it possible to know the memory occupation (bytes) of an object?

by Mariano Martinez Peck

On Thu, Apr 29, 2010 at 6:00 PM, Andreas Raab <andreas.raab(a)gmx.de> wrote: > On 4/29/2010 6:22 AM, Mariano Martinez Peck wrote: > >> and then I call it like this for example: >> >> oop := self firstAccessibleObject. >> [oop = nil] whileFalse: [ >> (self isIntegerObject: oop) >> ifFalse: [ >> size := self internalByteSize: oop. >> ......] >> oop := self accessibleObjectAfter: oop. >> ]. >> > > Do you realize that this simple computes the used memory which is > information that's directly accessible via the vm parameters? I don't recall > which one but you might want to look at these to see if they already have > what you need. > Thanks Andreas. I guess I should have explained my situation. Basically, what I was trying to do (and I did at the end) is to use the last free bit of the object header to use it to detect used and unused objects. I modified the VM so that when an object receives a message, it enables such bit. I also have primitives to mark and unmark all objects. I am not sure what I will do then with the unused objects, but for the moment, I just wanted to get numbers. Statistics. So, for example I wanted to know how many objects were with the bit on and how many with the bit off. Also the amount of memory those objects represents. The method is: primitiveGetStadistics | oop usedCount unusedCount results usedMemory unusedMemory usedCountOop unusedCountOop usedMemoryOop unusedMemoryOop | usedCount := unusedCount := 0. usedMemory := unusedMemory := 0. self print: 'Start to check objects'; cr. oop := self firstAccessibleObject. [oop = nil] whileFalse: [ (self isIntegerObject: oop) ifFalse: [ (self internalIsUsed: oop) ifTrue: [ usedCount := usedCount +1. usedMemory := usedMemory + (self internalByteSize: oop). ] ifFalse: [ unusedCount := unusedCount +1. unusedMemory := unusedMemory + (self internalByteSize: oop). ]. ]. oop := self accessibleObjectAfter: oop. ]. self print: 'Finish to check objects'; cr. self print: 'Push stadistics'; cr. self pushRemappableOop: (self instantiateClass: (self classArray) indexableSize: 4). self pushRemappableOop: (self positive64BitIntegerFor: usedCount). self pushRemappableOop: (self positive64BitIntegerFor: usedMemory). self pushRemappableOop: (self positive64BitIntegerFor: unusedCount). self pushRemappableOop: (self positive64BitIntegerFor: unusedMemory). self print: 'Pop stadistics'; cr. unusedMemoryOop := self popRemappableOop. unusedCountOop := self popRemappableOop. usedMemoryOop := self popRemappableOop. usedCountOop := self popRemappableOop. results := self popRemappableOop. self print: 'Write stadistics in array'; cr. self storePointer: 0 ofObject: results withValue: usedCountOop. self storePointer: 1 ofObject: results withValue: unusedCountOop. self storePointer: 2 ofObject: results withValue: usedMemoryOop. self storePointer: 3 ofObject: results withValue: unusedMemoryOop. self print: 'Push result array in stadistics'; cr. self pop: 1 thenPush: results. And as you may guess, internalIsUsed: oop self inline: true. ^((self baseHeader: oop) bitAnd: UsedObjectBit) ~= 0 So then, from the image side, I can get statistics at certain point, and get something like the attached screenshot. Thanks. Mariano > > Cheers, > - Andreas > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 29, 2010

Re: [Pharo-project] ConfigurationOfPharo and OmniBrowser

by Alexandre Bergel

Ok, I will check. Alexandre On 29 Apr 2010, at 14:08, Dale Henrichs wrote: > Mariano and Alexandre, > > Sorry for the late reply ... I've been off-line with a cold for the > last several days ... > > I have seen the behavior that you describe while working with GLASS > 1.0-beta.8 and have fixed the problem in Metacello 1.0-beta.26.1 ... > 1.0-beta.26.1 is still in development, but if you want to give it a > try, preload 1.0-beta.26.1 and rerun your test ... if the problem > still persists, let me know and I will dive into it. > > Dale > ----- "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote: > > | On Wed, Apr 28, 2010 at 11:28 PM, Alexandre Bergel < > | alexandre.bergel(a)inria.fr> wrote: > | > | > It is a bit more subtle than that. > | > > | > If I take a Core 1.1, and doit: ConfigurationOfPharo project > | lastVersion > | > load > | > Then I get a warning coming from OBSearchBrowser class related to > | the world > | > menu registration. > | > > | > > | Yes, I noticed that. > | > | > | > At that moment, OmniBrowser-lr.458 and OB-Morphic-lr.112 are > | loaded. > | > > | > Doing twice a proceed resume the loading. > | > It then blocks on SHWorkspace, for the very same reason. > | > > | > > | yes.. > | > | > | > After having manually fixed the Nile problem (isInMemory), Pharo > | loads > | > well. ProfStef is open. > | > > | > > | I did the same... > | > | > | > OmniBrowser-lr.469 and OB-Morphic-lr.116 are loaded. This means > | that > | > OmniBrowser is loaded twice. Is this the intended behavior? > | > > | > > | I saw directly the final versions: 469 and 116. I didn't notice it > was > | first > | trying to load 458 and 112. > | I know that in such conflict, Metacello will load the last one, > but I > | didnt > | know that it actually LOADS also the previous versions. I thought > that > | it > | only loads the final version, not both of them. In such case, I > think > | it is > | a metacello bug. > | > | See this link: > | http://groups.google.com/group/metacello/browse_thread/thread/e8a08b3ed1a9b… > | > | Dale, can you help us? > | > | Thanks > | > | Mariano > | > | > Alexandre > | > > | > > | > > | > On 28 Apr 2010, at 11:40, Mariano Martinez Peck wrote: > | > > | > > | >> > | >> On Wed, Apr 28, 2010 at 3:22 PM, Alexandre Bergel > | <alexandre(a)bergel.eu> > | >> wrote: > | >> Hi! > | >> > | >> I am now trying to make ConfigurationOfPharo load the last > version > | of > | >> OmniBrowser. > | >> If I do in a fresh core: ConfigurationOfPharo project lastVersion > | load > | >> > | >> Then OmniBrowser-lr.458 and OB-Morphic-lr.112 are loaded. > | >> > | >> > | >> No. If you take a PharoCore 1.0 OR 1.1 and evaluate > | ConfigurationOfPharo > | >> project lastVersion load > | >> > | >> It installs OmniBrowser-lr.469 and OB-Morphic-lr.116 > | >> which are correct as those are defined in > | ConfigurationOfOmniBrowser > | >> version 1.1.2. And ConfigurationOfPharo 1.1 has 1.1.2 of OB. > | >> > | >> > | >> The loading blocks on the deprecated warning (yes, the > registration > | in the > | >> World menu). > | >> In ConfigurationOfPharo>>version11: I have > | >> > | >> spec > | >> project: 'PharoNonCorePackages' > | with: > | >> '1.1.0'; > | >> project: 'NewInspector' with: > '1.1'; > | >> project: 'Shout' with: '1.0'; > | >> project: 'Shout Tests' with: '1.0'; > | >> project: 'OCompletion' with: '1.1'; > | >> project: 'OCompletion Tests' with: > | '1.1'; > | >> project: 'OB Dev' with: '1.1.3'; > | >> project: 'OB Dev Tests' with: > | '1.1.3'; > | >> ... > | >> > | >> I therefore assume that the version 1.1.3 of OmniBrowser is > | loaded. > | >> 1.1.3 is indeed the last version specified in > | ConfigurationOfOmniBrowser: > | >> ConfigurationOfOmniBrowser project lastVersion > | >> => ~1.1.3 [ConfigurationOfOmniBrowser] > | >> > | >> But I evaluate: ConfigurationOfOmniBrowser project lastVersion > | load > | >> Then the version OB-Morphic-lr.116, OB-Standard-lr.463 and > | >> OmniBrowser-lr.469 are loaded. > | >> > | >> > | >> Exactly. And that's correct. Those are the versions that are > | defined in > | >> ConfigurationOfOmnibrowser 1.1.3 > | >> > | >> I find it is very hard to keep track of what is actually loaded. > | >> > | >> > | >> I don't understand your problem. Everything seems to work as > | exepected. > | >> > | >> > | >> I haven't closely followed the evolution of Metacello, but > there is > | not a > | >> way to say: > | >> spec project: 'OB Dev' with: 'lastestVersion' > | >> > | >> Yes. Don't put any version. If you don't define a version, > | metacallo will > | >> load the last one. > | >> > | >> project: 'OB Dev'; > | >> > | >> or even remove that line from the version method. Even more, if > | you want > | >> ALL the last, you can load the baseline instead of the version. > In > | such > | >> case, as you don't specify any version, it will download all the > | last ones. > | >> > | >> Cheers > | >> > | >> Mariano > | >> > | >> > | >> Or Something? > | >> > | >> Cheers, > | >> Alexandre > | >> -- > | >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > | >> Alexandre Bergel http://www.bergel.eu > | >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > | >> > | >> > | >> > | >> > | >> > | >> > | >> _______________________________________________ > | >> Pharo-project mailing list > | >> Pharo-project(a)lists.gforge.inria.fr > | >> > | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > | >> > | >> _______________________________________________ > | >> Pharo-project mailing list > | >> Pharo-project(a)lists.gforge.inria.fr > | >> > | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > | >> > | > > | > > | > _______________________________________________ > | > Pharo-project mailing list > | > Pharo-project(a)lists.gforge.inria.fr > | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- > project > | > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 29, 2010

Re: [Pharo-project] ConfigurationOfPharo and OmniBrowser

by Dale Henrichs

April 29, 2010

[Pharo-project] ICMP/ping

by Damien Cassou

Dear list, is it possible to ping a host from pharo ? It seems that OSProcess would do, but it is for a windows machine and I haven't found a pre-compiled library. Thank you -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

April 29, 2010

Re: [Pharo-project] [squeak-dev] Re: Menu Registries

by Henrik Johansen

Thanks! I'll make sure to look at it when I get home. Cheers, Henry Den 29. apr. 2010 kl. 19.26 skrev Alain Plantec <alain.plantec(a)free.fr>: > http://code.google.com/p/pharo/issues/detail?id=2370 > > Alain Plantec a Ã©crit : >> Alain Plantec a Ã©crit : >>> Henrik Johansen a Ã©crit : >>>> It needs a way to register new valid preference pragmas, and >>>> setting generators for such pragmas. >>>> May I suggest... using pragmas? ;P >>>> >>> :) >>> I've checked and only two methods has to be adapted and one added >>> in Pharo. >>> Then a compatibility package can be implemented for Squeak. >>> This package is optional and could be available for pharo-dev. >>> I will provide it soon. >>> Alain >> SLICE-SystemSettings-SqueakCompatibility is in the InBox. >> The SqueakPreferences package is attached. >> Henrik, can you check and put it somewhere for pharo-dev ? >> >> For now, It only contains the following method: >> ---------------- >> SettingTreeBuilder>>preference: prefName category: category >> description: description type: type >> <settingPragmaProcessor> >> "Process a Squeak preference pragma" >> .... >> ---------------- >> It is tagged by the #settingPragmaProcessor pragma which is used by >> the builder >> when a SettingBrowser is opened in order to retrieve current >> settings keywords. >> >> For Pharo settings, the following is implemented >> ---------------- >> SettingTreeBuilder>>systemsettings >> <settingPragmaProcessor> >> "Process a <systemsettings> pragma" >> currentPragma methodClass theNonMetaClass perform: currentPragma >> selector with: self. >> ---------------- >> >> So, if Squeak makes use of a new pragma, the only thing to do is to >> add a >> similar method in the SqueakPreferences package and tag it with a >> #settingPragmaProcessor pragma. >> >> thanks to Andreas for its cs, I've removed one method and changed >> another one. >> >> Cheers >> Alain >> >> >>> >>>> Cheers, >>>> Henry >>>> >>> >>> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 29, 2010

Re: [Pharo-project] [squeak-dev] Re: Menu RegistriesÃ¥

by Henrik Johansen

+1. This is close to what I intended to write after "on the positive", but forgot :) (probably better than I would have, though) Cheers, Henry Den 29. apr. 2010 kl. 19.40 skrev Eliot Miranda <eliot.miranda(a)gmail.com>: > > and I don't think that having: > > ------------------ > Editor class>>blinkingCursor > ^ BlinkingCursor ifNil: [ true ] > > EditorSetting class>>editorSettingsOn: aBuilder > <systemsettings> > (aBuilder setting: #blinkingCursor) > label:'Blinking Text Cursor') > parent: #Morphic; > target: Editor; description: 'When true, the text cursor will > blink.' > ------------------- > > is so much more "complicated" than > > ------------------- > Editor class>>blinkingCursor > <preference: 'Blinking Text Cursor' > category: 'Morphic' > description: 'When true, the text cursor will blink.' > type: #Boolean> > ^ BlinkingCursor ifNil: [ true ] > ------------------- > > Well the former is executable and must be executable. The latter is > not necessarily executable (but its good if it is, because one can > locate the code that processes the specification) . So they're the > same on that level. But the former can only be executable and isn't > separated from the processing code, whereas the latter is > separated. The former also only works in context (aBuilder) whereas > the latter stands alone, and this ability to stand alone, as a > specification, loosely coupled to the settings maintennance system > is one thing that makes it simpler. It also clearly states the > default value which the former doesn't. So I find the latter > significantly easier to understand, and given I understand the > method annotation system I find the mechanics not that much more > complicated than the former's. We all understand perform: right? > > > You prefer UI+domain mixing, we prefer UI separated from domain. > > I see the opposite. I see good separation in the latter example but > I don't see the separation in the former. And BTW this is me trying > to think critically, trying to keep happy feet in both the Pharo and > Squeak (and eToys and Cuis and ....) camps, not trying to be > tribal. Apologies in advance if expressing a contradictory view is > taken as offensive. > > > And yes, the SettingBrowser implementation could be improved. > I know, but I'm happy because it can be removed or remade > without any other consequence. > And compare it to the PreferenceBrowser ... > > Cheers > Alain > > > best > Eliot > > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 29, 2010

Re: [Pharo-project] Metacello project dependencies

by Dale Henrichs

Torsten, Sorry for the late reply ... caught a nasty cold and used the opportunity to stop reading email for a couple of days ... It looks like the original problem was that ArchiveViewer was included in the group names but was no longer defined in 1.1-baseline. When using a configuration directly, only the target version is excercised. However, when used as prerequisite, the currentVersion of a project is calculated which ends up excercising all of the versions. Your problem points out the need for a Metacello verifier (there's a bug for that:) that finds these kinds of problems. It looks like the extra ArchiveViewer entry in the group has been removed so the load worked fine for me this morning:) Dale ----- "Torsten Bergmann" <astares(a)gmx.de> wrote: | When I load version "1.0-10517" of ConfigurationOfPharo in a clean | core 1.0#10517 image it works. | | But when I use the "1.0-10517" version of Pharo as a prerequisite in a | | project (for instance Metasource) within the same image I get a "Name | not found - ArchiveViewer" error. The config looks OK to me. | I'm puzzled ... | | If you want to try, use | https://gforge.inria.fr/frs/download.php/26790/Pharo-1.0.zip | and evaluate: | | | Gofer new | squeaksource: 'MetaSource'; | package: 'ConfigurationOfMetaSource'; | load. | | ((Smalltalk at: #ConfigurationOfMetaSource) project version: | '1.0-alpha3') load. | | | Bye | T. | -- | GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! | Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 29, 2010

Re: [Pharo-project] [squeak-dev] Re: Menu Registries

by Eliot Miranda

I have to say that devolving any technical discussion into "you think this..." and "we think that..." is a very quick way to destroy any ability to think critically in a technical discussion. This isn't Andreas "liking" anything, this is the result of having thought critically and objectively about the issues. Can we please act like engineers and scientists ought? Substantive comments below. On Thu, Apr 29, 2010 at 3:21 AM, Alain Plantec <alain.plantec(a)free.fr>wrote: > Andreas Raab a Ã©crit : > > On 4/28/2010 11:32 PM, StÃ©phane Ducasse wrote: >> >>> Good but what is your point? >>> >> >> Compatibility and simplicity. >> > Come on Andreas, "simple" is not so much more precise than "cool" > > and I don't think that having: > > ------------------ > Editor class>>blinkingCursor > ^ BlinkingCursor ifNil: [ true ] > > EditorSetting class>>editorSettingsOn: aBuilder > <systemsettings> > (aBuilder setting: #blinkingCursor) > label:'Blinking Text Cursor') > parent: #Morphic; > target: Editor; description: 'When true, the text cursor will blink.' > ------------------- > > is so much more "complicated" than > > ------------------- > Editor class>>blinkingCursor > <preference: 'Blinking Text Cursor' > category: 'Morphic' > description: 'When true, the text cursor will blink.' > type: #Boolean> > ^ BlinkingCursor ifNil: [ true ] > ------------------- > Well the former is executable and must be executable. The latter is not necessarily executable (but its good if it is, because one can locate the code that processes the specification) . So they're the same on that level. But the former can only be executable and isn't separated from the processing code, whereas the latter is separated. The former also only works in context (aBuilder) whereas the latter stands alone, and this ability to stand alone, as a specification, loosely coupled to the settings maintennance system is one thing that makes it simpler. It also clearly states the default value which the former doesn't. So I find the latter significantly easier to understand, and given I understand the method annotation system I find the mechanics not that much more complicated than the former's. We all understand perform: right? > You prefer UI+domain mixing, we prefer UI separated from domain. > I see the opposite. I see good separation in the latter example but I don't see the separation in the former. And BTW this is me trying to think critically, trying to keep happy feet in both the Pharo and Squeak (and eToys and Cuis and ....) camps, not trying to be tribal. Apologies in advance if expressing a contradictory view is taken as offensive. > And yes, the SettingBrowser implementation could be improved. > I know, but I'm happy because it can be removed or remade > without any other consequence. > And compare it to the PreferenceBrowser ... > > Cheers > Alain > > best Eliot > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 29, 2010

Re: [Pharo-project] [squeak-dev] Re: Menu Registries

by Eliot Miranda

On Thu, Apr 29, 2010 at 4:53 AM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > On Apr 29, 2010, at 1:44 29PM, Alain Plantec wrote: > > > Henrik Johansen a Ã©crit : > >> On Apr 29, 2010, at 11:30 06AM, StÃ©phane Ducasse wrote: > >> > >> It's not a question of one vs. the other, really. > >> The cs doesn't change the Settings implementation, it simply adds > support for also discovering settings defined in the pragma style used by > Squeak. > >> The downside is you'd have two ways to define settings. > >> The upside is the > > the upside is ... :) > > well, I will have a look at the cs. > > I would prefer that this changes do not introduce any > > overwriting so that it can be loaded separately as a compatibility > package. > > so, i will investigate the changes needed for the settingbrowser. > > is that ok like that ? > > Cheers > > Alain > > It needs a way to register new valid preference pragmas, and setting > generators for such pragmas. > May I suggest... using pragmas? ;P > This ids the way it works (and has worked for nearly 10 years) in VisualWorks. On the class side one can declare the pragmas a class supports using pragmas. One uses pragmas to avoid having one method that defines all pragmas for a class, which would create a potential conflict between packages of the kind that pragmas help avoid. When the compiler encounters a pragma it searches the class side looking for the pragmas that are "in scope" at the moment. The argument to the pragma: pragma is a symbol stating which side of the class the pragma is valid (why they don't support #both or #(class instance) I don't know). Here are some examples: AboutVisualWorksPage class methods for private pagePragma <pragmas: #class> ^#(pageOrder:) systemPragma <pragmas: #class> ^#(systemInformation:) BlockClosure class methods for private exceptionPragmas <pragmas: #instance> ^#(#exception:) StandardSystemController class methods for resources menuMethodPragmas <pragmas: #instance> <pragmas: #class> ^Menu pragmas With this approach a package can add its own method annotations to a hierarchy without conflicting with any other package. Here's the VW code that fetches the pragmas understood by a class: Metaclass methods for compiling recognizedMethodPragmas ^self soleInstance recognizedMethodPragmas: #class Class methods for compiling recognizedMethodPragmas ^self recognizedMethodPragmas: #instance requiredRecognizedPragmas ^#(#pragmas: #primitive: #primitive:errorCode:) recognizedMethodPragmas: type "The 'type' argument may be either #class or #instance" | list beh | list := IdentitySet withAll: self requiredRecognizedPragmas. beh := self class. [beh isMeta] whileTrue: [beh selectorsAndMethodsDo: [:sel :meth | | pragmas | pragmas := meth attributeMessages. pragmas == nil ifFalse: [pragmas do: [:msg | (msg selector = #pragmas: and: [msg arguments first = type]) ifTrue: [list addAll: (beh soleInstance perform: sel)]]]]. beh := beh superclass]. ^list Simple, but fabulously meta. Thank Steve Dahl for this idea. Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 29, 2010

Re: [Pharo-project] [squeak-dev] Re: Menu Registries

by Alain Plantec

http://code.google.com/p/pharo/issues/detail?id=2370 Alain Plantec a Ã©crit : > Alain Plantec a Ã©crit : >> Henrik Johansen a Ã©crit : >>> It needs a way to register new valid preference pragmas, and setting >>> generators for such pragmas. >>> May I suggest... using pragmas? ;P >>> >> :) >> I've checked and only two methods has to be adapted and one added in >> Pharo. >> Then a compatibility package can be implemented for Squeak. >> This package is optional and could be available for pharo-dev. >> I will provide it soon. >> Alain > SLICE-SystemSettings-SqueakCompatibility is in the InBox. > The SqueakPreferences package is attached. > Henrik, can you check and put it somewhere for pharo-dev ? > > For now, It only contains the following method: > ---------------- > SettingTreeBuilder>>preference: prefName category: category > description: description type: type > <settingPragmaProcessor> > "Process a Squeak preference pragma" > .... > ---------------- > It is tagged by the #settingPragmaProcessor pragma which is used by > the builder > when a SettingBrowser is opened in order to retrieve current settings > keywords. > > For Pharo settings, the following is implemented > ---------------- > SettingTreeBuilder>>systemsettings > <settingPragmaProcessor> > "Process a <systemsettings> pragma" > currentPragma methodClass theNonMetaClass perform: currentPragma > selector with: self. > ---------------- > > So, if Squeak makes use of a new pragma, the only thing to do is to add a > similar method in the SqueakPreferences package and tag it with a > #settingPragmaProcessor pragma. > > thanks to Andreas for its cs, I've removed one method and changed > another one. > > Cheers > Alain > > >> >>> Cheers, >>> Henry >>> >> >> >

April 29, 2010