Robert Bradshaw, 10.08.2012 23:00:
> We have plenty of non-transitive coercions. E.g. char* <-> object <->
> float.
Python <-> C coercions are not quite the same league as low-level C type
comparisons or coercions, though.
> While it's technically more correct to use signed or unsigned
> char, c
We have plenty of non-transitive coercions. E.g. char* <-> object <->
float. While it's technically more correct to use signed or unsigned
char, char* is pretty ubiquitous in the C world. There's also the
question of the python bytes object and array.array("c") which would
be good to support. And t
I agree. Non-transitive type comparisons seems like very fishy business (it
will be *very* surprising to whoever runs across it); I think there's a strong
case for just breaking backwards compatability:
ERROR: 'char' is illegal as a buffer dtype due to being underspecified in the C
standard, pl
On 10 August 2012 21:27, Bradley M. Froehle wrote:
> I think again this is an instance of the tests being incorrect, rather than
> the code. The failing numpy_tests are all cases where we instantiate a
> buffer of type 'b' (== 'signed char') but then try to use it as if it was a
> 'char'.
Yes, t
I think again this is an instance of the tests being incorrect, rather than the
code. The failing numpy_tests are all cases where we instantiate a buffer of
type 'b' (== 'signed char') but then try to use it as if it was a 'char'.
The fix, of course is to just replace most instances of 'char' w
Robert Bradshaw, 10.08.2012 22:07:
> On Fri, Aug 10, 2012 at 12:31 PM, Robert Bradshaw wrote:
>> On Fri, Aug 10, 2012 at 12:10 PM, Stefan Behnel wrote:
>>> Robert Bradshaw, 10.08.2012 20:54:
OK, the problem boiled down to using 'b' or 'B' for the format string
for char rather than 'c'. Se
On 10 August 2012 19:54, Robert Bradshaw wrote:
> On Fri, Aug 10, 2012 at 9:25 AM, Robert Bradshaw wrote:
>> On Thu, Aug 9, 2012 at 10:04 AM, Stefan Behnel wrote:
>>> mark florisson, 09.08.2012 18:51:
On 9 August 2012 16:36, Stefan Behnel wrote:
> Stefan Behnel, 09.08.2012 14:31:
>>
On Fri, Aug 10, 2012 at 12:31 PM, Robert Bradshaw wrote:
> On Fri, Aug 10, 2012 at 12:10 PM, Stefan Behnel wrote:
>> Robert Bradshaw, 10.08.2012 20:54:
>>> OK, the problem boiled down to using 'b' or 'B' for the format string
>>> for char rather than 'c'. See, e.g.
>>> http://docs.python.org/libr
On Fri, Aug 10, 2012 at 12:10 PM, Stefan Behnel wrote:
> Robert Bradshaw, 10.08.2012 20:54:
>> OK, the problem boiled down to using 'b' or 'B' for the format string
>> for char rather than 'c'. See, e.g.
>> http://docs.python.org/library/array.html . I've pushed a fix at
>> https://github.com/robe
Robert Bradshaw, 10.08.2012 20:54:
> OK, the problem boiled down to using 'b' or 'B' for the format string
> for char rather than 'c'. See, e.g.
> http://docs.python.org/library/array.html . I've pushed a fix at
> https://github.com/robertwb/cython/commit/b0539cbc32c200a09b1fbddf2d6943e92aec2f3e
>
On Fri, Aug 10, 2012 at 9:25 AM, Robert Bradshaw wrote:
> On Thu, Aug 9, 2012 at 10:04 AM, Stefan Behnel wrote:
>> mark florisson, 09.08.2012 18:51:
>>> On 9 August 2012 16:36, Stefan Behnel wrote:
Stefan Behnel, 09.08.2012 14:31:
> mark florisson, 07.08.2012 11:09:
>> I thought the
On Thu, Aug 9, 2012 at 10:04 AM, Stefan Behnel wrote:
> mark florisson, 09.08.2012 18:51:
>> On 9 August 2012 16:36, Stefan Behnel wrote:
>>> Stefan Behnel, 09.08.2012 14:31:
mark florisson, 07.08.2012 11:09:
> I thought the 32 bit issue was resolved? You pushed a fix and I fixed
> so
On 9 August 2012 18:04, Stefan Behnel wrote:
> mark florisson, 09.08.2012 18:51:
>> On 9 August 2012 16:36, Stefan Behnel wrote:
>>> Stefan Behnel, 09.08.2012 14:31:
mark florisson, 07.08.2012 11:09:
> I thought the 32 bit issue was resolved? You pushed a fix and I fixed
> some tests,
On Thu, 09 Aug 2012, Stefan Behnel wrote:
> > Is it bad to release something that doesn't pass the entire test suite
> > on some system?
> Given that we already made tons of releases without even knowing that
> they'd fail on some systems, I'd say no. :)
FWIW -- some time ago 0.15.1 build/passe
FWIW -- just double checked -- tests pass (of current master) just
fine on an i386 Debian system.
On Thu, 09 Aug 2012, Yaroslav Halchenko wrote:
> On Thu, 09 Aug 2012, Stefan Behnel wrote:
> > > I thought the 32 bit issue was resolved? You pushed a fix and I fixed
> > > some tests, so it passed f
mark florisson, 09.08.2012 18:51:
> On 9 August 2012 16:36, Stefan Behnel wrote:
>> Stefan Behnel, 09.08.2012 14:31:
>>> mark florisson, 07.08.2012 11:09:
I thought the 32 bit issue was resolved? You pushed a fix and I fixed
some tests, so it passed for me. I can run it again to check...
On 9 August 2012 16:36, Stefan Behnel wrote:
> Stefan Behnel, 09.08.2012 14:31:
>> mark florisson, 07.08.2012 11:09:
>>> I thought the 32 bit issue was resolved? You pushed a fix and I fixed
>>> some tests, so it passed for me. I can run it again to check...
>>
>> I don't know. Yaroslav replied to
Stefan Behnel, 09.08.2012 14:31:
> mark florisson, 07.08.2012 11:09:
>> I thought the 32 bit issue was resolved? You pushed a fix and I fixed
>> some tests, so it passed for me. I can run it again to check...
>
> I don't know. Yaroslav replied to your mail saying that your fixes didn't
> change an
On Thu, 09 Aug 2012, Stefan Behnel wrote:
> > I thought the 32 bit issue was resolved? You pushed a fix and I fixed
> > some tests, so it passed for me. I can run it again to check...
> I don't know. Yaroslav replied to your mail saying that your fixes didn't
> change anything for the Debian build
mark florisson, 07.08.2012 11:09:
> I thought the 32 bit issue was resolved? You pushed a fix and I fixed
> some tests, so it passed for me. I can run it again to check...
I don't know. Yaroslav replied to your mail saying that your fixes didn't
change anything for the Debian builds. Let's see wha
On 6 August 2012 22:58, Stefan Behnel wrote:
> Hi,
>
> please correct me if I'm missing something, but besides the fused types
> default value thing, I currently see two open issues for 0.17. One is the
> 32bit problem we have in the buffer code, the other one is the "vile hack"
> that Robert adde
Hi,
please correct me if I'm missing something, but besides the fused types
default value thing, I currently see two open issues for 0.17. One is the
32bit problem we have in the buffer code, the other one is the "vile hack"
that Robert added as a type inference fix. I just ran into the following
22 matches
Mail list logo
