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 o
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
condition
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
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
Greg Ewing canterbury.ac.nz> writes:
>
> 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 underlying data. Requiring allocation of
> a PyObject would be too expensive.
Tuples are used everywh
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 underlying
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 non-tri
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
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 mer
Travis Oliphant wrote:
When a slice view is made, a new memoryview object is created with a
Py_buffer structure that needs to allocate it's own shape and strides
(or something that will allow correct shape and strides to be reported
to any consumer). In this way, there are two Py_buffer stru
> 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
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
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, re
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, recovering would be likely (caveat emptor of course).
2008/12/10, Adam Olsen <[EMAIL
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 Python
On Wed, Dec 10, 2008 at 11:37 AM, 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 a
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 a
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. Using it, it's possible to catch them and
> > continue the execution of y
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
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
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 di
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 dire
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 pro
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
Antoine Pitrou wrote:
Nick Coghlan 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 an
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 d
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
Antoine Pitrou wrote:
Nick Coghlan 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 memoryview object
Antoine Pitrou wrote:
Alexander Belopolsky 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
strides just as it owns th
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 *a
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 inte
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
>> implem
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 arr
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
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 c
Nick Coghlan 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 the rest
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 im
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 design on us), 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 don'
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 "modu
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 c
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 und
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 object.
43 matches
Mail list logo