State machine controller should function as a ScopeExtendingAttribute

[cxbrooks]

Note: the issue was created automatically with bugzilla2github tool

Original bug ID: BZ#192 From: Bert Rodiers <bert.rodiers@gmail.com> Reported version: 7.1.devel CC: @cxbrooks, pt-dev@chess.eecs.berkeley.edu

[cxbrooks]

The state machine controller should function as a ScopeExtendingAttribute, with its attributes visible one level up. This way, they will be in scope for refinements. Did Thomas fix this?

(From Edward's bug list)

[cxbrooks]

Edward says:

This one may have been solved by Thomas... I recall seeing email about this...

Ok, I'm closing this one.

http://chess.eecs.berkeley.edu/ptolemy/listinfo/ptolemy/2008-May/010672.html from Thomas says:

Hi Christopher,

This is fixed.

Christopher Brooks wrote:

Hi Thomas,

Your April 8, 2008 changes mean that ptolemy.data.expr now requires the FSM domain.

Your comment for this change was: Miscellaneous bugfixes on the scoping of ERG and FSM actors.

data/expr/ModelScope.java imports these classes: import ptolemy.domains.fsm.kernel.State; import ptolemy.domains.fsm.modal.ModalController;

ParseTreeEvaluator.java imports: import ptolemy.domains.fsm.kernel.State;

ParseTreeTypeInference.java imports: import ptolemy.domains.fsm.kernel.State;

Can you make it a priority to refactor this code so that it does not import these domain specific classes?

Perhaps the right thing would be to create an interface at that appropriate place and have State implement that interface. It would be best to not use reflection, instead design something using class system instead of working around it.

Kepler/Core is interested in having clean extension points in the Ptolemy code. Having data/expr depend on fsm breaks our modularity system. I'm working on possible refactorings of our code to make it easier for Kepler to use our packages.

_Christopher

Edwdard writes:

One possibility is that the FSM controller could function like
a ScopeExtendingAttribute.  This will require, probably, extending
the mechanism of ScopeExtendingAttribute so that an Entity can be
one rather than just an Attribute.... But the extension should be
small...

Edward

At 11:03 PM 4/14/2008, Thomas Huining Feng wrote:
>Hi Christopher,
>
>Sorry that I forgot to remove unused imports from ERG.
>
>For FSM, I don't know what's the best way to allow an expression in a >     >refinement to refer to a parameter in the FSM controller.
>In the model structure the refinement is another FSMActor in the modal model,
>so structurally it is a sibling of the FSM controller. However, from the
>user point of view, there is a containment relationship between them. So I
>had to do something special to handle refinements in the expression language.
> The same change affects ERG as well, because ERG subclasses FSM.
>
>I wondered why we decided to have refinements as siblings of the FSM
> controller. It may be more convenient for the FSMDirector, but we
> are paying the price of more complication in other parts.
>
>Christopher Brooks wrote:
>>Hi Thomas,
>>Thanks, that fixed that problem.
>>Now the problem is that Kepler fails to build because 
>>ptolemy.data.expr depends on ptolemy.domains.erg and domains.fsm
>>I removed the dependendency on domains.erg.
>>Nothing in data should depend on the domains, this really breaks
>>modularity and means that Kepler would require those domains.
>>_Christopher

The ChangeLog says: 2008-05-21 tfeng

  Add interface ContainmentExtender to data/expr, and make State, ModalController and Refinement in the FSM domain to implement it, so that ptolemy.data.expr package no longer depends on FSM.

[cxbrooks]

I'm reopening this.

Thomas wrote:

I fixed this partially.

In an expression in the refinement, we can refer to parameters outside. Namely, > those belonging to the FSM controller that contains the state that the refinement refines. From the FSM controller, we can also refer to the parameters in the refinement (by using state_name + "." + parameter_name).

However, we can't refer to those names on the left-hand side of an assignment in the set actions. The reason is that FSM actor searches for those names in a way different from the name resolution in an expression. I fixed this problem in ERG and I will fix it in FSM as well.

[cxbrooks]

Thomas wrote:

I fixed this partially.

In an expression in the refinement, we can refer to parameters outside. Namely, > those belonging to the FSM controller that contains the state that the refinement refines. From the FSM controller, we can also refer to the parameters in the refinement (by using state_name + "." + parameter_name).

However, we can't refer to those names on the left-hand side of an assignment in the set actions. The reason is that FSM actor searches for those names in a way different from the name resolution in an expression.

Maybe something similar: You can also add parameters to the state directly (so not to the refinement), however I can't use these parameters. Both when I use them in the guard as in the set-actions of a transition I get the error message that the ID can not be resolved.

[cxbrooks]

I wrote

Maybe something similar: You can also add parameters to the state directly (so not to the refinement), however I can't use these parameters. Both when I use them in the guard as in the set-actions of a transition I get the error message that the ID can not be resolved.

This will give problems with the name scopes of the parameters since the refinement is directly accessible from within the scope of the modal model. An example: Suppose we have a modal model with one state, called State. State has a refinement called State and this one has a parameter called test. The current implementation allows to access the parameter test in the refinement State in a transition as State.test. We can also add the same parameter test to the state State, but how in earth can you make the difference between both. Will State.test be the one in the refinement or the one in the state?

I was wondering why the refinement is directly assessable from within the modal model. If you would only define them with the scope of a state you would not end up with this ambiguity and this would allow to reuse the same name for refinements in different states. In this case State.State.test would be the parameter within the refinement and State.test the one within the state. In this case however it's better to not allow to have parameters in a state and refinements of that same state to have the same name, since this also leads to name clashes...

[cxbrooks]

I fixed this one in FSMActor.PortScope. It now uses ModelScope.getScopedObject() to resolve a name if it is not recognized by the previous name resolution method. ModelScope.getScopedObject() (a static method) looks up the name given a container (which is the FSMActor in this case). It searches conceptual containers of the FSMActor (i.e., the FSMActor that contains it), as well as refinements of states contained in the FSMActor.

For example, if we have this model hierarchy:

A : FSMActor s1 : State B : FSMActor s2 : State C : FSMActor p : Parameter s3 : State

then within B, expression "s1" evaulates to the state s1 (in an ObjectToken), and "s2.p" refers to p in the refinement (C) of s2.

This is done with the ptolemy.domains.fsm.kernel.ContainmentExtender attribute, not ScopeExtendingAttribute.

Note: I think we decided to make all refinements (regardless of their levels) children of the modal model because that saves us work in the model execution process. For example, the initialize() method invoked on the modal model automatically invokes initialize() of all the refinements. Furthermore, because a state is not a CompositeEntity, technically it is impossible to define any children for it that is ComponentEntity. As a workaround, we make the refinements children of the modal model.

I also think that we are paying a high price for this workaround.

1) Expression evaluation doesn't work immediately because the scoping isn't right. I make it work now, with an extra mechanism called ContainmentExtender.

