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

Re: [Pharo-project] gettext package

by Hilaire Fernandes

Michael Rueger a Ã©crit : > >> can you give a sketch example so that I the it? >> >> instaed of 'lkjhlk' translated >> NaturalLanguageTranslator translated: 'lkjhlk' > > No, you keep the 'lkjhlk' translated :-) > > Apologies, the current implementation does already what I meant > > String>>translated > ^ NaturalLanguageTranslator current translate: self > The message current has changed, it seems to have a different meaning in recent reimplementation of NaturalLanguageTranslator. I rewrote it like bellow: String>>translated "answer the receiver translated to the default language" ^NaturalLanguageTranslator translate: self > All you would need to do is to exchange the implementation of > NaturalLanguageTranslator depending on whether you want to use the > current implementation or gettext. Do we want to have two implemenations or do we just want a dummy NaturalLanguageTranslator class, and the gettext support as an external package? Hilaire

May 4, 2010

Re: [Pharo-project] ConfigurationOfPharo and OmniBrowser

by Mariano Martinez Peck

On Tue, May 4, 2010 at 9:49 PM, Dale Henrichs <dale.henrichs(a)gemstone.com>wrote: > > ----- "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 > Thanks Dale. Yes, all of those things you report, and due to the fact that not all external packages are working in Pharo 1.1 Mostly Alexandre is pushing that :) Alexandres: do you want me to commit in Nile the remove of isInMemory ?

May 4, 2010

Re: [Pharo-project] ConfigurationOfPharo and OmniBrowser

by Dale Henrichs

----- "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

May 4, 2010

Re: [Pharo-project] ConfigurationOfPharo and OmniBrowser

by Dale Henrichs

----- "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

May 4, 2010

Re: [Pharo-project] ConfigurationOfPharo and OmniBrowser

by Dale Henrichs

May 4, 2010

Re: [Pharo-project] ConfigurationOfPharo and OmniBrowser

by Alexandre Bergel

> Thanks Dale for the dedicated answer. I understood you correclty? If > I change baseline11: and I put > > project: 'AutomaticMethodCategorizer' > with: > [ spec > className: > 'ConfigurationOfAutomaticMethodCategorizer'; > file: > 'ConfigurationOfAutomaticMethodCategorizer'; > repository: 'http://www.squeaksource.com/MetacelloRepository' > ]; > > > AFTER > > project: 'OB Dev' > with: > [ spec > className: > 'ConfigurationOfOmniBrowser'; > loads: #('Dev'); > file: 'ConfigurationOfOmniBrowser'; > repository: 'http://www.squeaksource.com/MetacelloRepository' > ]; > > > then it should work ok ? I understand that if you do this, then the version 1.1.3 of Omnibrowser will be loaded, then AutomaticMethodCategorizer will load the old version of OB. I think that ConfigurationOfAutomaticMethodCategorizer needs to be updated. I work on it now... Cheers, Alexandre > > > > 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... > > yes...the problem is that you have to do that in all the confs that > points to OB. > > ..... > > > 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] > > Thanks a lot for the explanation dale! > > mariano > > _______________________________________________ > 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 4, 2010

Re: [Pharo-project] ConfigurationOfPharo and OmniBrowser

by Alexandre Bergel

I understand now. Thanks, Alexandre On 4 May 2010, at 12:52, Dale Henrichs wrote: > > ----- "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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 4, 2010

Re: [Pharo-project] RTF reader/writer

by StÃ©phane Ducasse

Tx! Stef On May 4, 2010, at 7:31 PM, John M McIntosh wrote: > > On 2010-05-04, at 10:15 AM, Nicolas Cellier wrote: > >> Sophie ? >> > > Ya, there's a RTF parser in there.. RTFParser > > It makes a parse tree, then constructs a Sophie text tree, but obviously you could provide your own builder to > make whatever is desired from the RTF parse tree. > > I don't think there was a writer in there. > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > _______________________________________________ > 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 John M McIntosh

On 2010-05-04, at 10:15 AM, Nicolas Cellier wrote: > Sophie ? > Ya, there's a RTF parser in there.. RTFParser It makes a parse tree, then constructs a Sophie text tree, but obviously you could provide your own builder to make whatever is desired from the RTF parse tree. I don't think there was a writer in there. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

May 4, 2010

Re: [Pharo-project] ConfigurationOfPharo and OmniBrowser

by Mariano Martinez Peck

On Tue, May 4, 2010 at 6:52 PM, Dale Henrichs <dale.henrichs(a)gemstone.com>wrote: > > ----- "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. > > Thanks Dale for the dedicated answer. I understood you correclty? If I change baseline11: and I put project: 'AutomaticMethodCategorizer' with: [ spec className: 'ConfigurationOfAutomaticMethodCategorizer'; file: 'ConfigurationOfAutomaticMethodCategorizer'; repository: ' http://www.squeaksource.com/MetacelloRepository' ]; AFTER project: 'OB Dev' with: [ spec className: 'ConfigurationOfOmniBrowser'; loads: #('Dev'); file: 'ConfigurationOfOmniBrowser'; repository: ' http://www.squeaksource.com/MetacelloRepository' ]; then it should work ok ? > 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... > yes...the problem is that you have to do that in all the confs that points to OB. ..... > 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] Thanks a lot for the explanation dale! mariano

May 4, 2010