<div dir="ltr"> 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. <div><br></div><div>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. <br><div><br></div><div>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.</div><div><br></div><div>So if you have a method my_instance.my_method(arg1, arg2) </div><div>the statement </div><div>my_instance.my_method </div><div>wont call the method because it does not contain the parenthesses needed for method and function calls</div><div><br></div><div>However it wont throw an error either.</div><div><br></div><div>What will happen is  that like a variable it will return a reference to the method associated. </div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>so basically I would be doing following the previous example </div><div><br></div><div>updated_method = updated_instance.method</div><div>my_instance.my_method=updated_method # now points to updated_instance.method</div><div>my_instace.my_method(arg1,arg2)  #this equals to updated_instance.method(arg1,arg2)</div><div><br></div><div>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. </div><div><br></div><div>Unless we talking here millisecond to microsecond responses ? I have not tested in such speeds</div><div><br></div><div>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 ?</div><div><br></div><div>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. </div><div><br></div><div>What am I missing here ?</div><div><br></div><div><div class="gmail_quote"><div dir="ltr">On Wed, Oct 11, 2017 at 6:02 PM Jecel Assumpcao Jr. <<a href="mailto:jecel@merlintec.com">jecel@merlintec.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Dimitris,<br>
<br>
>  unfortunately no, those articles focus on JIT compilation and<br>
> method lookups and not live coding. <br>
<br>
Actually, these things are at the very core of live coding. Unless we<br>
are using the term in very different ways. So let me explain what I mean<br>
by "live coding".<br>
<br>
Imagine that I have two code browsers showing methods like:<br>
<br>
methA: x<br>
...<br>
 [...] whileTrue: [ self methB ].<br>
...<br>
<br>
and<br>
<br>
methoB<br>
...<br>
...<br>
<br>
<br>
and I have a third window where I am watching the effect of running<br>
#methA. What happens if I change the text in the second window and<br>
select "accept"? What happens if I edit the first window and accept?<br>
<br>
If the system is a simple interpreter and "accept" generated new<br>
bytecodes that get installed in the method dictionary in place of the<br>
previous version of the method, we would expect an instant change in<br>
behavior when changing #methB but nothing would happen when #methA is<br>
modified. That is because #methB is repeatedly called and the current<br>
execution finishes executing using the old code and then it gets invoked<br>
again and starts executing the new code. #methA, on the other hand, is<br>
in the middle of a very long loop and will keep executing the old code<br>
(pointed to from the stack) even though the method dictionary now has<br>
new code.<br>
<br>
An alternative system could use #become: to replace bytecodes when<br>
changing a method, but that would be hard to do (suddenly the stack<br>
state would no longer make sense with the new bytecodes) and would be<br>
harder for the user to understand. So let's not go there.<br>
<br>
If we have a JIT and not a simple interpreter, things can be complicated<br>
if we want to keep the same semantics. The compiler might have inlined<br>
#methB into #methA and in that case changing #methB would no longer have<br>
a visible effect in the third window. The technology to make it work as<br>
expected is called "dynamic deoptimization" and is pretty sophisticated.<br>
<br>
-- Jecel<br>
</blockquote></div></div></div></div>