January 2011 - Boost - lists.boost.org

[process] FileSystem version
by vicente.botet 10 Feb '11

10 Feb '11

Hi, with witch version of Boost.FileSystem Boost.Process is working, V2, V3 or both? Best, Vicente

3 4

[random] geometric_distribution backwards compatibility
by Steven Watanabe 05 Feb '11

05 Feb '11

AMDG Over the last year I've been (slowly) updating Boost.Random to match the new standard. Unfortunately I just hit a problem that I don't have a good solution for. In the standard, the geometric_distribution is defined as $p(i) = p(1-p)^{i}$, with i >= 0. In the current Boost.Random code it is $p(i) = (1-p) p^{i-1}$, with i >= 1. The definition in the standard makes more sense, but I don't want to introduce a breaking change. I can see two options here: * Leave the implementation alone and put a big warning in the documentation saying that the behavior doesn't match the standard. * Since I'm also moving things into namespace boost::random, I can use the new definition and leave a version with the old behavior in namespace boost instead of having a using declaration. I'd still have to add a warning that boost::geometric_distribution isn't the same as boost::random::geometric_distribution. Neither one is particularly appealing. Any thoughts? Better ideas? In Christ, Steven Watanabe

5 10

Process discussions
by Vladimir Prus 02 Feb '11

02 Feb '11

As of recent, we had quite a lot of discussion about process. In true open-source spirit, it was a fairly open discussion, with everybody offering their perspectives and experience. However, while we surely learned many things, it does not seem like we're going anywhere. For a quick experiment, I tried to assess whether the discussion actually reflects the needs of Boost developers, so I created a table of Boost developers sorted by the number of commits in 2010. It is here: http://tinyurl.com/5suwfbn It seems that 5 top Boost comitters did not participate much in recent discussions. And going down the list, it seems like many of active developers did not say anything, while most of discussions is fueled by folks who don't commit much. Of course, everybody can offer valuable thoughts, but if the goal is to fix things for Boost developers, it would make sense if developers say that needs fixing, as opposed to other people doing it for them. Maybe I suggest that for some time, we outright ban freeform discussion about process, and instead, we restrict them to threads started by a Boost developers and saying this: "I am maintainer of X, and had N commits and M trac changes in the last year. I most hate P1, P2 and P3. I would propose that we use T1, T2, and T3 to fix that". Then, everybody could join to suggest better way of fixing P1, P2 and P3 -- without making up other supposed problems. Thoughts? -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40

18 53

Kernel-level threads
by Tibor Szaboky 02 Feb '11

02 Feb '11

Does Boost support Kernel-level threads?

3 2

Re: [boost] boost::interprocess boost::interprocess xsi_shared_memory
by Ion Gaztañaga 01 Feb '11

01 Feb '11

