On Wednesday, May 4, 2011 3:06:40 PM UTC-7, robertwb wrote:
>
> On Wed, May 4, 2011 at 3:05 PM, Robert Bradshaw
> wrote:
> > On Wed, May 4, 2011 at 2:16 PM, Jeroen Demeyer
> wrote:
> >> On 2011-05-04 23:06, Robert Bradshaw wrote:
> >>> Are you returning a non-python object in a cdef method wit
On Wed, May 4, 2011 at 3:05 PM, Robert Bradshaw
wrote:
> On Wed, May 4, 2011 at 2:16 PM, Jeroen Demeyer wrote:
>> On 2011-05-04 23:06, Robert Bradshaw wrote:
>>> Are you returning a non-python object in a cdef method without an
>>> "except" signature?
>> This is not the issue.
>>
>> I think that
On Wed, May 4, 2011 at 2:16 PM, Jeroen Demeyer wrote:
> On 2011-05-04 23:06, Robert Bradshaw wrote:
>> Are you returning a non-python object in a cdef method without an
>> "except" signature?
> This is not the issue.
>
> I think that *somewhere* in Sage a KeyboardInterrupt exception is caught
> by
On 2011-05-04 23:06, Robert Bradshaw wrote:
> Are you returning a non-python object in a cdef method without an
> "except" signature?
This is not the issue.
I think that *somewhere* in Sage a KeyboardInterrupt exception is caught
by an "except:" (i.e. except everything) and I want to know where.
Are you returning a non-python object in a cdef method without an
"except" signature? (In this case, it should be printing where the
exception was unable to be propagated.) Turning on profiling is
another way to get call stacks.
On Wed, May 4, 2011 at 11:53 AM, Jeroen Demeyer wrote:
> Hello all,
Hello all,
I would be *very happy* if somebody can tell me a way of debugging
exceptions in Python and Cython. I would like to know when exceptions
are raised and where they are caught during a Sage run.
In particular, there is an instance where I explicitly raise an
exception (in Cython code) bu
