RetroSearch Browse

Sat Sep 7 11:06:13 CEST 2013 · https://mail.python.org/pipermail/python-dev/2013-September/128415.html

On Sat, 7 Sep 2013 08:57:07 +0200
Xavier Morel <python-dev at masklinn.net> 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 <jcea at jcea.es> 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.

Regards

Antoine.

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2013-September/128415.html below:

[Python-Dev] DTRACE support