Hi, If I execute the following code in 30720: Gofer new smalltalkhubUser: 'Moose' project: 'MooseAlgos'; configuration; loadDevelopment. I get an emergency evaluator with a strange Original error: MessageNotUnderstood Trait>>layout. Can anyone have a look at the first one? It seems to be related to some deep code changes because the same code works find in 30714. And also there seems to be something related to a nsWriteStream: message somewhere that breaks the Spec debugger in the same process and this is why we get an Emergency evaluator instead of the debugger. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"
yep, I can confirm. Looks like latest update broke something. Esteban On 26 Jan 2014, at 15:50, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
If I execute the following code in 30720: Gofer new smalltalkhubUser: 'Moose' project: 'MooseAlgos'; configuration; loadDevelopment.
I get an emergency evaluator with a strange Original error: MessageNotUnderstood Trait>>layout.
Can anyone have a look at the first one? It seems to be related to some deep code changes because the same code works find in 30714.
And also there seems to be something related to a nsWriteStream: message somewhere that breaks the Spec debugger in the same process and this is why we get an Emergency evaluator instead of the debugger.
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
I looked some more. If I remove the check from the below message it seems to work fine (essentially, re-establishing the code from before). MCPackageManager class>>classModified: anEvent anEvent isPropagation ifTrue: [ ^ self ]. self managersForClass: anEvent classAffected do:[ :mgr | mgr modified: true ]. It seems that the isPropagation was added as an optimization mechanism, but I cannot understand its meaning. Anyone? Could we figure out the issue that was related to the commit? Cheers, Doru On Sun, Jan 26, 2014 at 4:06 PM, Esteban Lorenzano <estebanlm@gmail.com>wrote:
yep, I can confirm. Looks like latest update broke something.
Esteban
On 26 Jan 2014, at 15:50, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
If I execute the following code in 30720: Gofer new smalltalkhubUser: 'Moose' project: 'MooseAlgos'; configuration; loadDevelopment.
I get an emergency evaluator with a strange Original error: MessageNotUnderstood Trait>>layout.
Can anyone have a look at the first one? It seems to be related to some deep code changes because the same code works find in 30714.
And also there seems to be something related to a nsWriteStream: message somewhere that breaks the Spec debugger in the same process and this is why we get an Emergency evaluator instead of the debugger.
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
I looked more into it, and here is a smaller example: Gofer new smalltalkhubUser: 'Moose' project: 'MooseAlgos'; package: 'Moose-Algos-Graph'; load This one does open the debugger, so the other emergency evaluator issue comes from somewhere else. The problem seems to come from a Trait being defined in this package, and loading this trait triggers ClassModifiedClassDefinition which stumbles in ClassModifiedClassDefinition>>isPropagation "If there is not slot changes, I can assume that there is a propagation (the change is in one of the superclasses)" self oldClassDefinition layout ifNil: [ ^ false ]. ^ self newClassDefinition layout instanceVariables = self oldClassDefinition layout instanceVariables (the method was added 3 days ago by Ben) Doru On Sun, Jan 26, 2014 at 3:50 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
If I execute the following code in 30720: Gofer new smalltalkhubUser: 'Moose' project: 'MooseAlgos'; configuration; loadDevelopment.
I get an emergency evaluator with a strange Original error: MessageNotUnderstood Trait>>layout.
Can anyone have a look at the first one? It seems to be related to some deep code changes because the same code works find in 30714.
And also there seems to be something related to a nsWriteStream: message somewhere that breaks the Spec debugger in the same process and this is why we get an Emergency evaluator instead of the debugger.
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
On Sun, Jan 26, 2014 at 4:07 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
I looked more into it, and here is a smaller example: Gofer new smalltalkhubUser: 'Moose' project: 'MooseAlgos'; package: 'Moose-Algos-Graph'; load
This one does open the debugger, so the other emergency evaluator issue comes from somewhere else.
The problem seems to come from a Trait being defined in this package, and loading this trait triggers ClassModifiedClassDefinition which stumbles in
ClassModifiedClassDefinition>>isPropagation "If there is not slot changes, I can assume that there is a propagation (the change is in one of the superclasses)" self oldClassDefinition layout ifNil: [ ^ false ]. ^ self newClassDefinition layout instanceVariables = self oldClassDefinition layout instanceVariables
Despite of the name of ClassModifiedClassDefinition, it is announced also when traits are modified. I don't know if Trait should implement #layout... but it is not. I reproduced using this: Trait named: #DDDD. Trait named: #DDDD uses: {TSortable} category: 'a'. I guess that ClassModifiedClassDefinition is not only being announced when a class changed but also it is being announced when its superclass changed (in the case, "propagated"). So the purpose of #isPropagation is the check that. But I'm not sure this announcement should be done for the subclasses...
On Sun, Jan 26, 2014 at 10:50 PM, Martin Dias <tinchodias@gmail.com> wrote:
On Sun, Jan 26, 2014 at 4:07 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
I looked more into it, and here is a smaller example: Gofer new smalltalkhubUser: 'Moose' project: 'MooseAlgos'; package: 'Moose-Algos-Graph'; load
This one does open the debugger, so the other emergency evaluator issue comes from somewhere else.
The problem seems to come from a Trait being defined in this package, and loading this trait triggers ClassModifiedClassDefinition which stumbles in
ClassModifiedClassDefinition>>isPropagation "If there is not slot changes, I can assume that there is a propagation (the change is in one of the superclasses)" self oldClassDefinition layout ifNil: [ ^ false ]. ^ self newClassDefinition layout instanceVariables = self oldClassDefinition layout instanceVariables
Despite of the name of ClassModifiedClassDefinition, it is announced also when traits are modified. I don't know if Trait should implement #layout... but it is not.
I reproduced using this:
Trait named: #DDDD. Trait named: #DDDD uses: {TSortable} category: 'a'.
I guess that ClassModifiedClassDefinition is not only being announced when a class changed but also it is being announced when its superclass changed (in the case, "propagated"). So the purpose of #isPropagation is the check that. But I'm not sure this announcement should be done for the subclasses...
Yes, when a class is redefined, the change is announced for subclasses also. Maybe we shouldn't, no? code to reproduce: aClass := Object subclass: #A. aClass subclass: #B. anns := OrderedCollection new. SystemAnnouncer uniqueInstance when: ClassModifiedClassDefinition send: #add: to: anns. Object subclass: #A instanceVariableNames: 'a'. anns. ---> an OrderedCollection(a ClassModifiedClassDefinition a ClassModifiedClassDefinition) MartÃn
can you propose a fix? On 26 Jan 2014, at 22:56, Martin Dias <tinchodias@gmail.com> wrote:
On Sun, Jan 26, 2014 at 10:50 PM, Martin Dias <tinchodias@gmail.com> wrote:
On Sun, Jan 26, 2014 at 4:07 PM, Tudor Girba <tudor@tudorgirba.com> wrote: I looked more into it, and here is a smaller example: Gofer new smalltalkhubUser: 'Moose' project: 'MooseAlgos'; package: 'Moose-Algos-Graph'; load
This one does open the debugger, so the other emergency evaluator issue comes from somewhere else.
The problem seems to come from a Trait being defined in this package, and loading this trait triggers ClassModifiedClassDefinition which stumbles in
ClassModifiedClassDefinition>>isPropagation "If there is not slot changes, I can assume that there is a propagation (the change is in one of the superclasses)" self oldClassDefinition layout ifNil: [ ^ false ].
^ self newClassDefinition layout instanceVariables = self oldClassDefinition layout instanceVariables
Despite of the name of ClassModifiedClassDefinition, it is announced also when traits are modified. I don't know if Trait should implement #layout... but it is not.
I reproduced using this:
Trait named: #DDDD. Trait named: #DDDD uses: {TSortable} category: 'a'.
I guess that ClassModifiedClassDefinition is not only being announced when a class changed but also it is being announced when its superclass changed (in the case, "propagated"). So the purpose of #isPropagation is the check that. But I'm not sure this announcement should be done for the subclasses...
Yes, when a class is redefined, the change is announced for subclasses also. Maybe we shouldn't, no?
code to reproduce:
aClass := Object subclass: #A. aClass subclass: #B.
anns := OrderedCollection new. SystemAnnouncer uniqueInstance when: ClassModifiedClassDefinition send: #add: to: anns.
Object subclass: #A instanceVariableNames: 'a'.
anns. ---> an OrderedCollection(a ClassModifiedClassDefinition a ClassModifiedClassDefinition)
MartÃn
I opened an issue: https://pharo.fogbugz.com/f/cases/12731/Traits-modifications-cause-a-DNU I marked it as a show stopper because right now you cannot load a package with Traits in the image. I am not sure about triggering the event for subclasses, but I can certainly understand that it can be useful for tools. However, the problem is that we are trying to figure out isPropagation after we trigger it, instead of doing it while triggering for a subclass. So, one possibility would be to distinguish between ClassModified and SuperclassModified. I tried to search in the code quickly but could not locate the exact place. I will try again later if nobody beats me to it. Cheers, Doru On Sun, Jan 26, 2014 at 11:29 PM, Esteban Lorenzano <estebanlm@gmail.com>wrote:
can you propose a fix?
On 26 Jan 2014, at 22:56, Martin Dias <tinchodias@gmail.com> wrote:
On Sun, Jan 26, 2014 at 10:50 PM, Martin Dias <tinchodias@gmail.com>wrote:
On Sun, Jan 26, 2014 at 4:07 PM, Tudor Girba <tudor@tudorgirba.com>wrote:
I looked more into it, and here is a smaller example: Gofer new smalltalkhubUser: 'Moose' project: 'MooseAlgos'; package: 'Moose-Algos-Graph'; load
This one does open the debugger, so the other emergency evaluator issue comes from somewhere else.
The problem seems to come from a Trait being defined in this package, and loading this trait triggers ClassModifiedClassDefinition which stumbles in
ClassModifiedClassDefinition>>isPropagation "If there is not slot changes, I can assume that there is a propagation (the change is in one of the superclasses)" self oldClassDefinition layout ifNil: [ ^ false ]. ^ self newClassDefinition layout instanceVariables = self oldClassDefinition layout instanceVariables
Despite of the name of ClassModifiedClassDefinition, it is announced also when traits are modified. I don't know if Trait should implement #layout... but it is not.
I reproduced using this:
Trait named: #DDDD. Trait named: #DDDD uses: {TSortable} category: 'a'.
I guess that ClassModifiedClassDefinition is not only being announced when a class changed but also it is being announced when its superclass changed (in the case, "propagated"). So the purpose of #isPropagation is the check that. But I'm not sure this announcement should be done for the subclasses...
Yes, when a class is redefined, the change is announced for subclasses also. Maybe we shouldn't, no?
code to reproduce:
aClass := Object subclass: #A. aClass subclass: #B.
anns := OrderedCollection new. SystemAnnouncer uniqueInstance when: ClassModifiedClassDefinition send: #add: to: anns.
Object subclass: #A instanceVariableNames: 'a'.
anns. ---> an OrderedCollection(a ClassModifiedClassDefinition a ClassModifiedClassDefinition)
MartÃn
-- www.tudorgirba.com "Every thing has its own flow"
On Mon, Jan 27, 2014 at 7:10 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
I opened an issue: https://pharo.fogbugz.com/f/cases/12731/Traits-modifications-cause-a-DNU
I marked it as a show stopper because right now you cannot load a package with Traits in the image.
I am not sure about triggering the event for subclasses, but I can certainly understand that it can be useful for tools. However, the problem is that we are trying to figure out isPropagation after we trigger it, instead of doing it while triggering for a subclass. So, one possibility would be to distinguish between ClassModified and SuperclassModified. I tried to search in the code quickly but could not locate the exact place. I will try again later if nobody beats me to it.
+1 I think not much people is interested in SuperclassModified. ClassModified is the more interesting one. It requires, for example, the browser to be refreshed, the package to be marked as dirty, or the change to be logged. But SuperclassModified... ?
2014-01-27 Martin Dias <tinchodias@gmail.com>
On Mon, Jan 27, 2014 at 7:10 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
I opened an issue: https://pharo.fogbugz.com/f/cases/12731/Traits-modifications-cause-a-DNU
I marked it as a show stopper because right now you cannot load a package with Traits in the image.
I am not sure about triggering the event for subclasses, but I can certainly understand that it can be useful for tools. However, the problem is that we are trying to figure out isPropagation after we trigger it, instead of doing it while triggering for a subclass. So, one possibility would be to distinguish between ClassModified and SuperclassModified. I tried to search in the code quickly but could not locate the exact place. I will try again later if nobody beats me to it.
+1 I think not much people is interested in SuperclassModified. ClassModified is the more interesting one. It requires, for example, the browser to be refreshed, the package to be marked as dirty, or the change to be logged. But SuperclassModified... ?
So, what to do? - Don't send ClassModifiedClassDefinition in SystemAnnouncer>>traitDefinitionChangedFrom: oldTrait to: newTrait ? - Implement Trait>>layout ? - Test for oldClassDefinition isTrait in ClassModifiedClassDefinition>>isPropagating ? Nicolai
So, what to do? - Don't send ClassModifiedClassDefinition in SystemAnnouncer>>traitDefinitionChangedFrom: oldTrait to: newTrait ? - Implement Trait>>layout ? - Test for oldClassDefinition isTrait in ClassModifiedClassDefinition>>isPropagating ?
I discussed with Camille and we think it's better this other alternative: to fix class builder to only announce ClassModifiedClassDefinition for the class that really changed its definition. For the subclasses, it won't be announced. This way, it's not necessary to check if it is a propagation. We can remove the two implementors and the unique sender. I verified that this was the behavior of "old class builder" (in Pharo 2). Do you agree? I can submit a slice this afternoon. MartÃn
yes, please :) On 28 Jan 2014, at 13:47, Martin Dias <tinchodias@gmail.com> wrote:
So, what to do? - Don't send ClassModifiedClassDefinition in SystemAnnouncer>>traitDefinitionChangedFrom: oldTrait to: newTrait ? - Implement Trait>>layout ? - Test for oldClassDefinition isTrait in ClassModifiedClassDefinition>>isPropagating ?
I discussed with Camille and we think it's better this other alternative: to fix class builder to only announce ClassModifiedClassDefinition for the class that really changed its definition. For the subclasses, it won't be announced. This way, it's not necessary to check if it is a propagation. We can remove the two implementors and the unique sender.
I verified that this was the behavior of "old class builder" (in Pharo 2). Do you agree?
I can submit a slice this afternoon.
MartÃn
Yes, please! Doru On Tue, Jan 28, 2014 at 2:04 PM, Esteban Lorenzano <estebanlm@gmail.com>wrote:
yes, please :)
On 28 Jan 2014, at 13:47, Martin Dias <tinchodias@gmail.com> wrote:
So, what to do? - Don't send ClassModifiedClassDefinition in SystemAnnouncer>>traitDefinitionChangedFrom: oldTrait to: newTrait ? - Implement Trait>>layout ? - Test for oldClassDefinition isTrait in ClassModifiedClassDefinition>>isPropagating ?
I discussed with Camille and we think it's better this other alternative: to fix class builder to only announce ClassModifiedClassDefinition for the class that really changed its definition. For the subclasses, it won't be announced. This way, it's not necessary to check if it is a propagation. We can remove the two implementors and the unique sender.
I verified that this was the behavior of "old class builder" (in Pharo 2). Do you agree?
I can submit a slice this afternoon.
MartÃn
-- www.tudorgirba.com "Every thing has its own flow"
hhahah, ok, I'm on it On Tue, Jan 28, 2014 at 2:06 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Yes, please!
Doru
On Tue, Jan 28, 2014 at 2:04 PM, Esteban Lorenzano <estebanlm@gmail.com>wrote:
yes, please :)
On 28 Jan 2014, at 13:47, Martin Dias <tinchodias@gmail.com> wrote:
So, what to do? - Don't send ClassModifiedClassDefinition in SystemAnnouncer>>traitDefinitionChangedFrom: oldTrait to: newTrait ? - Implement Trait>>layout ? - Test for oldClassDefinition isTrait in ClassModifiedClassDefinition>>isPropagating ?
I discussed with Camille and we think it's better this other alternative: to fix class builder to only announce ClassModifiedClassDefinition for the class that really changed its definition. For the subclasses, it won't be announced. This way, it's not necessary to check if it is a propagation. We can remove the two implementors and the unique sender.
I verified that this was the behavior of "old class builder" (in Pharo 2). Do you agree?
I can submit a slice this afternoon.
MartÃn
-- www.tudorgirba.com
"Every thing has its own flow"
Thank you! I can review it tomorrow morning. Doru On Tue, Jan 28, 2014 at 2:10 PM, Martin Dias <tinchodias@gmail.com> wrote:
hhahah, ok, I'm on it
On Tue, Jan 28, 2014 at 2:06 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Yes, please!
Doru
On Tue, Jan 28, 2014 at 2:04 PM, Esteban Lorenzano <estebanlm@gmail.com>wrote:
yes, please :)
On 28 Jan 2014, at 13:47, Martin Dias <tinchodias@gmail.com> wrote:
So, what to do? - Don't send ClassModifiedClassDefinition in SystemAnnouncer>>traitDefinitionChangedFrom: oldTrait to: newTrait ? - Implement Trait>>layout ? - Test for oldClassDefinition isTrait in ClassModifiedClassDefinition>>isPropagating ?
I discussed with Camille and we think it's better this other alternative: to fix class builder to only announce ClassModifiedClassDefinition for the class that really changed its definition. For the subclasses, it won't be announced. This way, it's not necessary to check if it is a propagation. We can remove the two implementors and the unique sender.
I verified that this was the behavior of "old class builder" (in Pharo 2). Do you agree?
I can submit a slice this afternoon.
MartÃn
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
Done. https://pharo.fogbugz.com/f/cases/12731/Traits-modifications-cause-a-DNU On Tue, Jan 28, 2014 at 2:13 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Thank you! I can review it tomorrow morning.
Doru
On Tue, Jan 28, 2014 at 2:10 PM, Martin Dias <tinchodias@gmail.com> wrote:
hhahah, ok, I'm on it
On Tue, Jan 28, 2014 at 2:06 PM, Tudor Girba <tudor@tudorgirba.com>wrote:
Yes, please!
Doru
On Tue, Jan 28, 2014 at 2:04 PM, Esteban Lorenzano <estebanlm@gmail.com>wrote:
yes, please :)
On 28 Jan 2014, at 13:47, Martin Dias <tinchodias@gmail.com> wrote:
So, what to do? - Don't send ClassModifiedClassDefinition in SystemAnnouncer>>traitDefinitionChangedFrom: oldTrait to: newTrait ? - Implement Trait>>layout ? - Test for oldClassDefinition isTrait in ClassModifiedClassDefinition>>isPropagating ?
I discussed with Camille and we think it's better this other alternative: to fix class builder to only announce ClassModifiedClassDefinition for the class that really changed its definition. For the subclasses, it won't be announced. This way, it's not necessary to check if it is a propagation. We can remove the two implementors and the unique sender.
I verified that this was the behavior of "old class builder" (in Pharo 2). Do you agree?
I can submit a slice this afternoon.
MartÃn
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
Itâs a duplicate of a closed issue (recently integrated by Sven) We should maybe join forces :) Ben On 28 Jan 2014, at 12:41, Martin Dias <tinchodias@gmail.com> wrote:
Done. https://pharo.fogbugz.com/f/cases/12731/Traits-modifications-cause-a-DNU
On Tue, Jan 28, 2014 at 2:13 PM, Tudor Girba <tudor@tudorgirba.com> wrote: Thank you! I can review it tomorrow morning.
Doru
On Tue, Jan 28, 2014 at 2:10 PM, Martin Dias <tinchodias@gmail.com> wrote: hhahah, ok, I'm on it
On Tue, Jan 28, 2014 at 2:06 PM, Tudor Girba <tudor@tudorgirba.com> wrote: Yes, please!
Doru
On Tue, Jan 28, 2014 at 2:04 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote: yes, please :)
On 28 Jan 2014, at 13:47, Martin Dias <tinchodias@gmail.com> wrote:
So, what to do? - Don't send ClassModifiedClassDefinition in SystemAnnouncer>>traitDefinitionChangedFrom: oldTrait to: newTrait ? - Implement Trait>>layout ? - Test for oldClassDefinition isTrait in ClassModifiedClassDefinition>>isPropagating ?
I discussed with Camille and we think it's better this other alternative: to fix class builder to only announce ClassModifiedClassDefinition for the class that really changed its definition. For the subclasses, it won't be announced. This way, it's not necessary to check if it is a propagation. We can remove the two implementors and the unique sender.
I verified that this was the behavior of "old class builder" (in Pharo 2). Do you agree?
I can submit a slice this afternoon.
MartÃn
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
Could you be more specific? Which issue? Doru On Tue, Jan 28, 2014 at 4:50 PM, Benjamin < benjamin.vanryseghem.pharo@gmail.com> wrote:
It's a duplicate of a closed issue (recently integrated by Sven) We should maybe join forces :)
Ben
On 28 Jan 2014, at 12:41, Martin Dias <tinchodias@gmail.com> wrote:
Done. https://pharo.fogbugz.com/f/cases/12731/Traits-modifications-cause-a-DNU
On Tue, Jan 28, 2014 at 2:13 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Thank you! I can review it tomorrow morning.
Doru
On Tue, Jan 28, 2014 at 2:10 PM, Martin Dias <tinchodias@gmail.com>wrote:
hhahah, ok, I'm on it
On Tue, Jan 28, 2014 at 2:06 PM, Tudor Girba <tudor@tudorgirba.com>wrote:
Yes, please!
Doru
On Tue, Jan 28, 2014 at 2:04 PM, Esteban Lorenzano <estebanlm@gmail.com
wrote:
yes, please :)
On 28 Jan 2014, at 13:47, Martin Dias <tinchodias@gmail.com> wrote:
So, what to do? - Don't send ClassModifiedClassDefinition in SystemAnnouncer>>traitDefinitionChangedFrom: oldTrait to: newTrait ? - Implement Trait>>layout ? - Test for oldClassDefinition isTrait in ClassModifiedClassDefinition>>isPropagating ?
I discussed with Camille and we think it's better this other alternative: to fix class builder to only announce ClassModifiedClassDefinition for the class that really changed its definition. For the subclasses, it won't be announced. This way, it's not necessary to check if it is a propagation. We can remove the two implementors and the unique sender.
I verified that this was the behavior of "old class builder" (in Pharo 2). Do you agree?
I can submit a slice this afternoon.
MartÃn
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
Thanks, Martin. I will look tomorrow morning. Doru On Tue, Jan 28, 2014 at 4:41 PM, Martin Dias <tinchodias@gmail.com> wrote:
Done. https://pharo.fogbugz.com/f/cases/12731/Traits-modifications-cause-a-DNU
On Tue, Jan 28, 2014 at 2:13 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Thank you! I can review it tomorrow morning.
Doru
On Tue, Jan 28, 2014 at 2:10 PM, Martin Dias <tinchodias@gmail.com>wrote:
hhahah, ok, I'm on it
On Tue, Jan 28, 2014 at 2:06 PM, Tudor Girba <tudor@tudorgirba.com>wrote:
Yes, please!
Doru
On Tue, Jan 28, 2014 at 2:04 PM, Esteban Lorenzano <estebanlm@gmail.com
wrote:
yes, please :)
On 28 Jan 2014, at 13:47, Martin Dias <tinchodias@gmail.com> wrote:
So, what to do? - Don't send ClassModifiedClassDefinition in SystemAnnouncer>>traitDefinitionChangedFrom: oldTrait to: newTrait ? - Implement Trait>>layout ? - Test for oldClassDefinition isTrait in ClassModifiedClassDefinition>>isPropagating ?
I discussed with Camille and we think it's better this other alternative: to fix class builder to only announce ClassModifiedClassDefinition for the class that really changed its definition. For the subclasses, it won't be announced. This way, it's not necessary to check if it is a propagation. We can remove the two implementors and the unique sender.
I verified that this was the behavior of "old class builder" (in Pharo 2). Do you agree?
I can submit a slice this afternoon.
MartÃn
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
Thanks for integrating the fix. The Moose builds are back to normal. Cheers, Doru On Tue, Jan 28, 2014 at 4:41 PM, Martin Dias <tinchodias@gmail.com> wrote:
Done. https://pharo.fogbugz.com/f/cases/12731/Traits-modifications-cause-a-DNU
On Tue, Jan 28, 2014 at 2:13 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Thank you! I can review it tomorrow morning.
Doru
On Tue, Jan 28, 2014 at 2:10 PM, Martin Dias <tinchodias@gmail.com>wrote:
hhahah, ok, I'm on it
On Tue, Jan 28, 2014 at 2:06 PM, Tudor Girba <tudor@tudorgirba.com>wrote:
Yes, please!
Doru
On Tue, Jan 28, 2014 at 2:04 PM, Esteban Lorenzano <estebanlm@gmail.com
wrote:
yes, please :)
On 28 Jan 2014, at 13:47, Martin Dias <tinchodias@gmail.com> wrote:
So, what to do? - Don't send ClassModifiedClassDefinition in SystemAnnouncer>>traitDefinitionChangedFrom: oldTrait to: newTrait ? - Implement Trait>>layout ? - Test for oldClassDefinition isTrait in ClassModifiedClassDefinition>>isPropagating ?
I discussed with Camille and we think it's better this other alternative: to fix class builder to only announce ClassModifiedClassDefinition for the class that really changed its definition. For the subclasses, it won't be announced. This way, it's not necessary to check if it is a propagation. We can remove the two implementors and the unique sender.
I verified that this was the behavior of "old class builder" (in Pharo 2). Do you agree?
I can submit a slice this afternoon.
MartÃn
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
may be in addition we could add layout returning a default value. Stef On 28 Jan 2014, at 13:47, Martin Dias <tinchodias@gmail.com> wrote:
So, what to do? - Don't send ClassModifiedClassDefinition in SystemAnnouncer>>traitDefinitionChangedFrom: oldTrait to: newTrait ? - Implement Trait>>layout ? - Test for oldClassDefinition isTrait in ClassModifiedClassDefinition>>isPropagating ?
I discussed with Camille and we think it's better this other alternative: to fix class builder to only announce ClassModifiedClassDefinition for the class that really changed its definition. For the subclasses, it won't be announced. This way, it's not necessary to check if it is a propagation. We can remove the two implementors and the unique sender.
I verified that this was the behavior of "old class builder" (in Pharo 2). Do you agree?
I can submit a slice this afternoon.
MartÃn
2014-01-26 Tudor Girba <tudor@tudorgirba.com>
Hi,
If I execute the following code in 30720: Gofer new smalltalkhubUser: 'Moose' project: 'MooseAlgos'; configuration; loadDevelopment.
I get an emergency evaluator with a strange Original error: MessageNotUnderstood Trait>>layout.
Can anyone have a look at the first one? It seems to be related to some deep code changes because the same code works find in 30714.
And also there seems to be something related to a nsWriteStream: message somewhere that breaks the Spec debugger in the same process and this is why we get an Emergency evaluator instead of the debugger.
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
Looks like something in your project rewrites Collection>>flatCollect: from using writeStream to nsWriteStream. Although I can not find anything that implements nsWriteStream.
Indeed, I figured that one out, although after I load the code, there is nothing like this (the method is removed from the package). Anyway, the real problem is the Trait one, like I described in my follow up emails. Cheers, Doru On Sun, Jan 26, 2014 at 5:00 PM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-01-26 Tudor Girba <tudor@tudorgirba.com>
Hi,
If I execute the following code in 30720: Gofer new smalltalkhubUser: 'Moose' project: 'MooseAlgos'; configuration; loadDevelopment.
I get an emergency evaluator with a strange Original error: MessageNotUnderstood Trait>>layout.
Can anyone have a look at the first one? It seems to be related to some deep code changes because the same code works find in 30714.
And also there seems to be something related to a nsWriteStream: message somewhere that breaks the Spec debugger in the same process and this is why we get an Emergency evaluator instead of the debugger.
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
Looks like something in your project rewrites Collection>>flatCollect: from using writeStream to nsWriteStream. Although I can not find anything that implements nsWriteStream.
-- www.tudorgirba.com "Every thing has its own flow"
participants (6)
-
Benjamin -
Esteban Lorenzano -
Martin Dias -
Nicolai Hess -
Pharo4Stef -
Tudor Girba