[Vm-dev] Recreating live coding in CPython 3.5

Ben Coman btc at openinworld.com
Wed Oct 11 12:49:25 UTC 2017


On Wed, Oct 11, 2017 at 8:11 PM, Dimitris Chloupis <kilon.alios at gmail.com>
wrote:

>
> on the subject of
> " In Pharo the VM recompiles a method and replace it’s old instance with
> a new one while code executes"
> I was wrong, the rest it correct in the live execution of the code and
> other objects.
>
> Pharo VM will update the class objects (together with other type of
> objects) but it wont update instance objects.Probably this is done on
> purpose for not overriding and losing on reload the existing live state and
> live code (in this case instance methods), because module reloading is not
> made specific for live coding as I explained in the thread. So a class
> object will be replaced but not an instance. What led me to this wrong
> assumption was that the code I am working on is reinitialising my objects
> for debugging purposes because currently live state is not my concern as I
> am working on a GUI and some other technical reason. I did not realise that
> it was my reinisitialisation that was updating my instance objects(method
> wise, state was lost obviously) and not Python VM. Hence in my code the
> instance objects were always updated to the latest code as I was changing
> it. However now I enter the stage that I need to also update the live state
> without a full reinitialisation.
>
> Its possible to update the instance object manually . So far I have found
> two ways of doing this
> a) Reinitialisation and take the state from the old one (instance
> variables and their values are stored as a dicitionary) and copy them to
> the new one and discard the old instance or
> b)  take the methods (methods in python are objects and so are functions
> so they can be referenced) from the new one and copy them to the old one
> and discard the new instance.
> I have tested both, both work as expected. Now I am in the process of
> finding how to detect that a class changed in a module so i dont have to
> reinitialise all classes (I know the overall solution to this as well) in a
> module and because reloading works per module at least I have avoided the
> other instances. But that is not my problem.
>
> My problem is what other challanges I have to face which I am not aware of
> live coding wise. Because I never tried implementing live coding enviroment
> in another language (my experiements are focused only on live execution of
> code because at the time the idea was to keep using Pharo for live state
> data) before it would be great if experts give me an insight about Pharo's
> live coding internals. This way I can "steal" cool ideas that I may not be
> aware they exists and make my live coding environment library progressively
> closer to Pharo.
>

> Hence, I need guidance for the advanced stuff.
>

I'm not sure if this matches what you want, but I remember finding these
articles enlightening about VM internals...
* https://clementbera.wordpress.com/2013/08/09/the-cog-vm-lookup/
*
http://www.mirandabanda.org/cogblog/2011/03/01/build-me-a-jit-as-fast-as-you-can/

Alternatively, with your background and focus on Python, maybe you can
learn something from RSqueak? ...
* http://scg.unibe.ch/archive/papers/Bolz08aSpy.pdf
*
http://stefan-marr.de/2014/02/how-to-get-a-jit-compiler-for-free-implementing-som-smalltalk-with-rpython-and-truffle/

cheers -ben


>
> On Wed, Oct 11, 2017 at 2:09 PM Nicolai Hess <nicolaihess at gmail.com>
> wrote:
>
>> 2017-10-11 12:14 GMT+02:00 Dimitris Chloupis <kilon.alios at gmail.com>:
>>
>>>
>>> Hey there as it says in the title I am trying to recreat live coding
>>> Pharo chracteristics in Python .
>>>
>>
>> Now I am confused, I thought you already did this? In the other thread
>> you wrote:
>>
>> "From my experience around  100 lines of code are enough to offer most of
>> Pharo’s basic live coding functionality"
>>
>>
>>
>>> One of the issues I have is live replacing of a method to an existing
>>> instance.
>>>
>>
>> And in the other thread you wrote:
>>
>> "Well live coding is a simple process of reloading code. In Pharo the VM
>> recompiles a method and replace it’s old instance with a new one while code
>> executes.
>>
>> Python you basically reload the module. Because Python does not compile
>> per method but per module which means executing code lively. This happens
>> because when you import a module in Python, Python does nothing special
>> than executing the source code. Not before compilation but during
>> execution. Hence live coding, the Python VM replaces objects lively. Python
>> can also compile any size of code including individual methods.
>>
>> That happens with one line of code importlib.reload(mymodule) "
>>
>> So, if python can already reload code and replace the instances, what is
>> missing ?
>>
>>
>>
>>
>>>
>>> I know how to do this in Python but that shown me I would benefit
>>> greatily from a more deeper understanding of Pharo live coding internals
>>> than I have at the moment which is only at the user level. This will help
>>> me avoid common pitfalls in a field that I am not experienced with.
>>>
>>> Have you guys written any paper , article or blog post in this area,
>>> explaining the internals of the VM to that regard ?
>>>
>>> I am also interested in time machine livde coding, meaning live coding
>>> that does not keeps you in the present but also can send you back in the
>>> past restoring the live state of old object instances in a specific time
>>> moment.
>>>
>>
>> I remember a project that developed some tools for back-in-time debugging
>> and testing
>> https://www.hpi.uni-potsdam.de/hirschfeld/trac/
>> SqueakCommunityProjects/wiki/pathToolsFramework
>>
>>
>>>
>>> Generally any guidance on the art of implementing live coding will be
>>> greatly appreciated.
>>>
>>> I don't care how this can be done in Python because I have already
>>> recreated a very basic live coding enviroment in Python and there is a lot
>>> of documentation about Python overall what I am interested only is the
>>> Smalltalk way of doing live coding but from the perspective of the
>>> implementors not the mere users.
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20171011/cd687d96/attachment.html>


More information about the Vm-dev mailing list