From noreply at sourceforge.net Fri Aug 1 15:15:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 1 17:15:52 2003 Subject: [Expat-bugs] [ expat-Bugs-781755 ] docs for pre-processor defines Message-ID: Bugs item #781755, was opened at 2003-08-01 17:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=781755&group_id=10127 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: docs for pre-processor defines Initial Comment: We need centralized documentation for the C pre-processor defines used to affect the compilation of Expat so people porting to new platforms will be able to understand what each is for and how they relate to each other. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=781755&group_id=10127 From noreply at sourceforge.net Mon Aug 4 07:22:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 4 09:22:21 2003 Subject: [Expat-bugs] [ expat-Bugs-782815 ] 404 error on mailing list link from main page Message-ID: Bugs item #782815, was opened at 2003-08-04 14:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=782815&group_id=10127 Category: www.libexpat.org Group: None Status: Open Resolution: None Priority: 5 Submitted By: Faye Gibbins (fgibbins) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: 404 error on mailing list link from main page Initial Comment: on http://www.libexpat.org there is a "mailing list" link to http://mail.libexpat.org/mailman-21/listinfo/ This returns an HTTP 404 error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=782815&group_id=10127 From noreply at sourceforge.net Mon Aug 4 08:39:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 4 10:40:01 2003 Subject: [Expat-bugs] [ expat-Bugs-782815 ] 404 error on mailing list link from main page Message-ID: Bugs item #782815, was opened at 2003-08-04 09:22 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=782815&group_id=10127 Category: www.libexpat.org Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Faye Gibbins (fgibbins) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: 404 error on mailing list link from main page Initial Comment: on http://www.libexpat.org there is a "mailing list" link to http://mail.libexpat.org/mailman-21/listinfo/ This returns an HTTP 404 error. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-08-04 10:39 Message: Logged In: YES user_id=3066 The interface on the list server changed a little; I've updated the link. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=782815&group_id=10127 From utcke at informatik.uni-hamburg.de Wed Aug 6 19:59:22 2003 From: utcke at informatik.uni-hamburg.de (Sven Utcke) Date: Wed Aug 6 13:01:37 2003 Subject: [Expat-bugs] expat: make check fails Message-ID: <20030806165922.GY27668@kogs31.informatik.uni-hamburg.de> Hi, I just ran set VERSION=`uname -r`-`uname -s` mkdir -p $VERSION/objs cd $VERSION/objs ../../src/configure --prefix=/software/expat-1.95.6 --exec-prefix=/software/expat-1.95.6/$VERSION make make check and got gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I../../src/lib -I. -o tests/runtests.o -c ../../src/tests/runtests.c ../../src/tests/runtests.c:2: check.h: No such file or directory make: *** [tests/runtests.o] Error 1 Even worse: find /software/expat-1.95.6/ -name check.h Does not find any file of that name. Any ideas? Sven -- _ __ The Cognitive Systems Group | |/ /___ __ _ ___ University of Hamburg | ' References: <20030806165922.GY27668@kogs31.informatik.uni-hamburg.de> Message-ID: <16178.23663.842756.138075@grendel.zope.com> Sven Utcke writes: > make > make check > > and got > > gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I../../src/lib -I. -o tests/runtests.o -c ../../src/tests/runtests.c > ../../src/tests/runtests.c:2: check.h: No such file or directory > make: *** [tests/runtests.o] Error 1 > > Even worse: > > find /software/expat-1.95.6/ -name check.h > > Does not find any file of that name. Any ideas? "check" is a third-party library to support unit testing in C. You can get more information about it at: http://check.sourceforge.net/ -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From utcke at informatik.uni-hamburg.de Thu Aug 7 17:17:33 2003 From: utcke at informatik.uni-hamburg.de (Sven Utcke) Date: Thu Aug 7 10:17:45 2003 Subject: [Expat-bugs] expat: make check fails In-Reply-To: <16178.23663.842756.138075@grendel.zope.com> References: <20030806165922.GY27668@kogs31.informatik.uni-hamburg.de> <16178.23663.842756.138075@grendel.zope.com> Message-ID: <20030807141733.GE27668@kogs31.informatik.uni-hamburg.de> Hello Fred L. Drake, Jr., > Sven Utcke writes: > > make > > make check > > > > and got > > > > gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I../../src/lib -I. -o tests/runtests.o -c ../../src/tests/runtests.c > > ../../src/tests/runtests.c:2: check.h: No such file or directory > > make: *** [tests/runtests.o] Error 1 > > > > Even worse: > > > > find /software/expat-1.95.6/ -name check.h > > > > Does not find any file of that name. Any ideas? > > "check" is a third-party library to support unit testing in C. You > can get more information about it at: > > http://check.sourceforge.net/ Ok. I would still claim that the above is a bug though, as most configure-based software (or maybe I should call it GNUish sw?) would allow you to type "make check" to run the included unit tests, rather than to compile a framework for unit-tests which needs to be downloaded separately. At the very least I would expect the README to point out this idiosyncrasy and tell me where to get (and where to put) check [please note that I do not mean to slight anybody --- I'm sure there was some reason to do things the way they were done; all I'm trying to do is to point out that in my opinion this is not the behaviour the majority of people would expect --- and I consider such startling behaviour a bug] Sven -- _ __ The Cognitive Systems Group | |/ /___ __ _ ___ University of Hamburg | ' References: <20030806165922.GY27668@kogs31.informatik.uni-hamburg.de> <16178.23663.842756.138075@grendel.zope.com> <20030807141733.GE27668@kogs31.informatik.uni-hamburg.de> Message-ID: <16178.24864.692345.33935@grendel.zope.com> Sven Utcke writes: > Ok. I would still claim that the above is a bug though, as most > configure-based software (or maybe I should call it GNUish sw?) would > allow you to type "make check" to run the included unit tests, rather > than to compile a framework for unit-tests which needs to be > downloaded separately. Perhaps. I've certainly considered removing the requirement, but haven't had time to do so, and the priority seems low. > At the very least I would expect the README to point out this > idiosyncrasy and tell me where to get (and where to put) check [please Understood. There is a note in the version of the README in our CVS repository, so the next Expat release will include such a note. > note that I do not mean to slight anybody --- I'm sure there was some > reason to do things the way they were done; all I'm trying to do is to > point out that in my opinion this is not the behaviour the majority of > people would expect --- and I consider such startling behaviour a bug] Understood. It's not unreasonable to expect a bit more from configure, but I'm afraid our autoconf expert has been more than a little busy lately. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From gstein at lyra.org Thu Aug 7 17:05:46 2003 From: gstein at lyra.org (Greg Stein) Date: Thu Aug 7 18:57:32 2003 Subject: [Expat-bugs] expat: make check fails In-Reply-To: <16178.24864.692345.33935@grendel.zope.com> References: <20030806165922.GY27668@kogs31.informatik.uni-hamburg.de> <16178.23663.842756.138075@grendel.zope.com> <20030807141733.GE27668@kogs31.informatik.uni-hamburg.de> <16178.24864.692345.33935@grendel.zope.com> Message-ID: <20030807230546.GO17867@lyra.org> On Thu, Aug 07, 2003 at 10:24:32AM -0400, Fred L. Drake, Jr. wrote: > Sven Utcke writes: >... > > note that I do not mean to slight anybody --- I'm sure there was some > > reason to do things the way they were done; all I'm trying to do is to > > point out that in my opinion this is not the behaviour the majority of > > people would expect --- and I consider such startling behaviour a bug] Yup, it is definitely a bug and has been logged at SourceForge. It is on my plate to fix it in the configuration process. My intent is to have configure note the absence of "check" and tweak "make check" to issue a warning when the library is missing. > Understood. It's not unreasonable to expect a bit more from > configure, but I'm afraid our autoconf expert has been more than a > little busy lately. Oof... you can say that again. :-( Cheers, -g -- Greg Stein, http://www.lyra.org/ From fdrake at acm.org Thu Aug 7 20:25:45 2003 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Thu Aug 7 19:26:25 2003 Subject: [Expat-bugs] expat: make check fails In-Reply-To: <20030807230546.GO17867@lyra.org> References: <20030806165922.GY27668@kogs31.informatik.uni-hamburg.de> <16178.23663.842756.138075@grendel.zope.com> <20030807141733.GE27668@kogs31.informatik.uni-hamburg.de> <16178.24864.692345.33935@grendel.zope.com> <20030807230546.GO17867@lyra.org> Message-ID: <16178.57337.859569.837447@grendel.zope.com> Greg Stein writes: > Yup, it is definitely a bug and has been logged at SourceForge. It is on my > plate to fix it in the configuration process. My intent is to have configure > note the absence of "check" and tweak "make check" to issue a warning when > the library is missing. Works for me. How difficult would it be to have configure change what happens in some other way when the library isn't found? I could certainly see doing a thin, just-enough version of the library's API so we can build & run the tests without check being available. (It's still good to support the real check library since it provides a lot of support for running unit tests even in the presence of nastiness like core dumps.) > Oof... you can say that again. :-( But just looking through the docs for Subversion is really making me look forward to it. I'm using some of the ideas for the filesystem synchronization support in Zope 3! And we're considering migrating the Zope 3 repository to Subversion as well. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From noreply at sourceforge.net Tue Aug 12 06:57:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 12 08:57:18 2003 Subject: [Expat-bugs] [ expat-Bugs-787387 ] xmlwf -n on file which uses a ':' as attribute name Message-ID: Bugs item #787387, was opened at 2003-08-12 05:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=787387&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: xmlwf -n on file which uses a ':' as attribute name Initial Comment: xmwf -n on file ]> reports valid/sa/012.xml:3:14: syntax error as it does not like ':' as an attribute name. I'm not quite sure whether this is a bug or not - cf. http://www.w3.org/TR/REC-xml-names/ [4] NCName ::= (Letter | '_') (NCNameChar)* [5] NCNameChar ::= Letter | Digit | '.' | '-' | '_' | CombiningChar | Extender [6] QName ::= (Prefix ':')? LocalPart [7] Prefix ::= NCName [8] LocalPart ::= NCName and http://www.w3.org/TR/REC-xml#attdecls [52] AttlistDecl ::= '' [53] AttDef ::= S Name S AttType S DefaultDecl [4] NameChar ::= Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender [5] Name ::= (Letter | '_' | ':') (NameChar)* tcrhak@suse.cz ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=787387&group_id=10127 From noreply at sourceforge.net Tue Aug 12 19:00:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 12 21:00:48 2003 Subject: [Expat-bugs] [ expat-Bugs-787387 ] xmlwf -n on file which uses a ':' as attribute name Message-ID: Bugs item #787387, was opened at 2003-08-12 12:57 Message generated for change (Comment added) made by pointsman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=787387&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: xmlwf -n on file which uses a ':' as attribute name Initial Comment: xmwf -n on file ]> reports valid/sa/012.xml:3:14: syntax error as it does not like ':' as an attribute name. I'm not quite sure whether this is a bug or not - cf. http://www.w3.org/TR/REC-xml-names/ [4] NCName ::= (Letter | '_') (NCNameChar)* [5] NCNameChar ::= Letter | Digit | '.' | '-' | '_' | CombiningChar | Extender [6] QName ::= (Prefix ':')? LocalPart [7] Prefix ::= NCName [8] LocalPart ::= NCName and http://www.w3.org/TR/REC-xml#attdecls [52] AttlistDecl ::= '' [53] AttDef ::= S Name S AttType S DefaultDecl [4] NameChar ::= Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender [5] Name ::= (Letter | '_' | ':') (NameChar)* tcrhak@suse.cz ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-08-13 01:00 Message: Logged In: YES user_id=13222 Not a bug. expat is right. You've quoted even the right productions, to decide this. (4) says, that a NCName must have at least one char and a colon isn't allowed. (By the way: I always thought, that NCName stands for non colon name, but could not found a source for that, at the moment). Prefix (7) and Localpart (8) are both NCNames. A colon in the QName is therefor only possible, if the QName has a prefix. Since the prefix must have at least one char, the att name in your example hasn't a prefix. Note, that your document is a wellformed XML document - and xmlwf (without -n) confirms this. It's only not a wellformed namespaced XML document. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=787387&group_id=10127 From noreply at sourceforge.net Tue Aug 12 21:29:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 12 23:29:08 2003 Subject: [Expat-bugs] [ expat-Bugs-787387 ] xmlwf -n on file which uses a ':' as attribute name Message-ID: Bugs item #787387, was opened at 2003-08-12 08:57 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=787387&group_id=10127 Category: None >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: xmlwf -n on file which uses a ':' as attribute name Initial Comment: xmwf -n on file ]> reports valid/sa/012.xml:3:14: syntax error as it does not like ':' as an attribute name. I'm not quite sure whether this is a bug or not - cf. http://www.w3.org/TR/REC-xml-names/ [4] NCName ::= (Letter | '_') (NCNameChar)* [5] NCNameChar ::= Letter | Digit | '.' | '-' | '_' | CombiningChar | Extender [6] QName ::= (Prefix ':')? LocalPart [7] Prefix ::= NCName [8] LocalPart ::= NCName and http://www.w3.org/TR/REC-xml#attdecls [52] AttlistDecl ::= '' [53] AttDef ::= S Name S AttType S DefaultDecl [4] NameChar ::= Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender [5] Name ::= (Letter | '_' | ':') (NameChar)* tcrhak@suse.cz ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-08-12 23:29 Message: Logged In: YES user_id=3066 Closing as not-a-bug, for the reason explained by Rolf. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-08-12 21:00 Message: Logged In: YES user_id=13222 Not a bug. expat is right. You've quoted even the right productions, to decide this. (4) says, that a NCName must have at least one char and a colon isn't allowed. (By the way: I always thought, that NCName stands for non colon name, but could not found a source for that, at the moment). Prefix (7) and Localpart (8) are both NCNames. A colon in the QName is therefor only possible, if the QName has a prefix. Since the prefix must have at least one char, the att name in your example hasn't a prefix. Note, that your document is a wellformed XML document - and xmlwf (without -n) confirms this. It's only not a wellformed namespaced XML document. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=787387&group_id=10127 From robert.repnak at verdisoft.com Tue Aug 19 16:29:35 2003 From: robert.repnak at verdisoft.com (Robert Repnak) Date: Tue Aug 19 09:29:42 2003 Subject: [Expat-bugs] CDATA problems Message-ID: <41E5E48B78F8564A9BB9EA2691843E1B333B48@ENTERPRISE.verdisoft.com> Hello, I'm using expat on a Symbian device. I get trouble with CDATA. I get a XML-File with a CDATA block. In this block a "0x0A" is included. At this position expat is deviding the CDATA block. Is it bug with expat, or do i something wrong with the encoding? Thanks robert -- VerdiSoft GmbH Robert Repnak Suederstr. 77 20097 Hamburg Tel.: +49 40 280054 30 From karl at waclawek.net Tue Aug 19 10:39:03 2003 From: karl at waclawek.net (Karl Waclawek) Date: Tue Aug 19 09:39:13 2003 Subject: [Expat-bugs] CDATA problems References: <41E5E48B78F8564A9BB9EA2691843E1B333B48@ENTERPRISE.verdisoft.com> Message-ID: <004a01c36657$41074810$9e539696@citkwaclaww2k> > I'm using expat on a Symbian device. I get trouble with CDATA. > I get a XML-File with a CDATA block. In this block a "0x0A" is included. > At this position expat is deviding the CDATA block. Is it bug with > expat, or do i something wrong with the encoding? No, this is normal behaviour. Expat may divide contiguous blocks of character data at its own discretion. Check the docs - reference.html - for XML_SetCharacterDataHandler. Karl From robert.repnak at verdisoft.com Tue Aug 19 17:01:23 2003 From: robert.repnak at verdisoft.com (Robert Repnak) Date: Tue Aug 19 10:01:27 2003 Subject: AW: [Expat-bugs] CDATA problems Message-ID: <41E5E48B78F8564A9BB9EA2691843E1B333B49@ENTERPRISE.verdisoft.com> Hello Karl, Thanks for the fast reply. Is it possible to turn off this feature? My xml-files are kind of tiny and i know there is no need for dividing data. This dividing makes my handler more complicated, and it's really not necessary. robert > -----Urspr?ngliche Nachricht----- > Von: Karl Waclawek [mailto:karl@waclawek.net] > Gesendet: Dienstag, 19. August 2003 15:39 > An: Robert Repnak; expat-bugs@libexpat.org > Betreff: Re: [Expat-bugs] CDATA problems > > > > I'm using expat on a Symbian device. I get trouble with CDATA. > > I get a XML-File with a CDATA block. In this block a "0x0A" > is included. > > At this position expat is deviding the CDATA block. Is it bug with > > expat, or do i something wrong with the encoding? > > No, this is normal behaviour. Expat may divide contiguous blocks > of character data at its own discretion. > Check the docs - reference.html - for XML_SetCharacterDataHandler. > > Karl > From karl at waclawek.net Tue Aug 19 11:38:28 2003 From: karl at waclawek.net (Karl Waclawek) Date: Tue Aug 19 10:38:37 2003 Subject: [Expat-bugs] CDATA problems References: <41E5E48B78F8564A9BB9EA2691843E1B333B49@ENTERPRISE.verdisoft.com> Message-ID: <006301c3665f$8e0563b0$9e539696@citkwaclaww2k> > Thanks for the fast reply. > Is it possible to turn off this feature? My xml-files are kind of tiny > and i know there is no need for dividing data. This dividing makes > my handler more complicated, and it's really not necessary. Unfortunately not. This dividing is not so much a feature as it is a result of how Expat processes the XML data, and removing it would mean to *re-design* core portions of Expat. You will find that most (if not all) SAX-like parsers have the same behaviour. Karl From noreply at sourceforge.net Sun Aug 24 22:13:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 25 00:13:53 2003 Subject: [Expat-bugs] [ expat-Bugs-794475 ] Truncated data from datahandler Message-ID: Bugs item #794475, was opened at 2003-08-25 14:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=794475&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Yvan Strahm (ystrahm) Assigned to: Nobody/Anonymous (nobody) Summary: Truncated data from datahandler Initial Comment: Hi all, I am usin expat 1.95.1 and it seems that the data retourned by the datahandler function are truncated or incomplete. Does anyone an idea what's going on and how I can correct this problem? Thanks cheers y. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=794475&group_id=10127 From tbray at textuality.com Mon Aug 25 06:24:20 2003 From: tbray at textuality.com (Tim Bray) Date: Mon Aug 25 08:24:20 2003 Subject: [Expat-bugs] OS X Build problems Message-ID: <3F49FFF4.4030803@textuality.com> I'm surprised not to find other people with the same problem, looking @ Google & other obvious places doesn't help. I grabbed 1.95.6 and did a configure and "make" blew up messily and quickly with tons of syntax errors /bin/sh ./libtool --silent --mode=compile gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I./lib -I. -o lib/xmlparse.lo -c lib/xmlparse.c lib/xmltok.h:143: syntax error, found `*' lib/xmltok.h:143: illegal member declaration, missing name, found `)' lib/xmltok.h:144: syntax error, found `*' lib/xmltok.h:144: illegal member declaration... etc. I've seen reports of OS X problems but they seem to be with static linking & so on... do I need to work through this one or is it a known issue & I just missed it when I went looking? -- Cheers, Tim Bray (ongoing fragmented essay: http://www.tbray.org/ongoing/) From noreply at sourceforge.net Mon Aug 25 07:04:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 25 09:05:05 2003 Subject: [Expat-bugs] [ expat-Bugs-794475 ] Truncated data from datahandler Message-ID: Bugs item #794475, was opened at 2003-08-25 00:13 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=794475&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Yvan Strahm (ystrahm) Assigned to: Nobody/Anonymous (nobody) Summary: Truncated data from datahandler Initial Comment: Hi all, I am usin expat 1.95.1 and it seems that the data retourned by the datahandler function are truncated or incomplete. Does anyone an idea what's going on and how I can correct this problem? Thanks cheers y. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-08-25 09:04 Message: Logged In: YES user_id=290026 Do you know that Expat may report contiguous character data in more than one call-back to the character data handler? Could that be your problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=794475&group_id=10127 From noreply at sourceforge.net Tue Aug 26 17:50:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 26 19:51:05 2003 Subject: [Expat-bugs] [ expat-Bugs-794475 ] Truncated data from datahandler Message-ID: Bugs item #794475, was opened at 2003-08-24 21:13 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=794475&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Yvan Strahm (ystrahm) Assigned to: Nobody/Anonymous (nobody) Summary: Truncated data from datahandler Initial Comment: Hi all, I am usin expat 1.95.1 and it seems that the data retourned by the datahandler function are truncated or incomplete. Does anyone an idea what's going on and how I can correct this problem? Thanks cheers y. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-08-26 16:50 Message: Logged In: NO No I didn't! And it was my problem. But now by knowing it, I fixed the problem. Thank you very much ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-08-25 06:04 Message: Logged In: YES user_id=290026 Do you know that Expat may report contiguous character data in more than one call-back to the character data handler? Could that be your problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=794475&group_id=10127 From noreply at sourceforge.net Tue Aug 26 21:30:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 26 23:30:34 2003 Subject: [Expat-bugs] [ expat-Bugs-794475 ] Truncated data from datahandler Message-ID: Bugs item #794475, was opened at 2003-08-25 00:13 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=794475&group_id=10127 Category: None >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Yvan Strahm (ystrahm) Assigned to: Nobody/Anonymous (nobody) Summary: Truncated data from datahandler Initial Comment: Hi all, I am usin expat 1.95.1 and it seems that the data retourned by the datahandler function are truncated or incomplete. Does anyone an idea what's going on and how I can correct this problem? Thanks cheers y. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-08-26 23:30 Message: Logged In: YES user_id=3066 Closed as "Not a bug" based on followup comments. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-08-26 19:50 Message: Logged In: NO No I didn't! And it was my problem. But now by knowing it, I fixed the problem. Thank you very much ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-08-25 09:04 Message: Logged In: YES user_id=290026 Do you know that Expat may report contiguous character data in more than one call-back to the character data handler? Could that be your problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=794475&group_id=10127 From noreply at sourceforge.net Wed Aug 27 06:38:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 27 08:38:45 2003 Subject: [Expat-bugs] [ expat-Bugs-774028 ] can't pass parser witch attribute contained char ">" Message-ID: Bugs item #774028, was opened at 2003-07-18 22:41 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=774028&group_id=10127 Category: XML::Parser (inactive) Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: can't pass parser witch attribute contained char ">" Initial Comment: can't pass parser witch attribute contained char ">" like this: ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-08-27 08:36 Message: Logged In: YES user_id=3066 Closing this since Expat's already doing the right thing. Added coverage to the test suite in tests/runtests.c revision 1.51. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-07-19 00:26 Message: Logged In: YES user_id=290026 Works for me with current Expat. Btw, we don't have an XML::Parser expert currently. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=774028&group_id=10127 From noreply at sourceforge.net Wed Aug 27 06:55:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 27 08:56:03 2003 Subject: [Expat-bugs] [ expat-Bugs-732794 ] Build issues on Unix platforms Message-ID: Bugs item #732794, was opened at 2003-05-05 12:49 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=732794&group_id=10127 Category: Build control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) >Assigned to: Greg Stein (gstein) Summary: Build issues on Unix platforms Initial Comment: Nelson Beebe reported a few issues while building Expat 1.95.6 on various Unix platforms. Attached as file beebe.txt. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-08-27 08:55 Message: Logged In: YES user_id=3066 I looked over Nelson's comments, and it looks like most of these issues are related to the way libtool puts command lines together, not things that are directly in the Makefile; Makefile.pre.in looks like it gets these issues right. Greg, can you take a look at this as well? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-15 11:42 Message: Logged In: YES user_id=3066 Added notes about the use of check in README revision 1.24. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=732794&group_id=10127 From tbray at textuality.com Wed Aug 27 10:32:40 2003 From: tbray at textuality.com (Tim Bray) Date: Wed Aug 27 12:33:00 2003 Subject: [Expat-bugs] OS X Build problems In-Reply-To: <3F49FFF4.4030803@textuality.com> References: <3F49FFF4.4030803@textuality.com> Message-ID: <3F4CDD28.7080300@textuality.com> Tim Bray wrote: > I'm surprised not to find other people with the same problem, looking @ > Google & other obvious places doesn't help. I grabbed 1.95.6 and did a > configure and "make" blew up messily and quickly with tons of syntax errors I have verified that the problem is with FASTCALL and PTRFASTCALL, #defining them away inside #if defined(__GNU_C__) in lib/internal.h makes the problem go away. So what's needed is to have a place in internal.h to insert the appropriate incantations for OS X... -Tim From fdrake at acm.org Wed Aug 27 13:37:20 2003 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Wed Aug 27 12:38:06 2003 Subject: [Expat-bugs] OS X Build problems In-Reply-To: <3F4CDD28.7080300@textuality.com> References: <3F49FFF4.4030803@textuality.com> <3F4CDD28.7080300@textuality.com> Message-ID: <16204.56896.333447.329124@grendel.zope.com> Tim Bray writes: > I have verified that the problem is with FASTCALL and PTRFASTCALL, > #defining them away inside #if defined(__GNU_C__) in lib/internal.h > makes the problem go away. So what's needed is to have a place in > internal.h to insert the appropriate incantations for OS X... -Tim I'm hoping to get this fixed in CVS tonight; I've been holding back on this since I now have reasonable access to a Mac OS X box, but haven't had time to play with it yet. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From noreply at sourceforge.net Wed Aug 27 10:40:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 27 12:40:35 2003 Subject: [Expat-bugs] [ expat-Bugs-765227 ] MacOSX build error with Expat 1.95.6 (included with PyXML) Message-ID: Bugs item #765227, was opened at 2003-07-03 06:32 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=765227&group_id=10127 >Category: None Group: Platform Specific Status: Open Resolution: None >Priority: 7 Submitted By: David Kaasen (davidkaasen) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: MacOSX build error with Expat 1.95.6 (included with PyXML) Initial Comment: I had trouble with the expat 1.95.6 that is included with PyXML 0.8.2 on MacOSX 10.2.6. The build of PyXML gave error messages (but didn't halt) when compiling xmltok.c. It appears to be problems with the macros FASTCALL, PTRCALL and PTRFASTCALL in internal.h. Defining these to nothing made the compile succeed. Here is the diff output: *** PyXML-0.8.2/extensions/expat/lib/internal.h~ Sat Jan 25 12:18:09 2003 --- PyXML-0.8.2/extensions/expat/lib/internal.h Thu Jul 3 11:12:36 2003 *************** *** 27,33 **** --- 27,36 ---- and let's try this: */ + /* It doesn't work on MacOSX (__MACH__ and __APPLE__ == MacOSX). */ + #if !(defined(__MACH__) && defined(__APPLE__)) #define FASTCALL __attribute__((regparm(3))) #define PTRCALL #define PTRFASTCALL __attribute__((regparm(3))) + #endif /* Not MacOSX */ #elif defined(WIN32) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-08-27 12:40 Message: Logged In: YES user_id=3066 Bumping priority; this must be fixed for 1.95.7. I've held back mostly since I now have reasonable access to a Mac OS X box, but haven't had time to really do much with it (like testing Expat!). ---------------------------------------------------------------------- Comment By: David Kaasen (davidkaasen) Date: 2003-07-03 06:59 Message: Logged In: YES user_id=20933 I should have mentioned that I am using Fink and Fink's Python distribution. Using /usr/bin/python instead only gives warnings, but then, there are problems with LDFLAGS containing "-arch i386" in /usr/lib/python2.2/config/Makefile. If that string is removed from LDFLAGS, everything seems to go well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=765227&group_id=10127 From noreply at sourceforge.net Wed Aug 27 10:43:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 27 12:43:44 2003 Subject: [Expat-bugs] [ expat-Patches-699487 ] Hash table improvement Message-ID: Patches item #699487, was opened at 2003-03-07 11:31 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=699487&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Hash table improvement Initial Comment: This patch addresses two areas: 1) The current hash function ignores the high byte of UTF-16 characters. This is not good. 2) There is a cheap way to switch from the current method of linear probing (to resolve collisions) to the slightly better double hashing. Ad 1) hashing of wide characters: Currently, the algorithm is like this: h = h * 33 + (unsigned char)c; where h is the hash value and c is a character in the string argument (char or wchar_t). It seems this hashing algorithm belongs to a family of algorithms of the type: h = h * + character where is taken froma list of tried and proven values like 31, 33, 37, 41, 65599 which should be (but are not always) prime numbers. I added a wchar_t version (#ifdef XML_UNICODE) of this type: h = h * 65599 + (unsigned short)c; Ad 2) double hashing: Currently the hash table index is calculated from the hash value by masking out the lower bits according to table size. This works because the table size is a power of 2. But this also means that some bits of the hash value are unused. From these we can therefore generate the second hash value with little extra effort. The patch also updates the inlined hash table implementation used for detecting duplicate prefixed attributes (in function storeAtts()). See the attached file hashpatch1.diff (to be applied against xmlparse.c rev. 1.109). ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-08-27 12:43 Message: Logged In: YES user_id=290026 Attached new patch file hashpatch2.diff. Includes changes suggested in comment from 2003-04-01. Also changed hash function to be closer to Python's string hash and improved comments on the inlined attributes hash table in storeAttributes(). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-04-01 12:50 Message: Logged In: YES user_id=290026 The last change is not necessary, since the cast to unsigned char takes care of overflow. It actually introduces a bug, since for small sizes the step size can now be larger than the table size. We can change back and write it like this: #define SECOND_HASH(hash, mask, power) \ ((((hash) & ~(mask)) >> ((power) - 1)) & ((mask) >> 2)) #define PROBE_STEP(hash, mask, power) \ ((unsigned char)((SECOND_HASH(hash, mask, power)) | 1)) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-28 20:40 Message: Logged In: YES user_id=290026 Further change for PROBE_STEP macro: To prevent overflow (the result should fit into one Byte) we replace "& (mask >> 2)" with "& (unsigned long)0xFF": #define BYTE_MASK ((unsigned long)0xFF) #define PROBE_STEP(hash, mask, power) \ ((unsigned char)((((hash) & ~(mask)) >> ((power) - 1)) \ & BYTE_MASK) \ | (unsigned char)(1)) which limits the maxium step size to 0xFF. Large steps are not a good idea anyway, since that might lead to cache misses. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-24 13:29 Message: Logged In: YES user_id=290026 Improvement to first patch version (hashpatch1.diff): For calculating second hash, don't overwrite the rightmost bit of the hash value's unused portion. This means: change ">> (power)" to ">> ((power) - 1)": #define PROBE_STEP(hash, mask, power) \ ((unsigned char)((((hash) & ~(mask)) >> ((power) - 1)) & ((mask) >> 2)) \ + | (unsigned char)(1)) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=699487&group_id=10127 From dent at oofile.com.au Thu Aug 28 12:08:30 2003 From: dent at oofile.com.au (Andy Dent) Date: Wed Aug 27 23:09:15 2003 Subject: [Expat-bugs] OS X Build problems In-Reply-To: <16204.56896.333447.329124@grendel.zope.com> Message-ID: <015701c36d8f$634df470$ed917482@berylpro> Fred Drake writes: > Tim Bray writes: > > I have verified that the problem is with FASTCALL and PTRFASTCALL, > > #defining them away inside #if defined(__GNU_C__) in lib/internal.h > I'm hoping to get this fixed in CVS tonight; I've been holding back on > this since I now have reasonable access to a Mac OS X box I'm in a multi-platform environment and building expatpp on OSX with CodeWarrior primarily but can test with gcc if I have to - I'm just more than usually busy until November. After that hope to be able to contribute more. (My current project using expat in expatpp is being built on PocketPC with Embedded VC 3 and Win with Visual Studio 6 but I'm in the process of moving to Visual Studio.net 2003). Andy Dent BSc MACS AACM http://www.oofile.com.au/ OOFILE - Database, Reports, Graphs, GUI for c++ on Mac, Unix & Windows PP2MFC - PowerPlant->MFC portability From tbray at textuality.com Wed Aug 27 17:52:36 2003 From: tbray at textuality.com (Tim Bray) Date: Thu Aug 28 00:13:51 2003 Subject: [Expat-bugs] Reference doc buglet for XML_ParserReset Message-ID: <3F4D4444.3080700@textuality.com> In doc/reference.html, the writeup for XML_ParserRest is wrong, it leaves out the second "encoding" argument. -- Cheers, Tim Bray (ongoing fragmented essay: http://www.tbray.org/ongoing/) From karl at waclawek.net Thu Aug 28 10:08:58 2003 From: karl at waclawek.net (Karl Waclawek) Date: Thu Aug 28 09:09:13 2003 Subject: [Expat-bugs] Reference doc buglet for XML_ParserReset References: <3F4D4444.3080700@textuality.com> Message-ID: <002401c36d65$8b0b1670$9e539696@citkwaclaww2k> > In doc/reference.html, the writeup for XML_ParserRest is wrong, it > leaves out the second "encoding" argument. Thanks - fixed in CVS. Karl From noreply at sourceforge.net Thu Aug 28 14:32:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 28 16:35:19 2003 Subject: [Expat-bugs] [ expat-Patches-699487 ] Hash table improvement Message-ID: Patches item #699487, was opened at 2003-03-07 11:31 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=699487&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Hash table improvement Initial Comment: This patch addresses two areas: 1) The current hash function ignores the high byte of UTF-16 characters. This is not good. 2) There is a cheap way to switch from the current method of linear probing (to resolve collisions) to the slightly better double hashing. Ad 1) hashing of wide characters: Currently, the algorithm is like this: h = h * 33 + (unsigned char)c; where h is the hash value and c is a character in the string argument (char or wchar_t). It seems this hashing algorithm belongs to a family of algorithms of the type: h = h * + character where is taken froma list of tried and proven values like 31, 33, 37, 41, 65599 which should be (but are not always) prime numbers. I added a wchar_t version (#ifdef XML_UNICODE) of this type: h = h * 65599 + (unsigned short)c; Ad 2) double hashing: Currently the hash table index is calculated from the hash value by masking out the lower bits according to table size. This works because the table size is a power of 2. But this also means that some bits of the hash value are unused. From these we can therefore generate the second hash value with little extra effort. The patch also updates the inlined hash table implementation used for detecting duplicate prefixed attributes (in function storeAtts()). See the attached file hashpatch1.diff (to be applied against xmlparse.c rev. 1.109). ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-08-28 16:32 Message: Logged In: YES user_id=290026 Added one more improvement (attached as hashpatch3.diff): Removed the need to initialize the hash table for the duplicate prefixed attributes check (see function storeAttributes()). The size of the hash table will be at least twice the largest number of prefixed attributes encountered in any one element. Once that element is processed, any subsequent call to storeAttributes() would need to clear the entire (large) hash table as long as there is at least one prefixed attribute. The solution was to add a version counter such that all hash table entries get a version flag, which is updated with every call to storeAttributes(). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-08-27 12:43 Message: Logged In: YES user_id=290026 Attached new patch file hashpatch2.diff. Includes changes suggested in comment from 2003-04-01. Also changed hash function to be closer to Python's string hash and improved comments on the inlined attributes hash table in storeAttributes(). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-04-01 12:50 Message: Logged In: YES user_id=290026 The last change is not necessary, since the cast to unsigned char takes care of overflow. It actually introduces a bug, since for small sizes the step size can now be larger than the table size. We can change back and write it like this: #define SECOND_HASH(hash, mask, power) \ ((((hash) & ~(mask)) >> ((power) - 1)) & ((mask) >> 2)) #define PROBE_STEP(hash, mask, power) \ ((unsigned char)((SECOND_HASH(hash, mask, power)) | 1)) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-28 20:40 Message: Logged In: YES user_id=290026 Further change for PROBE_STEP macro: To prevent overflow (the result should fit into one Byte) we replace "& (mask >> 2)" with "& (unsigned long)0xFF": #define BYTE_MASK ((unsigned long)0xFF) #define PROBE_STEP(hash, mask, power) \ ((unsigned char)((((hash) & ~(mask)) >> ((power) - 1)) \ & BYTE_MASK) \ | (unsigned char)(1)) which limits the maxium step size to 0xFF. Large steps are not a good idea anyway, since that might lead to cache misses. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-24 13:29 Message: Logged In: YES user_id=290026 Improvement to first patch version (hashpatch1.diff): For calculating second hash, don't overwrite the rightmost bit of the hash value's unused portion. This means: change ">> (power)" to ">> ((power) - 1)": #define PROBE_STEP(hash, mask, power) \ ((unsigned char)((((hash) & ~(mask)) >> ((power) - 1)) & ((mask) >> 2)) \ + | (unsigned char)(1)) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=699487&group_id=10127 From warrend at mdhost.cse.tek.com Fri Aug 29 10:53:49 2003 From: warrend at mdhost.cse.tek.com (Warren L Dodge) Date: Tue Sep 2 12:31:57 2003 Subject: [Expat-bugs] question about expat-1.95.6 on Solaris 8 Message-ID: <200308291653.h7TGrnnT019085@rosewood.cse.tek.com> I am building expat-1.95.6 on Solaris 8 with gcc-3.2.3 It seems to be making, however I get 79 of these at various points ../expat-1.95.6/lib/xmltok.c:1216: warning: `regparm' attribute directive ignored Are these really just a warning or is something wrong?