RE: [Flightgear-devel] EasyXML problem?
> That sounds like the right approach to me (and I'm an expert because I > took a compilers class 15 years ago and we used the "Dragon book".) :-) > > Curt. I stayed at a Holiday Inn Express, once ... :-) Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] EasyXML problem?
Jon Berndt wrote: OK, I fixed the problem. Here's what I do now in FGXMLParse (my XMLVisitor-derived class): startElement(): Here I simply set the working string to the null string. data(): Here I append the string that is passed in to the current working string, working_string += string(s, length); endElement(): Here is where more work is done. When execution gets to here, the working string could be composed of several lines (with embedded spaces and newlines). I work through this string, finding each line until there are no more lines. That sounds like the right approach to me (and I'm an expert because I took a compilers class 15 years ago and we used the "Dragon book".) :-) Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] EasyXML problem?
> The problems were twofold: > > 1) I was not correctly allowing for split chunks (multiple data() calls). > 2) I need to have table data as it is, now. > > Almost fixed. But, the kids are up and it's time for breakfast... > > Jon OK, I fixed the problem. Here's what I do now in FGXMLParse (my XMLVisitor-derived class): startElement(): Here I simply set the working string to the null string. data(): Here I append the string that is passed in to the current working string, working_string += string(s, length); endElement(): Here is where more work is done. When execution gets to here, the working string could be composed of several lines (with embedded spaces and newlines). I work through this string, finding each line until there are no more lines. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] EasyXML problem?
> On Wed, 29 Dec 2004 08:06:13 -0600, Jon Berndt <[EMAIL PROTECTED]> wrote: > > > It appears that entire tables could be read in as one data chunk. I need to > do processing > > in that case and "manually" separate the data rows. I think I've almost got > > this one > > figured out. > > Sounds good. The main problem is that you're doing this the hard way, > working with low-level XML markup events instead of the high-level > property interface -- I understand, though, that you want to control > the markup at the element/attribute level, so I guess there's no > choice. > > David The problems were twofold: 1) I was not correctly allowing for split chunks (multiple data() calls). 2) I need to have table data as it is, now. Almost fixed. But, the kids are up and it's time for breakfast... Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] EasyXML problem?
On Wed, 29 Dec 2004 08:06:13 -0600, Jon Berndt <[EMAIL PROTECTED]> wrote: > It appears that entire tables could be read in as one data chunk. I need to > do processing > in that case and "manually" separate the data rows. I think I've almost got > this one > figured out. Sounds good. The main problem is that you're doing this the hard way, working with low-level XML markup events instead of the high-level property interface -- I understand, though, that you want to control the markup at the element/attribute level, so I guess there's no choice. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] EasyXML problem?
> OK, I think I've figured out what the mitigating circumstance is. I can avoid > "digesting" > strings composed purely of blank spaces and newlines, but this seems to > create a problem > with table constructs: > > > Yaw moment due to beta > > aero/qbar-psf > metrics/Sw-sqft > metrics/bw-ft > > aero/beta-rad > > -0.349 -0.0227 >0.0 0.0 >0.349 0.0227 > > > > > > I need each line of tableData to be read in and stored as a separate string. > What fixes > the first problem I reported seems to cause a second, whereby the tableData > stored ends up > looking like this: > > -0.349 -0.0227 0.0 0.0 >0.349 0.0227 It appears that entire tables could be read in as one data chunk. I need to do processing in that case and "manually" separate the data rows. I think I've almost got this one figured out. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] EasyXML problem?
> No, there is no guarantee that the string will be non-empty (that goes
> down to the underlying XML library). Again, make sure that you set
> value = "" at the start event, and then process value at the
> corresponding end event.
>
> David
OK, I think I've figured out what the mitigating circumstance is. I can avoid
"digesting"
strings composed purely of blank spaces and newlines, but this seems to create
a problem
with table constructs:
Yaw moment due to beta
aero/qbar-psf
metrics/Sw-sqft
metrics/bw-ft
aero/beta-rad
-0.349 -0.0227
0.0 0.0
0.349 0.0227
I need each line of tableData to be read in and stored as a separate string.
What fixes
the first problem I reported seems to cause a second, whereby the tableData
stored ends up
looking like this:
-0.349 -0.0227 0.0 0.0
0.349 0.0227
That is, some of the lines are read in together. This is why it is so
imperative for me to
understand the mechanics of how the data() function works and what can be
passed in.
Here's what I have now for relevant parts of the functions:
startElement()
{
working_string.erase();
}
endElement()
{
if (!working_string.empty()) current_element->AddData(working_string);
working_string.erase();
}
data()
{
data_string = string(s, length);
working_string += data_string;
}
Any suggestions?
Jon
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] EasyXML problem?
What are the assumptions I can make about the string that is passed into the
call to
data()?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of David
> Megginson
> Sent: Tuesday, December 28, 2004 9:30 PM
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] EasyXML problem?
>
>
> On Tue, 28 Dec 2004 19:41:55 -0600, Jon Berndt <[EMAIL PROTECTED]> wrote:
>
> > void FGTrafficManager::data (const char * s, int len)
> > {
> > string token = string(s,len);
> > if (( token.find(" ") == string::npos
> > && (token.find('\n')) == string::npos))
> > {
> > value += token;
> > } else {
> > value = string("");
> > }
> > }
>
> No, there is no guarantee that the string will be non-empty (that goes
> down to the underlying XML library). Again, make sure that you set
> value = "" at the start event, and then process value at the
> corresponding end event.
>
>
> All the best,
>
>
> David
>
> --
> http://www.megginson.com/
>
> ___
> Flightgear-devel mailing list
> Flightgear-devel@flightgear.org
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> 2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] EasyXML problem?
On Tue, 28 Dec 2004 19:41:55 -0600, Jon Berndt <[EMAIL PROTECTED]> wrote:
> void FGTrafficManager::data (const char * s, int len)
> {
> string token = string(s,len);
> if (( token.find(" ") == string::npos
> && (token.find('\n')) == string::npos))
> {
> value += token;
> } else {
> value = string("");
> }
> }
No, there is no guarantee that the string will be non-empty (that goes
down to the underlying XML library). Again, make sure that you set
value = "" at the start event, and then process value at the
corresponding end event.
All the best,
David
--
http://www.megginson.com/
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] EasyXML problem?
> Make sure you blank the string at the start tag.
>
> David
Here's what's in the Traffic Manager:
void FGTrafficManager::data (const char * s, int len)
{
string token = string(s,len);
if (( token.find(" ") == string::npos
&& (token.find('\n')) == string::npos))
{
value += token;
} else {
value = string("");
}
}
So, it looks like in this case value is set to the null string if the data()
call is
passed anything with a space or carriage return in it. That seems wierd. If
there are
spaces in between tag delimeters that would cause a Bad Thing, it seems to me.
I've seen
this on occasion:
fdm/roll-rate
Is this in bad form? Should it cause a crash, or should it be handled?
Now, going back to the function call data(), it appears that if the carriage
return or
space is not found in the string, it is appended to a "working string".
Jon
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] EasyXML problem?
On December 28, 2004 05:07 pm, Jon Berndt wrote: > I thought that sounded reasonable and tried that this morning. But, it > still doesn't seem to work - in fact (at least the way I'm doing it) it > seems worse that way. A quick glance seems to suggest (rightly or wrongly) > that _everything is treated as "data" at one time or another. Maybe I need > to take another look at this approach. I'll give a more thorough report > later. > > Jon May be you need to add an extra line at the end. Just a random guess. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] EasyXML problem?
On Tue, 28 Dec 2004 16:07:19 -0600, Jon Berndt <[EMAIL PROTECTED]> wrote: > I thought that sounded reasonable and tried that this morning. But, it still > doesn't seem > to work - in fact (at least the way I'm doing it) it seems worse that way. A > quick glance > seems to suggest (rightly or wrongly) that _everything is treated as "data" > at one time or > another. Maybe I need to take another look at this approach. I'll give a more > thorough > report later. Make sure you blank the string at the start tag. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] EasyXML problem?
> Collect it in an STL string and then process it when you see the end tag. > > David I thought that sounded reasonable and tried that this morning. But, it still doesn't seem to work - in fact (at least the way I'm doing it) it seems worse that way. A quick glance seems to suggest (rightly or wrongly) that _everything is treated as "data" at one time or another. Maybe I need to take another look at this approach. I'll give a more thorough report later. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] EasyXML problem?
On Tue, 28 Dec 2004 12:43:27 -0600, Jon S Berndt <[EMAIL PROTECTED]> wrote: > So, I guess I've been lucky so far that the data I have gotten - > except in this particular case - has been chunked together. I'm a > little stumped as to how I can make sure that I get all the data for > an element and store it as an STL string for later reading. Collect it in an STL string and then process it when you see the end tag. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] EasyXML problem?
On Tuesday 28 December 2004 19:43, Jon S Berndt wrote: > I've encountered an unexpected problem with the class I have derived > from EasyXML. In one of the configuration files I have, the following > lines are present: > > > Yaw moment due to rudder > > aero/qbar-psf > metrics/Sw-sqft > metrics/bw-ft > fcs/rudder-pos-rad > -0.043 > > > > When I parse this construct I find that the last tagged property does > not get parsed correctly. What happens as the program is actually run > shows this: > > DATA LINE: ***=>fcs/rudde<=*** >Parsing property name: fcs/rudde > FGPropertyManager::GetNode() No node found for fcs/rudde > John, I seem to remember running into similar problems. Have a look at src/Traffic/TrafficMgr.cxx in FlightGear for a workaround. IIRC, easyxml reads the data in blocks, and at the border between two blocks you need to merge the data yourselves. Or something like that. It's been a while since I wrote that, so my memory is a bit rusty. HTH, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] EasyXML problem?
I've encountered an unexpected problem with the class I have derived
from EasyXML. In one of the configuration files I have, the following
lines are present:
Yaw moment due to rudder
aero/qbar-psf
metrics/Sw-sqft
metrics/bw-ft
fcs/rudder-pos-rad
-0.043
When I parse this construct I find that the last tagged property does
not get parsed correctly. What happens as the program is actually run
shows this:
DATA LINE: ***=>fcs/rudde<=***
Parsing property name: fcs/rudde
FGPropertyManager::GetNode() No node found for fcs/rudde
You can see that the "fcs/rudder-pos-rad" property name is only
partially read. If I go back and look at the overridden data()
function in my XMLVisitor-derived class, I see that I did this:
void FGXMLParse::data (const char * s, int length)
{
const char *local_string = s;
data_string = local_string;
data_string.resize(length);
if (data_string.find_first_of(VALID_CHARS) != string::npos)
current_element->AddData(data_string);
}
I know it's not pretty and certainly better approaches are solicited
from readers. Reading the documentation in the props.hxx file I see
this:
* Note that character data may be chunked arbitrarily: the
* character data content of an element may be returned in one
* large chunk or several consecutive smaller chunks.
So, I guess I've been lucky so far that the data I have gotten -
except in this particular case - has been chunked together. I'm a
little stumped as to how I can make sure that I get all the data for
an element and store it as an STL string for later reading.
Suggestions?
Jon
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
