On Wed, Nov 12, 2008 at 9:31 PM, Skip Montanaro <report@bugs.python.org> wrote:
> I see the reference to Apple in your original post, but can't find anything
> related to dtrace & python starting from the URL you gave.  Do you have
> something more specific?

http://www.opensource.apple.com/darwinsource/10.5.5/python-30.1.2/

That isn't Python 3.0, that's what I guess they call Python "Apple
Version 30"?  Anyways, it's their Python 2.5.1 and their "patches"
against it are actually ed scripts, contained in fix/

That's where my patch comes from, it's just changing the .ed scripts
to a patch and applying it against 2.6

> At this point Jeff's code does a fair bit more than simply tracing the
> CALL_FUNCTION opcode but needs some work with the other CALL_FUNCTION_*
> opodes.  It also has some obmalloc tracing which I've not yet tested.  I
> would have thought Apple would more heavily instrument the interpreter than
> it appears they have.

Sun has released a patch against DTrace that probes more than just
function calls also.  At least, it provides line number and some other
information, http://cvs.opensolaris.org/source/xref//jds/spec-files/trunk/patches/Python-07-dtrace.diff

I couldn't figure out why it broke the compile on OS X though, and
could only get it working on Solaris.

There's another problem (I think) with DTrace probes ... if the Apple
guys release Apple-Probe-Python.d and the Sun guys release
Sun-Probe-Python.d (just two scripts) and we setup our probes
differently, one or both will fail (because one may expect a probe for
foo while another expects a probe for bar).  Kind of sucks,
considering Sun was first and Apple chose to probe Python differently.
 Now we have to pick one or make a 3rd... I could be very mistaken
here, though.