gmane.comp.python.cython.devel

[Cython] Errors and pipelines (and small bug)

I stumbled over this case which crashes Cython:

http://hg.cython.org/cython-dagss/rev/50ec882441d0

Now, I could just go on and fix it in the switch transform; however I 
believe this is suboptimal...

What happens is that an error is reported during expressino analysis, 
and then life goes on, to code which expects everything to be in order.

So I propose this change: There is a cutoff in the pipeline at which 
stage errors are reported (and if any, processing stops). Any transforms 
after this stage (like those in Optimize.py) can happily assume there 
are no errors in the code.

I can do it in 10 minutes but I wanted some feedback first. (In 
particular, a simpler solution would be to always report only 1 error -- 
this is what Python does, but Cython (and gcc) usually tries to gather 
up more than one error.)

(I'm simply assuming that this is present somewhere in the Pyrex code so 
that one aborts right prior to code generation, so this is really a 
problem with the new pipeline stuff).

--

-- 
Dag Sverre

headers

Greg Ewing | 15 Aug 02:41

Re: [Cython] Errors and pipelines (and small bug)

Dag Sverre Seljebotn wrote:

> So I propose this change: There is a cutoff in the pipeline at which 
> stage errors are reported (and if any, processing stops).

That sounds reasonable. You could even go further and have
a cutoff after every stage of the pipeline, so that any
stage can assume it has valid data from the previous stage.

A refinement would be to have "fatal" and "non-fatal"
errors, where fatal errors terminate compilation at
the end of the current pipeline stage.

--

-- 
Greg

headers

Robert Bradshaw | 15 Aug 03:15

Re: [Cython] Errors and pipelines (and small bug)

On Fri, 15 Aug 2008, Greg Ewing wrote:

> Dag Sverre Seljebotn wrote:
>
>> So I propose this change: There is a cutoff in the pipeline at which
>> stage errors are reported (and if any, processing stops).
>
> That sounds reasonable. You could even go further and have
> a cutoff after every stage of the pipeline, so that any
> stage can assume it has valid data from the previous stage.

Often it is useful to maximimize the number of errors caught in a single 
invocation of the compiler. One thing I hate doing is (run the compiler, 
fix the only reported error) x 10.

> A refinement would be to have "fatal" and "non-fatal"
> errors, where fatal errors terminate compilation at
> the end of the current pipeline stage.

This sounds like a very good idea. Non-fatal errors would result in a 
valid tree that could be carried on to the next stage, but invalid 
compilation.

It might be to hackish, but we could also run each stage in a try-catch, 
and if it catches any Exceptions after a "non-fatal" error it silently 
ignores them.

- Robert

(Continue reading)

headers

Dag Sverre Seljebotn | 15 Aug 10:59

Re: [Cython] Errors and pipelines (and small bug)

Robert Bradshaw wrote:
> On Fri, 15 Aug 2008, Greg Ewing wrote:
>
>> Dag Sverre Seljebotn wrote:
>>
>>> So I propose this change: There is a cutoff in the pipeline at which
>>> stage errors are reported (and if any, processing stops).
>>
>> That sounds reasonable. You could even go further and have
>> a cutoff after every stage of the pipeline, so that any
>> stage can assume it has valid data from the previous stage.
>
> Often it is useful to maximimize the number of errors caught in a single
> invocation of the compiler. One thing I hate doing is (run the compiler,
> fix the only reported error) x 10.
>
>> A refinement would be to have "fatal" and "non-fatal"
>> errors, where fatal errors terminate compilation at
>> the end of the current pipeline stage.
>
> This sounds like a very good idea. Non-fatal errors would result in a
> valid tree that could be carried on to the next stage, but invalid
> compilation.
>
> It might be to hackish, but we could also run each stage in a try-catch,
> and if it catches any Exceptions after a "non-fatal" error it silently
> ignores them.

I already did this  sort of, but non-fatal error might very well
require that processing continues within the transform. The current system

(Continue reading)

headers

Dag Sverre Seljebotn | 15 Aug 14:18

Re: [Cython] Errors and pipelines (and small bug)

Dag Sverre Seljebotn wrote:
> Robert Bradshaw wrote:
>> On Fri, 15 Aug 2008, Greg Ewing wrote:
>>
>>> Dag Sverre Seljebotn wrote:
>>>
>>>> So I propose this change: There is a cutoff in the pipeline at which
>>>> stage errors are reported (and if any, processing stops).
>>> That sounds reasonable. You could even go further and have
>>> a cutoff after every stage of the pipeline, so that any
>>> stage can assume it has valid data from the previous stage.
>> Often it is useful to maximimize the number of errors caught in a single
>> invocation of the compiler. One thing I hate doing is (run the compiler,
>> fix the only reported error) x 10.
>>
>>> A refinement would be to have "fatal" and "non-fatal"
>>> errors, where fatal errors terminate compilation at
>>> the end of the current pipeline stage.
>> This sounds like a very good idea. Non-fatal errors would result in a
>> valid tree that could be carried on to the next stage, but invalid
>> compilation.
>>
>> It might be to hackish, but we could also run each stage in a try-catch,
>> and if it catches any Exceptions after a "non-fatal" error it silently
>> ignores them.
> 
> I already did this  sort of, but non-fatal error might very well
> require that processing continues within the transform. The current system
> is that transforms can raise a CompileError if processing cannot continue,
> or call self.context.nonfatal_error(CompileError(..)) if they just want to

(Continue reading)

headers

Robert Bradshaw | 17 Aug 02:43

Re: [Cython] Errors and pipelines (and small bug)


On Aug 15, 2008, at 5:18 AM, Dag Sverre Seljebotn wrote:

> Dag Sverre Seljebotn wrote:
>> Robert Bradshaw wrote:
>>> On Fri, 15 Aug 2008, Greg Ewing wrote:
>>>
>>>> Dag Sverre Seljebotn wrote:
>>>>
>>>>> So I propose this change: There is a cutoff in the pipeline at  
>>>>> which
>>>>> stage errors are reported (and if any, processing stops).
>>>> That sounds reasonable. You could even go further and have
>>>> a cutoff after every stage of the pipeline, so that any
>>>> stage can assume it has valid data from the previous stage.
>>> Often it is useful to maximimize the number of errors caught in a  
>>> single
>>> invocation of the compiler. One thing I hate doing is (run the  
>>> compiler,
>>> fix the only reported error) x 10.
>>>
>>>> A refinement would be to have "fatal" and "non-fatal"
>>>> errors, where fatal errors terminate compilation at
>>>> the end of the current pipeline stage.
>>> This sounds like a very good idea. Non-fatal errors would result  
>>> in a
>>> valid tree that could be carried on to the next stage, but invalid
>>> compilation.
>>>
>>> It might be to hackish, but we could also run each stage in a try-

(Continue reading)