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

Re: [Pharo-project] ConfigurationOfPharo and OmniBrowser
by Dale Henrichs May 4, 2010

May 4, 2010

----- "Dale Henrichs" <dale.henrichs(a)gemstone.com> wrote: | Moving the specification of OmniBrowser before the spec for | AutomaticMethodCategorizer does result in the correct mcz file for | OB-Standard to be loaded, however, other issues are exposed: | | SHOUT uses the deprecated registerMenu API | Refactoring Browser needs to be moved earlier to avoid double | loading. I didn't notice any ill effects of loading earlier | version of | Refactoring Browser. | Nile-Clients-MarianoMartinezPeck.178 has an issue with #isInMemory | not understood Using Metacello 1.0-beta.26 and PharoCore-1.1-11335-UNSTABLE (latest update), I get the same results: SHOUT uses the deprecated registerMenu API Refactoring Browser AST-Core-lr.66 is loaded first and the AST-Core-lr.67 is loaded but this probably isn't a problem, although moving the refactoring browser project in the baseline should eliminate the "double load" Nile-Clients-MarianoMartinezPeck.178 still has an issue with #isInMemory not understood, while doing NSAbstractDataStream class>>initialize Dale

2 1

[Pharo-project] how to simply double a ' inside string
by StÃ©phane Ducasse May 4, 2010

May 4, 2010

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

6 8

[Pharo-project] A question on the builder pattern
by Andreas Raab May 4, 2010

May 4, 2010

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

2 1

Re: [Pharo-project] A question on the builder pattern
by Dale Henrichs May 4, 2010

May 4, 2010

Andreas, I think the advantage of form B comes when you end up nesting the build instructions: spec for: #common do: [ spec blessing: #baseline. spec description: 'Descriptive comment'. spec project: 'UI Support' with: [ spec className: 'UIConfig'; loads: #('UI-Core' ); repository: 'http://www.example.com/r' ]. spec package: 'Example-AddOn' with: [ spec requires: #('Example-Core' ); includes: #('Example-UI' ); repositories: [ spec repository: 'http://www.example.com/yar'; repository: 'http://www.example.com/yas']]]. You can't construct the above as a cascade, so you end up having to create temp variables, etc. Like the following for form A: | common pkg | common := (spec for: #common) blessing: #baseline; description: 'Descriptive comment'. (common project: 'UI Support') className: 'UIConfig'; loads: #('UI-Core' ); repository: 'http://www.example.com/r'. pkg := common package: 'Example-AddOn'. pkg requires: #('Example-Core' ); includes: #('Example-UI' ). pkg repositories repository: 'http://www.example.com/yar'; repository: 'http://www.example.com/yas'. When I scan form B (with nested blocks) it is very clear that the repositories are associated with the package 'Example-AddOn'. If form A, it's not as obvious. Dale ----- "Andreas Raab" <andreas.raab(a)gmx.de> wrote: | 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 | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] A final version of #recreateSpecialObjectsArray for your revision
by Igor Stasenko May 4, 2010

May 4, 2010

As a result of discussion, started here http://forum.world.st/recreateSpecialObjectsArray-woes-td1837186.html we came to solution, which is following: 1. fix the interpreterProxy spec, so all VMs will include addRoot() & friends 2. create a single and _final_ version of #recreateSpecialObjectsArray 3. remove overrides of this method from both FFI and Alien packages. 4. Optionally, rewrite plugins to use own special objects at initialization, so they no longer need extending specialObjectsArray, and hence use of #recreateSpecialObjectsArray The [1] is almost everywhere now, if i'm not mistaken. The [2] is here for your revision: http://bugs.squeak.org/view.php?id=7525 So, what is left, is [3] which should be updated in official FFI and Alien sources. We should really prohibit altering this method by external packages. This method, ultimately, should belong to kernel and should not be overridden. -- Best regards, Igor Stasenko AKA sig.

1 0

[Pharo-project] RTF reader/writer
by Torsten Bergmann May 4, 2010

May 4, 2010

Cincom has something. Watch [1] or [2]. [1] http://www.cincomsmalltalk.com/blog/blogView?showComments=true&printTitle=S… [2] http://vimeo.com/groups/4790/videos/1929174 -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

1 0

[Pharo-project] PBE correction: #xor: -> #bitXor:
by Nick Ager May 4, 2010

May 4, 2010

Hi, Apologies if this isn't the best place to post corrections for the Pharo book. I'm using the latest PBE I can find (PBE1-2010-02-01.pdf). On page 200 I think all references to #xor: should be replaced by #bitXor: as my pharo-1.0 image doesn't contain #xor: except on False>>xor: and True>>xor: So Book>>hash should read: Book>>hash ^ title hash bitXor: authors hash Thanks for a great resource, Nick

1 0

[Pharo-project] Pharocasts: Dynamic finder with #doesNotUnderstand, #perform and Regex
by laurent laffont May 4, 2010

May 4, 2010

Here: http://pharocasts.blogspot.com/2010/05/dynamic-finder-with-doesnotunderstan… This is the sequel to SandstoneDb, simple ActiveRecord style persistence screencast. I show how to: - override Object#doesNotUnderstand in your class to answer to unknown messages - use regular expressions to extract substrings - use #perform: and #perform:with: to send a message dynamically - develop new code in the debugger without stopping current call. Inspired by Ruby On Rails ActiveRecord dynamic finder. Cheers, Laurent Laffont

1 0

[Pharo-project] Help System
by Torsten Bergmann May 4, 2010

May 4, 2010

>Even though, I imagine it can be easily unloaded. Yes Bye T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

1 0

[Pharo-project] ConfigurationOfPharo and OmniBrowser
by Alexandre Bergel May 3, 2010

May 3, 2010

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. 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. I find it is very hard to keep track of what is actually loaded. I haven't closely followed the evolution of Metacello, but there is not a way to say: spec project: 'OB Dev' with: 'lastestVersion' Or Something? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

4 7