Meta State Machine library review starts Monday
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
On Mon, Nov 23, 2009 at 2:07 AM, David Abrahams <dave@boostpro.com> wrote:
Dear all,
[snip]
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)
Is there any direct link for an online documentation? [snip]
Regards,
-- Felipe Magno de Almeida
Hi, This is not a review. So far I've done little more than read the docs, compile and run some examples and have a brief look at trying to use msm for a "real world" use. I found code size of stripped executables compiled with gcc 4.3 to be quite reasonable - especially at high optimisation levels, although still about twice the size (the docs state) VC9 achieves. I'm assuming that the large sizes mentioned are simply due to the generated files not being stripped. I was unable to compile the euml example - I haven't investigated the errors yet. I had hoped to pick what I'd consider a realistic use for a high performance FSM tool (a low level comms protocol) and do a basic mock-up implementation using MSM. However a reasonably typical layer 2 protocol (LAPD) has 8 states and a transition table that in a condensed form (row for each event, column for each state with the column describing the actions and transition) is 10 pages long, so it is pretty obvious I can't do that... Its likely that a bit of refactoring could bring the total number of transitions down somewhat using composite states, but the number of events to be handled exceeds the typical limits for number of transitions so this still seems hopeless. This leaves me fairly stuck for a practical use. I don't find a great deal of value in a FSM DSEL for really small FSMs. Hopefully someone else does. At this point, I really like what msm is trying to do - it just doesn't quite do it for me in a practical application. Maybe that just means waiting for Moore's law and compiler technology to catch up? Regards Darryl.
Not a review, just a question. Why the transition table uses non-type template parameter for actions and guards instead of using a agreed function name for handling events in states? That should get the transition table a lot smaller and maybe even faster for not using a pointer (though speed-wise, that's a wild guess). I think it would be alot cleaner. I'm surely missing something, but I would like to know what it is. Thanks in advance, -- Felipe Magno de Almeida
Hi,
The review of the Boost.Msm library starts this Monday, November 23rd and ends the December 6th.
This is not (yet) a review. I'm looking at MSM and its documentation, for the purpose of review, and I consider it very useful and interesting. First I thought (intuitively) that the eUML was meant for output, but apparently that is not the case, it is an embedded language for defining state machines, right. However, the documentation contains a lot of state machine drawings. For library users, that can be useful too. So it might make sense to relate (or export) a state machine to a Boost.Graph? If that is done, a drawing can be made easily using graphviz. Maybe not as fancy, but at least you see what you're doing :-). Is is somehow possible to export an MSM to a Boost.Graph, either within the library, or in an example or separate utility headerfile? Regards, Barend
Hi Dave, Christophe, list, Here is my review of MSM.
Please always include in your review a vote as to whether the library should be accepted into Boost.
Yes, I certainly think it should be accepted, so my vote is yes. The MSM it is a great addition to Boost. I didn't compare it to StateChart but I've read the discussions and I agree that it will be no problem to have both libraries within Boost. In preparing this review I did do two experiments. First I copied an example and transformed it into a "project management state machine", having request for quotation, quotation, rejection, etc. That all went well, also because it was quite similar to the examples. I got used to the MSM, a bit, by doing this. It is easy to apply. Then I wanted to use MSM in my own environment. So I found a piece of code where I keep track of state using an integer, and applied the MSM at that place. This all was possible, relatively easy, and compiled and run within one or two hours. It is giving more possibilities than a plain integer, and it is more elegant. I liked the is_flag_active option, because I needed it and could easily find it in the documentation, including argumentation why it is useful (and it is). (Of course) I forgot some state transitions and had to include the no_transition function, to avoid assertions. This is all working well. I wondered if non-possible transitions could be catched compile-time, but apparently this is not possible (because of triggers and guards). I didn't use any of the advanced features, such as eUML or composite states.
- What is your evaluation of the design?
I really like how MSM can be applied, the mpl::vector with the states and transitions. Simple, modern C++/Boost, and very useful. The design followed the example from the MPL-book, was extended and is now splitted into back-end and front-end, which seems a sound choice. It is a concise set of source files, in total 14205 lines (of which eUML contains 10534 lines). So (excluding the eUML) within about ~3500 lines a complete compile-time configurable flexible state machine is there. I didn't look at the eUML stuff because of time reasons. I would like to see a connection with Boost.Graph (I mean, see it in an example or so, not within the kernel), to see what I'm doing with all those transitions; I asked this on the list and this is possible, good.
- What is your evaluation of the implementation?
It looks very competent, impressive usage of MPL. I didn't look at all details. There are a few minor points (just a matter of style, not to be considered as contingent) 1) the struct "Row" is written with a capital, this is unusual within Boost. Words with a capital are normally template parameters. I understand why it is done (there was already a row without a capital in Msm 1.1), but I think it could have been solved differently (for example: "transition", or if that is too long "tr" which could stand for transition row or table row). I don't like to see Row where I expect to see a normal classname. The capitals are also used in the documentation and samples (struct Empty) but there I've less problems with it. Maybe use of Capitals for states is a state machine convention. I noticed different conventions in the source files. Many template parameters are completely capitalized. I had done the same thing, earlier, but was hinted that this is unusual as well. Just a matter of style (as long as library users normally don't see it, it is less important) 2) the class state_machine is quite long (in lines of code), containing several sub-structs which maybe (don't know) could be moved to a separate source file (detail). 3) the sources are too complex to understand completely, within the timeframe of this review. The only thing I could add (also maybe personal preference) is that I would consider to change some sfinae with tag dispatching. It might possible that, by this, more compilers could be supported. But I didn't take the effort to research if this would be feasable here. Don't know.
- What is your evaluation of the documentation?
The documentation is good. It explains state machines, gives enough tutorials and samples in the form of compilable code, and contains clear illustrations. I could easily find what I needed, such as the active-flag and the paragraph about speeding up the library. I did read most sections, but skipped most of the eUML sections (which are quite long). The documentation pays attention to the users coming from Msm 1.1, which is good because it is always good to support current users. However, as a newcomer it is less interesting (and sometimes a bit confusing) to see all differences. There is even humour included (e.g. at discussion of gcc: "Boring compiler, almost all is working almost as expected") but I don't think that is the norm within (Boost) documentation. However, it makes it nice to read :-)
- What is your evaluation of the potential usefulness of the library?
It is very useful, without doubts. I will use it in the future.
- Did you try to use the library? - With what compiler?
- Visual C++ 2005 Express Edition - gcc 4.4.0 on MinGW
- Did you have any problems?
No real problems. When using the member template function is_flag_active I had to add the funny template keyword. That was in my own code, because I was in a template environment, the Flags sample compiles OK. When I thought to be clever, in my own test, and call the p.start() from the within constructor of the state machine, the compiler hinted me: warning C4717: 'trav_state::trav_state' : recursive on all control paths, function will cause runtime stack overflow and that was for me the reason to change it back conform the samples. You have to call p.start() manually. However, it is running OK in an example (modified by me), don't know why. When compiling some other examples, I saw the points noted in the documentation Compiler's Corner...
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
About a mere day, in total, since the request for review was sent out.
- Are you knowledgeable about the problem domain?
Not very, but I know something about statecharts, and they are typically those kind of things you could (and should) use more often. Thanks for submitting this excellent library. Regards, Barend
Barend Gehrels wrote:
(Of course) I forgot some state transitions and had to include the no_transition function, to avoid assertions. This is all working well. I wondered if non-possible transitions could be catched compile-time, but apparently this is not possible (because of triggers and guards).
I wonder if the library can provide a debugging mode that would provide a helpful default implementation of no_transition that could help identify the unknown transition rather than requiring the user to write something? Such a function might access internal details, perhaps only provided in the said debugging mode, that would be clearer about the source state and event for which no transition was provided than would user-level code. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
David or someone in the know ... 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. Does the ML support png or some other type of attachment? Thanks - michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
On Mon, Dec 7, 2009 at 3:03 PM, Phil Endecott <spam_from_boost_dev@chezphil.org> wrote:
Michael Caisse wrote:
Does the ML support png or some other type of attachment?
Attachments don't work for those of us who read the digest; can you put the diagrams online somewhere?
I thought the digest (which I do not use) gave links to attached documents... Maybe that is just gmane...
Phil Endecott wrote:
Michael Caisse wrote:
Does the ML support png or some other type of attachment?
Attachments don't work for those of us who read the digest; can you put the diagrams online somewhere?
Phil.
Indeed Phil. I recall now that you have made this request before. Thanks for the reminder. michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
participants (8)
-
Barend Gehrels -
Darryl Green -
David Abrahams -
Felipe Magno de Almeida -
Michael Caisse -
OvermindDL1 -
Phil Endecott -
Stewart, Robert