June 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [update 2.0] #20145

by Mariano Martinez Peck

On Thu, Jun 21, 2012 at 12:14 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > On Thu, Jun 21, 2012 at 11:56 AM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: > > > > > > On Thu, Jun 21, 2012 at 11:35 AM, Guillermo Polito > > <guillermopolito(a)gmail.com> wrote: > >> > >> PAvel, the kernel does not need any of the three actually. Why you need > >> text in the kernel? > >> > > > > Because of TextContants. The users are: > > > > Smalltalk allClasses select: [:each | each poolDictionaryNames includes: > > 'TextConstants' ] -> an OrderedCollection(CharacterBlock > CharacterScanner > > CompositionScanner EncryptedMultiDisplayScanner FontSet > LogicalFontManager > > MetacelloScriptLoader MultiCharacterBlockScanner MultiCharacterScanner > > MultiDisplayScanner ParseNode ScriptLoader StandardFonts StrikeFont > > StrikeFontSet TTCFont TTCFontDescription TTCFontSet TTFontDescription > > TTFontReader Text TextAlignment TextLine TextStyle UpdatingStringMorph) > > > > so we thought the problem is Compiler. But we don't want that package in > the > > kernel either ;) > > So...I removed 'Compiler' and 'Text' from #kernelPackageNames. > > The problem is now that during the shrinking we are removing Compiler, > but > > we need it after ;) > > I would move out TextConstants from this package (maybe to to a > separate one) and moreover split this pool to two. DefaultFontFamily > and so on should not be needed for Compiler :-) > > > > > PharoKernel shrinking report > > Error: > > MessageNotUnderstood: CompiledMethod>>parserClass > > 341 2 BlockClosure>>cull: > > 3 BlockClosure>>cull:cull: > > 4 5 BlockClosure>>cull: > > 6 7 BlockClosure>>ensure: > > 8 MethodContext(ContextPart)>>handleSignal: > > 9 MessageNotUnderstood(Exception)>>signal > > 10 CompiledMethod(Object)>>doesNotUnderstand: #parserClass > > 11 CompiledMethod>>getSourceReplacingSelectorWith: > > 12 ClassDescription class(Behavior)>>addTraitSelector:withMethod: > > 13 14 OrderedCollection>>do: > > 15 ClassDescription class(Behavior)>>updateMethodDictionarySelector: > > 16 17 Array(SequenceableCollection)>>do: > > 18 ClassDescription class(Behavior)>>noteChangedSelectors: > > 19 ClassDescription class(Behavior)>>removeSelector: > > 20 ClassDescription class(ClassDescription)>>removeSelector: > > 21 22 Array(SequenceableCollection)>>do: > > 23 ClassDescription class(ClassDescription)>>removeCategory: > > 24 25 OrderedCollection>>do: > > 26 27 Set>>do: > > 28 SystemNavigation>>removeAllButPackages: > > 29 30 BlockClosure>>on:do: > > 31 BlockClosure>>ifError: > > 32 SmalltalkImage>>privShrinkingProcess > > 33 34 > > > > > > So I think SystemNavigation default removeAllButPackages: self > > kernelPackageNames. > > should not remove Compiler and we should do it at the end of the process? > > > > Pavel? > > > > Can some Traits guru explain me why we need Compiler for removing of > methods? :-) > > I don't know why it uses the parser: getSourceReplacingSelectorWith: newSelector | oldKeywords newKeywords args newSelectorWithArgs source oldSelector s | source := self sourceCode. oldSelector := self parserClass new parseSelector: source. .... if he could do: getSourceReplacingSelectorWith: newSelector | oldKeywords newKeywords args newSelectorWithArgs source oldSelector s | source := self sourceCode. oldSelector := self selector. .... Am I missing something? > -- Pavel > > >> > >> On Thu, Jun 21, 2012 at 8:38 AM, Pavel Krivanek < > pavel.krivanek(a)gmail.com> > >> wrote: > >>> > >>> This update significantly breaks the PharoKernel generation because > >>> classes in categories Text-Edition and Text-Scanning categories cannot > >>> be in this image. > >>> > >>> Please reject and rollback this update. We need to split the package > >>> into three (Text-Core, Text-Edition, Text-Scanning) and check > >>> extension methods ownership. We need working PharoKernel for work on > >>> related jobs. > >>> > >>> Cheers, > >>> -- Pavel > >>> > >>> On Wed, Jun 20, 2012 at 6:21 PM, Esteban Lorenzano < > estebanlm(a)gmail.com> > >>> wrote: > >>> > 20145 > >>> > ----- > >>> > > >>> > Issue 5945: Nice packaging for Text stuff > >>> > http://code.google.com/p/pharo/issues/detail?can=2&q=5945 > >>> > > >>> > >> > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > -- Mariano http://marianopeck.wordpress.com

June 21, 2012

Re: [Pharo-project] [update 2.0] #20145

by Pavel Krivanek

http://code.google.com/p/pharo/issues/detail?id=6109 On Thu, Jun 21, 2012 at 12:20 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Can you open an issue? :)Â I'll try to have a look at it tonight.Â The stack > trace will make it easy :P > > > On Thu, Jun 21, 2012 at 12:14 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: >> >> On Thu, Jun 21, 2012 at 11:56 AM, Mariano Martinez Peck >> <marianopeck(a)gmail.com> wrote: >> > >> > >> > On Thu, Jun 21, 2012 at 11:35 AM, Guillermo Polito >> > <guillermopolito(a)gmail.com> wrote: >> >> >> >> PAvel, the kernel does not need any of the three actually.Â Why you >> >> need >> >> text in the kernel? >> >> >> > >> > Because of TextContants. The users are: >> > >> > Smalltalk allClasses select: [:each | each poolDictionaryNames includes: >> > 'TextConstants' ]Â ->Â an OrderedCollection(CharacterBlock >> > CharacterScanner >> > CompositionScanner EncryptedMultiDisplayScanner FontSet >> > LogicalFontManager >> > MetacelloScriptLoader MultiCharacterBlockScanner MultiCharacterScanner >> > MultiDisplayScanner ParseNode ScriptLoader StandardFonts StrikeFont >> > StrikeFontSet TTCFont TTCFontDescription TTCFontSet TTFontDescription >> > TTFontReader Text TextAlignment TextLine TextStyle UpdatingStringMorph) >> > >> > so we thought the problem is Compiler. But we don't want that package in >> > the >> > kernel either ;) >> > So...I removed 'Compiler' and 'Text' from #kernelPackageNames. >> > The problem is now that during the shrinking we are removing Compiler, >> > but >> > we need it after ;) >> >> I would move out TextConstants from this package (maybe to to a >> separate one) and moreover split this pool to two. DefaultFontFamily >> and so on should not be needed for Compiler :-) >> >> > >> > PharoKernel shrinking report >> > Error: >> > MessageNotUnderstood: CompiledMethod>>parserClass >> > 341 2 BlockClosure>>cull: >> > 3 BlockClosure>>cull:cull: >> > 4 5 BlockClosure>>cull: >> > 6 7 BlockClosure>>ensure: >> > 8 MethodContext(ContextPart)>>handleSignal: >> > 9 MessageNotUnderstood(Exception)>>signal >> > 10 CompiledMethod(Object)>>doesNotUnderstand: #parserClass >> > 11 CompiledMethod>>getSourceReplacingSelectorWith: >> > 12 ClassDescription class(Behavior)>>addTraitSelector:withMethod: >> > 13 14 OrderedCollection>>do: >> > 15 ClassDescription class(Behavior)>>updateMethodDictionarySelector: >> > 16 17 Array(SequenceableCollection)>>do: >> > 18 ClassDescription class(Behavior)>>noteChangedSelectors: >> > 19 ClassDescription class(Behavior)>>removeSelector: >> > 20 ClassDescription class(ClassDescription)>>removeSelector: >> > 21 22 Array(SequenceableCollection)>>do: >> > 23 ClassDescription class(ClassDescription)>>removeCategory: >> > 24 25 OrderedCollection>>do: >> > 26 27 Set>>do: >> > 28 SystemNavigation>>removeAllButPackages: >> > 29 30 BlockClosure>>on:do: >> > 31 BlockClosure>>ifError: >> > 32 SmalltalkImage>>privShrinkingProcess >> > 33 34 >> > >> > >> > So I think SystemNavigation default removeAllButPackages: self >> > kernelPackageNames. >> > should not remove Compiler and we should do it at the end of the >> > process? >> > >> > Pavel? >> > >> >> Can some Traits guru explain me why we need Compiler for removing of >> methods? :-) >> >> -- Pavel >> >> >> >> >> On Thu, Jun 21, 2012 at 8:38 AM, Pavel Krivanek >> >> <pavel.krivanek(a)gmail.com> >> >> wrote: >> >>> >> >>> This update significantly breaks the PharoKernel generation because >> >>> classes in categories Text-Edition and Text-Scanning categories cannot >> >>> be in this image. >> >>> >> >>> Please reject and rollback this update. We need to split the package >> >>> into three (Text-Core, Text-Edition, Text-Scanning) and check >> >>> extension methods ownership. We need working PharoKernel for work on >> >>> related jobs. >> >>> >> >>> Cheers, >> >>> -- Pavel >> >>> >> >>> On Wed, Jun 20, 2012 at 6:21 PM, Esteban Lorenzano >> >>> <estebanlm(a)gmail.com> >> >>> wrote: >> >>> > 20145 >> >>> > ----- >> >>> > >> >>> > Issue 5945: Â Â Nice packaging for Text stuff >> >>> > Â Â Â Â http://code.google.com/p/pharo/issues/detail?can=2&q=5945 >> >>> > >> >>> >> >> >> > >> > >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> > >> >

