May 2010 - Pharo-dev - lists.pharo.org

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

[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