Hi, When initially reading the mail list I noted several people acknowledging that MK/MT is a steep learning curve with a complex software stack. That has been my experience.
While this poc introduces Ragel, it loosens the requirement to use GSL. In addition with Ragel the project introduces the tool that is generally acknowledged to produce very efficient FSM's. There is some learning curve for Ragel. The benefit is you add a very powerful tool to your IP. Below is a gist showing a proof-of-concept for a much simpler approach to Machinetalk bindings. I've used ruby as the example just to keep it simple. Other approaches are also possible, and I don't claim this is the best practice https://gist.github.com/hedgehog/de4b423f31451035514362a4a2e0f7c6 It would seem that one way to ensure users are running the same logic across different bindings - without restricting their ability to explore/experiment with alternative implementations - is to have a reference implementation in c (or bash for scripting) which the 3rd party bindings are encouraged to call. Swapping out the reference/MT implementation with a custom/experimental one then becomes a one-liner in the client library. I think comments are best recorded here, with changes to the gist forked over at github. Appreciate any thoughts on this or other approaches. Best wishes Hedge -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