June 21, 2012

[Pharo-project] [update 2.0] #20147

by Esteban Lorenzano

20147 ----- Issue 6098: Cleaning obsolete repositories in Gofer http://code.google.com/p/pharo/issues/detail?id=6098

June 21, 2012

Re: [Pharo-project] [update 2.0] #20145

by Guillermo Polito

Can you open an issue? :) I'll try to have a look at it tonight. The stack trace will make it easy :P On Thu, Jun 21, 2012 at 12:14 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > On Thu, Jun 21, 2012 at 11:56 AM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: > > > > > > On Thu, Jun 21, 2012 at 11:35 AM, Guillermo Polito > > <guillermopolito(a)gmail.com> wrote: > >> > >> PAvel, the kernel does not need any of the three actually. Why you need > >> text in the kernel? > >> > > > > Because of TextContants. The users are: > > > > Smalltalk allClasses select: [:each | each poolDictionaryNames includes: > > 'TextConstants' ] -> an OrderedCollection(CharacterBlock > CharacterScanner > > CompositionScanner EncryptedMultiDisplayScanner FontSet > LogicalFontManager > > MetacelloScriptLoader MultiCharacterBlockScanner MultiCharacterScanner > > MultiDisplayScanner ParseNode ScriptLoader StandardFonts StrikeFont > > StrikeFontSet TTCFont TTCFontDescription TTCFontSet TTFontDescription > > TTFontReader Text TextAlignment TextLine TextStyle UpdatingStringMorph) > > > > so we thought the problem is Compiler. But we don't want that package in > the > > kernel either ;) > > So...I removed 'Compiler' and 'Text' from #kernelPackageNames. > > The problem is now that during the shrinking we are removing Compiler, > but > > we need it after ;) > > I would move out TextConstants from this package (maybe to to a > separate one) and moreover split this pool to two. DefaultFontFamily > and so on should not be needed for Compiler :-) > > > > > PharoKernel shrinking report > > Error: > > MessageNotUnderstood: CompiledMethod>>parserClass > > 341 2 BlockClosure>>cull: > > 3 BlockClosure>>cull:cull: > > 4 5 BlockClosure>>cull: > > 6 7 BlockClosure>>ensure: > > 8 MethodContext(ContextPart)>>handleSignal: > > 9 MessageNotUnderstood(Exception)>>signal > > 10 CompiledMethod(Object)>>doesNotUnderstand: #parserClass > > 11 CompiledMethod>>getSourceReplacingSelectorWith: > > 12 ClassDescription class(Behavior)>>addTraitSelector:withMethod: > > 13 14 OrderedCollection>>do: > > 15 ClassDescription class(Behavior)>>updateMethodDictionarySelector: > > 16 17 Array(SequenceableCollection)>>do: > > 18 ClassDescription class(Behavior)>>noteChangedSelectors: > > 19 ClassDescription class(Behavior)>>removeSelector: > > 20 ClassDescription class(ClassDescription)>>removeSelector: > > 21 22 Array(SequenceableCollection)>>do: > > 23 ClassDescription class(ClassDescription)>>removeCategory: > > 24 25 OrderedCollection>>do: > > 26 27 Set>>do: > > 28 SystemNavigation>>removeAllButPackages: > > 29 30 BlockClosure>>on:do: > > 31 BlockClosure>>ifError: > > 32 SmalltalkImage>>privShrinkingProcess > > 33 34 > > > > > > So I think SystemNavigation default removeAllButPackages: self > > kernelPackageNames. > > should not remove Compiler and we should do it at the end of the process? > > > > Pavel? > > > > Can some Traits guru explain me why we need Compiler for removing of > methods? :-) > > -- Pavel > > >> > >> On Thu, Jun 21, 2012 at 8:38 AM, Pavel Krivanek < > pavel.krivanek(a)gmail.com> > >> wrote: > >>> > >>> This update significantly breaks the PharoKernel generation because > >>> classes in categories Text-Edition and Text-Scanning categories cannot > >>> be in this image. > >>> > >>> Please reject and rollback this update. We need to split the package > >>> into three (Text-Core, Text-Edition, Text-Scanning) and check > >>> extension methods ownership. We need working PharoKernel for work on > >>> related jobs. > >>> > >>> Cheers, > >>> -- Pavel > >>> > >>> On Wed, Jun 20, 2012 at 6:21 PM, Esteban Lorenzano < > estebanlm(a)gmail.com> > >>> wrote: > >>> > 20145 > >>> > ----- > >>> > > >>> > Issue 5945: Nice packaging for Text stuff > >>> > http://code.google.com/p/pharo/issues/detail?can=2&q=5945 > >>> > > >>> > >> > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > >

