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-in-Pharo-5>. 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 <hol...@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 >
