On Wed, Oct 7, 2009 at 7:07 AM, Charles R Harris <charlesr.har...@gmail.com>wrote:
> > > On Wed, Oct 7, 2009 at 6:59 AM, Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> >> >> On Wed, Oct 7, 2009 at 6:37 AM, David Cournapeau <courn...@gmail.com>wrote: >> >>> On Wed, Oct 7, 2009 at 9:31 PM, Charles R Harris >>> <charlesr.har...@gmail.com> wrote: >>> > >>> > >>> > On Wed, Oct 7, 2009 at 2:06 AM, David Cournapeau <courn...@gmail.com> >>> wrote: >>> >> >>> >> On Wed, Oct 7, 2009 at 2:31 AM, Charles R Harris >>> >> <charlesr.har...@gmail.com> wrote: >>> >> > >>> >> > >>> >> > Looks like a clue ;) >>> >> >>> >> Ok, I fixed it here: >>> >> >>> >> http://github.com/cournape/numpy/tree/fix_abi >>> >> >>> >> But that's an ugly hack. I think we should consider rewriting how we >>> >> generate the API: instead of automatically growing the API array of >>> >> fptr, we should explicitly mark which function name has which index, >>> >> and hardcode it. It would help quite a bit to avoid changing the ABI >>> >> unvoluntary. >>> >> >>> > >>> > I'm thinking the safest thing to do is to move the new type to the end >>> of >>> > the list. >>> >>> That's what the above branch does. >>> >>> > I'm not sure what all the ramifications are for compatibility to >>> > having it stuck in the middle like that, does it change the type >>> numbers for >>> > all the types after? >>> >>> Yes, there is no space left between the types declarations and the >>> first functions. Currently, I just put things at the end manually, but >>> that's really error prone. >>> >>> I am a bit lazy to fix this for real (I was thinking about using a >>> python dict with hardcoded indexes as an entry instead of the current >>> .txt files, but this requires several changes in the code generator, >>> which is already not the greatest code to begin with). >>> >>> >> What I'm concerned about is that, IIRC, types in the c-code can be >> referenced by their index in a list of types and that internal mechanism >> might be exposed to the outside somewhere. That is, what has happened to the >> order of the enumerated types? If that has changed, and if external code >> references a type by a hard-wired number, then there is a problem that goes >> beyond the code generator. The safe(r) thing to do in that case is add the >> new type to the end of the enumerated types and fix the promotion code so it >> doesn't try to rely on a linear order. >> >> > Here, for instance: > > "The various character codes indicating certain types are also part of an > enumerated > list. References to type characters (should they be needed at all) should > always use > these enumerations. The form of them is NPY <NAME>LTR where <NAME>" > > So those macros will generate a hard-coded number at compile time, and > number that might have changed with the addition of the new types. > > Nevermind, it looks like the new type number is at the end as it should be. In [22]: typecodes Out[22]: {'All': '?bhilqpBHILQPfdgFDGSUVOMm', 'AllFloat': 'fdgFDG', 'AllInteger': 'bBhHiIlLqQpP', 'Character': 'c', 'Complex': 'FDG', 'Datetime': 'Mm', 'Float': 'fdg', 'Integer': 'bhilqp', 'UnsignedInteger': 'BHILQP'} Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
