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

Removing _1 from the global namespace (again)
by Peter Dimov 04 Jan '14

04 Jan '14

If we're going to call the next release 2.0, we'll be allowed some latitude with respect to breaking changes, so maybe this is the right time to finally remove the Bind placeholders from the global namespace. This will, however, break many things all around Boost (to say nothing about the outside world), as a quick grep can readily reveal. And, consequently, it will generate a certain amount of work for the maintainers of the affected libraries that, from their point of view, can appear unnecessary. So I'll need a certain amount of community consensus before going ahead and breaking everyone's code. :-)

14 15

[git] mode and whitespace changes remaining between develop and master
by Nathan Ridge 04 Jan '14

04 Jan '14

Hello, I am trying to follow the instructions for "Establishing a merge point after SVN Conversion" [1] for the Boost.Range library. After cherry-picking all the commits to develop that have not been merged to master, onto master (all locally, I have not pushed anything yet), I am finding that there are still some mode and whitespace differences between master and develop (see the diff at the bottom of the message). I cannot find the commits that are responsible for these changes - is it safe to just ignore them? Thanks, Nate [1] https://svn.boost.org/trac/boost/wiki/PostCvtMergePoint diff --git a/include/boost/range.hpp b/include/boost/range.hpp old mode 100755 new mode 100644 diff --git a/include/boost/range/adaptor/strided.hpp b/include/boost/range/adaptor/strided.hpp old mode 100644 new mode 100755 diff --git a/include/boost/range/adaptor/transformed.hpp b/include/boost/range/adaptor/transformed.hpp old mode 100644 new mode 100755 diff --git a/include/boost/range/algorithm_ext/is_sorted.hpp b/include/boost/range/algorithm_ext/is_sorted.hpp old mode 100644 new mode 100755 diff --git a/include/boost/range/detail/demote_iterator_traversal_tag.hpp b/include/boost/range/detail/demote_iterator_traversal_tag.hpp old mode 100644 new mode 100755 diff --git a/include/boost/range/detail/implementation_help.hpp b/include/boost/range/detail/implementation_help.hpp old mode 100644 new mode 100755 index 1f7d163..ca12fa4 --- a/include/boost/range/detail/implementation_help.hpp +++ b/include/boost/range/detail/implementation_help.hpp @@ -21,13 +21,13 @@ #include <wchar.h> #endif -namespace boost +namespace boost { namespace range_detail { template <typename T> inline void boost_range_silence_warning( const T& ) { } - + ///////////////////////////////////////////////////////////////////// // end() help ///////////////////////////////////////////////////////////////////// @@ -36,7 +36,7 @@ namespace boost { return s + strlen( s ); } - + #ifndef BOOST_NO_CWCHAR inline const wchar_t* str_end( const wchar_t* s, const wchar_t* ) { @@ -51,7 +51,7 @@ namespace boost ; return s; } -#endif +#endif template< class Char> inline Char* str_end( Char* s ) @@ -64,7 +64,7 @@ namespace boost { return boost_range_array + sz; } - + template< class T, std::size_t sz> inline const T* array_end( const T BOOST_RANGE_ARRAY_REF()[sz] ) { @@ -74,7 +74,7 @@ namespace boost ///////////////////////////////////////////////////////////////////// // size() help ///////////////////////////////////////////////////////////////////// - + template< class Char> inline std::size_t str_size( const Char* const& s ) { @@ -96,7 +96,7 @@ namespace boost } } // namespace 'range_detail' - + } // namespace 'boost' diff --git a/include/boost/range/iterator.hpp b/include/boost/range/iterator.hpp index 4ba9122..2966bdf 100644 --- a/include/boost/range/iterator.hpp +++ b/include/boost/range/iterator.hpp @@ -25,46 +25,46 @@ namespace boost { -#if BOOST_WORKAROUND(BOOST_MSVC, == 1310) - - namespace range_detail_vc7_1 - { - template< typename C, typename Sig = void(C)> - struct range_iterator - { - typedef BOOST_RANGE_DEDUCED_TYPENAME - mpl::eval_if_c< is_const<C>::value, - range_const_iterator< typename remove_const<C>::type>, - range_mutable_iterator<C>>::type type; - }; +#if BOOST_WORKAROUND(BOOST_MSVC, == 1310) - template< typename C, typename T> - struct range_iterator< C, void(T[])> - { - typedef T* type; - }; - } - -#endif + namespace range_detail_vc7_1 + { + template< typename C, typename Sig = void(C)> + struct range_iterator + { + typedef BOOST_RANGE_DEDUCED_TYPENAME + mpl::eval_if_c< is_const<C>::value, + range_const_iterator< typename remove_const<C>::type>, + range_mutable_iterator<C>>::type type; + }; + + template< typename C, typename T> + struct range_iterator< C, void(T[])> + { + typedef T* type; + }; + } + +#endif template< typename C> struct range_iterator { #if BOOST_WORKAROUND(BOOST_MSVC, == 1310) + + typedef BOOST_RANGE_DEDUCED_TYPENAME + range_detail_vc7_1::range_iterator<C>::type type; + +#else - typedef BOOST_RANGE_DEDUCED_TYPENAME - range_detail_vc7_1::range_iterator<C>::type type; - -#else - - typedef BOOST_RANGE_DEDUCED_TYPENAME - mpl::eval_if_c< is_const<C>::value, + typedef BOOST_RANGE_DEDUCED_TYPENAME + mpl::eval_if_c< is_const<C>::value, range_const_iterator< typename remove_const<C>::type>, range_mutable_iterator<C>>::type type; - -#endif + +#endif }; - + } // namespace boost #endif

