- Pharo-dev - lists.pharo.org

Re: [Pharo-project] gettext package

by Philippe Marschall

On 05/06/2010 04:55 PM, Hilaire Fernandes wrote: > 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'. That's exactly what I need. > 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? I have two train rides this weekend. I'll see if I can hack something up. Cheers Philippe

May 7, 2010

Re: [Pharo-project] another fun case for Linked>>add:

by Henrik Johansen

On May 7, 2010, at 3:08 33PM, Henrik Johansen wrote: > Yes, this was somehting Nico Schwartz and I did during the sprint. > > He had the idea that it would be nice to be able to add any object to a LinkedList, instead of just Link subclasses. (IIRC, 'like you can in Ruby' ;)) > > So we added ValueLink as the common pattern for "A link with an object in it", which is now the default if you add an object which itself is not a link. > > Makes it much more convenient to actually use a LinkedList, ref. f.ex. the Stack implementation. > > Sort of similar to what was done in Squeak to add nils to sets, actually. > > Cheers, > Henry Which of course makes it all the more important that it actually returns aLink, rather than aLinkOrObject. Cheers, Henry > > > On May 6, 2010, at 9:25 52AM, StÃ©phane Ducasse wrote: > >> LinkedList>>add: aLinkOrObject >> "Add aLink to the end of the receiver's list. Answer aLink." >> >> ^self addLast: aLinkOrObject >> >> LinkedList>>addLast: aLinkOrObject >> "Add aLink to the end of the receiver's list. Answer aLink." >> |aLink| >> aLink := aLinkOrObject asLink. >> self isEmpty >> ifTrue: [firstLink := aLink] >> ifFalse: [lastLink nextLink: aLink]. >> lastLink := aLink. >> ^aLink >> >> Object>>asLink >> "Answer a string that represents the receiver." >> >> ^ ValueLink value: self >> >> >> In squeak there is no such asLink.... >> We need a database with all the history to know which change introduced this change. >> Henrik do you remember why you introduce this change? >> >> Stef >> >> >> >> >> >> _______________________________________________ >> 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 >

May 7, 2010

Re: [Pharo-project] another fun case for Linked>>add:

by Henrik Johansen

Yes, this was somehting Nico Schwartz and I did during the sprint. He had the idea that it would be nice to be able to add any object to a LinkedList, instead of just Link subclasses. (IIRC, 'like you can in Ruby' ;)) So we added ValueLink as the common pattern for "A link with an object in it", which is now the default if you add an object which itself is not a link. Makes it much more convenient to actually use a LinkedList, ref. f.ex. the Stack implementation. Sort of similar to what was done in Squeak to add nils to sets, actually. Cheers, Henry On May 6, 2010, at 9:25 52AM, StÃ©phane Ducasse wrote: > LinkedList>>add: aLinkOrObject > "Add aLink to the end of the receiver's list. Answer aLink." > > ^self addLast: aLinkOrObject > > LinkedList>>addLast: aLinkOrObject > "Add aLink to the end of the receiver's list. Answer aLink." > |aLink| > aLink := aLinkOrObject asLink. > self isEmpty > ifTrue: [firstLink := aLink] > ifFalse: [lastLink nextLink: aLink]. > lastLink := aLink. > ^aLink > > Object>>asLink > "Answer a string that represents the receiver." > > ^ ValueLink value: self > > > In squeak there is no such asLink.... > We need a database with all the history to know which change introduced this change. > Henrik do you remember why you introduce this change? > > Stef > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 7, 2010

Re: [Pharo-project] Help System

by laurent laffont

On Fri, May 7, 2010 at 1:25 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > >In addition to the story around tests, > > Could you be a little bit more specific what your wishes are > for using tests within the help documentation? > It's still not clear to me what you expect here. > Hi Torsten, IIRC this idea came from a discussion I had with Stef. There's some tests that show "how" to use the class it tests, that can make a good documentation for free. For example (may not be the best): XMLParserTest>>testParsing | xmlDocument root firstPerson numberOfPersons | xmlDocument := XMLDOMParser parseDocumentFrom: self addressBookXML readStream. self assert: (xmlDocument isKindOf: XMLDocument). root := xmlDocument root. self assert: (root class == XMLElement). "the tag has to be a symbol!" self assert: (root firstTagNamed: 'person') isNil. self assert: (root firstTagNamed: 'addressbook') isNil. self assert: (root firstTagNamed: #addressbook) == root. numberOfPersons := 0. root tagsNamed: #person do: [:p | numberOfPersons := numberOfPersons + 1]. self assert: numberOfPersons = 4. firstPerson := root firstTagNamed: #person. self assert: (firstPerson attributeAt: #'employee-number') = 'A0000'. self assert: (firstPerson attributeAt: #'family-name') = 'Gates'. self assert: (firstPerson attributeAt: #'first-name') = 'Bob'. Just reading it you know how to use XMLDOMParser. We don't need to add comments to understand it. So the idea is to tag this test to tell that we can learn from it. Then HelpSystem can built the documentation of XML-Parser package just by collecting the tests. Laurent Laffont > > >Torsten do you think we could use book.pharo-project.org to populate the > help? > > Dont know how the pier books are implemented. > Is it possible to access/parse the contents either on > the server or directly online from a client image? > > If so then yes, as the following example demonstrates: > > > |topic day url sub| > topic := HelpTopic named: 'Last week on Squeak IRC'. > 0 to: 7 do: [:index | > day := (Date today subtractDays: index) printFormat: #(3 2 1 $. 1 2 > 2). > url := 'http://tunes.org/~nef/logs/squeak/' , day. > sub := HelpTopic > title: day contents: (HTTPLoader default > retrieveContentsFor: url) contents. > topic addSubtopic: sub. > ]. > HelpBrowser openOn: topic > > > Bye > T. > > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 7, 2010

Re: [Pharo-project] Help System

by Lukas Renggli

>>Torsten do you think we could use book.pharo-project.org to populate the help? > > Dont know how the pier books are implemented. > Is it possible to access/parse the contents either on > the server or directly online from a client image? You can download the wiki or plain text of any Pier site like this: http://book.seaside.st/book/foreword?view=Wiki http://book.seaside.st/book/foreword?view=Text Lukas -- Lukas Renggli www.lukas-renggli.ch

May 7, 2010

Re: [Pharo-project] bug in the code of CompiledMethod >> =

by Mariano Martinez Peck

Hi. I am using Moose (an image that Cyrille Delaunay gave me) and I am having this problem. Is there a ticket for this ? I don't see analogousCodeTo: in PharoCore-1.1-11336-UNSTABLE should we integrate the fix ? Thanks Mariano On Tue, Mar 23, 2010 at 12:55 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2010/3/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > >> On Mon, Mar 22, 2010 at 2:54 PM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> You might also want to check last code published in trunk. > >> > >> I saw that. You're eliminating closeTo: for float comparison which > seems fine to me :) Thanks Nicolas! > >> However, it is indicative that a recompile all is necessary after > redefining the number scanning facilities. I guess that this is part of the > standard release build process. If not, we should add it. > > > > > > I saw the following but I could not see the float issue you mentioned. > Where it is? > > > > It's in CompiledMethod >> #= > > Note that Pharo has implemented different workaround for handling > cases like (Float class>#nan) = (Float class>#nan) copy, but these > are fragile. > trunk implementation rely on (lit1 == lit2) to handle this case. > > Nicolas > > > > > analogousCodeTo: aMethodProperties > > | bs | > > (aMethodProperties isKindOf: MethodProperties) ifTrue: > [^aMethodProperties analogousCodeTo: self]. > > (bs := self basicSize) ~= aMethodProperties basicSize ifTrue: > > [^false]. > > 1 to: bs do: > > [:i| > > ((self basicAt: i) analogousCodeTo: (aMethodProperties > basicAt: i)) ifFalse: > > [^false]]. > > ^true > > > > hasAtLeastTheSamePropertiesAs: aMethodProperties > > "Answer if the recever has at least the same properties as the > argument. > > N.B. The receiver may have additional properties and still answer > true." > > aMethodProperties keysAndValuesDo: > > [:k :v| > > (v isKindOf: Pragma) > > "ifTrue: [Pragmas have already been checked]" > > ifFalse: [ > > (self includes: k->v) ifFalse: [^false]]]. > > ^true > > > > > > > > > > On Mar 22, 2010, at 10:54 PM, Nicolas Cellier wrote: > > > >> You might also want to check last code published in trunk. > >> > >> Nicolas > >> > >> 2010/3/22 Eliot Miranda <eliot.miranda(a)gmail.com>: > >>> > >>> > >>> On Mon, Mar 22, 2010 at 2:25 PM, StÃ©phane Ducasse > >>> <stephane.ducasse(a)inria.fr> wrote: > >>>> > >>>> eliot > >>>> > >>>> Your changes fixed some of the problems. Now I tried to fix the test > >>>> testAnalogousCodeTo in MethodPropertiesTest and > >>>> the expression returns false. > >>>> > >>>> (#zork->'hello') analogousCodeTo: (#zork->'hello') -> false > >>>> > >>>> (#zork->'hello') = (#zork->'hello') -> true > >>> > >>> For me > >>> #(#zork -> 'hello') size 3 > >>> In Pharo is it true that > >>> #(#zork -> 'hello') size 1 > >>> ??!?! > >>> In that case I would implement analogousCodeTo: in Association, e.g. > >>> analogousCodeTo: anObject > >>> ^anObject class == self class > >>> and: [key = anObject key > >>> and: [value = anObject value]] > >>> > >>> But if Association isn't a literal I would simply check > >>> MethodPropertiesTests. It could be obsolete. > >>>> > >>>> Stef > >>>> > >>>> On Mar 22, 2010, at 6:20 PM, Eliot Miranda wrote: > >>>> > >>>>> Oops. Find attached. > >>>>> > >>>>> 2010/3/22 Cyrille Delaunay <cy.delaunay(a)gmail.com> > >>>>> try in a Pharo-1.0-10515-rc3 image : > >>>>> > >>>>> |set| > >>>>> set := Set new. > >>>>> Collection withAllSubclasses do: [:aClass | > >>>>> set addAll: aClass methods > >>>>> ]. > >>>>> > >>>>> It will raise an exception telling: "MessageNotUnderstood: > >>>>> ByteSymbol>>analogousCodeTo:". > >>>>> Indeed, in the code of CompiledMethod >> = , the message > >>>>> 'analogousCodeTo:' is send to a > >>>>> symbol. > >>>>> > >>>>> > >>>>> I opened an Issue: > >>>>> http://code.google.com/p/pharo/issues/detail?id=2185 > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Pharo-project mailing list > >>>>> Pharo-project(a)lists.gforge.inria.fr > >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>>>> > >>>>> > >>>>> > <Object-analogousCodeTo.st>_______________________________________________ > >>>>> 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 > >>> > >> > >> _______________________________________________ > >> 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 >

