<div dir="ltr">The problem in my case is that I do not build a VM from scratch neither I am modifying an existing VM <div><br></div><div>For me it boils down to </div><div><br></div><div>1) What is this in Smalltalk ?</div><div>2) Can Python do this ?</div><div>3) Can I make it easier without spending too much time and compromising ?</div><div><br></div><div>Python has its own stack frames, they are object too, not native stack frames (they may reference native stack frames though) and if I am not mistaken because unlike my previous statements I have not messed at all with them, they also come with their own context which includes local variables etc </div><div><br></div><div><a href="https://stackoverflow.com/questions/38937721/global-frame-vs-stack-frame">https://stackoverflow.com/questions/38937721/global-frame-vs-stack-frame</a><br></div><div><a href="https://docs.python.org/3/library/inspect.html">https://docs.python.org/3/library/inspect.html</a><br></div><div><a href="https://docs.python.org/3/library/traceback.html">https://docs.python.org/3/library/traceback.html</a><br></div><div><br></div><div>I can make to a degree such claims because anything I test live coding wise in python I do it from debugger. The Python debugger is called PDB as you would expect and it works from the terminal , beyond coming with its own commands and can do repl suff it also comes with an instance of Python REPL which of course gives you complete freedom in doing what you would do in source code file. This is how I hack objects removing and adding methods to them , mess with local variables etc. talking about live instance objects etc. </div><div><br></div><div>Of course I have to copy the code manually back to the source file , maybe there is a way around this as well or some feature I am not aware of, but the code fragments are usually small so its not a major problem for now. LiveCoding wise, besides the fact that indeed some things do not happen automagically as you would expect in Pharo still the debugger has not stopped me from doing anything live coding wise. </div><div><br></div><div>My only big frustration so far has been the fact that classes do not keep a list of their instances, but that is also easy to amend for my own classes adding their instances when it is created in class variable list or dictionary. Technically you can still get all references to an object (via gc module coming included with python) and ask each one if it is an instance of a class , still I think thats a big flaw and introduces extra works that should not happen when Python already tackles far more complex tasks of live coding. </div><div><br></div><div>But that's your usual language I guess, there is always something to annoy you. </div><div><br></div><div>In any case, I am not dismissing anything and of course I will read and delve deeper live coding related or not, so thanks for any help you guys give even if I do not need it. I may not need it now , but I may need it later on, so learning is always worth it.   But I am also careful not to recreate Python functionality because a) I will be wasting my time b) I will be ignoring Python's native design that can create incompatibilities down the road. </div><div><br></div><div>So gain a good understanding from both sides Cog VM and Python library (so far I had no need to seek information about Python VM because the functionality I want may not be completely automated but is non the less available as a library part of the standard distribution)</div><div><br></div><div>So the deeper I get , of course I expect to get more complex, obviously for now I want to keep it simple and then move step by step to something more sophisticated. But yes I have read the material, not extensively but I did gave it a fast read and I will re read again and I will be also reading the Bluebook. </div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 12, 2017 at 12:58 PM Nicolai Hess <<a href="mailto:nicolaihess@gmail.com">nicolaihess@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2017-10-12 10:50 GMT+02:00 Dimitris Chloupis <span dir="ltr"><<a href="mailto:kilon.alios@gmail.com" target="_blank">kilon.alios@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div dir="ltr">Thanks Ben actually your first link was the first thing I read when I googled become. I dont think VM lookup benefits me in my case as this is already handled by the Python VM. <div><br></div><div>You other tlinks are JIT VM related, Python is not friendly to JIT because its creator believe that performance enhancement should come from wrapping C libraries and wants to avoid the cost of more complex VM . In the case of Python this is easy to follow because Python has a ton of high performance libraries which by the way almost never are used when comparing Python with other languages speed wise (kinda fare if you just compare language implementations). Pharo does benefit a lot more from JIT VM as it does not have as many libraries targeting high performance. </div><br></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The interesting parts in this "JIT VM related" links is, if you happen to write a JIT VM , you have to take care of the language features smalltalk provides. For example, you can not just optimize away<br></div><div>smalltalks context chain by replacing it with native stack frames, without losing the features a smallalltak method context provides on the language level.<br></div><div>This language features are already explained very well in the blue book, but the links about the cog vm and other vm and jit vm papers for dynamic langueges are helpful too.<br><br></div><div>I don't know which language features (late bindng, method lookup , thisContext / execution context, become operation, etc) are *necessary* to provide the "smalltalk art of live coding".<br></div><div>Or to what extent this features exists in other language. But it is one reason why it is "easy" to build within smalltalk itself this smalltalk environment (edit / compile/ run / debug smallalk code from within a running smalltalk environment).<br></div><div><br><br><br></div></div></div></div>
</blockquote></div>