
Re: ucnhash and where the stuff gets tested Doesn't matter to me where the test goes. WRT how big it is, thats why its dynamically loaded at run time. If you don't compile it at all, then the \N{...} syntax just won't owrk. Re: static vs. staticforward I can actually do a patch for that, and regen ucnhash.c for you. Re: "" vs. <> Whats wrong with what I'm currently doing? All of the .h files I'm including are on the include file path. "" usage just means stick "." before everything else in your include path. None of the files need that. :) If there's a diffferent policy in the Python source 'bout that that I'm not aware of, then I can fix that issue too. Bill

Bill Tutt wrote:
Re: ucnhash and where the stuff gets tested
Doesn't matter to me where the test goes.
I'm currently trying to check these changes in... doesn't work though due to some obscure CVS locks.
WRT how big it is, thats why its dynamically loaded at run time. If you don't compile it at all, then the \N{...} syntax just won't owrk.
Re: static vs. staticforward I can actually do a patch for that, and regen ucnhash.c for you.
Someone (Fred ?) already patches those places for you. He didn't send patches for the perfect hash tool though.
Re: "" vs. <> Whats wrong with what I'm currently doing?
<> uses a differnt header file lookup path... normally doesn't hurt, but...
All of the .h files I'm including are on the include file path. "" usage just means stick "." before everything else in your include path. None of the files need that. :) If there's a diffferent policy in the Python source 'bout that that I'm not aware of, then I can fix that issue too.
... you already know that ;-) Again, these are already fixed :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
participants (3)
-
Bill Tutt
-
Fred L. Drake, Jr.
-
M.-A. Lemburg