- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] OB

by CÃ©drick BÃ©ler

yes confirmed (nb I like having buttons there). Cheers, 2009/3/6 Alexandre Bergel <Alexandre.Bergel(a)inria.fr>: > Hi David, > > it seems that your last improvement of OB (especially the one defining > the width of the mercury input field) does not work properly. The > input field is above the buttons. > > 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 > -- CÃ©drick

March 6, 2009

[Pharo-project] Fwd: [squeak-dev] An old gripe (or: SystemChangeNotifier + Announcements = Sanity?)

by CÃ©drick BÃ©ler

another change in the air ;) http://www.nabble.com/-squeak-dev--An-old-gripe-(or%3A-SystemChangeNotifier… ---------- Forwarded message ---------- From: Andreas Raab <andreas.raab(a)gmx.de> Date: 2009/3/6 Subject: [squeak-dev] An old gripe (or: SystemChangeNotifier + Announcements = Sanity?) To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> Folks - While doing some preferences stuff I ran into one of my "most-hated" issues in Squeak. Anyone who has ever encountered SystemChangeNotifier must have noticed how terrible it is to use it. I mean, just look at this code: prefEvent: anEvent Â Â Â Â "Check if this system event defines or removes a preference." Â Â Â Â (anEvent itemKind = SystemChangeNotifier classKind and: [anEvent isRemoved]) ifTrue:[...]. Â Â Â Â anEvent itemKind = SystemChangeNotifier methodKind ifTrue:[ Â Â Â Â Â Â Â Â (anEvent isRemoved or:[anEvent isModified]) ifTrue:[...] Â Â Â Â Â Â Â Â (anEvent isAdded or:[anEvent isModified]) ifTrue:[...] Â Â Â Â ]. just needless, pointless lines of case statements. How do people feel about replacing that mess with Announcements? If you really want to have all events you register for SystemEvent and if you'd like to be more specific you go for more specifically for ClassEvent or even more specifically for ClassAddedEvent. It would also remove the need for all of these weird tests like Â Â Â Â anEvent itemKind = SystemChangeNotifier methodKind and:[anEvent isRemoved] and just replace them with something like "anEvent isMethodRemoval". It would likely be faster too, since most places aren't really interested in *all* events either. It would mean that Announcents would have to go core but this cleanup alone seems worth it. I also suspect that adding Announcements and fixing SystemChangeNotifier may remove more code than it would add. How do people feel about that? Cheers, Â - Andreas -- CÃ©drick

March 6, 2009

[Pharo-project] OB

by Alexandre Bergel

Hi David, it seems that your last improvement of OB (especially the one defining the width of the mercury input field) does not work properly. The input field is above the buttons. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 6, 2009