On Tue, Dec 9, 2008 at 5:24 PM, Mark Dickinson [EMAIL PROTECTED] wrote:
I don't know of any. There are certainly places in the codebase that
assume 56 bits are enough. (I seem to recall it's something like
56 bits for IBM, 53 bits for IEEE 754, 48 for Cray, and 52 or 56 for VAX.)
Quick
A funny thing just happened to me. I tried out causing this error,
just to see how the error message was somehow different, by creating a
time.py in /tmp, and running python from there. Then I removed the
time.py, and went on working.
Two days later, my usage of zc.buildout are broken with a
Hi,
I published a new version of my fault handler: it installs an handler for
signals SIGFPE and SIGSEGV. Using it, it's possible to catch them and
continue the execution of your Python program. Example:
try:
call_evil_code()
except MemoryError:
print A segfault? Haha, I
On Tuesday 09 December 2008, Adam Olsen wrote:
On Tue, Dec 9, 2008 at 11:31 AM, Ulrich Eckhardt
[EMAIL PROTECTED] wrote:
On Monday 08 December 2008, Adam Olsen wrote:
At this point someone suggests we have a type that can store an
arbitrary mix of unicode and bytes, so the undecodable
Nick Coghlan ncoghlan at gmail.com writes:
I don't see anything wrong with the PEP 3118 protocol.
Apart from the fact that:
- it uses something (Py_buffer) which is not a PyObject and has totally
different allocation/lifetime semantics (which makes it non-trivial to adapt to
for anyone used to
Antoine Pitrou wrote:
If the memoryview wasn't holding onto a Py_buffer, one couldn't rely on its
length or anything else because the underlying object could be mutated at any
moment
Hmm, it seems there are two different approaches that could
be taken here to the design of a memoryview
Greg Ewing wrote:
In any case, I think it should be possible to implement
either version without the memoryview having to own
more than one Py_buffer and one set of shape/strides
at a time. Slicing the memoryview creates another
memoryview with its own Py_buffer and shape/strides.
The
On Mon, Dec 8, 2008 at 10:31 PM, Brett Cannon [EMAIL PROTECTED] wrote:
On Mon, Dec 8, 2008 at 18:53, A.M. Kuchling [EMAIL PROTECTED] wrote:
On Sat, Dec 06, 2008 at 02:42:38PM -0800, Brett Cannon wrote:
No, I am saying I had told AMK I was interested in championing the
session. He chose you,
On Tue, 09 Dec 2008 12:15:53 -0500, Steve Holden wrote:
Is anyone aware of any implementations that use other than 64-bit
floating-point? I'd be particularly interested in any that use greater
precision than the usual 56-bit mantissa. Do modern 64-bit systems
implement anything wider than the
Antoine Pitrou wrote:
Hello,
The Py_buffer struct has two pointers named `shape` and `strides`. Each points
to an array of Py_ssize_t values whose length is equal to the number of
dimensions of the buffer object. Unfortunately, the buffer protocol spec doesn't
explain how allocation of these
Lie Ryan wrote:
On Tue, 09 Dec 2008 12:15:53 -0500, Steve Holden wrote:
Is anyone aware of any implementations that use other than 64-bit
floating-point? I'd be particularly interested in any that use greater
precision than the usual 56-bit mantissa. Do modern 64-bit systems
implement
Alexander Belopolsky wrote:
On Mon, Dec 8, 2008 at 6:25 PM, Antoine Pitrou [EMAIL PROTECTED] wrote:
..
Alexander's suggestion of going and looking at what the numpy folks have
done in this area is probably a good idea too.
Well, I'm open to others doing this, but I won't do it myself. My
On Tue, Dec 9, 2008 at 9:48 PM, Lie Ryan [EMAIL PROTECTED] wrote:
Why don't we create a DecimalFloat datatype which is a variable-width
floating point number. Decimal is variable precision fixed-point number,
while the plain ol' float would be system dependent floating point.
Decimal is
Antoine Pitrou wrote:
Alexander Belopolsky alexander.belopolsky at gmail.com writes:
I did not follow numpy development for the last year or more, so I
won't qualify as the numpy folks, but my understanding is that numpy
does exactly what Nick recommended: the viewed object owns shape and
Antoine Pitrou wrote:
Nick Coghlan ncoghlan at gmail.com writes:
For the slicing problem in particular, memoryview is currently trying to
get away with only one Py_buffer object when it needs TWO.
Why should it need two? Why couldn't the embedded Py_buffer fullfill all the
needs of the
Greg Ewing wrote:
Antoine Pitrou wrote:
Why should it need two? Why couldn't the embedded Py_buffer fullfill
all the
needs of the memoryview object?
Two things here:
1) The memoryview should *not* be holding onto a Py_buffer
in between calls to its getitem and setitem methods. It
Nick Coghlan wrote:
Antoine Pitrou wrote:
In all honesty, I admit I am annoyed by all the problems with the buffer API /
memoryview object, many of which are caused by its utterly bizarre design (and
the fact that the design team went missing in action after imposing such a
bizarre and complex
Antoine Pitrou wrote:
Nick Coghlan ncoghlan at gmail.com writes:
I don't see anything wrong with the PEP 3118 protocol.
Apart from the fact that:
- it uses something (Py_buffer) which is not a PyObject and has totally
different allocation/lifetime semantics (which makes it non-trivial to
Greg Ewing wrote:
Nick Coghlan wrote:
Maintaining a PyDict instance to map from view pointers to shapes
and strides info doesn't strike me as a complex scheme though.
I don't see why a given buffer provider should ever need
more than one set of shape/strides arrays at a time. It
can allocate
On Dec 10, 2008, at 5:55 AM, Lennart Regebro wrote:
Turns out, I created an empty time.py in /tmp, just to see the error
message. By buildout will when creating eggs from checked out modules,
copy them to a directory under /tmp, and evidently run python from
/tmp to create the eggs. So that
On Wed, Dec 10, 2008 at 18:49, James Y Knight [EMAIL PROTECTED] wrote:
On Dec 10, 2008, at 5:55 AM, Lennart Regebro wrote:
Turns out, I created an empty time.py in /tmp, just to see the error
message. By buildout will when creating eggs from checked out modules,
copy them to a directory
On Wed, Dec 10, 2008 at 6:49 PM, James Y Knight [EMAIL PROTECTED] wrote:
On Dec 10, 2008, at 5:55 AM, Lennart Regebro wrote:
Turns out, I created an empty time.py in /tmp, just to see the error
message. By buildout will when creating eggs from checked out modules,
copy them to a directory
On Wed, Dec 10, 2008 at 4:06 AM, Victor Stinner
[EMAIL PROTECTED] wrote:
Hi,
I published a new version of my fault handler: it installs an handler for
signals SIGFPE and SIGSEGV. Using it, it's possible to catch them and
continue the execution of your Python program. Example:
This will of
On Wed, Dec 10, 2008 at 3:39 AM, Ulrich Eckhardt
[EMAIL PROTECTED] wrote:
On Tuesday 09 December 2008, Adam Olsen wrote:
The only thing separating this from a bikeshed discussion is that a
bikeshed has many equally good solutions, while we have no good
solutions. Instead we're trying to find
On Wed, Dec 10, 2008 at 12:37 PM, Victor Stinner
[EMAIL PROTECTED] wrote:
Oh, I forgot the issue URL:
http://bugs.python.org/issue3999
I also attached an example of catching segfaults.
I published a new version of my fault handler: it installs an handler for
signals SIGFPE and SIGSEGV.
Benjamin Peterson wrote:
On Wed, Dec 10, 2008 at 12:37 PM, Victor Stinner
This will of course leave the program in an undefined state. It is
very likely to crash again, emit garbage, hang, or otherwise be
useless.
Recover after a segfault is dangerous, but my first goal was to get the
On Wed, Dec 10, 2008 at 12:22 PM, BJörn Lindqvist [EMAIL PROTECTED] wrote:
One thing i think it would be useful for in the real world is for
unittesting extension modules. You cant profitably write unit tests
for segfaults because that breaks the test harness. In situations like
those,
On 2008-12-10 21:05, Adam Olsen wrote:
On Wed, Dec 10, 2008 at 12:22 PM, BJörn Lindqvist [EMAIL PROTECTED] wrote:
One thing i think it would be useful for in the real world is for
unittesting extension modules. You cant profitably write unit tests
for segfaults because that breaks the test
I would appreciate a review, especially for the patch in Python/ceval.c.
In this specific case, it is not clear for what objective you want such
review. For inclusion into Python?
Several people already said (essentially) that: -1. I don't think such
code should be added to the Python core, no
Was there ever a conclusion to this? I need to merge the patches
associated with issue 4597 from trunk to all the maintenance branches,
and I'd like to avoid messing anyone up if possible. If I don't hear
back, I'll plan to svnmerge directly from trunk to each of the
branches, and then block my
On Wed, Dec 10, 2008 at 6:12 PM, Martin v. Löwis [EMAIL PROTECTED] wrote:
I would appreciate a review, especially for the patch in Python/ceval.c.
In this specific case, it is not clear for what objective you want such
review. For inclusion into Python?
Even if it does not result in an
Nick Coghlan wrote:
The multi-dimensional cases get pretty tricky though, since they will
almost always end up dealing with non-contiguous data. The PEP 3118
protocol is up to handling the task, but the implementation of the index
mapping to handle these multi-dimensional cases is highly
Antoine Pitrou wrote:
- it uses something (Py_buffer) which is not a PyObject and has totally
different allocation/lifetime semantics
This was a deliberate decision -- in fact I argued for it myself.
The buffer interface is meant to be a minimal-overhead way for
C code to get at the
Jeffrey Yasskin wrote:
Was there ever a conclusion to this? I need to merge the patches
associated with issue 4597 from trunk to all the maintenance branches,
and I'd like to avoid messing anyone up if possible. If I don't hear
back, I'll plan to svnmerge directly from trunk to each of the
On Wed, Dec 10, 2008 at 5:21 PM, Alexander Belopolsky
[EMAIL PROTECTED] wrote:
On Wed, Dec 10, 2008 at 6:12 PM, Martin v. Löwis [EMAIL PROTECTED] wrote:
Several people already said (essentially) that: -1. I don't think such
code should be added to the Python core, no matter how smart or correct
On Wed, Dec 10, 2008 at 8:01 PM, Adam Olsen [EMAIL PROTECTED] wrote:
..
It is impossible to do in general, and I am -1 on any misguided
attempts to do so.
I agree, recovering from segfaults caused by buggy third party C
modules is a losing proposition, but for a limited number of
conditions
On Wed, Dec 10, 2008 at 8:37 PM, Victor Stinner
[EMAIL PROTECTED] wrote:
Recover after a segfault is dangerous, but my first goal was to get the Python
backtrace instead just one line: Segmentation fault. It helps a lot for
debug!
This would be extremely useful. I've had PyGTK segfault on me a
37 matches
Mail list logo
