- Boost - lists.preview.boost.org

Re: [boost] [msm] eUML guard/action location
by Christophe Henry 08 Dec '09

08 Dec '09

Hi Michael, >Thank you for setting me straight on this. It should have dawned >on me that they were completion transitions as described in 15.3.14. >I have a love/hate feeling about them... I don't personally like >the concept of leaving a state via implicit trigger. It just makes >me feel uncomfortable. However, I also see the power they can >afford and use them for exactly your example... stepping along >algorithms. You taught me about simple states' internal transitions so let's count it a fair trade ;-) >Right now I'm pushing on the edges of what I'm learning from the docs >and a little bit of playing so I can determine how to convert basic >constructs I use a lot from the model to the implementation. Thanks >for putting up with me. You're welcome. I enjoy the discussion and await the harder questions which are surely coming. Christophe

1 0

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

08 Dec '09

Hi Darryl, >I agree with this. However, I have yet to come completely to terms with >how best to use msm. I am beginning to think, in trying to use it, that >it would be better to separate the state transition table definition as >much as possible from what, in an msm world, are more like semantic >actions. This is very different from the more oo modeling approach of >statechart. I'm not sure the statechart isn't better at expressing fsms >that "emerge" out of overall application/system design in an all >encompassing oo design uml world, and msm better at expressing more self >contained "islands" of fsm in an app As far as I can tell, state machines and OO modeling are completely orthogonal concepts. An OO implementation doesn't mean that FSMs are an OO concept. Can you precise your point with a concrete example? >I'm far from an expert with >spirit, but I think there are many concepts that could be borrowed from >it to make msm better able to be used to define a fsm that can be bound >to separate objects to implement behavior and exend its use beyond these >islands. Again, can you help us with more concrete examples? >Basically, it needs to be easier to take a 1 TU transition table >integrate it into to a bigger multi TU system What would it concretely bring? Compile-time improvements not really, so? >actions - the functor approach is good - though it needs a bit more >development to make it easier to bind to actions that are not explicitly >designed for use as msm state machine actions. What would it bring? You can simply ignore the functor arguments if you don't need them. A closer look at eUML will however show you that having your source/target states at hand in a transition handling can be pretty useful. >states - I don't really understand what an instance of a state is in msm >- it doesn't model anything meaningful to me. Where do you suggest putting the entry/exit actions and the flags? All in one big fat react function with lesser code reuse possibilites? And all the state data inside a fsm? Why giving up reuse of states? >This is unlike statechart, >where the idea of object instantiation as state is genuinely useful - >sometimes, and where it is the state that "reacts" to an event In UML, it is a state machine which reacts to an event, not a state. Statechart != UML (the same applies to MSM). Furthermore, "unlike Statechart" isn't a valid argument, is it? Making MSM look like Statechart is not the goal (besides, David would make us another round ;-) Just kidding, David) Could you please develop your point a little? >Should msm drop state objects altogether and simply have some sort of context / >current state object? Arguably it already has one in the form of the fsm >object - though that is a bigger concept than context. I disagree. I see no gain doing this. Just more confusing, tightly coupled, unreusable state machines. >Michael Caisse has already pointed out that there is something slightly odd about the >current state being represented as a scalar in a model that has objects >as states Did we read the same post? I didn't read all this in any of his posts. >I haven't spent much time thinking about this I also have this feeling, to be frank. If I understand, what you want is a MSM looking like Statechart. What for? I think a few concrete points would help us all. Of course, MSM could easily support a Statechart-like frontend, but nobody required this so far. I had the opposite feeling, that most people welcomed the lesser coupling offered by MSM. Or am I getting it wrong? Christophe

3 2

[serialization] #3677: Please, pay attention to a serious regression
by Alexander Churanov 08 Dec '09

08 Dec '09

Folks, I've just re-opened the issue #3677, since I did not receive any specific feedback on how to resolve it. In the ticket it's claimed that the issue is fixed. However, for the question about how to obtain the patch it was answered that there is a belief the patch is checked in somewhere into the trunk. I completely understand that Boost is free and does not provide any warranty for quality and reliability of the libraries. However, I hope that there is a strong interest in Boost community for that. To my knowledge, the issue is cross-platform and may broke more applications than stated in the ticket. It is a pure regression: boost 1.39 is known to work. The issue is a showstopper, at least for FreeBSD: I may not update the boost to 1.41, because this action breaks working applications. The desired is any definite decision on the issue. Preferably, a fix or a workaround. Alexander Churanov, maintainer of devel/boost-*

