December 2009 - Boost - lists.boost.org

Re: [boost] [msm] internal/external conflicting transitions
by Christophe Henry 07 Dec '09

07 Dec '09

>> I didn't find this in the standard, but I might have missed it out. >> Whatever, after a lengthy discussion with Juraj Ivancic, I came to the >> conclusion that MSM needed what we called an "execution row", which is >> pretty much your internal transitions for simple states. >> >I'll need to search the archives for this discussion (unless it was >elsewhere). As for the standard: using the UML 2.2 Superstructure >document (it is the one I have handy), Section 15.3.15 describes >TransitionKind. It's ok, I found it in 15.3.14. Just before the completion events actually, so we can have a look at both at the same time ;-)

1 0

[msm] eUML guard/action location
by Christophe Henry 07 Dec '09

07 Dec '09

Hi Michael, >What do you think about this instead? > >CurrentState() + cool_event()[Guard()]/(action()) = DestState() > >I think it more closely matches the UML syntax. It's a good idea and it surely matches the UML syntax better. I think the operator precedence will also work. There are however 2 issues: - the current order "CurrentState() + cool_event() = DestState() [Guard()]/(action())" has been chosen to closely match the "normal" row syntax. Only guard and action have been inverted because of operator precedence. - anonymous events. In this case, you have no event, so your syntax would become: CurrentState() [Guard()]/(action()) = DestState() But now the guard/action are "attached" to the source state, which means 2 grammars to support with the corresponding flow of compiler risks and compile-time increases. The first issue is only my worry that users would be confused (eUML already being quite a change). I'd be interested to hear from others about it. The second issue is not so big that it's not worth a try. I think I'll have a look at it and if it works we can then decide which one we prefer. Regards, Christophe

4 3

[iostreams] Fix for restrict/slice
by Daniel James 07 Dec '09

07 Dec '09

Hi, I don't want to merge the new iostreams changes until the unit test results are looking better. So I had a go at fixing restrict_test and slice_test. It would be really helpful if someone more familiar with the library than I am check this. There are two changes, the first is just to fix a problem with running the tests (which I suspect is why the test failure wasn't noticed before). The second one is the one that matters. It look like that when a write to a restricted/sliced stream goes past the end of the restricted area it wasn't writing the last part of the data, so I've tried to fix that. The change is here: https://svn.boost.org/trac/boost/changeset/58225 If it's wrong, I'll revert it. I know little about the library, so I'd appreciate any help here. thanks, Daniel

1 0

Re: [boost] [Boost-users] Updated performance results using Boost Serialization 1.41
by Brian Wood 07 Dec '09

07 Dec '09

Kim Barrett writes: >On Dec 4, 2009, at 7:11 PM, Hartmut Kaiser wrote: >> Our measurements show Boost.Serialization spends most of its time creating >> (constructing) archives and there it's mainly initializing the locale... > > The locale initialization can be avoided if your application can get away with using the > boost::archive::no_codecvt construction flag. (Assuming that's still behaving the same > as when I looked into this performance area back around boost 1.33.) > > These threads may also be of interest: > > http://lists.boost.org/Archives/boost/2005/07/90814.php Based on that link I tried it as follows: int const binary_archive_flags = boost::archive::no_header | boost::archive::no_codecvt; filebuf fb; fb.open("ofile", ios_base::out); binary_oarchive oa(fb, binary_archive_flags); clock_t start(clock()); oa << lst; clock_t end(clock()); I didn't discern any improvement to the performance of this test from adding those flags. > http://lists.boost.org/Archives/boost/2006/03/102133.php I don't see how that is relevant. > > I keep promising myself that I will soon collect sufficient round tuits to do something > about this, but so far those promises remain broken. Maybe once I upgrade my team to boost 1.41. -- Brian Wood Ebenezer Enterprises http://www.webEbenezer.net

1 0

Re: [boost] [Boost-users] Updated performance results using Boost Serialization 1.41
by Brian Wood 07 Dec '09

07 Dec '09

Hartmut Kaiser writes: > Our measurements show Boost.Serialization spends most of its time creating > (constructing) archives and there it's mainly initializing the locale... That seems a little different from what I've been testing. The test looks like this: filebuf fb; fb.open("ofile", ios_base::out); binary_oarchive oa(fb); clock_t start(clock()); oa << lst; clock_t end(clock()); The time to construct an oarchive is not included in the test. -- Brian Wood Ebenezer Enterprises http://www.webEbenezer.net

1 0

Re: [boost] [msm] internal/external conflicting transitions
by Christophe Henry 07 Dec '09

07 Dec '09

