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

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

by Gary Chambers

----- Original Message ----- From: "Norbert Hartl" <norbert(a)hartl.name> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Friday, March 06, 2009 10:59 AM Subject: Re: [Pharo-project] [Fwd: Re: [ANN] Preference pragmas] >> You're really just inventing a half-baked Magritte now. Do >> yourself a favor and use the real thing. Magritte is far more >> descriptive and far less verbose than anything you have yet >> presented. Magritte also already knows how to automatically create both >> seaside and morphic forms out of a field description. It also >> knows more ways to look up a field than just selector and block. >> > I don't think so. This is a definition of composite value model. The > value model does not need to reflect the structure of the objects > that use those preferences. Magritte on the other side would describe > the other model as it is a meta-model description. And Magritte is a > lot more heavy weight. So while it looks similar I can't see what you > are telling. > But you could use Magritte to describe this model ad then generate > a UI out of it ;) > > Norbert > Yes, Magritte seems like overkill for this. After all, the Preference needs to be modelled anyway otherwise all the classes that defined preferences (locally) would need Magritte descriptions. Also, I don't think that Magritte currently supports tree visualisations... Magritte can be quite handy though as long as one is not particularly bothered about decent control over the layout of the ui elements (we use it in the ReportBuilder for catalog-object properties). Regards, Gary

March 6, 2009

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

by Matthew Fulmer

On Fri, Mar 06, 2009 at 12:02:54PM +0100, Alain Plantec wrote: > Anyway, it seems very interesting and I would like to learn a bit about > Magritte even it is not possible to use it for preferences. > As an example, could you explain how you specify the themePreference > with Magritte ? > Maybe it can help us to improve our implementation. Hehe. I've already done that twice now: http://lists.gforge.inria.fr/pipermail/pharo-project/2009-March/006202.html prefTheme <preference category: 'User Interface'> ^ MASingleOptionDescription new options: #( 'Vistary' 'Watery' 'Squeak' 'Soft Squeak' ); reference: MAStringDescription new; autoAccessor: 'theme'; label: 'Theme'; priority: 40; beSorted; yourself -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

March 6, 2009

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

by Norbert Hartl

