- Boost - lists.boost.org

[serialization] new portable binary archive based on HDF5
by Daniel Koester 13 Dec '13

13 Dec '13

Dear Boost developers, I would like to share a contribution to the boost::serialization module. It provides an answer to the challenge of supporting portable binary archives by using the well-known and stable HDF5 library (http://www.hdfgroup.org/HDF5) After first signals of interest by other users I have decided to fully integrate my work with the current boost::serialization module. My suggestion would be for Robert Ramey and other interested developers to consider the inclusion of my work in the official serialization code. I am not sure about the exact procedure in this case. I have forked from the Git serialization archive. All supplied tests have passed for gcc on Linux and MSVC 10 on Windows. My work can be pulled from https://github.com/dk1978/serialization/tree/development To compile the new archive code, define the paths to the HDF5 installation using the variables HDF5_INCLUDE_PATH, HDF5_LIB_PATH, and HDF5_BIN_PATH either as environment variables or in "project-config.jam". An example using the new archive is also provided in the "example" subdirectory. Motivation for this work: The hdf5_archive project provides a new serialization archive format based on HDF5 to complement the ones already included in the boost::serialization library: plain text, XML, and native binary. By building on the established and well-known boost::serialization framework, application code can use HDF5 or switch to any of the other established archive formats with only minimal changes to the code involved. HDF5 has become a popular format to store scientific data. It is open and well-documented. Further advantages of HDF5 are the following: - the format is self-describing and portable across computing platforms - efficient storage of large arrays, parallel IO using MPI is possible (though not yet implemented) - hierarchical description of stored data - several low-level storage drivers, including single file or multiple-directory layouts - APIs to C, C++, and Fortran Best regards, Daniel Koester

3 2

[git] Git id for automated commits
by Daniel James 13 Dec '13

13 Dec '13

Hi, I'm currently using a script to update the super project, so I'd rather not use my email address for the commits. Is there an email that I should use for things like this? Daniel

1 0

Equivalent of "svn update"?
by Peter Dimov 13 Dec '13

13 Dec '13

I've followed the instructions at https://svn.boost.org/trac/boost/wiki/TryModBoost and everything worked fine. I then switched to branch develop in libs/bind and libs/smart_ptr, did developmental things there. Switched to master, did a merge, switched back to develop, did more things, git pushed the changes. This also worked fine. Now, what do I need to do to achieve the equivalent of "svn update", that is, to update all other libraries to reflect changes that others might have done in the meantime? When I do "git status" at the "modular-boost" directory (which I've named "boost"), I get: C:\Projects\boost-git\boost>git status # On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # (commit or discard the untracked or modified content in submodules) # # modified: libs/bind (new commits) # modified: libs/smart_ptr (new commits) # modified: tools/build (untracked content) # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # b2.exe # bin.v2/ # bjam.exe # boost/ # bootstrap.log # project-config.jam no changes added to commit (use "git add" and/or "git commit -a") That looks correct. Now, what do I need to do to update the master and all submodules to their latest state? Is it "git submodule update --init", "git pull", or something else? And would I then need to again checkout develop (or master, if I happen to be on that branch) in libs/bind and libs/smart_ptr?

4 8

A proposal for superproject structure and testing
by Peter Dimov 12 Dec '13

12 Dec '13

To expand on what I said in a previous message, I suggest the following structure for the superproject: - branch "latest": automatically tracks "develop" of submodules (scripted). - branch "develop": automatically tracks "master" of submodules (scripted). - branch "master": contains either the last release or the current release candidate. (This naming reflects a gitflow model. An alternative would be to use the more traditional unstable/stable for latest/develop.) Test runners test all three, in sequence. Release preparation starts with a gitflow release branch from boostorg:develop. The release manager then runs local tests and, if necessary, applies fixes on the branch by downgrading submodules to an earlier version or asking the submodule maintainer to resolve a problem and then upgrading the submodule to the later version. Ideally, this release branch should be tested non-locally. However, in the past switching branches for testing has proved a problem. Therefore, the procedure continues instead with: When the release manager is satisfied with the local test results for the release branch, he merges it to master. This becomes a release candidate. If tests prove satisfactory, the release candidate is tagged as an official release and the release branch is deleted. If not, work continues on the release branch.

11 36

Branch names?
by Beman Dawes 12 Dec '13

12 Dec '13

