- Boost - lists.boost.org

Re: [boost] [msm] Review
by Christophe Henry 13 Jan '10

13 Jan '10

>No, I won't spend "a lot more" time trying to decipher the supposedly >hidden meaning of your post and invest the time more wisely by making >MSM more useful. >The link I added seems quite clear to me and anyone interested can >make himself his own opinion by opening it. >You did not bother bringing an argumentation disproving my claim, so I >will simply keep it. >As you also didn't address the more important technical part (multiple >TU) of my answer, I will consider it accepted. I want to apologize for the harsh language I used and the uncharacteristic loss of patience I displayed. I also wanted to let you know that I of course accept your explanation as not doing it would be suspecting you of being dishonest, which I have not been doing at any time. I admit honestly failing to understand what is the impossibility you claim, thus the confusion. I think there is no interest right now for a technical discussion but for the record, I do not accept any impossibility of any sort and the next version of MSM will include a precise example of a multi-TU fsm to illustrate my claim. I wish all of you a happy, successful new year. Christophe

2 1

Re: [boost] [msm] scalability
by Christophe Henry 13 Jan '10

13 Jan '10

>> It might be interesting to contemplate a "fast-compile mode" that >> builds the same logical state machine using the same input syntax but >> trades away a little run time for compile time. > > Yes, I'd be willing to trade that, as my SM is not running in a real > time environment, but is managing user mouse and menu management. I'm also thinking about such back-end but I think the trade-off is likely to be not so much against run-time but UML features. I'm think about transition conflicts. This one is pretty hard on the compiler. I'd also bet on submachines and entry/exit pseudo states. If one is ready to give these ones up, I think we can have pretty easily something running without speed loss (I'd even bet on a speed gain). All it'd take would be the MPL book example cooked with the MSM sauce.

3 2

Re: [boost] [MSM] Meta State Machine Library Accepted
by Christophe Henry 13 Jan '10

13 Jan '10

Hi all, I'm happy to hear this result! Thank you Dave for your support and for taking on the very hard job of managing the review. I also want to thank Franz Alt, David Bergman, Michael Caisse, Barend Gehrels, Darryl Greene, Juraj Ivancic, Erik Nelson and Kenny Riddile for taking the time to write the mentioned thorough reviews and all those who supported the library. The development will of course continue and I hope that many people will further provide me with more valuable nuggets. I used the time after the review to continue the development. You will find in the sandbox a few new features: - increased dispatch speed and other optimizations. - removed some SFINAE to help poor VC8 ;-) - new eUML syntax as discussed. You can now write: target == source + event [guard] /action or source + event [guard] /action == target. - base events: if eventA is the base of eventB, you can use eventB for transitions defined for eventA (doc not updated yet) - internal transitions (first syntax). More to come in the next days. Next, as required, I'll rewrite the doc, add the reference and some UML tutorial. So, as Dave wrote, a lot of work is waiting :) Thanks again to all of you!

1 0

Re: [boost] [Boost-users] GGL Review Results
by Christophe Henry 13 Jan '10

13 Jan '10

Hi all, I'm happy to hear this result! Thank you Dave for your support and for taking on the very hard job of managing the review. I also want to thank Franz Alt, David Bergman, Michael Caisse, Barend Gehrels, Darryl Greene, Juraj Ivancic, Erik Nelson and Kenny Riddile for taking the time to write the mentioned thorough reviews and all those who supported the library. The development will of course continue and I hope that many people will further provide me with more valuable nuggets. I used the time after the review to continue the development. You will find in the sandbox a few new features: - increased dispatch speed and other optimizations. - removed some SFINAE to help poor VC8 ;-) - new eUML syntax as discussed. You can now write: target == source + event [guard] /action or source + event [guard] /action == target. - base events: if eventA is the base of eventB, you can use eventB for transitions defined for eventA (doc not updated yet) - internal transitions (first syntax). More to come in the next days. Next, as required, I'll rewrite the doc, add the reference and some UML tutorial. So, as Dave wrote, a lot of work is waiting :) Thanks again to all of you!

1 0

Re: [boost] [msm] scalability
by Christophe Henry 13 Jan '10

13 Jan '10