May 7, 2010

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

by Andreas Raab

On 5/6/2010 5:26 PM, Dale Henrichs wrote: > I don't think I've completely answered your questions so we might want to continue the dialog on this question.... We're getting close :-) Let me take my own questions and answer them in my own words to see if I understand the issues correctly: Q1: #includes: vs. #requires: If I understand correctly what you're saying then, in heavily simplified form, I'd say they're both dependencies, except that #requires: is loaded before the package it relates to and #includes: afterwords. Thus: spec package: 'B' with:[ spec requires: 'A'. spec includes: 'C'. ]. will load A, B, and C in that order. One thing one can do with this is to have mutually dependent packages, for example if package Foo and Bar always must be loaded together (Foo before Bar) one would specify: spec package: 'Foo' with:[spec includes: 'Bar']. spec package: 'Bar' with:[spec requires: 'Foo']. There is now no way by which Foo or Bar could be loaded without its companion. Correct? Q2: Why is HelpSystem not loaded? A: That's a bug which I can work around by specifying either #version: or #versionString:. Q3: When exactly is HelpSystem loaded? A: In the context of my configuration HelpSystem is loaded for two reasons: a) because it's a dependency for WebClient-Help and b) because no 'default' group has been specified it would be loaded implicitly. Q4: How does one define dependencies that differ based on platform? A: I'm not really sure about this. My understanding is that I could use #includes: to model the dependency in the "for: #pharo" branch, but one question that is still open is whether the following two expressions are equivalent: spec package:'Foo' with:[spec requires: 'Bar']; package:'Foo' with:[spec requires: 'Baz']; and spec package: 'Foo' with:[spec requires: #('Bar' 'Baz')]. Are these equivalent? Cheers, - Andreas

May 7, 2010

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

by Dale Henrichs

