Merging shaped_arenas into HEAD (complete)

[klax]

Tested in linux and seems ok.

Before merging to head I think we should solve incompatibilities with windows. Here I post some errors to help to solve them:

Code: Select all

armagetronad\src\tron\gParser.cpp(43) : error C2065: 'strncasecmp' : undeclared identifier
armagetronad\src\tron\gGame.cpp(2736) : error C2065: 'close' : undeclared identifier
armagetronad\src\tron\gParser.cpp(15) : fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory
armagetronad\src\tron\gParser.cpp(109) : error C2057: expected constant expression
armagetronad\src\tron\gParser.cpp(109) : error C2466: cannot allocate an array of constant size 0
armagetronad\src\tron\gParser.cpp(109) : error C2133: 'axisDir' : unknown size
armagetronad\src\tron\gParser.cpp(329) : error C2065: 'mkdir' : undeclared identifier
armagetronad\src\tron\gParser.cpp(356) : error C2065: 'open' : undeclared identifier

The first one: why not use stricmp?

[philippeqc]

ok, any windows guru could help me on this. What is the windows equivalent to open() and close()?

fopen and fclose are C++ function. And I'm quite sure that before C++, people had ways to open and close files.

-ph

[Jonathan]

fopen and fclose are C++ function.

fopen and fclose are portable C (not C++) functions.
open and close are system calls.

[philippeqc]

fopen and fclose are C++ function.

fopen and fclose are portable C (not C++) functions.
open and close are system calls.

libxml2 has many "read" functions. http://xmlsoft.org/html/libxml-parser.html. xmlCtxtReadDoc, xmlCtxtReadFd, xmlCtxtReadFile (need the filename as an argument), xmlCtxtReadIO, xmlCtxtReadMemory.

I was using xmlCtxtReadFd, as we have an inteligent resource fetching function that return file descriptors, and because none of the read function supported a FILE *.

Now, the way I see it is either somehow the full file name of the ressource to load is returned from the resourceFetcher (yuck!), either the resourceFetcher is converted to return a FILE * (easy) and the xml file is loaded all in a buffer for xmlCtxtReadMemory.

Does that seem like a good idea at all?

-ph

[philippeqc]

update: the buffer option is a good idea, and it has been commited. ;) 2 lines should dissapear out of the compilationi on windows, the open and the close.

About strncasecmp, xmlStrncasecmp should be as portable as the whole xmllib2, and has the advantage of supporting UTF-8. As for UFT-16, I'd be tempted to beleive xmlStrncasecmp has a greater chance of supporting it than strncasecmp. But I've been wrong before on this sort of things.

-ph

for more xml string functions, check http://xmlsoft.org/html/libxml-xmlstring.html

[Luke-Jr]

About strncasecmp, xmlStrncasecmp should be as portable as the whole xmllib2, and has the advantage of supporting UTF-8. As for UFT-16, I'd be tempted to beleive xmlStrncasecmp has a greater chance of supporting it than strncasecmp. But I've been wrong before on this sort of things.

I don't think the design makes it even possible to support more than one character set... Besides, who uses UTF-16??

[Luke-Jr]

fopen and fclose are C++ function.

fopen and fclose are portable C (not C++) functions.
open and close are system calls.

fopen and fclose are C stream-based file opening/closing
open and close are *also* standard C, but for dealing with low level I/O

[Z-Man]

Luke:

CONFORMING TO
The fopen and freopen functions conform to ANSI X3.159-1989 (``ANSI C'').

CONFORMING TO
SVr4, SVID, POSIX, X/OPEN, BSD 4.3. The O_NOFOLLOW and O_DIRECTORY
flags are Linux-specific. One may have to define the _GNU_SOURCE
macro to get their definitions.

The (undefined) effect of O_RDONLY | O_TRUNC various among imple-
mentations. On many systems the file is actually truncated.

