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

Re: [Pharo-project] RTF reader/writer

by Nicolas Cellier

Sophie ? 2010/5/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > >> RTF is pretty evil... anything wrong with HTML? > > I do not know :) > Â this is for a potential client requirement. >> >> Regards, Gary >> >> ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> >> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Tuesday, May 04, 2010 10:30 AM >> Subject: [Pharo-project] RTF reader/writer >> >> >>> Hi guys >>> >>> Do you know if there is a library somewhere in Smalltalk to deal with RTF writing/saving? >>> >>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 4, 2010

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

by StÃ©phane Ducasse

cool! Stef On May 4, 2010, at 4:20 PM, Gary Chambers wrote: > 'don''t' printString withoutQuoting

May 4, 2010

Re: [Pharo-project] RTF reader/writer

by StÃ©phane Ducasse

> RTF is pretty evil... anything wrong with HTML? I do not know :) this is for a potential client requirement. > > Regards, Gary > > ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, May 04, 2010 10:30 AM > Subject: [Pharo-project] RTF reader/writer > > >> Hi guys >> >> Do you know if there is a library somewhere in Smalltalk to deal with RTF writing/saving? >> >> 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 4, 2010

Re: [Pharo-project] [squeak-dev] A question on the builder pattern

by Igor Stasenko

On 4 May 2010 06:05, 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? > The b and c , essentially is a form of command pattern. And there's more practical advantage, because style is not really important, and can be changed :) I am using a command pattern in SMorphic , which going to be the replacement of ToolBuilder in some distant future :) http://www.squeaksource.com/SMorphic There is a class, SMorphStyle which works as a command recorder, which is then can be applied to arbitrary morph. Its just replays all commands to this morph, and do, it doesn't needs to even know anything about the nature or morph, or use specs to keep data in fields. Its just sending a messages to it. builder := SMorphStyle new. builder allSubmorphs; className: #PluggableButton; borderWidth: 10. Here , the #allSubmorphs , and #className: is a special messages, known by builder, which changing its selection, and a #borderWidth: is an example of an arbitrary message, which should be sent to selection. So, as you may guess, when you doing: builder applyTo: myWindow it changing the border widths of all its buttons to 10 :) which can be written manually as: (morph allSubmorphs select: [:m | m class= PluggableButton ]) do: [:m | m borderWidth: 10 ]. > Cheers, > Â - Andreas > > -- Best regards, Igor Stasenko AKA sig.

May 4, 2010

Re: [Pharo-project] ConfigurationOfPharo and OmniBrowser

by Dale Henrichs

