- Boost - lists.preview.boost.org

[msm] Problems with no_message_queue and pseudo exit states
by Michael.Herchel＠rohde-schwarz.com 11 Jun '10

11 Jun '10

Hi Christophe, I know your are quiet bussy releasing msm but we found something and we do not know whether it is the intended behaviour or a bug. We implemented a little state machine with a submachine. The submachine has an pseudo exit state. If we use "typedef no_message_queue" in the state machine as well as in the submachine, then the state machines get somehow mixed up and do not act normally once you leave the submachine via the pseudo exit state. In that case msm does not exit the pseudo exit state. We followed almost your example that you provide in the documentation. Is that known to you? Does it make sense to fix that or are there serious reasons why msm behaves like that? Regards, Michael

1 0

Re: [boost] boost::asio 1.43 regression (canceling read operation doens't trigger operation_aborted)
by admin＠thefireflyproject.us 11 Jun '10

11 Jun '10

Philippe Vaucher <[1]philippe.vaucher(a)gmail.com> wrote: > The problem is that when BOOST_ASIO_ENABLE_CANCELIO is not defined, > asio\detail\win_iocp_handle_service.hpp makes it so > impl.safe_cancellation_thread_id_ is equal to 0 and then when cancelling the > following code is executed: This problem seems to be windows specific. I compiled and ran Philippes testcase ([2]http://codepad.org/yYrQEqSo) on Debian GNU/Linux with Boost 1.43. I got successful results with both and without BOOST_ASIO_ENABLE_CANCELIO defined. I compiled with g++-4.1, 4.2, 4.3 and 4.4 - system specs were: wash@Dortmunder:~/sandbox/concept_tests$ uname -a Linux Dortmunder 2.6.26-2-amd64 #1 SMP Tue Mar 9 22:29:32 UTC 2010 x86_64 GNU/Linux Bryce References 1. mailto://philippe.vaucher@gmail.com/ 2. http://codepad.org/yYrQEqSo

1 0

boost log: attributes and different loggers
by Dirk Griffioen 11 Jun '10

11 Jun '10

Hi, I am trying to use 2 loggers - 1 severity logger - 1 'normal' logger However, when I add sink->set_filter(flt::attr< severity_level >("Severity") >= level); to the severity logger sink and try to use the second logger I get: terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::log_mt_posix::missing_value> >' what(): Requested attribute value not found The second logger has no formatter: backend->set_formatter(fmt::stream << fmt::message()); Nor has it any attribute. I tried different solutions, but nothing works - what am I missing? Best, Dirk

2 2

boost::asio 1.43 regression (canceling read operation doens't trigger operation_aborted)
by Philippe Vaucher 11 Jun '10

11 Jun '10

Hello, I had working 1.42 code that suddenly stopped working with 1.43. With a bit of investigation I found out that canceling an async_read operation on a serial port when a timer was fired didn't trigger the expected boost::asio::error::operation_aborted like it used to do. Here is a testcase: http://codepad.org/XnLwybDl The idea is to implement a "read with timeout" functionality on a serial port. Btw, is this the correct way to implement this? Is there a simpler way to read from a serial port with a timeout? Thanks, Philippe

2 5

Re: [boost] MSM - 1.44 release
by Christophe Henry 10 Jun '10

10 Jun '10

>> Before the deadline, you'll need to merge your code to the release branch at >> <https://svn.boost.org/svn/boost/branches/release/>. > > Can you wait until we give you the go ahead. If we're slow then that's > our fault, so we're not going to stop you releasing. We need to check > the documentation, inspect report, test results etc. Yes, of course. The library is ready anyway so I can merge fast. If it could happen during the WE, it would be really great. Christophe

1 0

Re: [boost] MSM - 1.44 release
by Christophe Henry 10 Jun '10

10 Jun '10

>>Christophe Henry wrote: >> *Component has been added to Trac >> Not done. How to do? > > > I've done this. > > -- Marshall Thanks a lot Marshall! > Rene Riveira wrote: > You could do it, or you could post what you want in the release > announcement and Daniel will likely do it (or I will eventually). The > file to edit is > <https://svn.boost.org/svn/boost/website/public_html/beta/feed/history/boost…>. Done. It would be nice if you could check I did it ok. > Usually Daniel, or me eventually :-) Again, just post what you want. Or > if you are brave edit the database file yourself > <https://svn.boost.org/svn/boost/website/public_html/beta/doc/libraries.xml>. Done. >> *Component has been added to Trac >> Not done. How to do? > One of the admins will do it.. Which is often me.. Just tell me what > your trac user ID is. I suppose the same as svn: chenry Thanks, Christophe

1 0

MSM - 1.44 release
by Christophe Henry 10 Jun '10

10 Jun '10

Dear release managers, MSM is now almost ready for the 1.44 branch (hear hear, I didn't lie at the BoostCon ;-) ). I need a little help for some of the steps. The current status is: *root/index.html includes the library in its list of new libraries. Not done. How should I proceed? *root/libs/libraries.htm entry is OK, both in the alphabetic list and in the category lists. Done. *root/libs/maintainers.txt entry is OK. Done *website/public_html/beta/feed/history/ entry is OK Not done. Who does this? *The library has been added to the website documentation list Not done. Who does this? *The library's root/libs/xxx directory contains an index.html file with either the main docs or a redirection to the main docs Done *The primary docs pages meet Boost requirements and guidelines. Don't leave this until too late; it has turned up lots of issues in the past I suppose. Any comment on what I could have done wrong? *Component has been added to Trac Not done. How to do? *Trunk inspection report is clean Done (only irrelevant warnings about license in html files left) *Trunk regression tests are reasonably clean or marked up Done How do we proceed further? What do I also need to do to get MSM into the 1.44 branch? Thanks, Christophe

6 6

Bug sprint daily update for Thursday, June 10th
by Marshall Clow 10 Jun '10

10 Jun '10

As of 0800 Pacific time today, we had 854 open trac tickets. That is down by 40 from yesterday, and 135 since the start of the bug sprint! Of the 135 tickets closed, 100 were marked as "bugs". I am very impressed; keep up the great work! Total ticket counts: Saturday 989 Sunday 988 Monday 958 Tuesday 938 Wednesday 894 Thursday 854 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: 6 Modified: 29 Closed: 49 Reopened: 3 If you're looking to help, and don't know what you can do, there are 13 outstanding "Support Requests" You can see them at <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 -35 None -17 website -10 string_algo -9 function -6 iterator -6 concept_check-5 date_time -5 multi_array -5 Getting Started Guide -4 asio -4 random -4 tuple -4 variant -4 lambda -3 units -3 Building Boost -2 foreach -2 fusion -2 mpl -2 tokenizer -2 GIL -1 Regression Testing -1 assign -1 graph -1 io -1 lexical_cast -1 mpi -1 pool -1 regex -1 signals2 -1 spirit -1 trac / subversion -1 circular_buffer 1 program_options 1 serialization 1 utility 1 Documentation 2 property_tree 2 build 4 Changed totals by author: anthonyw -34 <none> -20 dave -13 grafik -9 pavol_droba -9 dgregor -8 jsiek -6 no-maintainer -6 az_sw_dude -5 djowel -5 garcia -5 chris_kohlhoff -4 ebf -4 agurtovoy -2 dlwalker -2 eric_niebler -2 matthiasschabel -2 bschaeling -1 cnewbold -1 danieljames -1 fmhess -1 hkaiser -1 hljin -1 jefffaust -1 johnmaddock -1 nasonov -1 nesotto -1 speedsnail -1 steven_watanabe -1 cornedbee 1 danielw 1 jano_gaspar 1 jewillco 1 matias 1 ramey 1 witt 1 vladimir_prus 7 Changed totals by category: Bugs -100 Patches -16 Feature Requests -11 Tasks -4 Support Requests -2 Library Submissions -1 -- Marshall

1 0

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

10 Jun '10

>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> > Actually not but I might need to detail a bit. Consider: struct SubFsm2_ ... // front-end { struct SubState2 ... // ---> nested type }; typedef msm::back::state_machine<SubFsm2_> SubFsm2; //back-end SubFsm2_ : front-end SubFsm2: back-end SubFsm2_::SubState2 : the complete name of SubState2. Which means that : _row < State1, Event2, SubFsm2::direct< SubFsm2_::SubState2> > is correct. The back-end(SubFsm2) provides a direct entry type (SubFsm2::direct<>) taking as argument the direct entry state, which name is SubFsm2_::SubState2. Regards, Christophe

1 0

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

10 Jun '10

>>> 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 ;). Good because my todo list is getting quite long ;-) >Maybe it would be good to describe it in the documentation. Will be done. Regards, Christophe

1 0

Re: [boost] [endian] endian flip and endian domain
by Dave Handley 10 Jun '10

10 Jun '10

Robert Stewart wrote: > Dave Handley wrote: > > Gottlob Frege wrote: > > > > > I think what I am saying is that, conceptually at least, the > > > endian-types come first, and the straight functions are built on top > > > of that (instead of the other way around as most are suggested). > > > Now, I wouldn't want that to impact performance, which is why I say > > > 'conceptually'. We can specialize the heck out of > > > everything so that > > > performance wins, but I think the conceptual foundation is > > > important. > > > > I disagree. If you have an endian type then I think you are > > coding in from the beginning a need for a copy in order to > > endian swap - even if the endian swap is a no-operation. > > This discussion isn't necessarily intended to account for swap in place, > which all have agreed is necessary. Rather, I at least am > thinking of this discussion as applying to the object-based approach > and to the copy-based conversion functions. The problem is with the initial statement above which says "the endian-types come first, and the straight functions are built on top of that". This is what I fundamentally disagree with. IMHO, you have to write the straight functions (in Tom's terminology, swap and swap_in_place), then implement the endian-types on top of that interface. If you do it the other way around you enforce a copy on the function based interface. At least as far as I can see. I don't disagree that many people want and might well heavily use an object-based interface. Robert Stewart wrote: > > Next, on naming, I think we should be very careful that we > > don't over-think the naming question. I'll ask a general > > question. What term does everyone use when talking about > > endian swapping? Certainly in my programming career I've > > never heard it called anything other than endian swapping. > > Also (and I know this shouldn't be taken as a definitive > > source) Wikipedia refers to the process of changing > > endianness as a byte swap. Shouldn't we use swap because > > that is what everyone knows the process of changing > > endianness as? That's my 2d, but I'm not wholly against > > another naming option. > > While I sympathize with your position, it has been noted that "swap" > is a very bad choice because of std::swap(), boost::swap(), etc. > Those functions have a distinct behavior and purpose that endianness > conversion does not satisfy. Considering that our work could be > standardized in the future, can you imagine the committee > accepting "swap" as the name? I can't. That implies the need to > find another name. I agree that the existence of std::swap() is an issue. In that context I would argue for something more like boost::endian_swap. I think changing the verb used is an obfuscation and not necessarily helpful. Dave

4 5

: Review of a safer memory management approach for C++
by Bartlett, Roscoe A 10 Jun '10

10 Jun '10

A few responses ... > 4. Re: Review of a safer memory management approach for C++ > (Mathias Gaunard) > 5. Re: Review of a safer memory management approach for C++ > (Roland Bock) > 6. Re: Review of a safer memory management approach for C++ > (Fernando Cacciola) > ------------------------------ > > Message: 4 > Date: Mon, 07 Jun 2010 18:07:55 +0100 > From: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> > To: boost(a)lists.boost.org > Subject: Re: [boost] Review of a safer memory management approach for > C++ > Message-ID: <huj91v$cem$1(a)dough.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Bartlett, Roscoe A wrote: > > > Tools like valgrind and purify are very helpful but are not nearly > sufficient as described in Section 3.2 (and other sections) in: > > > > http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf > > The limitations you give are simply that you expect valgrind to do more > than tell you about memory errors, but also to tell you about contract > violation of any library as well. > That's not something a generic tool can do. [Bartlett, Roscoe A] Exactly my point. > Contracts are specified by > each library, and can be optionally checked in a special debug mode the > library may provide. [Bartlett, Roscoe A] Exactly. However, rather than doing this haphazardly why not have a consistent built-in approach in your own software to catch such mistakes automatically in a debug-mode build? Enter the Teuchos MM classes and the idioms described in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf > All that valgrind can do (as far as I my usage goes) is tell you if you > access some unallocated memory (relatively to the default global > allocator) or if you read an uninitialized object. [Bartlett, Roscoe A] Valgrind and purify are very useful but they will often only flag there is a problem until much after the original error occurred. As an example, a few months ago I was using std::multimap for the first time in a GCC implementation. The documentation I found for std::multimap on the web was not very detailed and did not really explain behavior in a few important cases (I have had a hard time finding decent standard C++ library documentation). I ran the code and it behaved in strange ways, segfaulted, etc. I turned on the checked STL implementation with -D_GLIBCXX_DEBUG but it did not complain about anything. I ran valgrind on it is it complained there was a problem in a place in the code that made no sense at all. I knew the only "unsafe" code that I had written (that did not exclusively use the Teuchos MM classes and idioms) was the std::multimap code. After more experimentation I figured out that I had guess the behavior of std::multimap incorrectly. Once I figured out what the behavior really was, the program ran fine. Here was a case where the checked STL implementation was not catching a basic user error and valgrind was worthless. I just wish that I would have saved the state of this code in a branch or something so that I could show this to other people. > ------------------------------ > > Message: 5 > Date: Mon, 07 Jun 2010 19:14:33 +0200 > From: Roland Bock <rbock(a)eudoxos.de> > To: boost(a)lists.boost.org > Subject: Re: [boost] Review of a safer memory management approach for > C++ > Message-ID: <4C0D28F9.1060301(a)eudoxos.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > Bartlett, Roscoe A wrote: > > Come one, at least some people on this mail list must have had > similar nightmare experiences in trying to track down and diagnose hard > memory misuse errors in C++ that took days of effort to resolve (even > with the help of tools like valgrind and purify). > > > > Hi, > > yes, I had such experiences, but that's years in the past, when I did > not know shared pointers. With shared pointers only very few memory > issues ever occurred. [Bartlett, Roscoe A] I have to admit, that w.r.t. single objects, after I started using smart reference-counted pointers, I experienced very few memory errors. However, I was still having some errors and I was writing a lot of paranoid manual error checking code with all of the raw pointers that remained (and yes, if all you have is an RCP class, you will still need to use raw pointers in many cases). After I developed Teuchos::Ptr, the raw pointers to single objects went away and I ripped out a bunch of manual error checking code (a process that I will likely never finish because of the large amount of code I have written over the years). There are people in my domain that still today will refuse to use a smart pointer class and insist on manipulating raw memory, even in brand-new code. The cycle of undefined behavior, segfault, etc. will continue ... > These days, our memory issues are of a different kind: Memory > fragmenation due to malloc's strategies in multithreading scenarios. > These are even worse, because formally, there is no problem in the > code. > Writing you own allocator and then suddenly not being able to use > valgrind anymore, that's the memory fun today. [Bartlett, Roscoe A] Do people have experience with library allocators from MPI and TBB? These are supposed to place memory more carefully but they mean that you can't use the allocator embedded in std::vector anymore. > ------------------------------ > > Message: 6 > Date: Mon, 07 Jun 2010 14:32:15 -0300 > From: Fernando Cacciola <fernando.cacciola(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] Review of a safer memory management approach for > C++ > Message-ID: <hujad9$ic7$1(a)dough.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Bartlett, > > Just for the record and since your statements below are about general > experiences with large scale C++ projects, let me put my own > experiences in > context: I had been architecting, designing and implementing large- > scaled > projects from the early 90's. The largest of which accounts for 160K > of C++ > code, which in fact I wrote almost entirely myslef. > Again this is just to put the comments based on my experience in > persective. [Bartlett, Roscoe A] The real problem comes when you can't architect all of the code yourself with one consistent style and instead have to glue together code from lots of different sources that had very inconsistent ideas about design and managing memory. Early experience with this type of work lead me to put in the extra_data hack in Teuchos::RCP. It was not pretty but it worked to glue all kinds of software together effectively. > > These types of experiences have > > lead many C++ teams to code C++ with a (justified but unfortunate) > paranoia > > about the use of memory in C++ that has all kinds of bad consequences > > I think that those memory problems are funtamentally rooted at a design > issue. [Bartlett, Roscoe A] The problems are rooted in the raw manipulation of memory with raw pointers and raw calls to new and delete and raw use of arrays as raw pointers. In my opinion that this is the design problem. Others will likely disagree. > In the mid 90's I used to developed best practices and utilities for > sane memory > management (and other sanity requirements), in the same spirit of the > paper you > presented (I did read it btw). I even implemented custom allocators, > based on > class-specific memory pools, and mandated that every object should obey > a strict > allocation-deallocation protocol. > > Simply defining a new class on my system required the use of a macro- > based DSL, > something like "DEFINE_DERIVED_OBJECT(Foo,Base). Likewise, object > graphs had to > be very carefully spelled with my DSL, as in "INCLUDE_SUBOBJECT(Bar)", > and so on.. > > This forced everyone in the team, year after year, to learn a language > on top of > C++. [Bartlett, Roscoe A] Note that the STL absolutely defined a new language in C++ as has been pointed out by Scott Meyers in Item 1 in "Effective C++ 3rd edition". The question is if the new language provides enough benefit to justify having to learn it. I believe that STL has been hugely worth it but it is only a container, algorithm, and data-structure library and does not solve the most fundamental problems with C++ coding; the usage of raw pointers which the STL alone did not eliminate the need for in many programs (others may disagree). > In the long end, however, I realized I was just overengineering the > problem way > too much, putting a big burden on the team and making it difficult for > newcomers. [Bartlett, Roscoe A] That was my opinion also in the late 90s as I was also going down that road and I stopped around 1999 but I have since come to regret that view today for the reasons described in Section 3.2 of: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf As argued in Sections 5.8 and 6.2 of the above document, the Teuchos MM classes and the associated idioms create a fairly thin language above raw pointers that increase the self-documenting nature of the code in a way you can't do with a language like Java or Python. > When C++ evolved I found new, much simpler ways to solve the same > problems, and > in particular, memory problems: using smart pointers (even long before > boost::shared_ptr came alone). Once I started using smart pointers I > never > looked back, and I never again, ever, had to spend a single minute on a > memory leak. [Bartlett, Roscoe A] Smart pointers solve leaks very well but the real problem are other invalid usages of memory that create undefined behavior. In CSE we have to use lots of arrays and we can't mandate that all memory use std::vector or STL allocators to do all of the allocations. The main holes that were filled with the Teuchos MM classes were better safer handling of arrays without mandating (not even at compile-time) how the memory is allocated or deallocated in a consistent system. > > Come one, at least some people on this mail list must have had > similar > > nightmare experiences in trying to track down and diagnose hard > memory misuse > > errors in C++ that took days of effort to resolve (even with the help > of > > tools like valgrind and purify). > > > Before I started using smart pointers, yes. > After that, no.. never again. [Bartlett, Roscoe A] Yes but what currently exists in C++0x and boost for arrays is not sufficient to provide the guarantees. Read the paper, look the classes, and make of you mind for yourself. Also, what did you do in cases where you did not need machinery for persisting associations and could not afford the overhead of reference-counting classes? Did you just use a raw pointer? Did you use a raw C++ reference? Are all of your objects using value semantics (deep or shallow copy) and just copied objects? That was the hole the Teuchos::Ptr class was designed to fill and it still provides full referentially checking in a debug-mode build. > > And again, tools like valgrind and purify will *never* catch semantic > misuse > > of memory (i.e. allocating a big chunk of memory and then breaking it > up to > > be used to construct different objects and array of objects). The > Teuchos MM > > classes will catch most semantic misuse of memory in a way that no > tool like > > valgrind and purify every can (because they don't know the context of > your > > program, they only know that any read/writes in a big block of memory > that > > you allocated look okay). I think this is a big deal in catching > > hard-to-find defects that are not (technically speaking) memory > misuse > > defects but are program defects none the less. > > > I totally fail to see why this design mistakes (wrong allocation > pattern) should > be detected by a framework? These are design issues and should be deal > with at > that stage. Surely any team can be trained not to make such mistakes. [Bartlett, Roscoe A] Telling people to simply stop making mistakes is not a solution to every problem. W. Edwards Deming stated that most mistakes that are made by people are due to a faulty process or faulty support tools. If people keep making mistakes then we need to first look at the processes and tools and not just blame them. We should be able to create the tools so that basic errors in memory usage are automatically detected, even in C++. The Teuchos MM classes and idioms paired with a static analysis tool (if we could find and configure one) to help enforce the idioms would largely solve this problem in C++. Otherwise, most people what currently write CSE software would be better off writing code in a language like C# but that is just not viable for many reasons.

5 6

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

[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

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

09 Jun '10

<snip> >I have made an example which implements the UML state chart provided by Michael. > >well it does not compiles with VC9 :(. > >it compiles as fare as the explicit entry target state is a simple >state but does not if it is a composite sate (e.g.: a sub state >machine). 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. The second has to do with the fact that msm looks for states in the transition table. In particular, RunningStateMachine has: struct transition_table : mpl::vector< // Start Event Next Action Guard // +---------+-------------+---------+---------------------+----------------------+ a_row < InitialState , event4 , InitialState , &RunningStateMachine_::onEvent4 > // +---------+-------------+---------+---------------------+----------------------+ > {}; There is no Inner1 or Inner2 to be found, so you need to tell msm about them. Add in RunningStateMachine: typedef mpl::vector<Inner1,Inner2> explicit_creation; So now it should compile. But it doesn't because I think VC9 has a bug and seems to look for Inner1 not in RunningStateMachine 's table but in Inner1's, then complains not to find it. MinGW g++4.4 compiles the code fast and correctly. However, VC9 is not the only one with bugs, and if you add Inner1 into RunningStateMachine's table, it will not compile, so msm also has a bug and I simply forgot the case of a submachine being an explicit entry. You just happen not to notice it in this example. I attach you the corrected example in case you use g++ and do not need Inner1 in RunningStateMachine's transition table. So, we'll have to live with this restriction for the moment and I offer you an alternative solution. Replace the explicit entry by an entry point (from a design perspective, I find it better anyway). I attach you this solution too. HTH, Christophe

2 1

Re: [boost] [endian] endian flip and endian domain
by Dave Handley 09 Jun '10

09 Jun '10

Gottlob Frege wrote: > I think what I am saying is that, conceptually at least, the > endian-types come first, and the straight functions are built on top > of that (instead of the other way around as most are suggested). > Now, I wouldn't want that to impact performance, which is why I say > 'conceptually'. We can specialize the heck out of everything so that > performance wins, but I think the conceptual foundation is important. I disagree. If you have an endian type then I think you are coding in from the beginning a need for a copy in order to endian swap - even if the endian swap is a no-operation. Unless I'm missing something here. I also don't think this is bad. Remember that endian swapping happens once at the boundary of the code. It isn't something that is constantly changing type and we shouldn't be worried about the programmer losing track of what type the data is in imho. Of course, if someone can come up with a typed interface which doesn't enforce a copy then I may change my mind. Next, on naming, I think we should be very careful that we don't over-think the naming question. I'll ask a general question. What term does everyone use when talking about endian swapping? Certainly in my programming career I've never heard it called anything other than endian swapping. Also (and I know this shouldn't be taken as a definitive source) Wikipedia refers to the process of changing endianness as a byte swap. Shouldn't we use swap because that is what everyone knows the process of changing endianness as? That's my 2d, but I'm not wholly against another naming option. Dave

3 4