2.2.0 Changes on rtt/ocl master with regard to paths/imports/scripting

Warning: master is somewhat unstable as a lot of stuff got merged in the last
days and some caveats are out there. Don't upgrade your critically-imporant
demo setup to it :-)

See my attempt to document scripting-style deployments on
http://www.orocos.org/wiki/orocos/toolchain/getting-started/toolchain-
tutorials/configuring-and-starting-components-orocos
for context.

There are three major changes for 2.2.0:
1. import() and path() statements in the deployment component's xml or API
allow to separately specify paths to search for components and imports to load
packages (directories) with components. Adding a path() will never fail. An
unresolved import *will* fail. If the (default) RTT_COMPONENT_PATH works for
you, you don't need to use 'path' and can just keep using import statements.
An import statement can be of two types:
- specify a full filename. It will be loaded directly as a component
- specify a directory or ros package name. It will look for that directory in
the search path, specified with the RTT_COMPONENT_PATH and the 'path()'
statements. If found, it will load the components in that directory/package
and in case of ros, also its dependencies if these were not loaded already. If
it has a types or plugins subdir, these will be loaded too.

The purpose of this change is to have better error reporting, diagnostics and
a cleaner (more explicit) syntax.

2. connecting ports in the DC
I have created the connect("service.port","service.port", policy) and
stream("service.port",policy) operations. connectTwoPorts, createStream and
connectPorts have been deprecated, but are still available.

3. Scripting

First of all, the unified script parsing has been added to master such that you
can mix normal statements with program scripts and state machines. I announced
this before.

When writing the tutorial, I hit the long overdue missing 'print' statement
bug in the scripting language. The problem is that we can only extend the
scripting 'commands' by defining new components, but not the language itself. I
didn't want to do the latter, so I added a GlobalService::Instance() which is
process-local and *not* distributable, which will contain:

- all process-local variables/enums like 'SendStatus', 'LogLevel' etc. The
TaskBrowser can then complete these and scripts can refer to these as plain
variables. This will replace the 'GlobalsRepository' which already existed
soon.
- a "bool require(string)" operation that takes a service name as argument. It
will load a 'free' service (not attached to a component) in the current
process, if this hasn't been done before. The Global ExecutionEngine (which
already exists) will execute the asynchronous operations of that service, if
any.
- A factory function to the ORO_SERVICE_NAMED_PLUGIN macro such that a 'free'
service can be created, without being attached to a TaskContext. This now
effectively distanciates a 'service' from a 'plugin'.
- The PrintingService "print" which is part of OCL.

Concretely, if you would write:

import("ocl")                 // finds ocl + loads its services and plugins
require("print")             // loads the 'print' service in this process
print.ln("prints a line")  // uses the print service
print.err("prints a line to std err.")
print.log(Error, "prints a line to Orocos logger with loglevel Error")


that would work. For example, you can also have:

help require
require("print")
help print


in the TaskBrowser.

This change is only intrusive to Scripting, No other parts depend on it,
although future RTT extensions may depend on it too.

People had asked me if a 'math' package couldn't be added to the scripting
language. With this change, that becomes trivial, since you don't have to load
that service in a specific component, but can have it as a 'require' statement
on top of your script, and it will become available in your current process.

I'm about to push this in the next days to master. I'm a bit worried about the
competing features we're providing from different contributors to the RTT. On
the other hand, people are using these destinct mechanisms, depending on their
use case, so I don't want to block the resolution of an issue because we
haven't sorted out the global picture yet.

Peter

2.2.0 Changes on rtt/ocl master with regard to paths/imports/scr

On Nov 22, 2010, at 10:05 , Peter Soetens wrote:

>
> Warning: master is somewhat unstable as a lot of stuff got merged in the last
> days and some caveats are out there. Don't upgrade your critically-imporant
> demo setup to it :-)
>
> See my attempt to document scripting-style deployments on
> http://www.orocos.org/wiki/orocos/toolchain/getting-started/toolchain-
> tutorials/configuring-and-starting-components-orocos
> for context.
>
>
> There are three major changes for 2.2.0:
> 1. import() and path() statements in the deployment component's xml or API
> allow to separately specify paths to search for components and imports to load
> packages (directories) with components. Adding a path() will never fail. An
> unresolved import *will* fail. If the (default) RTT_COMPONENT_PATH works for
> you, you don't need to use 'path' and can just keep using import statements.
> An import statement can be of two types:
> - specify a full filename. It will be loaded directly as a component
> - specify a directory or ros package name. It will look for that directory in
> the search path, specified with the RTT_COMPONENT_PATH and the 'path()'
> statements. If found, it will load the components in that directory/package
> and in case of ros, also its dependencies if these were not loaded already. If
> it has a types or plugins subdir, these will be loaded too.
>
> The purpose of this change is to have better error reporting, diagnostics and
> a cleaner (more explicit) syntax.
>
> 2. connecting ports in the DC
> I have created the connect("service.port","service.port", policy) and
> stream("service.port",policy) operations. connectTwoPorts, createStream and
> connectPorts have been deprecated, but are still available.
>
> 3. Scripting
>
> First of all, the unified script parsing has been added to master such that you
> can mix normal statements with program scripts and state machines. I announced
> this before.
>
> When writing the tutorial, I hit the long overdue missing 'print' statement
> bug in the scripting language. The problem is that we can only extend the
> scripting 'commands' by defining new components, but not the language itself. I
> didn't want to do the latter, so I added a GlobalService::Instance() which is
> process-local and *not* distributable, which will contain:
>
> - all process-local variables/enums like 'SendStatus', 'LogLevel' etc. The
> TaskBrowser can then complete these and scripts can refer to these as plain
> variables. This will replace the 'GlobalsRepository' which already existed
> soon.
> - a "bool require(string)" operation that takes a service name as argument. It
> will load a 'free' service (not attached to a component) in the current
> process, if this hasn't been done before. The Global ExecutionEngine (which
> already exists) will execute the asynchronous operations of that service, if
> any.
> - A factory function to the ORO_SERVICE_NAMED_PLUGIN macro such that a 'free'
> service can be created, without being attached to a TaskContext. This now
> effectively distanciates a 'service' from a 'plugin'.

Could something like this, or similar, be used to instantiate different time services?

> - The PrintingService "print" which is part of OCL.
>
> Concretely, if you would write:
> 
> import("ocl")                 // finds ocl + loads its services and plugins
> require("print")             // loads the 'print' service in this process
> print.ln("prints a line")  // uses the print service
> print.err("prints a line to std err.")
> print.log(Error, "prints a line to Orocos logger with loglevel Error")
>
>
> that would work. For example, you can also have:
> 
> help require
> require("print")
> help print
>
>
> in the TaskBrowser.
>
> This change is only intrusive to Scripting, No other parts depend on it,
> although future RTT extensions may depend on it too.

Is there any current or planned capability to access environment variables within scripting? With systems with lots of configuration options, being able to do "if env{ROBOT_IS_HARDWARE} then ... else ... fi" style deployment conditionals would really help.

> People had asked me if a 'math' package couldn't be added to the scripting
> language. With this change, that becomes trivial, since you don't have to load
> that service in a specific component, but can have it as a 'require' statement
> on top of your script, and it will become available in your current process.
>
> I'm about to push this in the next days to master. I'm a bit worried about the
> competing features we're providing from different contributors to the RTT. On
> the other hand, people are using these destinct mechanisms, depending on their
> use case, so I don't want to block the resolution of an issue because we
> haven't sorted out the global picture yet.

This sounds like a big step in a good direction ... looking forward to trying it .... sometime in 2011 .... :-)
S

2.2.0 Changes on rtt/ocl master with regard to paths/imports/scr

On Mon, Nov 22, 2010 at 07:48:08PM +0100, S Roderick wrote:
> On Nov 22, 2010, at 10:05 , Peter Soetens wrote:

> > This change is only intrusive to Scripting, No other parts depend on it,
> > although future RTT extensions may depend on it too.
>
> Is there any current or planned capability to access environment
> variables within scripting? With systems with lots of configuration
> options, being able to do "if env{ROBOT_IS_HARDWARE} then ... else
> ... fi" style deployment conditionals would really help.

rttlua -e "print( os.getenv('PWD') )"
/home/mk

;-)

Markus