I'm out of time (not just the review period but other time constraints) for doing a proper review, something I regret. However I would like to vote for the acceptance of the msm backend conditional on:
Improvements to documentation to formally and fully describe the msm interface.
As already said, I agree to add a reference.
Inclusion of straight-forward out of the box configurability to support large FSMs.
Unfortunately, there is nothing I can do to improve the compilers :(
Yes, with gcc 4.2.4
- Did you have any problems?
I couldn't get the euml examples to compile. I'm not sure whether this is an environment problem (I was using boost 1.40 on Debian testing) or something else. I didn't spend much time investigating.
As stated in the documentation, g++ supports eUML only from 4.3. It is therefore normal that you didn't manage it. eUML support is repeated several times in the documentation.
My comments have been almost entirely around the back end and the more direct front-ends to it. I personally think euml should be a separate submission/review, once it is more "review ready". There seem to be boost version and compiler version issues in getting even the examples to compile. These are quite possibly outside of msm/euml itselfs control, but if nothing else, they prevent easy review of euml.
I'm actually struggling with the above, because I think having euml in trunk, with tests being run, could facilitate resolving some of these issues. Maybe euml could be included as some experimental/example part of msm initially?
I'm afraid you're extrapolating a little from your own experience using the wrong compiler. There were just 2 issues so far. One with VC8, which has a (documented) weak support for eUML. This issue has been fixed immediately. The second is a reported warning on g++, which I was not able to reproduce and needs more concrete input from Michael. It doesn't seem sufficient for calling eUML not "review ready". True, eUML has more limited compiler support and this is documented too. It doesn't make it less ready.
I don't generally bombard innocent bystanders with my vague ideas. I took asking for a review to be asking for it :-)
The review involves many questions from different people and vague ideas are hard to address. Fortunately, you clarified afterwards, so that I can take valuable data from it. Sorry about the wrong start. It's quite sad because I find a few points quite interesting and they will flow in the design of the future back-ends or improvements in the current one.
In putting together the LAPD implementation I'm using the functor front end, but end up creating functors via a few macros that dispatch to the objects that do the work. I find they don't need access to anything other than the fsm (to post events back to) and the event (to access/process anything it contains). I'm fairly happy with that aspect of the interface.
If it's bothering you to have the source/target states as argument, it's trivial for me to add a new row type. I wouldn't want to force macros on you.
I haven't tried to do it yet, but it struck me that I could potentially use the state types alone (not the object ref parameters) as tags to determine which object to dispatch to. If I chose to have objects that were 1:1 with states I could - but it wouldn't be part of the fsm kernel. Is that concrete enough to make sense?
It is ;-) I'm just unsure if I follow you. With "object to dispatch to", do you mean objects in your application? Why not use the state for this? I'm interested in your use case for future developments.
No, I don't agree at all. I can't see how you can argue that having transitions specified in states as statechart does is less clear than a separate transition table, then claim that having enty/exit actions specified in states is more clear than having them similarly separated.
Good point, which I need to explain. The problem with Statechart's approach is that states do the job which should be the state machine's. This increases the importance of states in Statechart, at the cost of the state machine, which becomes little more than a wrapper. It also mixes entry/exit with the rest of the transition. It's not my reading of the philosophy behind the UML specification. I think the states have a role, state machines another. State machines implement the structure of the diagram. States implement state-specific job, which is much less than the state machines'. Their jobs are: - entry/exit - holding state-specific data (not in the UML standard but still sounds logical to me) - (possibly) internal transitions When you look at a transition table, you see the structure of the machine and only the structure. (EUML shows you more, but this is not a classical state machine front-end :) ) AFAIK you didn't complain about not seeing the actions/guards code in the transition table. To illustrate the difference of roles, could you please have a look at the examples iPodSearch or iPodSearchEuml? This is a good example. Take the state StringFind. Its description would be: - looks if the string contained in an event is found in the string contained in the state. - if found, the state sends the event Found on the current state machine. - else it sends NotFound. Note that StringFind has no idea of which fsm it is used in. It only gets a generic fsm as argument of on_entry. The same documentation is possible for the other states (Foreach and Insert). So what do we have? 3 states, perfectly reusable and implementing some valuable job. And they have no idea of the transition table. Now imagine that MSM comes in with more states, transform, remove, push_back, etc. Using a supporting CASE tool, one could easily build complex algorithms.
I personally find this response vague
Is this already less vague? About the CASE tool, I showed an early prototype in the last BoostCon and plan to start working on it again after the review. I only ask for some patience (for the tool, the state library concept and the back-ends) because I'm doing all this at night, so I'm not so fast ;-) For the moment, the tool only allows defining a complete state machine and generates MSM1 code from it.
But why do they need to be part of the transition table based "kernel"? Don't pay for what you don't need/use?
True, it is an extra cost. Not a big one though, and with little influence on the performance.
Yes. Rather. Sorry for the combination of complex grammar and outright incorrect grammar that would seem to have lead to this.
Sorry for my lack of patience due to my several parallel discussions.
I'm not outright against state instantiation. I can't be. I do really like statechart's state instantiation model. However, in the review of that library I did ask if there was any way that the costs associated with it could be avoided when not strictly needed (when the state contains no state-local storage). I'm asking a very similar question here, but somewhat more emphatically because this is the Msm (first M is important!) and it should surely be able to do this
There are limits to what the first M can do though (besides, you know what that means to your compiler). But I now understand the point and find the idea interesting. It'd probably be possible to instantiate only states with local-storage. It would require a tag (as I won't be able to rely on sizeof) but it could be possible. Thanks for the good point!
- make a 3rd one, more dynamic, which I want to do since a while. - make no review until all possible back-ends are done and make everybody wait at least one more year.
Do we agree that solution 1 seems the more logical?
Logical from what perspective? Buying votes or producing a good library? Politics... ;-)
It's not politics and even less buying votes, but a simple recognition that each developer will use different features and if he doesn't find his, he'll simply not use the library. I'm pretty sure, if I had only proposed a mini-backend, many would have complained about the lack of features, and they'd be right. The say 20-40% of UML features which you use won't be the same as what another developer will use. So, a library needs to support as much as possible. I think MSM is a good library as it offers almost all of UML features at very low runtime cost. The only high cost is the compile-time. Now it's proven that the concepts of the MPL book were right, that it was indeed possible to implement at least as much as statechart with metaprogramming techniques. That this wasn't evident, as shown here (http://lists.boost.org/Archives/boost/2005/03/81853.php). I hope you'll trust me that if I can also implement less ;-) If I get you right, the only major problem you have with the back-end is the automatic, unavoidable instantiation of states? Doesn't sound like an impossible problem to me :) Christophe