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

[Pharo-project] Comments on Metacello and ConfigurationOfExternalWebBrowser

by Torsten Bergmann

FFI now has squeakCommon and external web browser has #pharo For further changes the repo is open ;) Bye T. -- Preisknaller: GMX DSL Flatrate fÃ¼r nur 16,99 Euro/mtl.! http://portal.gmx.net/de/go/dsl02

Jan. 13, 2010

Re: [Pharo-project] Issue 1807: Preferences color picker becomes uncontrollable.

by Gary Chambers

See ColorSelectorDialogWindow>>pickColor for a workaround... Regards, Gary ----- Original Message ----- From: "Stan Shepherd" <stan.shepherd414(a)gmail.com> To: <pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, January 13, 2010 2:48 PM Subject: [Pharo-project] Issue 1807: Preferences color picker becomes uncontrollable. > > Dev 10505 Ubuntu 9.04 and Xubuntu 9.10 > > system > preference > preference browser > window colors > click a color > > opens a preference browser, that is uncontrollable. > (enter and/or escape) regains control > > ...Stan > -- > View this message in context: > http://n2.nabble.com/Issue-1807-Preferences-color-picker-becomes-uncontroll… > 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

Jan. 13, 2010

Re: [Pharo-project] Comments on Metacello and ConfigurationOfExternalWebBrowser

by Mariano Martinez Peck

> > >#commonSqueak or something like that , which is for pharo and squeak (but > >not gemstone) > > It's called "squeakCommon" and I have no idea if "gemstone" means > the pharo based gemstone image Not, that's GemTools. Gemstone, is the Smalltalk gemstone. > or the server. Anything I see is that > FFI config also uses #common and developers for it are Esteban, you and > Dale. > I didn't do the FFI ;) In addition, if you see all the confs I announced I put everything in #pharo because I didn't test it in squeak. Actually, at the beginning, I put everything in #common but then Dale suggest me to put them in #pharo if I only tested there, and that's what I did. If them someone test it in squeak or gemstone, and works ok, then we can put it as common. But yes, everything that uses FFI, I think should be only in Squeak and Pharo as Gemstone does not support a "similar" FFI. > > So you should know ;) > > However - what if Metacello gets ported. Do we have an > "commercialSmalltalksCommon", "vastAndVW", ... or any other > combination or do we have to maintain a spec for any each platform. > > Would'nt it be better to have a spec and tell on which (multiple) > targets it is able to run. > > +1 I totally agree. That solution doesn't scale. The ideal would be if for: can also an array, as load: do for example: You can do load: 'aGroup' or load: #('group1' 'group2' ) So, maybe would be cool to do: for: #('squeak' 'pharo' .... ) what do you think? Questions over Questions ... > > Bye > T. > > > > > -- > Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 > - > sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 13, 2010

Re: [Pharo-project] Comments on Metacello and ConfigurationOfExternalWebBrowser

by Danie Roux

On Wed, Jan 13, 2010 at 5:11 PM, Torsten Bergmann wrote: > It's called "squeakCommon" and I have no idea if "gemstone" means > the pharo based gemstone image or the server. #gemstone refers to the server "platform", which has among other things a separate class library. The GemTools, or client, can be loaded into any Pharo or Squeak image and is not a platform on its own. > However - what if Metacello gets ported. Do we have an "commercialSmalltalksCommon", "vastAndVW", ... or any other combination or do we have to maintain a spec for any each platform. Squeak and Pharo still shares enough of a common base that you can load in most things into any one of them without modification. Hence #squeakCommon. When Metacello gets ported, that question will be addressed :-) -- Danie Roux *shuffle* Adore Unix - http://danieroux.com

Jan. 13, 2010

Re: [Pharo-project] Issue 1807: Preferences color picker becomes uncontrollable.

by Gary Chambers

Down to Sensor refactoring/polling... Speaking of which, not managed to get the non-polling version of InputEventFetcher to work... Regards, Gary ----- Original Message ----- From: "Stan Shepherd" <stan.shepherd414(a)gmail.com> To: <pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, January 13, 2010 2:48 PM Subject: [Pharo-project] Issue 1807: Preferences color picker becomes uncontrollable. > > Dev 10505 Ubuntu 9.04 and Xubuntu 9.10 > > system > preference > preference browser > window colors > click a color > > opens a preference browser, that is uncontrollable. > (enter and/or escape) regains control > > ...Stan > -- > View this message in context: > http://n2.nabble.com/Issue-1807-Preferences-color-picker-becomes-uncontroll… > 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

Jan. 13, 2010

[Pharo-project] Comments on Metacello and ConfigurationOfExternalWebBrowser

by Torsten Bergmann

>Come on!!! That's not an excuse Yes it is - maybe there is already a better or fixed version in a private repo of dale or the tutorial is not maintained anymore since according to http://code.google.com/p/metacello/wiki/Tutorial there is a real tutorial in preparation. Who knows without asking... >#commonSqueak or something like that , which is for pharo and squeak (but >not gemstone) It's called "squeakCommon" and I have no idea if "gemstone" means the pharo based gemstone image or the server. Anything I see is that FFI config also uses #common and developers for it are Esteban, you and Dale. So you should know ;) However - what if Metacello gets ported. Do we have an "commercialSmalltalksCommon", "vastAndVW", ... or any other combination or do we have to maintain a spec for any each platform. Would'nt it be better to have a spec and tell on which (multiple) targets it is able to run. Questions over Questions ... Bye T. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

Jan. 13, 2010

Re: [Pharo-project] PluggableTextMorph >> getText proposed modification

by Nicolas Cellier

2010/1/13 Levente Uzonyi <leves(a)elte.hu>: > On Wed, 13 Jan 2010, StÃ©phane Ducasse wrote: > >> Hi guys >> >> I would really like to get your feedback on this change because it seems >> to me that menu are not >> good enough. > > There were problems with String >> #numArgs, don't know if they still exist http://code.google.com/p/pharo/issues/detail?id=237 ? I think this should go in trunk too if not already here... > or not, but #isUnary seems to be a better (and faster) choice. > > > Levente > >> >> Stef >> >> On Jan 12, 2010, at 6:14 AM, Ralph Boland wrote: >> >>> In my (Squeak) project I modified PluggableTextMorph >> getText to be >>> as follows: >>> >>> getText >>> Â Â Â "Retrieve the current model text" >>> >>> Â Â Â | newText | >>> Â Â Â getTextSelector isNil ifTrue: [^Text new]. >>> Â Â Â newText := (getTextSelector numArgs = 1) >>> Â Â Â Â Â Â Â ifTrue: [model perform: getTextSelector with: self] >>> Â Â Â Â Â Â Â ifFalse: [model perform: getTextSelector]. >>> Â Â Â newText ifNil: [^Text new]. >>> Â Â Â ^newText shallowCopy >>> >>> >>> The change allows the getTextSelector to pass an additional argument: >>> self. >>> I made this change because I wanted to know which PluggableTextMorph >>> was asking for text. >>> This is useful when one has large numbers of similar PluggableTextMorphs. >>> Note that the method PluggableTextMorph >> Â acceptTextInModel >>> already does this so I didn't need to modify it. >>> Thus I think my change makes PluggableTextMorph more consistent. >>> >>> Any chance of this change being made a part of the Pharo image? >>> >>> Frankly, I would prefer that all the GUI objects that have get/set >>> messages >>> had this capability. Â For CheckBoxes Â I earlier added the capability to >>> return >>> either self or some arguments (by subclassing this time). >>> I am happy with the result. >>> >>> Another way I could do this would be to create a holder for the >>> PluggableTextMorph >>> (or other gui object) that would respond to the Â getText and >>> acceptTextInModel messages >>> and would know which PluggableTextMorph is speaking to it (since there >>> would be only one). >>> The holder would replace the model in the PluggableTextMorph and have >>> a reference to the original model to which it could forward messages. >>> Again this would allow me to have a large number of similar >>> PluggableTextMorphs. >>> One could create a Â PluggableTextMorphHolder class for this or create >>> a single holder >>> class that could work with different Morph classes (only one at a timeof >>> course) >>> (by responding to messages from all of them). Â It would be nice of >>> course if these >>> GUI holders already existed in Squeak/Pharo so I didn't have to invent >>> them. >>> >>> Which approach do you think is better? >>> >>> Regards, >>> >>> Ralph Boland >>> >>> >>> -- >>> I've been middle class and I've been poor. >>> Middle class is better. >>> >>> _______________________________________________ >>> 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 >

Jan. 13, 2010

[Pharo-project] Issue 1807: Preferences color picker becomes uncontrollable.

by Stan Shepherd

Dev 10505 Ubuntu 9.04 and Xubuntu 9.10 system preference preference browser window colors click a color opens a preference browser, that is uncontrollable. (enter and/or escape) regains control ...Stan -- View this message in context: http://n2.nabble.com/Issue-1807-Preferences-color-picker-becomes-uncontroll… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 13, 2010

