December 2009 - Boost - lists.preview.boost.org

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

07 Dec '09

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

1 0

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

07 Dec '09

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

4 3

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

07 Dec '09

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

1 0

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

07 Dec '09

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

1 0

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

07 Dec '09

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

1 0

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

07 Dec '09

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

2 1

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

07 Dec '09

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

1 0

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

07 Dec '09

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

1 0

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

07 Dec '09

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

4 4

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

07 Dec '09

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

1 0

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

07 Dec '09

Hi Michael, >>"To be frank, History is not a completely satisfying concept. First >>of all, there can be just one history pseudostate and only one >>transition may originate from it." >I'll not contend with the views of history yet. They can be a very >powerful concept. What I'm unclear about is the statement that >there can be just one. According to the UML specification there >can be just one per composite state. That of course makes perfect >sense. MSM has SubmachineStates instead of composite states; however, >the same "rule" applies to both. >Does MSM obey this definition or is there a further constraint? >My confusion might be partially attributed to not having finished >reading all of the docs. Sorry for the confusion which I created. Let me try to correct it. Yes of course, I meant one per composite state. And no it doesn't make perfect sense (at least for me) so there'll be a small constraint: History is not a pseudo state for MSM. I find the concept in UML highly dissatisfying. It simply doesn't fit well with orthogonal regions. What if I want to "remember" more than one region? With UML, you're out of luck: one history per composite, one transition originating from it. Want more? Sorry we can't help you. And with deep history, it is even worse. You don't even see for what region of the subcomposite it applies. And I don't see how adding a "*" is supposed to help. So MSM replaced this unfinished and unsatisfying concept with a policy. This allows you much better history configuration and easy deep history. I hope I managed to correct the created confusion. Christophe

2 1

Two FSM libraries, one interface
by Christophe Henry 07 Dec '09

07 Dec '09

Hi David, >Anyway, I just got tired of being a grumpy old passive man, so decided to put some of my money >(or time) where my mouth is. I will write more about this side effect of my analysis in a blog post later I find it great and worth of respect that you spent time making a useful contribution to the discussion by going the extra mile (or even 2-3) to present your point. While I am by no mean a friend of the preprocessor, I find your solution interesting and encourage you to push it a bit further by supporting at least guards. If you allow a few comments: - I suggest you to give the action a name because you won't always manage to name an action actState1EventState2, for example with 2 transitions with the same source and target. - this would also remove the need for direct code writing, which could break the preprocessor - What about adding some entry/exit? I'm sure you manage to pack this one too. Otherwise I find the idea surprising but fun and think that it could gain being pushed a bit further. If you do, you could even tempt me to reuse it in an eUML front-end ;-) Christophe

2 1

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

07 Dec '09

Hi Michael, Looks like you are thoroughly testing MSM and I find it great :) >The docs have a section on "Conflicting Transitions". It has >two conflicts described: > >1. an event enables multiple transitions because > multiple guards test valid, > >2. an internal and external transition are both enabled > >I see a clear definition for the behavior of #1 in the >discussion; however, it is not clear that #2 will follow >the same rule. I was maybe unclear with "internal" so let's see if we can converge. With internal, I mean internal to a composite. Suppose we have a fsm named Top containing a state State and a composite Sub. Top has a transition on Event from Sub to State. Sub has 2 states, SubState1 and SubState2 and a transition on Event from SubState2 to SubState1. If the fsm is in the state Sub::SubState2 and Event is detected, we now have a conflict between Sub->State and SubState2->SubState1. UML defines this as a conflict and orders that SubState2->SubState1 wins. It also surprised me a bit until I implemented exit points, which are in themselves a conflict (they are defined as a connection between a transition inside a composite and one outside, triggered by the same event). So, if SubState1 were an exit point, it would still work. >It was actually a little surprising to me that the order <of the transition definitions affected #2. (Well, maybe >not surprising ... but not what I wanted). I used >the SimpleTutorial to test the behavior with: > > a_row < Stopped , play , Stopped , &p::test_conflict >, > a_row < Stopped , play , Playing , &p::start_playback >, > a_row < Stopped , open_close , Open , &p::open_drawer >, > >and > > a_row < Stopped , play , Playing , &p::start_playback >, > a_row < Stopped , play , Stopped , &p::test_conflict >, > a_row < Stopped , open_close , Open , &p::open_drawer >, > > >The last transition defined "wins" in a conflict. This is were I'm unsure if I follow you. SimpleTutorial has no composite, so no internal transition so we must be talking about different things. I can, however, still answer about the order of evaluation. UML orders that conflicts be solved by guards which are mutually exclusive, so your machine is currently ill-formed (no guards) and UML says the behavior is undefined and I, as implementer, am allowed to punish you like I wish ;-) Seriously, if you have guards and they are mutually exclusive, your machine is correct and all will work as expected, no matter the order of evaluation. If you still want to know how it works, with pleasure (this is where normal users could stop reading ;-) ). First, for every event used inside a composite, MSM adds a forwarding row at the end of your table (at the end, so they have no influence on the state index calculation system). Then, for a given event, MSM iterates at compile-time through the STT, from back to front and replaces the conflicts by a new row containing all of the conflicts (this is were your compiler suffers). Thus, transitions internal to a composite are given higher priority in the evaluation. This also means that for "normal" conflicts, the last transition wins. I was already asked if I would change it. It is implementation-specific so you should not rely on it, but it is very unlikely that I will ever want to change it. I hope I brought enough elements to bring clarity. If not, please let me know. Christophe

2 1

Re: [boost] Meta State Machine (MSM) review
by Christophe Henry 07 Dec '09

07 Dec '09

Hi Robert, >I wonder if the library can provide a debugging mode that would provide a helpful default implementation >of no_transition that could help identify the unknown transition rather than requiring the user to write something? >Such a function might access internal details, perhaps only provided in the said debugging mode, >that would be clearer about the source state and event for which no transition was provided than would user-level code. Right now you only get an assert in debug mode. I also wonder if more would be possible. About the event, sure, it is already done, about the source state, I can't promise anything, but I will have a look at it. If I understand correctly, you would be satisfied with an assert or error message bringing a bit more debug information? Christophe

2 1

Interprocess regexes
by Mike Spertus 07 Dec '09

07 Dec '09

I would like to store regexes in shared memory, but it seems like Boost regex falls just barely short of supporting this. In the basic_regex documentation, it says "The definition of basic_regex... is based very closely on class basic_string and fulfils the requirements for a constant-container of charT." This may be technically correct, however basic_string and other containers take an allocator template argument, while basic_regex does not. If basic_regex had an allocator it would reap all the same benefits that other string and container types do. In particular, it would be possible to use boost::interprocess to place them in shared memory. Since the allocator would be defaulted to allocator<charT>, I think it would IMO be compatible with the vast majority of existing code (not quite all because template<class charT, class traits> void f(basic_regex<charT, traits>) wouldn't work). Does this make sense? Do others agree that it would make regexes more like other strings and containers as advertised? Thanks, Mike

7 16

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

07 Dec '09

Hi Franz, > SC 19.63630 s > Rhapsody 4.95109 s > MSM 0.90754 s Thanks for the review and for the very interesting comparison with Rhapsody, which I found impressive for several reasons: - Rhapsody is, I think, a pretty costly tool (I heard 15k€) so I expected some cool fsm framework and instead the event dispatching really is just a simple switch on states of if/else on event ids, so a pretty basic implementation (though it would be interesting to see how more complicated machines are generated). Of course, as it is made for embedded development, this is understandable. - although this is such basic C-like implementation, Msm is 5 times faster. This is fascinating, the rootState_processEvent is so simple, one can wonder how it is possible to be faster. I find this a good example of the power of metaprogramming. I love C++ :) Thanks, Christophe