Hi Michael, >I'm hoping to test it thoroughly. I'm an HFSM geek and >ROOM/UML implementations are part of my livelihood. Great! Welcome to the club (though you probably were there before me). >Ok. So I think this is part of the issue. As you know, UML defines three >types of states: simple, composite and submachines. It appears that >MSM implements simple and maybe submachines. I'm still unclear on >what MSM exactly has and will write another email on the subject after >I have sorted it all out. MSM supports all but implements submachines and composite as one concept because I consider the difference isn't worth bringing 2 words. >Transitions can be either internal or external. Even for simple states. >An internal transition in a simple state will never execute exit or >entry code. I didn't find this in the standard, but I might have missed it out. Whatever, after a lengthy discussion with Juraj Ivancic, I came to the conclusion that MSM needed what we called an "execution row", which is pretty much your internal transitions for simple states. >And this is where I was unclear. A better question would be: For >a simple state, how do I create an internal transition? For the moment, you can't easily. The only way would be to specialize on_entry and on_exit on some events, but this is less than perfect, so this feature is quite at the top of my list. >This also disturbs me a bit... though it isn't your problem. Bran Selic >for some reason changed this behavior in UML. It used to be much more >well defined. Internal transitions were always evaluated before external >transitions. I don't know about that change, but I know that this depth-first strategy has some critics (which I failed to understand). Whatever, after the new type of row for simple states is added, you'll be able to define it wherever you want in the transition table and can therefore decide yourself of the priority. You will not however be able to do it for rows coming from composites because MSM will handle it alone, otherwise it'd break the exit points. I think it is a reasonable solution. >Perfect! This is what I wanted to know. I think it would be helpful >to describe the run-to-completion semantics (including the ordering) >in the documentation as well as a summary of rules for conflict >resolution. I do like the "last transition wins" rule you have >created. I also understand defining it as undefined (implementation-specific) >behavior. This has already been requested and will be done, along with a complete description of the dispatch algorithm. Christophe

2 1

Re: [boost] [msm] Review
by Christophe Henry 07 Dec '09

07 Dec '09

>I would expect both libraries to allow either mpl::vector or mpl::list. Sure. That the examples use mpl::vector doesn't mean list would not work.

1 0

Re: [boost] [msm] history pseudo states
by Christophe Henry 07 Dec '09

07 Dec '09

>I apologize. I'm still not clear on the distaste. Ignoring regions >for a minute.... does it make sense then? A composite state could >only have a single history. And the history's transition is the default >if the composite state hasn't been visited yet... so it makes sense >that there could only be one of those too. Not to apologize, I knew I was taking a risk when I decided to ignore this part of the standard. Sure, ignoring regions, shallow history makes sense. Except for the part about having to draw a transition from the top-level fsm to INSIDE the composite. Talk about UML favoring encapsulation... And if you count deep history, then it becomes even uglier. How do you mark the default state in the sub-submachine? I found no answer. >Adding in regions messes the whole thing up. And here might be >the sticking point. I can tell you that the history of "return to history" >was from an era without regions. In that context it is a very power >construct. Seeing the spec it is clear that regions were not included ;-) So, all this brought me to the conclusion that a policy was a greatly superior solution. Encapsulation ok, deep history ok, regions ok, and the possibility to define a new history policy. But I'm open to any solution answering my critics on this subjects. Of course, it's not the kind of solution that an OO-dominated body can come up with. Christophe

1 0

Re: [boost] [msm] Review
by Christophe Henry 07 Dec '09

07 Dec '09

Hi David, Thanks for bringing some depth to the discussion. >2. In Statechart, the definition of a state is coupled to the machine in which it resides > while in MSM the state can be defined totally in isolation of the machine, and, thus, reused in other machines >3. In Statechart, the transitions are coupled to the from-state, and defined therein, > whereas in MSM, the transitions are coupled to the machine itself; this makes it a bit tricky to reuse a state in Statechart This is an important interface difference, isn't it? > 5. MSM has eUML, which I have *not* used, to simplify the machine specification. I'd also count it as an important interface difference. You brought the following example, which will be a good starting point. Unfortunately, you seem to want to make it tell too much about Statechart/MSM similarities (I read "fairly similar") so let's tough it out a little. With Statechart, you had: struct State1 : simple_state<State1, Machine> { typedef transition<Event, State2, Machine, &Machine::action> reactions; }; And with MSM: typedef mpl::vector< a_row<State1, Event, State2, &Machine_::action> > transition_table; Now this example is a bit too simple to see a huge difference, so it is slightly misleading. If you don't mind, let's add a very simple thing, a guard (which is a boolean condition having the right to prevent the triggering of a transition). With MSM this becomes: typedef mpl::vector< row<State1, Event, State2, &Machine_::action, &Machine_::some_condition> > transition_table; Could you you maybe now show us how the Statechart version will look like? Let's now add a conflicting transition, which means another possible transition on the same event and the same source state, with guards deciding which (if any) transition will be taken. With MSM you'd have, for example: typedef mpl::vector< row<State1, Event, State2, &Machine_::action, &Machine_::some_condition>, row<State1, Event, State3, &Machine_::action, &Machine_::some_other_condition> > transition_table; Could you now write the Statechart version for us? How easy is your Statechart->MSM translator now? (Note: MSM->Statechart will stay pretty simple, right?) After seeing both versions, will we all agree that there are important interface differences and that these differences are an important distinguishing feature? Christophe

4 4

Re: [boost] Two FSM libraries, one interface
by Christophe Henry 07 Dec '09

07 Dec '09

>Out of curiosity, but since MSM is designed to have configurable >front-ends and back-ends, why cannot statemachine become a new >back-end and/or front-end to MSM? MSM supports everything >statemachine does so it should be possible with perhaps minor syntax >changes... You mean FSM_DEF? It could, but first it'd need to support a bit more to become interesting. If I have to maintain it, I want to be sure that it does what the other front-ends do. If I don't maintain it, then no problem for me.

1 0