>> What I'd like to do first and foremost is split the ruby code out of >> the C++ library. This would make the development cycle in Ruby that >> much more streamlined (documentation, gemification & tests) > > Would you also put language bindings into a separate library?
I'm less clear-cut on that, as the bindings are definitely related to the core library (a.k.a. I don't mind either way). It would definitely make it easier on the build side. >> tools/modelkit-transformer: what's currently the non-syskit bits of >> drivers/transformer/ruby >> tools/syskit-transformer: drivers/transformer/ruby/syskit/* >> tools/orogen-transformer: the transformer/orogen plugin > > Why using modelkit-* and not e.g. transformer_ruby as already used for > other packages? Because modelkit-transformer is not transformer_ruby the way frame_helper_ruby is related to frame_helper. It's actual relationship with drivers/transformer is very loose. And also because I'd like to gather the "modelling of components" under the same hood. Long-term, the OroGen::Spec and OroGen::Loader would go there as well as e.g. modelkit-component and modelkit-component-rtt > I would prefer something like syskit-plugin- and orogen-plugin- for clarity I thought about that. I was following the rubygems convention (XXX-YYY is YYY plugin for XXX). Moreover, I would rather not put the syskit/transformer plugin code in the Syskit::Plugin::Transformer namespace, sticking with Syskit::Transformer (again, a common convention in the Ruby world). > Any example for what runkit is supposed to contain? The low-level runtime bits related to running, visualization and replay. Long term, hopefully, a generalized and fully unit-tested orocos.rb layer, e.g. runkit runkit-rtt runkit-async runkit-pocolog Regarding the SDF/Gazebo stuff runkit-sdf # starting gazebo, setting up a vizkit3d by connecting to a SDF instance, ... >> I'm open for better ideas. It does split the code in smaller units - >> against which there was a strong feeling at the origin of Rock - but >> I've seen that explaining where is everything is REALLY hard right >> now, simply because loosely-related things ended up being bundled >> together. > > I would add: because related things are sometimes not clearly or easily > identifiable. So your proposal would solve that in parts e.g. by > exposing the plugins a bit more. Absolutely. Sylvain _______________________________________________ Rock-dev mailing list Rock-dev@dfki.de http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