June 21, 2012

Re: [Pharo-project] [update 2.0] #20145

by Pavel Krivanek

On Thu, Jun 21, 2012 at 11:56 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Thu, Jun 21, 2012 at 11:35 AM, Guillermo Polito > <guillermopolito(a)gmail.com> wrote: >> >> PAvel, the kernel does not need any of the three actually.Â Why you need >> text in the kernel? >> > > Because of TextContants. The users are: > > Smalltalk allClasses select: [:each | each poolDictionaryNames includes: > 'TextConstants' ]Â ->Â an OrderedCollection(CharacterBlock CharacterScanner > CompositionScanner EncryptedMultiDisplayScanner FontSet LogicalFontManager > MetacelloScriptLoader MultiCharacterBlockScanner MultiCharacterScanner > MultiDisplayScanner ParseNode ScriptLoader StandardFonts StrikeFont > StrikeFontSet TTCFont TTCFontDescription TTCFontSet TTFontDescription > TTFontReader Text TextAlignment TextLine TextStyle UpdatingStringMorph) > > so we thought the problem is Compiler. But we don't want that package in the > kernel either ;) > So...I removed 'Compiler' and 'Text' from #kernelPackageNames. > The problem is now that during the shrinking we are removing Compiler, but > we need it after ;) I would move out TextConstants from this package (maybe to to a separate one) and moreover split this pool to two. DefaultFontFamily and so on should not be needed for Compiler :-) > > PharoKernel shrinking report > Error: > MessageNotUnderstood: CompiledMethod>>parserClass > 341 2 BlockClosure>>cull: > 3 BlockClosure>>cull:cull: > 4 5 BlockClosure>>cull: > 6 7 BlockClosure>>ensure: > 8 MethodContext(ContextPart)>>handleSignal: > 9 MessageNotUnderstood(Exception)>>signal > 10 CompiledMethod(Object)>>doesNotUnderstand: #parserClass > 11 CompiledMethod>>getSourceReplacingSelectorWith: > 12 ClassDescription class(Behavior)>>addTraitSelector:withMethod: > 13 14 OrderedCollection>>do: > 15 ClassDescription class(Behavior)>>updateMethodDictionarySelector: > 16 17 Array(SequenceableCollection)>>do: > 18 ClassDescription class(Behavior)>>noteChangedSelectors: > 19 ClassDescription class(Behavior)>>removeSelector: > 20 ClassDescription class(ClassDescription)>>removeSelector: > 21 22 Array(SequenceableCollection)>>do: > 23 ClassDescription class(ClassDescription)>>removeCategory: > 24 25 OrderedCollection>>do: > 26 27 Set>>do: > 28 SystemNavigation>>removeAllButPackages: > 29 30 BlockClosure>>on:do: > 31 BlockClosure>>ifError: > 32 SmalltalkImage>>privShrinkingProcess > 33 34 > > > So I think SystemNavigation default removeAllButPackages: self > kernelPackageNames. > should not remove Compiler and we should do it at the end of the process? > > Pavel? > Can some Traits guru explain me why we need Compiler for removing of methods? :-) -- Pavel >> >> On Thu, Jun 21, 2012 at 8:38 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> >> wrote: >>> >>> This update significantly breaks the PharoKernel generation because >>> classes in categories Text-Edition and Text-Scanning categories cannot >>> be in this image. >>> >>> Please reject and rollback this update. We need to split the package >>> into three (Text-Core, Text-Edition, Text-Scanning) and check >>> extension methods ownership. We need working PharoKernel for work on >>> related jobs. >>> >>> Cheers, >>> -- Pavel >>> >>> On Wed, Jun 20, 2012 at 6:21 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >>> wrote: >>> > 20145 >>> > ----- >>> > >>> > Issue 5945: Â Â Nice packaging for Text stuff >>> > Â Â Â Â http://code.google.com/p/pharo/issues/detail?can=2&q=5945 >>> > >>> >> > > > > -- > Mariano > http://marianopeck.wordpress.com >

