- Boost - lists.boost.org

[release management] Drop .gz and .zip release packaging?
by Beman Dawes 23 Oct '08

23 Oct '08

Boost releases are currently packaged four ways. With CR/NL line endings: boost_1_37_0_beta1.7z 27,340,204 boost_1_37_0_beta1.zip 57,017,457 With NL line endings: boost_1_37_0_beta1.tar.bz2 29,494,538 boost_1_37_0_beta1.tar.gz 36,436,716 I'd like to drop the .zip and .gz packages, starting with release 1.38.0. The primary motivation is a personal one; as release manager I do a lot of FTP transfers and would like to spend less time waiting for the big .zip and .gz packages to upload/download. The problem I see is that CR/NL users still download .zip files twice as often as .7z, and NL users still download about as many .gz packages as bz2. Comments? --Beman

11 11

[1.37] Showstopper? Documentation pdf build broken.
by John Maddock 23 Oct '08

23 Oct '08

Generation of pdf's from the docbook source appears to be terminally broken at present, for example: fop.render.pdf ..\..\..\bin.v2\libs\config\doc\msvc-8.0\debug\threading-multi\config.pdf (document [system-id file:/c:/data/boost/boost/trunk/libs/config/doc/../../../bin.v2/libs/config/doc/msvc-8.0/debug/threading-multi/config.fo] (validate [error] Element 'fo:inline' cannot be a child of 'fo:flow'. Only block-level elements are permitted in this context. [validation total: 1 error] Parse error: Invalid XSL FO source 'file:/c:/data/boost/boost/trunk/libs/config/doc/../../../bin.v2/libs/config/doc/msvc-8.0/debug/threading-multi/config.fo': 1 error found during validation The problem occurs with both FOP and XEP as the FO translator BTW. Anyone know where to look for the problem? John.

1 0

[1.37] Fixing doc typos in the beta.
by John Maddock 23 Oct '08

23 Oct '08

Someone's just emailed me regarding a doc typo in Boost.Regex. Is this the sort of QA issue that should be fixed between the beta and release? If so what criteria and procedure should we be applying? Cheers, John.

2 1

[pool] doubling algorithm
by Boris 23 Oct '08

23 Oct '08

Are there any plans to make the pool's doubling algorithm configurable? It would be great if it was possible for example to set an upper limit or to use constant chunk sizes (thus no algorithm at all). If there are no plans may I propose then some patches? I ask as I need to configure the pool as it eats too much memory sometimes. Boris

3 5

[test] Problems building Boost.Test
by Daniel Walker 23 Oct '08

23 Oct '08

Hello, I'm trying to build Boost.Test from SVN trunk. Linking the dynamic libraries fails with gcc 4.0 on OSX. Apparently, the option -h is passed to the linker. Not sure what that means. The complete bjam output follows. Daniel Walker $ echo $OSTYPE darwin9.0 $ gcc --version i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5488) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ bjam --version Boost.Build V2 (Milestone 12) Boost.Jam 03.1.16 $ svn update At revision 49428. $ bjam --toolset=gcc --with-test ...patience... ...found 659 targets... ...updating 2 targets... gcc.link.dll bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/libboost_prg_exec_monitor-gcc40-mt-1_37.dylib ld: unknown option: -h collect2: ld returned 1 exit status "g++" -o "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/libboost_prg_exec_monitor-gcc40-mt-1_37.dylib" -Wl,-h -Wl,libboost_prg_exec_monitor-gcc40-mt-1_37.dylib -shared -Wl,--start-group "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/execution_monitor.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/debug.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/cpp_main.o" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -Wl,--strip-all ...failed gcc.link.dll bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/libboost_prg_exec_monitor-gcc40-mt-1_37.dylib... gcc.link.dll bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/libboost_unit_test_framework-gcc40-mt-1_37.dylib ld: unknown option: -h collect2: ld returned 1 exit status "g++" -o "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/libboost_unit_test_framework-gcc40-mt-1_37.dylib" -Wl,-h -Wl,libboost_unit_test_framework-gcc40-mt-1_37.dylib -shared -Wl,--start-group "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/execution_monitor.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/debug.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/compiler_log_formatter.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/framework.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/plain_report_formatter.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/progress_monitor.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/results_collector.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/results_reporter.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/test_tools.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/unit_test_log.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/unit_test_main.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/unit_test_monitor.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/unit_test_parameters.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/unit_test_suite.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/xml_log_formatter.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/xml_report_formatter.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/exception_safety.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/interaction_based.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/logged_expectations.o" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -Wl,--strip-all ...failed gcc.link.dll bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/libboost_unit_test_framework-gcc40-mt-1_37.dylib... ...failed updating 2 targets... $

