Get task names from an orogen project

[g-arjones]

I am trying to get the task names defined in an orogen file and this is as far as could get:

class OrogenProject
    attr_reader :loader, :target
    def initialize(file)
        @loader = OroGen::Loaders::RTT.new
        @target = OroGen::Spec::Project.new(loader)
        target.define_default_deployments = false
        load file
    end

    def load(file)
        OroGen::Loaders::Project.new(target).__load__(file)
    end

    def tasks
        target.self_tasks.keys
    end
end

This only works if the tasks defined in the file do not have any external dependencies. How do I make it find whatever it needs or, even better, is there an easy way to ignore missing typekits/base tasks/deployments? I only want the task names, I don't care if there are stuff missing. Thanks!

[g-arjones]

I got it!

class OrogenProject
    attr_reader :project
    def initialize(file)
        @project = OroGen::Gen::RTT_CPP::Project.load(file, false)
    end

    def tasks
        project.self_tasks.map(&:name)
    end
end

Would have preferred something more quiet but it does the job.

[doudou]

OroGen::Gen::RTT_CPP::Project.load(file, false)

Do NOT use the Gen namespace in client code. For all intents and purposes, consider the whole Gen namespace a private namespace.

We can't add methods in an API to make every single possible use-case a one-liner. Generally speaking, getting information about a project means:

• create a loader
• load

It would help if you said what do you exactly want to do with the information, it's unclear to me ...

[g-arjones]

I tried what I mentioned in my first comment but that wasn't enough, I guess I need to somehow load the typekits also.

It would help if you said what do you exactly want to do with the information, it's unclear to me ...

I find my self often writing very similar scripts to run and debug components so I was building a tool for that and possibly integrate the functionality in a plugin for the IDE most of the team here use (select a task from a list and set that as a debug target).

[doudou]

integrate the functionality in a plugin for the IDE most of the team here use

This is Atom, right ? FYI, I started doing some work around Atom integration as well (github.com/rock-core/atom-build-autoproj). Moreover, I have (a lot of) plans to do a better Atom integration with Syskit. We should probably sync the end goals there...

I created a gitter room for rock-core a while back, but never used it (i.e. never publicized its existence), let's meet there to discuss how we can work on this together ?

[doudou]

To come back to what you want to do here: do you want to load an installed orogen file or one that is not yet installed ?

If it is installed, the loader is your entry point, not the Spec classes:

loader = OroGen::Loaders::RTT.new
project_model = loader.project_model_from_name('name_of_project')

You can also enumerate what's available without loading anything with the each_available_* methods on the loader:

