[Pharo-project] fuelized test failures
Mariano Martinez Peck
marianopeck at gmail.com
Sat Jul 21 13:29:18 EDT 2012
On Sat, Jul 21, 2012 at 3:29 PM, Tudor Girba <tudor at tudorgirba.com> 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
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.
> 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:
> > 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
> "In a world where everything is moving ever faster,
> one might have better chances to win by moving slower."
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-dev