- Boost - lists.boost.org

Re: [boost] [Boost-users] [1.46.0 beta 1] [SourceForge] SourceForge mirror sync system broken
by Dean Michael Berris 01 Feb '11

01 Feb '11

On Wed, Feb 2, 2011 at 5:08 AM, Vladimir Prus <vladimir(a)codesourcery.com> wrote: > Beman Dawes wrote: > >> The SourceForge mirror sync system has broken down. Other projects are >> affected, not just Boost. >> >> The files up there are probably good and the download problems should >> clear once the mirrors are synced again, the S/F folks say. >> >> Some projects say their files are back online, but as of a few minutes >> ago the Boost stuff still seemed broken and/or running so slowly as to >> be effectively broken. > > I am sure we can host 1.46 beta off google for the time being, here: > > http://code.google.com/p/boost/ > > Let me know if you want me to upload packages there, or whether you want > to do that yourself. > Interesting. Has anybody considered moving the current Subversion repository to code.google.com as well? I'm positive that especially now that they accept pretty much any OSI approved-license project there, maybe we can take the SVN administration issue and move that to Google's hands instead? Thinking-out-loudly-as-per-usual-yours'ly -- Dean Michael Berris about.me/deanberris

1 0

Re: [boost] Need help identifying present and past Boost authors
by Oliver Kowalke 01 Feb '11

01 Feb '11

> I'm working on a repository convertor which must translate SVN author ids > to fullname/e-mail pairs. This has already been done to some extent by > Brad King, but I've found that several authors remain unidentified. > > I'm sending this e-mail to ask the Boost community if they could identify > any or all of the authors at the following URL whose name is Unknown. > Also, if you can provide spelling corrections or more updated e-mail > information, please let me know by e-mail. The current authors file is > here: olli Oliver Kowalke k-oli(a)gmx.de

1 0

[trac] The no-spam solution..
by Rene Rivera 01 Feb '11

01 Feb '11

Just thought I'd point out something that at least the people who receive the trac emails may have noticed... A lack of SPAM in the past few days! This the result of various tweaks to the SPAM filtering to the point where it is almost impossible to post automated SPAM. And it's very hard to post manual SPAM. But there is a drawback.. As a result of the tweaking it's also more likely that people will be accosted by a CAPTCHA challenge. Usually this is enough to validate a trac post. But there will be times when even the CAPTCHA is not enough to overcome the preceived SPAMiness of the post. Feel free to post here if you run into one of those cases. Although looking at the logs, I haven't seen one in the past few days either. Enjoy.. The SPAM free experience :-) PS. And of course, if you find some old SPAM please point it out ASAP for quick eradication. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

4 5

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

Trac administration
by Vladimir Prus 01 Feb '11

01 Feb '11

[Apologies in advance if I have asked this question before and forgot the answer.] Suppose I want something to be changed in Trac that requires admin access. Whom do I contact? Can this contact be published somewhere? I've tried to file an issue using "trac/subversion" component, but it got auto-assigned to Doug Gregor, who, I presume, has more interesting tasks right now ;-) Thanks, Volodya

2 1

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

[context] review manager wanted
by Oliver Kowalke 01 Feb '11

01 Feb '11

I'd like to ask who wants to be the review manager for boost.context? Oliver -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

1 0

[Review] Phoenix V3: mini-review starts February 19th
by Hartmut Kaiser 01 Feb '11

01 Feb '11

Hi List, Phoenix V3 is nearing its completion. With the port to Boost.Proto we tried to address the outstanding issues of the review and would like to announce that the mini-review will start on February 19th. Feel free to preview the code at: https://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/ and the documentation at: http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/libs/phoenix/doc/ht ml/index.html We are currently occupied with code cleanups and finishing of the documentation. The code itself is in a stable condition, feel free to make yourself comfortable with this new library. Regards Hartmut Phoenix V3 Review Manager --------------- http://boost-spirit.com

4 9

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