The O_DIRECT flag was introduced in SGI IRIX, where it has align-
ment restrictions similar to those of Linux 2.4. IRIX has also a
fcntl(2) call to query appropriate alignments, and sizes. FreeBSD
4.x introduced a flag of same name, but without alignment restric-
tions. Support was added under Linux in kernel version 2.4.10.
Older Linux kernels simply ignore this flag.

Only one of these looks like deserving the title "Standard C".

[Luke-Jr]

The first one: why not use stricmp?

Because stricmp isn't C at all?
Maybe we should do some #define strcasecmp stricmp though

Only one of these looks like deserving the title "Standard C".

meh.
#undef "Standard C"
#define "Standard C" glibc

[philippeqc]

I don't think the design makes it even possible to support more than one character set...

Well, I dont know how feasable it was, but the first version of the parser used mostly xml functions for text operations.

Besides, who uses UTF-16??

*buzzing sound* I'd like to answer Alex. The question is: "Who are the Chineses, the Thai, the Coreeans, the Arabics (*), or anyone who doesnt speak any of the west europeans languages."

Ok, I might be technically wrong on that one, there is still lots about UTF-8 and UTF-16 that I dont understand, but it just felt better in me to think that I was at least trying a bit to fix that when I wrote the parser.

To luke-jr and Jonathan. Thanks for the open vs fopen explication. Most of my file descriptor and FILE* knowledge comes from a socket programing in Linux book. I'll try to avoid this mistake again.

-ph

(*) Sorry if that sound pejoratif. I'm swimming in a 3 languages envirenment, which mean I'm unable to express myself correctly in either of them. I dont know what is the adjectif to describe all the people that have "Arab" as a mother tongue.

[Lucifer]

Um, phil? UTF-8 can represent all of those languages, that's why it's the encoding of GNOME. And I think KDE too.

UTF-8 has as its first set of characters the old ASCII set, but it's much bigger than that, using up to 3 bytes to represent a character, which is 8*8*8, or 512 total characters it can contain.

At least, last I checked UTF-8 could handle them all......

[Luke-Jr]

Ok, I might be technically wrong on that one, there is still lots about UTF-8 and UTF-16 that I dont understand, but it just felt better in me to think that I was at least trying a bit to fix that when I wrote the parser.

UTF-8 and UTF-16 support the same stuff. The difference is that UTF-8 is compatible with ASCII and actually common-use.

(*) Sorry if that sound pejoratif. I'm swimming in a 3 languages envirenment, which mean I'm unable to express myself correctly in either of them. I dont know what is the adjectif to describe all the people that have "Arab" as a mother tongue.

I think Arabic is correct... At least, back when I was in a fansubbing group translating anime, one of the destination languages was Arabic, and our Arabic translator didn't give any hints that there's a better English word for it.

[klax]

Very fast m8s!! The open and close errors are gone.

Errors now:

Code: Select all

armagetronad\src\tron\gParser.cpp(43) : error C2065: 'strncasecmp' : undeclared identifier
armagetronad\src\tron\gParser.cpp(15) : fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory
armagetronad\src\tron\gParser.cpp(109) : error C2057: expected constant expression
armagetronad\src\tron\gParser.cpp(109) : error C2466: cannot allocate an array of constant size 0
armagetronad\src\tron\gParser.cpp(109) : error C2133: 'axisDir' : unknown size
armagetronad\src\tron\gParser.cpp(329) : error C2065: 'mkdir' : undeclared identifier

The strncasecmp is solved with this (can anyone commit this?):

Code: Select all

#ifdef WIN32
#define strncasecmp strnicmp
#endif

[Jonathan]

Um, phil? UTF-8 can represent all of those languages, that's why it's the encoding of GNOME. And I think KDE too.

UTF-8 has as its first set of characters the old ASCII set, but it's much bigger than that, using up to 3 bytes to represent a character, which is 8*8*8, or 512 total characters it can contain.

At least, last I checked UTF-8 could handle them all......

Everyone read this: http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8

[Luke-Jr]

Everyone read this: http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8

Did... a long time ago... back when I was implementing UTF-8 support for the MOO programming language =p