- Pharo-dev - lists.pharo.org

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

May 5, 2010

>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

5 8

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

May 4, 2010

----- "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote: | > The nesting level for '1.1.3 [ConfigurationOfOmniBrowser]' and '1.1 | > [ConfigurationOfAutomaticMethodCategorizer]' are the same which | means that | > they are both referenced in '1.1 [ConfigurationOfPharo]'. That was | enough to | > solve this particular problem, but in an Inspector, you can dive | into the | > directives themselves and actually get to the MetacelloSpec that was | used to | > create the directive... | > | > | > | Here is what I don't understand. If you have that directive, and you | have | ALL that information, can't you guess that if you need to load the N | version | of a package and then the version M, where M > N, then you can skip to | load | N and just load M directly ? | | In this example, can you DO NOT load OmniBrowser-lr.458 as you know | that | after you will load OmniBrowser-lr.469 ? | Or maybe directly about conf: Do not load 1.1 | [ConfigurationOfOmniBrowser] if you know that then you will need to | load | 1.1.3 [ConfigurationOfOmniBrowser] Mariano, If you were using #atomic loads then what you are suggesting would happen ... Metacello would recognize that OmniBrowser-lr.469 was later and would use that instead of the older mcz file. With #linear loads it isn't necessarily safe to substitute a newer version of an mcz file earlier into the load sequence, because the newer version may have dependencies that wouldn't necessarily be satisfied this early in the load sequence...The only safe way is to explicitly move the project earlier in the sequence. 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 Perhaps the MNU is due to the fact that I haven't updated PharoCore-1.1-11326-UNSTABLE. My tests to this point were done with Metacello 1.0-beta.26.1 (in development) to eliminate any (known) Metacello bugs from the equation. At this point I don't think 1.0-beta.26.1 is needed, but I will run an additional test and let you know... Dale

2 2

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