The formal review for Andrey Semashev's Finite State Machines (FSM) library is scheduled for August 11th to 20th. Quoting from the documentation: "The main goals of the library are: * Simplicity. It should be very simple to create state machine using this library. * Performance. The state machine infrastructure should not be very time and memory-consuming in order to be applicable in more use cases. * Extensibility. A developer may want to add more states to the existing state machine, and this addition should be relatively safe since it shouldn't interfere with the existing states. The developer should also be able to specify additional transitions and events for the machine with minimum modifications to the existing code." "The following compilers are known to have problems or most likely will have ones: * Microsoft Visual C++ 6.0 and 7.0. Most probably will fail to compile due to lack of partial template specialization support. * Borland C++ Builder 5.5.1 (free version). Fails to compile due to lack of partial template specialization and in-class using declarations support. Some other minor problems also have been noticed. Newer versions of the compiler have not been tested. * OpenWatcom 1.5. Fails to compile due to problems with Boost.MPL code. Newer versions of the compiler have not been tested. * SunPro C++ Compiler 5.5 for Solaris (SPARC). Most likely will show problems with function overload resolution. Newer versions of the compiler have not been tested." The current submission is available from the sandbox vault at http://tinyurl.com/yjozfn (or http://www.boostpro.com/vault/index.php?action=downloadfile&filename=FSM.zip &directory=&PHPSESSID=48493076c1ea60ae316f7b60f15b9ed1, if you prefer.) MV
On Mon, Aug 4, 2008 at 9:36 PM, Martin Vuille <martin@jpmvrealtime.com> wrote:
The formal review for Andrey Semashev's Finite State Machines (FSM) library is scheduled for August 11th to 20th.
<snip>
The current submission is available from the sandbox vault at http://tinyurl.com/yjozfn (or http://www.boostpro.com/vault/index.php?action=downloadfile&filename=FSM.zip &directory=&PHPSESSID=48493076c1ea60ae316f7b60f15b9ed1, if you prefer.)
Are the docs available online somewhere? -- gpd
Giovanni Piero Deretta wrote:
On Mon, Aug 4, 2008 at 9:36 PM, Martin Vuille <martin@jpmvrealtime.com> wrote:
The formal review for Andrey Semashev's Finite State Machines (FSM) library is scheduled for August 11th to 20th.
<snip>
The current submission is available from the sandbox vault at http://tinyurl.com/yjozfn (or http://www.boostpro.com/vault/index.php?action=downloadfile&filename=FSM.zip &directory=&PHPSESSID=48493076c1ea60ae316f7b60f15b9ed1, if you prefer.)
Are the docs available online somewhere?
Sorry, the library is not hosted anywhere. I wonder if libraries in the Boost sandbox have some hosting for docs?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 05 August 2008 13:36 pm, Andrey Semashev wrote:
Are the docs available online somewhere?
Sorry, the library is not hosted anywhere. I wonder if libraries in the Boost sandbox have some hosting for docs?
I don't know if it's a recommended practice for the sandbox, but if you commit your html to the sandbox, it's available to any web browser by pointing it directly at the svn URL. For example, there is some html checked into the boost_docs part of the sandbox: http://svn.boost.org/svn/boost/sandbox/boost_docs/trunk/tools/boostbook/doc/... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFImJZy5vihyNWuA4URAqx6AKCoVyyryYpvBeuzloxmvyjFT9QxzQCfdmJi 7VL9cZlNhm2xsg2HgxnVMKY= =s1l+ -----END PGP SIGNATURE-----
Frank Mori Hess wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday 05 August 2008 13:36 pm, Andrey Semashev wrote:
Are the docs available online somewhere? Sorry, the library is not hosted anywhere. I wonder if libraries in the Boost sandbox have some hosting for docs?
You can put your docs at http://boost-sandbox.sf.net/. Just ssh into shell.sf.net, cd to /home/groups/b/bo/boost-sandbox/htdocs, make a directory for your stuff (probably under libs/), then exit and use scp to copy your docs to the correct place. I created the following bash script that gzips xpressive's html directory, pushes it to shell.sf.net, and unzips it remotely. You might find it useful. (Obviously, you'll need to change the username.) #!/bin/sh rm html.tar.gz tar -czf html.tar.gz html scp html.tar.gz \ eric_niebler@shell.sf.net:/home/groups/b/bo/boost-sandbox/htdocs/libs/xpressive/doc ssh eric_niebler@shell.sf.net \ 'cd /home/groups/b/bo/boost-sandbox/htdocs/libs/xpressive/doc; \ rm -rf html; \ tar -xzf html.tar.gz' -- Eric Niebler BoostPro Computing http://www.boostpro.com
Giovanni, On Tue, Aug 5, 2008 at 10:36 AM, Andrey Semashev <andrey.semashev@gmail.com>wrote:
<snip>
Are the docs available online somewhere?
Sorry, the library is not hosted anywhere. I wonder if libraries in the Boost sandbox have some hosting for docs?
I've hosted the docs here: http://boost-extension.redshoelace.com/docs/boost/fsm/doc/reference.html http://boost-extension.redshoelace.com/docs/boost/fsm/doc/state_machine.html If anyone else needs documentation hosting for potential Boost libraries, I can donate space. The server ought to be faster than hosting them straight from the sandbox. Jeremy Pack
"Jeremy Pack" <rostovpack@gmail.com> wrote in news:1b251b590808051138x6ec7920v33d754c8f33fff7e@mail.gmail.com:
I've hosted the docs here:
http://boost-extension.redshoelace.com/docs/boost/fsm/doc/reference.html http://boost-extension.redshoelace.com/docs/boost/fsm/doc/state_machine.h tml
If anyone else needs documentation hosting for potential Boost libraries, I can donate space. The server ought to be faster than hosting them straight from the sandbox.
Thank you very much Jeremy for taking care of this. MV
Jurko Gospodnetić wrote:
Hi Martin.
The formal review for Andrey Semashev's Finite State Machines (FSM) library is scheduled for August 11th to 20th.
What are the intended and actual differences from the already accepted Statechart library?
The main differences are simplicity and performance. The performance tests show difference by an order of magnitude, in the best case for Boost.Statechart. The overall design of Boost.FSM is geared more to compile-time code generation, while Boost.Statechart aims to support more scaled machines and therefore is geared towards run-time. There is a section in the docs that compares the libraries.
Andrey Semashev wrote:
Jurko Gospodnetić wrote:
What are the intended and actual differences from the already accepted Statechart library?
The main differences are simplicity and performance. The performance tests show difference by an order of magnitude, in the best case for Boost.Statechart. The overall design of Boost.FSM is geared more to compile-time code generation, while Boost.Statechart aims to support more scaled machines and therefore is geared towards run-time. There is a section in the docs that compares the libraries.
I can attest to the necessity of this. We have several exchange libraries that require state machines to implement their data protocols but we use a home-brewed boost::mpl::inherit_linearly implementation because the features of Boost.StateChart simply brings in to many performance penalties for our simpler usage that would fit within the Boost.FSM framework. In fact, if I remember correctly, we used a thing on Boost.Vault called "FSM" as an implementation guide.
on Tue Aug 05 2008, Chris Knight <cknite-AT-gmail.com> wrote:
Andrey Semashev wrote:
Jurko Gospodnetić wrote:
What are the intended and actual differences from the already accepted Statechart library?
The main differences are simplicity and performance. The performance tests show difference by an order of magnitude, in the best case for Boost.Statechart. The overall design of Boost.FSM is geared more to compile-time code generation, while Boost.Statechart aims to support more scaled machines and therefore is geared towards run-time. There is a section in the docs that compares the libraries.
I can attest to the necessity of this. We have several exchange libraries that require state machines to implement their data protocols but we use a home-brewed boost::mpl::inherit_linearly implementation because the features of Boost.StateChart simply brings in to many performance penalties for our simpler usage that would fit within the Boost.FSM framework. In fact, if I remember correctly, we used a thing on Boost.Vault called "FSM" as an implementation guide.
I don't know if you've seen the FSM examples from "C++ Template Metaprogramming" or not. It would be interesting for this library's documentation to explain its advantages over that approach (I can see some from here already). One other thing I'd like to see is an implementation of nested states. I once promised some people who needed that functionality that I'd extend our framework to support them, but was never able to figure out what their semantics are ;-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Tuesday 05 August 2008 4:34:30 pm David Abrahams wrote:
I don't know if you've seen the FSM examples from "C++ Template Metaprogramming" or not. It would be interesting for this library's documentation to explain its advantages over that approach (I can see some from here already).
One other thing I'd like to see is an implementation of nested states. I once promised some people who needed that functionality that I'd extend our framework to support them, but was never able to figure out what their semantics are ;-)
Nested states would be nice. I looked through the "C++ Template Metaprogramming" book as another reference when developing our internal implementation. I didn't get too fancy in our own but some protocol's like FIX for instance has many, many dark corners. I would see nested states as simply a further restriction on the matching of the from state. This could provide further optimizations as a well designed transition table could reduce the set of states to match against. However, I'm not quite sure how that plays out in a design with the enter/exit state handlers, transition handlers, et al. The finite state machine I came up with for the FIX protocol was well over 50 transitions. I implemented ours so that the from state could be boost::any which acts acts like '.' in regexps and I suppose means our implementation should be renamed kmt::nfsm. It was a zero-cost implentation as it simply adds one last transition to each from state's action linked-list.I was able to get the transition list down to 22 with that one feature. Mostly all the different error conditions that you want to handle gracefully in a text protocol originally designed in the 1980's and still used by finance exchanges today. <sigh> The other feature that I'm not sure whether FSM supports or not is static registering of posted event types so as to skip around run-time double dispatching. I suspect any implementation that seeks to provide a simplified/speedier interface over StateChart should support that as well. Chris
Chris Knight wrote:
On Tuesday 05 August 2008 4:34:30 pm David Abrahams wrote:
The finite state machine I came up with for the FIX protocol was well over 50 transitions. I implemented ours so that the from state could be boost::any which acts acts like '.' in regexps and I suppose means our implementation should be renamed kmt::nfsm. It was a zero-cost implentation as it simply adds one last transition to each from state's action linked-list.I was able to get the transition list down to 22 with that one feature. Mostly all the different error conditions that you want to handle gracefully in a text protocol originally designed in the 1980's and still used by finance exchanges today. <sigh>
The Boost.FSM library supports similar feature. You can use any_state placeholder in transitions in order to tell that the transition works for any source state.
The other feature that I'm not sure whether FSM supports or not is static registering of posted event types so as to skip around run-time double dispatching. I suspect any implementation that seeks to provide a simplified/speedier interface over StateChart should support that as well.
I'm not sure what you mean by that "registering". The library does one event dispatching if it is known at compile time that no entry in the transition map will be triggered. If a transition map entry is triggered, then two dispatches are done - one to deliver event to the transition handler, and second to deliver the event to the active state. In any case, dispatching is very efficient and is basically a call on a function pointer that is acquired from an array by index.
On Wednesday 06 August 2008 9:59:43 am Andrey Semashev wrote:
I'm not sure what you mean by that "registering". The library does one event dispatching if it is known at compile time that no entry in the transition map will be triggered. If a transition map entry is triggered, then two dispatches are done - one to deliver event to the transition handler, and second to deliver the event to the active state. In any case, dispatching is very efficient and is basically a call on a function pointer that is acquired from an array by index.
I was referring to deferred event dispatching. I see on another thread that Boost.FSM does not support such a concept. I was simply noting that any such implementation can/should be done without the use of rtti/virtuals. Chris
Chris Knight wrote:
On Wednesday 06 August 2008 9:59:43 am Andrey Semashev wrote:
I'm not sure what you mean by that "registering". The library does one event dispatching if it is known at compile time that no entry in the transition map will be triggered. If a transition map entry is triggered, then two dispatches are done - one to deliver event to the transition handler, and second to deliver the event to the active state. In any case, dispatching is very efficient and is basically a call on a function pointer that is acquired from an array by index.
I was referring to deferred event dispatching. I see on another thread that Boost.FSM does not support such a concept. I was simply noting that any such implementation can/should be done without the use of rtti/virtuals.
I don't see the connection between rtti/virtuals and event deferring. Anyway, in case of Boost.FSM virtual functions are only used for enter state handlers in case of run-time version of state switching. Type info is used for convenience only - it provides default state names and diagnostic information in case of exceptions.
On Wednesday 06 August 2008 12:03:27 pm Andrey Semashev wrote:
I don't see the connection between rtti/virtuals and event deferring. Anyway, in case of Boost.FSM virtual functions are only used for enter state handlers in case of run-time version of state switching. Type info is used for convenience only - it provides default state names and diagnostic information in case of exceptions.
template< typename T > void on_process(T const&); void on_process_dynamic(base_event const& base) { base->some_virtual(); // or m_events[base->id].some_non_virtual(); } My only point I suppose is that with a
On Wednesday 06 August 2008 12:03:27 pm Andrey Semashev wrote:
I don't see the connection between rtti/virtuals and event deferring. Anyway, in case of Boost.FSM virtual functions are only used for enter state handlers in case of run-time version of state switching. Type info is used for convenience only - it provides default state names and diagnostic information in case of exceptions.
template< typename T > void on_process(T const&); void on_process_dynamic(base_event const& base) { base->some_virtual(); // or m_events[base->id].some_non_virtual(); } My only point was that with a little bit of help from the library, implementing dynamic/defferred event processing should be possible. Chris
Chris Knight wrote:
On Wednesday 06 August 2008 12:03:27 pm Andrey Semashev wrote:
I don't see the connection between rtti/virtuals and event deferring. Anyway, in case of Boost.FSM virtual functions are only used for enter state handlers in case of run-time version of state switching. Type info is used for convenience only - it provides default state names and diagnostic information in case of exceptions.
template< typename T > void on_process(T const&);
void on_process_dynamic(base_event const& base) { base->some_virtual(); // or m_events[base->id].some_non_virtual(); }
My only point was that with a little bit of help from the library, implementing dynamic/defferred event processing should be possible.
Sorry, I still don't get it. You already can pass events with virtual functions and process them through base classes. The main problem with deferred events is that there's nobody to call process(deferred_event) of the FSM. Another problem is that you generally don't know the complete FSM type in states or transitions, but this issue is solvable with a change in the state and transition base classes. Could you elaborate your point, please?
On Wednesday 06 August 2008 1:18:33 pm Andrey Semashev wrote:
Chris Knight wrote:
template< typename T > void on_process(T const&);
void on_process_dynamic(base_event const& base) { base->some_virtual(); // or m_events[base->id].some_non_virtual(); }
My only point was that with a little bit of help from the library, implementing dynamic/defferred event processing should be possible.
Sorry, I still don't get it. You already can pass events with virtual functions and process them through base classes. The main problem with deferred events is that there's nobody to call process(deferred_event) of the FSM. Another problem is that you generally don't know the complete FSM type in states or transitions, but this issue is solvable with a change in the state and transition base classes.
Could you elaborate your point, please?
I think you basically have it. I agree that the deferred event processing while (events_to_process) { fsm.process_dynamic(event); } shouldn't be included in boost.FSM, the process_dynamic(event_c& const) function should be. Using the TagV in the event_c class, it should be possible to provide a member function in state_machine to process events given only a reference to the event_c base class and that calls the appropriate process(event& const) via dispatching on the integer TagV. I'm trying to figure out whether this would be a simple feature addition or there is some critical piece I am missing. Chris
Chris Knight wrote:
On Wednesday 06 August 2008 1:18:33 pm Andrey Semashev wrote:
Sorry, I still don't get it. You already can pass events with virtual functions and process them through base classes. The main problem with deferred events is that there's nobody to call process(deferred_event) of the FSM. Another problem is that you generally don't know the complete FSM type in states or transitions, but this issue is solvable with a change in the state and transition base classes.
Could you elaborate your point, please?
I think you basically have it. I agree that the deferred event processing while (events_to_process) { fsm.process_dynamic(event); } shouldn't be included in boost.FSM, the process_dynamic(event_c& const) function should be.
Using the TagV in the event_c class, it should be possible to provide a member function in state_machine to process events given only a reference to the event_c base class and that calls the appropriate process(event& const) via dispatching on the integer TagV.
I see. However, tags are not a good candidate to dispatch events on since different events can have same tags. I think, the event itself should contain enough information to be dispatched after being postponed. BTW, you can achieve the same functionality right now if you bind the event to the process function of the FSM and save the call into boost::function.
I'm trying to figure out whether this would be a simple feature addition or there is some critical piece I am missing.
I think, this would be an interesting feature to add in future releases. I won't be able to implement it before the review. State and transition base classes will have to be extended, in order to allow to postpone events. State machine and event classes will have to be modified too.
On Thursday 07 August 2008 10:58:21 am Andrey Semashev wrote:
I see. However, tags are not a good candidate to dispatch events on since different events can have same tags. I think, the event itself should contain enough information to be dispatched after being postponed.
BTW, you can achieve the same functionality right now if you bind the event to the process function of the FSM and save the call into boost::function.
I never thought of that one. Maybe a little mention in the Documentation would be good. I imagine other potential users might want to do the same.
I think, this would be an interesting feature to add in future releases. I won't be able to implement it before the review. State and transition base classes will have to be extended, in order to allow to postpone events. State machine and event classes will have to be modified too.
Yeah, something like EventID and TransactionID in each event and transaction would be nice along with I imagine a deferred_state_machine and a deferred_lock_state_machine Thanks, Chris
On Thursday 07 August 2008 20:14:32 Chris Knight wrote:
On Thursday 07 August 2008 10:58:21 am Andrey Semashev wrote:
I see. However, tags are not a good candidate to dispatch events on since different events can have same tags. I think, the event itself should contain enough information to be dispatched after being postponed.
BTW, you can achieve the same functionality right now if you bind the event to the process function of the FSM and save the call into boost::function.
I never thought of that one. Maybe a little mention in the Documentation would be good. I imagine other potential users might want to do the same.
Ok, I will.
After a little more thought, I believe I can explain what the semantics might be. The following is the state machine for the finance exchange protocol. You will notice the "selfSyncWait" and "peerSyncWait" states. These states exist only to express the further restriction of matching events while protocol level message syncing is executed immediately following session authentication. Syntactic sugar to more cleanly express that sort of "synthetic" state would be nice. Instead of giving the states names, they would simply be expressed as anonymous sub-states within the layout of the transition table. typedef boost::mpl::list25< transition<any, events::MessageRecv, disconnected, &Machine::handle_message_unexpected>, transition<any, events::SessionRejectRecv, disconnected, &Machine::handle_session_reject>, transition<any, events::SeqNumLow, disconnected, &Machine::handle_seqnum_low>, transition<any, events::SeqNumHigh, disconnected, &Machine::handle_seqnum_high>, transition<any, events::LogoutRecv, disconnected, &Machine::handle_logout_unexpected>, transition<any, events::LogoutSend, logoutSent, &Machine::handle_logout_initiate>, transition<any, events::TimeoutSend, disconnected, &Machine::handle_timeout_send>, transition<any, events::TimeoutRecv, disconnected, &Machine::handle_timeout_recv>, transition<any, events::ErrorRecv, disconnected, &Machine::handle_error_recv>, transition<any, events::ErrorSend, disconnected, &Machine::handle_error_send>, transition<any, events::ErrorHandle, disconnected, &Machine::handle_error_handle>, transition<active, events::MessageRecv, active, &Machine::handle_message_recv>, transition<active, events::MessageSend, active, &Machine::handle_message_send>, transition<active, events::SessionRejectRecv, active, &Machine::handle_session_reject>, transition<active, events::TimeoutSend, active, &Machine::handle_heartbeat_send>, transition<active, events::LogoutRecv, disconnecting, &Machine::handle_logout_accept>, transition<connected, events::LogonSend, logonSent, &Machine::handle_logon_initiate>, transition<accepted, events::LogonRecv, logonAckWait, &Machine::handle_logon_accept>, transition<logonSent, events::LogonRecv, peerSyncWait, &Machine::handle_logon_reply>, transition<logonAckWait, events::LogonAck, peerSyncWait, &Machine::handle_logon_ack>, transition<logonAckWait, events::LogonNack, disconnected, &Machine::handle_logon_nack>, transition<logoutSent, events::LogoutRecv, disconnected, &Machine::handle_logout_complete>, transition<peerSyncWait, events::MessageRecv, active, &Machine::handle_logon_peerSyncing>, transition<peerSyncWait, events::SeqNumHigh, selfSyncWait, &Machine::handle_seqnum_gap>, transition<selfSyncWait, events::MessageRecv, active, &Machine::handle_logon_selfSyncing> >::type transition_table; Chris
David Abrahams wrote:
on Tue Aug 05 2008, Chris Knight <cknite-AT-gmail.com> wrote:
Andrey Semashev wrote:
Jurko Gospodnetić wrote:
What are the intended and actual differences from the already accepted Statechart library? The main differences are simplicity and performance. The performance tests show difference by an order of magnitude, in the best case for Boost.Statechart. The overall design of Boost.FSM is geared more to compile-time code generation, while Boost.Statechart aims to support more scaled machines and therefore is geared towards run-time. There is a section in the docs that compares the libraries. I can attest to the necessity of this. We have several exchange libraries that require state machines to implement their data protocols but we use a home-brewed boost::mpl::inherit_linearly implementation because the features of Boost.StateChart simply brings in to many performance penalties for our simpler usage that would fit within the Boost.FSM framework. In fact, if I remember correctly, we used a thing on Boost.Vault called "FSM" as an implementation guide.
I don't know if you've seen the FSM examples from "C++ Template Metaprogramming" or not. It would be interesting for this library's documentation to explain its advantages over that approach (I can see some from here already).
No, I don't have that book.
One other thing I'd like to see is an implementation of nested states. I once promised some people who needed that functionality that I'd extend our framework to support them, but was never able to figure out what their semantics are ;-)
I thought about nested states, but, the way I understand it, there are no advantages of nested states over nested state machines. Obviously, you can define as much FSMs as you like and nest them within states as you need.
Andrey Semashev wrote:
I thought about nested states, but, the way I understand it, there are no advantages of nested states over nested state machines. Obviously, you can define as much FSMs as you like and nest them within states as you need. _______________________________________________
Perhaps I don't understand your use of nesting FSMs within a state yet. "Nested states" or hierarchical state machines can provide extremely powerful semantics such as return-to-history. -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
Michael Caisse wrote:
Andrey Semashev wrote:
I thought about nested states, but, the way I understand it, there are no advantages of nested states over nested state machines. Obviously, you can define as much FSMs as you like and nest them within states as you need. _______________________________________________
Perhaps I don't understand your use of nesting FSMs within a state yet. "Nested states" or hierarchical state machines can provide extremely powerful semantics such as return-to-history.
Maybe I just misunderstand what you mean by "nested states". I understand it as a more detailed description of the machine condition. For example, we have electronic watches that show either current date or current time and while showing time the colon between hours and minutes is blinking. The top level states could be showing_date and showing_time, and showing_time could have nested states with_colon and without_colon. If this is what you call "nested states", then the approach is similar to having a separate FSM with states with_colon and without_colon within the showing_time state.
on Tue Aug 05 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
David Abrahams wrote:
on Tue Aug 05 2008, Chris Knight <cknite-AT-gmail.com> wrote:
Jurko Gospodnetić wrote:
What are the intended and actual differences from the already accepted Statechart library? The main differences are simplicity and performance. The performance tests show difference by an order of magnitude, in the best case for Boost.Statechart. The overall design of Boost.FSM is geared more to compile-time code generation, while Boost.Statechart aims to support more scaled machines and therefore is geared towards run-time. There is a section in the docs that compares the libraries. I can attest to the necessity of this. We have several exchange libraries that require state machines to implement their data protocols but we use a home-brewed boost::mpl::inherit_linearly implementation because
Andrey Semashev wrote: the features of Boost.StateChart simply brings in to many performance penalties for our simpler usage that would fit within the Boost.FSM framework. In fact, if I remember correctly, we used a thing on Boost.Vault called "FSM" as an implementation guide.
I don't know if you've seen the FSM examples from "C++ Template Metaprogramming" or not. It would be interesting for this library's documentation to explain its advantages over that approach (I can see some from here already).
No, I don't have that book.
For your perusal: http://www.boostpro.com/mplbook/examples/player.cpp http://www.boostpro.com/mplbook/examples/player2.cpp -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Tue Aug 05 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
David Abrahams wrote:
on Tue Aug 05 2008, Chris Knight <cknite-AT-gmail.com> wrote: I don't know if you've seen the FSM examples from "C++ Template Metaprogramming" or not. It would be interesting for this library's documentation to explain its advantages over that approach (I can see some from here already). No, I don't have that book.
For your perusal:
http://www.boostpro.com/mplbook/examples/player.cpp http://www.boostpro.com/mplbook/examples/player2.cpp
Thanks for the info. I guess I'm not the first one who came up with such approach. :) My implementation has similarities to player2.cpp, however, there are significant advantages in Boost.FSM. - The library does not take addresses of user's functions, which allows to use templates and simplifies overloading. - States are not an enum values but classes that may have a common virtual base, which allows to have state-specific and shared data in the FSM. The events are processed in states. - States support enter and leave handlers. There is also a reset method that allows to clear the states and silently transit to the initial state. - Other minor things, like auto-generated state names, dynamic handler for unsupported events, thread-safety issues, etc. I'd love to put a full comparison to the library documentation, but I feel this would be not... fair (for the lack of a better word) since I didn't read the book and only seen a couple of examples.
on Fri Aug 08 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
David Abrahams wrote:
on Tue Aug 05 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
David Abrahams wrote:
on Tue Aug 05 2008, Chris Knight <cknite-AT-gmail.com> wrote: I don't know if you've seen the FSM examples from "C++ Template Metaprogramming" or not. It would be interesting for this library's documentation to explain its advantages over that approach (I can see some from here already). No, I don't have that book.
For your perusal:
http://www.boostpro.com/mplbook/examples/player.cpp http://www.boostpro.com/mplbook/examples/player2.cpp
Thanks for the info. I guess I'm not the first one who came up with such approach. :)
My implementation has similarities to player2.cpp, however, there are significant advantages in Boost.FSM. - The library does not take addresses of user's functions, which allows to use templates and simplifies overloading.
Huh? The member function pointers involved in our code are all compile-time constants, and thus work very well with templates (in fact, they are passed as template arguments).
- States are not an enum values but classes that may have a common virtual base, which allows to have state-specific and shared data in the FSM. The events are processed in states.
I'm not sure that isn't overkill. In our implementation you are free to add any data you like to the FSM and use it in your transition (member) functions.
- States support enter and leave handlers. There is also a reset method that allows to clear the states and silently transit to the initial state.
Yeah, that's a real advantage.
- Other minor things, like auto-generated state names, dynamic handler for unsupported events,
Our design lets you make the handler static or dynamic as you please.
thread-safety issues, etc.
Not sure what issues you have in mind.
I'd love to put a full comparison to the library documentation, but I feel this would be not... fair (for the lack of a better word) since I didn't read the book and only seen a couple of examples.
What you're seeing is a little more than everything the book does with FSMs, so I think it would be fair. More importantly, it would supply people familiar with the book with a useful frame of reference. Since the book's example was never meant to be more than a (very usable) toy for demonstrating some principles of DSLs, I wouldn't worry about trying to "be fair." -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Fri Aug 08 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
David Abrahams wrote:
on Tue Aug 05 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
David Abrahams wrote:
on Tue Aug 05 2008, Chris Knight <cknite-AT-gmail.com> wrote: I don't know if you've seen the FSM examples from "C++ Template Metaprogramming" or not. It would be interesting for this library's documentation to explain its advantages over that approach (I can see some from here already). No, I don't have that book. For your perusal:
http://www.boostpro.com/mplbook/examples/player.cpp http://www.boostpro.com/mplbook/examples/player2.cpp Thanks for the info. I guess I'm not the first one who came up with such approach. :)
My implementation has similarities to player2.cpp, however, there are significant advantages in Boost.FSM. - The library does not take addresses of user's functions, which allows to use templates and simplifies overloading.
Huh? The member function pointers involved in our code are all compile-time constants,
No, they are stored into the dispatching map array and thus there is no benefit in passing them as template arguments.
and thus work very well with templates (in fact, they are passed as template arguments).
I mean, I can make an event handler a template. Or overload it. This allows to process a subset of events in a similar manner. Another application is event layering, like this: class my_state : public fsm::state< ... > { // UI-related events processing // The event is received when the main window is closed void on_process(ui< main_wnd_closed > const& evt); // Other user-interface related events go here template< typename T > void on_process(ui< T > const& evt); // Network related event processing template< typename T > void on_process(net< T > const& evt); }; The same can be done with transitions. Sure, this can also be done in your approach, too, but you'll have to explicitly state template arguments, which I find rather inconvenient.
- States are not an enum values but classes that may have a common virtual base, which allows to have state-specific and shared data in the FSM. The events are processed in states.
I'm not sure that isn't overkill. In our implementation you are free to add any data you like to the FSM and use it in your transition (member) functions.
Your approach doesn't allow to separate state-specific data from the common data. Besides, using classes for states allows to define base classes with default event handlers and data, which can be reused in more than one state.
- Other minor things, like auto-generated state names, dynamic handler for unsupported events,
Our design lets you make the handler static or dynamic as you please.
Right, I didn't notice you could override the no_transition handler.
thread-safety issues, etc.
Not sure what issues you have in mind.
Your implementation uses global dispatching table, which is non-POD and therefore is not thread-safe. The proposed library solves this and additionally provides a locking state machine class.
I'd love to put a full comparison to the library documentation, but I feel this would be not... fair (for the lack of a better word) since I didn't read the book and only seen a couple of examples.
What you're seeing is a little more than everything the book does with FSMs, so I think it would be fair. More importantly, it would supply people familiar with the book with a useful frame of reference. Since the book's example was never meant to be more than a (very usable) toy for demonstrating some principles of DSLs, I wouldn't worry about trying to "be fair."
Ok, then I'll add a new "Boost.FSM vs. ..." section. May I put the links you posted in the docs?
on Mon Aug 11 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
David Abrahams wrote:
on Fri Aug 08 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
David Abrahams wrote:
on Tue Aug 05 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
David Abrahams wrote:
on Tue Aug 05 2008, Chris Knight <cknite-AT-gmail.com> wrote: I don't know if you've seen the FSM examples from "C++ Template Metaprogramming" or not. It would be interesting for this library's documentation to explain its advantages over that approach (I can see some from here already). No, I don't have that book. For your perusal:
http://www.boostpro.com/mplbook/examples/player.cpp http://www.boostpro.com/mplbook/examples/player2.cpp Thanks for the info. I guess I'm not the first one who came up with such approach. :)
My implementation has similarities to player2.cpp, however, there are significant advantages in Boost.FSM. - The library does not take addresses of user's functions, which allows to use templates and simplifies overloading.
Huh? The member function pointers involved in our code are all compile-time constants,
No, they are stored into the dispatching map array and thus there is no benefit in passing them as template arguments.
Oh, I wasn't talking about player2.cpp. It's just a proof-of-concept to show that you can change the dispatching logic to use O(1) lookup.
and thus work very well with templates (in fact, they are passed as template arguments).
I mean, I can make an event handler a template. Or overload it. This allows to process a subset of events in a similar manner. Another application is event layering, like this:
class my_state : public fsm::state< ... > { // UI-related events processing // The event is received when the main window is closed void on_process(ui< main_wnd_closed > const& evt); // Other user-interface related events go here template< typename T > void on_process(ui< T > const& evt);
// Network related event processing template< typename T > void on_process(net< T > const& evt); };
The same can be done with transitions. Sure, this can also be done in your approach, too, but you'll have to explicitly state template arguments, which I find rather inconvenient.
OK.
- States are not an enum values but classes that may have a common virtual base, which allows to have state-specific and shared data in the FSM. The events are processed in states.
I'm not sure that isn't overkill. In our implementation you are free to add any data you like to the FSM and use it in your transition (member) functions.
Your approach doesn't allow to separate state-specific data from the common data.
Yes, but in your approach the common data can't persist across state transitions. Is that not a serious limitation?
Besides, using classes for states allows to define base classes with default event handlers and data, which can be reused in more than one state.
- Other minor things, like auto-generated state names, dynamic handler for unsupported events,
Our design lets you make the handler static or dynamic as you please.
Right, I didn't notice you could override the no_transition handler.
It's actually a replacement.
thread-safety issues, etc.
Not sure what issues you have in mind.
Your implementation uses global dispatching table, which is non-POD and therefore is not thread-safe.
The table is constant once it's been initialized. Regardless, if you're worried about thread safety during startup you again shouldn't look at player2.cpp.
The proposed library solves this and additionally provides a locking state machine class.
I'd love to put a full comparison to the library documentation, but I feel this would be not... fair (for the lack of a better word) since I didn't read the book and only seen a couple of examples.
What you're seeing is a little more than everything the book does with FSMs, so I think it would be fair. More importantly, it would supply people familiar with the book with a useful frame of reference. Since the book's example was never meant to be more than a (very usable) toy for demonstrating some principles of DSLs, I wouldn't worry about trying to "be fair."
Ok, then I'll add a new "Boost.FSM vs. ..." section. May I put the links you posted in the docs?
Sure thing. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
- States are not an enum values but classes that may have a common virtual base, which allows to have state-specific and shared data in the FSM. The events are processed in states. I'm not sure that isn't overkill. In our implementation you are free to add any data you like to the FSM and use it in your transition (member) functions. Your approach doesn't allow to separate state-specific data from the common data.
Yes, but in your approach the common data can't persist across state transitions. Is that not a serious limitation?
Why? It does persist as long as the FSM persists. All states and their base classes are constructed and destroyed with the FSM and never in the middle.
on Mon Aug 11 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
David Abrahams wrote:
- States are not an enum values but classes that may have a common virtual base, which allows to have state-specific and shared data in the FSM. The events are processed in states. I'm not sure that isn't overkill. In our implementation you are free to add any data you like to the FSM and use it in your transition (member) functions.
Your approach doesn't allow to separate state-specific data from the common data.
Yes, but in your approach the common data can't persist across state transitions. Is that not a serious limitation?
Why? It does persist as long as the FSM persists. All states and their base classes are constructed and destroyed with the FSM and never in the middle.
I'm confused. If states 1 and 2 have associated data of types A and B, the fact that A and B are both derived from C does not mean that there is only one copy of the base class... or are you doing something special to have states 1 and 2 share a single object of type D derived from A and B? [Please keep in mind that I'm not trying to say that the Book's FSM is better than the one in your library. It's clearly more limited.] -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Mon Aug 11 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
David Abrahams wrote:
- States are not an enum values but classes that may have a common virtual base, which allows to have state-specific and shared data in the FSM. The events are processed in states. I'm not sure that isn't overkill. In our implementation you are free to add any data you like to the FSM and use it in your transition (member) functions. Your approach doesn't allow to separate state-specific data from the common data. Yes, but in your approach the common data can't persist across state transitions. Is that not a serious limitation? Why? It does persist as long as the FSM persists. All states and their base classes are constructed and destroyed with the FSM and never in the middle.
I'm confused. If states 1 and 2 have associated data of types A and B, the fact that A and B are both derived from C does not mean that there is only one copy of the base class... or are you doing something special to have states 1 and 2 share a single object of type D derived from A and B?
That's right, the library constructs a composite class that derives from all states. This allows states to virtually derive from a common base and share its data between each other. This composite class is a part of the complete FSM, so all states live as long as the FSM does. Switching between states only calls enter/leave handlers in the states, which can be used to initialize or clean the data in the state.
[Please keep in mind that I'm not trying to say that the Book's FSM is better than the one in your library. It's clearly more limited.]
Yes, I understand that it's merely an example for the book.
Is there any difference between the book and the sample described at: http://www.boost.org/doc/libs/1_35_0/libs/mpl/doc/paper/mpl_paper.pdf David Abrahams-3 wrote:
I'm confused. If states 1 and 2 have associated data of types A and B, the fact that A and B are both derived from C does not mean that there is only one copy of the base class... or are you doing something special to have states 1 and 2 share a single object of type D derived from A and B?
[Please keep in mind that I'm not trying to say that the Book's FSM is better than the one in your library. It's clearly more limited.]
-- Dave Abrahams BoostPro Computing http://www.boostpro.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- View this message in context: http://www.nabble.com/FSM-Review-Announcement-tp18820219p18984305.html Sent from the Boost - Dev mailing list archive at Nabble.com.
On Thu, 14 Aug 2008 08:48:08 -0700 (PDT), Henrik Vallgren <henrik.vallgren@streamspace.com> wrote:
Is there any difference between the book and the sample described at:
http://www.boost.org/doc/libs/1_35_0/libs/mpl/doc/paper/mpl_paper.pdf
Yes, there's some difference. I linked to a copy of the code we discuss in the book earlier in this thread. -- David Abrahams Boostpro Computing http://www.boostpro.com
Hi Andrey, I thought I'd clarify a couple of points below. On Fri, 08 Aug 2008 11:55:30 -0500, Andrey Semashev <andrey.semashev@gmail.com> wrote:
My implementation has similarities to player2.cpp, however, there are significant advantages in Boost.FSM. - The library does not take addresses of user's functions, which allows to use templates and simplifies overloading. - States are not an enum values but classes that may have a common virtual base, which allows to have state-specific and shared data in the FSM.
Enum- vs. class-based states *per se* is a relatively minor aspect of the MPL's FSM example. You can have it either way [1]. In fact, earlier version of the example does use (non-polymorphic) classes to represent states: http://svn.boost.org/trac/boost/browser/trunk/libs/mpl/example/fsm/player.cp... Our derivative version here at work allows for state-specific data.
The events are processed in states.
This one, however, is IMHO the biggest difference between the approaches.
- States support enter and leave handlers.
Along with other niceties such as state invariants, this comes for free once you decide to go with the class-based states (the version we use at work has these as well).
There is also a reset method that allows to clear the states and silently transit to the initial state.
[1] Obviously, class-based states have a higher runtime overhead. -- Aleksey Gurtovoy MetaCommunications Engineering
On 05 Aug 2008, you wrote in gmane.comp.lib.boost.devel:
Jurko Gospodnetić wrote:
What are the intended and actual differences from the already accepted Statechart library?
The main differences are simplicity and performance. The performance tests show difference by an order of magnitude, in the best case for Boost.Statechart. The overall design of Boost.FSM is geared more to compile-time code generation, while Boost.Statechart aims to support more scaled machines and therefore is geared towards run-time. There is a section in the docs that compares the libraries. I can attest to the necessity of this. We have several exchange
Andrey Semashev wrote: libraries that require state machines to implement their data protocols but we use a home-brewed boost::mpl::inherit_linearly implementation because the features of Boost.StateChart simply brings in to many performance penalties for our simpler usage that would fit within the Boost.FSM framework. In fact, if I remember correctly, we used a thing on Boost.Vault called "FSM" as an implementation guide.
Hi Chris, I am the review manager for the proposed FSM library, and I was wondering whether you might have time to submit a more comprehensive review? The review period runs until the 20th, but if you need more time it might be possible to extend the review. MV
Hello,
Hi Martin.
The formal review for Andrey Semashev's Finite State Machines (FSM) library is scheduled for August 11th to 20th.
What are the intended and actual differences from the already accepted Statechart library?
The main differences are simplicity and performance. The performance tests show difference by an order of magnitude, in the best case for Boost.Statechart. The overall design of Boost.FSM is geared more to compile-time code generation, while Boost.Statechart aims to support more scaled machines and therefore is geared towards run-time. There is a section in the docs that compares the libraries.
Is it correct that Boost.FSM can not defer an events (I didn't found a statement in the docs)? That means in yout tutorial the state Processing consumes the event passed to template< typename T > void on_process(T const&)? If so - how Boost.FSM supports you if the order of passed events are not predictable? Oliver
Kowalke Oliver (QD IT PA SI) wrote:
Hello,
Hi Martin.
The formal review for Andrey Semashev's Finite State Machines (FSM) library is scheduled for August 11th to 20th. What are the intended and actual differences from the already accepted Statechart library? The main differences are simplicity and performance. The performance tests show difference by an order of magnitude, in the best case for Boost.Statechart. The overall design of Boost.FSM is geared more to compile-time code generation, while Boost.Statechart aims to support more scaled machines and therefore is geared towards run-time. There is a section in the docs that compares the libraries.
Is it correct that Boost.FSM can not defer an events (I didn't found a statement in the docs)?
Yes, this feature is not supported.
That means in yout tutorial the state Processing consumes the event passed to template< typename T > void on_process(T const&)?
Right.
If so - how Boost.FSM supports you if the order of passed events are not predictable?
The library itself does not mandate the order of events and I am convinced that this is the right thing. The events are passed to the machine implementation (i.e. states and transitions) in the order they are received. It is up to the implementation to support (or not support) a particular order of the events. The solutions for event deferring may be very different and involve other libraries (such as Boost.Thread, for example), depending on the desired effects. In fact, it is a new library of event dispatching that you want. I consider it out of the Boost.FSM scope. PS: I was thinking about implementing such a library as a separate submission, but I'm too short in time.
Martin Vuille <martin <at> jpmvrealtime.com> writes:
The formal review for Andrey Semashev's Finite State Machines (FSM) library is scheduled for August 11th to 20th.
... and again (!) this is not announced on the main web page where it should, so I nearly missed that one again. Could you please trigger an update of the webpage news section? I have a proposal: Mails to *.boost.announce should automatically be reflected on the web page news section, so the review manager is released from this burden. Or better: After login to www.boost.org the review manager fills in a web form for the announcement, which is then sent to the ML _AND_ brought to the frontpage news at the same time. Markus
Markus Werle <numerical.simulation@web.de> wrote in news:loom.20080806T131306-688@post.gmane.org:
Could you please trigger an update of the webpage news section?
I have a proposal: Mails to *.boost.announce should automatically be reflected on the web page news section, so the review manager is released from this burden.
Or better: After login to www.boost.org the review manager fills in a web form for the announcement, which is then sent to the ML _AND_ brought to the frontpage news at the same time.
I admit that I did not think about updating the news, but there also doesn't seem to be any concensus on what review-related events are newsworthy. All events (announcement, reminder, start, end, etc.) or just start and end, or ??? MV
Markus Werle <numerical.simulation@web.de> wrote in news:loom.20080806T131306-688@post.gmane.org:
Martin Vuille <martin <at> jpmvrealtime.com> writes:
The formal review for Andrey Semashev's Finite State Machines (FSM) library is scheduled for August 11th to 20th.
... and again (!) this is not announced on the main web page where it should, so I nearly missed that one again.
Could you please trigger an update of the webpage news section?
I have a proposal: Mails to *.boost.announce should automatically be reflected on the web page news section, so the review manager is released from this burden.
Or better: After login to www.boost.org the review manager fills in a web form for the announcement, which is then sent to the ML _AND_ brought to the frontpage news at the same time.
I would like to understand how the News and Recent Announcements sections of the website's front page are intended to be used. Are they supposed to be updated automatically through some means, or manually? What is the difference between News and Recent Announcements? Should review- related matters be posted in the News, the Recent Announcements, or both? To my mind, it would make the most sense to keep the News focused on major events of interest to Boost users (e.g., new releases), while the Recent Announcements can (as they seem intended to) reflect postings to the boost- announce mailing list. MV
Martin Vuille wrote:
Markus Werle <numerical.simulation@web.de> wrote in news:loom.20080806T131306-688@post.gmane.org:
Martin Vuille <martin <at> jpmvrealtime.com> writes:
The formal review for Andrey Semashev's Finite State Machines (FSM) library is scheduled for August 11th to 20th. ... and again (!) this is not announced on the main web page where it should, so I nearly missed that one again.
Could you please trigger an update of the webpage news section?
I have a proposal: Mails to *.boost.announce should automatically be reflected on the web page news section, so the review manager is released from this burden.
Or better: After login to www.boost.org the review manager fills in a web form for the announcement, which is then sent to the ML _AND_ brought to the frontpage news at the same time.
I would like to understand how the News and Recent Announcements sections of the website's front page are intended to be used. Are they supposed to be updated automatically through some means, or manually?
Technically, the news section reflects a combination of the news feeds <http://svn.boost.org/trac/boost/browser/website/public_html/live/feed>. Which are "hand" edited as is deemed appropriate by any Boost developer. But really is only touched by the release team, moderators, and review manager. And the "Recent Announcements" is a direct reflection of the messages posted to the Boost announce list. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Rene Rivera <grafikrobot@gmail.com> wrote in news:489B0BAA.9090909@gmail.com:
Technically, the news section reflects a combination of the news feeds <http://svn.boost.org/trac/boost/browser/website/public_html/live /feed>. Which are "hand" edited as is deemed appropriate by any Boost developer. But really is only touched by the release team, moderators, and review manager. And the "Recent Announcements" is a direct reflection of the messages posted to the Boost announce list.
I see that the Recent Announcements heading links to the posts from boost-announce, but is the list of recent announcements below the heading supposed to be updated automatically, or does it have to be updated manually as well? MV
Martin Vuille wrote:
Rene Rivera <grafikrobot@gmail.com> wrote in news:489B0BAA.9090909@gmail.com:
Technically, the news section reflects a combination of the news feeds <http://svn.boost.org/trac/boost/browser/website/public_html/live /feed>. Which are "hand" edited as is deemed appropriate by any Boost developer. But really is only touched by the release team, moderators, and review manager. And the "Recent Announcements" is a direct reflection of the messages posted to the Boost announce list.
I see that the Recent Announcements heading links to the posts from boost-announce, but is the list of recent announcements below the heading supposed to be updated automatically, or does it have to be updated manually as well?
It's automatic, as in there's a cronjob on the web server that reflects the list content periodically. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Rene Rivera <grafikrobot@gmail.com> wrote in news:489B1389.1070409@gmail.com:
I see that the Recent Announcements heading links to the posts from boost-announce, but is the list of recent announcements below the heading supposed to be updated automatically, or does it have to be updated manually as well?
It's automatic, as in there's a cronjob on the web server that reflects the list content periodically.
OK, thanks. How often does the cron job run? I posted a review announcement on boost-announce late on Monday, it showed up on the list on Tuesday, but was not reflected on the front page until this morning (or maybe late last night). MV
Rene Rivera <grafikrobot@gmail.com> wrote in news:489B0BAA.9090909@gmail.com:
Technically, the news section reflects a combination of the news feeds <http://svn.boost.org/trac/boost/browser/website/public_html/live /feed>. Which are "hand" edited as is deemed appropriate by any Boost developer. But really is only touched by the release team, moderators, and review manager. And the "Recent Announcements" is a direct reflection of the messages posted to the Boost announce list.
So, for example, I would create a new .qbk file in the news subdirectory and the scripts would take care of updating the RSS feed and the website front page? Are the scripts run automatically, or do I need to run them myself to perform the updates? Is this all described somewhere that I should be reading? MV
participants (15)
-
Aleksey Gurtovoy -
Andrey Semashev -
Chris Knight -
David Abrahams -
Eric Niebler -
Frank Mori Hess -
Giovanni Piero Deretta -
Henrik Vallgren -
Jeremy Pack -
Jurko Gospodnetić -
Kowalke Oliver (QD IT PA SI) -
Markus Werle -
Martin Vuille -
Michael Caisse -
Rene Rivera