[Pharo-project] [update 2.0] #20145
20145 ----- Issue 5945: Nice packaging for Text stuff http://code.google.com/p/pharo/issues/detail?can=2&q=5945
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@gmail.com> wrote:
20145 -----
Issue 5945:   Nice packaging for Text stuff     http://code.google.com/p/pharo/issues/detail?can=2&q=5945
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@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@gmail.com> wrote:
20145 -----
Issue 5945: Nice packaging for Text stuff http://code.google.com/p/pharo/issues/detail?can=2&q=5945
On Thu, Jun 21, 2012 at 11:35 AM, Guillermo Polito < guillermopolito@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@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@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
On Thu, Jun 21, 2012 at 11:56 AM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Thu, Jun 21, 2012 at 11:35 AM, Guillermo Polito <guillermopolito@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@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@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
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@gmail.com>wrote:
On Thu, Jun 21, 2012 at 11:56 AM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Thu, Jun 21, 2012 at 11:35 AM, Guillermo Polito <guillermopolito@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@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@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
http://code.google.com/p/pharo/issues/detail?id=6109 On Thu, Jun 21, 2012 at 12:20 PM, Guillermo Polito <guillermopolito@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@gmail.com> wrote:
On Thu, Jun 21, 2012 at 11:56 AM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Thu, Jun 21, 2012 at 11:35 AM, Guillermo Polito <guillermopolito@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@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@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
http://code.google.com/p/pharo/issues/detail?id=6110 On Thu, Jun 21, 2012 at 12:20 PM, Guillermo Polito <guillermopolito@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@gmail.com> wrote:
On Thu, Jun 21, 2012 at 11:56 AM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Thu, Jun 21, 2012 at 11:35 AM, Guillermo Polito <guillermopolito@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@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@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
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@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@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@gmail.com> wrote:
On Thu, Jun 21, 2012 at 11:56 AM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Thu, Jun 21, 2012 at 11:35 AM, Guillermo Polito <guillermopolito@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@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@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
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@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@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@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@gmail.com> wrote:
On Thu, Jun 21, 2012 at 11:56 AM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Thu, Jun 21, 2012 at 11:35 AM, Guillermo Polito <guillermopolito@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@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@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
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@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@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@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@gmail.com> wrote:
On Thu, Jun 21, 2012 at 11:56 AM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Thu, Jun 21, 2012 at 11:35 AM, Guillermo Polito <guillermopolito@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@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@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
The message removeAllButPackages: processes methods in classes only by categories (it uses standard message removeCategory:). So it should be fixed in the system. -- Pavel On Thu, Jun 21, 2012 at 12:44 PM, Guillermo Polito <guillermopolito@gmail.com> wrote:
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@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@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@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@gmail.com> wrote:
On Thu, Jun 21, 2012 at 11:56 AM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Thu, Jun 21, 2012 at 11:35 AM, Guillermo Polito <guillermopolito@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@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@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
On Thu, Jun 21, 2012 at 12:14 PM, Pavel Krivanek <pavel.krivanek@gmail.com>wrote:
On Thu, Jun 21, 2012 at 11:56 AM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Thu, Jun 21, 2012 at 11:35 AM, Guillermo Polito <guillermopolito@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@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@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
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@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@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@gmail.com> wrote:
20145 -----
Issue 5945:   Nice packaging for Text stuff     http://code.google.com/p/pharo/issues/detail?can=2&q=5945
participants (4)
-
Esteban Lorenzano -
Guillermo Polito -
Mariano Martinez Peck -
Pavel Krivanek