[msm]how to distinguish region ids?
Hello, On Boost.Msm 1.46.1, When I use explicit entries and entry pseudo states, I have to provide a template argument "region id". http://www.boost.org/doc/libs/1_46_1/libs/msm/doc/HTML/ch03s02.html#d0e930 But I couldn't find documents about numbering policy of region id. I also check the example below. http://www.boost.org/doc/libs/1_46_1/libs/msm/doc/HTML/examples/DirectEntryT... The example passes the region id 0 and 1. I'd like to know how to decide which region is 0(or1). Am I missing something? Thanks, Takatoshi
Hello,
On Boost.Msm 1.46.1, When I use explicit entries and entry pseudo states, I have to provide a template argument "region id". http://www.boost.org/doc/libs/1_46_1/libs/msm/doc/HTML/ch03s02.html#d0e930
But I couldn't find documents about numbering policy of region id. I also check the example below. http://www.boost.org/doc/libs/1_46_1/libs/msm/doc/HTML/examples/DirectEntryT... The example passes the region id 0 and 1. I'd like to know how to decide which region is 0(or1).
Am I missing something?
Thanks, Takatoshi
Hi, The region ids are numbered in the order of the initial_state typedef: typedef boost::mpl::vector<Start1,Start2> initial_state; Start1 will be the initial state of the first region (id 0), Start2 the initial state of the second region (id 1). Alternatively, you can omit the id and let MSM build a graph using mpl_graph and find this out for you (which will work if your pseudo entry is somehow connected to the initial state). Please note however that there is a compile-time cost for this. HTH, Christophe
Hi, Christohe Thanks for quick reply. On Tue, 21 Jun 2011 21:09:20 +0200 "Christophe Henry" <christophe.j.henry@googlemail.com> wrote:
Hello,
On Boost.Msm 1.46.1, When I use explicit entries and entry pseudo states, I have to provide a template argument "region id". http://www.boost.org/doc/libs/1_46_1/libs/msm/doc/HTML/ch03s02.html#d0e930
But I couldn't find documents about numbering policy of region id. I also check the example below. http://www.boost.org/doc/libs/1_46_1/libs/msm/doc/HTML/examples/DirectEntryT... The example passes the region id 0 and 1. I'd like to know how to decide which region is 0(or1).
Am I missing something?
Thanks, Takatoshi
Hi,
The region ids are numbered in the order of the initial_state typedef:
typedef boost::mpl::vector<Start1,Start2> initial_state;
Start1 will be the initial state of the first region (id 0), Start2 the initial state of the second region (id 1).
Thanks, I understand. I believe if I pass the out of range value then compile error should occur. And I tested. 0 and 1 are OK. (expected) -1 is NG. (expected) But 2 is OK. (unexpected) 3 or more is NG. (expected) I'm not expert of msm's implementation. I suspect that state_machine.hpp:(2256) BOOST_STATIC_ASSERT(find_region_id<typename StateType::wrapped_entry>::region_index <= nr_regions::value); should be BOOST_STATIC_ASSERT(find_region_id<typename StateType::wrapped_entry>::region_index < nr_regions::value);
Alternatively, you can omit the id and let MSM build a graph using mpl_graph and find this out for you (which will work if your pseudo entry is somehow connected to the initial state). Please note however that there is a compile-time cost for this.
Great!! This is the function that I really want to.
HTH, Christophe
P.S.We met BoosoCon2010, how are you? Regards, Takatoshi
The region ids are numbered in the order of the initial_state typedef:
typedef boost::mpl::vector<Start1,Start2> initial_state;
Start1 will be the initial state of the first region (id 0), Start2 the initial state of the second region (id 1).
Thanks, I understand. I believe if I pass the out of range value then compile error should occur. And I tested. 0 and 1 are OK. (expected) -1 is NG. (expected) But 2 is OK. (unexpected) 3 or more is NG. (expected)
I'm not expert of msm's implementation.
I suspect that
state_machine.hpp:(2256) BOOST_STATIC_ASSERT(find_region_id<typename StateType::wrapped_entry>::region_index <= nr_regions::value);
should be
BOOST_STATIC_ASSERT(find_region_id<typename StateType::wrapped_entry>::region_index < nr_regions::value);
Hi Takatoshi, Clearly you're right and it's a beginner's mistake. Thanks, I'll fix this immediately.
Alternatively, you can omit the id and let MSM build a graph using mpl_graph and find this out for you (which will work if your pseudo entry is somehow connected to the initial state). Please note however that there is a compile-time cost for this.
Great!! This is the function that I really want to.
Good :) You're probably one of the first to use this new feature so your experience with it will be very useful. Please let me know how it went.
P.S.We met BoosoCon2010, how are you?
I remember. We spoke at the end of the talk, right? I'm doing great, thanks :) I remember you required some feature but I forgot what it was. Was it this automatic region id calculation of pseudo entry state? Christophe
Hi, Christophe
I remember. We spoke at the end of the talk, right? I'm doing great, thanks :) I remember you required some feature but I forgot what it was. Was it this automatic region id calculation of pseudo entry state?
No, My request is junction pseudo state. Here is a exsample model. E1[G1]/A1 [G4]/A4 S1------------+ +--------->S4 E2[G2]/A2 V | [G5]/A5 S2----------->J-+--------->S5 E3[G3]/A3 A | [G6]/A6 S3------------+ +--------->S6 If we can use the junction pseudo state, we write only 6 transitions in the code. I know the transition below is equivalent. E1 [G1 && G4] / A1;A4 S1 ----------------------->S4 E1 [G1 && G2] / A1;A5 S1 ----------------------->S5 ... But we have to write 9 transitions. The difference is 3+3 or 3*3. This is my request. And I also requested the choice pseudo state. But you didn't like this semantics. And I agreed. We can use the (normal) state with guard only (event-less) transition instead of the choice pseudo state. So I cancelled the my request. BTW, I'm trying to write the guideline for UML modelers. In the guideline, the relation between the UML element and the msm element will be described. And it will be also described how to use the msm better. I will show it to you when completing it. Thanks, Takatoshi On Wed, 22 Jun 2011 19:37:05 +0200 "Christophe Henry" <christophe.j.henry@googlemail.com> wrote:
The region ids are numbered in the order of the initial_state typedef:
typedef boost::mpl::vector<Start1,Start2> initial_state;
Start1 will be the initial state of the first region (id 0), Start2 the initial state of the second region (id 1).
Thanks, I understand. I believe if I pass the out of range value then compile error should occur. And I tested. 0 and 1 are OK. (expected) -1 is NG. (expected) But 2 is OK. (unexpected) 3 or more is NG. (expected)
I'm not expert of msm's implementation.
I suspect that
state_machine.hpp:(2256) BOOST_STATIC_ASSERT(find_region_id<typename StateType::wrapped_entry>::region_index <= nr_regions::value);
should be
BOOST_STATIC_ASSERT(find_region_id<typename StateType::wrapped_entry>::region_index < nr_regions::value);
Hi Takatoshi,
Clearly you're right and it's a beginner's mistake. Thanks, I'll fix this immediately.
Alternatively, you can omit the id and let MSM build a graph using mpl_graph and find this out for you (which will work if your pseudo entry is somehow connected to the initial state). Please note however that there is a compile-time cost for this.
Great!! This is the function that I really want to.
Good :) You're probably one of the first to use this new feature so your experience with it will be very useful. Please let me know how it went.
P.S.We met BoosoCon2010, how are you?
I remember. We spoke at the end of the talk, right? I'm doing great, thanks :) I remember you required some feature but I forgot what it was. Was it this automatic region id calculation of pseudo entry state?
Christophe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
No, My request is junction pseudo state. Here is a exsample model.
E1[G1]/A1 [G4]/A4 S1------------+ +--------->S4 E2[G2]/A2 V | [G5]/A5 S2----------->J-+--------->S5 E3[G3]/A3 A | [G6]/A6 S3------------+ +--------->S6
If we can use the junction pseudo state, we write only 6 transitions in the code. I know the transition below is equivalent.
E1 [G1 && G4] / A1;A4 S1 ----------------------->S4
E1 [G1 && G2] / A1;A5 S1 ----------------------->S5
...
But we have to write 9 transitions. The difference is 3+3 or 3*3.
This is my request.
Ah yes I remember now. Yes, it clearly means less transitions. The cost of it is the extra complexity added by the following case: If we are in S1 and G1 is true and A1 will cause G4 to become true, do we switch to S4? Answer no, because the guards are evaluated prior to any action. Yes it makes sense, but there is a risk of mistakes and these are hard to spot. However, it still makes a welcome addition for power users so msm should support it. I still have a few big features to pack but this one is clearly on my radar and I'll give it a try someday (though to be frank, I still have no idea of how to implement it ;-) )
And I also requested the choice pseudo state. But you didn't like this semantics. And I agreed. We can use the (normal) state with guard only (event-less) transition instead of the choice pseudo state. So I cancelled the my request.
Yes I think this feature adds not much to the party and is dangerous (as noted in "Real Time UML"). If you move to the choice pseudo state and all outgoing guards are false, you are in an undefined state and I'm not a fan of undefined behaviour.
BTW, I'm trying to write the guideline for UML modelers. In the guideline, the relation between the UML element and the msm element will be described. And it will be also described how to use the msm better.
I will show it to you when completing it.
Oh yes please, it will probably be very interesting! Specifically, I'm interested in an outside view of the points where msm does not follow the standard. Usually it is wanted that way, but I might have missed some subleties. Christophe
participants (2)
-
Christophe Henry -
Takatoshi Kondo