An extra thing for the first article, maybe change the package name from "HelloDemo" to "HelloWorld"


On 9 December 2017 at 11:37, horrido <horrido.hobbies@gmail.com> wrote:
Pharo: The Next Ten Minutes
<https://medium.com/@richardeng/pharo-the-next-ten-minutes-a17899dc9a58>�� .

Feedback welcome.

I will be leaving for vacation on Sunday for two weeks. Feedback should be
given to me asap. Thanks.

I see you have auto-update-process turned on, but you didn't tell users to do this.
(I think it is useful to have on.�� @all, I'm curious why its not on by default)��


Double "little" in first sentence.


You should describe how you enter the second method over the top of the first.
People sometimes get stuck thinking they'll be altering the #sayIt method.


In hindsight, when readers go to experiment themselves,��
some may drop the #wait to see how fast it can generate messages
which will lock up the UI due to co-operative scheduling within a priority.�� ��
It will be better to use...
�� �� ��[...] #forkAt: 30 named: 'Count de Money'�� ��



> How do you like it?�� ��

maybe...
�� �� How do you like it?�� ��The implication is that in the early stages of protoyping,��
�� �� you don't need to slow down to build an object/relational mapping.
�� �� Just design with pure objects and persist sample data in the Image.��





-----------------
The article is good but feels too short.�� One additional demonstration would look good.����
To facilitate this, change the demo code to use two methods.

�� �� sayCount: anInteger
�� �� �� �� ��self inform: anInteger printString.

�� �� counter
�� �� �� �� | count |
�� �� �� �� count := 0.
�� �� �� �� [1000 timesRepeat: [count := count + 1.����
�� �� �� �� �� �� self sayCount: count.
�� �� �� �� �� �� 2 seconds wait]] forkNamed: 'Count de Money'



Then after the existing end of the article...

�� �� ��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")

�� �� ��Make this modification...
��
�� �� �� �� ��sayCount: anInteger
�� �� �� �� �� �� �� self inform: anInteger * 10 printString.

�� �� ��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...

�� �� �� �� ��sayCount: anInteger
�� �� �� �� �� �� �� self inform: (anInteger * 10) printString.

�� �� 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.

�� �� For a similar demonstration, check out [PharoLambda Serverless Debugging, https://www.youtube.com/watch?v=bNNCT1hLA3E�� ]��


HTH
cheers -ben