On Fri, Aug 10, 2012 at 8:58 PM, Stefan Behnel wrote:
> Yes, once we know what to make of it, please send a pull request.
I'm happy to do so, though I'm not sure I'd be the best one to do real
refactoring of your docs if you want to go that way.
But just let me know and if I can help out, I'll b
Fernando Perez, 11.08.2012 05:40:
> Question: would you guys be open to including here:
>
> http://docs.cython.org/src/quickstart/build.html
>
> a note about IPython similar to the Sage one?
I think it's either both or none.
> Something like:
>
> """
> Similarly, in IPython (as of version 0.1
Question: would you guys be open to including here:
http://docs.cython.org/src/quickstart/build.html
a note about IPython similar to the Sage one? Something like:
"""
Similarly, in IPython (as of version 0.13) there is also Cython
support that can be used by loading the `cythonmagic` extension.
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
> > IIRC, it parses the gdb version to match against gdb >= 7.2. Something
> > is clearly going wrong, it needs investigation...
FWIW -- I have built 7.2-1 Debian package (obtained from
snapshot.debian.org) under Debian stable squeeze. So I have:
,---
| $> gdb -v
| GNU gdb (GDB) 7.2-debian
| Co
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:
>>
Dimitri Tcaciuc, 09.08.2012 05:40:
> On Tue, Aug 7, 2012 at 12:34 AM, Stefan Behnel wrote:
>> building the documentation currently yields a number of Sphinx warnings:
>>
>> https://sage.math.washington.edu:8091/hudson/job/cython-docs/lastSuccessfulBuild/warnings1Result/
>>
>> It would be nice if so
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, 10 Aug 2012, mark florisson wrote:
> > Is that the expected behaviour? Or is there just something missing in the
> > build server setup, maybe something wrong with the gdb Python plugin? It
> > looks like it's doing something, though...
> IIRC, it parses the gdb version to match against g
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 10 August 2012 05:23, Stefan Behnel wrote:
> Hi,
>
> Yaroslav Halchenko retried the test run on Sparc and all code related bugs
> seem to be resolved now (I had to fix a few minor endianess bugs).
>
> However, the cygdb tests still fail, but do not lead to a test run failure.
>
> Yaroslav Halch
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,
20 matches
Mail list logo
