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")
> 

> help require
> require("print")
> help print
> 

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