- Boost - lists.boost.org

async messaging
by Scott Woods 03 Feb '11

03 Feb '11

Hi, This is a slightly different post. I am hoping for some contact details for a handful of Boosters that showed some interest in a previous thread I started with the same subject line. I have taken that same work and developed it a lot further. I am quite confident that Boost will not be interested and I did not wish to pollute the list with something already rejected. But this list is also the only way to those few that might be interested. If those folks are out there (and its ok with the Boost moderators) and still listening I can be contacted at "scott dot suzuki at gmail dot com". Keywords: zeroconf, auto-detection, advanced connection models, specification language, network APIs, network protocols, state machine dispatch. Regards, Scott

1 0

[1.46.0 beta 1] [SourceForge] Testing beta from SourceForge (was: mirror sync system broken)
by Joachim Faulhaber 02 Feb '11

02 Feb '11

2011/2/1 Beman Dawes <bdawes(a)acm.org>: > On Tue, Feb 1, 2011 at 3:55 PM, Beman Dawes <bdawes(a)acm.org> 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. > > SourceForge downloads seems to be working much better. I did a > download of the .7z file and got the correct checksum. A second mirror > has come back online and the download speed was reasonable. I have successfully downloaded boost_1_46_0_beta1.7z from sourceforge and built it on ms-windows7 with msvc-9 and 10. I checked the general documentation roughly and ICL docs in more detail and did some tests. Everything worked well so far. The only issue I found was this: The link to "Release History" in boost_root/index.html: http://www.boost.org/users/history/version_1_46_0 does not exist: Error 404 (not found) Joachim

5 6

Re: [boost] [Review] Phoenix V3: mini-review starts February 19th
by Eric Niebler 02 Feb '11

02 Feb '11

(Cross-posting for now, but please follow up on boost-users only.) On 2/3/2011 12:06 AM, Robert Ramey wrote: > I've been studying proto/fusion/phoenix. Becoming familiar with this stuff > takes quite an effort. It's quite interesting though. And it seems ideal > for a project I want to do. But I do have one question: > > phoenix/Function objects > Functional/ > Proto/ > PolymorphicFunctionObject > ? > > All seem to address function objects. There seems to be a lot of > overlap and it's not clear to me which I should be using for what. > That is, each library seems to address function objects from a > different perspective, but there is not summary which contrasts > them. I need a "function object library Decoder Ring". Are > there any documents which would help me out? Lots of libraries define function objects or tools for creating them. That's true for Phoenix and Proto (both tools for creating function objects). Phoenix helps you define general purpose function objects in-place (lambdas). Proto helps you define function objects specifically for manipulating expression trees (grammars w/ semantic actions). PolymorphicFunctionObject is a concept that function objects must model if they are to be usable with boost::result_of. Function objects created by Phoenix and Proto all model PolymorphicFunctionObject. I don't know anything about boost/functional. HTH, -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

Re: [boost] [Git] Moving beyond arm waving?
by Ivan Le Lann 02 Feb '11

02 Feb '11

----- "Beman Dawes" <bdawes(a)acm.org> a écrit : > > Comments? > If some Boost developper find following thoughts useful, he should feel free to add them on this page: As a humble Boost user, I would appreciate to see more or less official distributions. Four examples: Boost + Accepted (pending) + Managed (has a review manager) + Candidates (sandbox pre-review maturation, probably a mess) I think this could make the maturation, review and integration process more structured and visible. I'm not suggesting to change Boost integration process, but only to have VCS be a better mirror of it than current sandbox. I fail to see how current combination of both central VCS and monolithic code base can easily lead to that, without burdening Boost itself. I'm not a VCS expert, but I thought DVCS forks could model this. Ivan

1 0

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

Need help identifying present and past Boost authors
by John Wiegley 02 Feb '11

02 Feb '11

Hello, 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: https://github.com/jwiegley/subconvert/blob/master/doc/authors.txt I'll update the file as corrections are provided. Thank you, John Wiegley BoostPro Computing http://www.boostpro.com

6 6

[Review][Move] Boost.Move Review Results
by Michael Caisse 02 Feb '11

02 Feb '11

