- Boost - lists.boost.org

Re: [boost] [msm] eUML guard/action location
by Christophe Henry 08 Dec '09

08 Dec '09

Hi Michael, >Ok... I looked up MSM's anonymous transitions again and >now I don't like it (o; It's probably because we don't talk about the same concept. And it's not an MSM concept. Sorry, I can't claim ownership for it ;-) Anonymous transitions are also called completion events in the standard (and both names are used in the excellent "Real-Time UML, 3rd Edition"). They are defined as a transition without explicit trigger and are generated after the entry actions. You can have a look at the tutorials to see how it is used. >Christophe ... as far as I can tell by looking at the docs, >the MSM use of anonymous transitions transforms the source >state to *almost* be a UML choice pseudo state I disagree with this. The state itself is not concerned, it is only a state machine thing. If you reuse the same state in another context, it will not behave like a choice point. But in this special state machine context, yes, it behaves the same, which is why I didn't implement choice points yet. Now you see what I meant ;-) I was at first not convinced by this feature until I saw a project in a big automotive company making extensive use of it. At every processor time slice, they'd go through the whole fsm used in this context as an algorithm. They could this way easily estimate the time slice they needed. What you are talking about is a trigger, which has to be fired, whatever it is. I didn't find it in the standard, but I could have missed that too. And no, MSM doesn't support it for the moment. The reason is that it's not on my radar as I'm pretty unconvinced of its need. I have yet to see a good convincing use case for it. Now, I don't say it won't be done, but it's not high on my list, unless someone makes a convincing case for it. Its implementation might be not trivial though. Christophe

2 1

Re: [boost] [msm] Review
by Christophe Henry 08 Dec '09

08 Dec '09

Hi, >eUML makes up *~75%* of Msm's code and ~30% of Msm's documentation; metrically, >it's obviously an extremely significant part of Msm, and is probably what >warranted a major version increment between Msm versions 1.2 and 2.0. Correct. Although it is not the only reason, there is also a big redesign with division in front- and back-ends and riddance of the CRTP. Adam Merz wrote: >I could be way off here, but my impression from the Msm documentation >is that the standard frontend exists mostly for backwards compatibility >with 1.x code and to support older compilers, and that > eUML is the recommended frontend for new FSMs on supported compilers David Bergman wrote: >That was not my impression. My impression was that the (old) standard interface >was the canonical one, and eUML an "option" for developers. MSM has no favorite interface, but a choice of interfaces which it tries to support equally well. But it's true that eUML is my personal favorite way and the source of a great amount of fun. I personally thought (or say hoped) that it'd become the new way of writing state machines, but I came into this review without an idea of how it would be welcome. From what I saw for reactions until now, I'm pretty confident eUML will meet this goal at some point. >I would welcome eUML into Boost any day, from what I have seen (especially after playing with it this morning.) Great! >Do we really need a new underlying library for eUML, though? I am not sure of that. You don't get a new library for eUML but eUML for a new library. It's clearly not the same. >And even if we do (for now), and cherish the much faster execution speeds of MSM >(in my non-complex but pretty big state machine examples), I don't get what is the problem. You get a backend with impressive performance which was built with the goal to allow expressive, declarative and concise front-ends with great UML support and lots of work done under the hood which you can't even imagine. Without it, there would be no interface and no eUML. Why not have it? I thought that Boost was standing for state-of-the-art C++ coding and was happy to get any great library coming, no matter which library is already part of it. Don't we all agree on that? >I would argue for an attempt at having eUML as an optional facade for both MSM and Statechart. For this you'd need some important amount of change in Statechart, for which I cannot do anything. eUML being a representation of the underlying MSM philosophy, I doubt that you will have it. Let me get it straight. The biggest value of MSM is not the front-end, not even eUML, no matter how cool it is. It is the back-end. Actually it's the philosophy behind the back-end. Christophe

4 5

[ratio] metafunction ratio_subtract
by vicente.botet 07 Dec '09

07 Dec '09

Hi Beman, Hi Howard, With current implementation of the metafunction ratio_subtract I get the type from the test ratio_test.cpp User1::Distance d( User1::mile(110) ); User1::Time t( boost::chrono::hours(2) ); typeof (d/t) is User1::quantity<boost::ratio<1,-1>, boost::ratio<1,1> > So the following assignation do not works User1::Speed s = d / t; as User1::Speed is defined as typedef quantity<boost::ratio<1>, boost::ratio<0> > Time; // second typedef quantity<boost::ratio<0>, boost::ratio<1> > Distance; // meter typedef quantity<boost::ratio<-1>, boost::ratio<1> > Speed; // meter/second The code is a little bit triky, and I have not taken the time to understand why the resulting type is User1::quantity<boost::ratio<1,-1>, boost::ratio<1,1> > and not <boost::ratio<-1,1>, boost::ratio<1,1> > User1::quantity I have replaced the type by typedef ratio<R1::num * R2::den - R2::num * R1::den,R1::den * R2::den> aux_type; typedef ratio<aux_type::num ,aux_type::den > type; // get normalized type to follow the recommendation "The nested typedef type shall be a synonym for ratio<T1, T2> where T1 has the value R1::num *R2::den - R2::num * R1::den and T2 has the value R1::den * R2::den." and every thing is OK (See below the replaced code) I'm doing something wrong? Best, _____________________ Vicente Juan Botet Escribá template <class R1, class R2> struct ratio_subtract { private: #if 1 typedef ratio<R1::num * R2::den - R2::num * R1::den,R1::den * R2::den> aux_type; #else static const boost::intmax_t gcd_n1_n2 = detail::static_gcd<R1::num, R2::num>::value; static const boost::intmax_t gcd_d1_d2 = detail::static_gcd<R1::den, R2::den>::value;#endif public: //The nested typedef type shall be a synonym for ratio<T1, T2> where T1 has the value // R1::num *R2::den - R2::num * R1::den and T2 has the value R1::den * R2::den. #if 1 typedef ratio<aux_type::num ,aux_type::den > type; #else typedef typename ratio_multiply < ratio<gcd_n1_n2, R1::den / gcd_d1_d2>, ratio < detail::ll_sub < detail::ll_mul<R1::num / gcd_n1_n2, R2::den / gcd_d1_d2>::value, detail::ll_mul<R2::num / gcd_n1_n2, R1::den / gcd_d1_d2>::value >::value, R2::den > >::type type; #endif };

2 4

[ratio] Assignation between equivalent ratios
by vicente.botet 07 Dec '09

07 Dec '09

Hi, I was wondering if we need to be able to make assignations between equivalent ratios. e.g. ratio<1,3> r1; ratio<3,9> r2; r1 = r2; // (1) Reading N3000 even if they are equivalents (synonym ) as its num and den are the same, there is no defined assignation. So (1) should not compile with the current recomendation. IMO, this should compile, and so we need to add a specific assignement operator. Other example ratio<1,3> r1; ratio<2,3> r2; r1 = r2-r1; // the type of this expression could be ratio<3,9> so the compilation fails. Otherwise the recomendation should clarify the meaning of synonym on the ratio arithmetic operators [ratio.arithmetic] 2 "The nested typedef type shall be a synonym for ratio<T1, T2> where T1 has the value R1::num * R2::den + R2::num * R1::den and T2 has the value R1::den * R2::den." Maybe we should talk of normalized ratio and not of synonym. BTW, where is synonym defined? In addition I think that we need also to add that the declaration of no normalized ratios, as ratio<3,9>, must fail at compile time as it is not normalized and we can not assigne nothing to them. I'm missing something? Any thougths? Best regards _____________________ Vicente Juan Botet Escribá

5 7

Re: [boost] [msm] Review
by Christophe Henry 07 Dec '09

07 Dec '09

