Hi Steve, Steve Howe wrote:
Friday, June 2, 2006, 3:56:45 AM, you wrote:
here's a new etree.c that /should/ compile. All lines below 8k. I was wrong about the max line size. It seems max size is 2k (argh!)
2k for a string? That's nothing! How can this thing call itself a C compiler?
The platform (MSVC6) docs for C2026:
After adjacent strings are concatenated, a string cannot be longer than 2048 characters.
However, this should work:
"huge part 1" "huge part 1"
The compiler only gripes about a single string literal > 2K.
Hu? But it says "after adjacent strings are concatenated"... Anyway, I can't do that from Pyrex code. Ok, so that means I have to revert the change that introduced these long strings, which are essentially long lists of constants, one per line. I did that to reduce the time it takes to compile. If we use Python lists to store them or Python objects that have them as attributes, Pyrex will generate tons of setup code that builds the objects or lists and that bloats the code and raises the compile time to the sky. A quick loop over a splitted string is just the fastest and smallest thing I could imagine. I'll see what I can come up with. I guess the best way is an auto-generator for these constants from the libxml2 source I currently cut&pasted them from. Maybe we should store them in C arrays and then have our own loop to generate Python strings from them. Stefan