[issue13405] Add DTrace probes
Changes by Robert Kern robert.k...@gmail.com: -- nosy: -robert.kern ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13405 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11673] RawArray does not accept long
New submission from Robert Kern robert.k...@gmail.com: The constructor for multiprocessing.RawArray() takes an argument that is either an integer size or a sequence to initialize the contents. To determine if the argument is a size, it uses isinstance(x, int). This means that integers that happen to be Python longs cause an error. On Win64 systems, Python ints are still 32-bits, so valid sizes for arrays sometimes must be represented by Python longs. Attached is a patch that uses operator.index() to determine if the object can be used as an integer size. -- components: Library (Lib) files: raw-array-long.diff keywords: patch messages: 132144 nosy: Robert.Kern priority: normal severity: normal status: open title: RawArray does not accept long type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file21396/raw-array-long.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11673 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11673] RawArray does not accept long
Robert Kern robert.k...@gmail.com added the comment: The practical case I was thinking of was numpy integer scalar types, which can crop up without explicitly requesting them, much like the long type. Although, now that I check, I see that single-element numpy arrays also pass index(). Ideally, there would be two functions, one that takes sizes and one that takes sequences, much like numpy has array() and empty(). I can revert my patch to doing the isinstance(x, (int, long)) test as a quick fix. That will allow most of the numpy scalar types that I expect will actually be encountered. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11673 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11673] RawArray does not accept long
Robert Kern robert.k...@gmail.com added the comment: numpy.int is just an alias to the builtin int, left for historical reasons. The integer scalar type that has the same width as Python's int (numpy.int32 or numpy.int64, depending) will always pass the isinstance() check. Since it's the default integer type in numpy arrays, it will be the most frequently encountered. Thanks! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11673 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8221] 2to3 mishandles StringIO inside a package with an io.py module
New submission from Robert Kern robert.k...@gmail.com: When a module inside a package imports StringIO from cStringIO, it should change that to from io import StringIO. However, if there is a module inside the package named io.py, 2to3 changes it to from .io import StringIO. [bug23]$ tree . `-- package |-- __init__.py |-- helper.py `-- io.py 1 directory, 3 files [bug23]$ cat package/helper.py from cStringIO import StringIO [bug23]$ 2to3 package RefactoringTool: Skipping implicit fixer: buffer RefactoringTool: Skipping implicit fixer: idioms RefactoringTool: Skipping implicit fixer: set_literal RefactoringTool: Skipping implicit fixer: ws_comma --- package/helper.py (original) +++ package/helper.py (refactored) @@ -1,1 +1,1 @@ -from cStringIO import StringIO +from .io import StringIO RefactoringTool: Files that need to be modified: RefactoringTool: package/helper.py -- components: 2to3 (2.x to 3.0 conversion tool) messages: 101636 nosy: Robert.Kern severity: normal status: open title: 2to3 mishandles StringIO inside a package with an io.py module versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8221 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6798] Argument for sys.settrace() callbacks documented incorrectly
New submission from Robert Kern robert.k...@gmail.com: The final 'arg' argument of the sys.settrace() callback is documented to be None for the 'c_return' and 'c_exception' events, but it appears to be the function object itself. Additionally, the 'return' event's argument may be None if the 'return' event is being generated because of an exception. These errors also exist in the Py_tracefunc documentation in the C API. The latter error is not particularly important for the Python API, but in the C API the argument may be a NULL pointer. I am happy to make the corrections if someone will confirm that my analysis is correct. -- assignee: georg.brandl components: Documentation messages: 92050 nosy: georg.brandl, robert.kern severity: normal status: open title: Argument for sys.settrace() callbacks documented incorrectly type: behavior versions: Python 2.5, Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6798 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Robert Kern robert.k...@gmail.com added the comment: Ah, I misread the Apple function-return probe code. Its extra argument is the type name of the return object or error if an exception was raised, not the returned object itself. Could be useful. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Robert Kern robert.k...@gmail.com added the comment: Is there any interest in my expanding the list of probes? Ruby has quite a few more than function-entry and function-return, to give some examples of what is possible: http://dev.joyent.com/projects/ruby-dtrace/wiki/Ruby+DTrace+probes+and+arguments I think that adding probes that correspond to PyTrace_LINE and PyTrace_EXCEPTION would be straightforward and worthwhile. PyTrace_C_* may also be worthwhile, but you can probably accomplish similar things with the normal pid probes if you know the C function names (although something like printing the name of a raised exception will probably require a dedicated probe). Adding probes to replicate what the LLTRACE configuration option did, but dynamically, might be interesting. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Robert Kern robert.k...@gmail.com added the comment: We could probably merge Apple's and Sun's probes without too much trouble. Apple simply extended function-entry to include the argcount in addition to Sun's (filename, funcname, lineno) arguments. We could use Apple's probe while retaining compatibility with Sun-oriented DTrace scripts already in existence. The two different function-returns are a bit of a problem. I recommend starting with Sun's argument list because there are already a number of quite useful scripts that use it in the DTraceToolkit. We could extend Sun's argument list to add the *object pointer, but I don't actually know of a use case. I haven't seen a script in the wild that uses it. It seems like it would be tricky to write something in a DTrace script that could make much use of it besides printing out the address. Maybe you could navigate your way down to the type name, but that might be unreliable. I suggest adding the *object pointer argument only if we can devise a use case or if one of the Apple folks pop up with one. I don't feel too bad making Apple devs modify a single character from their internal scripts if they don't make them public. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Robert Kern robert.k...@gmail.com added the comment: James McIlree from Apple has informed me on dtrace-discuss that ustack helpers cannot currently be built on OS X. Bummer. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Robert Kern robert.k...@gmail.com added the comment: Skip, it doesn't appear that the ustack helper is getting incorporated into the OS X build anywhere. This rule is obviously wrong (compiling the wrong input file with the wrong flags): Include/phelper.h: $(srcdir)/Include/phelper.d dtrace -o $@ $(DFLAGS) -C -h -s $(srcdir)/Python/python.d I *think* it should be something along these lines: Include/phelper.h: $(srcdir)/Include/phelper.d dtrace -o $@ -DPHELPER $(DFLAGS) $(CPPFLAGS) -C -h -s $(srcdir)/Include/phelper.d There are some static functions in the standard system headers that get pulled in that need to be avoided. The #define _SYS_STAT_H up at the top avoids similar problems on Solaris. I'm working through the OS X headers now, but I'm stuck on trying to avoid sys/_structs.h. Unfortunately, it does not have the #ifndef _SYS__STRUCTS_H magic up at the top that would allow me to do so, nor any convenient #ifdefs around the offending declaration. sigh Even if that would work, phelper.h is not #included anywhere. I'm not really sure where it needs to go. On Solaris, the object file gets linked in, but on OS X, you don't generate an object file; you just #include the .h. Somewhere. I'm guessing where the pydtrace.h is currently, but I don't really know. John, do you have any insights? Also, s/DTRADEHDRS/DTRACEHDRS/ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Robert Kern robert.k...@gmail.com added the comment: Got a bit farther. Adding this stanza to the top of phelper.d gets past the issues in the headers: #ifdef __APPLE__ #define _SYS_TIME_H_ #define _SYS_SELECT_H_ #define __MATH_H__ #define _OS__OSBYTEORDER_H #define _FD_SET #define __GNUC_VA_LIST #endif /* __APPLE__ */ However, I now get a more legitimate dtrace compilation error that John might be able to help us interpret: $ dtrace -o /Users/rkern/hg/Python-2.5.4/Include/phelper.h -DPHELPER -I. -IInclude -I/Users/rkern/hg/Python-2.5.4/Include -C -h -s /Users/rkern/hg/Python-2.5.4/Include/phelper.d dtrace: failed to compile script /Users/rkern/hg/Python-2.5.4/Include/phelper.d: line 110: relocation remains against user symbol D``PyEval_EvalFrameEx (offset 0x5) I also tried running this without -DPHELPER as a regular DTrace script rather than a ustack helper and ran into a problem that I've noticed with any OS X Python build I've tried. I cannot seem to probe any of the C functions in the Python interpreter. There are no simply pid$target:a.out:: probes available. I'm wondering if that is an effect of their being in a .framework, but I think I've been able to probe other symbols other .frameworks. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Robert Kern robert.k...@gmail.com added the comment: This is on an Intel Core 2 Duo running OS X 10.5.6. __i386 is defined. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Robert Kern robert.k...@gmail.com added the comment: John, -Z does not appear to help: $ sudo dtrace -Z -n 'pid$target::PyEval_EvalFrameEx:entry' -c python dtrace: description 'pid$target::PyEval_EvalFrameEx:entry' matched 0 probes I'm not sure how that would help. If I'm reading the man page correctly, that just let's dtrace continue on even when the probe specifiers do not match anything. It still doesn't let me probe these functions. The only modification I made to phelper.d was to add the stanza of #defines given a few messages up. The failing line expands in the C preprocessor to this line (expanding at_evalframe(), then startframe and endframe): dtrace:helper:ustack: /((uintptr_t)arg0 = ((uintptr_t)``PyEval_EvalFrameEx) (uintptr_t)arg0 ( (uintptr_t)``PyEval_EvalCodeEx))/ This is based on the phelper.d in dtrace.diff attached to this ticket by Skip. It is the same (modulo my #defines) as the phelper.d in Python26-07-dtrace.diff from OpenSolaris as linked by Ted. Hmm, I am applying this to Python 2.5.4, though. Perhaps I need to go back to the Python25-07-dtrace.diff, which does appear to use PyEval_EvalFrame. PyEval_EvalFrameEx is in Python 2.5, so I thought I would try the latest and greatest. If I were to process it with dtrace -h, do you think that I could name it as a .c and compile it into an object file with gcc? Or does dtrace -G do significantly more stuff behind the scenes to generate its object file? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Robert Kern robert.k...@gmail.com added the comment: Skip Perhaps not quite on-topic for this tracker item, but it bugs me that the Skip mere compilation of a D script requires root privileges. It doesn't. dtrace -G and dtrace -h (the only mere compilation that dtrace does) run without root privileges. That line you quoted was actually probing a process and thus needed root privileges. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Robert Kern robert.k...@gmail.com added the comment: Ah, duh, of course. The problem here with PyEval_EvalFrameEx is that I don't have ceval.o on the command line *at all* since OS X's dtrace doesn't support -G. It doesn't appear to accept ceval.o with -h, either, so I suppose that adding the ustack helper may simply be impossible unless Apple adds the -G flag. Thanks for you help John. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Robert Kern robert.k...@gmail.com added the comment: Hmm, wait a second. Never mind. The Solaris patches don't have ceval.o on the line for compiling phelper.o, either. If dtrace needs to resolve the symbol PyEval_EvalFrameEx in an object file, how does it know to look in ceval.o for the phelper.d? WITH_DTRACE is defined in ceval.c and PyEval_EvalFrameEx is in ceval.o, but I don't understand how that relates to compiling phelper.d. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3976] pprint._safe_repr is not general enough in one instance
Changes by Robert Kern robert.k...@gmail.com: -- nosy: +robert.kern ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3976 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