17 47

[msm] choice (point) pseudo state
by Christophe Henry 07 Dec '09

07 Dec '09

Hi Michael, >I do not see the concept of a choice point. Did >I miss it? It looks like it can be modeled with >a state having only anonymous transitions and >appropriate guards. Correct, there is currently no choice point as it can be easily emulated and I'm still scratching my head about what to do with it. I'm actually unsure whether and how it should be implemented. It'd be a normal state with an incoming anonymous transition (as you mentioned) and several guards. Even the "else" is optional. So I admit I'm a bit confused if I should simply provide a typedef or if something makes it different from a state. That's the reason why it's not implemented yet. If you or anybody else sees a good use for it and why it's more than a normal state, I'd be quite thankful and could implement it. Christophe

1 0

GGL review (JTF)
by Jonathan Franklin 07 Dec '09

07 Dec '09

=== What is your evaluation of the design? === The design seems to adequately capture important geometric concepts, such as dimensionality and coordinate systems, as well as numerical precision, etc. The 4-type overload for assign (center + radius for a sphere) deviates from the semantics of the 2-/3-arg versions, which I dislike. I have not reviewed any of the extensions, so perhaps there is a good reason doing this... Other than the fact that more people will probably use center+radius than 4-d polygons. Then again, assign is parameterized by the geometry type, so this is probably just an omission. Issues w/ units continue to nag at the back of my mind. However, specifying units for specific geometries (e.g. radians), and requiring consistency of units within a given geometry seems appropriate. Any design issues that would prevent strong robustness guarantees (without drastic refactoring) in the future should be identified and fixed prior to release. I *think* we are okay here, but have not put sufficient effort to make that call (because I don't need it). === What is your evaluation of the implementation? === I didn't have time to review the implementation, other than general poking-around in the code. I was happy to note that some of the functionality already works for k-dimensional euclidean geometries, even though it is technically not supported at the moment. And by k-dimensional, I mean k=4. :-) I didn't have time to push the limits. === What is your evaluation of the documentation? === In a nutshell, the documentation is inadequate, and IMO must be completed prior to release. I'm not sure whether it is best to require a mini-review, or some other process. A few anecdotes that illustrate the problem: The example code on the main page didn't compile, which isn't a problem in and of itself. However, it took an inspection of random code in the separate Examples section, and inductive reasoning to determine that I needed some additional includes beyond ggl.hpp to make the snippets work. I suggest a direct link to a working example program anywhere example code snippets are provided. I also had a bit of difficulty getting several algorithms to work, like union/intersection. The concepts were decently documented, however, translating the concepts to working code took some leg-work. The doxygen documentation seems incomplete. I expected a tab for functions, like union_inserter, but was only able to drill down to the functions by looking at the header docs. An algorithms page seems apropos. However, I couldn't find a page listing the available algorithms. I arrived at the union_inserter page via the doxygen-generated union.hpp header page. Average and worst case performance, as well as any known/suspected numerical issues or other bugs (such as the non-minimal result returned by union_inserter) IMO *must* be listed in the docs for each algorithm. This is the trade-off for not providing a 100% robustness guarantee. Even then, the pre/post conditions for algorithms must be specified, which seemed to be lacking from the docs. A note (personal opinion) regarding Doxygen documentation: Doxygen is best suited for a reference manual. For a User's/Programmer's guide, not so much. === What is your evaluation of the potential usefulness of the library? === This is a generally useful library across *many* domains. In particular, I am excited to make use of this library at work in our graphics/visualization infrastructure code, as well as our actual GIS features. In my academic research, I plan to make use of this library in statistical machine learning/data mining algorithms. However, it is a shame that the library lacks a first-class spatial index capability in it's present state (e.g. what is up for review). Even a relatively naive reference implementation using an R-tree would be useful to me. === Did you try to use the library? === Yup. * With what compiler? g++ (Ubuntu 4.4.1-4ubuntu8) 4.4.1 * Did you have any problems? The internal headers #include <ggl/blah.hpp>, which requires a -I<BOOST_ROOT>/boost directive, in addition to the usual -I required to find the boost headers. This needs to be fixed prior to release, such that only -I<BOOST_ROOT> is required. I am assuming that this is broken for the same reason that Barends chose not to put ggl in the boost namespace. Other than having to use the 'find' command to locate the appropriate headers for inclusion, and other documentation-related issues listed elsewhere in this review, I didn't experience much difficulty using the library. === How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? === On average, a couple hours a day, over the course of a week. Admittedly, I squandered too many hours justifying my own use case on the ML, which may have been better spent reviewing the implementation, and/or writing useful test cases. === Are you knowledgeable about the problem domain? === I have been a casual user (and occasional developer) of Computational Geometry and GIS algorithms at my current job for ~ 4 years. I have also taken a few (recent) graduate-level C.G. and numerical analysis courses. === Miscellany === The existing GGL mailing list(s) should probably be moved to boost/boost-users, and/or a boost-ggl list. Unless there is a compelling reason to maintain an external list (i.e. paid support, etc) , this will best serve the GGL users/developers. === Do you think the library should be accepted as a Boost library? === Yes, contingent on meeting a minimum level of documentation, as determined by the review manager and/or community. Thanks for putting so much work into this library! Jon

5 7

[Review] GGL review starts today, November 5th
by Hartmut Kaiser 07 Dec '09

07 Dec '09

Hi all, The formal review of the Generic Geometry Library (GGL) starts today, November 5, 2009 and will finish November 15, 2009. GGL is being developed by Barend Gehrels, Bruno Lalande and Mateusz Loskot, with substantial input from this Boost mailing list. ------------------------------------------------ About the library: GGL defines concepts for geometries and implements some algorithms on such geometries. GGL is header-only, and can be applied in all software where geometry plays a small or a larger role. Users of the library can use just only one function, such as distance: int a[2] = {1,1}; int b[2] = {2,3}; double d = ggl::distance(a, b); Library users can also use the library in combination with std::vector, boost::tuple's and boost::ranges, such as: std::vector<boost::tuple<double, double, double> > line; line.push_back(boost::make_tuple(1, 2, 3)); line.push_back(boost::make_tuple(4, 5, 6)); line.push_back(boost::make_tuple(7, 8, 9)); double length = ggl::length(line); GGL can also be used in combination with custom or legacy geometries, adapting them to the library specializing traits classes or using registration macro's. Formally, GGL contains a dimension-agnostic, coordinate-system-agnostic and scalable kernel, based on concepts, meta-functions and tag-dispatching. On top of that kernel, algorithms are built: area, length, perimeter, centroid, convex hull, intersection (clipping), within (point in polygon), distance, envelope (bounding box), simplify, transform, convert, and more. The library is also designed to support high precision arithmetic numbers, such as GMP. The GGL might be used in all domains where geometry plays a role: mapping and GIS, gaming, computer graphics and widgets, robotics, astronomy... The core is designed to be as generic as possible and support those domains. However, for now the development has been mostly GIS-oriented. The GGL team proposes an extension model, very similar to what is used by GIL. The proposal as it is in the Boost Sandbox included three extensions: - SVG because it is used in the samples and to generate the documentation - WKT because it is used in the tests - The geographic coordinate system because it is used in some of the examples, also showing how other coordinate systems can be implemented There are more extensions, not included now, a.o.: - Spatial index - Map projections The proposed GGL has seen four previews, many discussions and many changes in design and implementation, based on those discussions. Previews were published on this list January '08, March'08, October'08 and February'09. GGL can be found in the sandbox https://svn.boost.org/svn/boost/sandbox/ggl/formal_review, including source code, examples, unit tests and documentation. Documentation can also be found online: http://geometrylibrary.geodan.nl/formal_review ------------------------------------------------------- Everybody on this list is invited to participate in this formal review. I hope to see your review of this library, including your vote, and I welcome your participation in the discussions on the Boost mailing list. Please always state in your review, whether you think the library should be accepted as a Boost library. 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 Hartmut Review Manager ------------------- Meet me at BoostCon http://boostcon.com