project.each_available_deployed_task_name { |task_model_name| ... project.each_available_task_model_name { |task_model_name| ... }

If your goal is to debug tasks started by Syskit, the best would be to actually ask Syskit about the info. It knows better than you do about the PID-to-task-name mapping. Moreover, medium-term, I want to get rid of the dependency on the omniorb name service, which means that Syskit itself would become the "info repository" of the live system.

Generally speaking, I'm moving to replace all the existing orocos.rb-based CLI by some Syskit-based CLI. I.e. rock-run project::Task would become

syskit run task::Model [name]

which would either start a Syskit instance or connect to the local Syskit instance if it is present (therefore allowing an existing IDE to grab the task and work on it).

[g-arjones]

This is Atom, right ? FYI, I started doing some work around Atom integration as well (github.com/rock-core/atom-build-autoproj). Moreover, I have (a lot of) plans to do a better Atom integration with Syskit. We should probably sync the end goals there...

Actually, that would be VS Code. I think there are a lot of cool things that could be done w.r.t. rock/autoproj IDE integration, specially if you decide to provide apis for that in syskit. Would you consider porting your initial work to vscode instead (vscode extensions are built in TypeScript)? Personally, I think VS Code is a much more powerful editor IMO mainly because of: its integrated debugger, IntelliSense(tm) and some cool extensions

let's meet there to discuss how we can work on this together ?

👍

do you want to load an installed orogen file or one that is not yet installed ?

Since building and installing are too very tightly coupled steps in autoproj, I think either would work. What you suggested gives me even better results so I am sticking to that.

Generally speaking, I'm moving to replace all the existing orocos.rb-based CLI by some Syskit-based CLI

I like the sound of that, the only drawbacks I see is the increasing complexity in Syskit and it becoming a development tool rather than a very specialized manager/supervisor. Also, the fact that you are basically the only one working on syskit/roby/autoproj scares me a little (I am willing to become a more active contributor since I find these to be three (very) cool projects)

[g-arjones]

Could not find a rock-core room in gitter (i am g-arjones there as well)

[doudou]

Actually, that would be VS Code

I liked Atom because it is really easy to extend, and because you can tune it to go beyond "just an IDE". I didn't know about VSCode (apart from seeing it mentioned here and there). I'll try to have a look.

Personally, I think VS Code is a much more powerful editor IMO mainly because of: its integrated debugger, IntelliSense(tm) and some cool extensions

There is a decent integrated debugger in Atom as well (probably less powerful than what MS could provide, though). The CMake integration is more likely than not going to get in the way because Autoproj is the one handling the build/install cycle. Generally speaking, recent atom plugins often provide services that make functionality easy to use elsewhere (I.e. do a command "debug deployment X in gdb" is easy to make happen). Is that the case with VSCode as well ?

increasing complexity in Syskit

Actually, I don't see any. What would become more complex (I prefer "complete" :P) is the interface. We will probably have to add a REST API directly inside the Syskit instance to make the integration with Atom or VSCode easier - there's one already that goes through the interface server, but I'd rather have it in-process. The rest of the system is already there to do most of the heavy lifting (i.e. the state tracking). I've created a project on github for the overall runtime aspects (not "IDE" yet) - and to test GitHub's project feature.

https://github.com/rock-core/tools-syskit/projects/1

Have a look and tell me what you think. Have I added you already as collaborator to Syskit and Roby ?

Also, the fact that you are basically the only one working on syskit/roby/autoproj scares me a little (I am willing to become a more active contributor since I find these to be three (very) cool projects)

Welcome to the club (and thanks a LOT for your work these last weeks) ! This situation will very probably change very quickly. Syskit+Rock will most likely become a central part at Kraken, and will therefore see some investment.

[doudou]

Gitter room is there: https://gitter.im/rock-core. Not sure why you can't find it :( I'm new to gitter, so I might have messed up with the configuration. Went through most settings, but couldn't find something that matches.

[g-arjones]

I liked Atom because it is really easy to extend, and because you can tune it to go beyond "just an IDE"

I can't compare how easy they are because I don't have enough experience with neither but from what I have seen in VS Code, it looks pretty straightforward and, given who is behind the project, vs code is pretty damn well documented (support is great as well). Extensions are capable of providing services for other extensions and MS itself provides some functionalities (C++ language support) as extensions.

(I.e. do a command "debug deployment X in gdb" is easy to make happen). Is that the case with VSCode as well ?

Yes, you can run commands in gdb and you have pre launch tasks that can be either shell commands or processes (with state tracking through regexps)

We will probably have to add a REST API directly inside the Syskit instance to make the integration with Atom or VSCode easier

Yeah, well, I fear seeing bad stuff happening due to a bug in this interface (we have seen that in flatfish, when the connection was lost while the ide was running, if I remember it correctly)

Have I added you already as collaborator to Syskit and Roby ?

Nope.

Syskit+Rock will most likely become a central part at Kraken, and will therefore see some investment.

Please, have a team dedicated to documentation (excuse my intrusion :P). The lack of documentation is an obvious non-starter for some (most?) people, specially in complex projects.

[doudou]

Please, have a team dedicated to documentation (excuse my intrusion :P). The lack of documentation is an obvious non-starter for some (most?) people, specially in complex projects.

Well ... do you believe that I spent weeks (probably > 1.5 months so far) on https://github.com/doudou/rock_website because I believe documentation isn't important ? ;-)

[doudou]

Yeah, well, I fear seeing bad stuff happening due to a bug in this interface (we have seen that in flatfish, when the connection was lost while the ide was running, if I remember it correctly)

We will have to have some form of communication within Syskit to allow for any form of remote control, so whatever the way it's implemented, it will have to be there. The "bad behavior" in FF was due to the Syskit write-side being blocking instead of non-blocking.

[doudou]

Yes, you can run commands in gdb and you have pre launch tasks that can be either shell commands or processes (with state tracking through regexps)

Wasn't the idea. The autoproj plugin I wrote can ask for "a binary with arguments" to be debugged. Since Autoproj is one that knows where the binary is (or, in the case of a rock-run equivalent, which arguments need to be passed), I found it pretty cool.

In any case, I'll give a try to VSCode as well. We'll see ...

[g-arjones]

Well ... do you believe that I spent weeks (probably > 1.5 months so far) on https://github.com/doudou/rock_website because I believe documentation isn't important ? ;-)

Hahah, obviously not and I don't see myself doing what you are doing there so 👍 for the effort. I just wanted to be another voice screaming for documentation here in case anyone other than you is reading this.

In any case, I'll give a try to VSCode as well. We'll see ...

Let me know your thoughts once you do. I am willing to reconsider my vs code preference if you can convince me (you probably know that's not easy by now :P)