Re: [Pharo-project] Comments on Metacello and ConfigurationOfExternalWebBrowser

by Mariano Martinez Peck

On Wed, Jan 13, 2010 at 3:34 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > >They are doing an excellent work > > +1 > > >if you saw the typos, an if it was even versioned code, why didn't you > >fix them and commit ? > > It's in package "Metacello-Tutorial" and the repo > http://seaside.gemstone.com/ss/metacello is READ only > > Come on!!! That's not an excuse ;) You can send the .ch for mail, ask for access, etc :) > >Don't put initials. > > But the examples in the lesson use initials "dkh". Thats why I asked and > recommended more infos (name, initials, contact) like in Java Maven POM's. > > mmm now that I think it again, is true, sometimes I saw dkh instead of the name...You are right. Let's wait what Dale says. > >I have two erros > > Dont know about your image, config and changes - I just tried in a > clean udated core image #10506 > > >you are using for FFI '1.0-baseline' > > Thats by intention since I dont think there will be another baseline > and I want the latest. But since I use it with transitive dependency > in a release version of ExternalWebBrowser you are right. It's fixed now. > > >And the other thing is that you put everything under spec for: #common > > Depends on the meaning of common (only Pharo and other Squeak > Distributions) or does it include other Smalltalks (VW, VAST) too? > #common always mean common, all. Metacello *should* work on every Smalltalk that supports Monticello. Right now, I know it is working in Squeak, Pharo and Gemstone. So, if it works in all of them, then it is correct to put them in #common. Otherwise, put it where it works. There is also something like #commonSqueak or something like that , which is for pharo and squeak (but not gemstone). But I don't remember exactly how is it. > If Metacello gets ported then you are right. > > The tutorial only says: > "In addition to #common, there are pre-defined attributes for each of the > platforms upon which Metacello runs (#pharo, #squeak, #gemstone and > #squeakCommon)." > > However FFI (which is definitely limited to Squeak derivates) > is also #common and I used it as a template. > > Maybe #squeakCommon is right for FFI and ExternalWebBrowser > since this is what is used in the seaside, swazoo, ... configs. > > Exactly :) > Bye > T. > > > -- > Preisknaller: GMX DSL Flatrate fÃ¼r nur 16,99 Euro/mtl.! > http://portal.gmx.net/de/go/dsl02 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 13, 2010

Re: [Pharo-project] Network tests - Pharo vs. Squeak

by Schwab,Wilhelm K

Adrian It might. IIRC, there is at least one IPV6-specific primitive method that is called w/o checking #useOldNetwork. My working image contains attempts at fixing that, so I should probably try a fresh image on the offending machines. Is there really a useOldNetwork setting? I do not see anything in 10505 dev. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Wednesday, January 13, 2010 4:27 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Network tests - Pharo vs. Squeak Hi Bill, If I remember correctly the consensus was to enable the useOldNetwork setting (at least in 1.0 and until the new implementation works reliably). Somehow we forgot to do that. Wouldn't that solve the problem? Cheers, Adrian On Jan 12, 2010, at 23:27 , Schwab,Wilhelm K wrote: > Hello all, > > I was recently reminded of network problems, such as a need to force the use of the "old network" on at least some Linux machines, and that I have had mixed results on Windows (not sure what is causing grief there, but suspects include 2k3 vs. xp, bad network setup in general and ipv6 in particular). > > So far, I have only one useful method that establishes a connection queue, then uses SocketStream to connect to is as locahost, enters a loop on #getConnectionOrNil, and then finally does some I/O. As I said, results are mixed. > > Another test that needs to be done is split the client and server across a real network. I can do that (perhaps subject to weird constraints) between win2k, 2k3 and Linux. I tend to think of Linux as the client, but I might be able to flip that around. > > My expectation (I can't believe I'm typing this<g>) is that Squeak will perform better than Pharo, only because of the "new network" changes, which I believe to be the cause of the problems. > > I envision something like a friendly root kit: get each machine to download both Pharo and Squeak, and install a small .mcz into each image. The idea is to allow many of us to try this on different networks and platforms, and to merge the results. > > For remote testing, there would probably need to be a server class with start/stop methods, and the client side test methods would hopefully log what they can. On successful remote conversation, the client should be able to automatically log details about the server, having read the details over the network. > > Suggestions on how to build this would be greatly appreciated. Can it all be done with Sunit, or is that asking too much? > > Bill > > > _______________________________________________ > 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

Jan. 13, 2010