An error occurred fetching the project authors.
- 07 Feb, 2016 1 commit
-
-
Jeroen Demeyer authored
-
- 05 Feb, 2016 2 commits
-
-
Robert Bradshaw authored
-
Robert Bradshaw authored
-
- 02 Feb, 2016 1 commit
-
-
Robert Bradshaw authored
-
- 31 Oct, 2015 1 commit
-
-
Robert Bradshaw authored
-
- 26 Oct, 2015 1 commit
-
-
Stefan Behnel authored
-
- 27 Sep, 2015 1 commit
-
-
Stefan Behnel authored
-
- 04 Sep, 2015 1 commit
-
-
Stefan Behnel authored
-
- 08 Aug, 2015 2 commits
-
-
Stefan Behnel authored
prevent non-const char* string literals from being interned
-
Stefan Behnel authored
-
- 07 Aug, 2015 1 commit
-
-
Stefan Behnel authored
-
- 30 Jul, 2015 1 commit
-
-
Robert Bradshaw authored
-
- 28 Jul, 2015 1 commit
-
-
Robert Bradshaw authored
-
- 25 Jul, 2015 3 commits
-
-
Stefan Behnel authored
-
Stefan Behnel authored
-
Stefan Behnel authored
-
- 22 Jul, 2015 1 commit
-
-
Robert Bradshaw authored
Formerly bad code involving unassigned reference temporaries was generated.
-
- 18 Jul, 2015 1 commit
-
-
Robert Bradshaw authored
This not only fixes bugs like auto-conversion of std::map[enum, enum] but also fixes a bug where the compiler-chosen type of int for the enum may not have been long.
-
- 17 Jul, 2015 2 commits
-
-
Stefan Behnel authored
-
Stefan Behnel authored
-
- 16 Jul, 2015 1 commit
-
-
Robert Bradshaw authored
Many C API calls, both from CPython and externally, expect PyTypeObject* for the type argument. A misdeclaration is a warning in C, but an error in C++. The C type of other builtins, such as lists, are not typically required in function signatures, so they are left as PyObject*.
-
- 03 Jul, 2015 2 commits
-
-
Robert Bradshaw authored
This makes type promotion rules clearer.
-
Robert Bradshaw authored
-
- 29 Jun, 2015 1 commit
-
-
Stefan Behnel authored
-
- 28 Jun, 2015 1 commit
-
-
Stefan Behnel authored
-
- 02 Jun, 2015 1 commit
-
-
Robert Bradshaw authored
-
- 01 Jun, 2015 1 commit
-
-
Robert Bradshaw authored
-
- 31 May, 2015 2 commits
-
-
Stefan Behnel authored
avoid antipattern of sum()-ing lists
-
Robert Bradshaw authored
-
- 22 May, 2015 1 commit
-
-
Stefan Behnel authored
-
- 21 May, 2015 1 commit
-
-
Stefan Behnel authored
-
- 26 Apr, 2015 1 commit
-
-
Stefan Behnel authored
-
- 24 Apr, 2015 1 commit
-
-
Stefan Behnel authored
-
- 12 Apr, 2015 1 commit
-
-
Stefan Behnel authored
-
- 23 Feb, 2015 1 commit
-
-
Stefan Behnel authored
-
- 04 Feb, 2015 1 commit
-
-
Robert Bradshaw authored
-
- 17 Jan, 2015 1 commit
-
-
Robert Bradshaw authored
-
- 01 Jan, 2015 1 commit
-
-
Stefan Behnel authored
-
- 29 Dec, 2014 2 commits
-
-
Matthew Johnson authored
object id hashes resulting in duplicate utility code in specialization The CppClassType.specialize() method uses a hash table to avoid re-generating specializations and thus, for example, re-generating utility code: # values is a dict where values are instances of classes in # PyrexTypes.py key = tuple(values.items()) if key in self.specializations: return self.specializations[key] # instantiate new CppClassType, eventually resulting in utility code However, because MemoryViewSliceType used the default (object-id) hash, distinct MemoryViewSliceType instances would ultimately give rise to distinct keys. As a result, code like def test_memviews_same(a,b): cdef vector[double[:]] aa = a cdef vector[double[:]] bb = b would successfully pass through the Cython compiler but then result in a C++ compiler error due to redefinition of utility code: error: redefinition of 'std::vector<__Pyx_memviewslice> __pyx_convert_vector_from_py___Pyx_memviewslice(PyObject*)' To allow the hash table in CppClassType.specialize() to identify 'equal' specializations of CppClassType, we can add __hash__() and __eq__() methods based on the existing MemoryViewSliceType.same_as_resolved_type() method. Other classes in PyrexTypes.py also have __hash__() methods defined and the choices made here appear roughly consistent. This addition allows the above example to compile successfully.
-
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.
-