Hi Brian,
On 23 February 2014 20:14, Brian Kearns wrote:
> I believe all of them in micronumpy are at risk -- any type could be a
> subtype of a record type consisting of something like a single char followed
> by whatever type.
I agree about the ones in the types.py module, but there are more i
I believe all of them in micronumpy are at risk -- any type could be a
subtype of a record type consisting of something like a single char
followed by whatever type.
On Sun, Feb 23, 2014 at 1:43 AM, Armin Rigo wrote:
> Hi Matti,
>
> I've checked in some new code in rawstorage.py on default:
> r
Hi Matti,
I've checked in some new code in rawstorage.py on default:
raw_storage_{get,set}item_unaligned(). It's regular RPython code that
checks if the argument is aligned or not, and if not, it falls back to
a memcpy(). It should be relatively jit-friendly. Note that I also
changed the non-un
Thanks for taking a look.
My immediate goal is to get micronumpy tests passing on ARM.
micronumpy uses raw_storage_getitem, which needs to be fixed. I thought
nonaligned access would be a problem in other parts of pypy, but do not
have the perspective to judge that, so I tried to stick xxx in al
Hi Matti,
On 18 February 2014 14:05, matti picus wrote:
> I would like to ask for help with this branch, as I have not been able to
> move it forward fast enough.
I moved it forward a little bit, but now I'm wondering if it actually
makes sense. What is the goal? Is it to fix a problem in ctyp
I would like to ask for help with this branch, as I have not been able to
move it forward fast enough.
micronumpy tests crash on ARM, due to issues accessing raw memory in struct
arrays. It turn out that casting unaligned memory to a float or double
causes a segfault on ARM, I started to fix this
