DNU on materializing a fueled out exception
Locked
DNU on materializing a fueled out exception
 
|
Hi,
I showed Pharo to a friend and wanted to show the nice feature of fueling out an exception and then using FLMaterializer class>>#materializeFromFileNamed: to load it back and get a debugger up. In Pharo5 I am presented a DNU instead. The DNU is on GTGenericStackDebugger as it doesn't understand the message Fuel is sending. What to fix, Fuel to use the new protocol or GTGenericStackDebugger to honor the old protocol? FueldOutStackDebugAction>>#serializeTestFailureContext: aContext toFileNamed: aFilename | serializer | serializer := FLSerializer newDefault. self encodeDebugInformationOn: serializer. serializer addPostMaterializationAction: [ :materialization | Smalltalk tools debugger openOn: Processor activeProcess context: materialization root label: 'External stack' contents: nil fullView: false ]. So it looks like now it should create a debug session first and then pass it to the debugger? I think loading new fuel in Pharo3.x is still possible so maybe it is best to re-add that protocol? comments? holger |
Re: DNU on materializing a fueled out exception
|
|
On Mon, Dec 19, 2016 at 4:53 AM, Holger Freyther <[hidden email]> wrote: Hi, Hi Holger, I hope you were able to show that example to him anyways. That example make us won the first price at ESUG awards hahaha. I still remember when I was sitting at home, trying to think of a good example to show and I thought: "what if I serialize the debugger and the stack to another image?". I tried and it worked out of the box. One of the happiest dev programming days ever hahaha. The DNU is on GTGenericStackDebugger as it doesn't understand the message Fuel is sending. What to fix, Fuel to use the new protocol or GTGenericStackDebugger to honor the old protocol? Well, if the GT developers (CC'ed Dory) do not want to add back the old protocol, then no problem, we do have a way to manage portability across dialects and versions. Max Leske (CC'ed) has changed and improved this in the recent months. So I will wait to see if he can take care. Else, I will do it. Thanks for the report. |
Re: DNU on materializing a fueled out exception
|
|
In reply to this post by Holger Freyther
Hi Holgen, This should be fixed by updating #serializeTestFailureContext:toFileNamed:. The API of the debugger was refactored in Pharo 5 and it seems like #serializeTestFailureContext:toFileNamed: was not updated in Pharo 5. Created an issue case 19477. Also currently on mac there is another issue when fueling out the stack (case 19064) Cheers, Andrei On Mon, Dec 19, 2016 at 9:53 AM, Holger Freyther <[hidden email]> wrote: Hi, |
|
|
In reply to this post by Mariano Martinez Peck
I suppose that functionality should be resolved via FuelPlatform. Something like
FLPlatform current openDebuggerOn: Processor activeProcess context: materialization root label: 'External stack' That method can then be overriden accoring to the platform.
Holger, did you load Fuel explicitly or did you use the version that's already in Pharo 5? In the latter case we'll have to port that fix back to Pharo 5. Cheers, Max
|
Re: DNU on materializing a fueled out exception
|
|
Hi. 2016-12-19 18:08 GMT+01:00 Max Leske <[hidden email]>:
Is it really nice way to do it? I mean why we force system to open debugger when serialised context is loaded? IMHO it is responsibility of tool to decide what to do with object. It should be good extension for file browser or inspector. Tool will detect that it work with context and will allow to debug it. Post materialisation action is nice feature but for me it is overused here. |
Re: DNU on materializing a fueled out exception
|
|
2016-12-19 18:34 GMT+01:00 Denis Kudriashov <[hidden email]>:
As solution to current approach I agree here: it should be resolved by platform |
Re: DNU on materializing a fueled out exception
|
|
In reply to this post by Denis Kudriashov
Hi,
> On Dec 19, 2016, at 6:34 PM, Denis Kudriashov <[hidden email]> wrote: > > Hi. > > 2016-12-19 18:08 GMT+01:00 Max Leske <[hidden email]>: > I suppose that functionality should be resolved via FuelPlatform. Something like > > FLPlatform current > openDebuggerOn: Processor activeProcess > context: materialization root > label: 'External stack' > > Is it really nice way to do it? I mean why we force system to open debugger when serialised context is loaded? > IMHO it is responsibility of tool to decide what to do with object. It should be good extension for file browser or inspector. Tool will detect that it work with context and will allow to debug it. > > Post materialisation action is nice feature but for me it is overused here. Looking from far away (I did not check the code) I kind of agree with this point of view. If we make it the responsibility of the tool, the design becomes a bit more object-centric. To me it looks like the Platform tries to know more things that are not about Fuel. Cheers, Doru -- www.tudorgirba.com www.feenk.com "The coherence of a trip is given by the clearness of the goal." |
Re: DNU on materializing a fueled out exception
|
|
I personally think Denis has raised an important remark. Fuel responsibility here should stop at supporting post materialization actions. So...I do agree that this code is ONE particular usage of Fuel and such code should likely be packaged with the tool and not with Fuel . On Mon, Dec 19, 2016 at 2:41 PM, Tudor Girba <[hidden email]> wrote: Hi, |
Re: DNU on materializing a fueled out exception
|
|
In reply to this post by Holger Freyther
> On 19 Dec 2016, at 08:53, Holger Freyther <[hidden email]> wrote: Good Morning Everyone, > So it looks like now it should create a debug session first and then pass it to the debugger? I think loading new fuel in Pharo3.x is still possible so maybe it is best to re-add that protocol? I hope all of you had a nice break and look forward to 2017. I understand that in the future (Pharo6 or beyond) there are conceptually better ways to achieve what was working in Pharo3 (and maybe before) but right now something that worked stopped to work and from my point of view such a regression should be fixed. I am not asking someone to fix what I think is important but I am still struggling to grasp the process of getting a bugfix into Pharo5. Maybe someone can help to line it out? * I pick the approach Max suggested and put it into FLPlatform to open a debugger for a context * Put it into the Pharo50Inbox? * Create a ticket? * Make a slice? holger |
Re: DNU on materializing a fueled out exception
|
|
Hi Holger,
For slice based fixes: 1) Open case on Fogbugz and set the milestone to Pharo 5.0 2) Create a slice with the proposed fix 3) In Monticello browser: Select the slice package and select Pharo50/main repository and then click on changes to verify that the slice is correct. 3) Upload the slice to Pharo50Inbox/main 4) Copy the slice commit text to the case on Fogbugz so others will know which slice is the current. (click on edit) 5) Change the status of the case from "Work needed" to "Resolved(Fix review needed)" (this will trigger the automatic test runner). (click on resolve). https://vimeo.com/162493974 Best regards, Henrik -----Original Message----- From: Pharo-users [mailto:[hidden email]] On Behalf Of Holger Freyther Sent: Wednesday, December 28, 2016 11:23 AM To: Any question about pharo is welcome <[hidden email]> Subject: Re: [Pharo-users] DNU on materializing a fueled out exception > On 19 Dec 2016, at 08:53, Holger Freyther <[hidden email]> wrote: Good Morning Everyone, > So it looks like now it should create a debug session first and then pass it to the debugger? I think loading new fuel in Pharo3.x is still possible so maybe it is best to re-add that protocol? I hope all of you had a nice break and look forward to 2017. I understand that in the future (Pharo6 or beyond) there are conceptually better ways to achieve what was working in Pharo3 (and maybe before) but right now something that worked stopped to work and from my point of view such a regression should be fixed. I am not asking someone to fix what I think is important but I am still struggling to grasp the process of getting a bugfix into Pharo5. Maybe someone can help to line it out? * I pick the approach Max suggested and put it into FLPlatform to open a debugger for a context * Put it into the Pharo50Inbox? * Create a ticket? * Make a slice? holger |
Re: DNU on materializing a fueled out exception
|
|
In reply to this post by Holger Freyther
On Wed, Dec 28, 2016 at 7:22 AM, Holger Freyther <[hidden email]> wrote:
Hi Holger, Yes, terrible busy months around here, sorry. I am not asking someone to fix what I think is important but I am still struggling to grasp the process of getting a bugfix into Pharo5. But.... are you sure there will be a bugfix release of 5.0? Because I am not sure about that. Maybe someone can help to line it out? |
Re: DNU on materializing a fueled out exception
|
|
> On 28 Dec 2016, at 13:44, Mariano Martinez Peck <[hidden email]> wrote: > > I am not asking someone to fix what I think is important but I am still struggling to grasp the process of getting a bugfix into Pharo5. > > > But.... are you sure there will be a bugfix release of 5.0? Because I am not sure about that. I have committed a slice into the Pharo5 inbox but I don't see the monkey(?) testing the change or the slice being mentioned in the ticket. Do I have to do anything extra? thanks holger Links to tickets, the slice and the individual monticello commits https://pharo.fogbugz.com/f/cases/19477/Fuel-out-Stack-uses-old-debugger-API-in-Pharo-5 http://smalltalkhub.com/#!/~Pharo/Pharo50Inbox/versions/SLICE-Issue-19477-Fuel-out-Stack-uses-old-debugger-API-in-Pharo-5-HolgerHansPeterFreyther.1 http://smalltalkhub.com/#!/~Pharo/Pharo50Inbox/versions/FuelPlatform-HolgerHansPeterFreyther.63 http://smalltalkhub.com/#!/~Pharo/Pharo50Inbox/versions/FuelTools-Debugger-HolgerHansPeterFreyther.11 |
|
|
You needed to change the status from 'Work Needed' to 'Resolved (Fix Review Needed)',
which I see Andrei has done and the monkey has run. cheers -ben On Mon, Jan 23, 2017 at 1:15 AM, Holger Freyther <[hidden email]> wrote:
|
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |