Changes between Version 1 and Version 2 of WikiStart/CPPLayer
- Timestamp:
- 05/20/15 16:11:18 (6 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
WikiStart/CPPLayer
v1 v2 8 8 * Extend orocos.cpp layer with model layer 9 9 * Use cpp model layer to use it for dynamic_properties and the orocos.rb extension 10 * ??? What does this mean ? 10 11 * make ruby-binding for this part that allows ruby-tooling the model checking 11 *12 * '''Sylvain''' there is zero interest from my side in using C++ bindings from the Ruby tooling. I do plan to extend the '''use of models''' in the ruby tooling, and a transition like this would most likely hold these plans back a few years, with zero benefit (only cost, a.k.a. the reduced speed of development as one now needs to modify C++ *and* the bindings, plus the inability to move away from the CRuby implementation to more realtime-friendly ones such as e.g. JRuby). The ruby side of things really has no need for this, using C++ bindings is really only adding problems and complexity. 12 13 * Create model-files from orogen 13 14 * create (yml?) Task-description files from orogen that can be parsed and somewhere outside the ruby tooling … … 15 16 === Future thoughts === 16 17 * Use language independent descriptions between parts of syskit (work of AG-Framework) 18 '''Sylvain''' This is non-sensical. You can create language-independent representations and add the ability for Syskit to load and save them. Using them as the mean of communication between the Syskit modules would basically be: marshal roby plan into independent representation -> pass independent representation -> unmarshal roby plan from independent representation. This is as dumb as making the yml-representation the way to load models in orocos.rb/syskit: both libraries use orogen to represent their models, using orogen's native representation is really a lot less dumb than using some marshalled version of it. 17 19