[Cython] heads-up on master branch status

[Stefan Behnel]

Hi,

by applying some initially small but perpetually growing fixes, I pushed
myself into a corner where the only escape was to rewrite BoolBinopNode
(short-circuiting and/or expressions). This was long overdue anyway and
simply wasn't done before because it's not trivial and quite risky. I think
I got it working better than before, but there are still corner cases that
require some further fighting. One of them currently crashes the pyregr
tests in Py2.7, it's this code:

[tuple((e is None and 'X' or e) for e in t) for t in target]

Thank you, python-devs, for collecting these little gems in the test suite.
From the C code this generates, the problem seems to be related to type
coercion in closures. I'm currently preparing my participation at
EuroPython next week, so I can't tell for sure when I'll be able to dig
into this. This means that current master may stay less stable than it
should be for a couple of more days.

Stefan

[Robert Bradshaw]

Ironically, I noticed these BoolBinop failures and started working on a fix
myself (including side diversions like making void* the spanning type of
all pointers) before noticing that you were on it, so I have a bit of an
idea what a long, twisty path this starts down and can only say thanks for
taking this on.

- Robert

Post by Stefan Behnel
Hi,
by applying some initially small but perpetually growing fixes, I pushed
myself into a corner where the only escape was to rewrite BoolBinopNode
(short-circuiting and/or expressions). This was long overdue anyway and
simply wasn't done before because it's not trivial and quite risky. I think
I got it working better than before, but there are still corner cases that
require some further fighting. One of them currently crashes the pyregr
[tuple((e is None and 'X' or e) for e in t) for t in target]
Thank you, python-devs, for collecting these little gems in the test suite.
From the C code this generates, the problem seems to be related to type
coercion in closures. I'm currently preparing my participation at
EuroPython next week, so I can't tell for sure when I'll be able to dig
into this. This means that current master may stay less stable than it
should be for a couple of more days.
Stefan
_______________________________________________
cython-devel mailing list
https://mail.python.org/mailman/listinfo/cython-devel

[Stefan Behnel]

Post by Robert Bradshaw

Post by Stefan Behnel
by applying some initially small but perpetually growing fixes, I pushed
myself into a corner where the only escape was to rewrite BoolBinopNode
(short-circuiting and/or expressions). This was long overdue anyway and
simply wasn't done before because it's not trivial and quite risky. I think
I got it working better than before, but there are still corner cases that
require some further fighting. One of them currently crashes the pyregr
tests in Py2.7 [...]

Ironically, I noticed these BoolBinop failures and started working on a fix
myself (including side diversions like making void* the spanning type of
all pointers) before noticing that you were on it, so I have a bit of an
idea what a long, twisty path this starts down and can only say thanks for
taking this on.

It looks like I got all corner cases fixed that I could find anywhere on
Jenkins (and I definitely broke enough builds along the way). That brings
master back to a state where I think we should plan for an alpha release to
get testing on user side as well.

Regarding the void* spanning type, it's currently only used for
independently inferred types for the operands of conditional and and/or
expressions. I don't see a reason not to enable it for all type inference
cases, though. Any objections to that?

Stefan

[Robert Bradshaw]

Post by Stefan Behnel

Post by Robert Bradshaw

Post by Stefan Behnel
by applying some initially small but perpetually growing fixes, I pushed
myself into a corner where the only escape was to rewrite BoolBinopNode
(short-circuiting and/or expressions). This was long overdue anyway and
simply wasn't done before because it's not trivial and quite risky. I

think

Post by Robert Bradshaw

Post by Stefan Behnel
I got it working better than before, but there are still corner cases

that

Post by Robert Bradshaw

Post by Stefan Behnel
require some further fighting. One of them currently crashes the pyregr
tests in Py2.7 [...]

Ironically, I noticed these BoolBinop failures and started working on a

fix

Post by Robert Bradshaw
myself (including side diversions like making void* the spanning type of
all pointers) before noticing that you were on it, so I have a bit of an
idea what a long, twisty path this starts down and can only say thanks

for

Post by Robert Bradshaw
taking this on.

It looks like I got all corner cases fixed that I could find anywhere on
Jenkins (and I definitely broke enough builds along the way). That brings
master back to a state where I think we should plan for an alpha release to
get testing on user side as well.

Sound good. There's a lot of stuff in this release.

Post by Stefan Behnel
Regarding the void* spanning type, it's currently only used for

independently inferred types for the operands of conditional and and/or

Post by Stefan Behnel
expressions. I don't see a reason not to enable it for all type inference
cases, though. Any objections to that?

The other case I could see it coming up is

common = some_int_ptr()
common = some_double_ptr()

Which formerly would be an error.

The C standard prohibits pointer arithmetic with void*, but gcc accepts it
(as if it were a char* IIRC). However, it can't be dereferenced without
casting to another pointer type, so it's not totally unsafe. I think it's
OK to enable everywhere, making things more consistent.

- Robert