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 --------
I'm beginning to wonder what the difference is
between the Pharo way and #511: reload-leo command.
-- How does Pharo handle changes in object format or methods? How does Pharo recover from crashes due to changed method signatures, invalid calls, etc? Edward You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout. |
On Fri, Jul 7, 2017 at 10:50 PM, Offray Vladimir Luna Cárdenas <[hidden email]> wrote:
"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.
Search for "doesNotUnderstand" in these references... 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 |
Thanks a lot Ben. I'll share this thread, now that have your answers in the Leo list. Cheers, Offray On 15/07/17 04:40, Ben Coman wrote:
|
Free forum by Nabble | Edit this page |