On Fri, Jul 7, 2017 at 10:50 PM, Offray Vladimir Luna Cárdenas < offray.luna@mutabit.com> wrote:
Hi,
Grafoscopio brings inspiration from IPython/Jupyter[1][2], Leo and, of course, Pharo/Smalltalk (among others). Recently Edward Ream, the main force behind Leo, asked my about the internals of Pharo and I would like to give him a better answer that the one I gave[4] with pointers to detailed literature. [1] http://ipython.org/ [2] http://jupyter.org/ [3] http://leoeditor.com/ [4] https://groups.google.com/forum/#!topic/leo-editor/rYF21GxraT4
So, any details on the following question will be appreciated.
Cheers,
Offray
-------- Forwarded Message -------- Subject: How does instant update work in Pharo? Date: Fri, 7 Jul 2017 03:23:21 -0700 (PDT) From: Edward K. Ream <edreamleo@gmail.com> <edreamleo@gmail.com> Reply-To: leo-editor@googlegroups.com To: leo-editor <leo-editor@googlegroups.com> <leo-editor@googlegroups.com>
I'm beginning to wonder what the difference is between the Pharo way and #511: reload-leo command. <https://github.com/leo-editor/leo-editor/issues/511>
How does Pharo handle changes in object format?
https://gbracha.blogspot.com.au/2009/07/miracle-of-become.html http://www.mirandabanda.org/cogblog/2013/09/13/lazy-become-and-a-partial-rea... http://fast.org.ar/live/wp-content/uploads/2015/10/ClementBera-Efficient-sup... https://hal.inria.fr/hal-01152610/document
or methods?
https://clementbera.wordpress.com/2013/08/09/the-cog-vm-lookup/
How does Pharo recover from crashes due to changed method signatures
"crash" is quite a loaded term. We "never" ;) crash due to application code changes. We only get "crashes" from defects in the VM. What we do get are lockups from damaging the UI loop with never completing loops or a swarm of debuggers appearing across the screen each UI cycle. You would need to clarify what is meant by "method signature". It sounds like he may be referring to argument typing. Our method arguments are not typed, so there are no method signature changes, thus its NotAProblem(tm). Now to be clear, this doesn't mean Smalltalk is weakly-typed. Smalltalk is strong-typed. Each object absolutely knows its type and what message it can respond to. We just don't type variables. i.e. we have late-bound dynamic type checking rather than compile time static type checking, which works well for us.
, invalid calls, etc?
Search for "doesNotUnderstand" in these references... https://marianopeck.wordpress.com/2011/04/30/smalltalk-reflective-model/ http://www.mirandabanda.org/bluebook/bluebook_chapter27.html https://stackoverflow.com/questions/3102695/what-are-the-key-differences-bet... http://wiki.c2.com/?DoesNotUnderstand But the best way to understand how it works is to observe it. In a playground, select the following... 1 xxxxx and choose [debug It] from the context men, then <Step Into> every line of code until the debugger window "Instance of nil did not understand #xxxxx" appears. Although the first time through you may want to <Step Over> #findContextSuchThat: and #printString. Although I'm curious why it says "Instance of nil did not...." rather than "Instance of SmallInteger did not..." cheers -ben