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
On Mon, Dec 19, 2016 at 4:53 AM, Holger Freyther <holger@freyther.de> wrote:
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.
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?
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?
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. -- Mariano http://marianopeck.wordpress.com
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. https://github.com/theseion/Fuel/issues/222 <https://github.com/theseion/Fuel/issues/222>
On 19 Dec 2016, at 15:12, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Mon, Dec 19, 2016 at 4:53 AM, Holger Freyther <holger@freyther.de <mailto:holger@freyther.de>> wrote: 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.
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
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?
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?
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.
-- Mariano http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>
Hi. 2016-12-19 18:08 GMT+01:00 Max Leske <maxleske@gmail.com>:
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.
2016-12-19 18:34 GMT+01:00 Denis Kudriashov <dionisiydk@gmail.com>:
016-12-19 18:08 GMT+01:00 Max Leske <maxleske@gmail.com>:
I suppose that functionality should be resolved via FuelPlatform. Something like
FLPlatform current openDebuggerOn: Processor activeProcess context: materialization root label: 'External stack'
As solution to current approach I agree here: it should be resolved by platform
Hi,
On Dec 19, 2016, at 6:34 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi.
2016-12-19 18:08 GMT+01:00 Max Leske <maxleske@gmail.com>: 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."
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 <tudor@tudorgirba.com> wrote:
Hi,
On Dec 19, 2016, at 6:34 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi.
2016-12-19 18:08 GMT+01:00 Max Leske <maxleske@gmail.com>: 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."
-- Mariano http://marianopeck.wordpress.com
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 <https://pharo.fogbugz.com/f/cases/19477/Fuel-out-Stack-uses-old-debugger-API...>. Also currently on mac there is another issue when fueling out the stack (case 19064 <https://pharo.fogbugz.com/f/cases/19064/Fuel-out-stack-not-working>) Cheers, Andrei On Mon, Dec 19, 2016 at 9:53 AM, Holger Freyther <holger@freyther.de> wrote:
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
On 19 Dec 2016, at 08:53, Holger Freyther <holger@freyther.de> 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
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:pharo-users-bounces@lists.pharo.org] On Behalf Of Holger Freyther Sent: Wednesday, December 28, 2016 11:23 AM To: Any question about pharo is welcome <pharo-users@lists.pharo.org> Subject: Re: [Pharo-users] DNU on materializing a fueled out exception
On 19 Dec 2016, at 08:53, Holger Freyther <holger@freyther.de> 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
On Wed, Dec 28, 2016 at 7:22 AM, Holger Freyther <holger@freyther.de> wrote:
On 19 Dec 2016, at 08:53, Holger Freyther <holger@freyther.de> 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.
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?
* 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
-- Mariano http://marianopeck.wordpress.com
On 28 Dec 2016, at 13:44, Mariano Martinez Peck <marianopeck@gmail.com> 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... http://smalltalkhub.com/#!/~Pharo/Pharo50Inbox/versions/SLICE-Issue-19477-Fu... http://smalltalkhub.com/#!/~Pharo/Pharo50Inbox/versions/FuelPlatform-HolgerH... http://smalltalkhub.com/#!/~Pharo/Pharo50Inbox/versions/FuelTools-Debugger-H...
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 <holger@freyther.de> wrote:
On 28 Dec 2016, at 13:44, Mariano Martinez Peck <marianopeck@gmail.com> 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
participants (8)
-
Andrei Chis -
Ben Coman -
Denis Kudriashov -
Henrik Nergaard -
Holger Freyther -
Mariano Martinez Peck -
Max Leske -
Tudor Girba