Re: [Flightgear-devel] [RFC][PATCH] SimGear: property system bug

2005-05-09 Thread Andy Ross
Melchior FRANZ wrote:
> To fix that I added a clear() method to SGPropertyNode, which does
> first call private clear_node() and then sets the type to NONE. Only
> now a new type can get assigned. This new method is called from the
> XML handler's startElement()

This looks good to me.  It only does the "type forcing" for nodes that
are (re-) read from a XML file, which is almost certainly correct in
all cases.

Andy

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] [RFC][PATCH] SimGear: property system bug

2005-05-09 Thread Curtis L. Olson
Melchior,
David Megginson isn't currently subscribed to the list, but he is the 
architect of the property system, so it is probably a good idea to run 
this past him before a final commit.

Regards,
Curt.
Melchior FRANZ wrote:
Vivian pointed out that a redefined Ctrl-U key binding didn't work
correctly. I found out that this is, because the definition in
$FG_ROOT/keyboard.xml sets  for binding[1],
and ... [better sit down first!] ... and assigning 
in a *-set.xml file doesn't *really* set "double" as new type!
Instead, the boolean is kept, and a double sqeezed into it. In other
words: once tainted as bool, you can throw all doubles in the universe
on a property node, and all it will accept is 0 and 1. Without warning!
To fix that I added a clear() method to SGPropertyNode, which does first
call private clear_node() and then sets the type to NONE. Only now a new
type can get assigned. This new method is called from the XML
handler's startElement() (which fixes the Ctrl-U bug), and while I
was at it, from removeChild(), where it makes sense, too. setDoubleValue()
alone, for instance, does of course still not change a node type to
double. Patch attached.
Does anyone have objections? Better solutions? (code preferred! :-)
m.


PS: is it just me or is sg/fgfs grossly over-commented?! It's not
   uncommon to see things like:
   // set node value to 0.0
   node->setDoubleValue(0.0);
   I add these silly comments, too, if it's the style of the file,
   but it always costs me some nerves. (No need to tell me that this
   is better than too *few* comments, which is an entirely different
   story.  :-}
 


Index: props.cxx
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/props/props.cxx,v
retrieving revision 1.7
diff -u -p -r1.7 props.cxx
--- props.cxx	23 Dec 2004 13:32:01 -	1.7
+++ props.cxx	9 May 2005 12:08:55 -
@@ -923,6 +923,7 @@ SGPropertyNode::removeChild (const char 
vector::iterator it = _children.begin();
it += pos;
SGPropertyNode_ptr node = _children[pos];
+node->clear();
_children.erase(it);
if (keep) {
  _removedChildren.push_back(node);
Index: props.hxx
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/props/props.hxx,v
retrieving revision 1.6
diff -u -p -r1.6 props.hxx
--- props.hxx	23 Dec 2004 13:32:01 -	1.6
+++ props.hxx	9 May 2005 12:08:56 -
@@ -1172,6 +1172,12 @@ public:
  void fireChildRemoved (SGPropertyNode * child);

+  /**
+   * Clear node, so that a new type can get assigned.
+   */
+  void clear () { if (!_tied) { clear_value(); _type = NONE; } }
+
+
protected:
  void fireValueChanged (SGPropertyNode * node);
Index: props_io.cxx
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/props/props_io.cxx,v
retrieving revision 1.7
diff -u -p -r1.7 props_io.cxx
--- props_io.cxx23 Dec 2004 13:32:01 -  1.7
+++ props_io.cxx9 May 2005 12:08:56 -
@@ -173,6 +173,7 @@ PropsVisitor::startElement (const char *
// Got the index, so grab the node.
SGPropertyNode * node = st.node->getChild(name, index, true);
+node->clear();
// Get the access-mode attributes,
// but don't set yet (in case they
 


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

--
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] [RFC][PATCH] SimGear: property system bug

2005-05-09 Thread Jim Wilson
Sounds good.  Are there any performance implications?  Off hand it doesn't 
sound like it.  Maybe a test doing a bunch of switches back and forth between 
different types just to check for leakage would be good.  Am I right though 
that since the SetXXXValue alone won't change, this clear will not be done 
frequently?  Or do we have code that will (maybe incorrectly) do this every 
frame?

Maybe cc a copy of your proposal to David Megginson would be a good idea.

Best,

Jim

> -Original Message-
> From: Melchior FRANZ <[EMAIL PROTECTED]>
> Sent: Monday, 9. May 2005 8:13 -0400
> To: flightgear-devel@flightgear.org
> Subject: [Flightgear-devel] [RFC][PATCH] SimGear: property system bug
> 
> Vivian pointed out that a redefined Ctrl-U key binding didn't work
> correctly. I found out that this is, because the definition in
> $FG_ROOT/keyboard.xml sets  for binding[1],
> and ... [better sit down first!] ... and assigning 
> in a *-set.xml file doesn't *really* set "double" as new type!
> 
> Instead, the boolean is kept, and a double sqeezed into it. In other
> words: once tainted as bool, you can throw all doubles in the universe
> on a property node, and all it will accept is 0 and 1. Without warning!
> 
> To fix that I added a clear() method to SGPropertyNode, which does first
> call private clear_node() and then sets the type to NONE. Only now a new
> type can get assigned. This new method is called from the XML
> handler's startElement() (which fixes the Ctrl-U bug), and while I
> was at it, from removeChild(), where it makes sense, too. setDoubleValue()
> alone, for instance, does of course still not change a node type to
> double. Patch attached.
> 
> Does anyone have objections? Better solutions? (code preferred! 
> 
> m.
> 
> 
> 
> 
> 
> PS: is it just me or is sg/fgfs grossly over-commented?! It's not
> uncommon to see things like:
> 
> // set node value to 0.0
> node->setDoubleValue(0.0);
> 
> I add these silly comments, too, if it's the style of the file,
> but it always costs me some nerves. (No need to tell me that this
> is better than too *few* comments, which is an entirely different
> story.  :-}
> ___
> 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