- Pharo-dev - lists.pharo.org

[Pharo-project] Fwd: [squeak-dev] Re: Metacello questions

by Dale Henrichs

May 6, 2010

Re: [Pharo-project] [Metacello] Fwd: Metacello questions

by Dale Henrichs

I've replied to question 1) in the Squeak-dev list (http://forum.world.st/Metacello-questions-tt2132073.html#a2133038) but will finish/continue the discussion on the Metacello list (http://forum.world.st/Fwd-Metacello-questions-tt2132927.html#a2132927) Dale ----- "Andreas.Raab" <andreas.raab(a)gmail.com> wrote: | [forwarded from Squeak-dev] | | Hi - | | I've been trying to wet my feet with Metacello a little by writing a | ConfigurationOfWebClient and in the process I've come across various | things that I don't understand or don't know how to express. The | configuration itself can be found here: | | http://www.squeaksource.com/MetacelloRepository | | Here are the questions I'm having: | | 1) #includes: vs. #requires: | What is the difference between #includes: and #requires:? They sound | entirely interchangeable, in particular after reading the tutorial | which | states: | | "When you use the #includes: directive, you are not only specifying | that the listed packages should be loaded when the parent package is | loaded, but that the #included: packages should be loaded _before_ | any | packages that require the parent package." | | I would expect that precise behavior for required packages, i.e., if | Foo | requires: Bar then Bar is loaded before Foo if some other package | requires: Foo. What am I missing? | | 2) Why is HelpSystem not loaded? | In my configuration, baseline specifies that HelpSystem is required | for | WebClient-Help: | | "Documentation doesn't require Core/Tests, but HelpSystem" | spec package: 'WebClient-Help' with:[spec requires: 'HelpSystem']. | | spec project: 'HelpSystem' with:[ | spec | className: 'ConfigurationOfHelpSystem'; | repository: 'http://www.squeaksource.com/MetacelloRepository' | ]. | | However, when executed, Metacello goes through the motions but | doesn't | actually *load* any version of HelpSystem (I can see it 'fetch' the | packages but not load them). It even calls the postLoadDoIt on it | (which | fails since nothing was loaded). What am I doing wrong? | | 3) When exactly is HelpSystem loaded? | | What I'm wondering about in the above is that HelpSystem should only | be | loaded if WebClient-Help is being loaded. Is this implicitly part of | specifying a 'project' instead of a 'package'? Or is there some other | way of specifying that? | | I guess really the question here is what entities get loaded | implicitly | simply by declaring them (packages for sure, any others?) and what | entities need to be 'required' in order to be loaded? | | 4) How does one define dependencies that differ based on platform? | | In WebClient, the WebClient-HTTP package requires WebClient-Core and | -only for: #pharo- also WebClient-Pharo. How does one express that | there's an additional dependency for WebClient-HTTP that only exists | for: #pharo? The config currently specifies: | | spec for: #common do:[ | " ... " | spec package: 'WebClient-HTTP' with:[spec requires: | 'WebClient-Core']. | " ... " | ]. | | spec for: #pharo do:[ | "Just the fact it exists; no requirements here" | spec package: 'WebClient-Pharo'. | ]. | | Which means that WebClient-Pharo will be loaded on Pharo by default | but | it's missing the fact that WebClient-Pharo is in fact a requirement | for | WebClient-HTTP (but only on that platform). How is that best | expressed? | | 5) Bootstrapping Metacello? | | I found that most of the ConfigurationsOfXXX include some code to | 'bootstrap' Metacello in some form. There appear to be variants on | the | code; is there a "canonical bootstrap method" that should be used? | | 6) A standard Configuration template? | | The Metacello tutorial is very useful as far as the configuration | goes | but it falls short of getting into the details of what it means to | provide a 'working' configuration. Testing the configuration isn't | covered (is there a way to get back to a 'clean' state?); | bootstrapping | isn't covered; the meaning of #isMetacelloConfig, | #metacelloVesion:loads:, #lastMetacelloVersionLoad and several other | -seemingly random- methods that can be found on most -but not all- of | the configurations. There is no indication on what these do, if | they're | required, recommended, or optional. Is there some 'standard' | Configuration template that people can use to avoid guessing about | which | parts of the boilerplate to copy from some other configuration? | | That's it for now. Thanks for any insights on any of these issues. | | Cheers, | - Andreas

May 6, 2010

[Pharo-project] Metacello questions

by Torsten Bergmann

>Does that mean the documentation is just wrong then? I would see/interpret it like this: With the baseline you describe a set of packages (structure/dependencies) that form your app/project (MyApp). Beside the usual loading of a version: (ConfigurationOfMyApp project version: '1.0') load it is possible to load also a baseline - this would load all the latest Monticello package versions of any package described in this baseline: (ConfigurationOfMyApp project version: '1.0-baseline') load Note that in the baseline you dont say anything about the Monticello package version to use/load. In a baseline you can also define a dependency on another project (that provides a config too, for instance ConfigurationOfMyFoo). Now you have two options: a) dont say anything about the version of "ConfigurationOfMyFoo" in the baseline => this should load the latest version of Foo's Metacello configuration then, so you get the latest version of "Foo" when loading the baseline of MyApp b) you note/give a default version for "ConfigurationOfMyFoo" in the baseline => then this specific version of "Foo" is loaded when you load the baseline for MyApp. I think you can override the version specified in the baseline in a #versionXXX of MyApp if required Loading baselines is usefull if you work in a team. If you work on the same baseline you can just load it to be up to date with the latest commits of the other team members. If your dependencies, load order, set of packages/pre-projects change then you typically create a new baseline. But it is more often the case that you just create new versions based on a baseline. In a versionXXX you pin/mark the Metacello version of all packages/projects version that fit/work together to form this version. Maybe Dale is able to correct me if I'm wrong. Thanks Torsten -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

May 6, 2010

[Pharo-project] Getting Shout in Pharo 1.1

by Alexandre Bergel

