- Boost - lists.boost.org

[git][multi_index] help merging from develop
by Joaquin M Lopez Munoz 26 Dec '13

26 Dec '13

Hi, I've tried following the instructions on https://svn.boost.org/trac/boost/wiki/StartModMaint but I obviously screwed up something. After creating my first merge point https://github.com/boostorg/multi_index/ commit/802543fd948b5cf41460addf2260693f08cf7f8d a subsequent merge from develop doesn't change any code: https://github.com/boostorg/multi_index/ commit/3239677c40b6e15d1bb49675cabb077460333538 even though branch develop is indeed different from (and more recent than) the code in master (it contains changes from about one month or so intended for Boost 1.56 that weren't published when the branch master was originally created) Heeeelp! Thanks for bearing with an incompetent Git user. Joaquín M López Muñoz Telefónica Digital

6 29

STL MAP Insertion and Updates ..!!
by Rahul Mathur 25 Dec '13

25 Dec '13

Hi, Looking for clue for below. Having a code which has to be inserted and updated with following status - 1. Insert with unique ID and initially with two values (viz . v1[1100] & v2[1000]) 2. If v1 [viz 1100] is NOT accepted exit. 3. Else value v2[1000] is accepted. With v2 being accepted, further insert with same unique ID on which v2 was accepted but now either with three values of v3[1001] or v4[1002] or v5[1003] and UPDATE the STL MAP. 4. Print the FINAL value (v2 or v3 or v5) of STL MAP with given unique ID. Did wrote below lines which works until value v1 [1000] insertion - --- #include <iostream> #include <algorithm> #include <map> #include <iterator> using namespace std; struct TBag { int UnqID; short value_code; TBag():UnqID(1234),value_code(1000){} }; TBag ms_var1; typedef std::map<int, short> map1; class Apple { map1 abc; public: void TypeInsert ( TBag *ms_var ); }; void Apple::TypeInsert ( TBag *ms_var ) { // Insert the 'UnqID' with messages of either TC = 1000 or 1100 only. typedef std::pair <map1::iterator, bool> itr; itr it1 = abc.insert( std::make_pair( ms_var->UnqID, ms_var->value_code ) ); typedef std::pair <map1::iterator, bool> itr; //Searching for value of Value Code = 1000 if (ms_var->value_code == 1100) { std::cout << "Value Error." << endl; exit (1); } if (it1.second) { // Checking correct insertion happened with 1000 std::cout << "Unq ID (" << it1.first->first << ") => " << "Value Code (" << it1.first->second << ")" << endl; std::cout << "The Status is .." << it1.first->first << " & " << it1.first->second << endl ; // INSERT now with Value code of either 1001 or 1002 or 1003 & finally UPDATE the STL MAP std::cout << "Final Status:" << endl ; for( map<int, short>::iterator iter = map1.begin(); iter != map1.end(); ++iter ) std::cout << iter->first << " " << iter->second << endl ; std::cout << "All Status successful." << endl; } else std::cout << "Status Error." << endl; } int main () { Apple ms; ms.TypeInsert( &ms_var1 ); return 0; } --- Any help is well appreciated ..:) ~ XoXo

2 1

[git] avoiding fast-forward merges
by Peter A. Bigot 25 Dec '13

25 Dec '13

Forked from Re: [boost] [git][multi_index] help merging from develop On 12/25/2013 06:03 AM, Daniel James wrote: > On 25 December 2013 11:57, Daniel James <daniel(a)calamity.org.uk> wrote: >> >> You can, but you don't need "-s ours": >> >> git checkout develop >> git merge master >> >> It should be a fast-forward merge. > > Oh sorry, I just remembered why I didn't suggest merging into develop. > The recommended work flow is not to do fast forward merges in order to > keep the two branches separate. Is this (keeping the two branches separate) the right rationale? I take "separate" to mean having no commit (SHA1) that is present on both branches (other than, for new modules, an initial master/develop branch fork which serves as the first merge base). A fast-forward merge necessarily places the same commit on both branches. git-flow recommends avoiding fast-forward merges to branch develop so the historical feature branch is preserved and to bundle the merge effect into a single commit, simplifying reversion. But this is more of a per-module traceability policy in the selected workflow than something that has a material effect on overall Boost process. In contrast, for Boost modules it's important not to do fast-forward merges to master, because a maintenance plan or email somewhere said super-project release managers may choose to select an earlier version on a module master branch to resolve integration failures.[*] To achieve that it must be possible for the manager to identify stable releases on the master branch, which would not be the case if a fast-forward merge added a commit series that did not stabilize until the final commit. The simplest derived requirement is that every commit on the master branch must represent a stable module, enforced by --no-ff. This I understood to be a strict requirement for the module master branch regardless of the module maintainers' chosen workflow within the module, but it does not affect workflow for develop. The effect of adopting these two practices may be that develop and master are kept separate. But that's not necessarily true if the develop branch itself is always kept at a releasable state, or if I misconstrued the strict requirement that stable release points on the module master branch be recognizable. If only master HEAD must be kept releasable the simplest work flow is to do a fast-forward merge from develop to master and push the results at any time where develop is considered stable enough to release. If there's an another rationale for keeping the branches separate I'd like to hear it to better my understanding of how git is expected to be used in Boost. Peter [*] I can't find the super-project release plan text about selecting non-HEAD module master branch contents from which this requirement is derived. https://svn.boost.org/trac/boost/wiki/ModBigPicture has a more lax requirement that pushes to master only be done when the content is stable, which will work in the more common case where there are no interoperability issues. The strict requirement makes sense, though, and I'm sure I read it somewhere.

1 0

[git-help] Clone / fetch specific submodule SHA?
by Rene Rivera 25 Dec '13

25 Dec '13

Does anyone know of a way to do a submodule update and clone that only fetches a specific SHA? In particular the SHA referenced in the superproject? 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

3 6

Reminder about links when running b2 headers
by Edward Diener 25 Dec '13

25 Dec '13

There was already a discussion about why the creation of hard links to individual files in the boost directory is inferior to the creation of symbolic links when the ability to create symbolic links is supported by the OS. As a reminder, if a hard link is created and the submodule file is replaced by git, the hard link will still refer to the old file contents. Thus testing, when it refers to any of the hard linked header files in the boost subdirectory, will go awry if this happens. Can we please have this updated at the module boost superproject level by some Boost Build guru so that symbolic links are created when allowed by the OS ? Even if, as on Windows, administrator rights are needed to create symbolic links it seems we could have some b2 headers alternative, aka 'b2 headers_wadmin', which would create symbolic links on Windows for users who have administrator rights. Of course on Linux this is not a problem. I realize this might not be easy to do even by a Boost Build expert but unless we want to hear squawks and complaints from Boost developers/end-users using our git/modular boost setup we need to change to symbolic links when possible.

3 6

[range]slicing any_range
by Takatoshi Kondo 25 Dec '13

25 Dec '13

Hello, I'm using the Boost.Range library (Version:1.55.0). When I use any_range with sliced adaptor, slicing operation doesn't return. Is my code something wrong? If it is a bug, I will create a ticket. Here is the minimized code that reproduces the situation: #include <vector> #include <iostream> #include <cassert> #include <boost/range/any_range.hpp> #include <boost/range/adaptor/sliced.hpp> typedef boost::any_range<int, boost::random_access_traversal_tag, int, std::ptrdiff_t> int_range; int main() { std::vector<int> v; v.push_back(0); v.push_back(1); v.push_back(2); { // works fine std::cout << "slice vector" << std::endl; int_range ir1 = v | boost::adaptors::sliced(0,2); std::cout << "slice vector finished" << std::endl; assert(ir1[0] == 0); assert(ir1[1] == 1); assert(ir1.size() == 2); } { int_range ir2(v); std::cout << "slice any_range" << std::endl; int_range ir3 = ir2 | boost::adaptors::sliced(0,2); // never return... std::cout << "slice any_range finished" << std::endl; assert(ir3[0] == 0); assert(ir3[1] == 1); assert(ir3.size() == 2); } } Takatoshi Kondo

1 2

[string_ref] degree of conformance to standard proposal
by Peter A. Bigot 24 Dec '13

24 Dec '13

(Background: I need a string_view with features in N3762 that aren't in N3442 (viz., pos parameters to the string methods). I'm trying to determine how much effort I should put into a set of patches to update the Boost implementation to the latest draft proposal.) The default constructor for Boost.string_ref produces an object which returns a null pointer from data(). N3442 and its successor N3762 both require the return value from data() to be non-null (http://isocpp.org/files/papers/N3762.html#h5o-5) GCC's libstdc++ folks solved this by adding a constexpr unit length string to serve as the base referenced object (http://gcc.gnu.org/ml/libstdc++/2013-11/msg00104.html) But for Boost I don't see how this can be changed without introducing a link dependency. In a cases like this, how closely does Boost want to track the standard proposals? Similarly, the standard proposal has settled on *string_view instead of *string_ref. Would Boost rename the library/class, or just introduce an alias? Peter

2 3

Re: [boost] [git] Effects of git submodule update
by Beman Dawes 24 Dec '13

24 Dec '13

On Mon, Dec 23, 2013 at 2:17 PM, Robert Ramey <robertmacleranramey(a)gmail.com > wrote: > > > On Monday, December 23, 2013 8:47:21 AM UTC-8, Beman Dawes wrote: > <snip ..> > > Comments welcome, >> > > Beman. > > This is beyond awesome !!!! (I can't believe I used the word "awesome") > > I've been dabbled with git on my own machine (now a new machine) for a few > months > and it's been OK but I never really "got" the branching/merging, etc..... > Mainly this > is because I didn't really have to yet. I've also been lurking around > waiting for > the smoke to clear with boost modularization - a cowardly position I know, > but expedient in my particular circumstances right now. The work you've > done > is getting this organized AND well explained is incredible. I'm aware > that the dust has to settle some. But this looks to me like it's going to > support a whole new trajectory for boost. It makes me very, optimistic > about future of boost and C++ in general. > > Personally, I don't think that it's too much to say that boost saved C++. > > And I don't think it's too much to say that you're saving boost right now. > Robert, thank you very much for the kind words. Knowing that work is appreciated is a strong motivation to continue! But do remember this is a long process with a lot of people contributing, both now and in the past. Dave Abrahams and Daniel Pfeifer deserve special mention for several years of work on the git and modular boost conversion implementation. The release managers and boost.build team are working on infrastructure. The testers will soon be doing their part. And mailing list participants are providing the ideas and feedback that drive the whole process. Thanks to all, --Beman

1 0

[Proposal] Boost Community Maintenance Team Goals and Guidelines
by Marshall Clow 24 Dec '13

24 Dec '13

Start here: https://dl.dropboxusercontent.com/u/9897665/community-maintenance.html I have contacted the authors of the libraries listed in Beman’s proposals. Some have responded affirmatively; the rest have not responded. So, I thought I would put down some thoughts about how the Boost Community Maintenance Team (Boost.CMT) should work. Goals (in priority order): 1. Keep things building on all the supported compilers (and as many others as possible) 2. Get the test matrix “all green” and keep it that way. 3. Fix the accumulated bugs; drive the bug count to zero, and keep it there. 4. Add new features. How I see this working: 0) We’ll set up a separate Boost.CMT mailing list. (the main developer list has too much traffic already) 1) People would pick a problem and post a note to the list that they were working on it. 2) {Optional] discussion ensues about the way to solve the problem. 3) A potential solution is implemented (and tested!) 4) A pull request is posted to the mailing list (with tests) 5) Discussion ensues. Repeat steps 3/4/5 as needed. 6) The pull request is merged to ‘develop’ 7) After test cycles, the change is merged to ‘master' Notes: 1) All of this should happen on the Boost.CMT ML. 2) Discussions _about_ the CMT should happen on the main Boost ML. 3) The person who lands the patch is responsible for checking the test results and merging to “master” (and closing out the bug report, if any). 4) The goal of the CMT will be the same as the Boy Scouts - “Leave the code cleaner than when you found it” Comments? -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

2 2

Re: [boost] [atomic] Probable documentation issue: how do we know atomic is safe and/or efficient?
by Pete Bartlett 24 Dec '13

24 Dec '13

> On 24 Dec 2013, at 13:43, "John Maddock" <john(a)johnmaddock.co.uk> wrote: > > This message has no content.

1 0