Hi David, >The problem is this: if, *hypothetically*, eUML were the only substantial difference between this proposal >and what is already in Boost, I would argue for an implementation of that syntax on top of Statechart to be a more viable solution. Agreed. >As you spell out here - and I can confirm - that is not the only difference Happy that we finally agree ;-) >Perhaps, I would like to take on that challenge and see how far I can get. >I think it would be great to have a common transition-definition format for these two libraries, and being able to switch in compile-time. >Let me try to look at it a bit, and see what I can do. It would involve a lot of wrappers, unfortunately :-( As I wrote in another post, I find the idea hard but interesting and I can only encourage you to give it a try. >I enjoy being critical of things I like, which is why I always criticize my wife. I wouldn't try to push this too much with mine ;-) >So, take that as a good sign for my formal review (which has already been pushed one day due to my "common interface" sickness :-) ) I'll be happy to read it. I think that, while this common interface thing went a bit long, you brought interesting points to the review and even went the extra mile to not criticize without bringing at least a beginning of a solution, which is not a very common thing. Christophe

1 0

Meta State Machine library review starts Monday
by David Abrahams 07 Dec '09

07 Dec '09

Dear all, With apologies for making this announcement so close to the review start date... The review of the Boost.Msm library starts this Monday, November 23rd and ends the December 6th. Msm was written by Christophe Henry, inspired in part by the example in the book "C++ Template Metaprogramming" (http://boostpro.com/mplbook) About the library: Msm (Meta State Machine) is a library allowing the user to easily define high-performance, straightforward and readable UML2 finite state machines, while respecting the principles of efficiency and declarativeness of the original example. To that end, Msm offers several Domain-Specific Embedded Languages that strive to closely emulate a standard UML diagram. Msm supports a broad range of UML features: - state entry/exit - transition actions/guards - composite states - history - orthogonal regions - terminate states - deferred events - explicit entry/fork - entry/exit pseudostates - anonymous transitions - transition conflicts And several non-standard features to make the developer's life easier (interrupt states, query about the current state(s)). Msm (in its current version, 2.0) can be found: * in the sandbox (http://svn.boost.org/svn/boost/sandbox/msm/) * or in the vault: (http://www.boostpro.com/vault/index.php?directory=Msm) Everybody on this list is invited to participate in this formal review. I hope to see your review of Msm, including your vote on acceptance, and I welcome your participation in the ensuing discussions on the Boost developers' mailing list. Please always include in your review a vote as to whether the library should be accepted into Boost. Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? - With what compiler? - Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards, -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com Review Manager BoostPro Computing http://www.boostpro.com

8 10

Re: [boost] Meta State Machine library review starts Monday
by Christophe Henry 07 Dec '09

07 Dec '09

>I'm wanting to start discussing some more complicated >use cases of this library. Ideally I will just post >the UML HFSM diagram with my email so it is clear. Why not in the Vault in MSM's directory?

1 0

Re: [boost] [msm] internal/external conflicting transitions
by Christophe Henry 07 Dec '09

07 Dec '09

>> I didn't find this in the standard, but I might have missed it out. >> Whatever, after a lengthy discussion with Juraj Ivancic, I came to the >> conclusion that MSM needed what we called an "execution row", which is >> pretty much your internal transitions for simple states. >> >I'll need to search the archives for this discussion (unless it was >elsewhere). As for the standard: using the UML 2.2 Superstructure >document (it is the one I have handy), Section 15.3.15 describes >TransitionKind. It's ok, I found it in 15.3.14. Just before the completion events actually, so we can have a look at both at the same time ;-)

1 0

[msm] eUML guard/action location
by Christophe Henry 07 Dec '09

07 Dec '09

Hi Michael, >What do you think about this instead? > >CurrentState() + cool_event()[Guard()]/(action()) = DestState() > >I think it more closely matches the UML syntax. It's a good idea and it surely matches the UML syntax better. I think the operator precedence will also work. There are however 2 issues: - the current order "CurrentState() + cool_event() = DestState() [Guard()]/(action())" has been chosen to closely match the "normal" row syntax. Only guard and action have been inverted because of operator precedence. - anonymous events. In this case, you have no event, so your syntax would become: CurrentState() [Guard()]/(action()) = DestState() But now the guard/action are "attached" to the source state, which means 2 grammars to support with the corresponding flow of compiler risks and compile-time increases. The first issue is only my worry that users would be confused (eUML already being quite a change). I'd be interested to hear from others about it. The second issue is not so big that it's not worth a try. I think I'll have a look at it and if it works we can then decide which one we prefer. Regards, Christophe

4 3

[iostreams] Fix for restrict/slice
by Daniel James 07 Dec '09

07 Dec '09

Hi, I don't want to merge the new iostreams changes until the unit test results are looking better. So I had a go at fixing restrict_test and slice_test. It would be really helpful if someone more familiar with the library than I am check this. There are two changes, the first is just to fix a problem with running the tests (which I suspect is why the test failure wasn't noticed before). The second one is the one that matters. It look like that when a write to a restricted/sliced stream goes past the end of the restricted area it wasn't writing the last part of the data, so I've tried to fix that. The change is here: https://svn.boost.org/trac/boost/changeset/58225 If it's wrong, I'll revert it. I know little about the library, so I'd appreciate any help here. thanks, Daniel

1 0