Hi Andy, Little needs to be done to have a preliminary version of Pharo 1.1. One of remaining things is the method SHWorkspace class >> initialize which uses the former registration mechanism. Would it be possible to replace this method by: initialize ((TheWorldMenu respondsTo: #registerOpenCommand:) and: [((TheWorldMenu class >>#registerOpenCommand:) sendsSelector: #deprecated:) not]) ifTrue: [TheWorldMenu registerOpenCommand: {'Shout Workspace'. {self. #open}}] and add: menuCommandOn: aBuilder <worldMenu> (aBuilder item: #'SH Workspace') parent: #Tools; action:[ self new open ]; icon: self taskbarIcon. I guess this change are squeak compatible. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 6, 2010

[Pharo-project] [ENH] Added CompiledMethod>>isDeprecated

by Alexandre Bergel

SLICE-DeprecationTestMethod-Alexandre_Bergel.1 is in the inbox. It simply add a isDeprecated test method on CompiledMethod. A test has been added to CompiledMethodTest. http://code.google.com/p/pharo/issues/detail?id=2390 It would be great to have this slice in the image. I am working to produce Pharo 1.1. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 6, 2010

Re: [Pharo-project] Set + collect:

by GermÃ¡n Leiva

2010/5/3 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > Hi, this is my first post (please be gentle xD) > > Thanks! > > xD > > > > The #collect: message commonly return a new collection like the receiver, > but this is really unpractical in some cases > > > > e.g. > > col := Set with: 'one'->1 with: 'two'->2 with: 'dos'->2. > > (col collect: [:each | each value ]) sum > > In VW you get the same. > > Yes > In this example #sum will return 3 instead of 5 (I searched a test for > #sum but I didnÂ´t find it). > > > > Ok, I can use the message #asBag (or something like that) but does the > second line have to depend on the type of the receiver (i.e. the type of > col)? > > I think that this is the invariant for collect: ? > > I didnÂ´t understand that. I'll like that this line (col collect: [:each | each value ]) sum always returns 5 independently of the class of col (if col has the elements 'one'->1 , 'two'->2 and 'dos'->2). > For example, the implementation of #collect: in SortedCollection returns > an OrderedCollection (in the current image) > > in VW too > > Yes, I like that. I just put the example to show that* #collect:* not always returns a new collection like the receiver. > and in other dialects the message #collect: when the receiver is a Set > returns a Bag ... > > which ones? > > In IBM VisualAge 6.0 returns a Bag (in Instantiations VA 7.5.2 returns a Set). > Basically, what do you think of an implementation like this? > > > > Set >> collect: aBlock > > "Evaluate aBlock with each of the receiver's elements as the argument. > > Collect the resulting values into a Bag. Answer the new collection." > > | newBag | > > newBag := Bag new: self size. > > array do: [:each | each ifNotNil: [newBag add: (aBlock value: each)]]. > > ^ newBag > 2010/5/4 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > True.It can be impractical, but no need to change #collect: > Please use #detectSum: > > (Set with: 'one'->1 with: 'two'->2 with: 'dos'->2) detectSum: [:e |e > value]. > or #collect:as: > > ((Set with: 'one'->1 with: 'two'->2 with: 'dos'->2) collect: [:e |e > value] as: Array) sum. > > Nicolas Nice =) I didn't know those messages (although IMHO the name #detectSum: is not pretty - I'm thinking aloud here ... *#acummulateSum:* or: directly * #sum:* ...?) The reason I'm proposing to change the *Set >> #collect:* implementation is because the only situtation when you need that *#collect:* returns a Set is when you didn't want duplications and for that is really nice to explicity send the message asSet. In all other cases a Bag is all you need as response to collect (when collect is sended to a Set). If you say this is counterproductive and the change will generate more headaches than happiness I understand xD Cheers, > > 2010/5/3 GermÃ¡n Leiva <leivagerman(a)gmail.com>: > > Hi, this is my first post (please be gentle xD) > > > > The #collect: message commonly return a new collection like the receiver, > > but this is really unpractical in some cases > > e.g. > > col := Set with: 'one'->1 with: 'two'->2 with: 'dos'->2. > > (col collect: [:each | each value ]) sum > > In this example #sum will return 3 instead of 5 (I searched a test for > #sum > > but I didnÂ´t find it). > > > > Ok, I can use the message #asBag (or something like that) but does the > > second line have to depend on the type of the receiver (i.e. the type of > > col)? > > For example, the implementation of #collect: in SortedCollection returns > an > > OrderedCollection (in the current image) and in other dialects the > message > > #collect: when the receiver is a Set returns a Bag ... > > > > Basically, what do you think of an implementation like this? > > > > Set >> collect: aBlock > > "Evaluate aBlock with each of the receiver's elements as the argument. > > Collect the resulting values into a Bag. Answer the new collection." > > | newBag | > > newBag := Bag new: self size. > > array do: [:each | each ifNotNil: [newBag add: (aBlock value: each)]]. > > ^ newBag > > Cordially, > > -- > > GermÃ¡n Leiva > > LeivaGerman(a)gmail.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 > -- GermÃ¡n Leiva LeivaGerman(a)gmail.com

May 6, 2010

Re: [Pharo-project] Metacello questions

by Andreas Raab

On 5/5/2010 11:36 PM, Torsten Bergmann wrote: > Just have a look at ConfigurationOfSQLite3 for a simple > example. This one has a "project dependency" on ConfigurationOfFFI. > > If you want Help system project to be loaded in your configurartion > you need to define it in the baselineXXX method and set a specific > version of the project in your own #versionXXX method Thanks. Does that mean the documentation is just wrong then? It says MetacelloReferenceConfig>>baseline10: "... snip ..." spec "Create or update a project reference" project: 'UI Support' with: [ "One or more of the following attributes may be defined or changed" spec "Name of config class (i.e., ConfigurationOfXXX)" className: 'ConfigurationOfUI'; "Version of project to be loaded. if theversionString is not specified, then the latest version of the project is used." versionString: '1.0'; This last comment made me assume that not providing a version would be enough to make Metacello load the latest version. Also, the reference config has no #version: anywhere related to the project dependency. Oh, and what's the difference between #version: (SQLite3) and #versionString: (MetacelloReferenceConfig)? Cheers, - Andreas

May 6, 2010

Re: [Pharo-project] gettext package

by Hilaire Fernandes

Philippe Marschall a Ã©crit : >>> The protocol I have in mind for Seaside is something like: >>> >>> html translate: >> aString translated "return the translating in the current locale." > > Nope sorry, in a server the current locale in the one of the request or > session, not a global variable. Seaside can figure this out Yes, it makes sense. So in some way you need to specify the locale to use for translation, and it was not how was intended String>>translated, so definitely not your friend. > automatically which is why I need some layer over gettext. But I also Right. > need a way to make the gettext exporter aware of this, basically looking > for more selectors. Yes, we should adapt the protocol to the need. I would like to clean it a and remove some classes as the NaturalLanguageEditor and InternalTranslator so we can simplify the whole package. > >>> html translate:to: >> >> NaturalLanguageTranslator >> translate: 'This point %1' >> toLocaleID: (LocaleID isoLanguage: 'fr') >> inDomain: 'DrGeoII' >> -> 'Ce point %1' >> 'DrGeoII' is the name of the catalog to look for the translation. > > Which would be the Seaside application name. This can be looked up > automatically without a need to repeat yourself every time you want to > have a string translated. Yes, it makes sense. > >> Wth this message you also avoid some overhead as your directly specify >> the translation catalog. The system does not need to figure out the >> catalog to search the translation (done by figuring out from which class >> - then class category - the String>>translated message was sent). >> >> >> Your register a domain from classes prefix: >> TextDomainManager registerCategoryPrefix: 'DrGeoII' domain: 'DrGeoII'. > > I would need to hock into that. So that a domain has a "scope" of only > several class categories and has a given value there. Is there a way to > do this? Yes, execute: TextDomainManager registerCategoryPrefix: 'Seaside-MyShop' domain: 'MyShop'. Then a new domain is created, at startup, the relevant .mo file are loaded (I guess, not sure how it is handled in detail). Is it what you were asking? >> Then you export the .po file for translation: >> GetTextExporter2 exportTemplate. >> >> Then you compile your .po translation as .mo and move it in >> locale/fr/LC_MESSAGES/DrGeo.mo >> >> >> Some documentation in the PBE2 could be written once stuff is stabilized. >> In the Etoys ml, Bert proposed to move the domain in the method >> properties to get a more efficient translation look-up >> >>> What would the way to hook into GetTextExporter(2) to make it pick >>> that up? This I really don't know. Hilaire

May 6, 2010

Re: [Pharo-project] customizing tab looks in watery2

by Richard Durr

Take a Look at: UITheme >> newTabGroupIn: aThemedMorph for: labelsAndControls On Thu, May 6, 2010 at 1:32 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi, > > I would like to change slightly the default Watery2 theme. For starters, I > would like to change the tab widget: > - to make it look like a group box > - use a smaller font > > However, I did not figure out how to do that. Could anyone point me in the > right direction? > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Problem solving efficiency grows with the abstractness level of problem > understanding." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 6, 2010

[Pharo-project] Settings Browser

by Geert Claes

I have to say that the new Settings Browser in 1.1 is a huge improvement over the old Preference Browser. It's just that I can't seem to figure out how to save the settings I have changed? I did noticed the "Style > New/Update/Load/Browse/Remove". I managed to create a new style, but when selecting "Style>Update" I get this tiny window titled "Choose" with a wee white box and a Cancel button? Am I missing something? ps. What is the "Blab email" in the Network section? -- View this message in context: http://forum.world.st/Settings-Browser-tp2132556p2132556.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 6, 2010