El 12/01/2011 19:48, Daniel Neuberger escribió: > Hi Ion, > > I saw that you made a commit for XSI shared memory (https:// > svn.boost.org/trac/boost/changeset/67451) Could you confirm whether > it is ready to use? We're using Boost 1.43; do you think applying > that changeset would be sufficient to be able to use XSI shared > memory? Yes, I think it will be enough. > Lastly, do you think these changes will make it into the > upcoming 1.46 release? Yes, I see tests are ok. It seems that in FreeBSD 64 we have some ENOSYS error ("function not implemented"), but there is not much we can do if the platform does not support it ;-) I will merge to release ASAP, please it would be nice if you could test these new XSI functions to get more feedback. Best, Ion

2 3

RE process (prospective from a retired FreeBSD committer)...
by Sean Chittenden 01 Feb '11

01 Feb '11

[[ whoops! I double tapped the send keyboard shortcut on a foreground message and sent this before I'd finished cleaning it up. Apologies for the near-double post. The last few paragraphs are different ]] I originally sent this to Eric but am cleaning it up and reposting here per his suggestion. From an outsider's perspective it appears as though the lack of branching/merging tied to release management is the biggest issue for Boost at present. As a retired FreeBSD committer (and a boost-digest lurker since 1.33), I wanted to point out how the FreeBSD community deals with release engineering and see if there are a few nugget policies that could be cherry picked for boost. FreeBSD's process has been in place and refined for the last 15 years and comes with already written documentation as a starting point. It's not perfect, but there's a pound of prevention that comes via policy that no tool can replicate. head/trunk/tip is known as the -CURRENT branch. Released versions for production used (or are in prep for being released) are known as -STABLE branches. When FreeBSD 8 was being developed, people committed to HEAD (aka -CURRENT). When the re@ team called for a freeze for release and -CURRENT was in sufficiently good condition, they branched HEAD in to RELENG_8_STABLE. Everything in RELENG_8_* is expected to be production quality (or nearing it). Upon release of 8.0, RELENG_8 was branched again to RELEASE_8_0. 8.1, 8.2, etc were all created from RELENG_8_STABLE. Fixes for things in stable go to -CURRENT first, then are back patched to the appropriate stable releases, colloquially known as MFC's or Merge From -CURRENT. -CURRENT is the wild west of OS development and repo trash. Use at your own risk. Stability and likelihood of all tests passing is marginal, at best. Towards the end of a given major version -CURRENT becomes more stable, but once -STABLE has been branched it quickly degenerates some as people implement the impetus to checkin new features. -STABLE should always be passing 100% of the regression tests present in the branch at all times. A quick doc on merging between branches: http://wiki.freebsd.org/SVN_Merging I don't know how wide spread it is and despite svk having gone in to maintenance mode, but the use of svk has merit (partial checkouts): http://svk.bestpractical.com/view/HomePage A schedule and handoff of hats/responsibilities for each of the branches is pretty well documented and is now time driven (it used to be feature driven, which didn't work as well as they'd hoped): http://www.freebsd.org/releng/ The way that FreeBSD handles its permissions and merging from one branch to the next is via the commit message, commit hooks and approvals from different people wearing different hats. A few examples: http://lists.freebsd.org/pipermail/svn-src-stable/2011-January/008657.html The above has an MFC line in there to denote the changes included. The commit handler verifies that the diffed files largely match (at least it used to back in the day when I was committing via CVS). http://lists.freebsd.org/pipermail/svn-src-stable/2011-January/008683.html A 'Reviewed by' commit header. This gives greater latitude in terms of what can be included in the commit. http://lists.freebsd.org/pipermail/svn-src-stable/2011-January/008808.html And the 'Approved by' commit header. Once a release is frozen, all commits need to have this tag otherwise the commit will fail. If someone commits with that line and didn't have permission to do so, as a policy, the commit is always reverted 100% of the time as a matter of principle. Frequently it's re-committed, but it's a big slap to the back of the hands to have to go through the process again. Needless to say, the commit mailing list is the most active and widely read list as a result. And tons of code gets reviewed with many eyes viewing it as a result. Unlike boost, FreeBSD uses an abridged commit message that doesn't include the actual diff itself (if you're a committer, then you see the diffs to areas of the tree that you subscribe to). I don't know how many people actually follow boost's commit log on a per commit basis, but given 100% of all commits go to a single mailing list and the diffs can sometimes be massive, it seems like the current list infrastructure makes that kind of review process unsustainable for Joe Reviewer (vs. the shorter abridged commit messages w/ a link to the actual diff). Links to each of the diffs is useful and lets people click through if reviewing the diff is of interest. I can't stress the organizational difference and peer pressure a widely used commit mailing list brings about. There are other bits worth noting, acls apply to different parts of the tree (doc commit bits and a doc-re@ hat vs a src-re@ hat and even ports@), but the mailing list/commit reviews and branching/merging are the biggies that I wanted to point out. Branching trunk in to a boost_1_46_prerelease branch three weeks before the release (or some sane interval) so that people can fix up the code seems like a pretty painless adjustment, then snapping/releasing boost_1_46_0 when the pre-release is ready. Post-1.46 release fixes could go in to 1.46.0 and (heaven forbid), maybe even a micro version with specific fixes for the .46 minor version. PostgreSQL ships with a contrib/ directory of "soon to be" or "possible candidates for being a core component" which serves the same purpose as FreeBSD's ports structure. This gets yet-to-be finalized modules out in the wild and helps garner interest. PostgreSQL's autovacuum went from being a fringe project to a contrib/ module and a core feature in 2 minor releases because of the huge interest in its use/adoption. Boost.Log or Atomic or any of the other "we all really want this but it's not quite finalized" modules seem like ideal candidates for inclusion in such a directory because it could generate additional interest/eyes. A contrib/ or proposed/ would go a long way towards keeping boost lean-ish, too. At present it seems like boost-*.tar.bz2 is on track to including boost/kitchen/sink.hpp and boost/bath/water.hpp and that's something that is a bit concerning to me on the long-term scale. Me personally, I keep running 'svn ls http://svn.boost.org/svn/boost/branches/' to see if a branch pops up for release but I haven't yet. The structure on the server is largely there, but it the svn tree looks pretty disorganized with lots of legacy clutter so it doesn't look like it's being used well. And lastly re: VCSs, lots of people fork FreeBSD to do experimental work out of the tree via git and hg, but the monolithic and serialized commit/review process seems to be working quite well from my perspective. A little bureaucratic but very stable and democratic without reliance on any one person to push the release forward. Anyway, food for thought. Hopefully there's something there that you can pick out of value. If you have questions, feel free to ask on or offline (CC if online since I'm a digest subscriber). Cheers. -Sean -- Sean Chittenden sean(a)chittenden.org

12 46

Functors created by boost::bind and move semantic
by Marat Abrarov 01 Feb '11

01 Feb '11

Hi, Boost Users and/or Developers. Does anybody know why functional objects created by means of boost::bind have no move constructors? It would be rather useful especially when such functional objects consist of some smart pointers (like boost::shared_ptr). For example, move constructor of boost::shared_ptr is very light (comparing to its copy constructor) - it doesn't use any CAS at all (which is the main overhead of boost::shared_ptr). May be someone know the reason of move constructor absence or maybe someone know any plans of implementing it. Regards, Abrarov Marat.

2 1

Boost Modularization
by Robert Ramey 01 Feb '11

01 Feb '11

I believe that eventually we will want have feel the need to address some issues in directory structure, namespaces etc. However, I'm thinking that it's premature to do anything but set a few policies for new libraries and submissions. The only specific one that comes to mind is: a) libraries should not place any header files directly in the boost directory or in the boost namespace. The only exception would be a "convience header" in the boost directory which would include the headers in the library directory. b) The library name should be the same as the namespace name and the same as the subdirectory name in the boost directory. .... Robert Ramey

6 5

Re: [boost] [string] proposal
by Ivan Le Lann 01 Feb '11

01 Feb '11

----- "Patrick Horgan" <phorgan1(a)gmail.com> a écrit : > On 01/28/2011 09:59 AM, Dean Michael Berris wrote: > > On Fri, Jan 28, 2011 at 7:20 PM, Dean Michael Berris > > <mikhailberis(a)gmail.com> wrote: > >> So the interface I was thinking about (and suggesting) is a lot > more > >> minimal than what rope or std::string have exposed. I think when I > do > >> finish that design document (with rationale) it would be clear why > I > >> would like to keep it immutable and why I would prefer it still be > >> called a string. > >> > >> Let me finish that document -- expect something over the weekend. > :) > >> > > And I stopped before I write too much -- the initial version is > > already up: > https://github.com/downloads/mikhailberis/cpp-string-theory/cpp-string-theo… > > -- I'll give it more information and the actual interfaces and > > implementation as soon as I get some Z's. :) > > > You mention that your string is thread safe by design, but you only > solve the problem of mutating the data of a string, your references to > the pieces from which you compose a string are not thread safe, since > they are mutable, right? I don't think so. Isn't the easiest way towards proper composition to consider that the whole is the same as the part? I see the "chain" (I voted for that one!) as an immutable tree of immutable leafs. I think this can be naïvely seen as the following recursive boost::variant: boost::make_recursive_variant < boost::shared_ptr <const std::basic_string <code_unit_type>>, boost::shared_ptr <const std::list <boost::recursive_variant_>> >::type Ivan

3 3

One thing at a time: let's move to Git
by Mathias Gaunard 01 Feb '11

01 Feb '11

Many people wish for Boost to move from svn to git. Other people are fine with svn, but are not opposed to a change to git. So how about we just make it happen? Clearly Ryppl is trying to do too many things at once (modularize Boost, change the build system, the testing system, etc.). I offer we take one step at a time: let's simply move from svn to git, and not do anything else. I think there is already a non-modularized version of Boost on git somewhere. What else needs to be done? Do we just need to set up a scheme to transfer over all accounts and that's it?

8 9