I'm a bit worried about the ucnhash module and its huge size. I didn't follow the discussion closely at the time, because I thought I could always exclude it from the Pythons without dynamic linking, but now it seems that if i don't include it test_unicode doesn't run anymore. Is this a problem with test_unicode, or should I consider ucnhash a mandatory module? (BTW: there were also a couple of bugs in the module, include <> in stead of include "", and static in stead of staticforward declarations, I'll submit patches for those shortly). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++
Jack Jansen wrote:
I'm a bit worried about the ucnhash module and its huge size. I didn't follow the discussion closely at the time, because I thought I could always exclude it from the Pythons without dynamic linking, but now it seems that if i don't include it test_unicode doesn't run anymore.
Is this a problem with test_unicode, or should I consider ucnhash a mandatory module?
The ucnhash module is loaded on demand to avoid memory bloat. In practice the difference is not really noticeable since loading a shared module or swapping in a few pages of static C data result in pretty much the same overall memory usage. If no-one complains, I'll fix the test suite though to make the tests of the named Unicode characters optional. Is this ok with you, Bill ?
(BTW: there were also a couple of bugs in the module, include <> in stead of include "", and static in stead of staticforward declarations, I'll submit patches for those shortly).
I didn't have any problem compiling the module (don't even get warnings when compiling with -Wall) ... but you're right: these ought to get fixed. BTW, since ucnhash.h|c are generated using the scripts in Tools/perfecthash/ your patch should probably also fix the instances of the problems found in there. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
On 29 June 2000, M.-A. Lemburg said:
The ucnhash module is loaded on demand to avoid memory bloat. In practice the difference is not really noticeable since loading a shared module or swapping in a few pages of static C data result in pretty much the same overall memory usage.
If no-one complains, I'll fix the test suite though to make the tests of the named Unicode characters optional.
How 'bout a separate "test_ucn" to test this feature? ...of course, this is yet another case of language syntax features becoming optional and selectable at compile-time, which I still think is a bad idea. Hmmm. Greg
Greg Ward wrote:
On 29 June 2000, M.-A. Lemburg said:
The ucnhash module is loaded on demand to avoid memory bloat. In practice the difference is not really noticeable since loading a shared module or swapping in a few pages of static C data result in pretty much the same overall memory usage.
If no-one complains, I'll fix the test suite though to make the tests of the named Unicode characters optional.
How 'bout a separate "test_ucn" to test this feature?
Good idea.
...of course, this is yet another case of language syntax features becoming optional and selectable at compile-time, which I still think is a bad idea. Hmmm.
It's not selectable at run-time: either you have compiled the module or not. It is enabled per default. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
participants (3)
-
Greg Ward
-
Jack Jansen
-
M.-A. Lemburg