November 2009 - Boost - lists.boost.org

Re: [boost] [msm] Version 2.0 available
by Christophe Henry 14 Nov '09

14 Nov '09

> MSM 1.20 allowed writing a state machine with actions/guards which > modify some external state. <snip/> > I no longer instantiate the state machine directly and cannot pass > parameters to constructor and it seems that msm::back::state_machine > will not do this for me (after a quick glance at the definition it > seemed to me that msm::back::state_machine expects its template > parameter to be default constructible). > Is this wrong or am I missing something obvious? Is there some way I > could still achieve the old functionality? No you're not doing anything wrong, it's a use case I simply oversaw, so it's not your fault but mine ;-) So, I corrected the problem and : - added a templated constructor, with up to 5 arguments (can be changed with the BOOST_MSM_CONSTRUCTOR_ARG_SIZE define) - actualized the doc - thanked you for this in the acknowledgments You can download the change (in back/state machine.hpp) from the sandbox (http://svn.boost.org/svn/boost/sandbox/msm/) I tested your case and a few more so it should be ok now. Thanks a lot for the report. I'm happy you like the library. Regards, Christophe

2 1

Re: [boost] [msm] Version 2.0 available
by Christophe Henry 14 Nov '09

14 Nov '09

>No, in this particular scenario I'd leave all the existing transitions in >place and just add the CDLoaded outer state. This is barely more work than >adding the flag, right? Ultimately, what I'm getting at is that your >justifying example in MsmSession_Handout.pdf could be better, because most >Statechart users wouldn't write the code you're implying they would. MSM vs. >Statechart aside, MSM users might be left with the question what flags are >good for when they can achieve the same with an additional outer state. >Again, flags are good, but the justifying example isn't. Ah now I think I now see what you mean. You're using direct entries and need therefore no change to the transitions. Point taken. I can change the example by adding another flag and giving it to one of the CDLoaded-states and one of the non-CDLoaded states, thus preventing the use of an outer state, eventhough it might make the example slightly more difficult than I intended. I really simply wanted to bring this new general concept. Regards, Christophe

2 1

Detached threads and Futures
by ak1mbox-boost＠yahoo.ca 14 Nov '09

14 Nov '09

Hi, I wanted to judge people interest in the following feature and to see [hope :)] that maybe it is already scheduled to appear in the next thread library. I find it often useful to run blocking operations in a fully detached thread. These are often atomic IO operations which receive some input by copy and then if they succeed return some output or error if they fail. The functionality that I need can be described as follow: 1. Encapsulate some code, providing ability to send it any number of parameters 2. Receive notification when this code has finished doing whatever it was supposed to be doing and get the resulting output or error. 3. Be able to terminate all other threads without the fear of the detached thread causing a memory corruption. 4. [Optional] Indicate to the detached thread that it should try to interrupt its operation and exit but not really care if it can't at this point. With Anthony Williams Futures addition to the thread library implementing something like this should not be too difficult. Is this already in the works or would people be interested in someone taking this on as a standalone library and an addition to thread library? Thanks, Alex

2 1

[mirror] C++0x version of the reflection library available
by Matus Chochlik 14 Nov '09

14 Nov '09

Dear list, I would like to announce that a new (alpha) version of the Mirror reflection library, re-written nearly completely from scratch in C++0x, is available at sourceforge.net for those interested, the code can be checked out from the SF repository: https://mirror-lib.svn.sourceforge.net/svnroot/mirror-lib/trunk/impl documentation pre-built with doxygen and DOT is available here: http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/ Based on a year and a half of user experience with the previous version (the one in Boost sandbox) there have been made several important changes. Just to mention a few: - The meta-objects should be more consistent with the base-level language - There is a run-time layer with an run-time interface very similar to the compile-time interface - Meta-object categories for tag dispatching have been added - "Local" names having parts of the nested name specifier stripped away if the Mirror's "using namespace" directive is used on the current (or parent) scope - C++0x features are extensively used to make things more straightforward - etc. This version does not yet implement all features from the previous version, like inherited class members, visitor-based traversals, meta-constructors and factory generators. These will be added in the near future. The library has been tested only with gcc (version 4.5.0 20091010) so I would be glad to hear about experiences with other compilers supporting C++0x. I would also appreciate any feedback, suggestions or other contributions. best regards, Matus

2 3

[iostreams] 64bit compile issue
by Christoph 14 Nov '09

14 Nov '09

in boost/iostreams/detail/streambuf/indirect_streambuf.hpp:171: error: no matching function for call to 'max(int, std::streamsize&)' suggest fix: cast 2 to std::streamsize Best regards Christoph

2 1

