|
Hi Charles,
has the meeting for today been canceled? I'm connected with Asma,
but we seem to be the only ones.
Best regards
Ansgar
On 02/11/2016 15:39, charles+zeligsoft.com wrote:
BTW, you referred to this test as “Barry’s model.”
would that not then make him a “modeler” ;-)
The only downside to having target language self-coded “models" is
that there is no validation of those “pseudo” models to conform to
UML-RT as implemented in Papyrus-RT, past their ability to compile
and run against the RTS. They would also not be portable if (when)
we add other implementation languages.
If we decide continue to have non-modeler developers
create these tests, but they may very well be limited to
checking for regressions during development and could not be
used to express any other quality metric against the whole of
the Papyrus-RT product.
I think that this is also is a good case for using
the textual capability being built to express the runtime tests!
These tests are in the git repo
under plugins/umlrt/runtime, rather than in the actual
model tests, and they are not packaged or deployed.
They are intended exclusively for testing the runtime
"directly", this is, they are not intended to exercise
the generated code, but the runtime itself. Those have
been written by hand by Barry for him to do his own
testing of the runtime, so they do not necessarily
correspond to generated code. They do not have a
model. They are just plain C++.
It might be that it is preferable that
tests have models, but not all developers are
modellers. If a developer works best with code, we
might not be improving the process, by forcing all
tests to be models. I think it makes sense to allow
for some flexibility towards developers who have
their own non-model-based tests and to allow those
developers to push tests into the repo that are not
model-based.
--
Ernesto Posse
Zeligsoft
We
need to review the tests found in
"plugins/umlrt/runtime/tests” to determine which
aren’t runnable or maintainable and, therefore,
need to be removed or updated.
Although it was totally
justified to do this at the time, my take on
this is that we really should be creating tests
by modelling them and not creating them by hand.
Regards,
Charles Rivet
Senior Product Manager, Papyrus-RT
product lead
Begin forwarded
message:
Subject: [Bug
469429] [runtime]
[bmaher/runtime/cygwin] branch -
application crashes after
de-registering SAP port
Date: November 1, 2016 at
15:07:03 EDT
https://bugs.eclipse.org/bugs/show_bug.cgi?id=469429
Product/Component: Papyrus-rt / runtime
Ernesto Posse < eposse@xxxxxxxxx>
changed:
What |Removed
|Added
----------------------------------------------------------------------------
CC|
| eposse@xxxxxxxxx
--- Comment #2 from Ernesto Posse < eposse@xxxxxxxxx>
---
I can't reproduce.
I tested SAPs on Windows 7 with Cygwin,
more precisely the Services model in
the git repo and it works as expected.
I am unable to build Barry's custom
(hand-written) tests under
plugins/umlrt/runtime/tests on Windows,
and there are no instructions on how to
do it, hence, I assume that Barry's
model may be outdated, and I would
suggest
that he looks into it.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are watching the assignee of the
bug.
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
--
Ansgar Radermacher CEA/DRT/DILS/LISE
http://www-list.cea.fr/index.htm
phone: +33 16908 3812
mailto: ansgar.radermacher@xxxxxx
|
