scripting: opDot vs. getMember?

Dear List,

I'm wondering what is the preferred way to update DataSources from
scripting. There seem to be two options: opDot and getMember. I recall
Peter stating that getMember is "highly non-realtime", while opDot
is. However I understand the latter needs explicit typekit support.
How does the rtt-scripting and the TaskBrowser handle this? Use opDot
if possible, else fall back on getMember?

Thanks for clarifying!
Markus

scripting: opDot vs. getMember?

On Friday 10 September 2010 08:55:25 Markus Klotzbuecher wrote:
> Dear List,
>
> I'm wondering what is the preferred way to update DataSources from
> scripting. There seem to be two options: opDot and getMember. I recall
> Peter stating that getMember is "highly non-realtime", while opDot
> is. However I understand the latter needs explicit typekit support.
> How does the rtt-scripting and the TaskBrowser handle this? Use opDot
> if possible, else fall back on getMember?

Hmm. DotOp is as 'highly non-realtime' as getMember(). getMember() is the
renamed/factored cousin of DotOp. Both will create a new datasource on the
heap. Any reference to DotOp must be removed and must be considered as dead
code. For example, 'applyDot', the key function to use DotOp is nowhere called
in the RTT.

The factory approaches (produceX(), getMember(), etc) are there to allow pre-
allocation in a non-realtime part and execute later. This clashes with 'true'
scripting languages that only know what to allocate when it is executing.

Same is true for SendHandleC/OperationCallerC. I've grep'ed for the occurences
of 'new ' in RTT::internal, we'd practically end up with allocating everything
with the rt-alloc if we had to wish for real-time allocation during the 'real
scripting' execution...

Peter

PS: One advantage of boost::shared_ptr is that you can attach a custom
deleter, so if datasource A is allocated with std new and datasource B with rt
malloc, both would remember that they need to be freed with 'delete' and 'rt
free' respectively.

scripting: opDot vs. getMember?

On Fri, Sep 10, 2010 at 09:24:23AM +0200, Peter Soetens wrote:
> On Friday 10 September 2010 08:55:25 Markus Klotzbuecher wrote:
> > Dear List,
> >
> > I'm wondering what is the preferred way to update DataSources from
> > scripting. There seem to be two options: opDot and getMember. I recall
> > Peter stating that getMember is "highly non-realtime", while opDot
> > is. However I understand the latter needs explicit typekit support.
> > How does the rtt-scripting and the TaskBrowser handle this? Use opDot
> > if possible, else fall back on getMember?
>
> Hmm. DotOp is as 'highly non-realtime' as getMember(). getMember() is the
> renamed/factored cousin of DotOp. Both will create a new datasource on the
> heap. Any reference to DotOp must be removed and must be considered as dead
> code. For example, 'applyDot', the key function to use DotOp is nowhere called
> in the RTT.

Ok, thanks for clarifying.

> The factory approaches (produceX(), getMember(), etc) are there to allow pre-
> allocation in a non-realtime part and execute later. This clashes with 'true'
> scripting languages that only know what to allocate when it is executing.

So you know at parsing time that a user will access eg. connpol.size
so you call getMember("size") then and not at runtime anymore, right?

Indeed I can not really do that easily. One solution would be if I had
way to pass an own (rt-allocated) datasource to getMember like

void getMember(const char* member, DataSourceBase::shared_ptr dsb)

that wouldn't be too difficult to add, would it?

> Same is true for SendHandleC/OperationCallerC. I've grep'ed for the occurences
> of 'new ' in RTT::internal, we'd practically end up with allocating everything
> with the rt-alloc if we had to wish for real-time allocation during the 'real
> scripting' execution...

Yes, that would be too intrusive. Same thing as above here. I would
like to call/send by passing in a vector of argument dsb and a result
dsb:

call(std::vector<DataSourceBase::shared_ptr> args, DataSourceBase::shared_ptr ret)

> PS: One advantage of boost::shared_ptr is that you can attach a custom
> deleter, so if datasource A is allocated with std new and datasource B with rt
> malloc, both would remember that they need to be freed with 'delete' and 'rt
> free' respectively.

Ah I didn't know that. Good to know!

Markus

scripting: opDot vs. getMember?

On Friday 10 September 2010 09:56:21 Markus Klotzbuecher wrote:
> On Fri, Sep 10, 2010 at 09:24:23AM +0200, Peter Soetens wrote:
> > On Friday 10 September 2010 08:55:25 Markus Klotzbuecher wrote:
> > > Dear List,
> > >
> > > I'm wondering what is the preferred way to update DataSources from
> > > scripting. There seem to be two options: opDot and getMember. I recall
> > > Peter stating that getMember is "highly non-realtime", while opDot
> > > is. However I understand the latter needs explicit typekit support.
> > > How does the rtt-scripting and the TaskBrowser handle this? Use opDot
> > > if possible, else fall back on getMember?
> >
> > Hmm. DotOp is as 'highly non-realtime' as getMember(). getMember() is the
> > renamed/factored cousin of DotOp. Both will create a new datasource on
> > the heap. Any reference to DotOp must be removed and must be considered
> > as dead code. For example, 'applyDot', the key function to use DotOp is
> > nowhere called in the RTT.
>
> Ok, thanks for clarifying.
>
> > The factory approaches (produceX(), getMember(), etc) are there to allow
> > pre- allocation in a non-realtime part and execute later. This clashes
> > with 'true' scripting languages that only know what to allocate when it
> > is executing.
>
> So you know at parsing time that a user will access eg. connpol.size
> so you call getMember("size") then and not at runtime anymore, right?

Yes.

>
> Indeed I can not really do that easily. One solution would be if I had
> way to pass an own (rt-allocated) datasource to getMember like
>
> void getMember(const char* member, DataSourceBase::shared_ptr dsb)
>
> that wouldn't be too difficult to add, would it?

I'm not yet sure of that. The dsb that getMember returns is a typed function
object. You'd need to assign function objects, which works (and is in well
defined cases real-time) with boost::function, but also the types of both
boost::function objects need to match.

>
> > Same is true for SendHandleC/OperationCallerC. I've grep'ed for the
> > occurences of 'new ' in RTT::internal, we'd practically end up with
> > allocating everything with the rt-alloc if we had to wish for real-time
> > allocation during the 'real scripting' execution...
>
> Yes, that would be too intrusive. Same thing as above here. I would
> like to call/send by passing in a vector of argument dsb and a result
> dsb:
>
> call(std::vector<DataSourceBase::shared_ptr> args,
> DataSourceBase::shared_ptr ret)

Even more complex. 'ret' will need to be a FusedFunctionDataSource<Signature>.
How will you create 'ret' on beforehand ? If 'ret' is just a ValueDataSource,
we'd need to create the FusedFunctionDataSource anyway and we're back to
square #1.

Peter