taskCERTI - Tasks: task #10290, Implement [part of] IEEE-1516 API

 
 

You are not allowed to post comments on this tracker with your current authentification level.

task #10290: Implement [part of] IEEE-1516 API

Submitted by:  Eric NOULARD <erk>
Submitted on:  Mon 22 Mar 2010 08:13:42 AM UTC  
 
Should Start On: Sun 21 Mar 2010 11:00:00 PM UTCShould be Finished on: Sun 21 Mar 2010 11:00:00 PM UTC
Category: IEEE-1516 compliancePriority: 5 - Normal
Status: DonePrivacy: Public
Percent Complete: 100%Assigned to: Jeroen van IJperen <vyperx>
Open/Closed: ClosedPlanned Release: CERTI 3.4.0
RTI Service Groups: None

(Jump to the original submission Jump to the original submission)

Thu 11 Nov 2010 11:17:24 AM UTC, comment #22:

This work has been integrated into CERTI 3.4.0.

Eric NOULARD <erk>
Project Administrator
Mon 31 May 2010 09:38:14 AM UTC, comment #21:

I've just checked-in the latest attached patch.
this one does neither includes the STATIC lib trick
nor the LogicalTimeDouble class.

Some remarks concerning modifications I did include myself before check-in:

- try to avoid mixin C style include and [new] C++ style ones.
#include <math.h>
should be
#include <cmath>

- size_t is usually unsigned so beware of
comparing "int" with "size_t".
Most of the time you'd better use <cstdint> types
uint8/16/32/64 and int8/16/32/64
I did add the appropriate definitions in
RTI/SpecificConfig.h

- you may use STL algorithm std::for_each
http://www.cplusplus.com/reference/algorithm/for_each/
for deleting all point stored in a container.

Declare:

template <class T>
struct deletor {
void operator() (T* e) {delete e;};
};

then use:
struct deletor<whatevertype> deletorWhatever
std::vector<whatevertype*> c;
...
std::for_each(c.begin(),c.end(),deletorWhatever);

