DNU on materializing a fueled out exception

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

DNU on materializing a fueled out exception

Holger Freyther
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
Reply | Threaded
Open this post in threaded view
|

Re: DNU on materializing a fueled out exception

Mariano Martinez Peck


On Mon, Dec 19, 2016 at 4:53 AM, Holger Freyther <[hidden email]> 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. 



--
Reply | Threaded
Open this post in threaded view
|

Re: DNU on materializing a fueled out exception

Andrei Chis
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,

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

Reply | Threaded
Open this post in threaded view
|

Re: DNU on materializing a fueled out exception

Max Leske
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.



On 19 Dec 2016, at 15:12, Mariano Martinez Peck <[hidden email]> wrote:



On Mon, Dec 19, 2016 at 4:53 AM, Holger Freyther <[hidden email]> 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. 



--

Reply | Threaded
Open this post in threaded view
|

Re: DNU on materializing a fueled out exception

Denis Kudriashov
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.
Reply | Threaded
Open this post in threaded view
|

Re: DNU on materializing a fueled out exception

Denis Kudriashov

2016-12-19 18:34 GMT+01:00 Denis Kudriashov <[hidden email]>:
016-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'

As solution to current approach I agree here: it should be resolved by platform 
Reply | Threaded
Open this post in threaded view
|

Re: DNU on materializing a fueled out exception

Tudor Girba-2
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."






Reply | Threaded
Open this post in threaded view
|

Re: DNU on materializing a fueled out exception

Mariano Martinez Peck
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,

> 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."









--
Reply | Threaded
Open this post in threaded view
|

Re: DNU on materializing a fueled out exception

Holger Freyther
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



Reply | Threaded
Open this post in threaded view
|

Re: DNU on materializing a fueled out exception

Henrik Nergaard-2
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




Reply | Threaded
Open this post in threaded view
|

Re: DNU on materializing a fueled out exception

Mariano Martinez Peck
In reply to this post by Holger Freyther


On Wed, Dec 28, 2016 at 7:22 AM, Holger Freyther <[hidden email]> wrote:

> 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.


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






--
Reply | Threaded
Open this post in threaded view
|

Re: DNU on materializing a fueled out exception

Holger Freyther

> 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
Reply | Threaded
Open this post in threaded view
|

Re: DNU on materializing a fueled out exception

Ben Coman
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:

> 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