For your information: <http://code.google.com/p/protobuf-dt />.
This is an example of a tool to help people write the "model" for a
"Communication" message. It might be doable to apply the same
infrastructure for other data models than just Google Protocol Buffers:
NetCDF, ROS typekits,...
Herman
What is Sylvain problem with metamodels?
He never gives a concise, precise, accurate answer.
-H
What is Sylvain problem with metamodels?
On Fri, Feb 17, 2012 at 4:06 PM, Hugo Garcia
<hugo [dot] garcia [..] ...> wrote:
> He never gives a concise, precise, accurate answer.
Sylvain just explained at length why he thinks there is no problem in
both approaches (both are modeling), and then you ask this question !?
Peter
What is Sylvain problem with metamodels?
On 02/17/2012 04:06 PM, Hugo Garcia wrote:
> He never gives a concise, precise, accurate answer.
I'm not against metamodels, models or whatever and I really don't
understand why you absolutely want me to be. It's not about being "for"
or "against" models, metamodels or meta**X-models. We're not talking
absolutes here.
The only thing I said I was against is the absolutist view of having
"pure" MDE vs. "impure" MDE. And I am grateful of both Markus and Piotr
participation in the thread, which has been very interesting for me.
What is Sylvain problem with metamodels?
On 02/17/2012 07:32 PM, Sylvain Joyeux wrote:
> On 02/17/2012 04:06 PM, Hugo Garcia wrote:
>> He never gives a concise, precise, accurate answer.
> I'm not against metamodels, models or whatever and I really don't
> understand why you absolutely want me to be. It's not about being "for"
> or "against" models, metamodels or meta**X-models. We're not talking
> absolutes here.
>
> The only thing I said I was against is the absolutist view of having
> "pure" MDE vs. "impure" MDE.
Ok
So the main difference between us is that I separate the RTT metamodel
from the transformation code while you have the metamodel intermingled
within the code for transformation.
You use your specification as a means to persist an instance of the
model while I use an ecore model for the same purpose.
Could you use a persisted instance of an RTT model in ecore as the input
specification for your stuff? I could attempt the same... using your
specification use for my stuff.
If our metamodels are equivalent then the above should work. Right?
-H
What is Sylvain problem with metamodels?
On 02/20/2012 11:19 AM, Hugo Garcia wrote:
> So the main difference between us is that I separate the RTT metamodel
> from the transformation code while you have the metamodel intermingled
> within the code for transformation.
Mostly false. There are oroGen models and there is code generation, and
they are separated, the same way than you have an eCore model and
eCore-based code generation. The "mostly" is because oroGen does *not*
properly separate for the "infrastructure" stuff (e.g. dependencies
between projects) which sucks and is definitely on my "needs fixing" list.
> You use your specification as a means to persist an instance of the
> model while I use an ecore model for the same purpose.
That's true.
> Could you use a persisted instance of an RTT model in ecore as the input
> specification for your stuff? I could attempt the same... using your
> specification use for my stuff.
I guess I could, if I had an example or a spec of (1) how to load the
ecore specification and (2) how to interpret it.
The questions is not what CAN be done, but what SHOULD be done. What's
the developer's workflow that should be achieved ?
My impression is that it is:
1. Eclipse GUI => code generation. Why not generate an oroGen spec
or make oroGen load the eCore spec and use oroGen for code
generation ?
2. (text based) oroGen spec => code generation. That's the current
workflow.
3. edit previously created oroGen specs using the Eclipse GUI. What I
would go for is have oroGen load the spec and generate the eCore
model. (1) would not be doable anymore in case of oroGen plugins as
it would lose information. However, it's going to be easier *and*
more generic *and* handle oroGen plugins fine (see explanations
below).
Explanations about 3: as Piotr pointed out, the use of embedded DSLs
require you to be able to parse the host language to get the information
you want. What we did not discuss is that using embedded DSLs makes
extensions to the spec a lot easier to implement, which in Rock exists
in the form of oroGen plugins.
> If our metamodels are equivalent then the above should work. Right?
Right.
What is Sylvain problem with metamodels?
On Mon, 20 Feb 2012, Sylvain Joyeux wrote:
> On 02/20/2012 11:19 AM, Hugo Garcia wrote:
>> So the main difference between us is that I separate the RTT metamodel
>> from the transformation code while you have the metamodel intermingled
>> within the code for transformation.
> Mostly false. There are oroGen models and there is code generation, and
> they are separated, the same way than you have an eCore model and
> eCore-based code generation. The "mostly" is because oroGen does *not*
> properly separate for the "infrastructure" stuff (e.g. dependencies
> between projects) which sucks and is definitely on my "needs fixing" list.
>
>> You use your specification as a means to persist an instance of the
>> model while I use an ecore model for the same purpose.
> That's true.
>
>> Could you use a persisted instance of an RTT model in ecore as the input
>> specification for your stuff? I could attempt the same... using your
>> specification use for my stuff.
> I guess I could, if I had an example or a spec of (1) how to load the
> ecore specification and (2) how to interpret it.
>
> The questions is not what CAN be done, but what SHOULD be done. What's
> the developer's workflow that should be achieved ?
>
> My impression is that it is:
> 1. Eclipse GUI => code generation. Why not generate an oroGen spec
> or make oroGen load the eCore spec and use oroGen for code
> generation ?
> 2. (text based) oroGen spec => code generation. That's the current
> workflow.
> 3. edit previously created oroGen specs using the Eclipse GUI. What I
> would go for is have oroGen load the spec and generate the eCore
> model. (1) would not be doable anymore in case of oroGen plugins as
> it would lose information. However, it's going to be easier *and*
> more generic *and* handle oroGen plugins fine (see explanations
> below).
>
> Explanations about 3: as Piotr pointed out, the use of embedded DSLs
> require you to be able to parse the host language to get the information
> you want. What we did not discuss is that using embedded DSLs makes
> extensions to the spec a lot easier to implement, which in Rock exists
> in the form of oroGen plugins.
>
>> If our metamodels are equivalent then the above should work. Right?
> Right.
Good! Let's look for a master student to do the work :-)
Herman
What is Sylvain problem with metamodels?
On 02/20/2012 01:04 PM, Herman Bruyninckx wrote:
>>> If our metamodels are equivalent then the above should work. Right?
>> Right.
>
> Good! Let's look for a master student to do the work :-)
Doing what ? I'm still missing what is the BRICS goal in all of this.
Currently, as far as I understood, BRIDE tries to reimplement the code
generation already done in the toolchain. To what end ?
I don't see the point of converting between the tools if there is no
clear *long term* goal as to what it is going to be done *for*.
What is Sylvain problem with metamodels?
2012/2/20 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
> On 02/20/2012 01:04 PM, Herman Bruyninckx wrote:
>>>> If our metamodels are equivalent then the above should work. Right?
>>> Right.
>>
>> Good! Let's look for a master student to do the work :-)
>
> Doing what ? I'm still missing what is the BRICS goal in all of this.
> Currently, as far as I understood, BRIDE tries to reimplement the code
> generation already done in the toolchain. To what end ?
>
> I don't see the point of converting between the tools if there is no
> clear *long term* goal as to what it is going to be done *for*.
> --
If I may, I am afraid it is the industry vs research focus point difference.
> Sylvain Joyeux (Dr.Ing.)
> Space & Security Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax: +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> Weitere Informationen: http://www.dfki.de/robotik
> -----------------------------------------------------------------------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973
> Steuernummer: 19/673/0060/3
> -----------------------------------------------------------------------
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
What is Sylvain problem with metamodels?
On Mon, 20 Feb 2012, Willy Lambert wrote:
> 2012/2/20 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
>> On 02/20/2012 01:04 PM, Herman Bruyninckx wrote:
>>>>> If our metamodels are equivalent then the above should work. Right?
>>>> Right.
>>>
>>> Good! Let's look for a master student to do the work :-)
>>
>> Doing what ? I'm still missing what is the BRICS goal in all of this.
>> Currently, as far as I understood, BRIDE tries to reimplement the code
>> generation already done in the toolchain. To what end ?
>>
>> I don't see the point of converting between the tools if there is no
>> clear *long term* goal as to what it is going to be done *for*.
>> --
>
> If I may, I am afraid it is the industry vs research focus point difference.
You may :-) I agree. Functionality wise, there will be no difference, but
"industry" is a lot less flexible in selecting tooling than academia.
(Because they (rightfully so?) expect that only "big iron" companies can
support "big software" tools....) Hence, "lock-in" into "big" ecosystems like
Eclipse will be more and more a reality. I don't know whether I like that
or not, but I will try to reduce the negative consequences as much as
possible, my keeping on advocating "integration by composition" and not
"integration by inheritance". The latter means that new functionality can
only be added by extending (the source code of) what is already there,
where the former would do it via "plug ins" that can be developed by
"third-parties".
>> Sylvain Joyeux (Dr.Ing.)
Herman
>> Space & Security Robotics
>>
>> !!! Achtung, neue Telefonnummer!!!
>>
>> Standort Bremen:
>> DFKI GmbH
>> Robotics Innovation Center
>> Robert-Hooke-Straße 5
>> 28359 Bremen, Germany
>>
>> Phone: +49 (0)421 178-454136
>> Fax: +49 (0)421 218-454150
>> E-Mail: robotik [..] ...
>>
>> Weitere Informationen: http://www.dfki.de/robotik
>> -----------------------------------------------------------------------
>> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
>> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
>> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
>> (Vorsitzender) Dr. Walter Olthoff
>> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
>> Amtsgericht Kaiserslautern, HRB 2313
>> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
>> USt-Id.Nr.: DE 148646973
>> Steuernummer: 19/673/0060/3
>> -----------------------------------------------------------------------
>> --
>> Orocos-Dev mailing list
>> Orocos-Dev [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
--
KU Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
EURON Coordinator (European Robotics Research Network) <http://www.euron.org>
Open Realtime Control Services <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
What is Sylvain problem with metamodels?
>> 2012/2/20 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
>>> On 02/20/2012 01:04 PM, Herman Bruyninckx wrote:
>>>>>> If our metamodels are equivalent then the above should work. Right?
>>>>> Right.
>>>>
>>>> Good! Let's look for a master student to do the work :-)
>>>
>>> Doing what ? I'm still missing what is the BRICS goal in all of this.
>>> Currently, as far as I understood, BRIDE tries to reimplement the code
>>> generation already done in the toolchain. To what end ?
>>>
>>> I don't see the point of converting between the tools if there is no
>>> clear *long term* goal as to what it is going to be done *for*.
As a BRIDE developer I would like to defend it a bit. BRIDE is more
than code-generation. It serves as a tool to explore the *use* and
*power* of model-to-model transformations. For instance, in the
short-term you can model an application in a framework-independent
manner and later generate ROS or Orocos code.
>>> --
>>
>> If I may, I am afraid it is the industry vs research focus point difference.
>
> You may :-) I agree. Functionality wise, there will be no difference, but
> "industry" is a lot less flexible in selecting tooling than academia.
> (Because they (rightfully so?) expect that only "big iron" companies can
> support "big software" tools....) Hence, "lock-in" into "big" ecosystems like
> Eclipse will be more and more a reality. I don't know whether I like that
> or not, but I will try to reduce the negative consequences as much as
> possible, my keeping on advocating "integration by composition" and not
> "integration by inheritance". The latter means that new functionality can
> only be added by extending (the source code of) what is already there,
> where the former would do it via "plug ins" that can be developed by
> "third-parties".
It's useless IMHO to debate whether Eclipse is a good decision or not.
Let's assume we would have developed BRIDE not within the Eclipse
ecosystem probably the same people would say "why not using Eclipse?".
I prefer a lock-in in a huge open-source ecosystem like Eclipse above
a lock-in in a handcrafted and hard to maintain toolchain developed by
a couple of programmers.
Nico
>
>>> Sylvain Joyeux (Dr.Ing.)
>
> Herman
>
What is Sylvain problem with metamodels?
On 02/20/2012 06:52 PM, Nico Hochgeschwender wrote:
>>> 2012/2/20 Sylvain Joyeux<sylvain [dot] joyeux [..] ...>:
>>>> On 02/20/2012 01:04 PM, Herman Bruyninckx wrote:
>>>>>>> If our metamodels are equivalent then the above should work. Right?
>>>>>> Right.
>>>>>
>>>>> Good! Let's look for a master student to do the work :-)
>>>>
>>>> Doing what ? I'm still missing what is the BRICS goal in all of this.
>>>> Currently, as far as I understood, BRIDE tries to reimplement the code
>>>> generation already done in the toolchain. To what end ?
>>>>
>>>> I don't see the point of converting between the tools if there is no
>>>> clear *long term* goal as to what it is going to be done *for*.
>
> As a BRIDE developer I would like to defend it a bit. BRIDE is more
> than code-generation. It serves as a tool to explore the *use* and
> *power* of model-to-model transformations. For instance, in the
> short-term you can model an application in a framework-independent
> manner and later generate ROS or Orocos code.
Yes. And oroGen is more than code generation, it serves as a tool to
explore the use and power of models in system configuration and
management. I really don't mean to say "oh, you guys should drop BRIDE".
What I am saying, or at least trying to, is that redoing the
orocos-target code generation just for the sake of using Eclipse's
templating system is IMO not a very productive endeavour as you are
redoing something that already exists, is pretty well tested, and for
which quite a few implemented components already exist. And, in the
meantime, make "us" (orocos developers "us") not share any ressources in
the maintenance and improvement of a common code generation tool.
And I definitely don't plan spending resources in converting model
representations just for the sake of converting model representations.
It would have to have a long-term vision (read: a benefit for the
overall workflow, not for the theoretical beauty of it) for me to spend
any resources.
What is Sylvain problem with metamodels?
On Feb 20, 2012, at 09:03 , Herman Bruyninckx wrote:
> On Mon, 20 Feb 2012, Willy Lambert wrote:
>
>> 2012/2/20 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
>>> On 02/20/2012 01:04 PM, Herman Bruyninckx wrote:
>>>>>> If our metamodels are equivalent then the above should work. Right?
>>>>> Right.
>>>>
>>>> Good! Let's look for a master student to do the work :-)
>>>
>>> Doing what ? I'm still missing what is the BRICS goal in all of this.
>>> Currently, as far as I understood, BRIDE tries to reimplement the code
>>> generation already done in the toolchain. To what end ?
>>>
>>> I don't see the point of converting between the tools if there is no
>>> clear *long term* goal as to what it is going to be done *for*.
>>> --
>>
>> If I may, I am afraid it is the industry vs research focus point difference.
>
> You may :-) I agree. Functionality wise, there will be no difference, but
> "industry" is a lot less flexible in selecting tooling than academia.
> (Because they (rightfully so?) expect that only "big iron" companies can
> support "big software" tools....) Hence, "lock-in" into "big" ecosystems like
> Eclipse will be more and more a reality. I don't know whether I like that
I wouldn't be so quick to assume that for industry. More and more we worry about open and complete access to software, and those big-iron companies just don't like to give that up. See the drive away from VxWorks as just one example …
But I agree with the overall sentiment.
S
Eclipse editor for "data message", Google Protocol Buffer versio
On 02/16/2012 02:30 PM, Herman Bruyninckx wrote:
> For your information:<http://code.google.com/p/protobuf-dt />.
>
> This is an example of a tool to help people write the "model" for a
> "Communication" message. It might be doable to apply the same
> infrastructure for other data models than just Google Protocol Buffers:
> NetCDF, ROS typekits,...
This looks like a straightforward "programming language"-type editor
tuned for the protobufs, or am I missing something ?
Eclipse editor for "data message", Google Protocol Buffer versio
On 02/16/2012 06:04 PM, Sylvain Joyeux wrote:
> On 02/16/2012 02:30 PM, Herman Bruyninckx wrote:
>> For your information:<http://code.google.com/p/protobuf-dt />.
>>
>> This is an example of a tool to help people write the "model" for a
>> "Communication" message. It might be doable to apply the same
>> infrastructure for other data models than just Google Protocol Buffers:
>> NetCDF, ROS typekits,...
>
> This looks like a straightforward "programming language"-type editor
> tuned for the protobufs, or am I missing something ?
By "straightforward" here, I am referring to the pile of
language-specific language editor support that exist out there, in
Eclipse, KDevelop, vim, ... This definitely looks like that ...
Eclipse editor for "data message", Google Protocol Buffer versio
On Thu, 16 Feb 2012, Sylvain Joyeux wrote:
> On 02/16/2012 06:04 PM, Sylvain Joyeux wrote:
>> On 02/16/2012 02:30 PM, Herman Bruyninckx wrote:
>> > For your information:<http://code.google.com/p/protobuf-dt />.
>> >
>> > This is an example of a tool to help people write the "model" for a
>> > "Communication" message. It might be doable to apply the same
>> > infrastructure for other data models than just Google Protocol Buffers:
>> > NetCDF, ROS typekits,...
>>
>> This looks like a straightforward "programming language"-type editor
>> tuned for the protobufs, or am I missing something ?
> By "straightforward" here, I am referring to the pile of language-specific
> language editor support that exist out there, in Eclipse, KDevelop, vim, ...
> This definitely looks like that ...
>
It "looks" like that, but it has some "formal model" behind the screens.
That's a lot more than we can say about what the majority of code
generation tools in robotics provide. It does lack a "meta level" model, or
"ontology", but it is definitely a step in the right direction. I have not
yet been able to check whether the same "message model" can be used to
generate code for other protocols than Google's...
Herman
Eclipse editor for "data message", Google Protocol Buffer versio
On 02/16/2012 09:01 PM, Herman Bruyninckx wrote:
> On Thu, 16 Feb 2012, Sylvain Joyeux wrote:
>
>> On 02/16/2012 06:04 PM, Sylvain Joyeux wrote:
>>> On 02/16/2012 02:30 PM, Herman Bruyninckx wrote:
>>> > For your information:<http://code.google.com/p/protobuf-dt />.
>>> > > This is an example of a tool to help people write the "model" for a
>>> > "Communication" message. It might be doable to apply the same
>>> > infrastructure for other data models than just Google Protocol
>>> Buffers:
>>> > NetCDF, ROS typekits,...
>>>
>>> This looks like a straightforward "programming language"-type editor
>>> tuned for the protobufs, or am I missing something ?
>> By "straightforward" here, I am referring to the pile of
>> language-specific language editor support that exist out there, in
>> Eclipse, KDevelop, vim, ... This definitely looks like that ...
>>
> It "looks" like that, but it has some "formal model" behind the screens.
> That's a lot more than we can say about what the majority of code
> generation tools in robotics provide. It does lack a "meta level" model, or
> "ontology", but it is definitely a step in the right direction. I have not
> yet been able to check whether the same "message model" can be used to
> generate code for other protocols than Google's...
Unless you mean "not in eclipse" by "not using a formal model" (if you
are wondering, I am being a bit sarcastic there, that was too tempting),
code generators are in robotics (1) few and (2) all the ones that come
to my mind do have an underlying model representation.
Examples:
* genom (all versions, that's dating back to 1995)
* typegen/orogen (Typelib::Type and subclasses and Orocos::Spec::*)
* ROS messages (unless I am mistaken, they do have an internal
representation of the messages)
Could you share counter-examples ?
[software-toolchain] Eclipse editor for "data message", Google P
On Fri, Feb 17, 2012 at 10:33:31AM +0100, Sylvain Joyeux wrote:
> On 02/16/2012 09:01 PM, Herman Bruyninckx wrote:
> > On Thu, 16 Feb 2012, Sylvain Joyeux wrote:
> >
> >> On 02/16/2012 06:04 PM, Sylvain Joyeux wrote:
> >>> On 02/16/2012 02:30 PM, Herman Bruyninckx wrote:
> >>> > For your information:<http://code.google.com/p/protobuf-dt />.
> >>> > > This is an example of a tool to help people write the "model" for a
> >>> > "Communication" message. It might be doable to apply the same
> >>> > infrastructure for other data models than just Google Protocol
> >>> Buffers:
> >>> > NetCDF, ROS typekits,...
> >>>
> >>> This looks like a straightforward "programming language"-type editor
> >>> tuned for the protobufs, or am I missing something ?
> >> By "straightforward" here, I am referring to the pile of
> >> language-specific language editor support that exist out there, in
> >> Eclipse, KDevelop, vim, ... This definitely looks like that ...
> >>
> > It "looks" like that, but it has some "formal model" behind the screens.
> > That's a lot more than we can say about what the majority of code
> > generation tools in robotics provide. It does lack a "meta level" model, or
> > "ontology", but it is definitely a step in the right direction. I have not
> > yet been able to check whether the same "message model" can be used to
> > generate code for other protocols than Google's...
> Unless you mean "not in eclipse" by "not using a formal model" (if you
> are wondering, I am being a bit sarcastic there, that was too tempting),
> code generators are in robotics (1) few and (2) all the ones that come
> to my mind do have an underlying model representation.
>
> Examples:
>
> * genom (all versions, that's dating back to 1995)
> * typegen/orogen (Typelib::Type and subclasses and Orocos::Spec::*)
> * ROS messages (unless I am mistaken, they do have an internal
> representation of the messages)
* rFSM :-)
> Could you share counter-examples ?
No, the only difference is having a non-standard built-in meta-model
specialized for the particular tool vs. a semi-standard ecore
meta-model that is often unable to specify all necessary constraints.
I think the differences are smaller than they might appear.
Markus
[software-toolchain] Eclipse editor for "data message", Google P
On Fri, Feb 17, 2012 at 11:27, Markus Klotzbuecher <
markus [dot] klotzbuecher [..] ...> wrote:
> On Fri, Feb 17, 2012 at 10:33:31AM +0100, Sylvain Joyeux wrote:
> > On 02/16/2012 09:01 PM, Herman Bruyninckx wrote:
> > > On Thu, 16 Feb 2012, Sylvain Joyeux wrote:
> > >
> > >> On 02/16/2012 06:04 PM, Sylvain Joyeux wrote:
> > >>> On 02/16/2012 02:30 PM, Herman Bruyninckx wrote:
> > >>> > For your information:<http://code.google.com/p/protobuf-dt />.
> > >>> > > This is an example of a tool to help people write the "model"
> for a
> > >>> > "Communication" message. It might be doable to apply the same
> > >>> > infrastructure for other data models than just Google Protocol
> > >>> Buffers:
> > >>> > NetCDF, ROS typekits,...
> > >>>
> > >>> This looks like a straightforward "programming language"-type editor
> > >>> tuned for the protobufs, or am I missing something ?
> > >> By "straightforward" here, I am referring to the pile of
> > >> language-specific language editor support that exist out there, in
> > >> Eclipse, KDevelop, vim, ... This definitely looks like that ...
> > >>
> > > It "looks" like that, but it has some "formal model" behind the
> screens.
> > > That's a lot more than we can say about what the majority of code
> > > generation tools in robotics provide. It does lack a "meta level"
> model, or
> > > "ontology", but it is definitely a step in the right direction. I have
> not
> > > yet been able to check whether the same "message model" can be used to
> > > generate code for other protocols than Google's...
> > Unless you mean "not in eclipse" by "not using a formal model" (if you
> > are wondering, I am being a bit sarcastic there, that was too tempting),
> > code generators are in robotics (1) few and (2) all the ones that come
> > to my mind do have an underlying model representation.
> >
> > Examples:
> >
> > * genom (all versions, that's dating back to 1995)
> > * typegen/orogen (Typelib::Type and subclasses and Orocos::Spec::*)
> > * ROS messages (unless I am mistaken, they do have an internal
> > representation of the messages)
> * rFSM :-)
>
> > Could you share counter-examples ?
>
> No, the only difference is having a non-standard built-in meta-model
> specialized for the particular tool vs. a semi-standard ecore
> meta-model that is often unable to specify all necessary constraints.
>
Constraints need not to be expressed within a meta-model, but can be also
external to it (e.g., OCL)
and there is noting wrong with it. I am not sure if any of the constraint
languages is "complete" (i.e.,
is it possible to prove, that it is able to express ANY constraint), but
until now I was able to use it for
all constraints I could think of.
That's why I do not see real benefit of NOT using non-standard built-in
meta models.
>
> I think the differences are smaller than they might appear.
>
> Markus
>
>
>
>
>
>
>
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
[software-toolchain] Eclipse editor for "data message", Google P
On Fri, Feb 17, 2012 at 11:46:38AM +0100, Piotr Trojanek wrote:
> On Fri, Feb 17, 2012 at 11:27, Markus Klotzbuecher <
> markus [dot] klotzbuecher [..] ...> wrote:
>
> On Fri, Feb 17, 2012 at 10:33:31AM +0100, Sylvain Joyeux wrote:
> > On 02/16/2012 09:01 PM, Herman Bruyninckx wrote:
> > > On Thu, 16 Feb 2012, Sylvain Joyeux wrote:
> > >
> > >> On 02/16/2012 06:04 PM, Sylvain Joyeux wrote:
> > >>> On 02/16/2012 02:30 PM, Herman Bruyninckx wrote:
> > >>> > For your information:<http://code.google.com/p/protobuf-dt />.
> > >>> > > This is an example of a tool to help people write the "model" for
> a
> > >>> > "Communication" message. It might be doable to apply the same
> > >>> > infrastructure for other data models than just Google Protocol
> > >>> Buffers:
> > >>> > NetCDF, ROS typekits,...
> > >>>
> > >>> This looks like a straightforward "programming language"-type editor
> > >>> tuned for the protobufs, or am I missing something ?
> > >> By "straightforward" here, I am referring to the pile of
> > >> language-specific language editor support that exist out there, in
> > >> Eclipse, KDevelop, vim, ... This definitely looks like that ...
> > >>
> > > It "looks" like that, but it has some "formal model" behind the
> screens.
> > > That's a lot more than we can say about what the majority of code
> > > generation tools in robotics provide. It does lack a "meta level"
> model, or
> > > "ontology", but it is definitely a step in the right direction. I have
> not
> > > yet been able to check whether the same "message model" can be used to
> > > generate code for other protocols than Google's...
> > Unless you mean "not in eclipse" by "not using a formal model" (if you
> > are wondering, I am being a bit sarcastic there, that was too tempting),
> > code generators are in robotics (1) few and (2) all the ones that come
> > to my mind do have an underlying model representation.
> >
> > Examples:
> >
> > * genom (all versions, that's dating back to 1995)
> > * typegen/orogen (Typelib::Type and subclasses and Orocos::Spec::*)
> > * ROS messages (unless I am mistaken, they do have an internal
> > representation of the messages)
> * rFSM :-)
>
> > Could you share counter-examples ?
>
> No, the only difference is having a non-standard built-in meta-model
> specialized for the particular tool vs. a semi-standard ecore
> meta-model that is often unable to specify all necessary constraints.
>
>
> Constraints need not to be expressed within a meta-model, but can be also
> external to it (e.g., OCL)
> and there is noting wrong with it. I am not sure if any of the constraint
> languages is "complete" (i.e.,
> is it possible to prove, that it is able to express ANY constraint), but until
> now I was able to use it for
> all constraints I could think of.
>
> That's why I do not see real benefit of NOT using non-standard built-in meta
> models.
There's nothing wrong with OCL. Nevertheless, the benefit of using
non-standard meta-models is to NOT add an dependency on Eclipse! If
someone writes a snappy, stand-alone OCL model checker I'll consider
using it.
Markus
[software-toolchain] Eclipse editor for "data message", Google P
On Fri, Feb 17, 2012 at 13:49, Markus Klotzbuecher <
markus [dot] klotzbuecher [..] ...> wrote:
> > That's why I do not see real benefit of NOT using non-standard built-in
> meta
> > models.
>
> There's nothing wrong with OCL. Nevertheless, the benefit of using
> non-standard meta-models is to NOT add an dependency on Eclipse! If
> someone writes a snappy, stand-alone OCL model checker I'll consider
> using it.
>
I think, that path towards stand-alone OCL model checker is much shorter,
than path
toward standardization of home-grown meta-metamodels and constraint
languages.
If we are talking about R&D and short-term goals, then I would say, that
non-standard
tools/languages/frameworks are not a problem. But, when it comes to
certification,
high-reliability, long-term supported projects, then the matter of
"stand-alone or not"
is completely minor.
Maybe standardization of Orocos/ROS/Rock/Yarp/whatever is just a dream, but
as long
as they rely on non-standard tools and methods I doubt that this dream will
come true.
[software-toolchain] Eclipse editor for "data message", Google P
On Fri, Feb 17, 2012 at 02:47:04PM +0100, Piotr Trojanek wrote:
> On Fri, Feb 17, 2012 at 13:49, Markus Klotzbuecher <
> markus [dot] klotzbuecher [..] ...> wrote:
>
> > That's why I do not see real benefit of NOT using non-standard built-in
> meta
> > models.
>
> There's nothing wrong with OCL. Nevertheless, the benefit of using
> non-standard meta-models is to NOT add an dependency on Eclipse! If
> someone writes a snappy, stand-alone OCL model checker I'll consider
> using it.
>
>
> I think, that path towards stand-alone OCL model checker is much shorter, than
> path
> toward standardization of home-grown meta-metamodels and constraint languages.
>
> If we are talking about R&D and short-term goals, then I would say, that
> non-standard
> tools/languages/frameworks are not a problem. But, when it comes to
> certification,
> high-reliability, long-term supported projects, then the matter of "stand-alone
> or not"
> is completely minor.
If you have the budget to do certifcation and long-term support, then
you can easily afford the extra effort to do everything in eclipse.
Besides that, if you don't want to go broke while certifying your code
generator you'd still better keep it as small and self-contained as
possible.
> Maybe standardization of Orocos/ROS/Rock/Yarp/whatever is just a dream, but as
> long
> as they rely on non-standard tools and methods I doubt that this dream will
> come true.
If you manage to define a standard that these projects commonly agree
on, then the matter of relying on non-standard tools or not will be
minor :-)
Markus
[software-toolchain] Eclipse editor for "data message", Google P
Dear all,
> On Fri, Feb 17, 2012 at 13:49, Markus Klotzbuecher <
> markus [dot] klotzbuecher [..] ...> wrote:
>
>> > That's why I do not see real benefit of NOT using non-standard built-in
>> meta
>> > models.
>>
>> There's nothing wrong with OCL. Nevertheless, the benefit of using
>> non-standard meta-models is to NOT add an dependency on Eclipse! If
>> someone writes a snappy, stand-alone OCL model checker I'll consider
>> using it.
>>
>
> I think, that path towards stand-alone OCL model checker is much shorter,
> than path
> toward standardization of home-grown meta-metamodels and constraint
> languages.
>
> If we are talking about R&D and short-term goals, then I would say, that
> non-standard
> tools/languages/frameworks are not a problem. But, when it comes to
> certification,
> high-reliability, long-term supported projects, then the matter of
> "stand-alone or not"
> is completely minor.
One way to achieve "harmonization" is through models. Whether the
model is represented in Ecore or something else matters IMO only for
the tooling. For instance, the concepts (aka model) in OCL are rooted
in set-theory. However, it has been represented (at least the syntax)
as well in Ecore.
<http://www.emftext.org/index.php/EMFText_Concrete_Syntax_Zoo_OCL>
It seems that this thread is very much about "Eclipse vs. XYZ" and
"Ecore vs. XYZ". But that's not the point: the real discussion is how
can we establish the thinking of models and metamodels in robotics?
Where are the limits of modeling? Where are the deficits of current
modeling approaches etc.? The question whether to use Ecore or not is
secondary, but not unimportant.
Nico
>
> Maybe standardization of Orocos/ROS/Rock/Yarp/whatever is just a dream, but
> as long
> as they rely on non-standard tools and methods I doubt that this dream will
> come true.
>
> --
> Piotr Trojanek
>
[software-toolchain] Eclipse editor for "data message", Google P
On Fri, 17 Feb 2012, Nico Hochgeschwender wrote:
> Dear all,
>
>> On Fri, Feb 17, 2012 at 13:49, Markus Klotzbuecher <
>> markus [dot] klotzbuecher [..] ...> wrote:
>>
>>>> That's why I do not see real benefit of NOT using non-standard built-in
>>> meta
>>>> models.
>>>
>>> There's nothing wrong with OCL. Nevertheless, the benefit of using
>>> non-standard meta-models is to NOT add an dependency on Eclipse! If
>>> someone writes a snappy, stand-alone OCL model checker I'll consider
>>> using it.
>>>
>>
>> I think, that path towards stand-alone OCL model checker is much shorter,
>> than path
>> toward standardization of home-grown meta-metamodels and constraint
>> languages.
>>
>> If we are talking about R&D and short-term goals, then I would say, that
>> non-standard
>> tools/languages/frameworks are not a problem. But, when it comes to
>> certification,
>> high-reliability, long-term supported projects, then the matter of
>> "stand-alone or not"
>> is completely minor.
>
> One way to achieve "harmonization" is through models. Whether the
> model is represented in Ecore or something else matters IMO only for
> the tooling. For instance, the concepts (aka model) in OCL are rooted
> in set-theory. However, it has been represented (at least the syntax)
> as well in Ecore.
>
> <http://www.emftext.org/index.php/EMFText_Concrete_Syntax_Zoo_OCL>
>
> It seems that this thread is very much about "Eclipse vs. XYZ" and
> "Ecore vs. XYZ". But that's not the point: the real discussion is how
> can we establish the thinking of models and metamodels in robotics?
> Where are the limits of modeling? Where are the deficits of current
> modeling approaches etc.? The question whether to use Ecore or not is
> secondary, but not unimportant.
+1
> Nico
Herman
>>
>> Maybe standardization of Orocos/ROS/Rock/Yarp/whatever is just a dream, but
>> as long
>> as they rely on non-standard tools and methods I doubt that this dream will
>> come true.
>>
>> --
>> Piotr Trojanek
[software-toolchain] Eclipse editor for "data message", Google P
On Fri, Feb 17, 2012 at 15:09, Nico Hochgeschwender <
nico [dot] hochgeschwender [..] ...> wrote:
> It seems that this thread is very much about "Eclipse vs. XYZ" and
> "Ecore vs. XYZ". But that's not the point: the real discussion is how
> can we establish the thinking of models and metamodels in robotics?
>
I agree, that these questions are of much higher importance.
On this ML there are some people, who "believe in models" but there are
also people, who don't.
My goal is to convince them by showing benefits of model-based approach. We
will not establish
thinking in models until we can list their benefits in the context of
robotics.
Some of the benefits is much easier building of (1) modern, full-featured
IDEs, (2) code generators
and (3) checking of well-formedness (including non-trivial constraints)
than before.
> Where are the limits of modeling? Where are the deficits of current
> modeling approaches etc.? The question whether to use Ecore or not is
> secondary, but not unimportant.
>
> Nico
>
>
> >
> > Maybe standardization of Orocos/ROS/Rock/Yarp/whatever is just a dream,
> but
> > as long
> > as they rely on non-standard tools and methods I doubt that this dream
> will
> > come true.
> >
> > --
> > Piotr Trojanek
> >
>
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
[software-toolchain] Eclipse editor for "data message", Google P
On 02/17/2012 03:34 PM, Piotr Trojanek wrote:
> Some of the benefits is much easier building of (1) modern,
> full-featured IDEs, (2) code generators
> and (3) checking of well-formedness (including non-trivial constraints)
> than before.
My experience is that, if you want to advocate modelling, then drop (1)
and (2) because (1) is accessible for plain programming languages and,
for (2), a quite astonishing amount of people don't mind having to write
repetitive code by hand (mostly because they know the manual workflow
very well)
Model-based approaches will start being widespread when they provide
solutions to problem that non-model-based either cannot solve, or at
least problems that are very very hard to solve without models.
[software-toolchain] Eclipse editor for "data message", Google P
On Fri, 17 Feb 2012, Sylvain Joyeux wrote:
> On 02/17/2012 03:34 PM, Piotr Trojanek wrote:
>> Some of the benefits is much easier building of (1) modern,
>> full-featured IDEs, (2) code generators
>> and (3) checking of well-formedness (including non-trivial constraints)
>> than before.
> My experience is that, if you want to advocate modelling, then drop (1)
> and (2) because (1) is accessible for plain programming languages and,
> for (2), a quite astonishing amount of people don't mind having to write
> repetitive code by hand (mostly because they know the manual workflow
> very well)
>
> Model-based approaches will start being widespread when they provide
> solutions to problem that non-model-based either cannot solve, or at
> least problems that are very very hard to solve without models.
Let me just give you one, that is causing tons of problems for decades
already: to make sure that your component exchanges exactly the right set
of six numbers when it provides an end effector velocity to my
component... And this is the simplest possible complexity, namely one
component interacting with one other. What will happen when we have to
connect dozens of them...? This is a rethorical question, because I know
what happens: look at any normal ROS or Orocos application with a handful
or more nodes: developers have to look inside each others' nodes to debug
their semantic data communication problems.
[software-toolchain] Eclipse editor for "data message", Google P
On 02/18/2012 09:28 PM, Herman Bruyninckx wrote:
>> Model-based approaches will start being widespread when they provide
>> solutions to problem that non-model-based either cannot solve, or at
>> least problems that are very very hard to solve without models.
>
> Let me just give you one, that is causing tons of problems for decades
> already: to make sure that your component exchanges exactly the right set
> of six numbers when it provides an end effector velocity to my
> component... And this is the simplest possible complexity, namely one
> component interacting with one other. What will happen when we have to
> connect dozens of them...? This is a rethorical question, because I know
> what happens: look at any normal ROS or Orocos application with a handful
> or more nodes: developers have to look inside each others' nodes to debug
> their semantic data communication problems.
You know that you don't need to convince me ;-)
The fact is that most people are fine to have the first barrier to
incompatibilities be the weak-semantic-annotation that is provided with
typing and then do the rest based on naming. The very fact that ROS is
"so popular" is a statement to this.
Heck. A lot of people are fine with just building monolithic applications !
[software-toolchain] Eclipse editor for "data message", Google P
On Sat, Feb 18, 2012 at 21:28, Herman Bruyninckx <
Herman [dot] Bruyninckx [..] ...> wrote:
> On Fri, 17 Feb 2012, Sylvain Joyeux wrote:
>
> On 02/17/2012 03:34 PM, Piotr Trojanek wrote:
>>
>>> Some of the benefits is much easier building of (1) modern,
>>> full-featured IDEs, (2) code generators
>>> and (3) checking of well-formedness (including non-trivial constraints)
>>> than before.
>>>
>> My experience is that, if you want to advocate modelling, then drop (1)
>> and (2) because (1) is accessible for plain programming languages and,
>> for (2), a quite astonishing amount of people don't mind having to write
>> repetitive code by hand (mostly because they know the manual workflow
>> very well)
>>
>> Model-based approaches will start being widespread when they provide
>> solutions to problem that non-model-based either cannot solve, or at
>> least problems that are very very hard to solve without models.
>>
>
> Let me just give you one, that is causing tons of problems for decades
> already: to make sure that your component exchanges exactly the right set
> of six numbers when it provides an end effector velocity to my
> component... And this is the simplest possible complexity, namely one
> component interacting with one other. What will happen when we have to
> connect dozens of them...? This is a rethorical question, because I know
> what happens: look at any normal ROS or Orocos application with a handful
> or more nodes: developers have to look inside each others' nodes to debug
> their semantic data communication problems.
>
IMO for this kind of problems the right solution is strong typing + design
by contract.
Of course, it is possible to use MDE also for this (you can apply MDE for
everything),
but it seems like reinventing cure for the well known disease.
>
> --
>> Sylvain Joyeux (Dr.Ing.)
>>
>
> Herman
>
> Space & Security Robotics
>>
>> !!! Achtung, neue Telefonnummer!!!
>>
>> Standort Bremen:
>> DFKI GmbH
>> Robotics Innovation Center
>> Robert-Hooke-Straße 5
>> 28359 Bremen, Germany
>>
>> Phone: +49 (0)421 178-454136
>> Fax: +49 (0)421 218-454150
>> E-Mail: robotik [..] ...
>>
>> Weitere Informationen: http://www.dfki.de/robotik
>> ------------------------------**------------------------------**
>> -----------
>> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
>> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
>> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
>> (Vorsitzender) Dr. Walter Olthoff
>> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
>> Amtsgericht Kaiserslautern, HRB 2313
>> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
>> USt-Id.Nr.: DE 148646973
>> Steuernummer: 19/673/0060/3
>> ------------------------------**------------------------------**
>> -----------
>> ______________________________**_________________
>> software-toolchain mailing list
>> software-toolchain@best-of-**robotics.org<software-toolchain [..] ...>
>> http://mailman.gps-stuttgart.**de/mailman/listinfo/software-**toolchain<...
>>
>>
> --
> KU Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
> <http://people.mech.kuleuven.**be/~bruyninc
> EURON Coordinator (European Robotics Research Network) <
> http://www.euron.org>
> Open Realtime Control Services <http://www.orocos.org>
> Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
[software-toolchain] Eclipse editor for "data message", Google P
On Sat, 18 Feb 2012, Piotr Trojanek wrote:
> On Sat, Feb 18, 2012 at 21:28, Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> wrote:
> On Fri, 17 Feb 2012, Sylvain Joyeux wrote:
>
> On 02/17/2012 03:34 PM, Piotr Trojanek wrote:
> Some of the benefits is much easier building of
> (1) modern,
> full-featured IDEs, (2) code generators
> and (3) checking of well-formedness (including
> non-trivial constraints)
> than before.
>
> My experience is that, if you want to advocate modelling, then
> drop (1)
> and (2) because (1) is accessible for plain programming
> languages and,
> for (2), a quite astonishing amount of people don't mind
> having to write
> repetitive code by hand (mostly because they know the manual
> workflow
> very well)
>
> Model-based approaches will start being widespread when they
> provide
> solutions to problem that non-model-based either cannot solve,
> or at
> least problems that are very very hard to solve without
> models.
>
>
> Let me just give you one, that is causing tons of problems for decades
> already: to make sure that your component exchanges exactly the right set
> of six numbers when it provides an end effector velocity to my
> component... And this is the simplest possible complexity, namely one
> component interacting with one other. What will happen when we have to
> connect dozens of them...? This is a rethorical question, because I know
> what happens: look at any normal ROS or Orocos application with a handful
> or more nodes: developers have to look inside each others' nodes to debug
> their semantic data communication problems.
>
>
> IMO for this kind of problems the right solution is strong typing + design by
> contract.
You are one of the many that are still thinking in terms of _compile time_
construction of systems... Strong typing is not possible for components
that you have to combine at runtime, where no access is possible anymore to
the representation in the programming language that the components were
written in. In addition, the _type_ of a data structure can perfectly match
at both sides, while the _semantics_ do not!
> Of course, it is possible to use MDE also for this (you can apply MDE for
> everything), but it seems like reinventing cure for the well known
> disease.
You are looking at the wrong diseases :-)
Herman
[software-toolchain] Eclipse editor for "data message", Google P
On Sat, Feb 18, 2012 at 22:07, Herman Bruyninckx <
Herman [dot] Bruyninckx [..] ...> wrote:
>
> IMO for this kind of problems the right solution is strong typing +
>> design by
>> contract.
>>
>
> You are one of the many that are still thinking in terms of _compile time_
> construction of systems... Strong typing is not possible for components
> that you have to combine at runtime, where no access is possible anymore to
> the representation in the programming language that the components were
> written in. In addition, the _type_ of a data structure can perfectly match
> at both sides, while the _semantics_ do not!
I do not agree. Strong typing and design by contract are concepts, which
are independent of
compilation/representation. Formal specification languages (e.g., Z
notation) enforce them
without compilation/representation.
Both concepts rely on idea of "typed interfaces". If your component is
sending/epexcting
a bunch of bytes, then I would not say that there is any "type". When you
bound semantics
to data, then you are strong-typing it. The problem at runtime is only when
components try
to bound semantics to the bunch of bytes, which is essentially *untyped*.
In your example: the first possible error is when someone is applying
semantics of "6 numbers"
to blob of data. Second possibility is applying semantics of "velocity
vector" to these numbers.
Finally, it is possible when applying some "ordering" to elements of the
vector. This way is always
wrong, no matter if it is already runtime or not.
ADA language has already solved this issue and it has been used in
development of much
more complex and multi-teamed software products, than R&D robotics systems.
Of course,
it is much easier in a single-language environment, but concept is clear -
you should never
bound semantics to a bunch of bytes without asserting what's inside. If
this is a cross-language
system wired at runtime, then every message/rpc should have a label about
"what's inside".
What MDE can do is to (a) generate code for creating/checking these labels
at runtime and/or
(b) provide a IDL-like solution to support cross-language system
development.
>
> Of course, it is possible to use MDE also for this (you can apply MDE for
>> everything), but it seems like reinventing cure for the well known
>> disease.
>>
>
> You are looking at the wrong diseases :-)
>
> Herman
[software-toolchain] Eclipse editor for "data message", Google P
On Sat, 18 Feb 2012, Piotr Trojanek wrote:
> On Sat, Feb 18, 2012 at 22:07, Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> wrote:
> IMO for this kind of problems the right solution is strong
> typing + design by
> contract.
>
>
> You are one of the many that are still thinking in terms of _compile time_
> construction of systems... Strong typing is not possible for components
> that you have to combine at runtime, where no access is possible anymore to
> the representation in the programming language that the components were
> written in. In addition, the _type_ of a data structure can perfectly match
> at both sides, while the _semantics_ do not!
>
>
(First of all, Piotr, your postings are tremendously difficult to interpret,
since you seem to rely on a "HTML-only" system for indicating replies to
previuos post... Wouldn't it be possible to adhere to much more accepted
practice on mailinglists, and use ">"-like indentations...? Thanks!)
> I do not agree. Strong typing and design by contract are concepts, which
> are independent of compilation/representation. Formal specification
> languages (e.g., Z notation) enforce them without
> compilation/representation.
"semantic" checking is the clue to the story, not "syntactic"...
> Both concepts rely on idea of "typed interfaces". If your component is
> sending/epexcting a bunch of bytes, then I would not say that there is
> any "type". When you bound semantics to data, then you are strong-typing
> it. The problem at runtime is only when components try to bound semantics
> to the bunch of bytes, which is essentially *untyped*.
I think we first have to agree on the semantics of the word "semantics",
because we seem to talk about different things.
> In your example: the first possible error is when someone is applying semantics of "6
> numbers"
> to blob of data. Second possibility is applying semantics of "velocity vector" to
> these numbers.
> Finally, it is possible when applying some "ordering" to elements of the vector. This
> way is always
> wrong, no matter if it is already runtime or not.
>
> ADA language has already solved this issue
It has not, not at all. Since the "semantic grounding" of your data models
can not be done by a programming language! You need agreement by the
_humans_ in an _application domain_ in order to ground the semantic meaning
of programming language types.
> and it has been used in development of much more complex and multi-teamed
> software products, than R&D robotics systems. Of course, it is much
> easier in a single-language environment, but concept is clear - you
> should never bound semantics to a bunch of bytes without asserting what's
> inside. If this is a cross-language system wired at runtime, then every
> message/rpc should have a label about "what's inside".
Yes, and that is totally lacking in all the "modelling" we do in robotics.
(And in most other fields, by the way...)
> What MDE can do is to (a) generate code for creating/checking these
> labels at runtime and/or (b) provide a IDL-like solution to support
> cross-language system development.
That's true. And that is handy, but only half of the story. The simplest
half.
> Of course, it is possible to use MDE also for this (you can
> apply MDE for
> everything), but it seems like reinventing cure for the well
> known
> disease.
>
> You are looking at the wrong diseases :-)
Herman
[software-toolchain] Eclipse editor for "data message", Google P
On Sun, Feb 19, 2012 at 09:13, Herman Bruyninckx
<Herman [dot] Bruyninckx [..] ...> wrote:
> (First of all, Piotr, your postings are tremendously difficult to interpret,
> since you seem to rely on a "HTML-only" system for indicating replies to
> previuos post... Wouldn't it be possible to adhere to much more accepted
> practice on mailinglists, and use ">"-like indentations...? Thanks!)
(Sorry, now I have switched to Plain text formatting in Gmail, hope
this will help.)
>> I do not agree. Strong typing and design by contract are concepts, which
>> are independent of compilation/representation. Formal specification
>> languages (e.g., Z notation) enforce them without
>> compilation/representation.
>
>
> "semantic" checking is the clue to the story, not "syntactic"...
>
>
>> Both concepts rely on idea of "typed interfaces". If your component is
>> sending/epexcting a bunch of bytes, then I would not say that there is
>> any "type". When you bound semantics to data, then you are strong-typing
>> it. The problem at runtime is only when components try to bound semantics
>> to the bunch of bytes, which is essentially *untyped*.
>
>
> I think we first have to agree on the semantics of the word "semantics",
> because we seem to talk about different things.
Now I got your point.
>
>
>> In your example: the first possible error is when someone is applying
>> semantics of "6
>> numbers"
>> to blob of data. Second possibility is applying semantics of "velocity
>> vector" to
>> these numbers.
>> Finally, it is possible when applying some "ordering" to elements of the
>> vector. This
>> way is always
>> wrong, no matter if it is already runtime or not.
>>
>> ADA language has already solved this issue
>
>
> It has not, not at all. Since the "semantic grounding" of your data models
> can not be done by a programming language! You need agreement by the
> _humans_ in an _application domain_ in order to ground the semantic meaning
> of programming language types.
I think, that this problem is somehow similar to defining semantics of
programming language
(e.g., what is the meaning of the "for" statement, what is the meaning
of the "double" data type.)
You can find an overview of existing approaches in [1]. As you said,
first you need agreement by
the _humans_ and as long as one prefers to put X-axis vertically you
can not do much about this.
MDE technologies combine domain-specific modeling languages whose type
systems formalize
concepts and relationships of a particular domain [2]. This
formalization is the first step and DSML
are good for building an ontology. Second is to provide "semantic
grounding" for concepts and relationships
of an ontology with <<translational semantics>> approach and express
this grounding as model-to-model
transformations (but you still need a good target domain model with
already defined semantics anyway).
If I understand your point correctly, this is how MDE can help to
solve this issue in my opinion.
However, once you agree on semantics of a <concept> you should bind it
to the strongly typed
representation of this concept within your programming language.
Otherwise you will still have
problem of interpreting tuple of 6-numbers as a velocity in one
component and as a force-torque
in another (no matter if you are compiling them within the same build
environment or wire dynamically
at runtime).
[1] Anneke G. Kleppe, Software language engineering: creating
domain-specific languages using metamodels.
Addison-Wesley, 2009.
[2] Schmidt, D.C. (February 2006). "Model-Driven Engineering". IEEE
Computer 39 (2).
>
>
>> and it has been used in development of much more complex and multi-teamed
>> software products, than R&D robotics systems. Of course, it is much
>> easier in a single-language environment, but concept is clear - you
>> should never bound semantics to a bunch of bytes without asserting what's
>> inside. If this is a cross-language system wired at runtime, then every
>> message/rpc should have a label about "what's inside".
>
>
> Yes, and that is totally lacking in all the "modelling" we do in robotics.
> (And in most other fields, by the way...)
>
>
>> What MDE can do is to (a) generate code for creating/checking these
>> labels at runtime and/or (b) provide a IDL-like solution to support
>> cross-language system development.
>
>
> That's true. And that is handy, but only half of the story. The simplest
> half.
>
>
>> Of course, it is possible to use MDE also for this (you can
>> apply MDE for
>> everything), but it seems like reinventing cure for the well
>> known
>> disease.
>>
>> You are looking at the wrong diseases :-)
>
>
> Herman
[software-toolchain] Eclipse editor for "data message", Google P
On Sun, 19 Feb 2012, Piotr Trojanek wrote:
> On Sun, Feb 19, 2012 at 09:13, Herman Bruyninckx
> <Herman [dot] Bruyninckx [..] ...> wrote:
>> (First of all, Piotr, your postings are tremendously difficult to interpret,
>> since you seem to rely on a "HTML-only" system for indicating replies to
>> previuos post... Wouldn't it be possible to adhere to much more accepted
>> practice on mailinglists, and use ">"-like indentations...? Thanks!)
>
> (Sorry, now I have switched to Plain text formatting in Gmail, hope
> this will help.)
It does, thanks!
>>> I do not agree. Strong typing and design by contract are concepts, which
>>> are independent of compilation/representation. Formal specification
>>> languages (e.g., Z notation) enforce them without
>>> compilation/representation.
>>
>> "semantic" checking is the clue to the story, not "syntactic"...
>>
>>> Both concepts rely on idea of "typed interfaces". If your component is
>>> sending/epexcting a bunch of bytes, then I would not say that there is
>>> any "type". When you bound semantics to data, then you are strong-typing
>>> it. The problem at runtime is only when components try to bound semantics
>>> to the bunch of bytes, which is essentially *untyped*.
>>
>>
>> I think we first have to agree on the semantics of the word "semantics",
>> because we seem to talk about different things.
>
> Now I got your point.
>
>>> In your example: the first possible error is when someone is applying
>>> semantics of "6
>>> numbers"
>>> to blob of data. Second possibility is applying semantics of "velocity
>>> vector" to
>>> these numbers.
>>> Finally, it is possible when applying some "ordering" to elements of the
>>> vector. This
>>> way is always
>>> wrong, no matter if it is already runtime or not.
>>>
>>> ADA language has already solved this issue
>>
>> It has not, not at all. Since the "semantic grounding" of your data models
>> can not be done by a programming language! You need agreement by the
>> _humans_ in an _application domain_ in order to ground the semantic meaning
>> of programming language types.
>
> I think, that this problem is somehow similar to defining semantics of
> programming language
> (e.g., what is the meaning of the "for" statement, what is the meaning
> of the "double" data type.)
Indeed. And that is not done in the programming language itself. That's why
the "meta" level comes in, sooner or later.
> You can find an overview of existing approaches in [1]. As you said,
> first you need agreement by
> the _humans_ and as long as one prefers to put X-axis vertically you
> can not do much about this.
>
> MDE technologies combine domain-specific modeling languages whose type
> systems formalize
> concepts and relationships of a particular domain [2]. This
> formalization is the first step and DSML
> are good for building an ontology. Second is to provide "semantic
> grounding" for concepts and relationships
> of an ontology with <<translational semantics>> approach and express
> this grounding as model-to-model
> transformations (but you still need a good target domain model with
> already defined semantics anyway).
>
> If I understand your point correctly, this is how MDE can help to
> solve this issue in my opinion.
> However, once you agree on semantics of a <concept> you should bind it
> to the strongly typed
> representation of this concept within your programming language.
Yes!
> Otherwise you will still have
> problem of interpreting tuple of 6-numbers as a velocity in one
> component and as a force-torque
> in another (no matter if you are compiling them within the same build
> environment or wire dynamically
> at runtime).
>
> [1] Anneke G. Kleppe, Software language engineering: creating
> domain-specific languages using metamodels.
> Addison-Wesley, 2009.
>
> [2] Schmidt, D.C. (February 2006). "Model-Driven Engineering". IEEE
> Computer 39 (2).
Herman
>>> and it has been used in development of much more complex and multi-teamed
>>> software products, than R&D robotics systems. Of course, it is much
>>> easier in a single-language environment, but concept is clear - you
>>> should never bound semantics to a bunch of bytes without asserting what's
>>> inside. If this is a cross-language system wired at runtime, then every
>>> message/rpc should have a label about "what's inside".
>>
>> Yes, and that is totally lacking in all the "modelling" we do in robotics.
>> (And in most other fields, by the way...)
>>
>>> What MDE can do is to (a) generate code for creating/checking these
>>> labels at runtime and/or (b) provide a IDL-like solution to support
>>> cross-language system development.
>>
>> That's true. And that is handy, but only half of the story. The simplest
>> half.
>>
>>
>>> Of course, it is possible to use MDE also for this (you can
>>> apply MDE for
>>> everything), but it seems like reinventing cure for the well
>>> known
>>> disease.
>>>
>>> You are looking at the wrong diseases :-)
>>
>>
>> Herman
>
[software-toolchain] Eclipse editor for "data message", Google P
On Fri, Feb 17, 2012 at 19:39, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:
> Model-based approaches will start being widespread when they provide
> solutions to problem that non-model-based either cannot solve, or at least
> problems that are very very hard to solve without models.
Unfortunately... I agree with you completely! I think, that most of the
exciting robotics applications,
which you can watch on YouTube these days, can be solved without MDE. I am
afraid, that I can
say the same about their need for robot control frameworks also.
If one can manage to create software for thesis/paper/project without using
frameworks, then there
is no way to convince his/her to use them. I think, it is the same with
MDE. The benefit of nice IDE,
which comes with MDE, is somehow similar to benefit of device drivers,
which comes with robot
control frameworks - they are just addons.
The fundamental benefit of both frameworks and MDE, is that they allow you
to build systems of much
higher complexity comparing to those, which you can manage without them. I
like to think about DSL
as "next step" in the plain-code/library/framework path and you can find
some arguments for this in [1].
This path is about *patterns*. If your system is simple, then there is no
need to bother with patterns
and you just write the code. At some point you start discover repetitions
in your code and put them
into function calls. These functions will be repeated in your next program,
so you put them into library.
Then you start discovering patterns of control structures within the code
and you develop a framework
based around them. When you start working with framework made by your
colleague you will probably
discover some kind of repetitions. These are also patterns and you can
collect as a "model".
Maybe the question for the robotics community is not "to use MDE or not",
but "do you need to deal
with such a complexity, which is worth to use MDE"?
[1] Anneke G. Kleppe, Software language engineering: creating
domain-specific languages using metamodels.
Addison-Wesley, 2009.
P.S. I also want to thank all the participants for the discussion, as
expressed by Sylvian in thread dedicated to him :-)
> --
> Sylvain Joyeux (Dr.Ing.)
> Space & Security Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax: +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> Weitere Informationen: http://www.dfki.de/robotik
> ------------------------------**------------------------------**
> -----------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973
> Steuernummer: 19/673/0060/3
> ------------------------------**------------------------------**
> -----------
>
[software-toolchain] Eclipse editor for "data message", Google P
On Fri, Feb 17, 2012 at 03:34:58PM +0100, Piotr Trojanek wrote:
> On Fri, Feb 17, 2012 at 15:09, Nico Hochgeschwender <
> nico [dot] hochgeschwender [..] ...> wrote:
>
> It seems that this thread is very much about "Eclipse vs. XYZ" and
> "Ecore vs. XYZ". But that's not the point: the real discussion is how
> can we establish the thinking of models and metamodels in robotics?
>
>
> I agree, that these questions are of much higher importance.
>
> On this ML there are some people, who "believe in models" but there are also
> people, who don't.
> My goal is to convince them by showing benefits of model-based approach. We
> will not establish
> thinking in models until we can list their benefits in the context of robotics.
I don't think there are many (if any) people that need to be convinced
of the importance of modeling. But there might be some people to
convince about how to build robust, maintainable and usable tools.
> Some of the benefits is much easier building of (1) modern, full-featured IDEs,
> (2) code generators
> and (3) checking of well-formedness (including non-trivial constraints) than
> before.
I've heard that before. Still in practice it turns out to be harder
than those marketing flyers want to make you think...
Markus
[software-toolchain] Eclipse editor for "data message", Google P
On Fri, Feb 17, 2012 at 15:58, Markus Klotzbuecher <
markus [dot] klotzbuecher [..] ...> wrote:
> I don't think there are many (if any) people that need to be convinced
> of the importance of modeling. But there might be some people to
> convince about how to build robust, maintainable and usable tools.
>
Tools are just one of the benefits of MDE. With the model-centric approach
all the elements of a toolchain
fit together, e.g., IDEs for visual and textual notations, semantic
definitions, generators for code, documentation
and test cases.
> > Some of the benefits is much easier building of (1) modern,
> full-featured IDEs,
> > (2) code generators
> > and (3) checking of well-formedness (including non-trivial constraints)
> than
> > before.
>
> I've heard that before. Still in practice it turns out to be harder
> than those marketing flyers want to make you think...
>
Interesting impression. Can you tell us more about grounds of your opinion?
Do you know about some negative
experience reports from applying MDE in practice?
Some time ago I have found this presentation:
http://www.theenterprisearchitect.eu/archive/2011/01/25/why-there-is-no-...
But even the author concludes: *"[...] if we do MDD in a proper way we will
get new challenges. Model Driven
Development is necessary, but not sufficient!*" (this is more to software
factories, but some points may be
common also for the robotics context).
[software-toolchain] Eclipse editor for "data message", Google P
On Fri, Feb 17, 2012 at 04:42:10PM +0100, Piotr Trojanek wrote:
> On Fri, Feb 17, 2012 at 15:58, Markus Klotzbuecher <
> markus [dot] klotzbuecher [..] ...> wrote:
>
> I don't think there are many (if any) people that need to be convinced
> of the importance of modeling. But there might be some people to
> convince about how to build robust, maintainable and usable tools.
>
>
> Tools are just one of the benefits of MDE. With the model-centric approach all
> the elements of a toolchain
> fit together, e.g., IDEs for visual and textual notations, semantic
> definitions, generators for code, documentation
> and test cases.
>
>
> > Some of the benefits is much easier building of (1) modern, full-featured
> IDEs,
> > (2) code generators
> > and (3) checking of well-formedness (including non-trivial constraints)
> than
> > before.
>
> I've heard that before. Still in practice it turns out to be harder
> than those marketing flyers want to make you think...
>
>
> Interesting impression. Can you tell us more about grounds of your opinion? Do
> you know about some negative
> experience reports from applying MDE in practice?
>
> Some time ago I have found this presentation:
> http://www.theenterprisearchitect.eu/archive/2011/01/25/
> why-there-is-no-future-for-model-driven-development
> But even the author concludes: "[...] if we do MDD in a proper way we will get
> new challenges. Model Driven
> Development is necessary, but not sufficient!" (this is more to software
> factories, but some points may be
> common also for the robotics context).
Piotr, I am at all against MDE, nor do have I made any negative
experience. My only point is that in situations in which the models
are not very well understood or are likely subject to change (which is
often the case with behavioral models), the internal DSL will IMHO
help you evolve faster and hence obtain results more quickly than
going through the more heavyweight Eclipse way.
This is my opinion gained upon developing a non-trivial behavioral
model (rFSM). However now that things are settling, I am very well
considering taking the "informal" meta-model (that by the way has been
quite explicit in my head all the way) and formalizing it for the
purpose of generating some pretty editing facilities.
As other pointed out, I hope we can settle this thread now and indeed
focus on the numerous modeling challenges out there.
Best regards
Markus
[software-toolchain] Eclipse editor for "data message", Google P
On 02/17/2012 11:27 AM, Markus Klotzbuecher wrote:
>> Examples:
>>
>> * genom (all versions, that's dating back to 1995)
>> * typegen/orogen (Typelib::Type and subclasses and Orocos::Spec::*)
>> * ROS messages (unless I am mistaken, they do have an internal
>> representation of the messages)
> * rFSM :-)
:)
>> Could you share counter-examples ?
>
> No, the only difference is having a non-standard built-in meta-model
> specialized for the particular tool
I guess that the point is how much you can reuse the actual model
(without the meta-) for other purposes. I'm starting to model ROS nodes
with oroGen models... Doable since ROS is a subset of oroGen/RTT.
> vs. a semi-standard ecore
> meta-model that is often unable to specify all necessary constraints.
I think that the keyword here is "semi-standard". Moreover, when I
looked, last time we had that discussion, on the corresponding webpages
of the eclipse framework, what stroke me in the code-generation parts is
how it looks VERY MUCH like templating. It has a fancy "model
transformation" name attached to it, but it's pretty much the same.
> I think the differences are smaller than they might appear.
Thanks for summarizing my point so well.
[software-toolchain] Eclipse editor for "data message", Google P
On Fri, Feb 17, 2012 at 11:44, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:
> I think that the keyword here is "semi-standard". Moreover, when I
> looked, last time we had that discussion, on the corresponding webpages
> of the eclipse framework, what stroke me in the code-generation parts is
> how it looks VERY MUCH like templating. It has a fancy "model
> transformation" name attached to it, but it's pretty much the same.
>
Yes, it is templating, of course. However, writing templates within MDE
ecosystem
is much easier than without it. You have model-aware code completion,
dedicated
debugging modes, etc.
Depending on the MDE toolchain you will get different "development speed",
but
definitely they outperform any non-MDE approach. You can find some
comparison
results on the web, e.g., here: http://www.languageworkbenches.net/
> > I think the differences are smaller than they might appear.
> Thanks for summarizing my point so well.
> --
> Sylvain Joyeux (Dr.Ing.)
> Space & Security Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax: +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> Weitere Informationen: http://www.dfki.de/robotik
> -----------------------------------------------------------------------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973
> Steuernummer: 19/673/0060/3
> -----------------------------------------------------------------------
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
Eclipse editor for "data message", Google Protocol Buffer versio
On Fri, Feb 17, 2012 at 10:33, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:
> Examples:
>
> * genom (all versions, that's dating back to 1995)
>
Some months ago I was trying to build similar tool for Genom specification
(I do not remember exactly,
but I think I was using Xtext or EMFText for this). However, at that time
it was not possible, because
the underlying meta-metamodel of these tools put some constraints on
grammars, which are possible
to implement.
My observation (in general), is that the most difficult task when applying
MDE to legacy ideas is not to
find the underlying formal model, but to fit tools with existing syntax.
Thus, one of the benefits of MDE
is clear separation between concepts and corresponding textual/graphical
notations.
* typegen/orogen (Typelib::Type and subclasses and Orocos::Spec::*)
> * ROS messages (unless I am mistaken, they do have an internal
> representation of the messages)
>
> Could you share counter-examples ?
> --
> Sylvain Joyeux (Dr.Ing.)
> Space & Security Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax: +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> Weitere Informationen: http://www.dfki.de/robotik
> -----------------------------------------------------------------------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973
> Steuernummer: 19/673/0060/3
> -----------------------------------------------------------------------
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
Eclipse editor for "data message", Google Protocol Buffer versio
On 02/17/2012 11:23 AM, Piotr Trojanek wrote:
> Some months ago I was trying to build similar tool for Genom
> specification (I do not remember exactly,
> but I think I was using Xtext or EMFText for this). However, at that
> time it was not possible, because
> the underlying meta-metamodel of these tools put some constraints on
> grammars, which are possible
> to implement.
>
> My observation (in general), is that the most difficult task when
> applying MDE to legacy ideas is not to
> find the underlying formal model, but to fit tools with existing syntax.
> Thus, one of the benefits of MDE
> is clear separation between concepts and corresponding textual/graphical
> notations.
What you failed to do with Genom is parse the textual representation.
Genom (the tool) has an internal model representation and a parser that
populates this model. That you don't want to reuse the tool is your
choice, but discarding it as "not model based" BECAUSE you don't want to
reuse the tool is a shortcut that you should not do.
If I don't want to your-eclipse-based-MDE-framework-of-choice, I will
have to transmit the model information through a textual representation.
Which might no be doable in my-tool-of-choice. That does not allow me to
say that what you are doing is not model-based.
Eclipse editor for "data message", Google Protocol Buffer versio
On Fri, Feb 17, 2012 at 11:40, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:
> On 02/17/2012 11:23 AM, Piotr Trojanek wrote:
>
>> Some months ago I was trying to build similar tool for Genom
>> specification (I do not remember exactly,
>> but I think I was using Xtext or EMFText for this). However, at that
>> time it was not possible, because
>> the underlying meta-metamodel of these tools put some constraints on
>> grammars, which are possible
>> to implement.
>>
>> My observation (in general), is that the most difficult task when
>> applying MDE to legacy ideas is not to
>> find the underlying formal model, but to fit tools with existing syntax.
>> Thus, one of the benefits of MDE
>> is clear separation between concepts and corresponding textual/graphical
>> notations.
>>
> What you failed to do with Genom is parse the textual representation.
> Genom (the tool) has an internal model representation and a parser that
> populates this model. That you don't want to reuse the tool is your choice,
> but discarding it as "not model based" BECAUSE you don't want to reuse the
> tool is a shortcut that you should not do.
>
I agree, that the problem was not in Genom itself, but with the MDE tools
at that time. Moreover,
that limitation seemed to be easy to fix, so maybe it is not problem any
more.
I also agree, that when you can reuse the non-MDE-tool you should to this
(why not?!). However,
Genom tools give you "only" (1) parsing input files to generate code
templates and (2) basic syntax
support for editors like Emacs or Vim.
At that time I was rather interested in building modern, full featured IDE
(with cross-navigation, outlining,
etc.) without modifying existing syntax. If you prefer to have home-made,
hidden meta-metamodel - OK.
But can you build these kind of support tools *as easily* as with MDE
framework?
MDE does not give you anything, which you can not develop without it.
Rather, it gives you dedicated tools
for every step of your workflow. E.g., you can build parser with lex/yacc,
implement your constraints in C,
code generator in TCL, editor support by manually crafting vim-syntax files
- this is what Genom does and
there was no alternative at that time. Now there is an alternative, it's
MDE.
>
> If I don't want to your-eclipse-based-MDE-**framework-of-choice, I will
> have to transmit the model information through a textual representation.
> Which might no be doable in my-tool-of-choice. That does not allow me to
> say that what you are doing is not model-based.
>
> --
> Sylvain Joyeux (Dr.Ing.)
> Space & Security Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax: +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> Weitere Informationen: http://www.dfki.de/robotik
> ------------------------------**------------------------------**
> -----------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973
> Steuernummer: 19/673/0060/3
> ------------------------------**------------------------------**
> -----------
>
Eclipse editor for "data message", Google Protocol Buffer versio
On 02/17/2012 12:15 PM, Piotr Trojanek wrote:
> At that time I was rather interested in building modern, full featured
> IDE (with cross-navigation, outlining,
> etc.) without modifying existing syntax. If you prefer to have
> home-made, hidden meta-metamodel - OK.
> But can you build these kind of support tools *as easily* as with MDE
> framework?
Don't forget that what you get with your MDE framework is that support
*within* your MDE ecosystem (in your case, Eclipse). If I'm not an
eclipse user, I don't get a benefit. Moreover, it makes it impossible to
use in contexts where Eclipse cannot run. I'm using all these models at
runtime within a Ruby execution framework, and using an embedded Ruby
DSL gives me the ability to access these models transparently.
> MDE does not give you anything, which you can not develop without it.
> Rather, it gives you dedicated tools
> for every step of your workflow. E.g., you can build parser with
> lex/yacc, implement your constraints in C,
> code generator in TCL, editor support by manually crafting vim-syntax
> files - this is what Genom does and
> there was no alternative at that time. Now there is an alternative, it's
> MDE.
Using embedded DSLs is also a path towards removing most of the same
pain. Again, I'm not "for" or "against" MDE frameworks like eCore. I'm
just going against the "the only MDE is Eclipse-based-pure-MDE" feeling
that "if you don't use meta^3-models, you are not developing
model-driven systems", as it has been hinted at (and even stated a few
times) more than once on this ML.
Eclipse editor for "data message", Google Protocol Buffer versio
On Fri, Feb 17, 2012 at 12:56, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:
> On 02/17/2012 12:15 PM, Piotr Trojanek wrote:
>
>> At that time I was rather interested in building modern, full featured
>> IDE (with cross-navigation, outlining,
>> etc.) without modifying existing syntax. If you prefer to have
>> home-made, hidden meta-metamodel - OK.
>> But can you build these kind of support tools *as easily* as with MDE
>> framework?
>>
> Don't forget that what you get with your MDE framework is that support
> *within* your MDE ecosystem (in your case, Eclipse). If I'm not an eclipse
> user, I don't get a benefit. Moreover, it makes it impossible to use in
> contexts where Eclipse cannot run. I'm using all these models at runtime
> within a Ruby execution framework, and using an embedded Ruby DSL gives me
> the ability to access these models transparently.
You are not using Eclipse and I am not using Ruby :-)
However, it is not a problem to access external-DSL models from any
language. This can be easily solved with model-to-code
transformation or maybe even meta-metamodel specific API (e.g., XMI access
from Ruby). On the other hand, accessing models
embedded into general purpose programming languages is much more difficult
(you need much more complex parser, since the
grammar of the underlying language is usually much more complex).
Also, how about *deeply* embedded systems (e.g., Lego NXT), where you can
forget about Ruby?
>
>
> MDE does not give you anything, which you can not develop without it.
>> Rather, it gives you dedicated tools
>> for every step of your workflow. E.g., you can build parser with
>> lex/yacc, implement your constraints in C,
>> code generator in TCL, editor support by manually crafting vim-syntax
>> files - this is what Genom does and
>> there was no alternative at that time. Now there is an alternative, it's
>> MDE.
>>
> Using embedded DSLs is also a path towards removing most of the same pain.
> Again, I'm not "for" or "against" MDE frameworks like eCore. I'm just going
> against the "the only MDE is Eclipse-based-pure-MDE" feeling that "if you
> don't use meta^3-models, you are not developing model-driven systems", as
> it has been hinted at (and even stated a few times) more than once on this
> ML.
Embedded DSLs put considerable constraints on your design: (1) syntax is
limited by the syntax of the host language
(not to say that it is limited to textual notations), (2) it requires
reflection (for "parsing") and reasonable code generation
support from the host language (you can do this with printf/scanf, but
templates seems to be better).
I am not Eclipse nor ECore advocate. There are many workbenches and
meta-metamodels, which seems more attractive.
But eclipse is free and Ecore is almost-standard - that's all. I do not
know about any MDE definition, which says, that it
needs to be Eclipse. If you know such a definition, there are (at least)
two of use against it.
MDE is a methodology, just as OO software development. My point is, that
you can do MDE with lex/yacc/C/TCL and
OO programming with assembler. Or you can use dedicated tools (which need
not to be Eclipse).
>
> --
> Sylvain Joyeux (Dr.Ing.)
> Space & Security Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax: +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> Weitere Informationen: http://www.dfki.de/robotik
> ------------------------------**------------------------------**
> -----------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973
> Steuernummer: 19/673/0060/3
> ------------------------------**------------------------------**
> -----------
>
Eclipse editor for "data message", Google Protocol Buffer versio
On Fri, Feb 17, 2012 at 02:12:18PM +0100, Piotr Trojanek wrote:
> On Fri, Feb 17, 2012 at 12:56, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
>
> On 02/17/2012 12:15 PM, Piotr Trojanek wrote:
>
> At that time I was rather interested in building modern, full featured
> IDE (with cross-navigation, outlining,
> etc.) without modifying existing syntax. If you prefer to have
> home-made, hidden meta-metamodel - OK.
> But can you build these kind of support tools *as easily* as with MDE
> framework?
>
> Don't forget that what you get with your MDE framework is that support
> *within* your MDE ecosystem (in your case, Eclipse). If I'm not an eclipse
> user, I don't get a benefit. Moreover, it makes it impossible to use in
> contexts where Eclipse cannot run. I'm using all these models at runtime
> within a Ruby execution framework, and using an embedded Ruby DSL gives me
> the ability to access these models transparently.
>
>
> You are not using Eclipse and I am not using Ruby :-)
I _am_ using Eclipse where it makes sense to me.
> However, it is not a problem to access external-DSL models from any language.
> This can be easily solved with model-to-code
> transformation or maybe even meta-metamodel specific API (e.g., XMI access from
> Ruby). On the other hand, accessing models
> embedded into general purpose programming languages is much more difficult (you
> need much more complex parser, since the
> grammar of the underlying language is usually much more complex).
No, the difficulty is _not_ the parsing but because the general
purpose language is used to add behavior to the model, and Ecore,
being purely structural can't easily handle that.
> Also, how about *deeply* embedded systems (e.g., Lego NXT), where you can
> forget about Ruby?
For the record: i'm not using Ruby, I'm using Lua, and it has been
embedded exhaustively (even outside of Operating Systems in
bootloaders such as GRUB) and also in your Lego bots:
http://en.wikipedia.org/wiki/Lego_Mindstorms_NXT#Lua
Best regards
Markus
Eclipse editor for "data message", Google Protocol Buffer versio
On Fri, Feb 17, 2012 at 14:44, Markus Klotzbuecher <
markus [dot] klotzbuecher [..] ...> wrote:
> > However, it is not a problem to access external-DSL models from any
> language.
> > This can be easily solved with model-to-code
> > transformation or maybe even meta-metamodel specific API (e.g., XMI
> access from
> > Ruby). On the other hand, accessing models
> > embedded into general purpose programming languages is much more
> difficult (you
> > need much more complex parser, since the
> > grammar of the underlying language is usually much more complex).
>
> No, the difficulty is _not_ the parsing but because the general
> purpose language is used to add behavior to the model, and Ecore,
> being purely structural can't easily handle that.
>
I see no reason for the ECore to own any behavioral semantics. But ECore
(and other
meta-metamodels as well) can describe languages with behavioral semantics
without
any problem.
The behavioral semantics is not assigned by the ECore, but by
*transformations*, which
generate corresponding models within domains with already defined
(behavioral) semantics.
Parsing of general purpose languages *is* difficult, unless there is a
*formal* model of the syntax.
For the full C++ there is no (e.g., there is no BNF grammar, from which you
can auto-generate parser).
With the external DSLs this is different, because every "program" (or
rather "model") written in an external
DSL conforms with the underlying, formal meta-metamodel.
>
> > Also, how about *deeply* embedded systems (e.g., Lego NXT), where you can
> > forget about Ruby?
>
> For the record: i'm not using Ruby, I'm using Lua, and it has been
> embedded exhaustively (even outside of Operating Systems in
> bootloaders such as GRUB) and also in your Lego bots:
>
> http://en.wikipedia.org/wiki/Lego_Mindstorms_NXT#Lua
>
There is no problem if you can afford accessing your models at runtime
(e.g., have Eclipse-rooted OCL library
installed, Ruby, etc.). The problem is if you can not and I see no other
solution than code generation.
Eclipse editor for "data message", Google Protocol Buffer versio
On Fri, Feb 17, 2012 at 03:15:02PM +0100, Piotr Trojanek wrote:
> On Fri, Feb 17, 2012 at 14:44, Markus Klotzbuecher <
> markus [dot] klotzbuecher [..] ...> wrote:
>
> > However, it is not a problem to access external-DSL models from any
> language.
> > This can be easily solved with model-to-code
> > transformation or maybe even meta-metamodel specific API (e.g., XMI
> access from
> > Ruby). On the other hand, accessing models
> > embedded into general purpose programming languages is much more
> difficult (you
> > need much more complex parser, since the
> > grammar of the underlying language is usually much more complex).
>
> No, the difficulty is _not_ the parsing but because the general
> purpose language is used to add behavior to the model, and Ecore,
> being purely structural can't easily handle that.
>
>
> I see no reason for the ECore to own any behavioral semantics. But ECore (and
> other
> meta-metamodels as well) can describe languages with behavioral semantics
> without
> any problem.
>
> The behavioral semantics is not assigned by the ECore, but by
> *transformations*, which
> generate corresponding models within domains with already defined (behavioral)
> semantics.
Yes, you can do that, with 10 times the effort...
> Parsing of general purpose languages *is* difficult, unless there is a *formal*
> model of the syntax.
> For the full C++ there is no (e.g., there is no BNF grammar, from which you can
> auto-generate parser).
That's exactly why Sylvain and I are _not_ writing parsers but are
using the existing ones for free. Why would you want to write an
internal DSL in C++?
> With the external DSLs this is different, because every "program" (or rather
> "model") written in an external
> DSL conforms with the underlying, formal meta-metamodel.
Yep, nice, but "un-embeddable" dependencies.
> > Also, how about *deeply* embedded systems (e.g., Lego NXT), where you can
> > forget about Ruby?
>
> For the record: i'm not using Ruby, I'm using Lua, and it has been
> embedded exhaustively (even outside of Operating Systems in
> bootloaders such as GRUB) and also in your Lego bots:
>
> http://en.wikipedia.org/wiki/Lego_Mindstorms_NXT#Lua
>
>
> There is no problem if you can afford accessing your models at runtime (e.g.,
> have Eclipse-rooted OCL library
> installed, Ruby, etc.). The problem is if you can not and I see no other
> solution than code generation.
Yes, that's your problem and exactly why I don't use any OCL library
for now.
Markus
[software-toolchain] Eclipse editor for "data message", Google P
> Unless you mean "not in eclipse" by "not using a formal model" (if you
> are wondering, I am being a bit sarcastic there, that was too tempting),
> code generators are in robotics (1) few and (2) all the ones that come
> to my mind do have an underlying model representation.
>
> Examples:
>
> * genom (all versions, that's dating back to 1995)
> * typegen/orogen (Typelib::Type and subclasses and Orocos::Spec::*)
> * ROS messages (unless I am mistaken, they do have an internal
> representation of the messages)
>
Sylvain
What is your problem with models? What is your point?
-H
[software-toolchain] Eclipse editor for "data message", Google P
On 02/17/2012 11:23 AM, Hugo Garcia wrote:
> What is your problem with models? What is your point?
I have no problem with models, I'm developing and advocating Rock, which
is indeed a model-based toolchain (and will hopefully talk about it at
the ERF if my abstract proposal is accepted).
However, I am against a trend to split between "true" model-driven and
"false" model-driven, which has been (in my opinion) done quite a few
times on this ML, where the "true" model-driven are the approach that
are doing metamodelling.
I know that Herman's point of view is that the only "true" model-driven
approach is the one where you start at least at one meta-model (i.e. you
are modelling your models). I think that we both agree to not agree on
this point. As soon as you are having one level of models you *are*
model-based.
In this thread, I was reacting to the "most code generators in robotics
don't have a model representation" statement, which to my limited
knowledge is not true. Hence the few examples I provided.
[software-toolchain] Eclipse editor for "data message", Google P
On Fri, 17 Feb 2012, Sylvain Joyeux wrote:
> On 02/17/2012 11:23 AM, Hugo Garcia wrote:
>> What is your problem with models? What is your point?
> I have no problem with models, I'm developing and advocating Rock, which
> is indeed a model-based toolchain (and will hopefully talk about it at
> the ERF if my abstract proposal is accepted).
>
> However, I am against a trend to split between "true" model-driven and
> "false" model-driven, which has been (in my opinion) done quite a few
> times on this ML, where the "true" model-driven are the approach that
> are doing metamodelling.
I leave the responsibility for this comment to you :-) I most definitely
have never had the intention to make such a claim.
> I know that Herman's point of view is that the only "true" model-driven
> approach is the one where you start at least at one meta-model (i.e. you
> are modelling your models). I think that we both agree to not agree on
> this point. As soon as you are having one level of models you *are*
> model-based.
Sure, but the meta-model allows you to go further, plain and simple. Well,
"simple" is definitely not really the right word here :-) The meta-model is
the "introspection" to your model, so you need it if you want your
components to decide automatically whether or not they understand each
other's models.
This is indeed not "needed" in the current robotics state of the practice
where tons of human developers spend thousands of hours debugging the
_semantics_ of the code they interchange...
> In this thread, I was reacting to the "most code generators in robotics
> don't have a model representation" statement, which to my limited
> knowledge is not true. Hence the few examples I provided.