Re: sax/DTDHandler.hpp missing #include

If it includes any other headers, then its probably getting it from those. We never really made it a major goal that every header would compile standalone, so its quite possible that some headers, used in some ways, might require other includes. -- Dean Roddey The CIDLib C

sax/DTDHandler.hpp missing #include

Hey All, When I was going through the SAX API for Xerces-Perl, I noticed that all the other headers had '#include ', except DTDHandler.hpp. This seems like an oversight. jas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For addi

RE: seg fault with DOMParser::parse

what does errReporter point to? -Original Message- From: Xiaobing Wu [mailto:[EMAIL PROTECTED]] Sent: Monday, April 16, 2001 4:54 PM To: [EMAIL PROTECTED] Subject: seg fault with DOMParser::parse I run a simple experimental DOM parser program under linux with xerces-c1_4. There's no pro

Re: seg fault with DOMParser::parse

Given that 99.% of the code that runs in your program is inside the parse() method, that still leaves a lot of territory to cover. If its your own build, I'd suggest that you work the problem with the debugger and see what you can figure out. -- Dean Roddey The CIDLib

seg fault with DOMParser::parse

I run a simple experimental DOM parser program under linux with xerces-c1_4. There's no problem with compiling, but when I run the program, it finishes up with seg fault and no other error information. I used GDB to debug the program, and found the bug lies in the parse function. The code of the

Re: Xerces 1.4.0 on MacOS X

Hello Joannes, Thank you for your interest in getting Xerces 1.4 to compile with the Mac OS X command line tools. I've looked at your changes, and believe they can be integrated with little effort. Your changes are in two areas: (a) Updates to the Mac-specific code to support the Mac OS X fina

Re: file status after parse

If you do a progressive parse, and stop before the end, it will remain open until you call the reset method. If you do a regular parse, or a progressive parse that successfully goes all the way to the end, it flushes all entities on the way out, which will close the file.

file status after parse

After I parse the source file, is the file still open? I'm trying to rename it for archive and I get an errno of 13 (EACCES). thanks...charlie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL P

Re: Progressive SAX parsing and memory

> Are you transcoding any data out of the SAX events? If so, are you deleting > the returned text? In other words, you agree with my thinking that progressive parsing doesn't keep eating memory and, therefore, the problem is in my code somewhere, which is fair enough. :) I believe that yes, I am

Re: Progressive SAX parsing and memory

Are you transcoding any data out of the SAX events? If so, are you deleting the returned text? -- Dean Roddey The CIDLib C++ Frameworks Charmed Quark Software [EMAIL PROTECTED] http://www.charmedquark.com "Why put off until tomorrow what you can put off until the day afte

Progressive SAX parsing and memory

Hello, I am using progressive sax parser to parse an incoming and potentially very long tcp stream (with my own input source class). In pseudo code this would look like this, of course: parser.parseFirst (input_source, token) while (! end of stream) { if (! pars

[Bug 1345] New - BinHTTPURLInputStream ignoring query params

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1345 *** shadow/1345 Mon Apr 16 12:13:42 2001 --- shadow/1345.tmp.5842Mon Apr 16 12:13:42 2001 *** *** 0 --- 1,233 + ++ + | BinHTTPURLInputSt

[Bug 1262] Changed - Can't delete the pointer returned by DOMString::transcode()

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1262 *** shadow/1262 Mon Apr 9 07:03:14 2001 --- shadow/1262.tmp.4087Mon Apr 16 11:23:00 2001 *** *** 2,9 | Can't delete the pointer returned by DOMString::transcode()| +---

[Bug 1327] Changed - DOMParser crashes if XML source has damaged structure.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1327 *** shadow/1327 Thu Apr 12 13:38:31 2001 --- shadow/1327.tmp.3708Mon Apr 16 11:09:57 2001 *** *** 18,21 content the parser does not throw an exception. It crashes. In debug mode VisualStudio 6.0 give me some more

RE: DOM_Node::cloneNode() clones not getting released?

Correct, the object "row" is going out of scope almost immediately after this call. I've tried setting it to NULL and that doesn't change behavior. I've also added a line to set the clone object to NULL, again with no changes to the leak. I'm using Xerces-C 1.4.0. Thanks -Evan -Original Me