[Vm-dev] Recreating live coding in CPython 3.5

[Dimitris Chloupis]

 Jecel ,  you hit a head on the issues I want to tackle, this exactly the
concept I want to understand to implement an efficient live coding
enviroment so thank you.

Before starting excuse any misunderstanding I am very fresh into the whole
idea of live coding implementation so I may not understand the specific you
mention.

Now the way I understand this in Python its possible to keep around both
the old and new instance , if a method is replaced what happens is that
Python treats methods a bit like variables, again I am not talking VM I
know nothing about Python VM internals. This is purely python code.

So if you have a method my_instance.my_method(arg1, arg2)
the statement
my_instance.my_method
wont call the method because it does not contain the parenthesses needed
for method and function calls

However it wont throw an error either.

What will happen is  that like a variable it will return a reference to the
method associated.
That method is a separate object. Of type MethodObject which has a function
__CALL__ which is doing the work of parentheses and of course it has
instance variables for arguments, classes that is bound to etc.

So if I do what you say and change methodB and inject the updated version
of methodB which basically will be its new instance containing the modified
code in bytecode format to the place of old instance, i will be replacing a
reference and as such the 'variable' now will reference another method . so
Any call that will now be issues will be sent directly to the updated
version of the method.

so basically I would be doing following the previous example

updated_method = updated_instance.method
my_instance.my_method=updated_method # now points to updated_instance.method
my_instace.my_method(arg1,arg2)  #this equals to
updated_instance.method(arg1,arg2)

It wont matter if its a long loop , as matter of fact I am working on a
loop right now doing these experiment because the Python I use is in
Blender (3d app)  running concurent with many other stuff sometimes GBs of
data etc etc.

Unless we talking here millisecond to microsecond responses ? I have not
tested in such speeds

Do I understand you correctly or I miss something here. Why you need a JIT
to do this ? I see that pharo has CompiledMethod so methods also in pharo
are objects that means they are also referenced not tied to the object
instances , right ? Should not this work outside the box ?

So in my scenario of live replacing methods you should see the results
immediately , meaning as soon as the method is called again and both
editors will have to display the same exact code if they view the same
method. All calls are essentialy done via reference.

What am I missing here ?

On Wed, Oct 11, 2017 at 6:02 PM Jecel Assumpcao Jr. <jecel at merlintec.com>
wrote:

>
> Dimitris,
>
> >  unfortunately no, those articles focus on JIT compilation and
> > method lookups and not live coding.
>
> Actually, these things are at the very core of live coding. Unless we
> are using the term in very different ways. So let me explain what I mean
> by "live coding".
>
> Imagine that I have two code browsers showing methods like:
>
> methA: x
> ...
>  [...] whileTrue: [ self methB ].
> ...
>
> and
>
> methoB
> ...
> ...
>
>
> and I have a third window where I am watching the effect of running
> #methA. What happens if I change the text in the second window and
> select "accept"? What happens if I edit the first window and accept?
>
> If the system is a simple interpreter and "accept" generated new
> bytecodes that get installed in the method dictionary in place of the
> previous version of the method, we would expect an instant change in
> behavior when changing #methB but nothing would happen when #methA is
> modified. That is because #methB is repeatedly called and the current
> execution finishes executing using the old code and then it gets invoked
> again and starts executing the new code. #methA, on the other hand, is
> in the middle of a very long loop and will keep executing the old code
> (pointed to from the stack) even though the method dictionary now has
> new code.
>
> An alternative system could use #become: to replace bytecodes when
> changing a method, but that would be hard to do (suddenly the stack
> state would no longer make sense with the new bytecodes) and would be
> harder for the user to understand. So let's not go there.
>
> If we have a JIT and not a simple interpreter, things can be complicated
> if we want to keep the same semantics. The compiler might have inlined
> #methB into #methA and in that case changing #methB would no longer have
> a visible effect in the third window. The technology to make it work as
> expected is called "dynamic deoptimization" and is pretty sophisticated.
>
> -- Jecel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20171011/f9ca3a1d/attachment-0001.html>