20 78

[msm] internal/external conflicting transitions
by Michael Caisse 07 Dec '09

07 Dec '09

Christophe - The docs have a section on "Conflicting Transitions". It has two conflicts described: 1. an event enables multiple transitions because multiple guards test valid, 2. an internal and external transition are both enabled I see a clear definition for the behavior of #1 in the discussion; however, it is not clear that #2 will follow the same rule. It was actually a little surprising to me that the order of the transition definitions affected #2. (Well, maybe not surprising ... but not what I wanted). I used the SimpleTutorial to test the behavior with: a_row < Stopped , play , Stopped , &p::test_conflict >, a_row < Stopped , play , Playing , &p::start_playback >, a_row < Stopped , open_close , Open , &p::open_drawer >, and a_row < Stopped , play , Playing , &p::start_playback >, a_row < Stopped , play , Stopped , &p::test_conflict >, a_row < Stopped , open_close , Open , &p::open_drawer >, The last transition defined "wins" in a conflict. I believe that there is strong historical precedent that internal transitions are always considered before external transitions. I suspect that if this is the behavior that I desire then I can order the transitions so that internals are listed last. Perhaps some additional clarification for case #2 in the docs would be helpful. Thanks - michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

1 0

[msm] choice (point) pseudo state
by Michael Caisse 07 Dec '09

07 Dec '09

Christophe - I am modifying my code generator to target MSM so that I can evaluate some larger machines and run existing test suites that I use. I do not see the concept of a choice point. Did I miss it? It looks like it can be modeled with a state having only anonymous transitions and appropriate guards. michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

1 0

[msm] history pseudo states
by Michael Caisse 07 Dec '09

07 Dec '09

Hello Christophe - I am trying to understand your implementation of history. In the MSM documentation it states: "As explained in the BoostCon09 paper <cid:part1.00040908.05020506@objectmodelingdesigns.com>, Histories are weird. First, there can be just one." In the boostcon09 paper it also states [page 5]: "To be frank, History is not a completely satisfying concept. First of all, there can be just one history pseudostate and only one transition may originate from it." I'll not contend with the views of history yet. They can be a very powerful concept. What I'm unclear about is the statement that there can be just one. According to the UML specification there can be just one per composite state. That of course makes perfect sense. MSM has SubmachineStates instead of composite states; however, the same "rule" applies to both. Does MSM obey this definition or is there a further constraint? My confusion might be partially attributed to not having finished reading all of the docs. Thanks - michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

1 0

[msm] eUML guard/action location
by Michael Caisse 07 Dec '09

07 Dec '09

Christophe - Just a quick question about eUML syntax. I think the concept is great. The placement of the guard and actions doesn't strike me as natural. CurrentState() + cool_event() = DestState() [Guard()]/(action()) There are a couple of reasons for this. One is the conceptual ordering of how the UML machine works. 1. In CurrentState 2. Receive cool_event 3. Check for transitions matching cool_event 4. Found match 5. Verify guards 6. Guards pass 7. Handle CurrentState exit action 8. Take transition and handle transition action 9. Handle DestState entry action 10. Reside in DestState Another reason that I find it unnatural is that the event/guard/action is associated (in my mind) first with the transition leaving the CurrentState. The transition obviously is associated with the DestState but the event/guard portions "occur" while in the CurrentState. UML already (via its notation) pulls together the event and action. What do you think about this instead? CurrentState() + cool_event()[Guard()]/(action()) = DestState() I think it more closely matches the UML syntax. Best regards - michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

1 0

Two FSM libraries, one interface
by David Bergman 07 Dec '09

07 Dec '09

NO, this is not yet another attempt of mine to irritate people by claiming that the interfaces of Statechart and MSM are similar ;-) When evaluating MSM, both from an interface and performance (read "abuse" ;-)) point of view, I decided to create a common wrapper for both libraries, since I host this awkward notion that the mapping from such a (much more abstract and less verbose) wrapper to the underlying libraries should not vary that much. Be that due to the interfacial commonalities between the two libraries or my great mapping skills :-) Anyway, I just got tired of being a grumpy old passive man, so decided to put some of my money (or time) where my mouth is. I will write more about this side effect of my analysis in a blog post later, as well as provide access to the actual header file. I just want to gauge the interest for such an abstraction layer *for non-complex FSM needs*. I do not claim any commutation, but at least we have a decent sub diagram with arrows from my abstract interface to each one of Statechart and MSM for non-complex cases. I currently imaginatively call this common interface "abstract_fsm.h". It preprocesses a common description to either Statechart or MSM, decided by setting either "USE_SC" or "USE_MSM". It is currently limited to non-nested machines without guards, and only handles the specification, not execution. But, the end result is pretty cool. So, hold on to you LISP hats (there will be parentheses...) and see for yourself. This is a simple FSM app using that abstraction: #include <iostream> #include "abstract_fsm.h" FSM_DEF(Machine, // The type of the FSM (Play)(Stop), // the events // The transitions (including the states) ((Stopped, ((Play, Playing, { std::cout << "starting to play" << std::endl; })) ((Stop, Stopped, { std::cout << "stopping" << std::endl; })))) ((Playing, ((Stop, Stopped, { std::cout << "staying in Stopped" << std::endl; })))) ) int main(int argc, const char* argv[]) { Machine mach; mach.initiate(); mach.process_event(Stop()); mach.process_event(Play()); mach.process_event(Stop()); } Everything is contained in that FSM_DEF construct, including events and transitions (including the source states). One cool thing is that the actions are right there. I have no clue as to the general usability of this abstract layer, but it serves the immediate purpose of testing runtime performance of the two libraries by merely using USE_SC or USE_MSM. This application is preprocessed to this Statechart app (by using -E -DUSE_SC...): #include <boost/statechart/event.hpp> #include <boost/statechart/state_machine.hpp> #include <boost/statechart/simple_state.hpp> #include <boost/statechart/transition.hpp> struct Play : boost::statechart::event<Play> {}; struct Stop : boost::statechart::event<Stop> {}; struct Stopped; struct Playing; struct Machine : boost::statechart::state_machine<Machine, Stopped> { void actStoppedPlayPlaying(const Play& evt) { std::cout << "starting to play" << std::endl; } void actStoppedStopStopped(const Stop& evt) { std::cout << "stopping" << std::endl; } void actPlayingStopStopped(const Stop& evt) { std::cout << "staying in Stopped" << std::endl; } }; struct Stopped : boost::statechart::simple_state<Stopped, Machine> { typedef boost::mpl::list< boost::statechart::transition<Play, Playing, Machine, &Machine::actStoppedPlayPlaying> , boost::statechart::transition<Stop, Stopped, Machine, &Machine::actStoppedStopStopped> > reactions; }; struct Playing : boost::statechart::simple_state<Playing, Machine> { typedef boost::mpl::list< boost::statechart::transition<Stop, Stopped, Machine, &Machine::actPlayingStopStopped> > reactions; }; int main(int argc, const char* argv[]) { Machine mach; mach.initiate(); mach.process_event(Stop()); mach.process_event(Play()); mach.process_event(Stop()); } And when preprocessing to an MSM app (by using -E -DUSE_MSM...): #include <boost/msm/back/state_machine.hpp> #include <boost/msm/front/state_machine_def.hpp> struct Play {}; struct Stop {}; struct Stopped : boost::msm::front::state<> {}; struct Playing : boost::msm::front::state<> {}; struct Machine_ : boost::msm::front::state_machine_def<Machine_> { typedef Stopped initial_state; void actStoppedPlayPlaying(const Play& evt) { std::cout << "starting to play" << std::endl; } void actStoppedStopStopped(const Stop& evt) { std::cout << "stopping" << std::endl; } void actPlayingStopStopped(const Stop& evt) { std::cout << "staying in Stopped" << std::endl; } typedef boost::mpl::vector< a_row<Stopped, Play, Playing, &Machine_::actStoppedPlayPlaying> , a_row<Stopped, Stop, Stopped, &Machine_::actStoppedStopStopped> , a_row<Playing, Stop, Stopped, &Machine_::actPlayingStopStopped> > transition_table; void initiate() {} }; typedef boost::msm::back::state_machine<Machine_> Machine; int main(int argc, const char* argv[]) { Machine mach; mach.initiate(); mach.process_event(Stop()); mach.process_event(Play()); mach.process_event(Stop()); } It is worth noting that once I had wrestled with Boost.Preprocessor and created a mapping to Statechart, the MSM mapping took 14 minutes, and a lot of meta functions were common between the two cases. /David

1 0

Does anyone know what happens to all we write at home?
by Vladimir Batov 07 Dec '09

07 Dec '09

Does anyone know what happens to all we write at home? We habitually put the 'boost' license on such work. However, can your employer claim that *anything* you do belongs to "him" and to slap you with a violation of Confidentiality Agreement or Intellectual Property Agreement? V.

3 2

[rdb, fusion, profile_templates] 0.2.03 - compilation speedup
by Jean-Louis Leroy 06 Dec '09

06 Dec '09

I have uploaded version 0.2.03 to the vault. No new features this time but improvements in compilation speed. The test_odbc project took more than 4.5 minutes to build in debug mode (msvc9, ThinkPad x200s, Intel L9400 with 2 cores @ 1.86 Ghz, 4 Gb RAM) and...17 minutes on a 2Gb RAM computer ! This was becoming unbearable. After a run through profile_templates - thanks to Steven Watanabe for creating this tool ! - I replaced the fusion::maps that were used to gather clause information in sql statement templates with a simpler, less flexible, less orthogonal and less capable version of my own. The result was a 41% speedup (calculated as (old-new)/old) on the 4 Gb computer and 85% on the 2Gb one. The number of template instantiations, as reported by profile_templates, dropped from 86330 to 62771. If someone is interested I can post the complete profiling reports. I plan to focus on datetime support now... Jean-Louis

2 2

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

06 Dec '09

Hi David, >>> 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? > Yes, which is why I brought it up; see (*) below. Thanks for doing it, I see this as an important point. >* - Yes and no... As I explained in my note to Dave, I did not mean API when I wrote that dreaded sentence about the interface similarity, >I meant it in a more abstract sense. BUT, for simple cases, where we do not deal with transition guards or nested machines, >there actually is a quite close similarity even at a syntactical level. Agreed. But isn't the interface similarity mainly due to the very tightly specified problem domain and to the fact that we all use the excellent MPL tool? Of course, simple state machines using MPL will all look slightly the same, as will do those based on OO-principles with each other. When a new implementation (even based on the same tools) brings important advantages, shouldn't it be considered for inclusion? >They treat guards differently. Yes. I'll come back to it in a minute. >> 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. >We are now arguably leaving theoretical FSM's and entering pragmatic machines :-) Sure. Theoretical FSM's are anyway about the same for all. My point is to show that differences between MSM and Statechart are subtle but play an important role. >> 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? > No ;-) Then, I'm not an expert with Statechart but allow me to try to help ;-) I think (please correct me if I'm wrong) it'd look about like: sc::result react(const Event& evt) { if (some_other_condition(evt)) { action(evt); return transit<State3>();} else if (some_condition(evt) { action(evt); return transit<State2>();} } And this is one important difference, not just a syntactic one. With SC, the structure of the state machine is hidden in the code, which will make your conversion tool harder to write on the direction SC->MSM as the tool will not just be able to parse the code but also understand it. Add a few more actions or other piece of code and I wish your tool luck ;-) OTOH you get more flexibility. So, my point is, there are more differences that syntactic ones, as long as you make more complicated machines. I still agree with you on the point that interfaces are not "widly different" but I put this on the account of a clearly specified problem domain and the fact that most of Boost uses the same MPL tool (due its huge power. Thanks Dave, thanks Aleksey ;-) ). >Yes, there are syntactical differences and decouplings of state vs machine which makes MSM a nicer tool; >and, didi I mention that MSM is in my simple test cases six times faster? You did and I thank you for adding your own tests to the review. As an extra note, if you are ready to give up some state features and need just an enum for the states, you might want to take the FSM in the MPL book. It would probably even be possible to make from it a backend which could at some point partly support the different MSM front-ends. MSM does not yet support this solution in order to deliver a back-end supporting the state features specified by UML (again the restricted problem domain) but it is one of the backends I consider for addition. Do we agree to leave the dreaded sentence behind us and replace it with one saying that both libraries solve the same problem using a wildly different implementation with similarities in the syntax? Christophe

2 1

[chrono] type_traits/common_type and integer/ratio
by Vicente Botet Escriba 06 Dec '09

06 Dec '09

Hi, I'm looking on how to continue with the Boost.Chrono library and I would like to know if * Boost.TypeTraits could take care of the common_type class template. * Boost.Integer could take care of the ratio class template. In this way Boost.Chrono will contain only the time related facilities, duration, time_point and Clocks. In order to minimize the task and been able to purpose as soon as possible the library for review I would like to concentrate on the implementation of the standard proposal and let for a future release the facilities Beman added as * Class template timer, with typedefs: * `system_timer` * `monotonic_timer` * `high_resolution_timer` * Process clocks and timers: * `process_clock`, capturing real, user-CPU, and system-CPU times. * `process_timer`, capturing elapsed real, user-CPU, and system-CPU times. * `run_timer`, convenient reporting of process_timer results. What do you think about this approach? Best, Vicente -- View this message in context: http://old.nabble.com/-chrono--type_traits-common_type-and-integer-ratio-tp… Sent from the Boost - Dev mailing list archive at Nabble.com.

6 19

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

06 Dec '09

