Am 26.02.2014 um 22:00 schrieb Mariano Martinez Peck <marianop...@gmail.com>:
> > > > On Wed, Feb 26, 2014 at 5:50 PM, Norbert Hartl <norb...@hartl.name> wrote: > > 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. > > Because I've been there in this case ;) > > 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. > > +9999. That's why I recommend everybody to use this approach taking the > necessary precautions. It does not harm at all and likely help a lot. > > 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. > > indeed...that's why I said "in the exact time it was produced.." > > 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. > > > Completrly agree!!! nice quote btw! > > thanks again :) > > > No problem. You know that serializing/materializing a debugger was one of the > coolest things I ever did. I was on my table, at Douai, thinking about > examples to present Fuel in the ESUG Awards 2011. I remember my wife was sit > in the couch and I said "Flor...what if I serialize the debugger!!!" . It > took me 5 minutes to try it. I was sure it was going to fail...couldn't be so > good for the first time. And surprisly....it worked out of the box. I > couldn't believe it. I said...."ok...I have everything I need for ESUG" :) > So yes, I very much like this feature! > > Also...it was the topic people outside the Smalltalk community commented the > most about Fuel... of course...this is not just Fuel...it is Smalltalk that > has contexts reified as objects and all it meta capabilities! > Just take the credit! Seaside was commented mostly about having continuations and not about building on top of smalltalk. Sure there is a powerful platform beneath. But building cool tools using that power is _really_ important, too. Norbert > 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 > > > > > -- > Mariano > http://marianopeck.wordpress.com