June 21, 2012

[Pharo-project] [update 2.0] #20146

by Esteban Lorenzano

20146 ----- Issue 6097: Bad source and changes path for one click on Windows (Jenkins?) http://code.google.com/p/pharo/issues/detail?id=6097 (but still not working)

June 21, 2012

Re: [Pharo-project] [update 2.0] #20145

by Pavel Krivanek

That is a very good comment :-) We should not need Text in the kernel and as I tried, the image is able to work without it. So I take my words back, let's keep this update. -- Pavel On Thu, Jun 21, 2012 at 11:35 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > PAvel, the kernel does not need any of the three actually.Â Why you need > text in the kernel? > > > On Thu, Jun 21, 2012 at 8:38 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: >> >> This update significantly breaks the PharoKernel generation because >> classes in categories Text-Edition and Text-Scanning categories cannot >> be in this image. >> >> Please reject and rollback this update. We need to split the package >> into three (Text-Core, Text-Edition, Text-Scanning) and check >> extension methods ownership. We need working PharoKernel for work on >> related jobs. >> >> Cheers, >> -- Pavel >> >> On Wed, Jun 20, 2012 at 6:21 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> > 20145 >> > ----- >> > >> > Issue 5945: Â Â Nice packaging for Text stuff >> > Â Â Â Â http://code.google.com/p/pharo/issues/detail?can=2&q=5945 >> > >> >

June 21, 2012

Re: [Pharo-project] [update 2.0] #20145

by Mariano Martinez Peck

