Am 26.02.2014 um 21:37 schrieb Mariano Martinez Peck <marianop...@gmail.com>:
> > > > On Wed, Feb 26, 2014 at 5:30 PM, Norbert Hartl <norb...@hartl.name> wrote: > > 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. > > > > +9999. That's the safest thing to do: use an image with the same "code" as > the one that failed. > >> 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. > > > No problem. > > Just be careful 4: do not trust 100% of the ability to debug a post morten. > It should be considered "just as another extra tool to the PharoDebug.log". > But debugging a stack with Fuel could even be different than the scenario > that caused the error. Imagine class variables that changed value, > files/socktets or something that depended on external resources, etc etc etc. > What I mean is...the debug of a materialized fuel stack may not be the same > as debugging the error at the exact time it was produced in the very same > image it happened. But it is a great addition to PharoDebug.log for several > use cases where it helps anyway. > Mariano, I admire your ability to offer all the precautions someone can think of. Maybe it is because it involves a tool you did on your own. Thanks for that. But for me the choice is easy. Having a fueled out stack is soooo much better than textual log files so that I need to come up with a lot of drawbacks until it wouldn’t be worth using that. The side effects of having shared state is nothing that fuel introduces. If you get a debugger in your image and go back a few frames/contexts/time you cannot see the content of the objects at that time because they could have changed. I would wish, too, we would have a debugger that snapshots all state and is able to „really“ go back. But at the moment we don’t have it. So it is nothing fuel can solve. Fuel is just a wonderful tool that is capable of making stupid tasks less stupid to handle. thanks again :) Norbert > Best, > > 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 > > > > > -- > Mariano > http://marianopeck.wordpress.com