(file #20661)

Eric NOULARD <erk>
Project Administrator
Sat 29 May 2010 09:27:30 PM UTC, comment #20:

Update Jeroen Modif as a patch (with modifications)
Currently the patch does not compile on Linux,
there is some more work to do.

(file #20652)

Eric NOULARD <erk>
Project Administrator
Thu 27 May 2010 12:23:36 PM UTC, comment #19:

Hi Jeroen,

Thank you for all the updates.
I'll try to process them today
and will keep you informed of what is merged and what is not.

Concerning the test modules,
I'll put them in HLA_TestsSuite myself.

I'll have a tight look at the static lib solution.

Alternate logical time may be useful, we'll see
if we should keep such thing in CERTI
(built-on FedTime lib or as a separate lib)
and/or propose a separate module (like python binding etc...)

Eric NOULARD <erk>
Project Administrator
Thu 27 May 2010 11:54:42 AM UTC, comment #18:

Hi Eric,

I've added a new version of our CERTI-branch... I'm afraid we haven't merged any changes you may have made in the mean time, but I hope the overlap will not be that large. The test modules are also still under the CERTI project, so you may want to keep those out when merging.

Additionally, I have attached the overview of the implemented services. Please note that some services are not tested, although this is not indicated in the overview yet.

Also, I have added another LogicalTime implementation to the FedTime1516 library. This is the one that is used in our project (BITS), and was difficult to include for us otherwise. Things like that I think we should better keep as a user-patch to the main CERTI stuff, but it's there now.

Finally, I think I have solved the circular dependency problem by introducing a new static libary (ExportRTI1516), which contains the classes (Exceptions, etc) needed by the FedTime1516 dynamic library.

Kind regards,

Jeroen

(file #20635, file #20636)

Jeroen van IJperen <vyperx>
Project MemberIn charge of this item.
Tue 25 May 2010 01:48:15 PM UTC, comment #17:

Hello Eric,

Things are going quite well on this side. We've completed the RTI1516 services we require and are now moving our original project to make use of CERTI.

We've partially tested the services we've ported, but we won't be testing all of them, because of budget constraints.

I'll fill in the spreadsheet tomorrow, along with a new version of the RTI1516 modules.

During the port of our project, I'm sure we will find some additional stuff in Certi that needs porting/fixing, so we're not completely done yet. :)

After this I'm not sure yet how things will go for me personally (with regard to new projects), but if I have the time, I'll put in some work to 'round off' the work we did for CERTI. (I.e. better responses for the test cases, using correct .cc/.hh files, etc.)

Jeroen van IJperen <vyperx>
Project MemberIn charge of this item.
Tue 25 May 2010 01:38:18 PM UTC, comment #16:

Hi Jeroen,

Maxime is currently working on test case based on
Pierre interactive federate (in HLA_TestsSuite).

The idea is to use the interactive federate which is kind
of "scriptable" federate which makes it possible to test
different services. (In the same spirit of your unit test).

I'll ask him to give all of us an
update during this week and/or at the beginning of next week.

Last message from Maxime (with the spreadsheet attached)
was a proposition to share the effort from missing services.

If you tell us where you are in the IEE-1516 service implementation (done or on-going) we can jump to implement
the un-started ones on our side.

Do you have any updated patch?
Is it going well on your side?

Eric NOULARD <erk>
Project Administrator
Tue 04 May 2010 12:22:29 PM UTC, comment #15:

I have attached table with all IEEE 1516 services.
The goal is to know which service is already implemented and what remains to do.

(file #20423)

BAUDRAIS <mbaudrai>
Thu 29 Apr 2010 09:20:20 PM UTC, comment #14:

2) Compiling CERTI with cygwin hasn't been done since a while
may be you could try with mingw32 + nmake
or even Code::Blocks (http://www.codeblocks.org/) for which
there is a CMake generator target on Windows.
Code::Blocks is shipped with gcc.

see
http://www.nongnu.org/certi/certi_doc/Install/html/build.html
for the generic building

4) OK. And yes good idea to put a separate zip containing
the tests. I may try to put them myself in HLA_TestsSuites.

6) Fine thank you, we'll try to handle/merge those bug fixes
faster for all.

Eric NOULARD <erk>
Project Administrator
Thu 29 Apr 2010 08:19:59 AM UTC, comment #13:

Hello Eric,

Thanks for the feedback.
1) __declspec on Win32 only - I'll keep it in mind. I think we skipped it at first because we were trying to get it to work.

2) throw declarations should match - Good call on that. Unfortunatly VS doesn't warn us about that. I'll see if I can easily get GCC to compile it under Cygwin. At least for the warnings...

3) Add messagetypes/enums at end - I can see how that's required for backwards compatibility. I'll do that from now on.

4) Move tests to HLA_TestSuite - For now I think I'll keep them in the 'certi' part. If I'd move them to the 'applications/HLA_TestSuite' they would end up in a different VS solution, meaning I would have to open two VS instances... Near the end of development I will definetly move them there.

5) Commit HLA1516 to CVS - Thanks! I hope people have a chance to experiment a bit with it... Perhaps I can add the RTI1516Test as a seperate Zip here so people can take a look at the tests.

6) fixed bugs Interaction publish/subscribe - Yeah, it would have been better to report that as a bug, with a patch for a fix. I have just uploaded a patch for another bug I found... (waitForMessage deadlock on exception). I'll keep doing that for any bugs I may find.

7) Warnings on handles - It seems the derived handles override the base 'operator=' operator. I actually think the base does not need the 'operator='... I'll take a look into it.

8) Double macro definition in RTI1516fedtime.h - I added that part because the VS 'IntelliSense' kept insisting it was defined as import, while it should export. Removing the macro still allowes it to compile, so I'll remove it.

The merge went fine, so we'll continue development today. :)

Jeroen van IJperen <vyperx>
Project MemberIn charge of this item.
Wed 28 Apr 2010 06:56:10 PM UTC, comment #12:

Hi Jeroen,

That's good work, I did partially checkin
your work in the CVS HEAD tree.

Here comes my more detailed remarks.

1) Beware of the fact that
__declspec(dllexport) / __declspec(dllimport)
are only used on windows so the definition
of the corresponding macro should be defaulted
to empty on other platform.

win32 specific part of code should be surrounded
by
#if defined(_WIN32)
blahblah
#else
blohbloh
#endif

2) Beware of the fact that header (.h/.hh)
and body (.c/.cc) should have the very same prototype
including eventual "throw()". I did fix a couple
of those.

3) When adding and/or modifying message classes
and thus modifying the message specification files

CERTI_Message.msg for M_Classes
CERTI_NetworkMessage.msg for NM_Classes

try to add your messages at the end of the file
(but before the native types and the factory)

In the same way, please add the concerned
enum values at the end of Message.hh::enum Type
and NetworkMessage.hh::enum Type

This way you'll avoid to make old enum values move
around.

In fact this is not currently "mandatory" but it will
soon be if we want to try to maintain compatibility between
CERTI versions.

So please put new messages at the end unless you have to
do it otherwise.

4) Concerning the RTI1516tests your initiative is very good
and I invite you to continue along this path.

However I'd rather put those tests inside HLA_TestSuites
source module and not in CERTI source module.
The main idea here is that those test may well be RTI-agnostic
(they are just HLA federates)
and building such open source RTI independent test suite
would be nice.

Moreover there is inside HLA_TestSuites some python helper
scripts which makes it possible to run the whole test suite
with a single make test
(for each test RTIG is killed/launched appropriately and
the federates (1 or more) launched too, then the output
ot the test is monitored for OK <-> NOK etc...)
More on this later.

5) After some Linux compile fix I did run usual and current CERTI HLA 1.3
regression tests suite (HLA_TestsSuite, HLA_Tutorial and billard)
since they are OK,
I did commit your change with needed fix for a Linux
compile.
This way it would be easier for other
including Maxime to follow (and participate) to the work.

However I did not checked-in the RTI1516tests.

6) I've seen you have fixed bugs concerning
publish/subscribe to interaction in RTIG_Processing.cc
this is fine off course. But when you do that please
try to file a separate bug report and a separate
patch. This makes it easier to track bug and associated bug fixes.

7) There remains weird compile warnings like:

/home/eric/workspace/certi-integration/libRTI/RTI1516HandleImplementation.h:41: warning: ‘virtual rti1516::HandleImplementation& rti1516::HandleImplementation::operator=(const rti1516::HandleImplementation&)’ was hidden
/home/eric/workspace/certi-integration/libRTI/RTI1516HandleImplementation.h:103: warning: by ‘rti1516::FederateHandleImplementation& rti1516::FederateHandleImplementation::operator=(const rti1516::FederateHandleImplementation&)’

and I did add a // FIXME Eric-->Jeroen in RTI1516fedtime.h

but we will fix those gradually. I'd rather check-in gradually
in order to ease testings and patch proposal from others.

I invite you to update (carefully as usual in order not to loose
local modifications) and retry a WIN32 compilation (I did not tried myself).

Again that's good work.

Eric NOULARD <erk>
Project Administrator
Wed 28 Apr 2010 05:09:55 PM UTC, comment #11:

Ok thanks,

Currently testing on Linux.

Eric NOULARD <erk>
Project Administrator
Wed 28 Apr 2010 12:42:27 PM UTC, comment #10:

I've attached a new version of the HLA1516 development... Actually, some test are now broken, but I guess that shows that we're still working on it. :)

We've only done compilation under Visual Studio (2005 & 2008), so please let us know if things aren't working under Linux (and how we can fix them :) )

(file #20358)

Jeroen van IJperen <vyperx>
Project MemberIn charge of this item.
Tue 27 Apr 2010 07:35:23 AM UTC, comment #9:

Hello Eric,

Glad to see you're back. :)
I will commit a new version for you tomorrow.

So far, things are progressing quite well, with a lot of the services ported directly to HLA1516...

I've also been working on a unit test system, which already identified some issues in the RTIA/RTIG code... So far, the unit tests still require manual handling, but I'm certain it could be adapted to be automatic, making it more useful in general.

Jeroen van IJperen <vyperx>
Project MemberIn charge of this item.
Tue 27 Apr 2010 07:28:38 AM UTC, comment #8:

Hi Jeroen,

I'm back now :-)
May be you have an updated contribution I may try to
review/merge.

I've fast-tried HLA1516-2010-04-13.zip on Linux and got some
compile error, however I'd better do the work on up-to-date
contrib from you in order to minimize the merge
on your side after my first commit.

Eric NOULARD <erk>
Project Administrator
Thu 15 Apr 2010 01:19:23 PM UTC, comment #7:

Thanks for keeping us informed, Eric. :)

