On Tue, Feb 2, 2016 at 6:19 PM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote:
Le 01/02/2016 11:57, Kris a écrit :
Hi Christophe,
Thank you very much for your feedback and time. I appreciate it a lot.
Yea, I like having everything visible on the transition table and therefore I put initial states as well entry/exit actions there. I know you have a different view on that, however, I find it easier to follow this way.
Declare events on the fly its easy to do, however, I don't think it will bring much value as events can be accessed outside the transition table as well as they, most likely, will hold some data. Therefore, I'm not sure about it. Might be useful to have both options tho.
I would love to compare MSM-lite/MSM-eUML to eUML2, however I haven't seen it yet besides some code in the emails. Can you share a link to the eUML2 version, please? I will defo add benchmarks for it.
I don't see any problem with that as MSM-lite is open source. I also offer my help in designing and/or coding.
Hi, IIUC you are proposing a 3rd MSM library in Boost, and you don't pretend to make it a sub-library of Boost.MSM. If I'm right, I suggest you to rename the namespace to msm_lite or whatever you find more appropriated.
Fair point, thanks for pointing it out. It's a valid concern. I have nothing against changing the namespace/name as 'msm-lite' is just a working title either way. Not sure what the best name should be tho?
BTW, with the figures you gave I believe that there would be an interest in your library.
Well, I would like to keep the core of the library as small as possible as in my experience a lot of users are actually not using as many features. Having said that, I have no problems adding new features via policies/extensions. Moreover, MSM-lite is already used in some of the top growing mobile games, but yea, I do agree that some users would like to see more features. Anyway, are there any specific features you are talking about which are so essential. I know that defer/history might be useful, but I don't see much more features in MSM, besides explicit/fork states?
Well these are already quite a few features. I have not see local transitions (different from internal transitions).
Yea interna(local) transitions are supported. Example here -> http://boost-experimental.github.io/msm-lite/examples/index.html#transitions
Please could you point me if you support choice points? While choice points are unavoidable in graphical UML, I find it not very
useful while writing MSM in C++ as I prefer to do it using if or switch. However having a transition table that can have only one next-state by transition disable this possibility. I use to have a transition table with a transition that has an action_nextstate that do the action and returns the nextstate of the transition.
|"s2"_s + event<e2> [ guard ] / action_nextstate This avoids the storage of local variable on the MSM data context. |
Have you considered this possibility?
Interesting idea, can you elaborate please as I'm not sure whether I follow the idea with the action_nextstate? If it comes to the choice points, I guess the easier way is just to have multiple transitions from the same state? make_transition_table( s1 -> s2 + e2 [some_guard1 && some_guard2] / action1 , s1 -> s3 + e2 [other_guard] / action2 , s1 + e2 / action3 ); would be the same as if (e2) { if (some_guard1 && some_guard2) { action1; change_state_to(s2); } else if(other_guard) { action2; change_state_to(s3); } else { action3; } }
Best, Vicente
Thank you for you feedback. Cheers, Kris
I totally admire MSM design. I really liked the separation between back and
front end. I have even implemented some extensions myself: * dependency injection support (https://github.com/krzysztof-jusiak/msm) * testing support (https://github.com/krzysztof-jusiak/msm/tree/master)
And I also followed this approach in MSM-lite; it's not stated explicitly but it might be found there.
Although it would be interesting to incorporate with MSM I'm afraid it's not possible with the current MSM as MSM-lite has a different approach. Especially back-end is achieved in a different way which is not compatible with MSM. While MSM-lite front-end still produces transitions-like types it holds objects and relay on dependencies to be injected. All in all, MSM-lite it's quite different than the current version of MSM. It maybe would be possible with a new version of MSM, however there is no such a thing yet, is it?
Thank you again for your feedback!
Cheers, Kris
On Sun, Jan 31, 2016 at 9:18 PM, Christophe Henry-2 [via Boost] < ml-node+s2283326n4683114h53@n4.nabble.com> wrote:
Hi Kris,
I have recently released 1.0.0 version of experimental C++14
Boost.MSM-lite. Your scalable C++14 header only eUML-like meta state machine library with no dependencies, which outperform Boost.MSM - eUML in: - faster compilation times - up to 60x times faster! - smaller executable size - up to 15x smaller - slightly better performance - smaller memory usage - short error messages
I find it quite nice. The idea is very interesting. Minor nitpicks, I find weird mixing strings and <> syntax and the trick about inital states, but it's really a matter of taste. It would also be good to avoid having to declare events separately. It would be interesting to see how it fares against the eUML successor, eUML2 written using metaparse.
I do plan to rewrite parts of MSM and have a second look at eUML later this year, so if you don't mind, I might use some of your ideas.
I'm wondering where you want to go from there. Rewriting all of MSM is quite some work. But keeping the library lite is not really an option if you want more than a toy library because most potential users will want more features.
Actually, the whole idea of dividing MSM in back and front ends was exactly to allow front-ends like yours as extensions. Would you be interested in doing this instead? If changes in back-end are necessary, why not? It has to be done anyway, as most of the library was written 7-8 years ago. It might mean that there will be a pre and post C++14 versions, but I don't think it matters.
Cheers, Christophe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
------------------------------ If you reply to this email, your message will be added to the discussion below:
http://boost.2283326.n4.nabble.com/MSM-Is-there-any-interest-in-C-14-Boost-M... To unsubscribe from [MSM] Is there any interest in C++14 Boost.MSM-eUML like library which compiles up to 60x quicker whilst being a slightly faster too?, click here < http://boost.2283326.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4683016&code=a3J6eXN6dG9mQGp1c2lhay5uZXR8NDY4MzAxNnwtMTY0MTkzNTIwMA==
-- View this message in context: http://boost.2283326.n4.nabble.com/MSM-Is-there-any-interest-in-C-14-Boost-M... Sent from the Boost - Dev mailing list archive at Nabble.com.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost