On Fri, Aug 3, 2012 at 8:03 AM, Ondřej Čertík wrote:
> On Mon, Jul 30, 2012 at 5:00 PM, Ronan Lamy wrote:
>> Le lundi 30 juillet 2012 à 11:07 -0700, Ondřej Čertík a écrit :
>>> On Mon, Jul 30, 2012 at 10:04 AM, Ronan Lamy wrote:
>>> > Le lundi 30 juillet 2012 à 17:10 +0100, Ronan Lamy a écrit :
On Mon, Jul 30, 2012 at 5:00 PM, Ronan Lamy wrote:
> Le lundi 30 juillet 2012 à 11:07 -0700, Ondřej Čertík a écrit :
>> On Mon, Jul 30, 2012 at 10:04 AM, Ronan Lamy wrote:
>> > Le lundi 30 juillet 2012 à 17:10 +0100, Ronan Lamy a écrit :
>> >> Le lundi 30 juillet 2012 à 04:57 +0100, Ronan Lamy a
Le lundi 30 juillet 2012 à 11:07 -0700, Ondřej Čertík a écrit :
> On Mon, Jul 30, 2012 at 10:04 AM, Ronan Lamy wrote:
> > Le lundi 30 juillet 2012 à 17:10 +0100, Ronan Lamy a écrit :
> >> Le lundi 30 juillet 2012 à 04:57 +0100, Ronan Lamy a écrit :
> >> > Le lundi 30 juillet 2012 à 02:00 +0100, Ro
On Mon, Jul 30, 2012 at 10:04 AM, Ronan Lamy wrote:
> Le lundi 30 juillet 2012 à 17:10 +0100, Ronan Lamy a écrit :
>> Le lundi 30 juillet 2012 à 04:57 +0100, Ronan Lamy a écrit :
>> > Le lundi 30 juillet 2012 à 02:00 +0100, Ronan Lamy a écrit :
>> >
>> > >
>> > > Anyway, I managed to compile (by b
Le lundi 30 juillet 2012 à 17:10 +0100, Ronan Lamy a écrit :
> Le lundi 30 juillet 2012 à 04:57 +0100, Ronan Lamy a écrit :
> > Le lundi 30 juillet 2012 à 02:00 +0100, Ronan Lamy a écrit :
> >
> > >
> > > Anyway, I managed to compile (by blanking
> > > numpy/distutils/command/__init__.py) and to
Le lundi 30 juillet 2012 à 04:57 +0100, Ronan Lamy a écrit :
> Le lundi 30 juillet 2012 à 02:00 +0100, Ronan Lamy a écrit :
>
> >
> > Anyway, I managed to compile (by blanking
> > numpy/distutils/command/__init__.py) and to run the tests. I only see
> > the 2 pickle errors from your latest gist.
Le lundi 30 juillet 2012 à 02:00 +0100, Ronan Lamy a écrit :
>
> Anyway, I managed to compile (by blanking
> numpy/distutils/command/__init__.py) and to run the tests. I only see
> the 2 pickle errors from your latest gist. So that's all good!
And the cause of these errors is that running the te
Le dimanche 29 juillet 2012 à 14:45 -0700, Ondřej Čertík a écrit :
> Hi Ronan!
>
> On Sun, Jul 29, 2012 at 2:27 PM, Ronan Lamy wrote:
> > Le samedi 28 juillet 2012 à 18:09 -0700, Ondřej Čertík a écrit :
> >
> >>
> >> So now the PR actually seems to work. The rest of the failures are here:
> >>
>
Le dimanche 29 juillet 2012 à 23:55 +0200, Stefan Krah a écrit :
> Ronan Lamy wrote:
> > ImportError: No module named 'distutils.command.install_clib'
>
> I'm seeing the same with Python 3.3.0b1 (68e2690a471d+) and this patch
> solves the problem:
>
> diff --git a/numpy/distutils/command/__init_
Ronan Lamy wrote:
> ImportError: No module named 'distutils.command.install_clib'
I'm seeing the same with Python 3.3.0b1 (68e2690a471d+) and this patch
solves the problem:
diff --git a/numpy/distutils/command/__init__.py
b/numpy/distutils/command/__init__.py
index f8f0884..b9f0d09 100644
--- a
Hi Ronan!
On Sun, Jul 29, 2012 at 2:27 PM, Ronan Lamy wrote:
> Le samedi 28 juillet 2012 à 18:09 -0700, Ondřej Čertík a écrit :
>
>>
>> So now the PR actually seems to work. The rest of the failures are here:
>>
>> https://gist.github.com/3195520
>>
> I wanted to have a look at the import errors
Le samedi 28 juillet 2012 à 18:09 -0700, Ondřej Čertík a écrit :
>
> So now the PR actually seems to work. The rest of the failures are here:
>
> https://gist.github.com/3195520
>
I wanted to have a look at the import errors in your previous gist. How
did you get rid of them? I can't even insta
On Sun, Jul 29, 2012 at 3:40 AM, Stefan Krah wrote:
> Ond??ej ??ert??k wrote:
>> Well, I simply went to the Python sources and then implemented a
>> solution that works with this patch:
>>
>> https://github.com/certik/numpy/commit/36fcd1327746a3d0ad346ce58ffbe00506e27654
>
>> https://github.com/n
Ond??ej ??ert??k wrote:
> > This should be expected since the byte-swapped strings aren't valid.
>
> Exactly, I am aware that my solution is a hack. So is the Python 3.2
> solution, except that Python 3.2 doesn't seem to have
> the _PyUnicode_CheckConsistency() function, so no checks are done.
>
On Sun, Jul 29, 2012 at 6:56 AM, Stefan Krah wrote:
> Ond??ej ??ert??k wrote:
>> https://github.com/numpy/numpy/pull/366
>
> Using Python 3.3 compiled --with-pydebug it appears to be impossible
> to fool the new Unicode implementation with byte-swapped data:
>
>
> Apply the patch from:
>
> http:/
Ond??ej ??ert??k wrote:
> https://github.com/numpy/numpy/pull/366
Using Python 3.3 compiled --with-pydebug it appears to be impossible
to fool the new Unicode implementation with byte-swapped data:
Apply the patch from:
http://projects.scipy.org/numpy/ticket/2193
Then:
Python 3.3.0b1 (defau
Stefan Krah wrote:
> > .python3.3: numpy/core/src/multiarray/common.c:161:
> > PyArray_DTypeFromObjectHelper: Assertion
> > `((PyObject*)(temp))->ob_type))->tp_flags & ((1L<<27))) != 0)' failed.
> > Aborted
>
> This also occurs with Python 3.2, so it's unrelated to the Unicode changes:
>
>
Stefan Krah wrote:
> Then there's another problem in numpy.test() if Python 3.3 is compiled
> --with-pydebug:
>
> .python3.3: numpy/core/src/multiarray/common.c:161:
> PyArray_DTypeFromObjectHelper: Assertion
> `((PyObject*)(temp))->ob_type))->tp_flags & ((1L<<27))) != 0)' failed.
> Aborted
Ond??ej ??ert??k wrote:
> Well, I simply went to the Python sources and then implemented a
> solution that works with this patch:
>
> https://github.com/certik/numpy/commit/36fcd1327746a3d0ad346ce58ffbe00506e27654
> https://github.com/numpy/numpy/pull/366
Nice! I hit the same problem yesterday
Ond??ej ??ert??k wrote:
> Why doesn't PyUnicode_FromKindAndData return a subtype of PyUnicodeObject?
>
> http://docs.python.org/dev/c-api/unicode.html#PyUnicode_FromKindAndData
Well, it would need a PyTypeObject * parameter to do that. I agree that
many C-API functions would be more useful if th
On 7/28/2012 6:17 PM, Christoph Gohlke wrote:
> On 7/28/2012 6:09 PM, Ondřej Čertík wrote:
>> On Sat, Jul 28, 2012 at 5:09 PM, Ondřej Čertík
>> wrote:
>>> On Sat, Jul 28, 2012 at 3:31 PM, Ondřej Čertík
>>> wrote:
On Sat, Jul 28, 2012 at 3:04 PM, Ondřej Čertík
wrote:
> Many of th
On 7/28/2012 6:09 PM, Ondřej Čertík wrote:
> On Sat, Jul 28, 2012 at 5:09 PM, Ondřej Čertík
> wrote:
>> On Sat, Jul 28, 2012 at 3:31 PM, Ondřej Čertík
>> wrote:
>>> On Sat, Jul 28, 2012 at 3:04 PM, Ondřej Čertík
>>> wrote:
Many of the failures in
https://gist.github.com/3194707/5696
On Sat, Jul 28, 2012 at 5:09 PM, Ondřej Čertík wrote:
> On Sat, Jul 28, 2012 at 3:31 PM, Ondřej Čertík
> wrote:
>> On Sat, Jul 28, 2012 at 3:04 PM, Ondřej Čertík
>> wrote:
>>> Many of the failures in
>>> https://gist.github.com/3194707/5696c8d3091b16ba8a9f00a921d512ed02e94d71
>>> are of the ty
On Sat, Jul 28, 2012 at 3:31 PM, Ondřej Čertík wrote:
> On Sat, Jul 28, 2012 at 3:04 PM, Ondřej Čertík
> wrote:
>> Many of the failures in
>> https://gist.github.com/3194707/5696c8d3091b16ba8a9f00a921d512ed02e94d71
>> are of the type:
>>
>> ===
On Sat, Jul 28, 2012 at 3:04 PM, Ondřej Čertík wrote:
> Many of the failures in
> https://gist.github.com/3194707/5696c8d3091b16ba8a9f00a921d512ed02e94d71
> are of the type:
>
> ==
> FAIL: Check byteorder of single-dimensional obj
Many of the failures in
https://gist.github.com/3194707/5696c8d3091b16ba8a9f00a921d512ed02e94d71
are of the type:
==
FAIL: Check byteorder of single-dimensional objects
-
On Sat, Jul 28, 2012 at 11:19 AM, Stefan Krah
wrote:
> Ond??ej ??ert??k wrote:
>> So at some point, the strings get converted to numpy strings in 3.2,
>> but not in 3.3.
>
> PyArray_Scalar() must return a subtype of PyUnicodeObject. I'm boldly
> assuming that data is in utf-32. If so, then this u
Ond??ej ??ert??k wrote:
> So at some point, the strings get converted to numpy strings in 3.2,
> but not in 3.3.
PyArray_Scalar() must return a subtype of PyUnicodeObject. I'm boldly
assuming that data is in utf-32. If so, then this unoptimized version
should work:
diff --git a/numpy/core/src/mu
On Sat, Jul 28, 2012 at 8:04 AM, Ondřej Čertík wrote:
> On Sat, Jul 28, 2012 at 7:58 AM, Ondřej Čertík
> wrote:
> [...]
>> Here is the code in defchararray.py:
>>
>>
>> 1911if not _globalvar and self.dtype.char not in 'SUbc':
>> 1912raise ValueError("Can only create a
On Sat, Jul 28, 2012 at 7:58 AM, Ondřej Čertík wrote:
[...]
> Here is the code in defchararray.py:
>
>
> 1911if not _globalvar and self.dtype.char not in 'SUbc':
> 1912raise ValueError("Can only create a chararray from
> string data.")
> 1913
> 1914def __getitem
Stefan,
On Sat, Jul 28, 2012 at 2:36 AM, Stefan Krah wrote:
> Ond??ej ??ert??k wrote:
>> >> I took a brief look at it, and from the errors I have seen, one is
>> >> cosmetic, the other one is a bit more involved (rewriting
>> >> PyArray_Scalar unicode support). While it is not difficult in natur
Ond??ej ??ert??k wrote:
> >> I took a brief look at it, and from the errors I have seen, one is
> >> cosmetic, the other one is a bit more involved (rewriting
> >> PyArray_Scalar unicode support). While it is not difficult in nature,
> >> the current code has multiple #ifdef of Py_UNICODE_WIDE, me
On Fri, Jul 27, 2012 at 6:47 AM, Ralf Gommers
wrote:
>
>
> On Fri, Jul 27, 2012 at 10:43 AM, David Cournapeau
> wrote:
>>
>> On Fri, Jul 27, 2012 at 9:28 AM, David Cournapeau
>> wrote:
>> > On Fri, Jul 27, 2012 at 7:30 AM, Travis Oliphant
>> > wrote:
>> >> Hey all,
>> >>
>> >> I'm wondering who
On Fri, Jul 27, 2012 at 10:43 AM, David Cournapeau wrote:
> On Fri, Jul 27, 2012 at 9:28 AM, David Cournapeau
> wrote:
> > On Fri, Jul 27, 2012 at 7:30 AM, Travis Oliphant
> wrote:
> >> Hey all,
> >>
> >> I'm wondering who has tried to make NumPy work with Python 3.3. The
> Unicode handling wa
On Fri, Jul 27, 2012 at 9:28 AM, David Cournapeau wrote:
> On Fri, Jul 27, 2012 at 7:30 AM, Travis Oliphant wrote:
>> Hey all,
>>
>> I'm wondering who has tried to make NumPy work with Python 3.3. The
>> Unicode handling was significantly improved in Python 3.3 and the
>> array-scalar code (w
On Fri, Jul 27, 2012 at 9:28 AM, David Cournapeau wrote:
> On Fri, Jul 27, 2012 at 7:30 AM, Travis Oliphant wrote:
>> Hey all,
>>
>> I'm wondering who has tried to make NumPy work with Python 3.3. The
>> Unicode handling was significantly improved in Python 3.3 and the
>> array-scalar code (w
On Fri, Jul 27, 2012 at 7:30 AM, Travis Oliphant wrote:
> Hey all,
>
> I'm wondering who has tried to make NumPy work with Python 3.3. The Unicode
> handling was significantly improved in Python 3.3 and the array-scalar code
> (which assumed a certain structure for UnicodeObjects) is not worki
Hey all,
I'm wondering who has tried to make NumPy work with Python 3.3. The Unicode
handling was significantly improved in Python 3.3 and the array-scalar code
(which assumed a certain structure for UnicodeObjects) is not working now.
It would be nice to get 1.7.0 working with Python 3.3
38 matches
Mail list logo