>> Repeating: the MSM/Statechart overlap in features and interface is quite >> unique to Boost. > > > They definitely overlap in features and also in intent, but my understanding > is that the interfaces are vastly different, and that's an important > distinguishing feature. Am I missing something? No you aren't. At first look, they seem similar, but as soon as you concretely start writing a state machine with both libraries, like Juraj could tell you (he did it), you'll start seeing that the differences are there. Of course, both use states, events and transitions but that's about all. MSM bases itself on the transition table, while with Statechart, the user writes his decisions in the react function. Composites are full state machines with MSM, a simple state with Statechart. MSM uses more metaprogramming, Statechart follows a solution with multiple translation units. Etc. etc. The point is, the interfaces differ, the normal usage even more and the "correct" way to use each (in the authors' eyes) much more as both follow a completely different philosophy, as many heated discussions showed. Christophe

4 4

arithmetic meta functions and traits
by Zachary Turner 06 Dec '09

06 Dec '09

Is there any use for something like this? Following compiles on MSVC 9.0. Despite the simplicity of the final template, it was *NOT* easy to get this working given that there's about 10 ways you should be able to do this according to the standard, but poor SFINAE support makes it next to impossible to get your compiler to accept anything. Since it doesn't do anything highly fancy, I would wager it works on GCC and other compilers as well, although it needs to be tested. struct no_type { }; #define MAKE_BINOP_METAFUNCTIONS(op, binop, traits) \ template<typename T, typename U> no_type operator op (T, U); \ template<typename T, typename U> \ struct traits \ { \ typedef BOOST_TYPEOF(T() op U()) type; \ }; \ template<typename T, typename U> \ struct binop \ { \ private: \ typedef typename traits<T,U>::type result_type; \ public: \ static const bool value = !boost::is_same<result_type,no_type>::value; \ }; MAKE_BINOP_METAFUNCTIONS(+, is_addable, addition_traits); MAKE_BINOP_METAFUNCTIONS(-, is_subtractable, subtraction_traits); MAKE_BINOP_METAFUNCTIONS(/, is_dividable, division_traits); MAKE_BINOP_METAFUNCTIONS(*, is_multipliable, multiplication_traits); Obviously you can define other operators similarly, as well as unary operators. Zach

2 4

Re: [boost] [explore] Library Proposal: Container Streaming
by Brian Wood 06 Dec '09

06 Dec '09

Jeff Flinn writes: > Regardless of the approach taken, I think this would be a useful > facility. I've created a similar, albeit much simplified facility for > two separate projects in the last 5 years. There've been several more > projects that could have used the more general facilities that this lib > offers. I think an on line approach is helpful and we have a service that writes Print functions based on user input -- http://webebenezer.net/cgi-bin/enrobo.cgi. This input: (list<int>) results in this output: void Print(std::ostream& so, const list<int>& abt1) { int indentation = 0; so.fill(' '); so << "\nabt1: "; so << "list has " << abt1.size() << "\n"; indentation += 2; list<int >::const_iterator mediator1 = abt1.begin(); list<int >::const_iterator omega1 = abt1.end(); for (; mediator1 != omega1; ++mediator1) { so.width(indentation); so << " "; so << (*mediator1); so << "\n"; } indentation -= 2; so << std::flush; } Brian Wood http://www.webEbenezer.net <http://www.webebenezer.net/> "The Kingdom of Heaven is like a treasure hidden in the field, which a man found and hid again; and from joy over it he goes and sells all that he has and buys that field."

1 0

MSM Review period extended to Dec 13th
by David Abrahams 06 Dec '09

06 Dec '09

Hi All, We thought this might happen because of the Thanksgiving holiday, and it did: we are extending the review period for the Meta State Machine library until Dec 13th. However, please don't let that delay your review; we'd like to see them all as soon as possible. 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? -- David Abrahams BoostPro Computing http://boostpro.com

2 1

Regex allocator support
by Fred Sundvik 06 Dec '09

06 Dec '09

Hi, We recently had to use the regular expression library in conditions where there was no available physical memory, for reporting resource consumption when our console game runs out of memory. This wasn't possible however due to the fact that the basic_regex does some dynamic allocations and doesn't provide any allocator specialization, allthough match_results for example does. So we modified the boost code a little bit and added a new template paramter for the allocator, and made constructors that takes allocators as parameters. This was quite straightforward to do, the allocators just had to be passed forward to the all internal classes it uses. The shared_ptr's had to be changed to use the three parameter constructor, that takes a a deleter and allocator, to prevent them from allocating. The mem_block_cache system was a bit more complicated. Initially we disabled it completely, but that obviously wasn't the best solution. So we figured out, that we can use a custom allocator as default, instead of std::allocator. That custom allocator then had to be specialized for the mem_block_nodes, and the funcion calls to get_mem_block replaced by allocator calls. Our implementation isn't ideal, though as we used mem_block_node as the specialization, and to pass the correct size to the allocator, we allocate BOOST_REGEX_BLOCKSIZE / sizeof(mem_block_node) of them, this way it works for allocators that don't specialize for mem_block_node(but only if the size is dividable by sizeof(mem_block_node) ). Better would probably be to make a new type that is BOOST_REGEX_BLOCKSIZE big. We also found another problem with allocation, the match_result::format functions only takes string_type, that isn't specialized by any allocator as they input. This made it impossible to call them with strings using different allocators. So we added specializations of those functions for different allocators and traits. There are probably more functions like that, but since our code doesn't use them there was no need to change anything. So my question is, what are the chances that theese kinds of modificiations gets implemented in the actual library, and possibly in the next c++ standard library as well? I consider it a quite big design flaw to not have any control of the internal allocations, so for me this a quite big thing. Obviously we are doing well with the modifications we made here internally, but there are other applications too that would benefit, many embedded applications for example. Would our code changes be of any use? The changes are only the minimal needed to make it work in our case, and there's many compiler and option permutations not taken care of, so obviously a lot of work would still be needed. Also there's no additional unit tests made. Fred Sundvik Bugbear Entertainment Ltd.

5 7

Notice: Boost.Atomic (atomic operations library)
by Helge Bahmann 05 Dec '09

05 Dec '09

Hello, as promised I have started extracting an atomic operations library. Current state is available at: http://www.chaoticmind.net/~hcb/projcets/boost.atomic It implements boost::atomic<TYPE> which faithfully mimics std::atomic<TYPE> as specified in the C++0x draft standard. As allowed by the standard, operations transparently fall back to locking when the underlying architecture does not support the requested operation, so the library already contains a "fallback" implementation that works an all platforms (using mutex from boost::thread). It currently natively supports gcc/x86, gcc/powerpc and gcc/alpha (I can vouch for the correctness of the implementations on these targets). It contains some entirely untested support for building implementations from CAS operations on other systems (e.g. _InterlockedCompareExchange on win), so I would greatly appreciate any feedback if it works/doesn't on any particular platform. There is some preliminary documentation, but not in boostdoc format -- after unsuccessfully struggling with bjam/boostbook & friends for a few hours I simply gave up and reverted to trusty old doxygen :( Is there any step-by-step guide on how to create, build and document a new library? I could really use that as the boost build and documentation system is pretty alien to an autotools-accustomed guy like me. Best regards Helge

10 33

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

05 Dec '09

Hi David, > It is sad that my comments are construed as criticism of MSM, since they merely point out the (I thought obvious...) >similarities with another library already in Boost. >After having tried MSM for a few days, most of it rocks, and I will provide a review later today. Oh I didn't take it as a criticism of MSM at all, merely of a valid issue which will have to be solved in Boost at some point because, as Boost grows, it is bound to happen again. I'll look at your review with great interest and thank you for taking the time to write it. To the core of your point, which is actually a valid concern. I agree that MSM and Statechart are solving the same problem. To explain what I (and probably Andreas) mean, let's look at the problem from a different angle. Let's suppose we'd build a Statechart 2.0. How would it look like? Would it go for the MSM way, putting as much as possible on the compiler, at the risk of breaking it, or the Statechart way, less metaprogramming and easier on compilers but slowlier and with a less descriptive interface (in my opinion)? Would it go for a transition table way or a state::react way? What kind of state storage would it take? And so on and so on. What is likely is that we'd probably not even manage to agree on the goals, much less on the design or the implementation. MSM comes from my frustration with not managing to make Satechart do what I needed. This shows that the philosophy of both authors is quite different and likely incompatible. Christophe

1 0

Fixed bug in filesystem library ?
by Luca Severini 05 Dec '09

05 Dec '09

Hello everyone, I'm a newbie to boost libraries but I have some good experience in software development on Mac OS. Today I use downloaded and used boost for the first time. I use a MacBook Pro with Snow Leopard 10.6.2. The IDE is Xcode 3.2.1 Writing some very basic code to learn how to use the filesystem library I got assertions (below) simply iterating recursilvely through a local directory to list its content. /Developer/Test/TestFolder Boost_Test(57690) malloc: *** error for object 0xe518: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Investigating in the code I've found the assertions were triggered by two uninitialized std::string variables with same name passed to the functions detail::dir_itr_first() and detail::dir_itr_increment(). Initializing both to the simple content ".", directly in the constructor, seems to have fixed the problem (no assertions anymore). Here are the two functions I've changed in the file operations.hpp. The code I added is in green. Nothing has been deleted. I was thinking to follow the instructions to submit the fix but, please excuse me, I've found easier to send an email to the list. Hopefully someone with better knowledge of boost than me will submit gthe fix if it's the case o will find a better solution. Best regards, Luac Severini template<class Path> system::error_code basic_directory_iterator<Path>::m_init(const Path & dir_path) { if ( dir_path.empty() ) { m_imp.reset(); return detail::not_found_error(); } typename Path::external_string_type name("."); // String initialized to avoid assertion file_status fs, symlink_fs; system::error_code ec( detail::dir_itr_first( m_imp->m_handle, #if defined(BOOST_POSIX_API) m_imp->m_buffer, #endif dir_path.external_directory_string(), name, fs, symlink_fs ) ); if ( ec ) { m_imp.reset(); return ec; } if ( m_imp->m_handle == 0 ) m_imp.reset(); // eof, so make end iterator else // not eof { m_imp->m_directory_entry.assign( dir_path / Path::traits_type::to_internal( name ), fs, symlink_fs ); if ( name[0] == dot<Path>::value // dot or dot-dot && (name.size() == 1 || (name[1] == dot<Path>::value && name.size() == 2)) ) { increment(); } } return boost::system::error_code(); } template<class Path> void basic_directory_iterator<Path>::increment() { BOOST_ASSERT( m_imp.get() && "attempt to increment end iterator" ); BOOST_ASSERT( m_imp->m_handle != 0 && "internal program error" ); typename Path::external_string_type name("."); // String initialized to avoid assertion file_status fs, symlink_fs; system::error_code ec; for (;;) { ec = detail::dir_itr_increment( m_imp->m_handle, #if defined(BOOST_POSIX_API) m_imp->m_buffer, #endif name, fs, symlink_fs ); if ( ec ) { boost::throw_exception( basic_filesystem_error<Path>( "boost::filesystem::basic_directory_iterator increment", m_imp->m_directory_entry.path().parent_path(), ec ) ); } if ( m_imp->m_handle == 0 ) { m_imp.reset(); return; } // eof, make end if ( !(name[0] == dot<Path>::value // !(dot or dot-dot) && (name.size() == 1 || (name[1] == dot<Path>::value && name.size() == 2))) ) { m_imp->m_directory_entry.replace_filename( Path::traits_type::to_internal( name ), fs, symlink_fs ); return; } } }

2 1

[iostreams] 1.41 gzip filter regression
by Alexander Arhipenko 05 Dec '09

05 Dec '09

Hi guys, In 1.41 we are experiencing regression in boost::iostreams::gzip_decompressor. Almost 50% percents of our test *.gz files failed to decompress. Following code snippet usually throws gzip error: std::ifstream f(n, std::ios_base::in | std::ios_base::binary); if(!f) { std::cerr<<"cant' open "<<n<<'\n'; } namespace io = boost::iostreams; io::filtering_istream in; in.push(io::gzip_decompressor() ); in.push(f); std::istreambuf_iterator<char> b(in); std::istreambuf_iterator<char> e; std::cout<<n<<'\n'; std::copy(b, e, std::ostream_iterator<char>(std::cout) ); Maybe that is caused by incorrect api usage. In this case, sorry for the noise in advance. I've attached minimal example that reproduces the issue. Build showfile executable and run ./showfile myfile.odt.bz2.gz > result. You should have 'error: gzip error' on stderr. Regards

4 8

svn mergeinfo broken at the root.
by Steven Watanabe 05 Dec '09

05 Dec '09

AMDG Beman, I'm not quire sure what you did, but svn:mergeinfo doesn't work for me anymore. https://svn.boost.org/trac/boost/changeset/57638 destroyed the svn:mergeinfo for all the revisions that I had already merged (I have been doing all merges at the root). In Christ, Steven Watanabe

1 0

symbolic links while building boost
by Zachary Turner 04 Dec '09

04 Dec '09

I use Windows primarily, and typically after building boost, there are two copies of each library. One with the version extension such as -1_41, and the other without. My understanding is that the one without the version number is supposed to be a symlink to the one with the version number on platforms such as linux, but that on Windows it is just a copy of the file due to poor support for symlinks in windows. My question is whether there has been any talk of changing this. Windows has supported first class symlinks since Vista, so it would seem possible to have Vista and beyond actually use this functionality and create real symlinks. Thoughts? Zach

3 3

Re: [boost] Meta State Machine library review / MSM, question
by Christophe Henry 04 Dec '09

04 Dec '09

Hi Barend, >All my states are structs. Why is the state an integer here? How can I >(humanly or with MSM) translate that state to one of the states defined? >It works, I get a message, but still don't know which transition was not >provided... Unfortunately, no_transition is one of the few cases, where because of implementation details, MSM already crossed the compile-time / run-time boundary and all it has is the state id. Annex A shows the order in which the (usually hidden) state index is calculated. It's simply the order of appearance in the transition table. First are source states checked, then target states. Regards, Christophe

1 0

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

04 Dec '09

Hi all, Looks like there was a fair bit of discussion ;-) I'll try to give my take on the many discussed points. Jeffrey Bosboom wrote: >But I think this concern can be addressed if there is a documentation >page that compares the libraries that is included in (or linked from) >both libraries' documentation. This would make it much easier for a >user to choose one or the other without having to read the full >documentation for each. This sounds like a good idea to me. Not everybody followed the review. Andrew Venikov wrote: >I think an even better example would be map and hash_map. >They serve almost identical purpose but using totally different >techniques. The user of stl is expected to understand the differences >and chose the appropriate container. >Why not do the same with SC and MSM? Yes, we should really write a page explaining the trade-offs. David Bergman wrote: > I would even have welcomed some macros that introduce the state declarations for simplistic states, > from that transition table expression. There is something like this in eUML (on compilers with native typeof). Is this ok for you? typedef BOOST_TYPEOF(build_state( )) Paused; I can of course also add a macro for other compilers. David Bergman wrote: >Well, well, I seem to be the only one caring about this, and MSM sure is a fine library, >so I say 'welcome metamagical states!'. > NOTE: no, this was not a formal review ;-) I would welcome a formal review though. It'd help the review manager make a decision ;-) Jeffrey Bosboom wrote: >Decide whether MSM should be included or not on its own merits. If so, >then MSM makes Boost better; we shouldn't be so concerned with being >perfect that we lose the opportunity to be better. I agree. We should always decide on a library's merit and then see how to handle it. It'd be sad to lose an opprtunity to make boost more valuable on organisatory grounds. This doesn't apply only to MSM. David Bergman wrote: >You have a good point there. Although I would rather have seen the MSM guys collaborate with the Statechart guys >on making Statechart easier to use (especially the expression of the transition table) and/or more performant, though. >If that would have led to a combined Statechart 2.0 (analogous to Spirit 2.0) in a year, I would wait. Merging would be quite hard. While both libraries seem to have almost the same interface, scratching the surface will show many differences. The reason is that both libraries follow a pretty different philosophy and use different techniques. The best which might be achieveable would be a new front-end in MSM trying to match as much as possible SC's front-end. It would probably work for simple state machines. It might even work for composites. I'm not expert enough in Statechart to tell if more is possible. And the question is if someone would ever need this. You would still get the compiler limitations (and maybe add some more due to the added metaprogramming) and not all of SC's features. Why to use it then? However, if someone is willing to take this task on, I'd be ready to help. Ideally we would have to do the same in Statechart for one of MSM's front-ends. Sounds like a lot of work. Christophe