---------------------------- Executive Summary ---------------------------- Ion Gaztañagas' Boost.Move library was reviewed from May 10th, 2010 through May 24th, 2010. The original review manager was OvermindDL1 who later went missing. Eleven individuals joined the discussion with the author. Six reviews were submitted: - 5 reviews ACCEPT - 1 review CONDITIONALLY ACCEPT Ion indicated he would meet the "conditional requirements" which easily satisfies a community vote of: Boost.Move library ACCEPTED ---------------------------- Overview ---------------------------- The Boost.Move library is a highly anticipated addition to the Boost collection. The primary motivation is to introduce usable move functionality in "a portable syntax between C++0x and C++03 compilers"; however, as Vicente Botet articulated, "Most people think that this is an emulation library, but it is more than that as it implements most of the C++0x Move semantics classes and functions." Reviewers' comments: - "This library is long overdue!" [Terry Golubiewski] - "The tutorial is well written." [Vicente Botet] - "Compared to my adobe based move implementation, I think yours is superior." [Daniel James] - "There is a lot of ingenuity in making the move emulation work, and Ion has made it very accessible and managed to make differences between C++03 and C++0x vanish behind macros and free functions." [Jeff Hellrung] An active discussion included: - exposing boost::rv<T> publicly - The merits of fully defining requirements of boost::rv<T>& - Duplicated functionality found in MPL and Type Traits - The necessity for two emulation modes - The merits of macros - Library author usage of Boost.Move - Non-throwing move constructors - Various potentially useful type traits - Other move implementations While it is unfortunate that a timely review result was not published, it did provide an opportunity to discuss some of the concerns raised in the review with actual users of the library. One such concern was the "two emulation modes." At some point in the discussions it became classified as "Safe vs. Fast". When coined with that bias "safe" would be the preference; however, further investigation and inquiries of actual users showed the "fast" version is perfectly acceptable as the default. Additionally, "safe" is a misnomer considering that one mode is not any safer than the other. Each mode has benefits and limitations as enumerated by Ion in the documentation and review responses. The past six months of use would indicate that defaulting to the "fast" version, as preferred by Ion, is in practice a good decision. Thank you Ion for this well thought out and excellent submittal. Thank you reviewers for expending time and energy to further Boost. Without those who are dedicated to review submitted libraries, the entire process and Boost itself falls apart. The community will benefit from the effort each of you put into this library. Best regards - Michael Caisse ---------------------------- Summary of changes ---------------------------- The following changes are planned based on discussions from the review: -- Conditional Acceptance -- 1. "Two Emulation Mode" documentation typos must be resolved. The descriptions, requirements and limitations need to be perfectly clear for the end user. -- Other Issues -- 1. The class rv should be public and documented. 2. is_movable should be renamed and the documentation clarified. It should only be enabled in C++03. A possible alternative name is has_move_emulation_enabled. 3. Nearly all reviewers voiced a preference that the move library should use existing functionality from MPL and TypeTraits libraries. While on one hand this creates a dependency between move and other libraries it results in reuse of accepted and well tested libraries. If a non-coupling option is also provided, it should not be the default. 4. Additional traits discussed. Resolution: add to TypeTraits library as actual use-cases are found. 5. Provide a boost/move.hpp that includes boost/move/move.hpp 6. Document the interaction of the two emulation modes. 7. Include example for making a container "movable". 8. Two emulation modes - Ion was hopeful that reviewers would have a uniform opinion that would result in a single mode. The trade-offs identified by Ion in the documentation were apparent to all reviewers; however, different conclusions were drawn and consensus was not met. The granularity of control was a common issue with nearly all reviewers. Therefore, keep both emulation modes with Optimized as the default and the granularity of control at or more "local level" than the macro provides (class level). 9. emulation_limitations.html: s/overaloading/overloading/ 10. Fully qualify enable_if ( ::boost::emable_if ) 11. Optimized version of forward should use identity so it will not try to deduce T. 12. Make sure required headers are mentioned for tutorials. 13. is_class in is_movable template< class T> struct is_movable : mpl::and_< is_class<T>, mpl::not_< is_rvalue_reference<T> >, is_convertible< T, rv<T>& > > {}; - or - another solution to is_movable problems with references. 14. On throwing move constructors, Ion should follow as close to the standard's behaviour as possible. This can be revisited after the initial release since it is a performance optimization. -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

5 7

[1.46.0 beta 1] [SourceForge] SourceForge mirror sync system broken
by Beman Dawes 01 Feb '11

01 Feb '11

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. --Beman

1 1

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