June 2010 - Boost - lists.preview.boost.org

Re: [boost] [msm] Nested submachines and explicit state entry
by Michael.Herchel＠rohde-schwarz.com 10 Jun '10

10 Jun '10

Hi Christophe, >>> There are several reasons to this and it took me a while to figure out >>> what was happening. >>> The first one is that there are 2 errors in the example: >>> RunningStateMachine::Inner1::direct<RunningStateMachine_::Inner1_> should be: >>> RunningStateMachine::direct<RunningStateMachine_::Inner1> >>> >>> As you are directly entering RunningStateMachine, not Inner1. >> >>actually I have made 2 mistakes :). One above the second is that I used Inner1_ >>which is a frontend instead of Inner1 caused that the on initial transition >>is getting triggered after entry of Inner1 >Ah yes I forgot that I corrected that one too. Could you please also correct the documentation regarding explicit entry. In the documentation you explicitly say that you have to pass the front end, which is wrong according to you. MSM Documentation (section: Explicit Entry): --------------------------------------------- You can then use it as target in a transition with State1 as source: _row < State1, Event2, SubFsm2::direct< SubFsm2_::SubState2> > The syntax deserves some explanation. SubFsm2_ is a front end. SubState2 is a nested state, therefore the SubFsm2_::SubState2 syntax. The containing machine (containing State1 and SubFsm2) refers to the backend instance (SubFsm2). SubFsm2::direct states that an explicit entry is desired. --------------------------------------------- So I think the code snippet has to look like as follows (SubFsm2 instead of SubFsm2_): _row < State1, Event2, SubFsm2::direct< SubFsm2::SubState2> > Regards, Michael

1 0

[msm] Choosing initial event in sub machines
by Michael.Herchel＠rohde-schwarz.com 10 Jun '10

10 Jun '10

Hi Christophe, >> Actually, this is exactly the behaviour what we want > I'm not sure I get. You'd want the submachine to use its own initial > event and receive this one instead of the containing machine's? It's > probably possible but I'm wondering what could be a use case for this. > Could you please elaborate? No, sorry for the confusion. The implemented msm behaviour is the one we want. So there is no need for a change in the msm code ;). Maybe it would be good to describe it in the documentation. Regards, Michael

1 0

Re: [boost] [msm] Nested submachines and explicit state entry
by Christophe Henry 10 Jun '10

10 Jun '10

>> There are several reasons to this and it took me a while to figure out >> what was happening. >> The first one is that there are 2 errors in the example: >> RunningStateMachine::Inner1::direct<RunningStateMachine_::Inner1_> should be: >> RunningStateMachine::direct<RunningStateMachine_::Inner1> >> >> As you are directly entering RunningStateMachine, not Inner1. > >actually I have made 2 mistakes :). One above the second is that I used Inner1_ >which is a frontend instead of Inner1 caused that the on initial transition >is getting triggered after entry of Inner1 Ah yes I forgot that I corrected that one too. >I found it even strange that it compiles when the frontend of and >inner state machine is used in the outer state machine transition >table. This surprises me a little because I tried with g++ 4.4 to replace in the corrected example Inner1 by Inner1_ in SM1's table and the compiler correctly complained. What did you do?

2 1

[msm] Choosing initial event in sub machines
by Christophe Henry 09 Jun '10

09 Jun '10

Hi Michael, > I just came along another question regarding state machines and sub > machines. > > With "typedef my_initial_event initial_event" it is possible to customize > the initial event. > This does not work for nested sub machines, because in those cases msm > just forwards the event that triggered the state change so that we end up > in the sub machines initial state. > Msm does not use the specified initial event of the sub machine to trigger > the initial state of the sub machine. Correct. This is actually the wanted behavior to respect the Liskov substitutability principle. It would be confusing if you replaced a substate by a submachine and get a different entry behavior. This means that the containing machine's initial event will get propagated to any substate or submachine marked as the initial. > Actually, this is exactly the behaviour what we want I'm not sure I get. You'd want the submachine to use its own initial event and receive this one instead of the containing machine's? It's probably possible but I'm wondering what could be a use case for this. Could you please elaborate? >but is it UML conform? > Do you have any idea? Neither is actually ;-) UML does not define the notion of an initial event. It was added into msm to allow a unique interface for entry behaviors (instead of one for "normal" entries and one for entry through an initial pseudo-state. All what UML defines is an initial pseudo-state which can have only one outgoing transition to a real state (making it the initial state). This cannot even be a real transition, it can have no event and no guard, only an action. So, as UML has no initial event and it is purely a msm construct, we are free to define it as we wish. I suppose we could allow the submachine to override the default behavior, but I would need to see at least one compelling use case before I punish compilers with some more metaprogramming ;-) Regards, Christophe

1 0

[serialization] Boost.DateTime tests failing
by Andrey Semashev 09 Jun '10

09 Jun '10

I see that a few tests of Boost.DateTime (see [1] for instance) are failing because Boost.Serialization fails to complile. It seems like revision 62546 caused this. Robert, will you take a look at it? [1] <http://www.boost.org/development/tests/trunk/developer/Sandia-darwin-4-0-1-…>

2 1

Re: [boost] [fusion] conflict with mpl
by Christophe Henry 09 Jun '10

09 Jun '10