1 0

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

04 Dec '09

Hi Barend, > First I thought (intuitively) that the eUML was meant for output, but > apparently that is not the case, it is an embedded language for defining > state machines, right Right. It is at the same time syntactic sugar and a way to concentrate more information in the transition table. For designers, it is sometimes helpful to be able to see the whole transition at the same time and in the same place. > Is is somehow possible to export an MSM to a Boost.Graph, either within > the library, or in an example or separate utility headerfile? Yes it is. A transition table is relatively easy to parse and thus it should be possible to generate a diagram from a transition table. As shown at the last BoostCon, I'm working on a tool doing just this, but a graph export might be a nice and useful addition. Regards, Christophe

2 1

[iostreams] input_sequence() questions
by Rob Riggs 04 Dec '09

04 Dec '09

I am attempting to adapt a windowed mmap reader, one which manages its mapping window using iterators, to a boost::iostreams direct source. I wrote this for reading large files via mmap on 32-bit platforms. The documentation shows that input_sequence() returns a pair of char pointers, not iterators. Is that really true or am I misreading the docs? http://www.boost.org/doc/libs/1_41_0/libs/iostreams/doc/concepts/source.html And it also shows that the input_sequence pointers are non-const. Why is that required for sources? Thanks, Rob

1 0

[explore] Extending namespace std
by Jeffrey Faust 04 Dec '09

