[Piglit] [PATCH] generated_tests: work around bug in Windows numpy implementation.

[Jose Fonseca]

----- Original Message ----- 

> On 8 September 2011 11:15, Jose Fonseca < jfonseca at vmware.com >
> wrote:

> > I think this is pretty brittle -- who knows when numpy decides to
> > create different type objects.
> 

> > It's better to use numpy dtypes [1] for this. With your example one
> > gets:
> 

> > Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit
> > (Intel)] on
> 

> > win32
> 
> > Type "help", "copyright", "credits" or "license" for more
> > information.
> 
> > >>> import numpy
> 
> > >>> x = numpy.int32(5)
> 
> > >>> y = numpy.abs(x)
> 

> > >>> type(x) == type(y)
> 
> > False
> 
> > >>> x.dtype == y.dtype
> 
> > True
> 
> > >>>
> 

> > That is, the type checking code should use
> 

> > if isinstance(x, numpy.number):
> 
> > if x.dtype == numpy.dtype(numpy.int32)
> 
> > ...
> 

> > ...
> 
> > Jose
> 

> > [1] http://docs.scipy.org/doc/numpy/reference/arrays.dtypes.html
> 

> I'm sorry, Jose. I pushed this patch to Piglit master as soon as I
> got a tested-by from Vinson Lee, which was right around the time you
> sent this email, so I didn't see your comments until after it was
> too late. Normally my rule is to wait one working day between
> receiving a reviewed-by, tested-by, or acked-by, to give others a
> chance to object. But I made an exception in this case because the
> magnitude of the breakage was so severe (Vinson was completely
> unable to build piglit on Windows before this patch). Your comments
> are making me rethink whether I was right to make an exception.

> I suspect that a solution along the lines of what you propose would
> work. I'm not convinced it would be any more or less brittle,
> because I don't really know what is causing this numpy bug in the
> first place, but I bet it would be less ugly than what I did.

> How important is this to you, on a scale from "gee it would be nice
> to do things differently" to "the code is unacceptable as is"? I
> would prefer to leave the patch as it is, mostly because my dev
> environment is Linux, so developing and testing on Windows requires
> me to go home and temporarily repurpose my home machine for Piglit
> development--that takes me a lot of time. But if you would be
> willing to work your dtype idea into a patch and try it on Windows,
> I would be happy to code review it and verify that it doesn't break
> on Linux.

Paul,

This is not a windows specific bug. It looks like numpy creates many identical type objects on all OSes, so type object identity/equality means nothing.

Take for example what "pydoc numpy" outputs on my Linux system:

CLASSES
    __builtin__.object
        broadcast
        dtype
        flatiter
        generic
[...]
            number
[...]
                integer
                    signedinteger
                        int16
                        int16
                        int32
                        int32
                        int64(signedinteger, __builtin__.int)
                        int64(signedinteger, __builtin__.int)
                        int64(signedinteger, __builtin__.int)
                        int64(signedinteger, __builtin__.int)
                        int64(signedinteger, __builtin__.int)
                        int8
                        int8
                    unsignedinteger
                        uint16
                        uint16
                        uint32
                        uint32
                        uint64
                        uint64
                        uint64
                        uint64
                        uint64
                        uint8
                        uint8

You were just lucky on Linux so far, and Windows unlucky, but your luck may change with different numpy versions, and or other systems. Who knows.

I believe such a hanging dagger on the testsuite is not good.

I have windows systems handy. So I'll try to do the proposed change myself as soon as I find the time.

Jose