- Boost - lists.boost.org

[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

[endian] endian flip and endian domain
by vicente.botet 09 Jun '10

09 Jun '10

Hi, I think that I have found a good name that can be used instead of the swap_in_place: "flip". This recall the flip operation used in bitset exchanging the value of a bit. On the endian context this will exchange in place the endianess of a data from/to the native endianess. As the same data can be used with different endianess depending of the the context, the flip function needs a specific parameter, let me call this the endian domain. As the data to flip can containg part that are big and others that are little endian, we need to map all the leaveds of the tree associated to the data structure. The domain mill map staticaly the data to its endianess. For fundamental types this will be reduced to a single endian value, but for structures, the map will be a tree having as leaves endian types. This mapping allows us to separate the endian concern from the data itself in a clear way. For structures that have been adapted as fusion sequences, we can define flip_to/from functions that will do the the flip in a generic way. Of course the user could always overload the flips functions to provide its own implementation. I have started to play with this, and even if I'm not a metaprogramming expert, I have reached to have a prototype implementation that I need to polish a little bit more, before I share it with you. I will need your help later to make it much more elegant. Anyway, let me know what do you think of this design. Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

8 19