Things are going quite well here. Services are being implemented, and I have started working on some unit tests. So far only found bugs in the rtia/rtig, so I guess that's good. :)

Enjoy your trip, and we'll see where we stand in a week.

Jeroen van IJperen <vyperx>
Project MemberIn charge of this item.
Thu 15 Apr 2010 07:12:19 AM UTC, comment #6:

Hi Jeroen,

I won't be very responsive for 7/8 days because I'm travelling
and I do not always have efficient net access.
May be Pierre will get in touch with you and or I will
for sure when I'm back online.

Eric NOULARD <erk>
Project Administrator
Mon 12 Apr 2010 11:17:43 AM UTC, comment #5:

Hi Eric,

I'd be happy to have some (more) help. :) Let me know if/when he needs any info.

I've uploaded a new patch of my work so far. Unfortunatly I have had to make a 'branch' of some of the HLA1516 header files, in order to get the project compiling under Visual Studio. I've renamed them with a 'certi' prefix, and added an explanation in the file. Still trying to figure out a better way to solve this though.

Right now I'll start working on CERTI being able to parse HLA1516 FOM files. My collegue in the mean time will work on implementing the rti1516::handles and porting the various services.

Jeroen van IJperen <vyperx>
Project MemberIn charge of this item.
Wed 07 Apr 2010 12:53:03 PM UTC, comment #4:

Hi Jeroen,

We (Pierre and myself)
now have a student here which will help in this task too.
He will be working on Linux such that you may be reliefed
from this task.

He is currently beginning to learn HLA with CERTI
and then will coordinate with you in order to
do appriate complementary work.

Eric NOULARD <erk>
Project Administrator
Mon 22 Mar 2010 04:57:00 PM UTC, comment #3:

Hi Jeroen,

Here is a first feedback on your work.

1) I think you don't have to modify
include/RTI.hh
Unless I'm wrong
the appropriate include for 1516 is: include/RTI/RTI1516.h
and you should probably make CERTI specific
modifications inside
include/RTI/SpecificConfig.h

2) I don't think we need separate RTIA for 1.3 and 1516
the same RTIA should be able to handle both because
RTIA is only processing internal CERTI messages.

There may be 1516/1.3 specific messages but I think
we should try to keep RTIA unique. It will be far easier
to maintain.

3) libRTI1516
Following the same idea I'll put 1516 and 1.3 files in the
same libRTI directory.

In fact you can modify the existing libRTI/CMakeLists.txt
in order to compile libRTI1516 using same
files as 1.3 (if they can be kept common 1516 - 1.3) or
a separate new file (as you already did).
i.e there may be
RTI_LIB_SRCS RTI_LIB_INCLUDE
RTI13_LIB_SRCS RTI13_LIB_INCLUDE
RTI1516_LIB_SRCS RTI1516_LIB_INCLUDE

and then
ADD_LIBRARY(RTI ${RTI_LIB_SRCS} ${RTI_LIB_INCLUDE} ${RTI13_LIB_SRCS} ${RTI13_LIB_INCLUDE})

ADD_LIBRARY(RTI1516 ${RTI_LIB_SRCS} ${RTI_LIB_INCLUDE} ${RTI1516_LIB_SRCS} ${RTI1516_LIB_INCLUDE})

I think you get the idea.

4) Please keep the same naming convention for file extension

C++ header = .hh
C++ body = .cc

5) I did merge-in your modifications of certi.hh

Eric NOULARD <erk>
Project Administrator
Mon 22 Mar 2010 09:26:58 AM UTC, comment #2:

I needed your Savannah account :-)
Now I have it so it's done.

As said on the ML, please attach some patches here
in order to ease the incremental integration of your work.

Thank you for contributing to CERTI