On Fri, 2009-03-06 at 12:02 +0100, Alain Plantec wrote: > Matthew Fulmer a Ã©crit : > > On Fri, Mar 06, 2009 at 10:36:13AM +0100, Alain Plantec wrote: > > > >> themePreference > >> <preference> > >> ^ ThemePreference > >> ifNil: [ThemePreference := MultiplePreferenceValue > >> name: 'UITheme' > >> description: 'The theme to use for UI look and feel' > >> parent: #uiPreferenceNode > >> type: #UITheme > >> default: UIThemeWatery2 > >> values: { > >> FixedPreferenceValue > >> name: 'Standard Squeak' > >> description: 'Standard Squeak style' > >> type: #UITheme > >> > >> value: UIThemeStandardSqueak. > >> FixedPreferenceValue > >> name: 'Watery 2' > >> description: 'Similar to a nice OS' > >> type: #UITheme > >> value: UIThemeWatery2}] > >> > > > > > Hi Matthew, > > You're really just inventing a half-baked Magritte now. > Surely, but, for now, Magritte is not in the base system. > Maybe you can send some advices or ideas about how we can improve > the preference system. > > And the <preference:ziag:zig:> way is still a solution we can adopt back > if the pharo community prefers it. > > > Do > > yourself a favor and use the real thing. Magritte is far more > > descriptive and far less verbose than anything you have yet > > presented. Magritte also already knows how to automatically create both > > seaside and morphic forms out of a field description. It also > > knows more ways to look up a field than just selector and block. > > > Anyway, it seems very interesting and I would like to learn a bit about > Magritte even it is not possible to use it for preferences. > As an example, could you explain how you specify the themePreference > with Magritte ? > Maybe it can help us to improve our implementation. > Thanks > alain > I'm not sure but I'm starting to understand what Matthew wanted. I think the description would like this descriptionThemePreference ^ MASingleOptionDescription new selectorAccessor: #themePreference; label: 'The theme to use for UI look and feel'; reference: MAClassDescription new; options: {UIThemeStandardSqueak. UIThemeWatery2}; default: UIThemeWatery2; priority: 1000; yourself Hmmm, I'm not sure if I should revoke my former mail :) Norbert

March 6, 2009

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

by Alain Plantec

Matthew Fulmer a Ã©crit : > On Fri, Mar 06, 2009 at 10:36:13AM +0100, Alain Plantec wrote: > >> themePreference >> <preference> >> ^ ThemePreference >> ifNil: [ThemePreference := MultiplePreferenceValue >> name: 'UITheme' >> description: 'The theme to use for UI look and feel' >> parent: #uiPreferenceNode >> type: #UITheme >> default: UIThemeWatery2 >> values: { >> FixedPreferenceValue >> name: 'Standard Squeak' >> description: 'Standard Squeak style' >> type: #UITheme >> >> value: UIThemeStandardSqueak. >> FixedPreferenceValue >> name: 'Watery 2' >> description: 'Similar to a nice OS' >> type: #UITheme >> value: UIThemeWatery2}] >> > > Hi Matthew, > You're really just inventing a half-baked Magritte now. Surely, but, for now, Magritte is not in the base system. Maybe you can send some advices or ideas about how we can improve the preference system. And the <preference:ziag:zig:> way is still a solution we can adopt back if the pharo community prefers it. > Do > yourself a favor and use the real thing. Magritte is far more > descriptive and far less verbose than anything you have yet > presented. Magritte also already knows how to automatically create both > seaside and morphic forms out of a field description. It also > knows more ways to look up a field than just selector and block. > Anyway, it seems very interesting and I would like to learn a bit about Magritte even it is not possible to use it for preferences. As an example, could you explain how you specify the themePreference with Magritte ? Maybe it can help us to improve our implementation. Thanks alain

March 6, 2009

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

by Norbert Hartl

On Fri, 2009-03-06 at 05:20 -0500, Matthew Fulmer wrote: > On Fri, Mar 06, 2009 at 10:36:13AM +0100, Alain Plantec wrote: > > themePreference > > <preference> > > ^ ThemePreference > > ifNil: [ThemePreference := MultiplePreferenceValue > > name: 'UITheme' > > description: 'The theme to use for UI look and feel' > > parent: #uiPreferenceNode > > type: #UITheme > > default: UIThemeWatery2 > > values: { > > FixedPreferenceValue > > name: 'Standard Squeak' > > description: 'Standard Squeak style' > > type: #UITheme > > > > value: UIThemeStandardSqueak. > > FixedPreferenceValue > > name: 'Watery 2' > > description: 'Similar to a nice OS' > > type: #UITheme > > value: UIThemeWatery2}] > > You're really just inventing a half-baked Magritte now. Do > yourself a favor and use the real thing. Magritte is far more > descriptive and far less verbose than anything you have yet > presented. Magritte also already knows how to automatically create both > seaside and morphic forms out of a field description. It also > knows more ways to look up a field than just selector and block. > I don't think so. This is a definition of composite value model. The value model does not need to reflect the structure of the objects that use those preferences. Magritte on the other side would describe the other model as it is a meta-model description. And Magritte is a lot more heavy weight. So while it looks similar I can't see what you are telling. But you could use Magritte to describe this model ad then generate a UI out of it ;) Norbert

March 6, 2009

[Pharo-project] Pushing Deltas (was Re: What about #ifNotNil and #ifNotNilDo:)

by GÃ¶ran Krampe

Hi all! Marcus Denker wrote: > On 22.02.2009, at 19:31, Marcus Denker wrote: > As soon as there are changesets that touch the same code, it starts to > get *very* messy. Which is one of the things that Deltas (in DeltaStreams) tries to deal better with. Let me explain quickly for those that do not know the idea: A Delta is "ChangeSet improved". It is an *ordered* list of changes instead of a Set. So ChangeList would be another good name. :) But that is not all it is, it also: - Models each kind of change using a unique class in much finer detail. Like "AddInstVarChange" for example. This creates the potential to be much "smarter". - Each change captures the "before state". This is very important - it doesn't only hold the "new method" but also the old one. (a diff could of course also work, that is just implementation details) - A Delta can be loaded into the image *before* it is installed. Thus you can operate on a Delta and analyse it before applying it. This is VERY important. - A Delta is *fully self contained*. It does not just "point to a method" like ChangeSet does. Thus, no matter how much the image changes - the Delta is totally isolated and totally independent of the image. - It can also be unapplied. Now... one use case that I wanted to be able to do with Deltas is to be able to load 100s of Deltas into an image (remember - they are not *installed* when only being loaded) and then *analyse* them in tons of ways like for example: - Can they be "cleanly applied"? One definition of "clean" is that the "before state" matches the image. - Can they be "dirtily" applied? One definition of "dirty" is that the before state does NOT match, but we can still apply it. Given say a Delta with a single method change - and the whole class is missing - then we can't apply it at all. But if the class exists - but with a DIFFERENT version of the method than the captured "before state" - we can apply, although possibly overwriting other changes. Since Deltas can be applied and unapplied we can start playing with "patch queues" like Mercurial and other systems have. So let's say you load 42 Deltas from some strange places - perhaps totally independent of each other. You look at them, the tool tells you that well, 37 can be cleanly applied "one by one" and 2 can be dirtily applied, and 3 are dead ducks. Ok, so you tell the tool to fine, group them by developer and sort them chronologically and analyze them in groups one by one. Then it might say that, sure first 2 groups from Marcus comprising 23 Deltas would apply fine - then it get's stuck on one of the dead ducks in group 2 from Andreas :). So you feel brave and tell the tool to fine - apply those first 2 groups of 23 (in total) so we can run tests being touched by those 23. The tool should be able to figure out a reasonable Set of tests that are affected given classes being modified and referenced by tests. Perhaps some tests turn red, so you tell the tool to unapply Deltas *one by one* (until the tests are green again, perhaps it ends up with 17 applied but the 18th caused the problem. It could even do a binary search. :) The dead ducks may be because of class renames. Tool could again try to find the right class for you. I am blabbering, but as you can see having working Deltas could enable a whole *range* of interesting tools that can operate *regardless* of history. Just writing about it makes me want to pick it up again where we left off. And no, this is not purely hype-code - a lot of stuff actually works today, including unapply. regards, GÃ¶ran

March 6, 2009

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

by Matthew Fulmer

On Fri, Mar 06, 2009 at 10:36:13AM +0100, Alain Plantec wrote: > themePreference > <preference> > ^ ThemePreference > ifNil: [ThemePreference := MultiplePreferenceValue > name: 'UITheme' > description: 'The theme to use for UI look and feel' > parent: #uiPreferenceNode > type: #UITheme > default: UIThemeWatery2 > values: { > FixedPreferenceValue > name: 'Standard Squeak' > description: 'Standard Squeak style' > type: #UITheme > > value: UIThemeStandardSqueak. > FixedPreferenceValue > name: 'Watery 2' > description: 'Similar to a nice OS' > type: #UITheme > value: UIThemeWatery2}] You're really just inventing a half-baked Magritte now. Do yourself a favor and use the real thing. Magritte is far more descriptive and far less verbose than anything you have yet presented. Magritte also already knows how to automatically create both seaside and morphic forms out of a field description. It also knows more ways to look up a field than just selector and block. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

March 6, 2009

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

by Alain Plantec

and here is my answer. Cheers Alain

March 6, 2009

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

by Alain Plantec

Here is a comments of Andreas. He compares our two different approaches Cheers Alain

March 6, 2009

Re: [Pharo-project] can't load seaside 2.9a2

by Damien Cassou

On Thu, Mar 5, 2009 at 8:37 PM, MichaelA <michael_atkisson(a)comcast.net> wrote: > I apoligize if this has been answered before. Â I have the latest > core. Â I am trying to load Seaside. Which version? The experimental 2.9 or the stable 2.8? You should try: ScriptLoader loadSeaside "for 2.8" ScriptLoader loadSeaside29 "for 2.9" -- Damien Cassou http://damiencassou.seasidehosting.st

March 6, 2009