I've been working on Modular Boost Library Workflow Overview. See https://svn.boost.org/trac/boost/wiki/StartModWorkflow In addition to the requirement for "master" and "develop", there is strong encouragement for naming conventions if several other branches are present: * feature/descriptive-name for feature branches. For example, feature/add-roman-numeral-math. * bugfix/descriptive-name for bug-fix branches, including hotfixes. For example, bugfix/ticket-1234-crash-if-result-negative * release.n.n.n for release staging branches. For example, release.1.56.2. Should "bugfix/..." be changed to "hotfix/...", since that's the name given in the Git Flow blog posting? While I see lots of advantages to following Git Flow naming, I've never been sure what "hotfix" means. It seems weird to call a low-priority cosmetic fix a "hotfix". What is the usual practice for description names? Can they include spaces? Is there any reason to recommend spaces vs underbars vs hypthens? Are there any other branches we should recommend names for? --Beman

5 7

[git] The any library does not pull cleanly because of a forced update on develop and master.
by Cox, Michael 12 Dec '13

12 Dec '13

I tried to update my local repositories to the latest changes in each submodule: git pull; git submodule foreach --recursive git pull When it got to the libs/any submodule, I got the following message: remote: Counting objects: 27, done. remote: Compressing objects: 100% (2/2), done. remote: Total 6 (delta 2), reused 6 (delta 2) Unpacking objects: 100% (6/6), done. >From https://github.com/boostorg/any + 3f0b981...e3e5da6 develop -> origin/develop (forced update) + 38039b3...d35b2d6 master -> origin/master (forced update) * [new tag] 20131209-develop -> 20131209-develop * [new tag] 20131209-master -> 20131209-master and my editor popped up with a merge commit message to edit. I think that's because the develop and master branches were force updated, re-writing history in develop and master. Michael

10 40

[githelp] Merging two repositories
by Edward Diener 11 Dec '13

11 Dec '13

I have two separate local repositories cloned from the same other repository and I have made different changes to both. How do I merge those changes together using git ? Or do I have to do it manually ?

4 6

Heads up: I've taken care of Boost.Utility's history
by Peter Dimov 11 Dec '13

11 Dec '13

I'm still awaiting push privileges for Boost.Utility, but locally, I've already taken care of the divergencies between the develop and master branches and created the necessary merge points, so I'm announcing this here to prevent duplication of work, if someone else also decides to do the same in the meantime.

3 2

BOOST_STATIC_ASSERT_MSG bug?
by Peter Dimov 11 Dec '13

11 Dec '13

#ifndef BOOST_NO_CXX11_STATIC_ASSERT # ifndef BOOST_NO_CXX11_VARIADIC_MACROS # define BOOST_STATIC_ASSERT_MSG( ... ) static_assert(__VA_ARGS__) # else # define BOOST_STATIC_ASSERT_MSG( B, Msg ) BOOST_STATIC_ASSERT( B ) # endif #else # define BOOST_STATIC_ASSERT_MSG( B, Msg ) BOOST_STATIC_ASSERT( B ) #endif The second case looks wrong, we have static_assert in this case; should it not be static_assert( B, Msg ) instead?

2 1

RFC: Community maintained libraries
by Beman Dawes 11 Dec '13

11 Dec '13

Boost libraries have always been maintained by an individual maintainer, or perhaps a small number of individuals. That works very well most of the time, and there is no need to change that approach for libraries that continue to have active maintainers. Where we have a problem is libraries that don't have active maintainers. Someone else has to step in from time-to-time to apply patches and perform other routine maintenance. That was easy to do for our svn repo because write permissions were global. GitHub gives us some additional tools; write permissions are given at the Team level, and a team can have permissions across multiple specific repositories. Strawman Proposal ------------------------- For Boost libraries where there is no library maintainer available, turn maintenance over to a "Community" team. Initially the team members would be volunteers who are already known as experienced maintainers or patch submitters. New volunteers for team membership would establish themselves by submitting patches and pull requests. At least to get things started, the release managers could OK requests for team membership. We might seed the list of libraries being community maintained by contacting some current maintainers who have not been active for years. If we can't even contact the maintainer, that's an indication the library is a candidate for community maintenance. Patch submitters who haven't gotten any action can request a library be added to community maintenance. At least to get things started, the release managers could OK requests for community maintenance. Comments? --Beman

14 40