March 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fwd: [squeak-dev] [ANN] Preference pragmas

by StÃ©phane Ducasse

>> Just because someone magically pretends to have come up with the same >> idea (and some others "coincidentally") without giving you credit >> for it >> does not mean that your work is suddenly obsolete. Please keep up the >> good work for Pharo!!! >> > thank for your support Michael. > but if I remember well, the idea is from Lukas, and Gary help me also. :) Stef ]

March 4, 2009

Re: [Pharo-project] Fwd: [squeak-dev] [ANN] Preference pragmas

by StÃ©phane Ducasse

So let us know when we integrate it :) Stef > StÃ©phane Ducasse a Ã©crit : >> I reread all the emails you exchanged with gary and igor. >> What is a parentNode in AbtsractPreferenceValue? >> This is when you have a composite preference? > yes >> I understood when reading the code of PrefProvider2 >> >>> no problem but tell me >>> that I stop working on this. >>> >>> The set of system preferences constitutes a tree of preferences. >>> The model for the tree is implemented by the PreferenceNode >>> hierarchy. >>> (see PrefCore2). This is the only mandatory part. >>> The tree can be visualized with a PreferenceTree UI built on top of >>> PrefCore2 (see PrefTool2 and snapshot). >>> Examples of preference declaration are given in PrefProvider2. >>> in order to open the tree: >>> PreferenceTree open >> >> I have two naive questions: >> - I imagine that we will be able to reuse the Preference browser >> and that we do not have to rebuild one? >> because the pragma preference collector could be put there? Or is >> it better to rewrite everything? > I guess we can reuse some parts. >> >> - second I was wondering why you only use <preference> and not >> <preference:zork:> like in andreas solution? >> Gary mentioned that some objects can be more complex than mere >> literal. > and he convinced me not to use <preference:zork:> for two main > reasons > -Only one model for preference in the image (no need to retrieve the > pragma or to store them in a second model) > -<preference:zork:> is flat, it allow on literals as parameters, so it > is very difficult to describe composites >> >> I was wondering if for the interface it would not be better to have >> cascaded selector instead of >> methods with multiple argument. >> >> PreferenceNode name: 'HTTP proxy' description: 'http proxy name >> and port' parent: #networkPreferenceNode >> vs >> PreferenceNode new >> name: 'HTTP proxy' ; >> description: 'http proxy name and port' ; >> parent: #networkPreferenceNode > ok for me. >> >> So can I summarize your approach as follow? >> >> - packages can defined locally their preferences (by construction >> this will be better >> since people will have to think about preferences value as their >> stuff. not the one of preference >> so this will help the flow to be local --- good. >> - preferences are not centralized anymore (youpi) >> - tools can register to get notified when preferences changes >> - preferences can be complex objects >> - preferences are structured in preferences tree. > exactly >> >> Sounds cool to me. I will let the other give their point of view. >> I'm leaving on vacation now. >> >> Stef >> >> PS: test should be >> >> >> "self test" >> PrefChangeListener new inspect. >> UIPreferences gradientButtonLook value: UIPreferences >> gradientButtonLook value not. >> UIPreferences gradientButtonLook value: UIPreferences >> gradientButtonLook value not. >> UIPreferences gradientButtonLook value: UIPreferences >> gradientButtonLook value not. > yes, this is the version you have in PrefListener.5.mcz > > alain >> >> >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 4, 2009

Re: [Pharo-project] Fwd: [squeak-dev] [ANN] Preference pragmas

by StÃ©phane Ducasse

+200 I think that Pharo is becoming cool and aggregating good energy and some people are afraid of it to succeed because of its good energy. And indeed such coincidence look suspicious to me. I only see great and cool stuff happening: no mvc, no etoy, lot of fixes,... and more soon Stef On Mar 4, 2009, at 8:24 PM, Michael Rueger wrote: > Alain Plantec wrote: >> Hi all, >> Here is a Preference engine based on pragma. >> please, check it and tell me if it is ok or not. >> If you prefer squeak version, no problem but tell me >> that I stop working on this. > > Well, I guess that is exactly what we don't want (that you stop > working > on it). > > Just because someone magically pretends to have come up with the same > idea (and some others "coincidentally") without giving you credit > for it > does not mean that your work is suddenly obsolete. Please keep up the > good work for Pharo!!! > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 4, 2009

[Pharo-project] A point a.k.a excuse to you

by Torsten Bergmann

>Lukas wrote: >> Why should it run on Squeak, if I have all my code running in Pharo? >> Keith wrote: >We have two equal and opposite questions you could ask. I would ask "Why >shouldn't it run on squeak?".... Nobody stops you to make Squeak compatible to Pharo so Lukas' code will also run on Squeak ;) But the more Pharo and Squeak evolve the harder it will be. Bye T. -- Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

March 4, 2009

Re: [Pharo-project] Fwd: [squeak-dev] [ANN] Preference pragmas

by Alain Plantec

Michael Rueger a Ã©crit : > Alain Plantec wrote: > >> Hi all, >> Here is a Preference engine based on pragma. >> please, check it and tell me if it is ok or not. >> If you prefer squeak version, no problem but tell me >> that I stop working on this. >> > > Well, I guess that is exactly what we don't want (that you stop working > on it). > > Just because someone magically pretends to have come up with the same > idea (and some others "coincidentally") without giving you credit for it > does not mean that your work is suddenly obsolete. Please keep up the > good work for Pharo!!! > thank for your support Michael. but if I remember well, the idea is from Lukas, and Gary help me also. Cheers alain > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

March 4, 2009

Re: [Pharo-project] Fwd: [squeak-dev] [ANN] Preference pragmas

by Alain Plantec

StÃ©phane Ducasse a Ã©crit : > I reread all the emails you exchanged with gary and igor. > What is a parentNode in AbtsractPreferenceValue? > This is when you have a composite preference? yes > I understood when reading the code of PrefProvider2 > >> no problem but tell me >> that I stop working on this. >> >> The set of system preferences constitutes a tree of preferences. >> The model for the tree is implemented by the PreferenceNode hierarchy. >> (see PrefCore2). This is the only mandatory part. >> The tree can be visualized with a PreferenceTree UI built on top of >> PrefCore2 (see PrefTool2 and snapshot). >> Examples of preference declaration are given in PrefProvider2. >> in order to open the tree: >> PreferenceTree open > > I have two naive questions: > - I imagine that we will be able to reuse the Preference browser > and that we do not have to rebuild one? > because the pragma preference collector could be put there? Or is > it better to rewrite everything? I guess we can reuse some parts. > > - second I was wondering why you only use <preference> and not > <preference:zork:> like in andreas solution? > Gary mentioned that some objects can be more complex than mere > literal. and he convinced me not to use <preference:zork:> for two main reasons -Only one model for preference in the image (no need to retrieve the pragma or to store them in a second model) -<preference:zork:> is flat, it allow on literals as parameters, so it is very difficult to describe composites > > I was wondering if for the interface it would not be better to have > cascaded selector instead of > methods with multiple argument. > > PreferenceNode name: 'HTTP proxy' description: 'http proxy name > and port' parent: #networkPreferenceNode > vs > PreferenceNode new > name: 'HTTP proxy' ; > description: 'http proxy name and port' ; > parent: #networkPreferenceNode ok for me. > > So can I summarize your approach as follow? > > - packages can defined locally their preferences (by construction > this will be better > since people will have to think about preferences value as their > stuff. not the one of preference > so this will help the flow to be local --- good. > - preferences are not centralized anymore (youpi) > - tools can register to get notified when preferences changes > - preferences can be complex objects > - preferences are structured in preferences tree. exactly > > Sounds cool to me. I will let the other give their point of view. > I'm leaving on vacation now. > > Stef > > PS: test should be > > > "self test" > PrefChangeListener new inspect. > UIPreferences gradientButtonLook value: UIPreferences > gradientButtonLook value not. > UIPreferences gradientButtonLook value: UIPreferences > gradientButtonLook value not. > UIPreferences gradientButtonLook value: UIPreferences > gradientButtonLook value not. yes, this is the version you have in PrefListener.5.mcz alain > > > >

March 4, 2009

Re: [Pharo-project] Fwd: [squeak-dev] [ANN] Preference pragmas

by Michael Rueger

Alain Plantec wrote: > Hi all, > Here is a Preference engine based on pragma. > please, check it and tell me if it is ok or not. > If you prefer squeak version, no problem but tell me > that I stop working on this. Well, I guess that is exactly what we don't want (that you stop working on it). Just because someone magically pretends to have come up with the same idea (and some others "coincidentally") without giving you credit for it does not mean that your work is suddenly obsolete. Please keep up the good work for Pharo!!! Michael

March 4, 2009

Re: [Pharo-project] Mac Carbon VM 4.0.0b1 Closure Compiler Aware with Alien support

by John M McIntosh

If the unix vm hasn't been updated with basic fixes or even critical fixes for the last two years, why would you put it on the critical decision path? The macintosh VM is available now, and I'd guess a windows VM should be available since no-doubt qwaq has been building a windows one for bleeding edge deployment since all this work (and more) is being funded by qwaq. On 4-Mar-09, at 9:19 AM, StÃ©phane Ducasse wrote: > sounds a good attitude. > We should fix the rest of the items then. > > Stef > > On Mar 4, 2009, at 6:00 PM, Adrian Lienhard wrote: > >> Do the major VMs (Unix, Mac, Win) support this *now*? >> What is the required work to include the closure changes (are they >> published somewhere?)? >> >> I'd like to avoid that we get a dependency on VMs that would delay >> version 1.0. If everything is ready, though, I would also vote for >> including them now. >> >> Cheers, >> Adrian >> -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

March 4, 2009

Re: [Pharo-project] Unicode test II

by Michael Rueger

Yoshiki Ohshima wrote: > So I loaded the good old FontForJapaneseEnvironment.sar and the > latter case it does display characters properly. do you have that anywhere available so I can check out what code it changes? Thanks for debugging! Michael

March 4, 2009

Re: [Pharo-project] Unicode test II

by Yoshiki Ohshima

At Tue, 03 Mar 2009 15:50:47 -0800, Michael Rueger wrote: > > Yoshiki Ohshima wrote: > > > On Windows Vista in Japanese, the system seems to get the unicode > > values from keyboard but doesn't display them correctly. For short > > Any idea why? I'm pretty sure I'm going through the correct process for > the leading char. Is there any glyph translation needed for the > rendering or the font import? - The char typed into the workspace doesn't have the leading char. - If I open the browser and go to JapaneseEnvironment class>>isBreakableAt:in: (possibly the only method with Japanese characters), it doesn't display characters, even though the result from #sourceCodeAt: does contain strings with leading chars. So I loaded the good old FontForJapaneseEnvironment.sar and the latter case it does display characters properly. -- Yoshiki

March 4, 2009