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
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). FYI weâre actively working on pruning of the serialization graph to solve this. Max On 26.02.2014, at 14:01, Norbert Hartl <norbert@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
Am 26.02.2014 um 14:19 schrieb Max Leske <maxleske@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 <norbert@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
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? ... So yeah..the fact that Fuel was throwing an error causes a loop so be careful of that as well. On Wed, Feb 26, 2014 at 10:28 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 26.02.2014 um 14:19 schrieb Max Leske <maxleske@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 <norbert@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
Am 26.02.2014 um 14:38 schrieb Mariano Martinez Peck <marianopeck@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. thanks, Norbert
On Wed, Feb 26, 2014 at 10:28 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 26.02.2014 um 14:19 schrieb Max Leske <maxleske@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 <norbert@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
On Wed, Feb 26, 2014 at 3:53 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 26.02.2014 um 14:38 schrieb Mariano Martinez Peck < marianopeck@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... I recommend everyone interested in this topic to take a look to: #serializeTestFailureContext:toFileNamed: Cheers,
thanks,
Norbert
On Wed, Feb 26, 2014 at 10:28 AM, Norbert Hartl <norbert@hartl.name>wrote:
Am 26.02.2014 um 14:19 schrieb Max Leske <maxleske@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 <norbert@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
Am 26.02.2014 um 21:21 schrieb Mariano Martinez Peck <marianopeck@gmail.com>:
On Wed, Feb 26, 2014 at 3:53 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 26.02.2014 um 14:38 schrieb Mariano Martinez Peck <marianopeck@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 <norbert@hartl.name> wrote:
Am 26.02.2014 um 14:19 schrieb Max Leske <maxleske@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 <norbert@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
On Wed, Feb 26, 2014 at 5:30 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 26.02.2014 um 21:21 schrieb Mariano Martinez Peck < marianopeck@gmail.com>:
On Wed, Feb 26, 2014 at 3:53 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 26.02.2014 um 14:38 schrieb Mariano Martinez Peck < marianopeck@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. Best,
Norbert
Cheers,
thanks,
Norbert
On Wed, Feb 26, 2014 at 10:28 AM, Norbert Hartl <norbert@hartl.name>wrote:
Am 26.02.2014 um 14:19 schrieb Max Leske <maxleske@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 <norbert@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
Am 26.02.2014 um 21:37 schrieb Mariano Martinez Peck <marianopeck@gmail.com>:
On Wed, Feb 26, 2014 at 5:30 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 26.02.2014 um 21:21 schrieb Mariano Martinez Peck <marianopeck@gmail.com>:
On Wed, Feb 26, 2014 at 3:53 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 26.02.2014 um 14:38 schrieb Mariano Martinez Peck <marianopeck@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 <norbert@hartl.name> wrote:
Am 26.02.2014 um 14:19 schrieb Max Leske <maxleske@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 <norbert@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
On Wed, Feb 26, 2014 at 5:50 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 26.02.2014 um 21:37 schrieb Mariano Martinez Peck < marianopeck@gmail.com>:
On Wed, Feb 26, 2014 at 5:30 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 26.02.2014 um 21:21 schrieb Mariano Martinez Peck < marianopeck@gmail.com>:
On Wed, Feb 26, 2014 at 3:53 PM, Norbert Hartl <norbert@hartl.name>wrote:
Am 26.02.2014 um 14:38 schrieb Mariano Martinez Peck < marianopeck@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! Norbert
Best,
Norbert
Cheers,
thanks,
Norbert
On Wed, Feb 26, 2014 at 10:28 AM, Norbert Hartl <norbert@hartl.name>wrote:
Am 26.02.2014 um 14:19 schrieb Max Leske <maxleske@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 <norbert@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
Am 26.02.2014 um 22:00 schrieb Mariano Martinez Peck <marianopeck@gmail.com>:
On Wed, Feb 26, 2014 at 5:50 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 26.02.2014 um 21:37 schrieb Mariano Martinez Peck <marianopeck@gmail.com>:
On Wed, Feb 26, 2014 at 5:30 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 26.02.2014 um 21:21 schrieb Mariano Martinez Peck <marianopeck@gmail.com>:
On Wed, Feb 26, 2014 at 3:53 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 26.02.2014 um 14:38 schrieb Mariano Martinez Peck <marianopeck@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 <norbert@hartl.name> wrote:
Am 26.02.2014 um 14:19 schrieb Max Leske <maxleske@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 <norbert@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
Pharo is Cool. Definitely. How do you set up the "fuel dump"? This morning I woke up with a "out of memory" crash (the first crash in two months), and going through the .log file didn't help much. Regards! Esteban A. Maringolo 2014-02-26 10:01 GMT-03:00 Norbert Hartl <norbert@hartl.name>:
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
Here the code operates on a shared queue EventDispatcher>>#consumeQueue | block | [ true ] whileTrue: [ block := queue next. [ block value ] on: Error do: [ :err | self serializeStackFor: err. Log error: 'block execution failed. stack saved' ] ] EventDispatcher>>#serializeStackFor: anError [ FuelOutStackDebugAction serializeTestFailureContext: anError signalerContext toFileNamed: 'Stack-', (DateAndTime now printString),'.fuel' ] on: Error do: [:err| "simply continue...â ] Norbert Am 26.02.2014 um 14:40 schrieb Esteban A. Maringolo <emaringolo@gmail.com>:
Pharo is Cool. Definitely.
How do you set up the "fuel dump"?
This morning I woke up with a "out of memory" crash (the first crash in two months), and going through the .log file didn't help much.
Regards!
Esteban A. Maringolo
2014-02-26 10:01 GMT-03:00 Norbert Hartl <norbert@hartl.name>:
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
interesting So far Iâm using the sringify-ed walkbacks in emails, but (if the materializable dump isnât too big) it would definitively be cool to have it. Made me think, thanks for sharing Norbert & friends On Feb 26, 2014, at 11:31 AM, Norbert Hartl <norbert@hartl.name> wrote:
Here the code operates on a shared queue
EventDispatcher>>#consumeQueue | block | [ true ] whileTrue: [ block := queue next. [ block value ] on: Error do: [ :err | self serializeStackFor: err. Log error: 'block execution failed. stack saved' ] ]
EventDispatcher>>#serializeStackFor: anError [ FuelOutStackDebugAction serializeTestFailureContext: anError signalerContext toFileNamed: 'Stack-', (DateAndTime now printString),'.fuel' ] on: Error do: [:err| "simply continue...â ]
Norbert
Am 26.02.2014 um 14:40 schrieb Esteban A. Maringolo <emaringolo@gmail.com>:
Pharo is Cool. Definitely.
How do you set up the "fuel dump"?
This morning I woke up with a "out of memory" crash (the first crash in two months), and going through the .log file didn't help much.
Regards!
Esteban A. Maringolo
2014-02-26 10:01 GMT-03:00 Norbert Hartl <norbert@hartl.name>:
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
participants (5)
-
Esteban A. Maringolo -
Mariano Martinez Peck -
Max Leske -
Norbert Hartl -
Sebastian Sastre