----- "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 :-) Alexandre, The short answer is that this isn't really a bug. ConfigurationOfAutomaticMethodCategorizer calls for version 1.1 of ConfigurationOfOmniBrowser which references OB-Standard-lr.442. Version 1.1.3 of ConfigurationOfOmniBrowser (which references OB-Standard-lr.463) is listed after ConfigurationOfAutomaticMethodCategorizer in 1.1-baseline so OB-Standard-lr.442 is loaded first, then OB-Standard-lr.463 will be loaded later. This implies that ConfigurationOfAutomaticMethodCategorizer will not load correctly into Pharo 1.1, so the solution is to create a new version ConfigurationOfAutomaticMethodCategorizer that will load into Pharo 1.1 (i.e. referencing version 1.1.3 of ConfigurationOfOmniBrowser) and then update ConfigurationOfPharo accordingly... I'll give the long answer here so that folks can have an example of debugging a load issue in Metacello. The first thing I do is find the top MetacelloLoaderPolicy on the debugger stack and inspect loadDirective instance variable. Here's the printString: linear load : explicit load : 1.1 [ConfigurationOfPharo] load : ConfigurationOfOCompletion-Alexandre_Bergel.17 explicit load : 1.1 [ConfigurationOfPharo] load : ConfigurationOfProfStef-DaleHenrichs.8 explicit load : 1.1 [ConfigurationOfPharo] load : ConfigurationOfOmniBrowser-MarianoMartinezPeck.41 explicit load : 1.1 [ConfigurationOfPharo] explicit load : 1.1 [ConfigurationOfPharo] explicit load : 1.1 [ConfigurationOfPharo] load : ConfigurationOfPharoNonCore-MarianoMartinezPeck.2 explicit load : 1.1 [ConfigurationOfPharo] load : ConfigurationOfRefactoringBrowser-MarianoMartinezPeck.22 explicit load : 1.1 [ConfigurationOfPharo] explicit load : 1.1 [ConfigurationOfPharo] explicit load : 1.1 [ConfigurationOfPharo] load : ConfigurationOfShout-DaleHenrichs.11 explicit load : 1.1 [ConfigurationOfPharo] load : ConfigurationOfNile-MarianoMartinezPeck.11 explicit load : 1.1 [ConfigurationOfPharo] load : ConfigurationOfAutomaticMethodCategorizer-MarianoMartinezPeck.4 explicit load : 1.1 [ConfigurationOfPharo] explicit load : 1.1 [ConfigurationOfPharo] load : ConfigurationOfNewInspector-MarianoMartinezPeck.5 explicit load : 1.1 [ConfigurationOfPharo] preload : 1.1 [ConfigurationOfPharo] >> preloadForPharo linear load : 1.1 [ConfigurationOfPharo] explicit load : 1.1 [ConfigurationOfAutomaticMethodCategorizer] linear load : 1.1 [ConfigurationOfAutomaticMethodCategorizer] linear load : 1.1 [ConfigurationOfOmniBrowser] load : OmniBrowser-lr.458 load : OB-Morphic-lr.112 load : OB-Standard-lr.442 postload : OB-Standard >> postLoadOBStandard load : AutomaticMethodCategorizer-DF.25 load : AutomaticMethodCategorizerOB-DF.1 linear load : 1.0 [ConfigurationOfShout] load : Shout-nice.83 load : ShoutWorkspace.1-tween.4 linear load : 1.0 [ConfigurationOfShout] load : ShoutTests-tween.9 linear load : 1.1.1 [ConfigurationOfOCompletion] load : RoelTyper-DamienCassou.80 load : Ocompletion-RomainRobbes.58 linear load : 1.1.1 [ConfigurationOfOCompletion] load : OcompletionTests-MarianoMartinezPeck.3 explicit load : 1.1.0 [ConfigurationOfPharoNonCore] load : ConfigurationOfPharoSound-MarianoMartinezPeck.8 explicit load : 1.1.0 [ConfigurationOfPharoNonCore] load : ConfigurationOfPharoMorphicExtras-MarianoMartinezPeck.10 preload : 1.1.0 [ConfigurationOfPharoNonCore] >> preloadForPharo linear load : 1.1.0 [ConfigurationOfPharoNonCore] linear load : 2.0 [ConfigurationOfPharoSound] load : Sound-MarianoMartinezPeck.49 load : SoundMorphicUserInterface-MarianoMartinezPeck.9 explicit load : 2.0 [ConfigurationOfPharoMorphicExtras] linear load : 2.0 [ConfigurationOfPharoMorphicExtras] load : MorphExamplesAndDemos-DamienCassou.5 load : LED-StephaneDucasse.1 load : ArchiveViewer-MarianoMartinezPeck.3 postload : 1.1.0 [ConfigurationOfPharoNonCore] >> postloadForPharo linear load : 1.1 [ConfigurationOfNewInspector] load : NewInspector-FredericPluquet.64 linear load : 1.2.1 [ConfigurationOfRefactoringBrowser] load : AST-Core-lr.67 load : Refactoring-Core-lr.115 load : Refactoring-Spelling-lr.19 linear load : 1.2.1 [ConfigurationOfRefactoringBrowser] load : AST-Tests-Core-lr.9 load : Refactoring-Tests-Core-lr.36 load : Refactoring-Tests-Spelling-lr.4 linear load : 1.1 [ConfigurationOfNile] load : Nile-Base-DamienCassou.81 linear load : 1.1 [ConfigurationOfNile] load : Nile-Tests-DamienCassou.75 load : Nile-Clients-MarianoMartinezPeck.178 explicit load : 1.1.3 [ConfigurationOfOmniBrowser] linear load : 1.1.3 [ConfigurationOfOmniBrowser] load : OmniBrowser-lr.469 load : OB-Morphic-lr.116 load : OB-Standard-lr.463 postload : OB-Standard >> postLoadOBStandard load : OB-SUnitIntegration-lr.24 load : OB-Shout-lr.5 load : OB-Refactory-lr.203 load : OB-Regex-lr.22 load : OCForOB-rr.2 explicit load : 1.1.3 [ConfigurationOfOmniBrowser] linear load : 1.1.3 [ConfigurationOfOmniBrowser] load : OB-Tests-Core-lr.81 load : OB-Tests-Morphic-lr.26 load : BogusInfo-lr.18 load : OB-Fake-lr.14 load : OB-Tests-Standard-lr.110 linear load : 1.0 [ConfigurationOfProfStef] load : ProfStef-Core-LaurentLaffont.2 linear load : 1.0 [ConfigurationOfProfStef] load : ProfStef-Tests-LaurentLaffont.2 load : ImageForDevelopers-pharo-MarianoMartinezPeck.224 postload : 1.1 [ConfigurationOfPharo] >> postloadForPharo Since OB-Standard is the problem package you can search for the package in the printString. The first occurrence is here: linear load : 1.1 [ConfigurationOfPharo] explicit load : 1.1 [ConfigurationOfAutomaticMethodCategorizer] linear load : 1.1 [ConfigurationOfAutomaticMethodCategorizer] linear load : 1.1 [ConfigurationOfOmniBrowser] load : OmniBrowser-lr.458 load : OB-Morphic-lr.112 load : OB-Standard-lr.442 postload : OB-Standard >> postLoadOBStandard and the second occurrence is here: linear load : 1.1.3 [ConfigurationOfOmniBrowser] load : OmniBrowser-lr.469 load : OB-Morphic-lr.116 load : OB-Standard-lr.463 postload : OB-Standard >> postLoadOBStandard 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... Dale

May 4, 2010

Re: [Pharo-project] A question on the builder pattern

by Dale Henrichs

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

May 4, 2010

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

by Gary Chambers

'don''t' printString withoutQuoting Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <Stephane.Ducasse(a)inria.fr> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, May 03, 2010 9:48 PM 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 4, 2010

Re: [Pharo-project] RTF reader/writer

by Gary Chambers

RTF is pretty evil... anything wrong with HTML? Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, May 04, 2010 10:30 AM Subject: [Pharo-project] RTF reader/writer > Hi guys > > Do you know if there is a library somewhere in Smalltalk to deal with RTF > writing/saving? > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 4, 2010

[Pharo-project] A final version of #recreateSpecialObjectsArray for your revision

by Igor Stasenko

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.

May 4, 2010

Re: [Pharo-project] RTF reader/writer

by HernÃ¡n Morales Durand

See here for a writer http://www.smalltalking.net/Goodies/VisualSmalltalk/index.htm HernÃ¡n 2010/5/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi guys > > Do you know if there is a library somewhere in Smalltalk to deal with RTF writing/saving? > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 4, 2010