1 0

Re: [boost] [serialization] polymorphic archives runtime failure(was:polymorphic archives ... generates linker errors)
by Bogdan 08 Dec '09

08 Dec '09

I just want to confirm I have the same issue with boost 1.41.0 built with MSVC 9.0 (Visual Studio 2008). I have created two tests similar to the one Christoph describes ( both with and without DLLs) and I hit exactly the same assert in basic_serializer_map::find(). It looks like while deserializing B via A*, basic_iarchive_impl::load_pointer() is trying to recover a serializer from: boost::serialization::singleton< boost::archive::detail::archive_serializer_map<boost::archive::naked_xml_iar chive> > (or boost::serialization::singleton< boost::archive::detail::archive_serializer_map<boost::archive::naked_text_ia rchive> >, depending on the input archive actually used) but that map is empty. I checked boost::serialization::singleton< boost::archive::detail::archive_serializer_map<boost::archive::polymorphic_i archive> > in the first line of my program and it contains correctly two serializers (one for A and one for B, respectively), proving that the macro BOOST_CLASS_EXPORT_IMPLEMENT(.) has registered those classes. I am not sure why the serializers for A and B do not register with the specific polymorphic archives but only with the base archive. I was under the impression that the polymorphic archives are meant to make that process transparent to the user (especially future archives that are created later). I appreciate any feedback about this issue and please let me know if you need more details. Thank you, Bogdan PS I am using extended type_info_no_rtti. Deserializing via isomorphic pointers (B*->ser->dser->B*) is working.

4 4

[regex][patch] regex build not honoring ICU_LINK build property
by Martin Schafföner 08 Dec '09

08 Dec '09

I have been trying to build boost.regex with Unicode support against a custom ICU4C build. The ICU4C build used the "--with-library-suffix=rm" configuration option to distinguish the library as being custom built. I tried building boost.regex with the bjam option like '-sICU_LINK="\"/LIBPATH:c:\icu4c\dist\libs\windows-i686 icuinrm.lib icuucrm.lib\""' but it failed to apply the linker flags. I then tried to understand what's going on and it seemed that the ICU_LINK property never makes it into the actual linker calls. With the attached patch against 1.41.0 the ICU_LINK build property works as expected. Regards, Dr. Martin Schafföner Core Technologies Recommind, Inc. Office: +49 2226 15 966 13 Email: martin.schaffoener(a)recommind.com This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.

2 1

Re: [boost] [Regex] Why doesn't this pattern match?
by Vitalij Gotovskij 08 Dec '09

08 Dec '09

