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: Kris (krzysztof_at_[hidden])
Date: 2016-02-01 05:57:57

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.

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?

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.