>> If one is ready to give these ones up, I think we can have pretty >> easily something running without speed loss (I'd even bet on a speed >> gain). All it'd take would be the MPL book example cooked with the MSM >> sauce. >That'd be great. Let me know how I can help. > >Jeff First of all, what would really help would be if you (and any other interested) could list me the main UML features you use so that we can define what the mini backend must provide in addition to what the book example does.

1 0

[uuid] status?
by Vladimir Prus 13 Jan '10

13 Jan '10

I notice that uuid is still not merged to the release branch. What is missing and can the merge be performed in next 24 hours? - Volodya

4 9

[MSM] Meta State Machine Library Accepted
by David Abrahams 13 Jan '10

13 Jan '10

I'm pleased to announce the acceptance into Boost of the Meta State Machine library by Christophe Henry The library got seven reviews, all thoughtful and in-depth, and was unanimously accepted by all reviewers (conditionally, by three of them). Reading through the reviews (not to mention all the other commentary) was truly an overwhelming experience for me. The thoroughness and depth of knowledge of the reviewers seemed to be a cut well above what I'm used to seeing. That, along with the unanimity of their votes, and Christophe's good-natured responsiveness to questions and criticism during the review, make me very confident in accepting MSM. The reviews contain scads of feature requests, ideas, and other valuable nuggets for Christophe to work on, so many that nobody other than Christophe would find a full enumeration useful. So, sorry Christophe, I'm going to leave it to you to troll for details in the message archives. [I suggest taking a pass over all issues mentioned and turning them into Trac tickets. Maybe you can get the review authors to do that themselves for their own reviews.] However, I can summarize some broad themes and issues of general interest to Boosters (and a few things I feel strongly about but won't demand): * There was universal satisfaction with the performance of state machines generated with MSM. * Though the tutorial was generally praised, every conditional acceptance was predicated on improving the documentation, in particular on providing a library reference. This really must be done. There were also several requests to break the tutorial into multiple pages. * One reviewer had problems reading the tutorial because it relies so heavily on UML terms-of-art. I agree with him that people only familiar with FSMs ought to be able to read the tutorial as well. That may mean including documentation of some UML concepts in the library docs. * eUML is really cool but it is apparently still in flux; for now it should probably be labelled as an experimental feature subject to change. * SimpleStates do not support internal transitions. They should. * The name is a bit misleading. Now would be the time to come up with something better if you're going to do it. StateChart is called StateChart in part because of my insistence that any library called Boost.FSM should be able to implement small, tight state machines appropriate for embedded systems use. Even though this library has those properties, I do not know whether the name would be appropriate, for several other reasons I won't list but that you, dear reader are probably thinking of right now. Thank you to Christophe and all the reviewers for restoring my faith in the Boost review process. And of course, congratulations to Christophe. Now the fun is over and the hard work begins... :-) -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com

2 1

Release branch closed
by Vladimir Prus 13 Jan '10

13 Jan '10

Boosters, The release branch is now closed for all commits, except by explicit permission of release managers. -- The Release Managers, Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus

5 12

Re: [boost] [msm] eUML guard/action location
by Christophe Henry 13 Jan '10

13 Jan '10

> Cristophe, I could definitely help out with macros and use of PP for MSM, if you need that help. Unfortunately, the next few weeks (at least) are a bit too hectic. >But, now you know that I might be willing (if not currently available) :-) > > /David I looked at your abstract fsm example and I easily believe you :) I happily and thankfully accept your offer. Just contact me when you have time and we can work this out. Thanks a lot! Christophe

1 0

Re: [boost] [msm] eUML guard/action location
by Christophe Henry 12 Jan '10

12 Jan '10

> IMO making it easy for the user to declare these things (maybe with a > macro) and documenting that as the normal approach, dropping all the > parens, could be a big improvement. Unfortunately, I'm pretty bad at macros (and try to avoid them as much as I can) and after spending quite some time at it, I don't come further. Ok, for states, it's trivial: BOOST_MSM_STATE((Empty_Entry(),Empty_Exit()),Empty_,empty) Where Empty_ is the state type name and empty the instance for use in the transition table. Implemented with: # define BOOST_MSM_STATE(expr,state_name,instance_name) \ typedef BOOST_TYPEOF(build_state(expr)) state_name;state_name const instance_name; Where it gets slightly more "fun" is when I want to also remove the parens for the actions/guards. For example, if I have an action called start_playback which is: struct start_playback : euml_action<start_playback> { template <class FSM,class EVT,class SourceState,class TargetState> void operator()(EVT const& ,FSM&,SourceState& ,TargetState& ) { cout << "player::start_playback" << endl; } }; I want to use the same principle. start_playback_ will be the type and start_playback the instance. I come to: BOOST_MSM_ACTION((start_playback_,start_playback, (({ template <class FSM,class EVT,class SourceState,class TargetState> void operator()(EVT const& ,FSM&,SourceState& ,TargetState& ) { cout << "player::start_playback" << endl; } })) )) I thought of using PP tuple: // the action type #define BOOST_MSM_ACTION_TYPE(x) \ BOOST_PP_TUPLE_ELEM(3,0,x) // the action instance for use in the stt #define BOOST_MSM_ACTION_INSTANCE(x) \ BOOST_PP_TUPLE_ELEM(3,1,x) // the action code #define BOOST_MSM_ACTION_CODE(x) \ BOOST_PP_TUPLE_REM_CTOR(1,BOOST_PP_TUPLE_ELEM(3,2,x)) # define BOOST_MSM_ACTION(tuple) \ struct BOOST_MSM_ACTION_TYPE(tuple): euml_action<BOOST_MSM_ACTION_TYPE(tuple)> BOOST_MSM_ACTION_CODE(tuple) ; BOOST_MSM_ACTION_TYPE(tuple) const BOOST_MSM_ACTION_INSTANCE(tuple) ; But I fail at getting the action correctly so I generate: struct start_playback_: euml_action<start_playback_> ({ template... // notice the extra parens I hoped that REM_CTOR would do the job but no. Any idea if it is possible?

2 1