- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Tests Gueard report for 20144

by Marcus Denker

On Jun 21, 2012, at 9:44 AM, StÃ©phane Ducasse wrote: > marcus do you know if it has the latest vm with the fix for files primitives? > no idea. I thought it should be aut-updated to the last... > stef > > On Jun 21, 2012, at 9:36 AM, Marcus Denker wrote: > >> >> On Jun 21, 2012, at 9:31 AM, StÃ©phane Ducasse wrote: >> >>> Hi pavel >>> >>> where did you run the tests >>> >> >> on the build server. >> >> https://ci.lille.inria.fr/pharo/view/Pharo%202.0/job/Pharo-2.0-Tests/Archit… >> >> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> > > -- Marcus Denker -- http://marcusdenker.de

June 21, 2012

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

by Guillermo Polito

I mean, privShrinkingProcess should remove the trait methods first, and then the class methods if you do not want to rely on compiler maybe... Another posibility is to copy the method, but that way they will share the same space into the sources file maybe? I don't know that part of the system.. On Thu, Jun 21, 2012 at 12:41 PM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > I think it is a bug in privShrinkingProcess that may be removing methods > from a class, keeping the one in the trait. That means that when you > remove a method from the class, the system will take the method in the > trait and try to compile it again for the class. > > > On Thu, Jun 21, 2012 at 12:33 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com > > wrote: > >> http://code.google.com/p/pharo/issues/detail?id=6110 >> >> 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

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

by Pavel Krivanek

I think that it works only with local selectors but I will check that. -- Pavel On Thu, Jun 21, 2012 at 12:41 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > I think it is a bug in privShrinkingProcess that may be removing methods > from a class, keeping the one in the trait.Â That means that when you remove > a method from the class, the system will take the method in the trait and > try to compile it again for the class. > > > On Thu, Jun 21, 2012 at 12:33 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: >> >> http://code.google.com/p/pharo/issues/detail?id=6110 >> >> 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

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

by Guillermo Polito

I think it is a bug in privShrinkingProcess that may be removing methods from a class, keeping the one in the trait. That means that when you remove a method from the class, the system will take the method in the trait and try to compile it again for the class. On Thu, Jun 21, 2012 at 12:33 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > http://code.google.com/p/pharo/issues/detail?id=6110 > > 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

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

by Pavel Krivanek

http://code.google.com/p/pharo/issues/detail?id=6110 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

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