https://forum.world.st/fuelized-test-failures-tp4640954p4641013.html
On Sat, Jul 21, 2012 at 3:29 PM, Tudor Girba
<[hidden email]> wrote:
Wow! This is truly science fiction.
hehehe yes, but there are still some problems when serializing contexs/debuggers. I would like to clarify the possible problems.
When you serialize a context, we serialize all the context state together with its sender, and the sender has a sender, and a sender...so you end up serializing the whole list of contexts. That means that:
1) the object graph that you serialize, and hence, the stream size can be REALLY large depending on what the contexts have. Sometimes a context end up in the UI, so you end up serializing lots of morphs, colors, forms, etc. So..if everything is fine, it should be a couple hundred or thousands KB in the file. If it start to be in MB...then you may be serializing too much.
2) the same problem of 1) is that not only the graph is too big, but also that you incorporate objects (mostly when these are objects from the UI) that CHANGE while being serialized. This will cause Fuel to throw an error saying the graph has changed during serialization.
3) if 2) happens, then depending where you trigger the fuel serialization, you may end up in a loop. For example, say you want to serialize each error with Fuel. So you change SmalltalkImage>>logError:inContext: to write the context with Fuel. Now, if 2) happens and Fuel throws an error, you will try to log that again, causing again the serialization.... infinitive loop.
So...some workarounds you may try to do (still, not sure if will help in all cases):
1) Deep copy the context before serializing it.
2) If you want to serialize particular contexts (for example, particular domain exceptions) then you may know WHERE to hook to make some instVars transient and therefore avoid serializing things you don't want and that may cause 2).
3) Copy the context, and actually serialize a PART of it.
Cheers,
Cheers,
Doru
On 20 Jul 2012, at 18:09, Camillo Bruni wrote:
> From now on all the test-failures are serialized on the build server.
>
> This allows us to quickly find the cause of a failing test:
> - download the .fuel file for the failing test
> - materialize the .fuel in the image and debug the code
> | aContext |
> aContext := FLMaterializer materializeFromFileNamed: 'PharoDebug.fuel'.
> Debugger openContext: aContext label: 'This is the new debugger!' contents: nil
>
> The serialized stack trace is very limited (generally only 2 contexts) but they
> are enough to get a decent view on what the variables are
www.tudorgirba.com
"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."