04 Dec '09

The various threads of discussion have died down. These include the name of the library, whether it's useful or not, if it is useful can it be satisfied by an existing library, whether it should it be part of another library or be a library on its own, and gcc compiler switches. All of these are important and we'll have to address them at some point (except perhaps the compiler switches). One item that was brought up and dismissed is that the implementation relies on extending namespace std. I'd like to visit this item more thoroughly. In my opinion the ideal interface is the most natural, simplest, and the most familiar to C++ developers: 'cout << c;' where c is a container of type C. Going beyond this nominal usage employs stream manipulators, again something that is known. Other forms such as 'print(c);' or 'wrapper(cout) << c;' are inferior interfaces. The former is clumsy and the latter does not extend in a natural way. Whether or not you agree, for the sake of argument, let's start with the statement that 'cout << c;' is the ideal interface for this library. Let's discuss how we can make this work. The only way I know how to make 'cout << c;' work for all cases is to put operator<<(C) in the same namespace as C. For example, variant<C, ...> will not stream if C is in std and operator<<(C) is not. The only way operator<<(variant) can see operator<<(C) is through ADL. If anybody can think of a mechanism where this will work without extending namespace std, please speak up. In regards to extending namespace std, I understand what the standard says and I think I understand the reasons behind it. I could add something to namespace std that conflicts with an existing item, changing the behavior. This is certainly undefined behavior, and the standard is right in restricting it. I don't believe this problem exist for the explore library. If we know that on all supported compilers that extending namespace std in this way behaves correctly, what is the concrete problem of doing so? Thanks for reading, -- Jeff Faust

1 0

FunctionTypes broken in trunk
by Tor Brede Vekterli 03 Dec '09

03 Dec '09

Hi This is just a notice that the FunctionTypes library appears to have been broken since revision 56305, where several of the arity preprocessor files have become corrupted (more specifically, arbitrarily cut off) for some reason or another. The following extremely small test-case should fail to compile: #include <boost/function_types/function_pointer.hpp> int main() {} Best regards, Tor Brede Vekterli

3 2

[msm] Comments
by Nelson, Erik - 2 03 Dec '09

03 Dec '09

I erroneously posted this on boost-users yesterday... Reposting it here today. I'm not competent to present a full review of the Boost MSM library, but I've been following it with interest since I discovered it at BoostCon. I've read very many mailing list exchanges between Christophe and users during this time. The MSM review hasn't generated a ton of traffic, and I'd like to contribute my comments for whatever they're worth. >What is your evaluation of the design? The Boost MSM library seems to be a well-designed implementation of state machine logic that is faithful to the UML standard in most areas and thoughtfully deviates from (or extends) it in a few places. >What is your evaluation of the implementation? I feel like the implementation is a clean example of modern C++ and abstracts state machine concepts quite well. The transition table in particular is implemented elegantly. >What is your evaluation of the documentation? Adequate >What is your evaluation of the potential usefulness of the library? Very useful... I expect to need this library for my work within the next 3-6 months >Did you try to use the library? I have not used the library. >How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Something more than a quick reading, yet well short of an in-depth study. >Are you knowledgeable about the problem domain? Not particularly.. I've handwritten small state machines for GUI programming in the past As an additional comment, I believe Christophe himself typifies the best things about Boost. He has tirelessly worked on MSM and has been very supportive of users, incorporating many suggestions for improvement. MSM should definitely be included in Boost. Thanks Erik

1 0

[explore] Library Proposal: Container Streaming
by Jeffrey Faust 03 Dec '09

03 Dec '09

Jared McIntyre, Danny Havenith, and myself, with support from Jeff Garland have developed a library to stream standard containers to output streams. We would like to submit this for review. The requirements for this library were gathered at the BoostCon 2007 Library in a Week sessions. An initial review was held and further requirements were gathered at BoostCon 2008. Everything can be found in the boost vault <http://www.boostpro.com/vault/> . Here is a direct link to explore.zip <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=ex plore.zip&directory=&> . Some quick examples: #include <boost/explore.hpp> # include ... // simple vector example std::vector<int> vi; vi.push_back(1); vi.push_back(2); vi.push_back(3); std::cout << vi; // prints [1, 2, 3] // lets do some containers in containers std::vector<std::vector<int> > vvi; vvi.push_back(vi); vvi.push_back(vi); std::cout << vvi; // prints [[1, 2, 3], [1, 2, 3]] // associative containers std::map<std::string, int> si_map; si_map["hello"] = 1; si_map["world"] = 2; std::cout << si_map; // prints [hello:1, world:2] // containers of complex types std::list<date> dl; // date from boost::gregorian dl.push_back(date(2007, Jan, 1)); dl.push_back(date(2007, Jan, 3)); std::cout << dl; // prints [2007-Jan-1, 2007-Jan-3] // how about some boost container types: boost::array<std::string, 2> sa2; sa2[0] = "one"; sa2[1] = "two"; std::cout << sa2; // prints [one, two] Jeffrey Faust

27 56

[serialization] polymorphic archives runtime failure (was: polymorphic archives ... generates linker errors)
by Christoph Heindl 03 Dec '09

03 Dec '09

Hi, thanks to Roberts help I managed to get the polymorphic archives issue, discussed earlier at http://article.gmane.org/gmane.comp.lib.boost.devel/196984) resolved. However there remains a runtime issue I can't resolve: Based on demo_polymorphic.cpp I've re-created minimal test example, which I think is correct, that fails with the runtime assertion it != m_map.end(), file libs\serialization\src\basic_serializer_map.cpp, line 72 on load. The demo consists of 5 files that create the following scenario: class B inherits from polymorphic base class A. An object of B is allocated on the heap and serialized through a base pointer A using a polymorphic xml archive. Saving runs without problems. Next, B is loaded from the stream through a base pointer to A. This fails with the mentioned assertion. What makes me wonder is that changing the from polymorphic_xml_iarchive to xml_iarchive and from polymorphic_xml_oarchive to xml_oarchive will not produce the named assertion. As mentioned in my previous post, I tested this with boost 1.40.0 and msvc 9.0. I would be really, really, grateful if you could give the demo a try. I've prepared everything so that it is just a matter of copying the files to libs/serialization/example and adding [ demo_bsl_run demo_polymorphic_cheind : cheind_a cheind_b ] The files can be found attached to my lost post at http://article.gmane.org/gmane.comp.lib.boost.devel/197061 Best regards, Christoph

2 4

Re: [boost] Regex allocator support
by Fred Sundvik 03 Dec '09

03 Dec '09

Sorry for the previous message. Somehow I managed to send the message without a reply. A proper reply will follow soon. "Fred Sundvik" <fred.sundvik(a)bugbear.fi> wrote in message news:14525.2590220936$1259836768@news.gmane.org... >>> We recently had to use the regular expression library in conditions >>> where there was no available physical memory, for reporting resource >>> consumption when our console game runs out of memory. This wasn't >>> possible however due to the fact that the basic_regex does some > dynamic >>> allocations and doesn't provide any allocator specialization, > allthough >>> match_results for example does. So we modified the boost code a > little >>> bit and added a new template paramter for the allocator, and made >>> constructors that takes allocators as parameters. >>> >> <snip> >>> >>> So my question is, what are the chances that theese kinds of >>> modificiations gets implemented in the actual library, and possibly > in >>> the next c++ standard library as well? I consider it a quite big > design >>> flaw to not have any control of the internal allocations, so for me > this >>> a quite big thing. >> >> +1; I agree with the OP's sentiments, though I wouldn't say it's >> necessarily a "big" design flaw. However, I've never used the >> Boost.Regex library, and I don't know if the next standard specifies >> allocator parameters. I gather it doesn't? > > Sigh... no. > > The original regex++ library upon which the Boost version is derived > *did* > have allocators for everything. But during review folks felt quite > strongly > that: > > a) It was overkill. > b) Regex should be free to manage it's own memory - it's not a container > - > it's needs are much more complex than that - so it should be free to > optimize memory allocation and caching as it sees fit. > > As a result this facility was removed. Rightly or wrongly, no one on > the > stds committee questioned that design decision. > > Some specific comments on the other issues: > >>The mem_block_cache system was a bit more complicated. Initially we >>disabled >>it completely, but that obviously wasn't the best solution. So we > figured >>out, that we can use a custom allocator as default, instead of >>std::allocator. That custom allocator then had to be specialized for > the >>mem_block_nodes, and the funcion calls to get_mem_block replaced by >>allocator calls. Our implementation isn't ideal, though as we used >>mem_block_node as the specialization, and to pass the correct size to > the >>allocator, we allocate BOOST_REGEX_BLOCKSIZE / sizeof(mem_block_node) > of >>them, this way it works for allocators that don't specialize for >>mem_block_node(but only if the size is dividable by >>sizeof(mem_block_node) ). Better would probably be to make a new type > that >>is BOOST_REGEX_BLOCKSIZE big. > > Can you not just define BOOST_REGEX_RECURSIVE and use the stack based > implementation that does away with that altogether? > >>We also found another problem with allocation, the match_result::format >>functions only takes string_type, that isn't specialized by any > allocator >>as >>they input. This made it impossible to call them with strings using >>different allocators. So we added specializations of those functions > for >>different allocators and traits. There are probably more functions like >>that, but since our code doesn't use them there was no need to change >>anything. > > The current Trunk allows any string, container or character type, plus > function objects to be used as arguments to regex_format/regex_replace > etc, > which should avoid that problem. > >>We recently had to use the regular expression library in conditions > where >>there was no available physical memory, for reporting resource > consumption >>when our console game runs out of memory. > > I'm not sure I understand the issue here, that operator new doesn't > report > out of memory conditions? What does your allocator do that's different > to > operator new, and why not replace global new and delete with calls to > your > custom allocator? Just trying to get a handle on the issue... > >>So my question is, what are the chances that these kinds of > modifications >>gets implemented in the actual library, and possibly in the next c++ >>standard library as well? > > As noted above, I was asked to remove this feature during review, so I'm > not > *that* keen to put it back in! As far as the standard is concerned it's > > basically a done deal at this stage in the process - too late for such a > big > change. WRT Boost I'd really like to get a handle on the issue better > before making judgment - you seem to be one of very few people actually > using custom allocators ;-) > > Regards, John. > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Re: [boost] Regex allocator support
by Fred Sundvik 03 Dec '09

03 Dec '09

>> We recently had to use the regular expression library in conditions >> where there was no available physical memory, for reporting resource >> consumption when our console game runs out of memory. This wasn't >> possible however due to the fact that the basic_regex does some dynamic >> allocations and doesn't provide any allocator specialization, allthough >> match_results for example does. So we modified the boost code a little >> bit and added a new template paramter for the allocator, and made >> constructors that takes allocators as parameters. >> > <snip> >> >> So my question is, what are the chances that theese kinds of >> modificiations gets implemented in the actual library, and possibly in >> the next c++ standard library as well? I consider it a quite big design >> flaw to not have any control of the internal allocations, so for me this >> a quite big thing. > > +1; I agree with the OP's sentiments, though I wouldn't say it's > necessarily a "big" design flaw. However, I've never used the > Boost.Regex library, and I don't know if the next standard specifies > allocator parameters. I gather it doesn't? Sigh... no. The original regex++ library upon which the Boost version is derived *did* have allocators for everything. But during review folks felt quite strongly that: a) It was overkill. b) Regex should be free to manage it's own memory - it's not a container - it's needs are much more complex than that - so it should be free to optimize memory allocation and caching as it sees fit. As a result this facility was removed. Rightly or wrongly, no one on the stds committee questioned that design decision. Some specific comments on the other issues: >The mem_block_cache system was a bit more complicated. Initially we >disabled >it completely, but that obviously wasn't the best solution. So we figured >out, that we can use a custom allocator as default, instead of >std::allocator. That custom allocator then had to be specialized for the >mem_block_nodes, and the funcion calls to get_mem_block replaced by >allocator calls. Our implementation isn't ideal, though as we used >mem_block_node as the specialization, and to pass the correct size to the >allocator, we allocate BOOST_REGEX_BLOCKSIZE / sizeof(mem_block_node) of >them, this way it works for allocators that don't specialize for >mem_block_node(but only if the size is dividable by >sizeof(mem_block_node) ). Better would probably be to make a new type that >is BOOST_REGEX_BLOCKSIZE big. Can you not just define BOOST_REGEX_RECURSIVE and use the stack based implementation that does away with that altogether? >We also found another problem with allocation, the match_result::format >functions only takes string_type, that isn't specialized by any allocator >as >they input. This made it impossible to call them with strings using >different allocators. So we added specializations of those functions for >different allocators and traits. There are probably more functions like >that, but since our code doesn't use them there was no need to change >anything. The current Trunk allows any string, container or character type, plus function objects to be used as arguments to regex_format/regex_replace etc, which should avoid that problem. >We recently had to use the regular expression library in conditions where >there was no available physical memory, for reporting resource consumption >when our console game runs out of memory. I'm not sure I understand the issue here, that operator new doesn't report out of memory conditions? What does your allocator do that's different to operator new, and why not replace global new and delete with calls to your custom allocator? Just trying to get a handle on the issue... >So my question is, what are the chances that these kinds of modifications >gets implemented in the actual library, and possibly in the next c++ >standard library as well? As noted above, I was asked to remove this feature during review, so I'm not *that* keen to put it back in! As far as the standard is concerned it's basically a done deal at this stage in the process - too late for such a big change. WRT Boost I'd really like to get a handle on the issue better before making judgment - you seem to be one of very few people actually using custom allocators ;-) Regards, John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0