Re: [certi-dev] Java Binding

[Andrej Pancik]

Hello,

 I have finished the preliminary version of second Java generator. It
successfully parsers current proto message file and generates java
message classes. The code is still very ugly - I will use native types
better later when refactoring.

 To download the current code visit:
https://savannah.nongnu.org/task/download.php?file_id=19918

 Anyway, the code of RTI ambassador needs changes in almost all of the
messages but these changes can not be done until full message
specification is in place. Should I add the missing parts of message
specification or should I wait for you. I strongly suggest to do the
adjusting of ambassador only once (so we must be sure that generation
data are proper) since distribution of changes to rti ambassador code
can not be done automatically and it is pretty time consuming (more
than 500 manual changes). If you need more information about this
issue I will be glad to describe it in extend.

Note #1:
What do you think about putting in of the combined type name. Something like:

combine AttributeHandleValuePairSet suppliedAttributes{
           repeated AttributeHandle       attributes
           repeated AttributeValue_t      values
        }


Note #2:
My generator needs straightforward modification of of receive
interaction and send interaction classes to something like this

message M_Receive_Interaction : merge Message {
        required InteractionClassHandle interactionClass
    combine ParameterHandleValuePairSet
    {
    repeated ParameterHandle        parameters
           repeated ParameterValue_t       values
     }
        required RegionHandle           region  
        combine EventRetractionHandle {
           optional EventRetraction eventRetraction
        }
}

regards

Andrej Pancik

On Fri, Mar 5, 2010 at 3:10 PM, Eric Noulard <address@hidden> wrote:
> 2010/2/28 Eric Noulard <address@hidden>:
>> 2010/2/28 Andrej Pancik <address@hidden>:
>>> My response is included up there in the body of your email. I will try to 
>>> write
>>> more verbose explanation of my point of view on this issue tomorrow if
>>> needed - please write if it is the case.
>>
>> I think I caught your point.
>> I'll give this a try and keep you informed.
>
> Andrej,
>
> I did try some evolution in the message generator (and the specifications) 
> which
> should enables you to do what you want.
>
> I have added the notion of "combined" message field.
> For example the UAV message specification is now:
>
> message M_Update_Attribute_Values : merge Message {
>         required ObjectClassHandle     objectClass
>         required ObjectHandle          object
>         combine AttributeHandleValuePairSet {
>              repeated AttributeHandle       attributes
>              repeated AttributeValue_t      values
>        }
>        optional EventRetractionHandle eventRetraction
> }
>
> as you can see the fields attributes and values are "combine" into
> a AttributeHandleValuePairSet.
>
> The combine type itself is a a native message:
>
> native AttributeHandleValuePairSet {
>    representation combine
>    language CXX   [#include "RTItypes.hh"]
>    language Java  [import hla.rti.SuppliedAttributes]
> }
>
> This means that now you know that those fields should be "combined"
> by the generator backend into a to-be-matched native type.
> However it also means that the message must  be serialized
> as-if there were the "uncombined fields".
>
> You can add as many "language Java  [xxx]" lines you want in order to be able
> to do the match more easily.
> Note that we will( must) be able to support several variant
> (JavaHLA13, JavaIEEE1516, CXXHLA13, CXXIEEE1516)
> variant using this scheme, while keeping the same "internal"
> serialized messages.
>
> I think the mechanism is powerful enough to cleanly implement your ideas
> and keep as many informations as we need for serialization,
> what do you think?
>
> During this update I did split the monolitical GenerateMessage.py script into:
>
> GenerateMessages.py - the main as before
> GenMsgAST.py - the AST type definition and ASTChecker
> GenMsgBase.py - the message generator base class including MsgSpec
> GenMsgCXX.py - the C++ message generator  (updated to handle combine fields)
> GenMsgJava.py - the Java message generator (not updated [yet])
> GenMsgPython.py - the Python message generator
>
> I did not have time to update your message generator
> but I can give you a hand on this if you want.
>
> Now at least we can work on GenMsg<LANG>.py in a clean separate fashion.
>
> Waiting for your feedback on this.
> --
> Erk
> Membre de l'April - « promouvoir et défendre le logiciel libre » -
> http://www.april.org
>
>
> --
> CERTI-Devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/certi-devel
>