GetProperties.getDispatchProtocol returns null for Aperiodic thread

brlarson commented 5 years ago

Summary

When calling GetProperties.getDispatchProtocol on a ThreadType, null is returned in code written long ago.

Expected and Current Behavior

Return of an EnumerationLiteral is expected, but null received

Steps to Reproduce

  contextToUse = ((ThreadImplementation)contextToUse).getType();
EnumerationLiteral dispatchProtocol = GetProperties.getDispatchProtocol((NamedElement) contextToUse);

Chasing in debugger, GetProperties.getDispatchProtocol calls

GetProperties.lookupPropertyDefinition which calls
Aadl2GlobalScopeUtil.get which calls
IEObjectDescription desc = scope.getSingleElement(qnameConverter.toQualifiedName(qname)); (where qname="Thread_Properties::Dispatch_Protocol") which returns null

thread VVI
  features
    s: in event port;   --a ventricular contraction has been sensed
    p: out event port   --pace ventricle
      {BLESS::Assertion => "<<VP()>>";};
    n: out event port   --non-refractory ventricular sense
      {BLESS::Assertion => "<<(now=0) or VS()>>";};
    lrl: in data port BLESS_Types::Time;  --lower rate limit interval
    vrp: in data port BLESS_Types::Time;  --ventricular refractory period 
  properties
    Dispatch_Protocol => Aperiodic;
    BLESS::Invariant => "<<LRL(now)>>";  
end VVI;

Environment

OSATE Version 2.5.2:
Operating System: MacOS 10.14.6

brlarson commented 5 years ago

Related issue:

Property blessAssertion = GetProperties.lookupPropertyDefinition(p, "BLESS::Assertion");

returns null when p is an EventPort having a BLESS::Assertion property (either port "p" or "n" in VVI above). BLESS::Assertion is defined in BLESS.aadl which is a Plug-in Contribution of BLESS.

This property look-up issue only appears to affect declarative model queries. Hari Thiagarajan's AIR plugin transforms the VVI thread above into JSON for BLESS code generation, and includes both Dispatch_Protocol and BLESS::Assertion properties. Somehow, building the instance model resolves all the proxies.

lwrage commented 5 years ago

I cannot reproduce this. I have created a branch issue_1980_test that adds a test to org.osate.core.test that retrieves the property value from a thread type. Could you run the test, please? Right click on Issue1980Test.xtend and select Run As -> JUnit Plug-in Test

brlarson commented 5 years ago

Lutz,

I ran your test, and it passed. I looked at the .xtend and issue1980.aadl; they test the right thing, in essence.

Yet when I try running again, I get the same thing (null returned from getDispatchProtocol).

So I replaced the body of issue1980.aadl with my thread, renaming "VVI" to "T" and "VVI.i" to "T.i"--and it passes.

So then I changed the names in my model from VVI to T--and it worked!

I changed them back to VVI--and it worked again! I ran the whole proof script, which uses the BLESS::Assertion properties of ports, and it works too!

Why would changing names from VVI to T make any difference?

Gawd I spent lots of time trying to figure it out.

I'm going to pound on it for a couple of days, so don't close the issue quite yet. It's frustrationg to have spent so much time chasing this bug around to have it disappear after changing labels.

--Brian

On Sep 3, 2019, at 11:00 AM, Lutz Wrage notifications@github.com<mailto:notifications@github.com> wrote:

I cannot reproduce this. I have created a branch issue_1980_test that adds a test to org.osate.core.test that retrieves the property value from a thread type. Could you run the test, please? Right click on Issue1980Test.xtend and select Run As -> JUnit Plug-in Test

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/osate/osate2/issues/1980?email_source=notifications&email_token=AAJC32Q743ZWPT35Y4GHPKLQH2CYJA5CNFSM4ISYZXZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5YWAYY#issuecomment-527523939, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAJC32TAKRJOLGSYUXBPFXTQH2CYJANCNFSM4ISYZXZA.

lwrage commented 5 years ago

It looks like something left OSATE in an inconsistent state, maybe you killed a debugging session during a build. Did you ever do a clean build while you had the problem? In weird cases like this it's also a good idea to try a fresh workspace.

brlarson commented 5 years ago

Thanks for the fresh workspace idea. I don't know if I killed it during build. I know that I refreshed, and completely re-built several times.

On Sep 4, 2019, at 2:56 PM, Lutz Wrage notifications@github.com<mailto:notifications@github.com> wrote:

It looks like something left OSATE in an inconsistent state, maybe you killed a debugging session during a build. Did you ever do a clean build while you had the problem? In weird cases like this it's also a good idea to try a fresh workspace.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/osate/osate2/issues/1980?email_source=notifications&email_token=AAJC32SZNRQPKF4CZ7CTVCDQIAHHNA5CNFSM4ISYZXZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD54Y5DQ#issuecomment-528060046, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAJC32V77AQKX3ZKRGFZXBDQIAHHNANCNFSM4ISYZXZA.

osate / osate2