- Pharo-dev - lists.pharo.org

[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

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

by Alain Plantec

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

Re: [Pharo-project] Instance variable readers/writers

by Davide Varvello

Yes, thanks. Davide Mariano Martinez Peck wrote: > > On Thu, Apr 29, 2010 at 4:00 PM, Davide Varvello <varvello(a)yahoo.com> > wrote: > >> >> Hi, >> Is there a way on Pharo to search for readers and writers of instance >> variables? >> > > Yes. Select a class, right button -> "refactoring scope" -> "instance > variable reader" or "instance variable writer" > > Did it work ? > > cheers > > mariano > > TIA >> Davide >> -- >> View this message in context: >> http://forum.world.st/Instance-variable-readers-writers-tp2075506p2075506.h… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> _______________________________________________ >> 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 > -- View this message in context: http://forum.world.st/Instance-variable-readers-writers-tp2075506p2075884.h… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 29, 2010

Re: [Pharo-project] status of i18n for Pharo

by Hilaire Fernandes

I never been through installing system change set before. However what I did to load the cs, is to make String>>translated to answer self, so I don't have the emergency debugger at least. I will try to see step by step what is going wrong in the String>>translated method. Are there any other way to proceed? Hilaire StÃ©phane Ducasse a Ã©crit : > try to identify the problem so that we fix it

April 29, 2010