>> Yes, Robert, You are right. I am trying to change \\n (wchar_t '\' and >> wchar_t 'n') with a real new line symbols and it doesn't work. Allthought, >> then I am trying to find only wchar_t 'n' (or any other letter) everything >> is working good. The problem is that I have XML configuration file >> (Unicode), where all new lines are L"\\n" (!!! not '\n' !!!). I can't >> change that file format. Of course I can program that replace without >> boost::regex, but I am afraid that I'll loose my sleep afterwards... >> >>>> You're replacing each occurrence of \\n with \\n, so the >>>> string at the end should be exactly the same! :-) >> >>> The replacement is "\n" not "\\n" so the '\' followed by 'n' in str >>> should be replaced with a newline, right? > No. Remember the compiler gets first bite at the escape characters, so if > you put a string "\\n" in your program, that gets passed to Boost.Regex as > the two character string: "\n", which matches a single newline character. > If you want to match a \ followed by a \n then you need a regex of "\\\n". >HTH, John. You wanted to say: "\\\\n" ? :) Anyway, thanks a lot. This works! Didn't knew regex engine is working in that way... If he understands "\\\\n" as C++ "\\n" and "\\n" as C++ understands "\n", then how regex engine understands "\n" ...? Don't answer this letter. The problem is solved.

1 0

[Regex] Why doesn't this pattern match?
by Vitalij Gotovskij 08 Dec '09

08 Dec '09

Hello, can, please, somebody explain, why this code doesn't work? std::wstring str = L"Line \\n line \\n line \\n"; std::wstring result = L""; const boost::u32regex e = boost::make_u32regex(L"\\n"); std::wstring newText = L"\n"; result = boost::u32regex_replace(str, e, newText); After launching result == str... :((( I also tryed with const boost::u32regex e = boost::make_u32regex("\\n"); but result was the same... I am using Regex from bost 1.37.0 compilled with ICU 4.2.1 Visual Studio 2008.

3 3

[MSM] Comparison with ad-hoc FSM implementation
by Phil Endecott 08 Dec '09

08 Dec '09

Dear All, When we reviewed Andrey Semashev's proposed FSM library last year I presented a couple of examples of simple state machines encoded "ad hoc", i.e. primarily as switch statements that set the next state based on the current state and inputs, and asked "why is this library better?". I'm going to ask the same question of MSM. Consider the example presented in the documentation: struct cd_player_fsm { enum state_t { Stopped, Open, Empty, Playing, Paused }; enum event_t { play, open_close, stop cd_detected, pause, end_pause }; state_t state; void process_event(event_t event) { if (state==Stopped && event==play) { start_playback(); state=Playing; } else if (state==Stopped && event==open_close) { open_drawer(); state=Open; } else if (state==Stopped && event==stop) { state=Stopped; } else if (state==Open && event==open_close) { close_drawer(); state=Empty; } else if (state==Empty && event==open_close) { open_drawer(); state=Open; } else if (state==Empty && event==cd_detected && good_disk_format()) { store_cd_info(); state=Stopped; } etc. etc. } }; Of course one difference is that MSM has O(1) dispatch. We can get that too if we use a switch statement, maybe something like: switch ((state<<8) | event) { case (Stopped<<8)|play: start_playback(); state=Playing; break; case (Stopped<<8)|open_close: open_drawer(); state=Open; break; etc. etc. The greatest advantage of this ad-hoc style is that it is readable by anyone who has even the most basic understanding of C++ without the need to learn a new library, and its exact behaviour is immediately evident. It is also likely to compile and run quickly. I have no doubt that MSM has many benefits compared to this. Perhaps it would be useful to spell them out? Regards, Phil.

1 0

Re: [boost] [msm] eUML guard/action location
by Christophe Henry 08 Dec '09

08 Dec '09

Hi Michael, >Ok... I looked up MSM's anonymous transitions again and >now I don't like it (o; It's probably because we don't talk about the same concept. And it's not an MSM concept. Sorry, I can't claim ownership for it ;-) Anonymous transitions are also called completion events in the standard (and both names are used in the excellent "Real-Time UML, 3rd Edition"). They are defined as a transition without explicit trigger and are generated after the entry actions. You can have a look at the tutorials to see how it is used. >Christophe ... as far as I can tell by looking at the docs, >the MSM use of anonymous transitions transforms the source >state to *almost* be a UML choice pseudo state I disagree with this. The state itself is not concerned, it is only a state machine thing. If you reuse the same state in another context, it will not behave like a choice point. But in this special state machine context, yes, it behaves the same, which is why I didn't implement choice points yet. Now you see what I meant ;-) I was at first not convinced by this feature until I saw a project in a big automotive company making extensive use of it. At every processor time slice, they'd go through the whole fsm used in this context as an algorithm. They could this way easily estimate the time slice they needed. What you are talking about is a trigger, which has to be fired, whatever it is. I didn't find it in the standard, but I could have missed that too. And no, MSM doesn't support it for the moment. The reason is that it's not on my radar as I'm pretty unconvinced of its need. I have yet to see a good convincing use case for it. Now, I don't say it won't be done, but it's not high on my list, unless someone makes a convincing case for it. Its implementation might be not trivial though. Christophe

2 1

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

08 Dec '09

Hi, >eUML makes up *~75%* of Msm's code and ~30% of Msm's documentation; metrically, >it's obviously an extremely significant part of Msm, and is probably what >warranted a major version increment between Msm versions 1.2 and 2.0. Correct. Although it is not the only reason, there is also a big redesign with division in front- and back-ends and riddance of the CRTP. Adam Merz wrote: >I could be way off here, but my impression from the Msm documentation >is that the standard frontend exists mostly for backwards compatibility >with 1.x code and to support older compilers, and that > eUML is the recommended frontend for new FSMs on supported compilers David Bergman wrote: >That was not my impression. My impression was that the (old) standard interface >was the canonical one, and eUML an "option" for developers. MSM has no favorite interface, but a choice of interfaces which it tries to support equally well. But it's true that eUML is my personal favorite way and the source of a great amount of fun. I personally thought (or say hoped) that it'd become the new way of writing state machines, but I came into this review without an idea of how it would be welcome. From what I saw for reactions until now, I'm pretty confident eUML will meet this goal at some point. >I would welcome eUML into Boost any day, from what I have seen (especially after playing with it this morning.) Great! >Do we really need a new underlying library for eUML, though? I am not sure of that. You don't get a new library for eUML but eUML for a new library. It's clearly not the same. >And even if we do (for now), and cherish the much faster execution speeds of MSM >(in my non-complex but pretty big state machine examples), I don't get what is the problem. You get a backend with impressive performance which was built with the goal to allow expressive, declarative and concise front-ends with great UML support and lots of work done under the hood which you can't even imagine. Without it, there would be no interface and no eUML. Why not have it? I thought that Boost was standing for state-of-the-art C++ coding and was happy to get any great library coming, no matter which library is already part of it. Don't we all agree on that? >I would argue for an attempt at having eUML as an optional facade for both MSM and Statechart. For this you'd need some important amount of change in Statechart, for which I cannot do anything. eUML being a representation of the underlying MSM philosophy, I doubt that you will have it. Let me get it straight. The biggest value of MSM is not the front-end, not even eUML, no matter how cool it is. It is the back-end. Actually it's the philosophy behind the back-end. Christophe

4 5

[ratio] metafunction ratio_subtract
by vicente.botet 07 Dec '09

07 Dec '09

Hi Beman, Hi Howard, With current implementation of the metafunction ratio_subtract I get the type from the test ratio_test.cpp User1::Distance d( User1::mile(110) ); User1::Time t( boost::chrono::hours(2) ); typeof (d/t) is User1::quantity<boost::ratio<1,-1>, boost::ratio<1,1> > So the following assignation do not works User1::Speed s = d / t; as User1::Speed is defined as typedef quantity<boost::ratio<1>, boost::ratio<0> > Time; // second typedef quantity<boost::ratio<0>, boost::ratio<1> > Distance; // meter typedef quantity<boost::ratio<-1>, boost::ratio<1> > Speed; // meter/second The code is a little bit triky, and I have not taken the time to understand why the resulting type is User1::quantity<boost::ratio<1,-1>, boost::ratio<1,1> > and not <boost::ratio<-1,1>, boost::ratio<1,1> > User1::quantity I have replaced the type by typedef ratio<R1::num * R2::den - R2::num * R1::den,R1::den * R2::den> aux_type; typedef ratio<aux_type::num ,aux_type::den > type; // get normalized type to follow the recommendation "The nested typedef type shall be a synonym for ratio<T1, T2> where T1 has the value R1::num *R2::den - R2::num * R1::den and T2 has the value R1::den * R2::den." and every thing is OK (See below the replaced code) I'm doing something wrong? Best, _____________________ Vicente Juan Botet Escribá template <class R1, class R2> struct ratio_subtract { private: #if 1 typedef ratio<R1::num * R2::den - R2::num * R1::den,R1::den * R2::den> aux_type; #else static const boost::intmax_t gcd_n1_n2 = detail::static_gcd<R1::num, R2::num>::value; static const boost::intmax_t gcd_d1_d2 = detail::static_gcd<R1::den, R2::den>::value;#endif public: //The nested typedef type shall be a synonym for ratio<T1, T2> where T1 has the value // R1::num *R2::den - R2::num * R1::den and T2 has the value R1::den * R2::den. #if 1 typedef ratio<aux_type::num ,aux_type::den > type; #else typedef typename ratio_multiply < ratio<gcd_n1_n2, R1::den / gcd_d1_d2>, ratio < detail::ll_sub < detail::ll_mul<R1::num / gcd_n1_n2, R2::den / gcd_d1_d2>::value, detail::ll_mul<R2::num / gcd_n1_n2, R1::den / gcd_d1_d2>::value >::value, R2::den > >::type type; #endif };

2 4

[ratio] Assignation between equivalent ratios
by vicente.botet 07 Dec '09

07 Dec '09

Hi, I was wondering if we need to be able to make assignations between equivalent ratios. e.g. ratio<1,3> r1; ratio<3,9> r2; r1 = r2; // (1) Reading N3000 even if they are equivalents (synonym ) as its num and den are the same, there is no defined assignation. So (1) should not compile with the current recomendation. IMO, this should compile, and so we need to add a specific assignement operator. Other example ratio<1,3> r1; ratio<2,3> r2; r1 = r2-r1; // the type of this expression could be ratio<3,9> so the compilation fails. Otherwise the recomendation should clarify the meaning of synonym on the ratio arithmetic operators [ratio.arithmetic] 2 "The nested typedef type shall be a synonym for ratio<T1, T2> where T1 has the value R1::num * R2::den + R2::num * R1::den and T2 has the value R1::den * R2::den." Maybe we should talk of normalized ratio and not of synonym. BTW, where is synonym defined? In addition I think that we need also to add that the declaration of no normalized ratios, as ratio<3,9>, must fail at compile time as it is not normalized and we can not assigne nothing to them. I'm missing something? Any thougths? Best regards _____________________ Vicente Juan Botet Escribá

5 7

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

07 Dec '09

Hi David, >The problem is this: if, *hypothetically*, eUML were the only substantial difference between this proposal >and what is already in Boost, I would argue for an implementation of that syntax on top of Statechart to be a more viable solution. Agreed. >As you spell out here - and I can confirm - that is not the only difference Happy that we finally agree ;-) >Perhaps, I would like to take on that challenge and see how far I can get. >I think it would be great to have a common transition-definition format for these two libraries, and being able to switch in compile-time. >Let me try to look at it a bit, and see what I can do. It would involve a lot of wrappers, unfortunately :-( As I wrote in another post, I find the idea hard but interesting and I can only encourage you to give it a try. >I enjoy being critical of things I like, which is why I always criticize my wife. I wouldn't try to push this too much with mine ;-) >So, take that as a good sign for my formal review (which has already been pushed one day due to my "common interface" sickness :-) ) I'll be happy to read it. I think that, while this common interface thing went a bit long, you brought interesting points to the review and even went the extra mile to not criticize without bringing at least a beginning of a solution, which is not a very common thing. Christophe

1 0

Meta State Machine library review starts Monday
by David Abrahams 07 Dec '09

07 Dec '09

Dear all, With apologies for making this announcement so close to the review start date... The review of the Boost.Msm library starts this Monday, November 23rd and ends the December 6th. Msm was written by Christophe Henry, inspired in part by the example in the book "C++ Template Metaprogramming" (http://boostpro.com/mplbook) About the library: Msm (Meta State Machine) is a library allowing the user to easily define high-performance, straightforward and readable UML2 finite state machines, while respecting the principles of efficiency and declarativeness of the original example. To that end, Msm offers several Domain-Specific Embedded Languages that strive to closely emulate a standard UML diagram. Msm supports a broad range of UML features: - state entry/exit - transition actions/guards - composite states - history - orthogonal regions - terminate states - deferred events - explicit entry/fork - entry/exit pseudostates - anonymous transitions - transition conflicts And several non-standard features to make the developer's life easier (interrupt states, query about the current state(s)). Msm (in its current version, 2.0) can be found: * in the sandbox (http://svn.boost.org/svn/boost/sandbox/msm/) * or in the vault: (http://www.boostpro.com/vault/index.php?directory=Msm) Everybody on this list is invited to participate in this formal review. I hope to see your review of Msm, including your vote on acceptance, and I welcome your participation in the ensuing discussions on the Boost developers' mailing list. Please always include in your review a vote as to whether the library should be accepted into Boost. Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? - With what compiler? - Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards, -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com Review Manager BoostPro Computing http://www.boostpro.com

8 10

Re: [boost] Meta State Machine library review starts Monday
by Christophe Henry 07 Dec '09

07 Dec '09

>I'm wanting to start discussing some more complicated >use cases of this library. Ideally I will just post >the UML HFSM diagram with my email so it is clear. Why not in the Vault in MSM's directory?

1 0

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