On Thursday 22 January 2009 10:55:14 Vandenbroucke Sander wrote:
> >
> > We can't really get rid of templates the way we work now. The only
> > 'solution'
> > is to define stuff like 'extern template class Buffer<double>;' in a
> > header and
> > 'template class Buffer<double>;' in a .cpp file. (GCC only). This will
> > avoid
> > emitting code for this case.
>
> I think that with a well designed strategy design pattern the actual
> algorithm can be split off from the template Buffer<> class. The default
> buffer strategy could be assigned in some startup code. This goes for
> any TS-IPC object.

This is how the commands, methods, properties and events are implemented.
But this works only by defining a templated 'implementation' interface

// #1 'low level' Interface definition
template<class T>
class BufferImpl {
  // define interface for any T
};
// #2 'user level' class defintion.
template<class T>
class Buffer { 
  BufferImp<T>l* impl; 
  //... assign impl in constructor (using a factory)
};
// #3 an implementation.
template<class T>
class LockFreeBuffer 
 : public BufferImpl<T>
{
 // Implements BufferImpl<T>
};

The user code will still include #1 and #2. We will however require that some
kind of factory includes #3 and creates an object for it. This brings back up
the discussion if A) all types T should be registered to the Orocos type
system

 types()->addtype(new TemplateTypeFactory<UserType>("UserType")  );

B) allows the RTT to handle your types smartly and is even required for
transports, but puts a burden on the user for declaring each type A) works as
well and code is 'only' duplicated among .so libraries.

Maybe the plugin system could be handy for loading type construction
information and solving these kind of issues. It would simply the RTT and
improve compile times dramatically.

Peter

On Thu, 22 Jan 2009, Vandenbroucke Sander wrote:

[...]
>> YAGNI ?
> I don't get this...
<http://en.wikipedia.org/wiki/YAGNI>: "You Ain't Gonna Need It" :-)

Herman

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Regarding the ARM version of OROCOS, the version that I wrote seems to be working fine - the entire system and its dependencies compile and run without any issues. However, there is still the issue of the IRQs that I will leave up to you guys - I really don't have enough experience in this field to deal with such matters.


I am only sending in the files, as I am not sure on how to send in a proper patch...

I wrote/tested this patch with OROCOS 1.6.1 (as well as 1.6.0), Xenomai 2.4.6.1 and Linux 2.4.24 on an PXA-270 ARM platform running OpenEmbedded (the Gumstix Verdex).


Thanks for everyone that helped,
        -Felipe Brandão Cavalcanti
        LARA - Laboratory of Robotics and Automation
        Department of Electrical Engineering
        UnB - University of Brasília, Brazil

        http://www.lara.unb.br/

--
*º¤., ¸¸,.¤º*¨*¤., ¸¸,.¤º*¨*
Cavalkaf (aka Felipe) <cavalkaf [..] ...>
AIM: Cavalkaf | MSN: cavalkaf2 [..] ...

Check out <http://www.flickr.com/photos/rbcav2003/>

Let me continue this (part of the) thread under a more appropriate
heading...

On Thu, 22 Jan 2009, Markus Klotzbücher wrote:

> On Wed, Jan 21, 2009 at 05:40:36PM +0100, Herman Bruyninckx wrote:
>> On Wed, 21 Jan 2009, Vandenbroucke Sander wrote:
>>
>>>> The lists and the data/buffer ports already have mutex based
>>> alternatives
>>>> in
>>>> the code. Only AtomicQueue needs an (easy to implement) mutex based
>>>> alternative. The rest is guarding with #ifdef ORO_HAS_LOCK_FREE... and
>>>> instantiating the correct object.
>>>>
>>> My comment is slightly of topic regading to ARM but I'll go ahead
>>> anyway.
>>>
>>> I think a more fundamental refactoring should be done. I mean from an
>>> academic point of view it might be interesting to have a BufferLockfree,
>>> BufferLocked, DataObjectPriorityGet/Set, DataObjectLockFree, etc. You
>>> can write a program to prove witch is best and produce nice charts. But
>>> in real life it isn't helping the end user.
>>
>> I don't agree... We are targeting many possible end-users! From the deeply
>> embedded to the highly distributed... (Or rather, we are targeting
>> "application developers" and not users.)
>
> I think you're both right. What's missing (and Peter mentioned in his
> mail) is a hierarchy that makes clear "If unsure use X which will
> perform great in most cases, if you know you need to optimize,
> low-level y or z might be beneficial". This would be useful for other
> OROCOS types, e.g. for Properties and Attributes too.
>
Yes... And the appropriate support for this kind of
"platform-(in)dependent" configuration is "Model-Driven Engineering", as
you undoubtedly know :-)

So, people on this list: what kind of "ideal" software support toolchain
are you dreaming of, in order to be able use Orocos in the most efficient
and optimized way, including (semi)automatic configuration decision making,
code generation, platform optimization and deployment,...?

First of all, I am most interested in knowing the "non-functional
requirements" of the _developers_ as our main "stakeholders" for the time
being.

I'm asking this question because I will have (at least) two people working
full time at preparing such MDE things in the very near future...

Herman

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm