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