2) Copying and pasting a state with refinement lead to dangerous result. (If the state is pasted to a different FSMActor, then it won't have refinement any more. If it is pasted to the same FSMActor, then it has the SAME refinement as the copied state's, so changes on the refinement is visible in both states.)

3) The order in which the preinitialize(), initialize(), fire(), postfire(), wrapup() methods of the refinements are called is arbitrary. That order is usually the same as the order in which those refinements are created (regardless of their depth), but if copy and paste are done, then they may not be the same any more.

I may be able to name some other disadvantages. They aren't easy to fix unless we change the refinement structure.

I'm closing the bug for expression evaluation in state machines.

[cxbrooks]

Is there a test case that illustrates this bug? There probably should be, it is fairly complex.

Also, this test in fsm/kernel fails:

==== Transition-3.1 test scope of guard and trigger expressions ==== Contents of test case:

set e0 [java::new ptolemy.actor.TypedCompositeActor]
set dir [java::new ptolemy.actor.Director $e0 dir]
set fsm [java::new ptolemy.domains.fsm.kernel.FSMActor $e0 fsm]
set s0 [java::new ptolemy.domains.fsm.kernel.State $fsm s0]
set s1 [java::new ptolemy.domains.fsm.kernel.State $fsm s1]
set t0 [java::new ptolemy.domains.fsm.kernel.Transition $fsm t0]
[java::field $s0 outgoingPort] link $t0
[java::field $s1 incomingPort] link $t0
[java::field $fsm initialStateName] setExpression s0
set p0 [java::new ptolemy.actor.TypedIOPort $fsm p0]
$p0 setInput true
set p1 [java::new ptolemy.actor.TypedIOPort $fsm p1]
$p1 setInput true
$p1 setMultiport true
set e2 [java::new ptolemy.actor.TypedAtomicActor $e0 e2]
set p2 [java::new ptolemy.actor.TypedIOPort $e2 p2]
$p2 setMultiport true
set r0 [java::new ptolemy.actor.TypedIORelation $e0 r0]
set r1 [java::new ptolemy.actor.TypedIORelation $e0 r1]
$r1 setWidth 2
$p0 link $r0
$p1 link $r1
$p2 link $r0
$p2 link $r1
$dir preinitialize
set scope1 [[$fsm getPortScope] identifierSet]
list [lsort [listToStrings $scope1]]

==== Result was: {_iconDescription dir e2 finalStateNames fsm initialStateName p0 p0Array p0_0 p0_0Array p0_0_i\ sPresent p0_isPresent p1 p1Array p1_0 p1_0Array p1_0_isPresent p1_1 p1_1Array p1_1_isPresent p\ 1_isPresent r0 r1 s0 s1 stateDependentCausality t0 this} ---- Result should have been: {p0 p0Array p0_0 p0_0Array p0_0_isPresent p0_isPresent p1 p1Array p1_0 p1_0Array p1_0_isPresen\ t p1_1 p1_1Array p1_1_isPresent p1_isPresent stateDependentCausality}

[cxbrooks]

I fixed the test case. identifierSet() of the PortScope now returns more identifiers, including the names of NamedObj's in the model that can be evaluated to ObjectTokens. I will add some test cases soon.