- Boost - lists.preview.boost.org

[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

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

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

How to specify return policy for object returned as part of a tuple in boost python
by Eddie C. 31 Jan '11

31 Jan '11

Hi all, I have a function that creates a C++ object. Before the refactor, I was returning a pointer from the C++ function, and in the boost python wrapper declaration, I would use boost::python::return_value_policy<boost::python::manage_new_object>. Now I need to return not only just the object, but also some error messages, and the refactor basically changes the C++ function to let it return a tuple: boost::python::tuple create_object_from_description(std::string& description) { ... return boost::python::make_tuple(myObject, errmsg); } How should I specify the return policy with this change? Thanks, Eddie

1 0

[1.46.0 beta 1] Release 1.46.0 beta 1 available
by Beman Dawes 31 Jan '11

31 Jan '11

Boost release 1.46.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/ This release contains one new library, Interval Containers, and numerous enhancements and bug fixes for existing libraries. For details of what's in the release, see http://beta.boost.org/users/news/version_1_46_0. Note that the links to files on this web page are for the final release - use the SourceForge link above to get the beta files. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus

9 13

[Boost Graph Library] larger neighborhood in grid_graph
by Hannes Schulz 31 Jan '11

31 Jan '11

Hi all, i recently discovered grid_graph and found it quite useful so far. However, I would prefer a larger neighborhood in the graph (e.g. 8 instead of 4 for 2D; 26 instead of 6 in 3D). I already started looking into copying and modifying grid_graph.hpp accordingly, but cannot entirely anticipate the complexity of the problem. Therefore I decided to ask here first: - Why did the developers restrict grid_graph to "orthogonal" neighborhoods? - Is a modification of grid_graph worth it, or am I going to throw away everything anyway and should start over anew instead? (without the wrapping overhead, which I do not need) Thank you very much! Hannes

2 1

Git vs SVN - review
by Robert Ramey 31 Jan '11

31 Jan '11

Here's my take on Git vs SVN All VCS systems are an extra layer of hassle. Once I learn enough about them to do the job, I'm happy to forget about them. I'm mostly happy with SVN. I only commit/update occasionally. Most of my time on boost is spent testing on my own machine with windows VC and gcc. I love the windows interface - it's great for someone with my attitude about this. I hate the merging process - it's slow and cumbersome and wastes a lot of my time - when I do it which is only once every three months. So - I don't really have strong feelings about this topic and I'm happy to go along with what ever is decided. I'm just hoping that those who make the decision take into account those of use who are VCS luddites. Robert Ramey

6 9

Testing procedure
by Robert Ramey 31 Jan '11

31 Jan '11

John Maddock wrote: > * I think we could organize the testing more efficiently for faster > turnaround and better integration testing, and much to my surprise I'm > coming round to Robert Ramey's suggestion that we reorganize testing > on a library-by-library basis, with each library tested against the > current release/stable branch. +1 of course, > * I think the release branch is closed for stabilization for too > long, and that beta's are too short. I would hope that implementing the above would make this a non-issue. > Here's a concrete suggestion for how the testing workflow might work: > > * Test machine pulls changes for lib X from version control (whatever > tool that is). > * Iff there are changes (either to lib X or to release), only then > run the tests for that library against current release branch. > * The testers machine builds it's own test results pages - ideally > these should go into some form of version control as well so we can > roll back and see what broke when. > * When a tester first starts testing they would add a short > meta-description to a script, and run the script to generate the test > results index pages. ie there would be no need for a separate machine > collecting and > processing the results. > * The test script should run much of the above in parallel if > requested. > The aim would be to speed processing of testing by reducing the cycle > time (most libraries most of the time don't need re-testing). > +1 to all of the above. Robert Ramey

2 2