- Boost - lists.boost.org

Getting Started Testing with Linux virtual machine on Windows host
by Beman Dawes 19 Dec '13

19 Dec '13

I'm primarily a Windows developer, but like to be able to test locally on both Windows and Linux so I don't have to wait for Boost's regression tests to cycle. For several years I've done that on a Linux virtual machine. I just rebuilt my virtual machine and kept a log so I could share how it is done. Such a virtual machine is free and is easy enough that most Boost library maintainers who use Windows could do the setup in an afternoon, most of which is just downloading files, and can be overlapped with other work. See https://svn.boost.org/trac/boost/wiki/StartTestingLinuxOnWindows Corrections or other comments appreciated. Enjoy! --Beman PS: The process would work in the other direction too, but it would require a Windows license (I.E. not free) and I don't have experience going in that direction so can't write about it.

10 21

Gsoc Participation
by Pulkit Mendiratta 19 Dec '13

19 Dec '13

Is Boost sending an application for participation in GSOC-2014? -- Cheers, Pulkit Mendiratta

6 5

[git] Submodule's readme and logo
by Adam Wulkiewicz 19 Dec '13

19 Dec '13

Hi, In Boost.Geometry we recently added a readme file (currently only in develop branch http://github.com/boostorg/geometry/tree/develop) and some basic wiki. From one of the discussions (by Mateusz Loskot): What I'd suggest is to create README.{md|markdown} file in root directory of geometry repo: have big heading on top [LOGO] Boost.Geometry The readme could also explain briefly what's around, what is include folder, what is example, test folder. and link to the main documentation and wiki pages. GitHub has somewhat 'trained' people there always is a README file (seehttp://tom.preston-werner.com/2010/08/23/readme-driven-development.html) so many users expect to use it as a first contact with a project. I believe having those files in all submodules would have a positive impact on the GitHub community and the users. Furthermore the style of those files could be more or less unified. Therefore I've prepared semi-consistent set of logos for some of the libraries: http://github.com/awulkiew/boost-logos. I decided to achieve the consistency by using the Boost logo as a base. Let me know what do you think about it. And don't hesitate to write about your ideas or propose changes. Regards, Adam

11 46

C++11 variant of the gcc toolset?
by Peter Dimov 19 Dec '13

19 Dec '13

Currently, when I want to test under g++ in C++11 mode, I use b2 toolset=gcc cxxflags=-std=c++11 This works, but (a) prevents me from combining this with other toolsets, (b) prevents me from testing both 03 and 11 at once, and (c) boost.build doesn't treat the two modes of the gcc toolset as distinct and uses the same directory for both. Am I missing something simple, or if not, shouldn't we have a separate gcc11 toolset that is exactly the same as the gcc toolset, but with -std=c++11 applied?

4 7

[Container] Priority Deque - Refinement
by Nathaniel McClatchey 19 Dec '13

19 Dec '13

Hi. I've recently made a double-ended priority queue (priority deque) publicly available at https://github.com/nmcclatchey/Priority-Deque , with the intent of submitting it to Boost (more specifically, I wish to make it part of Boost.Container). I would appreciate any comments, discussion, or refinements. Goals of the project: * Provide an efficient double-ended priority queue, with interface similar to std::priority_queue. * Keep requirements to a minimum. In particular, require nothing except what is already required by std::priority_queue. * Make it fast. Performance should be competitive with std::priority_queue. How goals are met: * The priority deque is implemented as a single class template, mimicking std::priority_queue * The interface of priority_deque is a strict superset of the interface of std::priority_queue. New functions follow the STL naming scheme. * The underlying container is assumed to be a sequence container supporting random-access iterators, front(), back(), and push_back(), as in std::priority_queue. No other assumptions are made. * The underlying data structure is an interval heap, which allows finding min/max in O(1) time, and single-element changes in O(log n) time. * Benchmarks (on queues with 20,000,000+ elements) indicated that the difference in performance between std::priority_queue and the priority deque is negligible when compiled by GCC with the O3 option. A specific question for anyone more experienced with development of generalized code: * I added several functions for controlled access to arbitrary elements. Is this overkill? If so, should they be removed? Thank-you for your time, Nate

7 16

[filesystem] fix recur_dir_itr_imp::increment(system::error_code* ec) in 1.54.0
by claudio.bley＠gmail.com 19 Dec '13

19 Dec '13

Hi. What's happening to the filesystem library? It seems there's no progress on any tickets in the bug tracker? Referring to https://svn.boost.org/trac/boost/ticket/6821#comment:5 Could we get this fix into 1.54.0, please? BTW, sorry for any confusion - I "managed" to comment on the wrong ticket... https://svn.boost.org/trac/boost/ticket/5403 would've been more appropriate, I guess. Claudio -- Claudio

3 4

Fwd: [Boost-users] Forthcoming Boost.Fiber review
by Nat Goodspeed 18 Dec '13

18 Dec '13

---------- Forwarded message ---------- From: Oliver Kowalke <oliver.kowalke(a)gmail.com> Date: Wed, Dec 18, 2013 at 4:12 PM Subject: Re: [Boost-users] Forthcoming Boost.Fiber review To: boost-users(a)lists.boost.org 2013/12/18 Oliver Kowalke <oliver.kowalke(a)gmail.com> > 2013/12/18 Carlos Ferreira <carlosmf.pt(a)gmail.com> > >> Hi! >> Docs link isn't working... -> 404 >> > docs: http://ok73.ok.funpic.de/boost/libs/fiber/doc/html/ src: http://ok73.ok.funpic.de/boost.fiber.zip

1 0

[build] improving the history
by Vladimir Prus 18 Dec '13

18 Dec '13

I've spent some time looking at history of Boost.Build git repository, and I think I've got a fairly reasonable outcome. The problem statement is that in the converted repository, the top-level has nothing but a directory called 'v2', which is rather ugly. While it can be fixed with 'git mv', it would mean that 'git log file' will not show complete history unless the --follow option is passed, which is inconvenient. It appears that graphical tools don't like moves much either. There were already moves in SVN, so even now, running 'git log' on any file in engine/ won't return complete history without --follow. Further, at some older revision, there are two copies of what was jam code then. The most convenient solution for these problems is to edit history of the 'develop' branch, so that content of top-level directory matches what was in 'v2' in SVN, and so that content of 'engine' matches Jam sources through the years. This won't actually break any important references from the super-project, first because they presumably are only to master branch, and second, because the commit objects will be still retained in repository. I am not sure we need to rewrite the 'master' branch, as it's not used for day to day development. Now, as soon as we're rewriting history, it might be good idea to change directory structure to be more alike to the structure that other components have. The additional downside here is that the historical versions will not be fully functional - specifically it will break references from examples and tests to the rest of Boost.Build. But, I think it's worth the trouble - users can still obtain old, fully functional, versions from the tags, or master branch (yet another reason for it not to be rewritten), while developers will enjoy both clean directory structure and fully functional history on 'develop' branch. So, the way I'd most like Boost.Build develop branch to look is this: https://github.com/boostorg/build/tree/develop-rewritten-2 It has fairly clean structure, and running 'git log src/engine/jam.c' goes all the way to initial jam code import. The original post-conversion state is stored at converted-develop tag. Steven, Jurgen, what do you think? Any other concerns I have overlooked. I really would like to to get over git games, and declare the repository to be ready, so unless I'll hear objections by the end of Monday, I will force-push this to develop branch and adjust the super-project as necessary. If anybody wants to try at home, the rewriting was done like this: git filter-branch --prune-empty --tree-filter `pwd`/../rewrite.sh -f where 'rewrite.sh' is attached. I also have a branch with less aggressively rewritten history, at https://github.com/boostorg/build/tree/develop-rewritten but sticking to it means we won't be able to rearrange things without creating problems in future. Thanks, Volodya

3 6

Salutations Boost!
by dominic ibeme 18 Dec '13

18 Dec '13

Wed, 18 Dec 2013 16:29:22 http://akcanlpg.com/wp-includes/welcome.php?gthkxzw1103qky dominic ibeme detroydom(a)yahoo.com ~~~~~~~~~~~~~~~~~ 1942 pennies are lucky. 1942 thousand-dollar bills are luckier.

1 0

develop -> master merges
by Vladimir Prus 18 Dec '13

18 Dec '13

Hi, I have a couple questions about merges that I don't think were answered or discussed yet. - Suppose I make a change in the superproject, bootstrap.sh, on develop branch, due to Boost.Build change. I also want to merge it to master, but I can't really use 'git merge', since it will merge references to 'develop' versions of all components - not something we want to do. It appears cherry-pick is what I want to do. I think that's not a problem, as we never modify 'master' directly, and therefore we won't get any merge conflicts in future. Does anybody see a problem? - Suppose next release is nearing, and I've tested 'develop' branch of my library, and it works fine. I want to put it on master (whether I use intermediate release branch is not relevant here). Gitflow say to use something like this: git merge --no-ff release-1.2 I imagine that most people want 'master' to be identical to 'develop', or to 'release-1.2', after such merge, and the above command does not guarantee that. In past, I could use git merge -s theirs release-1.2 which would make current branch identical to the branch we're merging. But then, git folks decided they don't like this flexibility, like this: http://marc.info/?l=git&m=121637513604413&w=2 and removed 'theirs' merge strategy. What this presumably means, is that I shall do this instead git merge -no-ff release-1.2 git diff HEAD release-1.2 and if the last command reports any difference, go and fix them by hand. This might be actually better than '-s theirs', in that if any fix is mistakenly put to 'master' but not merged to 'develop', this diff will find it, whereas '-s their' will silently wipe it away. But anyway, this 'git diff' invocation probably shall be documented. Am I missing something? Thanks, Volodya

4 9