problem with Epicea and #name
Locked
 
|
Hi,
When trying to load a new version of the GTInspector in the latest Pharo image I get an infinite recursion. It seems that the problem is appears because a class is removed, which at a certain point calls #asEpiceaRingDefinition. This does then 'self superclass name', however, the superclass is nil and UndefinedObject>>#name is called, which is deprecated. This should open a warning window and but it leads to an infinite recursion. Know problem or should I opened an issues? Cheers, Andrei |
|
|
Hi Andrei, there is an open issue that involves #name in category removal whose fix is ready in bleeding edge and only waits that i release the new stable version. But this is about category removal, not class removal. This night I will take a look on the code of class removal... however, could you send a stack trace, please? El 25/8/2016 7:18, "Andrei Chis" <[hidden email]> escribió:
|
Re: problem with Epicea and #name
|
|
Hi Martin, To reproduce the error execute the code below. The first part does some cleanups needed to remove the code. The second part attempts to remove two packages and seems to go into a recursion. If you interrupt the execution with cmd+. you'll see a lot of Context>>#handleSignal:. If you right click on one and select 'Peel to first like this' it will find the original context that triggered the error. Don't worry there is no inconvenience :). Thanks for looking into this. GTExampleOrganizer instance reset. GTExampleOrganizer instance stopThoroughly. GTExampleOrganizer stop. Smalltalk garbageCollect. self assert: GTExample allSubInstances isEmpty. self assert: GTExampleMethod allSubInstances isEmpty. Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'GT-InspectorExtensions-Core'; package: 'GT-Inspector'; load. Cheers, Andrei On Thu, Aug 25, 2016 at 1:00 PM, Martin Dias <[hidden email]> wrote:
|
Re: problem with Epicea and #name
|
|
Hi Martin,
Thanks a lot for the quick response. As Andrei said, please do not feel sorry. Epicea is an important new core component and just because it is a core one every tiny error will appear as a large problem. But, we are all humans here, and it should be expected that we make errors :). Cheers, Doru > On Aug 25, 2016, at 1:19 PM, Andrei Chis <[hidden email]> wrote: > > Hi Martin, > > To reproduce the error execute the code below. The first part does some cleanups needed to remove the code. The second part attempts to remove two packages and seems to go into a recursion. If you interrupt the execution with cmd+. you'll see a lot of Context>>#handleSignal:. If you right click on one and select 'Peel to first like this' it will find the original context that triggered the error. > > Don't worry there is no inconvenience :). > Thanks for looking into this. > > GTExampleOrganizer instance reset. > GTExampleOrganizer instance stopThoroughly. > GTExampleOrganizer stop. > Smalltalk garbageCollect. > self assert: GTExample allSubInstances isEmpty. > self assert: GTExampleMethod allSubInstances isEmpty. > > Gofer new > smalltalkhubUser: 'Moose' project: 'GToolkit'; > package: 'GT-InspectorExtensions-Core'; > package: 'GT-Inspector'; > load. > > Cheers, > Andrei > > On Thu, Aug 25, 2016 at 1:00 PM, Martin Dias <[hidden email]> wrote: > Hi Andrei, there is an open issue that involves #name in category removal whose fix is ready in bleeding edge and only waits that i release the new stable version. But this is about category removal, not class removal. This night I will take a look on the code of class removal... however, could you send a stack trace, please? > I'm sorry for the inconvenience. > Martín > > > El 25/8/2016 7:18, "Andrei Chis" <[hidden email]> escribió: > Hi, > > When trying to load a new version of the GTInspector in the latest Pharo image I get an infinite recursion. It seems that the problem is appears because a class is removed, which at a certain point calls #asEpiceaRingDefinition. This does then 'self superclass name', however, the superclass is nil and UndefinedObject>>#name is called, which is deprecated. This should open a warning window and but it leads to an infinite recursion. Know problem or should I opened an issues? > > Cheers, > Andrei > -- www.tudorgirba.com www.feenk.com "What is more important: To be happy, or to make happy?" |
|
|
In reply to this post by tinchodias
thanks martin! I really appreciate that you maintain epicea because this is a
great tool.
Le 25/8/16 à 13:00, Martin Dias a
écrit :
|
|
|
In reply to this post by Tudor Girba-2
Le 25/8/16 à 14:10, Tudor Girba a écrit : > Hi Martin, > > Thanks a lot for the quick response. > > As Andrei said, please do not feel sorry. Epicea is an important new core component and just because it is a core one every tiny error will appear as a large problem. But, we are all humans here, and it should be expected that we make errors :). + 1 Even the king of Pharo is doing errors :) Stef > > Cheers, > Doru > > >> On Aug 25, 2016, at 1:19 PM, Andrei Chis <[hidden email]> wrote: >> >> Hi Martin, >> >> To reproduce the error execute the code below. The first part does some cleanups needed to remove the code. The second part attempts to remove two packages and seems to go into a recursion. If you interrupt the execution with cmd+. you'll see a lot of Context>>#handleSignal:. If you right click on one and select 'Peel to first like this' it will find the original context that triggered the error. >> >> Don't worry there is no inconvenience :). >> Thanks for looking into this. >> >> GTExampleOrganizer instance reset. >> GTExampleOrganizer instance stopThoroughly. >> GTExampleOrganizer stop. >> Smalltalk garbageCollect. >> self assert: GTExample allSubInstances isEmpty. >> self assert: GTExampleMethod allSubInstances isEmpty. >> >> Gofer new >> smalltalkhubUser: 'Moose' project: 'GToolkit'; >> package: 'GT-InspectorExtensions-Core'; >> package: 'GT-Inspector'; >> load. >> >> Cheers, >> Andrei >> >> On Thu, Aug 25, 2016 at 1:00 PM, Martin Dias <[hidden email]> wrote: >> Hi Andrei, there is an open issue that involves #name in category removal whose fix is ready in bleeding edge and only waits that i release the new stable version. But this is about category removal, not class removal. This night I will take a look on the code of class removal... however, could you send a stack trace, please? >> I'm sorry for the inconvenience. >> Martín >> >> >> El 25/8/2016 7:18, "Andrei Chis" <[hidden email]> escribió: >> Hi, >> >> When trying to load a new version of the GTInspector in the latest Pharo image I get an infinite recursion. It seems that the problem is appears because a class is removed, which at a certain point calls #asEpiceaRingDefinition. This does then 'self superclass name', however, the superclass is nil and UndefinedObject>>#name is called, which is deprecated. This should open a warning window and but it leads to an infinite recursion. Know problem or should I opened an issues? >> >> Cheers, >> Andrei >> > -- > www.tudorgirba.com > www.feenk.com > > "What is more important: To be happy, or to make happy?" > > > |
Re: problem with Epicea and #name
|
|
Hi,
> On Aug 25, 2016, at 10:03 PM, stepharo <[hidden email]> wrote: > > > > Le 25/8/16 à 14:10, Tudor Girba a écrit : >> Hi Martin, >> >> Thanks a lot for the quick response. >> >> As Andrei said, please do not feel sorry. Epicea is an important new core component and just because it is a core one every tiny error will appear as a large problem. But, we are all humans here, and it should be expected that we make errors :). > + 1 > Even the king of Pharo is doing errors :) No no. We have agreed that there many kings :)) Doru > Stef >> >> Cheers, >> Doru >> >> >>> On Aug 25, 2016, at 1:19 PM, Andrei Chis <[hidden email]> wrote: >>> >>> Hi Martin, >>> >>> To reproduce the error execute the code below. The first part does some cleanups needed to remove the code. The second part attempts to remove two packages and seems to go into a recursion. If you interrupt the execution with cmd+. you'll see a lot of Context>>#handleSignal:. If you right click on one and select 'Peel to first like this' it will find the original context that triggered the error. >>> >>> Don't worry there is no inconvenience :). >>> Thanks for looking into this. >>> >>> GTExampleOrganizer instance reset. >>> GTExampleOrganizer instance stopThoroughly. >>> GTExampleOrganizer stop. >>> Smalltalk garbageCollect. >>> self assert: GTExample allSubInstances isEmpty. >>> self assert: GTExampleMethod allSubInstances isEmpty. >>> >>> Gofer new >>> smalltalkhubUser: 'Moose' project: 'GToolkit'; >>> package: 'GT-InspectorExtensions-Core'; >>> package: 'GT-Inspector'; >>> load. >>> >>> Cheers, >>> Andrei >>> >>> On Thu, Aug 25, 2016 at 1:00 PM, Martin Dias <[hidden email]> wrote: >>> Hi Andrei, there is an open issue that involves #name in category removal whose fix is ready in bleeding edge and only waits that i release the new stable version. But this is about category removal, not class removal. This night I will take a look on the code of class removal... however, could you send a stack trace, please? >>> I'm sorry for the inconvenience. >>> Martín >>> >>> >>> El 25/8/2016 7:18, "Andrei Chis" <[hidden email]> escribió: >>> Hi, >>> >>> When trying to load a new version of the GTInspector in the latest Pharo image I get an infinite recursion. It seems that the problem is appears because a class is removed, which at a certain point calls #asEpiceaRingDefinition. This does then 'self superclass name', however, the superclass is nil and UndefinedObject>>#name is called, which is deprecated. This should open a warning window and but it leads to an infinite recursion. Know problem or should I opened an issues? >>> >>> Cheers, >>> Andrei >>> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "What is more important: To be happy, or to make happy?" >> >> >> > > -- www.tudorgirba.com www.feenk.com "We cannot reach the flow of things unless we let go." |
|
|
ok, ok, thanks ;-) Loading latest ConfigurationOfEpicea from Epicea's repo and load bleedingEdge fixes the #name issue in the script. Tomorrow I can release the new version. Martin On Thu, Aug 25, 2016 at 6:10 PM, Tudor Girba <[hidden email]> wrote: Hi, |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |