[Vm-dev] Recreating live coding in CPython 3.5

Dimitris Chloupis kilon.alios at gmail.com
Thu Oct 12 08:50:20 UTC 2017


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.

On the last link, I do not know if I understand this correctly at sista
side but at python side yes you can take any string and compile to bytecode
real time and inject that code back to your live execution. If that is what
you mean. Live bytecode compilation can happen at module level too of
course , and a string can be anything from one line of code to a collection
of modules. The cool thing is that you can sandbox the compiling too so you
do not cause any security issues, giving the code access only to a fraction
of your state and code. So yes it gives you a lot of room to move around in
this department but again there is no JIT VM , at least for CPython.

PyPy is a JIT VM for python with Slang like language called rpython that
can be used to port any language and I spoken with some of it authoer and
seem to follow Cog VM vclosely and of coruse expressed admiration of
Eliot's work. Unfortunately PyPy had a long track of issues with python
libraries that wrapped C code so it never get a lot of traction, but its
non the less used by some python coders

If anyone does mind I would like some pointers on the subject of
class enumaration
and reified stack frames
that were mentioned earlier on, I googled them but did not find enough to
clarify what they are in case of Cog VM.


On Thu, Oct 12, 2017 at 12:42 AM Ben Coman <btc at openinworld.com> wrote:

> On Thu, Oct 12, 2017 at 12:38 AM, Dimitris Chloupis <kilon.alios at gmail.com
> > wrote:
>
>>
>> does "become" only exchange references ? Or is it more to it than that ?
>>
>
> https://gbracha.blogspot.com.au/2009/07/miracle-of-become.html
>
> Also interesting reading...
> https://clementbera.wordpress.com/2013/08/09/the-cog-vm-lookup/
>
>
>
>>
>> where I can find information about what insance enumeration and reified
>> stack frames are ?
>>
>
> Lhe last entry here...
> http://www.mirandabanda.org/cogblog/on-line-papers-and-presentations/
>
> Also, does Python do Polymorphic Inline Caching?...
> https://en.wikipedia.org/wiki/Inline_caching
>
> or bytecode level hotspot recompilation...
>
> https://clementbera.wordpress.com/2014/01/09/the-sista-chronicles-i-an-introduction-to-adaptive-recompilation/comment-page-1/
>
> cheers -ben
>
>
>
>>
>> Python has methods in gc module (module for its garbage collector) to
>> find objects that point to an object or objects that an object point to .
>> But it has no convenient method to exchange those references . I assume you
>> could do it via an iteration but I never tried it in practice.
>>
>> Indeed such feature is essential for live coding.  I will have to add it
>> to my implementation thanks.
>>
>> Is this book still relevant for my implementation ?
>> http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf
>>
>>
>> On Wed, Oct 11, 2017 at 6:07 PM Bert Freudenberg <bert at freudenbergs.de>
>> wrote:
>>
>>> On Wed 11. Oct 2017 at 16:27, Dimitris Chloupis <kilon.alios at gmail.com>
>>> wrote:
>>>
>>>>
>>>> I am talking about beyond those obvious features that Python has them
>>>> covered is there anything special the Cog VM is doing live coding wise that
>>>> I am not aware of ?
>>>>
>>>
>>> Instance enumeration, the become operation, and reified stack frames are
>>> features that set Smalltalk apart and enable many of its live coding
>>> capabilities. Cog supports these features. Cog was specifically designed to
>>> allow fast stack operations in the normal case while still allowing frame
>>> manipulation. Spur was designed to make "become" fast, it used to be very
>>> expensive.
>>>
>>> - Bert -
>>>
>>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20171012/03fe0865/attachment.html>


More information about the Vm-dev mailing list