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.hobb...@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