On Thu, Jun 21, 2012 at 11:35 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > PAvel, the kernel does not need any of the three actually. Why you need > text in the kernel? > > Because of TextContants. The users are: Smalltalk allClasses select: [:each | each poolDictionaryNames includes: 'TextConstants' ] -> an OrderedCollection(CharacterBlock CharacterScanner CompositionScanner EncryptedMultiDisplayScanner FontSet LogicalFontManager MetacelloScriptLoader MultiCharacterBlockScanner MultiCharacterScanner MultiDisplayScanner ParseNode ScriptLoader StandardFonts StrikeFont StrikeFontSet TTCFont TTCFontDescription TTCFontSet TTFontDescription TTFontReader Text TextAlignment TextLine TextStyle UpdatingStringMorph) so we thought the problem is Compiler. But we don't want that package in the kernel either ;) So...I removed 'Compiler' and 'Text' from #kernelPackageNames. The problem is now that during the shrinking we are removing Compiler, but we need it after ;) PharoKernel shrinking report Error: MessageNotUnderstood: CompiledMethod>>parserClass 341 2 BlockClosure>>cull: 3 BlockClosure>>cull:cull: 4 5 BlockClosure>>cull: 6 7 BlockClosure>>ensure: 8 MethodContext(ContextPart)>>handleSignal: 9 MessageNotUnderstood(Exception)>>signal 10 CompiledMethod(Object)>>doesNotUnderstand: #parserClass 11 CompiledMethod>>getSourceReplacingSelectorWith: 12 ClassDescription class(Behavior)>>addTraitSelector:withMethod: 13 14 OrderedCollection>>do: 15 ClassDescription class(Behavior)>>updateMethodDictionarySelector: 16 17 Array(SequenceableCollection)>>do: 18 ClassDescription class(Behavior)>>noteChangedSelectors: 19 ClassDescription class(Behavior)>>removeSelector: 20 ClassDescription class(ClassDescription)>>removeSelector: 21 22 Array(SequenceableCollection)>>do: 23 ClassDescription class(ClassDescription)>>removeCategory: 24 25 OrderedCollection>>do: 26 27 Set>>do: 28 SystemNavigation>>removeAllButPackages: 29 30 BlockClosure>>on:do: 31 BlockClosure>>ifError: 32 SmalltalkImage>>privShrinkingProcess 33 34 So I think SystemNavigation default removeAllButPackages: self kernelPackageNames. should not remove Compiler and we should do it at the end of the process? Pavel? > On Thu, Jun 21, 2012 at 8:38 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > >> This update significantly breaks the PharoKernel generation because >> classes in categories Text-Edition and Text-Scanning categories cannot >> be in this image. >> >> Please reject and rollback this update. We need to split the package >> into three (Text-Core, Text-Edition, Text-Scanning) and check >> extension methods ownership. We need working PharoKernel for work on >> related jobs. >> >> Cheers, >> -- Pavel >> >> On Wed, Jun 20, 2012 at 6:21 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> > 20145 >> > ----- >> > >> > Issue 5945: Nice packaging for Text stuff >> > http://code.google.com/p/pharo/issues/detail?can=2&q=5945 >> > >> >> > -- Mariano http://marianopeck.wordpress.com

June 21, 2012

Re: [Pharo-project] Array size in inspector

by Davide Varvello

Thanks Sean, Sorry for the wrong list -- View this message in context: http://forum.world.st/Array-size-in-inspector-tp4635484p4635827.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 21, 2012

Re: [Pharo-project] [update 2.0] #20145

by Guillermo Polito

PAvel, the kernel does not need any of the three actually. Why you need text in the kernel? On Thu, Jun 21, 2012 at 8:38 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > This update significantly breaks the PharoKernel generation because > classes in categories Text-Edition and Text-Scanning categories cannot > be in this image. > > Please reject and rollback this update. We need to split the package > into three (Text-Core, Text-Edition, Text-Scanning) and check > extension methods ownership. We need working PharoKernel for work on > related jobs. > > Cheers, > -- Pavel > > On Wed, Jun 20, 2012 at 6:21 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > 20145 > > ----- > > > > Issue 5945: Nice packaging for Text stuff > > http://code.google.com/p/pharo/issues/detail?can=2&q=5945 > > > >

June 21, 2012