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