On 7 September 2013 19:06, Antoine Pitrou
On Sat, 7 Sep 2013 08:57:07 +0200 Xavier Morel
wrote: On 2013-09-07, at 05:40 , Jesus Cea wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/09/13 20:33, Antoine Pitrou wrote:
On Fri, 06 Sep 2013 18:14:26 +0200 Jesus Cea
wrote: It is intrusive. Yes. I think it must be, by its own nature. Probably room for improvement and code transparency. But... are Python-DEVs interested in the project?. That is the point :)
As a concrete data point: - here are Dave's modifications to ceval.c for systemtap: http://bugs.python.org/review/14776/diff/5177/Python/ceval.c - here are your modifications to ceval.c for dtrace: http://bugs.python.org/review/13405/diff/6151/Python/ceval.c
Unfair, because that code is not doing the same thing.
Most of the extra complexity is there to deal with DTRACE ability to provide meaningful stackframes, with Python code instead of CPython evaluation loop. This is kind of magical.
Antoine will correct me if I'm wrong, but I believe his point is less about the complexity of dtrace provision and more about how much of it lives in ceval.c: the systemtap provision also takes quite a bit of code, but almost all of that code is extracted into a separate file and only a pair of calls live in ceval.c
Yes, that's exactly my point. There can be an arbitrarily complex ceval-dtrace.h for all I care :-)
Thanks for the examples, by the way.
Yep, complex stuff inline should be abstracted out so it doesn't affect the code flow for those of us that don't care :) Between Jesus, the Mac OS X using core devs and the Solaris and Mac OS X buildbots it should be a maintainable addition. However, it seems worthwhile to write up a short PEP (akin to the tracemalloc PEP) to scope out the suggestion. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia