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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
18 matches
Mail list logo
