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>

Reply-To: leo-editor@googlegroups.com

To: leo-editor <leo-editor@googlegroups.com>

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?

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>
Reply-To:	leo-editor@googlegroups.com
To:	leo-editor <leo-editor@googlegroups.com>

https://gbracha.blogspot.com.au/2009/07/miracle-of-become.html��

http://www.mirandabanda.org/cogblog/2013/09/13/lazy-become-and-a-partial-read-barrier/

http://fast.org.ar/live/wp-content/uploads/2015/10/ClementBera-Efficient-support-migration.pdf

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-between-oo-in-smalltalk-and-java

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