- Boost - lists.boost.org

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

08 Dec '09

Hi Michael, hi Robert, hi Felipe, >CurrentState() + cool_event() >[VeeeeeryLoooooooooongGuard()] >/(LooooooooooooooooongAction()) = DestState() I just wanted to bring an example from SimpleTimer (see doc): Ringing() + tick() == Ringing() [ Source_<m_ringing_cpt>() - Event_<m_tick>() > Int_<0>() ] / (Source_<m_ringing_cpt>() -= Event_<m_tick>() ) would become: Ringing() + tick() [ Source_<m_ringing_cpt>() - Event_<m_tick>() > Int_<0>() ] / (Source_<m_ringing_cpt>() -= Event_<m_tick>() ) == Ringing() Here, it is becoming hard to write action and target state on the same line. And the action can be as big as one wishes. >Here's another suggestion, though it breaks from the logical UML ordering Michael posted previously: >DestState() = CurrentState() + cool_event()[guard()]/(action()) I like this one quite much! Not UML at all but pretty much C++-style. And it'd become easy to write guard and action on the next lines if needed. >CurrentState() + cool_event()[guard()]/(action()) -> DestState() It's very similar with Michael's syntax but I think the operator precedence can be hard to master and we'll need extra parentheses. I think there is no operator -> in proto but ->* . We are making progress :) Christophe

2 1

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

08 Dec '09

>FYI, this is an issue of -- apparently -- English not being Christophe's first language. >Darryl's construct, "This is unlike StateChart, where the idea of object instantiation as state is genuinely useful sometimes,..." >means "MSM's approach is unlike that of StateChart, because StateChart instantiates state objects, which is sometimes genuinely useful." > >I think there was more to the original sentence, which I haven't taken the trouble to recover from earlier posts, >which better developed what Darryl liked about MSM's own approach. >There was, however, no implication that MSM fails to meet expectations because it wasn't like StateChart in this behavior. > >For those for whom English is a second language, I apologize. >Few native English speakers learn the language well. We thus make our inherently complex language harder >still to understand by our mistakes of grammar, syntax, structure, and even word usage. >Add to that the many idiomatic constructs and expressions, not to mention colloquialisms, >we use that it's amazing that you manage to converse with us so well. Oh I see. Sorry Darryl for misunderstanding your post. Robert, thanks for your help! Christophe

1 0

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