�� �� ��Now consider your current language of choice...��
�� �� ��Say you are part of the Testing Team and a unit test errors intermittently, or you're in Operations where an intermittent error occurs in a production system.
�� �� ��Typically the program exits, maybe dumping state but losing the live context where the error occurred.
�� �� ��What would it take to reproduce the exact error context for Developers to analyze?��
�� �� ��Lets see how Pharo handles this by introducing an error into a running 'Count de Money' process.
�� �� ��(If its not running, evaluate "Greeter new counter")
�� �� ��Immediately after you save this, a pre-debug window pops up...�� ��
�� �� �� �� ��[screen snapshot pre-debug top of stack]
�� �� ��Scroll down and click on "sayCount:"�� and you should see the debugger...�� ��
�� �� �� �� ��[screen snapshot full debugger on sayCount with "* 10 printString" highlighted]
�� �� ��Now as before, you can record the execution state of all running threads by saving a Pharo Image.��
�� �� ��Later when you reopen Pharo you can continue debugging the faulted thread.��
�� �� ��So give this a try. Save and quit Pharo now. (You could even transfer the .image file together with its paired .changes file to another machine with Pharo.)
�� �� ��Open the Pharo Image again.�� Now we are ready to fix the error.�� ��
�� �� ��To explain the error, one thing Pharo newcomers need to adapt to is that arithmetic operators are just normal message sends with no special precedence.����
�� �� ��Pharo has simple semantics with just three precedence rules, evaluated right to left.
�� �� ��Unary messages like "printString" are always evaluated first.�� Binary messages like " * " are evaluated second.
�� �� ��Keyword messages like "inform:" are evaluated last.�� ��So the error here is that we multiplied an integer with a string.�� �� �� ��Easily fixed...
�� �� After saving, click <Proceed> and observe the running process continues rather than needing to restart it.��
�� �� In many situations, continuing from errors like this rather than waiting for a restarted program to progress to the same state facilitates a very quick "debug->edit->compile->run" development loop.