----- "Andreas.Raab" <andreas.raab(a)gmail.com> wrote: | 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? Andreas, Here's the Transcript from a (successful) load of WebClient: Loading 1.0 of ConfigurationOfWebClient... Fetched -> ConfigurationOfHelpSystem-tbn.12 Loaded -> ConfigurationOfHelpSystem-tbn.12 Fetched -> WebClient-Core-ar.15 Fetched -> WebClient-Tests-ar.7 Fetched -> WebClient-HTTP-ar.1 Project: HelpSystem Fetched -> HelpSystem-Core-tbn.40 Fetched -> HelpSystem-Tests-tbn.9 Fetched -> Pharo-Project-Help-tbn.8 Fetched -> WebClient-Help-ar.4 Fetched -> WebClient-Pharo-ar.1 Starting atomic load Loaded -> WebClient-Core-ar.15 Loaded -> WebClient-Tests-ar.7 Loaded -> WebClient-HTTP-ar.1 Finished atomic load Loaded -> HelpSystem-Core-tbn.40 Loaded -> HelpSystem-Tests-tbn.9 Loaded -> Pharo-Project-Help-tbn.8 Starting atomic load Loaded -> WebClient-Help-ar.4 Loaded -> WebClient-Pharo-ar.1 Finished atomic load Evaluated -> 1.1 [ConfigurationOfHelpSystem] >> openHelpBrowser In your configuration you had specified that WebClient-Help required the Help System, so you can see that the load of the Help System was inserted at that point in the load (which is what triggered the bug, too). The order of specifying packages/projects implies the order that things will be loaded in. With #requires:, the load order is explicit. I would recommend that you explicitly use #requires: unless only one or two packages are involved. The implicit load order is not obvious when you introduce conditional loading (with #squeakCommon #squeak, and #pharo), so if load order matters I would explicitly declare the relationships. The other aspect besides load order is what you want loaded. By default all packages/projects are loaded, but you can define a 'default' group which would be used to specify a subset of the packages/projects that are loaded by default. This is useful if you want to control whether or not a set of packages (say tests) are loaded or not ... I don't think I've completely answered your questions so we might want to continue the dialog on this question.... Dale

May 7, 2010

Re: [Pharo-project] Metacello questions

by Dale Henrichs

Andreas, You have bumped into a bug in Metacello 1.0-beta.26. I discovered the bug a couple of weeks ago while using Metacello in GLASS so the bug is fixed in Metacello 1.0-beta.26.1. 1.0-beta.26.1 is under development (#development blessing) so is not loaded by #latestVersion. I am a couple of days away from releasing 1.0-beta.26.1 but if you want to try it out, you can explicitly load 1.0-beta.26.1 with this expression: (ConfigurationOfMetacello project version: '1.0-beta.26.1') load The bug was triggered because ConfigurationOfWebClient uses an #atomic load and ConfigurationOfHelpBrowser uses #linear loads ... the help browser packages were missed in the transition. The default configuration template sets the loadType to #linear, so you hit this specifically because you didn't use the template, which relates to your other questions so I'll answer them in another letter. Dale ----- "Andreas Raab" <andreas.raab(a)gmx.de> wrote: | On 5/6/2010 10:29 AM, Dale wrote: | > The documentation is correct and your understanding is correct ... | at the | > moment I'm not exactly sure why the Help System is not loaded in | your case | > ... if you could share your complete config, what version of Squeak | you are | > working with and the expression you use to load (privately if you | want), I | > might be able to figure out the answer to your question... | | Tried both on Squeak 4.1 and Pharo 1.0 with the same results. Here is | | the script for Squeak: | | (Installer repository: 'http://seaside.gemstone.com/ss/metacello) | install: 'ConfigurationOfMetacello'. | (Smalltalk at: #ConfigurationOfMetacello) project latestVersion load. | | (Installer repository: | 'http://www.squeaksource.com/MetacelloRepository) | install: 'ConfigurationOfWebClient'. | (Smalltalk at: #ConfigurationOfWebClient) project latestVersion load. | | | Again, the strange thing is that it 'fetches' the right files but | doesn't load them. | | Cheers, | - Andreas

May 6, 2010

[Pharo-project] Help System

by Torsten Bergmann

>In addition to the story around tests, Could you be a little bit more specific what your wishes are for using tests within the help documentation? It's still not clear to me what you expect here. >Torsten do you think we could use book.pharo-project.org to populate the help? Dont know how the pier books are implemented. Is it possible to access/parse the contents either on the server or directly online from a client image? If so then yes, as the following example demonstrates: |topic day url sub| topic := HelpTopic named: 'Last week on Squeak IRC'. 0 to: 7 do: [:index | day := (Date today subtractDays: index) printFormat: #(3 2 1 $. 1 2 2). url := 'http://tunes.org/~nef/logs/squeak/' , day. sub := HelpTopic title: day contents: (HTTPLoader default retrieveContentsFor: url) contents. topic addSubtopic: sub. ]. HelpBrowser openOn: topic Bye T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

May 6, 2010