1. 29 Dec, 2014 2 commits
    • Matthew Johnson's avatar
      Add MemoryViewSliceType.specialization_name() to include dtype in name · 6460e490
      Matthew Johnson authored
      Calling inherited BaseType.specialization_name() on a
      MemoryViewSliceType generates a name like "Pyx_memviewslice", which
      meant, for example, that generated utility code could have a name like
      
          __pyx_convert_from_py__Pyx_memviewslice
      
      which would collide with utility code generated for other memoryviews
      that might have other base types. That would mean something like
      
          def test_memviews_diff(a,b):
              cdef vector[double[:]] aa = a
              cdef vector[int[:]] bb = b
      
      would first have a compile error (function redefinition due to how
      utility code is currently generated) and second, if only one such
      utility function were emitted instead of one for each memoryview base
      type, have problems with any type-specific generated code, e.g.
      
          // generated inside __Pyx_PyObject_to_MemoryviewSlice,
          // which is called from __pyx_convert_vector_from_py___Pyx_memviewslice
          // note __Pyx_TypeInfo_double
          retcode = __Pyx_ValidateAndInit_memviewslice(axes_specs, 0,
                                                       PyBUF_RECORDS, 1,
                                                       &__Pyx_TypeInfo_double, stack,
                                                       &result, obj);
      
      By adding the dtype tag to the name string returned by
      specialization_name(), distinct utility code functions are generated (at
      least in the case above) and thus there is no name collision.
      6460e490
    • Stefan Behnel's avatar
      db4001fa
  2. 28 Dec, 2014 6 commits
  3. 27 Dec, 2014 11 commits
  4. 26 Dec, 2014 6 commits
  5. 25 Dec, 2014 3 commits
  6. 24 Dec, 2014 1 commit
  7. 23 Dec, 2014 2 commits
  8. 19 Dec, 2014 5 commits
  9. 18 Dec, 2014 1 commit
  10. 17 Dec, 2014 3 commits