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

[Pharo-project] A question on the builder pattern

by Andreas Raab

Hi - Over the weekend I realized an interesting difference in the utilization of the builder pattern. It is related with how to create and interact with new entities created by the builder, and goes like this: Form a: In this form (which is utilized by ToolBuilder) a request for a new item creates an instance of the item which is then populated with the desired set of attributes, for example ^(builder pluggableListSpec new) model: tool; list: listSymbol; getIndex: selectionSymbol; setIndex: selectionSymbol asMutator; frame: currentFrame; yourself The expression "builder pluggableListSpec new" (or some variant like "builder newObject") creates an instance of the item, returns it, and then we set various properties on it. Form b: In this form (which is utilized for example by Metacello or by Pharo's Settings package) the builder generally returns *self* (it may return some other builder object but from what I've seen it never returns the actual entity created) from the request to create a new entity, and effectively "proxies" the follow-on requests, for example: (aBuilder pickOne: #displayDepth) label: 'Display depth' translated; parent: #appearance; target: #Display; getSelector: #depth; setSelector: #newDepth:; domainValues: self depthChoices; notInStyle. The expression "aBuilder pickOne: #displayDepth" returns another builder which then assembles the various attributes. The more canonical use of this form seems to be utilized via an implicit block scope in the construction request, like here: spec project: 'OB-Standard' with: [ spec className: 'ConfigurationOfOmniBrowser'; loads: #('OB-Standard' ); file: 'ConfigurationOfOmniBrowser'; repository: 'http://www.squeaksource.com/MetacelloRepository' ]. In this form the 'project' is created by the 'spec' (constructor) internally and then populated via the follow-on messages (#className:, #loads:, #file:, #repository) sent to the 'spec' and from there forwarded internally to the project under construction. [Btw, it's not entirely clear to me whether these two forms really represent the same idea or if we need to split them into "form b" using nested builders and cascades and "form c" operating on scoped blocks. In any case...] What I'm curious about is this: Which advantage does "form b" have over "form a"? Why would one choose it? Is it merely for convenience or are there other (practical or style) advantages? Cheers, - Andreas

May 4, 2010

Re: [Pharo-project] ConfigurationOfPharo and OmniBrowser

by Dale Henrichs

Okay I'll dig into this...thanks for confirming. Dale ----- "Alexandre Bergel" <alexandre(a)bergel.eu> wrote: | Apparently the bug remains. When I load the last version of | 'ConfigurationOfPharo project' in a fresh and updated Core 1.1, then | | OB-Standard.lr.442 is loaded and initialized. | | So, the problem persists :-) | Thanks Dale for offering your help. | | Cheers, | Alexandre | | | On 29 Apr 2010, at 14:08, Dale Henrichs wrote: | | > Mariano and Alexandre, | > | > Sorry for the late reply ... I've been off-line with a cold for the | | > last several days ... | > | > I have seen the behavior that you describe while working with GLASS | | > 1.0-beta.8 and have fixed the problem in Metacello 1.0-beta.26.1 ... | | > 1.0-beta.26.1 is still in development, but if you want to give it a | | > try, preload 1.0-beta.26.1 and rerun your test ... if the problem | > still persists, let me know and I will dive into it. | > | > Dale | > ----- "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote: | > | > | On Wed, Apr 28, 2010 at 11:28 PM, Alexandre Bergel < | > | alexandre.bergel(a)inria.fr> wrote: | > | | > | > It is a bit more subtle than that. | > | > | > | > If I take a Core 1.1, and doit: ConfigurationOfPharo project | > | lastVersion | > | > load | > | > Then I get a warning coming from OBSearchBrowser class related | to | > | the world | > | > menu registration. | > | > | > | > | > | Yes, I noticed that. | > | | > | | > | > At that moment, OmniBrowser-lr.458 and OB-Morphic-lr.112 are | > | loaded. | > | > | > | > Doing twice a proceed resume the loading. | > | > It then blocks on SHWorkspace, for the very same reason. | > | > | > | > | > | yes.. | > | | > | | > | > After having manually fixed the Nile problem (isInMemory), | Pharo | > | loads | > | > well. ProfStef is open. | > | > | > | > | > | I did the same... | > | | > | | > | > OmniBrowser-lr.469 and OB-Morphic-lr.116 are loaded. This means | > | that | > | > OmniBrowser is loaded twice. Is this the intended behavior? | > | > | > | > | > | I saw directly the final versions: 469 and 116. I didn't notice it | | > was | > | first | > | trying to load 458 and 112. | > | I know that in such conflict, Metacello will load the last one, | > but I | > | didnt | > | know that it actually LOADS also the previous versions. I thought | | > that | > | it | > | only loads the final version, not both of them. In such case, I | > think | > | it is | > | a metacello bug. | > | | > | See this link: | > | | http://groups.google.com/group/metacello/browse_thread/thread/e8a08b3ed1a9b… | > | | > | Dale, can you help us? | > | | > | Thanks | > | | > | Mariano | > | | > | > Alexandre | > | > | > | > | > | > | > | > On 28 Apr 2010, at 11:40, Mariano Martinez Peck wrote: | > | > | > | > | > | >> | > | >> On Wed, Apr 28, 2010 at 3:22 PM, Alexandre Bergel | > | <alexandre(a)bergel.eu> | > | >> wrote: | > | >> Hi! | > | >> | > | >> I am now trying to make ConfigurationOfPharo load the last | > version | > | of | > | >> OmniBrowser. | > | >> If I do in a fresh core: ConfigurationOfPharo project | lastVersion | > | load | > | >> | > | >> Then OmniBrowser-lr.458 and OB-Morphic-lr.112 are loaded. | > | >> | > | >> | > | >> No. If you take a PharoCore 1.0 OR 1.1 and evaluate | > | ConfigurationOfPharo | > | >> project lastVersion load | > | >> | > | >> It installs OmniBrowser-lr.469 and OB-Morphic-lr.116 | > | >> which are correct as those are defined in | > | ConfigurationOfOmniBrowser | > | >> version 1.1.2. And ConfigurationOfPharo 1.1 has 1.1.2 of OB. | > | >> | > | >> | > | >> The loading blocks on the deprecated warning (yes, the | > registration | > | in the | > | >> World menu). | > | >> In ConfigurationOfPharo>>version11: I have | > | >> | > | >> spec | > | >> project: 'PharoNonCorePackages' | > | with: | > | >> '1.1.0'; | > | >> project: 'NewInspector' with: | > '1.1'; | > | >> project: 'Shout' with: '1.0'; | > | >> project: 'Shout Tests' with: | '1.0'; | > | >> project: 'OCompletion' with: | '1.1'; | > | >> project: 'OCompletion Tests' | with: | > | '1.1'; | > | >> project: 'OB Dev' with: '1.1.3'; | > | >> project: 'OB Dev Tests' with: | > | '1.1.3'; | > | >> ... | > | >> | > | >> I therefore assume that the version 1.1.3 of OmniBrowser is | > | loaded. | > | >> 1.1.3 is indeed the last version specified in | > | ConfigurationOfOmniBrowser: | > | >> ConfigurationOfOmniBrowser project lastVersion | > | >> => ~1.1.3 [ConfigurationOfOmniBrowser] | > | >> | > | >> But I evaluate: ConfigurationOfOmniBrowser project lastVersion | > | load | > | >> Then the version OB-Morphic-lr.116, OB-Standard-lr.463 and | > | >> OmniBrowser-lr.469 are loaded. | > | >> | > | >> | > | >> Exactly. And that's correct. Those are the versions that are | > | defined in | > | >> ConfigurationOfOmnibrowser 1.1.3 | > | >> | > | >> I find it is very hard to keep track of what is actually | loaded. | > | >> | > | >> | > | >> I don't understand your problem. Everything seems to work as | > | exepected. | > | >> | > | >> | > | >> I haven't closely followed the evolution of Metacello, but | > there is | > | not a | > | >> way to say: | > | >> spec project: 'OB Dev' with: 'lastestVersion' | > | >> | > | >> Yes. Don't put any version. If you don't define a version, | > | metacallo will | > | >> load the last one. | > | >> | > | >> project: 'OB Dev'; | > | >> | > | >> or even remove that line from the version method. Even more, | if | > | you want | > | >> ALL the last, you can load the baseline instead of the version. | | > In | > | such | > | >> case, as you don't specify any version, it will download all | the | > | last ones. | > | >> | > | >> Cheers | > | >> | > | >> Mariano | > | >> | > | >> | > | >> Or Something? | > | >> | > | >> Cheers, | > | >> 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 | > | >> | > | >> _______________________________________________ | > | >> 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 | | -- | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | Alexandre Bergel http://www.bergel.eu | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 3, 2010

Re: [Pharo-project] little request

by StÃ©phane Ducasse

On May 3, 2010, at 10:34 PM, Tudor Girba wrote: > On 3 May 2010, at 22:26, Laval Jannik wrote: > >> +1 >> >> On May 3, 2010, at 22:25 , StÃ©phane Ducasse wrote: >> >>> does anybody would like to have >>> cmd-b on a selector that is unique open a browser on it? > > This is not good because it is not predictable. cmd-b should open the implementors. agreed. > >>> cmd-m on a className of a class that exist open a browser on it? > > I like this one. Send me your code!

May 3, 2010

[Pharo-project] [update 1.1] #11335

by StÃ©phane Ducasse

11335 ----- - scriptLoader enh - Issue 2301: Fix drop handling in MultiByteFileStream

May 3, 2010

Re: [Pharo-project] how to simply double a ' inside string

by Schwab,Wilhelm K

Stef, First, try #printString - it might do the job for you. Failing that, you can do something like | out | out := WriteStream on:String new. self do:[ :c | c = $' ifTrue:[ out nextPut:$' ]. out nextPut:c. ]. ^out contents. I'll be interested to see all of the better ways to do this. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Monday, May 03, 2010 3:48 PM To: Pharo Development Subject: [Pharo-project] how to simply double a ' inside string Does anybody know how to double a ' inside a string? Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 3, 2010

Re: [Pharo-project] how to simply double a ' inside string

by StÃ©phane Ducasse

comment copyReplaceAll: (String with: $') with: (String with: $' with: $'). Trying with 'ababc' .'a' . 'aa' . 'aabaabc' is way simpler than with $' Stef On May 3, 2010, at 10:48 PM, StÃ©phane Ducasse wrote: > Does anybody know how to double a ' inside a string? > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 3, 2010

[Pharo-project] how to simply double a ' inside string

by StÃ©phane Ducasse

Does anybody know how to double a ' inside a string? Stef

May 3, 2010

Re: [Pharo-project] Help System

by Alexandre Bergel

> The class "HelpBrowser" is like an interface so you can write > > HelpBrowser open > HelpBrowser openOn: Integer > > and has only the minimal support to display the contents. > > We can easily implement a mechanism so that you can register another > custom (enhanced/glamour based) help browser class that is loaded > afterwards. > > I already have this in squeaksource/HelpSystem - have to merge > tomorrow. Ah ok, I understand better now. Indeed, having a documentation system in the core makes sense to me. Even though, I imagine it can be easily unloaded. Good decision! Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 3, 2010

Re: [Pharo-project] Help System

by Tudor Girba

Indeed, Glamour does not belong to core. But, it could belong to dev :) Doru On 3 May 2010, at 22:11, StÃ©phane Ducasse wrote: > +1 > > Stef > > On May 3, 2010, at 9:05 PM, Torsten Bergmann wrote: > >>> But it got loaded when I updated a core 1.1. Is this help system >>> really >>> part of the Core? >> >> Yes, the help system is now part of the core to help documenting the >> system. It's also in Squeak trunk. >> >>> I suspect a duplication of effort between Glamour and HelpBrowser. >> >> No, I dont think so. The minimalistic HelpBrowser is too simple >> to make it dependent on Glamour. Otherwise you would have to >> bring Glamour into core or dev-images and rebase all kinds >> of browsers on it (Monticello Browser, Class browser, ...) >> >> The class "HelpBrowser" is like an interface so you can write >> >> HelpBrowser open >> HelpBrowser openOn: Integer >> >> and has only the minimal support to display the contents. >> >> We can easily implement a mechanism so that you can register another >> custom (enhanced/glamour based) help browser class that is loaded >> afterwards. >> >> I already have this in squeaksource/HelpSystem - have to merge >> tomorrow. >> >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Beauty is where we see it."

May 3, 2010

Re: [Pharo-project] little request

by Tudor Girba

On 3 May 2010, at 22:26, Laval Jannik wrote: > +1 > > On May 3, 2010, at 22:25 , StÃ©phane Ducasse wrote: > >> does anybody would like to have >> cmd-b on a selector that is unique open a browser on it? This is not good because it is not predictable. cmd-b should open the implementors. >> cmd-m on a className of a class that exist open a browser on it? I like this one. Doru >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > --- > Jannik Laval > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Every successful trip needs a suitable vehicle."

May 3, 2010