Eric NOULARD <erk>
Project Administrator
Mon 22 Mar 2010 09:09:24 AM UTC, comment #1:

Hi Eric,

As indicated on the mailing list, I have taken up this task. Can you assign it to me here? Thanks.

Kind regards,

Jeroen v. IJperen (vyperx)
TASK24

Jeroen van IJperen <vyperx>
Project MemberIn charge of this item.
Mon 22 Mar 2010 08:13:42 AM UTC, original submission:

Many people want to use 1516 API instead of 1.3.
What we can do is to at least implement the same
services we have in 1.3 in 1516.

May be more than taht afterwards...

Eric NOULARD <erk>
Project Administrator

 

Attached Files
file #20661:  task10290-erk-jeroen4-1516only.patch added by erk (56kB - text/x-diff - Latest patch including 1516 only modif (this one has been checked-in CVS HEAD))
file #20654:  task10290-erk-jeroen4.patch added by erk (86kB - text/x-diff - Updated patch since previous one includes a separate bug fix now checked-in)
file #20652:  task10290-erk-jeroen3.patch added by erk (87kB - text/x-diff)
file #20635:  tab2.ods added by vyperx (17kB - application/vnd.oasis.opendocument.spreadsheet)
file #20636:  HLA1516-2010-05-27.zip added by vyperx (247kB - application/octet-stream)
file #20423:  tab implementation.ods added by mbaudrai (18kB - application/vnd.oasis.opendocument.spreadsheet)
file #20358:  HLA1516-2010-04-28.zip added by vyperx (181kB - application/octet-stream)
file #20203:  HLA1516-2010-04-13.zip added by vyperx (72kB - application/octet-stream - Updated patch. Waiting for my collegue before replacing extensions.)
file #20003:  HLA1516-2010-03-22.zip added by vyperx (127kB - application/octet-stream - Patch/content so far. Approach is to copy existing RTI(A) and replace with 1516 functionality.)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -unavailable- added by mbaudrai (Updated the item)
  • -unavailable- added by erk (Will help on this task too)
  • -unavailable- added by erk (Pour suivre l'implem' de la 1516)
  • -unavailable- added by vyperx (Posted a comment)
  • -unavailable- added by erk (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 19 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 11 Nov 2010 11:17:24 AM UTCerkStatusIn Progress=>Done
      Percent Complete70%=>100%
      Open/ClosedOpen=>Closed
      Planned ReleaseUnplannedRelease=>CERTI 3.4.0
    Mon 31 May 2010 09:38:14 AM UTCerkAttached File-=>Added task10290-erk-jeroen4-1516only.patch, #20661
      Percent Complete60%=>70%
    Sun 30 May 2010 05:48:15 PM UTCerkAttached File-=>Added task10290-erk-jeroen4.patch, #20654
    Sat 29 May 2010 09:27:30 PM UTCerkAttached File-=>Added task10290-erk-jeroen3.patch, #20652
    Thu 27 May 2010 12:23:36 PM UTCerkPercent Complete0%=>60%
    Thu 27 May 2010 11:54:42 AM UTCvyperxAttached File-=>Added tab2.ods, #20635
      Attached File-=>Added HLA1516-2010-05-27.zip, #20636
    Tue 04 May 2010 12:22:29 PM UTCmbaudraiAttached File-=>Added tab implementation.ods, #20423
    Wed 28 Apr 2010 12:42:27 PM UTCvyperxAttached File-=>Added HLA1516-2010-04-28.zip, #20358
    Mon 12 Apr 2010 11:11:28 AM UTCvyperxAttached File-=>Added HLA1516-2010-04-13.zip, #20203
    Wed 07 Apr 2010 12:53:03 PM UTCerkCarbon-Copy-=>Added mbaudrai
    Mon 22 Mar 2010 01:22:42 PM UTCvyperxAttached File-=>Added HLA1516-2010-03-22.zip, #20003
    Mon 22 Mar 2010 09:26:58 AM UTCerkStatusNone=>In Progress
      Assigned toNone=>vyperx
      Carbon-Copy-=>Added siron

    Back to the top


    Powered by Savane 3.1-cleanup