(
Jump to the original submission)
Tue 28 Oct 2008 09:40:19 PM UTC, comment #7:
Currently I'd feel more comfortable with the A) option, supposing it will be integrated into the overall CERTI dashboard.
The test case for this bug is already in CVS.
BTW: Have you already officially launched the CERTI dashboard?
|
Tue 28 Oct 2008 07:17:13 PM UTC, comment #6:
100% python test case is fine.
You may either:
A) write your python tests within PyHLA
B) write your python tests in HLA_TestsSuite
I would rather have all HLA/RTI tests in
HLA_TestsSuite, be it in Python, C++, Java ...
Such that running the testsuite would give us
the broader test coverage regarding HLA compliance.
We could just add some CMake scripts to the
current HLA_TestsTools in order to handle the
Python case.
The A) option is fine too, do it as you like.
Submission to the HLA_TestsSuite Dashboard in either case
is welcomed.
|
Tue 28 Oct 2008 05:34:46 PM UTC, comment #5:
Eric, this bug was found during my PyHLA development activity, so the test-case is completely in Python. :-) I was just about asking a question:
What would you say if I (somehow, somewhere) build a Python test sub-suite? The CDash/CTest should be able to integrate both into one dashboard. There are two reasons why I'd like to try making some tests in Python
- such test verifies both CERTI and the PyHLA wrappers
- writing tests in Python is a bit easier
|
Tue 28 Oct 2008 04:40:11 PM UTC, comment #4:
Here comes a link to the list archive as a reminder:
http://lists.nongnu.org/archive/html/certi-devel/2008-10/msg00025.html
Petr did you by any chance developped a test case
for validating that bug or is the test "design only"?
If you developped a test in order to check if the API
is working well would you be kind enough to add it
to HLA_TestsSuite?
|
Tue 28 Oct 2008 12:11:23 PM UTC, comment #3:
Done (as discussed via certi-dev).
|
Fri 10 Oct 2008 01:00:32 PM UTC, comment #2:
Pierre,
Could you have a look at that with Petr?
|
Fri 10 Oct 2008 12:51:29 PM UTC, comment #1:
There is one more problem related to this: Message.hh contains two functions
getOrdering() that returns RTI::OrderingHandle, which is 1 if "order" is RECEIVE, and 0 otherwise
getOrderType() that directly returns "order" as RTI::OrderType
Isn't one of them deprecated as well? Moreover, I think that the getOrdering is wrong. The RTI::OrderingHandle is not a binary value, it's the same as RTI::OrderType.
|
Fri 10 Oct 2008 12:22:39 PM UTC, original submission:
certi.hh contains several "deprecated HLA exceptions", some of them (at least InvalidOrderType and InvalidTransportType) overlap with standard exception names.
The throw/catch mechanism is inconsistently using both names.
What shall we do?
(a) remove the deprecated InvalidOrderType and InvalidTransportType and throw/catch standard only (my preference),
(b) keep catching both, but throw standard only (does not prevent the inconsistency to occur again)
(c) no change, or something else?
|
(Note: upload size limit is set to 16384 kB, after insertion of the required
escape characters.)
Attach File(s):
Comment:
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Follow 4 latest changes.