2 1

Re: [boost] [AFIO] Callback API
by Bjorn Reese 03 Jan '14

03 Jan '14

Moving the discussion from boost-users to boost-dev, and thus the full context is quoted. On 12/21/2013 01:53 AM, Niall Douglas wrote: > On 20 Dec 2013 at 19:16, Bjorn Reese wrote: > >>> Can you suggest something? I honestly can't think of anything simpler >>> which also provides strong write ordering guarantees. >> >> I have not given this much thought so consider the following a >> brainstorm. > > We really ought to move this off boost-users ... but we'll see how it > goes. > >> I am thinking about an API that uses handles that looks more like Asio >> sockets. Write ordering can be handled, not by batching operations >> together, but rather calling the next write operation from the callback >> of the previous operation (Asio-style.) This will not always yield good >> performance, but oftentimes that is less relevant. If you need >> performance, then the "advanced" dispatcher API is available. >> >> So there could be a file handle (and directory handle) class for file >> (directory) manipulation calls, which hides all the details of the >> dispatcher etc. >> >> class file_handle >> { >> public: >> void read(buffer, read_callback); >> void write(buffer, write_callback); >> // and so on >> }; >> >> class directory_handle >> { >> public: >> void create(name, create_callback); // uses file(single) or dir(single) >> void remove(name, remove_callback); // uses rmdir(single) >> void watch(name, watch_callback); // directory monitoring >> // and so on >> }; > > I'm struggling to see the merit in such an approach - it would be > incredibly verbose and complex to write even simple solutions, > because i/o on files is not like sockets, *especially* that you > almost never must strongly order i/o across a sequence of multiple > sockets, but that is a very common case with files e.g. during ACID. First, it follows a pattern that is familiar to Asio users. So rather than you being the only one who can write applications on top of Afio, you get a broader community who are already familiar with the callback approach. Second, you can more easily combine it with Asio socket code to create compound services that mixes socket and file access. For instance, a peer-to-peer file distribution mechanism. > AFIO tries to help users to not write callbacks except when > necessary, but if you do want a user defined callback you simply > chain a call() or completion() operation to the item whose completion > you want called back upon. > > The idea is, you see, that you subclass the async_io_dispatcher class > with additional completion handlers, and use those as building blocks > for further subclasses of async_io_dispatcher. That hopefully gets > people to break up their callbacks into reusable completion handlers, > and saves people writing and debugging code. > Before you say "this should be in the documentation", yes it should > and will be after Paul gets his directory monitoring implementation > working. I'm thinking that will form the fourth section in the > beginner's tutorial - how to modularise and make reusable the > normally bespoke glue code which makes up traditional callbacks. It > might actually be worth adding a section 3b which shows how the naïve > approach in 3a is a very stupid idea :) > > As much as this sort of operation dependency graph based design works > well for its niche, I agree there is a swathe of code which ends up > looking like the find in files implementation, and for that hopefully > fibers will make look much more sane. I am not arguing against the current API. Instead, I am arguing for the addition of a more familiar Asio-style callback API. I have no trouble with a fiber-enchanced API (similar to Asio with coroutines.)

3 5

[git] Bumping git version requirement to 1.7.10
by Beman Dawes 01 Jan '14

01 Jan '14

https://svn.boost.org/trac/boost/wiki/Git/GitHome documents Boost's version requirement for Git, currently at 1.7.3. The regression scripts are using the clone --single-branch option, which became available at git 1.7.10, so we are planning to bump the version requirement. Done anyone have a problem with this? --Beman

6 11

[urgent] Testing help needed..
by Rene Rivera 31 Dec '13

31 Dec '13

I finally have the changes to the regression scripts sufficiently complete that I've managed to do a few minimal cycles of regression testing from the git repos. I now need some help in various ways: 1. General testing.. I need some of the regular testers to do runs with their setups with the new scripts. To test I suggest starting from a new testing location. And follow the usual instructions except get the run.py script from < https://raw.github.com/boostorg/boost/develop/tools/regression/src/run.py>. The options are exactly the same as the SVN version of the scripts (the --tag is mapped to master or develop as needed). If you run patch scripts you will have to adjust paths for the new arrangement. In particular the boost tree is now checked out to <testing-root>/boost_root. 2. Non-nix testing.. I don't have the time or resources available to check if the scripts and git invocations work on Windows. I need one person to test and likely make changes to the regression script to do the right things on Windows. Testing should be the same as above. But doing changes locally and testing them is challenging. The procedure I use is (as shell commands): > mkdir testing-dev > cd testing-dev > link <BOOST_DEVELOP>/tools/regression/src/run.py run.py > ln -s < BOOST_DEVELOP>/tools/regression/xsl_reports xsl_reports > ln -s < BOOST_DEVELOP>/tools/regression/src tools_regression_src > ./run.py --runner=<RUNNER_NAME> --skip-script-download --use-local That lets you edit the regression.py and run.py scripts in your local develop checkout. The options make it skip most of the run.py code, but otherwise make it behave as the regular testing except using your local changes. If you need to test changes to run.py in the normal use case you will have to commit+push the changes and then test. 3. Report generation.. It seems that the reports are failing to get generated for some reason. I suspect that the new scripts putting the git commit SHAs as the tested version number are messing up the results generation. I need someone familiar with the result generation to fix this. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

4 6

[Boost][Proto] BOOST_PROTO_USE_NORMAL_RESULT_OF seems incorrectly defined
by Hui Li 31 Dec '13

31 Dec '13

In proto/proto_fwd.hpp, based on how the macro BOOST_PROTO_USE_NORMAL_RESULT_OF is used, it's meant to be defined when the compiler supports c++11 decltype and implements N3276, for example, BOOST_PROTO_RESULT_OF is boost::result_of when BOOST_PROTO_USE_NORMAL_RESULT_OF is defined. However, its definition seems incorrect, and is inconsistent with the comments next to it. #ifdef BOOST_NO_CXX11_DECLTYPE_N3276 ^^^^^^ should this be #ifndef ? # // Proto can only use the decltype-based result_of if N3276 has been # // implemented by the compiler. # // See http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2011/n3276.pdf # ifndef BOOST_PROTO_USE_NORMAL_RESULT_OF # define BOOST_PROTO_USE_NORMAL_RESULT_OF # endif #endif Am i missing something here? Hui

2 2

Versioning of individual modules
by Peter A. Bigot 31 Dec '13

31 Dec '13

Forked from Re: [boost] [git] tagging in modules Context below. Guided questions follow the quoted context. On 12/30/2013 11:02 AM, Beman Dawes wrote: > On Thu, Dec 26, 2013 at 7:24 PM, Peter A. Bigot <pab(a)pabigot.com> wrote: > >> Not relevant to the original thread, but since I just noticed it: >> >> git-push by default does not push tags: you need to specifically ask for >> the tag to be pushed (by name), or use --tags. So this sequence does >> nothing visible: >> >> git tag -a 1.2 >> git push >> >> Personally I'd prefer if tag symbols were a little more informative than >> "1.2", and followed a pattern that places them in a namespace reserved for >> the module, such as timer-1.2. Because tags aren't normally pushed, >> they're useful for individual developers to use as markers. However, >> git-pull will automatically retrieve tags attached to commits that are >> fetched unless --no-tags is given, so if a repository (from boostorg, or >> another developer) defines (or moves) a tag it might overwrite your local >> tag without warning. So it's important to know what tags you can expect >> might conflict with those in a remote repository to avoid conflicts. >> > Updated: > > https://svn.boost.org/trac/boost/wiki/StartModWorkflow#Releasetags > <https://svn.boost.org/trac/boost/wiki/StartModMaint#Lightweightlibraryrelea…> > https://svn.boost.org/trac/boost/wiki/StartModMaint > #Lightweightlibraryrelease<https://svn.boost.org/trac/boost/wiki/StartModMaint#Lightweightlibraryrelea…> > > >> I'd also really like to see any module that uses internal versioning also >> provide a mechanism by which code can determine which version is being >> used. E.g., for the above there ought to be a <boost/timer/version.hpp> >> header which has: >> >> #define BOOST_TIMER_VERSION_MAJOR 1 >> #define BOOST_TIMER_VERSION_MINOR 2 >> >> Otherwise I'm not seeing any value for module-level version tags in the >> repository. Matter of taste, though. >> > While I'm sympathetic, we should get comments and buy in from library > maintainers before recommending this. Are a lot of libraries already doing > something similar? If so, what? And do we follow Rene's suggestion and > recommend Predef? Could you please start a separate discussion with a > subject that let's maintainers know this is affects them? Thanks! > > There is a tangentially related issue: The git and modular boost related > docs are being developed without any reference to or updating of existing > developer documentation. We need to get that underway. Ditto web site > changes. > > >> I would expect, on superproject release, that each module would continue >> to receive a boost-X.Y tag marking the module commit that corresponds to >> the submodule SHA1 used for the release. This is another reason to make >> sure module-level tags are clearly distinguished (lest somebody think the >> tag corresponds to a boost version rather than a module version). >> > Sounds about right, but we would need to work out the mechanics. Who does > the tagging? A script release managers run? General questions related to this topic: *) When a module pushes to master, must all commits that appear directly on the master branch be considered "stable" or is it only necessary that the HEAD always be stable? The context for this is actually in "[git] avoiding fast forward merges" at http://lists.boost.org/Archives/boost/2013/12/210110.php. It's primarily a superproject decision but module maintainers should be aware of it. *) Should all modules be assigned version numbers, or may module "releases" be unversioned master commits that "inherit" the Boost version when incorporated into a release? My opinion: Don't bother unless there's clear evidence that the module will be shipped or used outside of a versioned Boost installation. *) If a module has a module-specific version number, should it be expected to provide that version number in a standard location and name so that preprocessor directives interrogate and adapt user code based on it? What mechanism should be used for this? My opinion: Absolutely. If the module is named timer (sorry I keep picking on that module), then I would like to see: #include <boost/timer/version.hpp> define a macro BOOST_TIMER_VERSION which has an ordinal integer value that may be used in comparisons in preprocessor conditionals to select available features. I support Rene Rivera's suggestion to use the BOOST_VERSION_NUMBER macro from Boosts.Predef to accomplish this. Of course, if no modules need module-level versioning, this won't be necessary. *) What syntactic format should be used for git tags that record version numbers? My opinion: If the module is named timer, and the version number is 1.2, the tag timer-1.2 would be created and pushed to the boostorg timer repository by the timer maintainer. *) By what process is the superproject version associated with the commit on the master branch that is selected for a given Boost release? My opinion: If the Boost release is 1.56, every module incorporated into that release has a boost-1.56 tag created, identifying the master branch commit that is incorporated into the release. This tag would be added by the release manager when the superproject is tagged using a trivial "git submodule foreach git tag boost-1.56" in the superproject master branch followed by "git submodule foreach push origin boost-1.56" after sanity checks. Other inputs? Peter

2 3

[git-help] clone asks for passphrase for every library
by Nathan Ridge 30 Dec '13

30 Dec '13

Hello, I'm trying out git + modular boost for the first time. When I try to clone the repository as described here [1], I run into a problem where the recursive clone process asks me for my SSH key's passphrase for every submodule (library) that it is checking out. Is there a way to avoid this? Thanks, Nate [1] https://svn.boost.org/trac/boost/wiki/TryModBoost

4 4

[GIL] Pixel Layout Padding?
by TONGARI J 30 Dec '13

30 Dec '13

Hi there, The current gil::pixel design has a deficiency that you can't specify the align of pixel, for example, you can't have an RGBX pixel in GIL where X is padding. An alternative is to introduce a dummy channel for X, but that doesn't seem to be a good idea as we don't want to mess up the color space. So, maybe it'd be better to extend the current design, say, pixel<ChannelValue, Layout>, to something like pixel<ChannelValue, Layout, Align>. Then we can specify RGBX as pixel<uint8_t, rgb_layout_t, 4>, or XRGB as pixel<uint8_t, rgb_layout_t, -4> where minus means left justify. Ideas?

3 11

[git-help][urgent] How do I ignore an upstream change to one file?
by Rene Rivera 30 Dec '13

30 Dec '13

When I attempt to do an update of the boost superproject I get and error: Froggy:develop grafik$ git pull error: Your local changes to the following files would be overwritten by merge: tools/regression/src/regression.py Please, commit your changes or stash them before you can merge. Aborting Froggy:develop grafik$ I know I've made changes. I also know I don't want to throw away my changes. I also know that I don't want to merge the upstream changes to that one file. Hence.. How do I do a pull and have git ignore the upstream of only that file? (i.e. throw away the upstream changes because I know that my changes supersede them) Rene. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

8 13