[Vm-dev] Recreating live coding in CPython 3.5

Dimitris Chloupis kilon.alios at gmail.com
Thu Oct 12 11:49:41 UTC 2017

The problem in my case is that I do not build a VM from scratch neither I
am modifying an existing VM

For me it boils down to

1) What is this in Smalltalk ?
2) Can Python do this ?
3) Can I make it easier without spending too much time and compromising ?

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


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

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.

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.

But that's your usual language I guess, there is always something to annoy

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.

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)

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

On Thu, Oct 12, 2017 at 12:58 PM Nicolai Hess <nicolaihess at gmail.com> wrote:

> 2017-10-12 10:50 GMT+02:00 Dimitris Chloupis <kilon.alios at gmail.com>:
>> 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.
>> 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.
> 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
> smalltalks context chain by replacing it with native stack frames, without
> losing the features a smallalltak method context provides on the language
> level.
> 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.
> 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".
> 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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20171012/2f27ea1d/attachment-0001.html>

More information about the Vm-dev mailing list