>> Hi, >> >> While looking at the trunk test results for MSM, I realized (with a >> shock) that many test cases were not working with g++ any more. The >> reason is listed in (read the last few lines): >> http://www.boost.org/development/tests/trunk/developer/output/minion-clang-… >> >> It appears there is a conflict between mpl and fusion for at. >> Editing boost/fusion/container/set/detail/deref_impl.hpp from >> return at<typename It::index>(it.seq->get_data()); >> >> to >> return ::boost::fusion::at<typename It::index>(it.seq->get_data()); >> >> Seems to solve the problem in the small example I attached. >> >> This stuff is pretty urgent for me because it breaks a lot of msm tests. >> How to proceed? The Monday deadline is looming ;-) > > Feel free to check in the fix, Christophe. Thanks! I just did.

1 0

Boost.Function comparisons
by David Abrahams 09 Jun '10

09 Jun '10

Hi, I know this has been a big issue in the distant past and I admit to being too lazy to pore through the old discussion history, but I was reading through the proposed C++0x standard and noticed there was no equality comparison for std::function, so I went to look at Boost. There I saw that boost::function<S> has meaningful equality comparisons with objects of the type stored in the function instance, but not with function<S> itself. And that struck me as very odd. It was clearly quite intentional, since such comparisons are intentionally “poisoned” to make sure nobody uses them. So can someone explain this to me? Whatever the rationale, I think it should be available in the documentation. Thanks, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 3

Bug sprint daily update for Wednesday, June 9th
by Marshall Clow 09 Jun '10

09 Jun '10

As of 0800 Pacific time today, we had 894 open trac tickets. That is down by 44 from yesterday, and 95 since the start of the bug sprint! This is great news!! Let's keep up the good work! Total ticket counts: Saturday 989 Sunday 988 Monday 958 Tuesday 938 Wednesday 894 Activity summary for yesterday (I'm counting tickets by hand here, here so blame my crummy math if it doesn't add up) New tickets: 14 Modified: 27 Closed: 59 Reopened: 1 If you're looking to help, and don't know what you can do, there are a whole lot of bugs in the database reported against old versions. You can regress these, see if they still exist, and close them if they do not. Here's a report that shows all open bugs reported against version 1.34.1 (which was released a long, long time ago). <https://svn.boost.org/trac/boost/query?status=assigned&status=new&status=re…> Today, rather than the summary totals for yesterday, I have deltas; changes in the totals. If you'ld like to see the totals, they are available online at: Open ticket count by owner: https://svn.boost.org/trac/boost/report/18 Open ticket count by component: https://svn.boost.org/trac/boost/report/19 Open ticket count by type https://svn.boost.org/trac/boost/report/20 (Overwhelmingly, these are 'bugs') Open ticket count by milestone: https://svn.boost.org/trac/boost/report/21 (All changes are since the start of the bug sprint; 0800 PDT Saturday June 5th) Changed totals by library: thread -27 None -17 website -10 iterator -6 concept_check-5 function -5 multi_array -5 asio -4 random -4 lambda -3 units -3 variant -3 fusion -2 mpl -2 Building Boost -1 GIL -1 Regression Testing -1 date_time -1 filesystem -1 io -1 lexical_cast -1 mpi -1 regex -1 spirit -1 trac / subversion -1 circular_buffer 1 config 1 program_options 1 property_tree 1 serialization 1 utility 1 xpressive 1 Documentation 2 build 4 Changed totals by author: anthonyw -26 <none> -19 dave -9 grafik -9 dgregor -7 no-maintainer -6 garcia -5 chris_kohlhoff -4 ebf -3 jsiek -3 agurtovoy -2 djowel -2 dlwalker -2 matthiasschabel -2 az_sw_dude -1 bemandawes -1 bschaeling -1 danieljames -1 hkaiser -1 hljin -1 nasonov -1 speedsnail -1 steven_watanabe -1 danielw 1 eric_niebler 1 jano_gaspar 1 jewillco 1 matias 1 ramey 1 witt 1 vladimir_prus 7 Changed totals by category: Bugs -71 Feature Requests -10 Patches -7 Tasks -3 Support Requests -2 Library Submissions -1 -- Marshall

1 0

[msm] Choosing initial event in sub machines
by Michael.Herchel＠rohde-schwarz.com 09 Jun '10

09 Jun '10

Hi, I just came along another question regarding state machines and sub machines. With "typedef my_initial_event initial_event" it is possible to customize the initial event. This does not work for nested sub machines, because in those cases msm just forwards the event that triggered the state change so that we end up in the sub machines initial state. Msm does not use the specified initial event of the sub machine to trigger the initial state of the sub machine. Actually, this is exactly the behaviour what we want but is it UML conform? Do you have any idea? Best Regards, Michael

1 0

[fusion] conflict with mpl
by Christophe Henry 09 Jun '10

09 Jun '10

Hi, While looking at the trunk test results for MSM, I realized (with a shock) that many test cases were not working with g++ any more. The reason is listed in (read the last few lines): http://www.boost.org/development/tests/trunk/developer/output/minion-clang-… It appears there is a conflict between mpl and fusion for at. Editing boost/fusion/container/set/detail/deref_impl.hpp from return at<typename It::index>(it.seq->get_data()); to return ::boost::fusion::at<typename It::index>(it.seq->get_data()); Seems to solve the problem in the small example I attached. This stuff is pretty urgent for me because it breaks a lot of msm tests. How to proceed? The Monday deadline is looming ;-) Thanks, Christophe

2 1