Am 26.02.2014 um 21:21 schrieb Mariano Martinez Peck <marianop...@gmail.com>:
> > > > On Wed, Feb 26, 2014 at 3:53 PM, Norbert Hartl <norb...@hartl.name> wrote: > > Am 26.02.2014 um 14:38 schrieb Mariano Martinez Peck <marianop...@gmail.com>: > >> Just be careful 2: "I switched one of my servers to dump to stack with fuel >> to disk if an exception occurs. " >> Once it happened to me the stack I was taking for serializing an error was >> too big. Too big because it even reached the UI. The UI has lots of sensible >> objects that change quite frequently. So my graph to serialize was big and >> the graph changed quite frequently. Result: Fuel throwing error because the >> graph to serialize changed while being serialized. Oh...exception? Fuel out >> exception! exception. Oh exception? ... >> > Good point, thanks! > >> So yeah..the fact that Fuel was throwing an error causes a loop so be >> careful of that as well. >> > If the serialization fails I just consider it an unrecoverable error and > proceed. I will add a logging message for that case so I can at least so when > something does not working while fueling out the stack. > > > Forgot... "just be careful 3": it may happen that you cannot correctly > materialize (not serialization) the graph: a method has changed, a class is > missing..whatever... So what I did in the fuel out of failure tests is to add > to the serializer header all the info (as plain strings) that we normally > have in the PharoDebug.log. This "header" will always be able to be > materialized.... this way, I don't have the risk of not being able to > materialize and hence loose info, and yet I don't need PharoDebug.log as > well. If you don't do what I did, then you likely need also pharoDebug.log > just in case... > That is unlikely to happen. My workflow is that every deployed image goes through the CI server. If a problem arises I download that same image from the CI server and load the stacks back into this. Everything is else is IMHO asking for trouble because contexts won’t map properly. > I recommend everyone interested in this topic to take a look to: > #serializeTestFailureContext:toFileNamed: > That is what I am using because it does what I want to happen. It is only the selector that doesn’t fit that well :) thanks a lot for this information Mariano. This is highly appreciated to get infos from someone that knows the stuff. Norbert > Cheers, > > > thanks, > > Norbert > >> >> >> On Wed, Feb 26, 2014 at 10:28 AM, Norbert Hartl <norb...@hartl.name> wrote: >> >> Am 26.02.2014 um 14:19 schrieb Max Leske <maxle...@gmail.com>: >> >> > Cool! :) >> > >> > Just be careful: if you’re using a large model the stack can blow up your >> > image with a low space warning / make it inresponsive (because the stack >> > referenes your model and boom, pretty much all of your instances will >> > becom serialized). >> > >> Yes, I know. But that would be a problem anyway. I think I have time. In the >> fuel files are 8 (!) contexts. :) >> >> Norbert >> >> > FYI we’re actively working on pruning of the serialization graph to solve >> > this. >> > >> > Max >> > >> > >> > On 26.02.2014, at 14:01, Norbert Hartl <norb...@hartl.name> wrote: >> > >> >> The best smalltalk/pharo moments you get if you try things you want to >> >> have just in order to see they are already there. >> >> >> >> Today FileBrowser. >> >> I switched one of my servers to dump to stack with fuel to disk if an >> >> exception occurs. Today I copied the files from the server to my local >> >> machine and opened a workspace starting to write an expression to open >> >> them. Then I thought it would be cool if I could use the file browser for >> >> it. So I opened it and navigated to the directory with the fuel files…et >> >> voilà…as soon as I clicked on a fuel file a button „materialize“ appeared >> >> which showed the stack from the server right away. >> >> >> >> Just brilliant! Well done! >> >> >> >> Norbert >> > >> > >> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com > > > > > -- > Mariano > http://marianopeck.wordpress.com