Halycon Days?
by Paul A. Bristow 14 Nov '09

14 Nov '09

http://tinyurl.com/yau3k57 see also youtube.com As Nom says - it is dead easy now there is a cable ;-) Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

1 1

[Serialization] warnings and maybe a 'bug'
by Christoph Duelli 14 Nov '09

14 Nov '09

(I tried to file a ticket, but got cookie trouble. Therefore I post here. Sorry for the inconvenience.) i) warnings (unused parameter) (These warnings are with gcc, 4.2.1) boost/serialization/shared_ptr.hpp:116: warning: unused parameter 'file_version' boost/archive/shared_ptr_helper.hpp:110: warning: unused parameter 't' /boost/archive/detail/iserializer.hpp:474: warning: unused parameter 'ar' (and 't', same line) I also get lots of boost::archive::detail::<unnamed>::init_guid<XXXX>::g' defined but not used where XXXX is some class name of mine ii) maybe a 'bug' (code does no longer compile) Code that used to compile with Boost 1.40 does no longer compile with the 1.41 beta: (I had no time to investigate yet; in case it is obvious for you once you see the code I have decided to include this point in this posting): boost/archive/shared_ptr_helper.hpp:114: error: cannot convert 'const boost::serialization::extended_type_info_typeid<MEPfad>' to 'const boost::serialization::extended_type_info*' in return (where MEPfad is a class of mine) Best regards Christoph

3 5

Beta build of PDF docs available for 1.41
by John Maddock 14 Nov '09

14 Nov '09

A beta build of the PDF documentation build for Boost-1.41 is available from the usual sourceforge page: https://sourceforge.net/project/admin/explorer.php?group_id=7586 in the Boost-docs/1.41.0 directory. Or directly from https://sourceforge.net/projects/boost/files/boost-docs/1.41.0/boost_pdf_1_…. If Boost authors would like to skim these for the usual SNAFU's that would be great. Otherwise I intend to release the final PDF build at the same time as Boost-1.41.0. Enjoy, John.

4 6

[msm] Version 2.0 available
by Christophe Henry 14 Nov '09

14 Nov '09

Dear Boosters, I'm happy to announce the review-ready new version of Msm (2.0). Msm is a framework which enables you to build a Finite State Machine in a straightforward, descriptive and easy-to-use manner. The generated code is optimized for speed and will force you to use neither RTTI nor anything virtual. Msm supports most of UML state machine 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 much more. Msm v2.0 is a redesign of Msm v1.20 and offers a separation beetween front- and back-ends. There is currently one backend and several frontends: - the same frontend as Msm v1.20 - a variation of this frontend based on functors for actions - eUML, a boost::proto-based compile-time language allowing you to use UML notations directly inside your code, thus making writing code from a state machine diagram easier. eUML also comes in with a functional programming library similar to Boost.Phoenix, adapted to state machines. I'll be happy for any comment. You can find Msm v2.0 in: - the vault (http://www.boostpro.com/vault/index.php?directory=Msm) - the boost sandbox (http://svn.boost.org/svn/boost/sandbox/msm/) The documentation can be found at libs/msm/doc/index.htm and the code in the boost/msm subdirectory. The 1.0 and 1.10 are now retired. To close up the 1.x path, I'll bring a 1.21 with the latest bugfixes and then retire the 1.20 from the vault. Best regards, Christophe

4 3

Boost bug sprint delayed until Wednesday, November 18th
by Marshall Clow 13 Nov '09

13 Nov '09

To allow time for the 1.41 release to complete, the start of the Boost Bug sprint has been delayed until next Wednesday, November 18th. That doesn't mean you can't work on bugs before that, though - just don't check fixes into svn until then. Find bugs, reproduce them, generate patches - all of those are fine! We started the last bug sprint with just over 800 open tickets. We finished with about 720 open tickets. Now (several months later) there are 854 open tickets. Useful reports: Active tickets https://svn.boost.org/trac/boost/report/1 Ticket counts by milestone https://svn.boost.org/trac/boost/report/21 Ticket counts by component https://svn.boost.org/trac/boost/report/19 Ticket counts by type https://svn.boost.org/trac/boost/report/20 Ticket counts by owner https://svn.boost.org/trac/boost/report/18 With 1.41 about to go out the door, we've still got a _bunch_ of tickets that were "to be resolved" by earlier milestones: Boost 1.36.0 101 Boost 1.37.0 45 Boost 1.38.0 64 Boost 1.39.0 89 Boost 1.40.0 139 That's more than half the active tickets! I'm sure that some of these have been fixed, or no longer apply. But which ones? -- Marshall P.S. If you're going to be participating in the sprint, please drop me a note.

1 0