3 5

[1.37.0][serialization] unreferenced formal parameter warning
by Jeff Flinn 22 Oct '08

22 Oct '08

Robert, Can this be fixed: \boost_1_37_0\boost/serialization/extended_type_info_typeid.hpp(115) : warning C4100: 'p' : unreferenced formal parameter I'm also having trouble reading portable_binary file generated from boost_1_35_0. I'll try to reproduce with a smaller test case, but if you have any ideas on what to look for I'd appreciated it. Thanks, Jeff

3 4

[1.37.0] The release branch is closed; please do not commit
by Beman Dawes 22 Oct '08

22 Oct '08

The release branch is closed; please do not commit. Creating the beta is in process and it really screws things up if branches/release changes. --Beman

1 0

[1.37.0][serialization] possible loss of data warnings
by Jeff Flinn 22 Oct '08

22 Oct '08

Robert, The following warnings are the result of assigning int values to smaller data types in basic_binary_oarchive::save_overload. Any thoughts on clearing these up. Should these use numeric_cast? boost_1_37_0\boost/archive/basic_binary_oarchive.hpp(72) : warning C4244: 'initializing' : conversion from 'const unsigned int' to 'const unsigned char', possible loss of data boost_1_37_0\boost/archive/basic_binary_oarchive.hpp(77) : warning C4244: 'initializing' : conversion from 'const int' to 'const boost::int_least16_t', possible loss of data \boost_1_37_0\boost/archive/basic_binary_oarchive.hpp(82) : warning C4244: 'initializing' : conversion from 'const int' to 'const boost::int_least16_t', possible loss of data Thanks, Jeff

1 0

Re: [boost] New library in Vault: Msm (Meta State Machine)
by Christophe Henry 22 Oct '08

22 Oct '08

Hi Andreas, > Whether you'd want to work with entry & exit points in the alarm-beeps > case is a matter of taste. I personally wouldn't bother simply because it > seems unlikely that it can be reused anywhere. Do you mean your example is irrelevant or that reuse is not important? > To reach a definite verdict in this particular example we'd need to define > first what coupling in a state machine actually means. To my knowledge, > nobody has done that so far. Do you need more than common sense to know that if you need to see inside of a state machine you have coupling? > Given my first 3 paragraphs above, I hope it has become clear that a > state-boundary-crossing transition combined with an entry/exit-point is > *not* an encapsulation breach. Please forgive me for not agreeing. > Just to make sure we're not talking past each other: With "entry/exit > states" I guess you mean "entry point pseudostate" and "exit point > pseudostate" as defined in UML? Yes, are there other possibilities? > You have read the whole paragraph, right? I quote it here for clarity: > > <quote> > A submachine state is semantically equivalent to a composite state. The > regions of the submachine state machine are the regions of the composite > state. The entry, exit, and behavior actions and internal transitions are > defined as part of the state. Submachine state is a decomposition > mechanism that allows factoring of common behaviors and their reuse. > </quote> > > Note the first sentence. What is unclear here? Well, first why there are 2 terms. They are not equal but equivalent. So what is the difference? And what does it have to do with the subject? The important part is about reuse. Again this is a key point for Msm. > I don't follow. Isn't it a fact that the current version of Msm only > supports a single entry point for a composite state/submachine, namely the > initial state? There is the entry function of the sub state machine and the one of the initial state. > Exactly. However, IIUC, at the moment Msm only supports a single entry > point and a single exit point, which IMO also makes reuse harder than > necessary, see below. Again I have to disagree. When a program runs, it calls functions, which call other functions, etc. Now if you read a book of Model Driven Development, you'll probably find inside that a UML diagram and code are two views of the same model. And now we have it. You don't mind having a single entry point in a function, right? Why is it a problem in a diagram? And there we are again, multiple entry points in a function are labels and goto. > Firstly, let's be clear that any reasonable semantics definition for FSMs > (e.g. Harel, UML) absolutely requires that an entry action of a composite > state/submachine is called when the composite state/submachine is entered > and it doesn't matter at all how the state is entered (ordinary > transition, state-boundary-crossing transition). The same goes for the > exit action when the state is left. Unfortunately I understood it the other way and had to go to great lengths in the example you gave me to avoid the entry of the composite. Maybe I'm not the only unreasonable and this brings confusion? > To cut a long story short: I would encourage you to do either of the > following: > > 1) Allow state-boundary-crossing transitions (without entry/exit points). > Once you have these, entry- and exit-points are a no-brainer: An entry > point is simply a member typedef in the type that defines the submachine. > An exit-point can be supported just as easily by passing the destination > state(s) as template parameters to the submachine. > 2) Introduce entry & exit points as first-class concepts. Implementing a > state-boundary-crossing transition would then become a three step process: > a) define an entry/exit point, b) connect the point with an internal > state, c) connect the point with an external state. > > In my (admittedly biased) view and from a purely conceptual standpoint > (ignoring e.g. performance and other real-world stuff for the moment), > option 1 is clearly superior as it gives the user complete freedom how to > tackle his design problems. Option 2 would be acceptable, when it is clear > that supporting 1) requires too many trade-offs. My goal is not to reimplement Statechart but offer an alternative. It is a key point for Msm to provide an easy-to-use interface and increase reusability. And a list of destination states in the submachine definition does neither. But we already discussed this. I wrote in the documentation of Msm and repeated you that I could implement entry and exit pseudostates if users asked for it. And this only if I'm satisfied of the solution I would offer. Regards, Christophe

