Config system errors at startup from script loading

[Jade-Fountain]

This should perhaps be fixed, but it isn't urgent. It might get in the way of other start-up error reporting.

Example:

ConfigTree::getParam(...): ACCESS ERROR:No such node (motion.scripts.SideKickRight.frame_10.joint_5.gain)
ConfigTree::getParam(...): ACCESS ERROR:No such node (motion.scripts.SideKickRight.frame_10.joint_6.position)
ConfigTree::getParam(...): ACCESS ERROR:No such node (motion.scripts.SideKickRight.frame_10.joint_6.gain)
ConfigTree::getParam(...): ACCESS ERROR:No such node (motion.scripts.SideKickRight.frame_10.joint_19.position)
ConfigTree::getParam(...): ACCESS ERROR:No such node (motion.scripts.SideKickRight.frame_10.joint_19.gain)
ConfigTree::getParam(...): ACCESS ERROR:No such node (motion.scripts.SideKickRight.frame_10.joint_20.position)
ConfigTree::getParam(...): ACCESS ERROR:No such node (motion.scripts.SideKickRight.frame_10.joint_20.gain)

[mmetcalfe]

These should definitely go away.
I'm planning on revisiting the Config System once i get this testing stuff set up, but i'll probably look into fixing these messages sooner.

[josiahw]

Good to talk to Trent about your thoughts for changes, as it is one their list for porting soonish :-)

Sent from my iPad

On 07/08/2013, at 10:00 PM, Mitchell notifications@github.com wrote:

These should definitely go away.
I'm planning on revisiting the Config System once i get this testing stuff set up, but i'll probably look into fixing these messages sooner.

—
Reply to this email directly or view it on GitHub.

[mmetcalfe]

My main goal for the Config System rewrite was to make it more flexible and extensible by making it far more object oriented through use of the Visitor Pattern.
I started a gist (here: https://gist.github.com/mitchellmetcalfe/5955226) to test out how the code would look, and am happy with it so far (although, obviously, it's in the very early stages).
Instead of attempting to deliver a config system that'll cater to everyone and everything out of the box, this approach would provide a few visitors that would store + retrieve simple config parameter types (within the existing tree structure), and if people wanted to store their own, more complex types, they would just have to write their own visitor (which are highly contained and convention based (which makes writing one relatively easy)).

[mmetcalfe]

Obviously, issues #8, #29, #30, and #31 should also be fixed - but they're less urgent.