Re: [boost] [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?

Subject: Re: [boost] [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?
From: Krzysztof Jusiak (krzysztof_at_[hidden])
Date: 2016-02-02 16:12:30

On Tue, Feb 2, 2016 at 6:19 PM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> 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_at_[hidden]> 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-MSM-eUML-like-library-which-compiles-up-to-60x-quicker-whils-tp4683016p4683114.html
>>> 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==
>>> >
>>> .
>>> NAML
>>> <
>>> http://boost.2283326.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
>>> >
>>>
>>>
>>
>>
>> --
>> View this message in context:
>> http://boost.2283326.n4.nabble.com/MSM-Is-there-any-interest-in-C-14-Boost-MSM-eUML-like-library-which-compiles-up-to-60x-quicker-whils-tp4683016p4683123.html
>> 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
>