2 1

[Boost.Msm] On the necessity of state-boundary-crossing transitions
by Andreas Huber 22 Oct '08

22 Oct '08

Unfortunately, the original thread on this subject has led to so many side arguments that IMO the main point hasn't gotten the attention it deserves. I'll therefore try to summarize the main point here, so that hopefully a more focused discussion results. State machine behavioral standards like e.g. Harel & UML allow that transitions can cross state boundaries. One example for when this is beneficial is given in Fig. 8 of Harel's paper, which can be found here: <http://www.wisdom.weizmann.ac.il/~dharel/SCANNED.PAPERS/Statecharts.pdf> In this example, the main reason for the existence of the "alarms-beep" composite state is to avoid duplicating the two transitions triggered by the "any button pressed" and "30 sec in alarms-beep" events. The design of Boost.Msm and the arguments presented in the thread titled "New library in Vault: Msm (Meta State Machine)" seem to amount to the following claim: It is *invariably* bad practice to let transitions cross state boundaries. It follows that a state machine like the one shown in Fig. 8 should *always* be redesigned so that the transitions no longer need to cross state boundaries [1]. For Fig. 8, I claim that any such redesign will lead to information duplication in the diagram and the code implementing it. Moreover, it's probably safe to say that the ultimate bad practice in software engineering is expressing the same piece of information more often in the code than minimally required by the language [2]. Therefore, if following a best practice leads to code duplication then common sense would mandate to choose the lesser of the two evils. So, boundary-crossing transitions cannot always be avoided. Therefore, the challenge is to show that my claim for Fig. 8 is wrong by coming up with an alternative state machine design with the same observable behavior where transitions no longer cross state boundaries without duplicating anything (transitions, events, states) [3]. Note that the leaf-state in which the machine currently resides is part of the observable behavior. So any redesign must have at least the states "alarm 1 beeps", "alarm 2 beeps", "both beep" and "displays". Anything else can be changed to suit. Note that Fig. 8 shows just one widely used pattern that employs boundary-crossing transitions. Other patterns employ them as well. So, even if Fig. 8 can be redesigned without boundary-crossing transitions and without duplicating any information then this is just one data point. Suitable redesigns for the other patterns would have to be shown as well. [1] UML's entry & exit points are "just" encapsulation tools that allow the designer of a composite state to only expose the parts of the inner workings that must be visible from the outside world. So, a transition destined to an entry point does in fact still cross the state boundary. The same goes for a transition originating at an exit point. [2] Of course, all rules come with exceptions: In some cases code duplication can increase performance, which in turn might help to meet system requirements that otherwise couldn't be met. Under such circumstances of course the lesser evil is the code duplication. [3] The obvious solution of moving the "displays" state into the "alarms-beep" state just replaces the crossings of the transitions triggered by the "T hits ..." events with the crossings of the transitions triggered by the "any button pressed" and the "30 sec in alarms-beep" events. Depending on how the latter transitions are drawn, the crossings might not be visible graphically but on the conceptual level they still exist. This is why such transitions are often drawn as the one triggered by y shown in Figure 2 here: <http://www.codeproject.com/KB/cpp/Statechart.aspx> -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 0