- Boost - lists.preview.boost.org

[community] request for revision: generic programming
by Steve Lorimer 06 Jun '13

06 Jun '13

In the light of C++11, the page on generic programming techniques http://www.boost.org/community/generic_programming.html is somewhat outdated. Any chance of a revision?

2 1

BOOST_STRONG_TYPEDEF
by Eric Niebler 05 Jun '13

05 Jun '13

Someone on stackoverflow is having a problem with BOOST_STRONG_TYPEDEF getting defined twice. There's a good recommendation there about boost/strong_typedef.hpp merely including boost/serialization/strong_typedef.hpp. Regardless, it's strange that trunk and release have been out of sync in this regard for so long. Robert? http://stackoverflow.com/questions/16901250/why-does-boost-include-two-diff… -- Eric Niebler Boost.org http://www.boost.org

1 0

[DNS] Heads up: svn.boost.org moving to a new server; IP address changing
by Beman Dawes 05 Jun '13

05 Jun '13

At 2:00 pm Eastern US time (i.e 30 minutes from now) we will switch svn.boost.org to a new server with a new IP address. It would be best to hold off on any SVN commits until after the change over, and after your DNS server has the new IP address. If command line "ping svn.boost.org" is going to [129.79.245.252], you are still getting the old IP address. Once svn.boost.org is resolving to [129.79.13.13] it should be OK to resume normal Subversion activity. Thanks, --Beman

1 2

[1.54.0] Beta 1 Available
by Marshall Clow 05 Jun '13

05 Jun '13

Boost release 1.54.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/boost/1.54.0.beta.1/ This release contains 3 new libraries: • Log: Logging library, from Andrey Semashev. • TTI: Type Traits Introspection library, from Edward Diener. • Type Erasure: Runtime polymorphism based on concepts. and numerous enhancements and bug fixes for existing libraries. For details of what's in the release, see http://www.boost.org/users/history/version_1_54_0.html. 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

3 2

[git] Library metadata
by Daniel James 04 Jun '13

04 Jun '13

Hello, Is anyone thinking about storing library metadata in modules? I'm thinking about this in context of the data required for the website, it'd be nice to automatically pull that from the library modules rather than having to maintain it myself, but I guess this might be something that others are thinking about (e.g. for the expected test failures, the library maintainer). So I was wondering if anyone has any plans? For anyone who isn't aware of it, the website data is stored in an xml file at: http://svn.boost.org/svn/boost/website/public_html/live/doc/libraries.xml Of course, it could be desirable to store modularized metadata in a different format. Daniel

3 4

[python] non-standard iteration / wrapping member function return value
by Matus Chochlik 04 Jun '13

04 Jun '13

Hi, I'm stuck at trying to make python bindings for a set of classes that use a non-c++-standard iteration protocol. I've made a minimal example of what I'm trying to do: the python-ized classes look in essence like this: //------------------------------------------------------------- class int_range { private: int i, max; public: int_range(int m) : i(0), max(m) { } bool empty(void) const { return i > max; } int front(void) const { return i; } void next(void) { ++i; } }; class range_maker { public: int_range make(void) const { return int_range(10); } }; //------------------------------------------------------------- the boost.python module that I've come up with so far: //------------------------------------------------------------- using namespace boost::python; class _py_int_range_iter { private: int_range _range; public: _py_int_range_iter(int_range range) : _range(range) { } _py_int_range_iter self(void) { return *this; } int next(void) { if(_range.empty()) objects::stop_iteration_error(); int result = _range.front(); _range.next(); return result; } }; class_<_py_int_range_iter>("_py_int_range_iter", init<const int_range&>()) .def("self", &_py_int_range_iter::self) .def("next", &_py_int_range_iter::next) ; class _py_int_range { private: int_range _range; public: _py_int_range(int_range range) : _range(range) { } _py_int_range_iter iter(void) { return _py_int_range_iter(_range); } }; class_<_py_int_range>("_py_int_range", init<const int_range&>()) .def("__iter__", &_py_int_range::iter) ; //------------------------------------------------------------- the problem is that when I register range_maker as follows... //------------------------------------------------------------- class_<range_maker>("range_maker") .def("make", &range_maker::make) ; //------------------------------------------------------------- ... it compiles but (obviously) fails in python at run-time because range_maker::make returns int_range and not _py_int_range. what do I need to do to make this work? I know that I could write _py_range_maker wrapping range_maker and let it return _py_int_range, but this approach does not scale very well. Is there some way to tell the def(...) function that I want to wrap the return value into an object of another type? Is there a return value policy for that or do I need to write my own? If so how? Thanks in advance Matus

2 2

Re: [boost] ATTN: Boost GSoC mentors and students: Continuous Integration for GSoC thoughts
by Niall Douglas 04 Jun '13

04 Jun '13

> > Personally speaking, I think this depth and degree of CI is > > *invaluable* to modern software development practice. > > I could not agree more. > > One thing you may want to add is coverage analysis with > https://coveralls.io/: > > If you build with gcc, pass "-fprofile-arcs -ftest-coverage" both to the compiler > and the linker. After running the tests, you can analyze the coverage with gcov > and send it to coveralls. > To collect and upload, I use the following script: > https://github.com/purpleKarrot/Karrot/blob/develop/test/coveralls.in > (Note that gcov 4.6 does not support all flags that I use in the script, I use it wiht > 4.8 only). That's really super useful of you Daniel. I wasn't aware that such a service existed for code coverage. Thank you. I don't suppose you'd know the answer to this question though: Travis CI's reporting is not great, it either reports success or failure and not *what* failed nor *why*. Specifically, if for example a build fails, I'd like to know which source files and what the compiler errors were. Similarly, if a unit test fails, I want to know which one and what the error was. Do you know if this can be done? Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

1 0

Re: [boost] ATTN: Boost GSoC mentors and students: Continuous Integration for GSoC thoughts
by Niall Douglas 04 Jun '13

04 Jun '13

> Just curious: is Visual Studio support not included because not deemed > important? Or not supported by this particular lib? Or not supported by Travis CI > for some reason? (licensing?) As others have mentioned, Travis CI provides only Ubuntu 12.04 x64 instances and none other. Interestingly, you /could/ actually package up MSVC and run it under wine, but Travis CI's free service limits test runs to 20 mins and getting wine et al installed in that time is probably more trouble than it's worth. Besides, I have another very good reason not to: my primary development platform is Visual Studio. Why? It has the least C++11 support, but also the best debugger. Any C++11 feature supported by the Nov 2012 CTP experimental MSVC is easily supported in GCC or clang, whereas the converse is most certainly not true. A further factor is that the library is an async file i/o abstraction layer intended for Boost, and the only true async backend currently is Windows IOCP. Therefore, naturally development, and especially performance tuning, currently focuses there. Travis CI is really useful though for checking Visual Studio work: MSVC I am told does not use an AST internally, and therefore permits C++ no other compiler will allow. Very often I write template metaprogramming which MSVC is absolutely fine with but chokes either GCC or clang or both. Travis CI emails me to tell me when I've done that. This is very, very useful. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

1 0

[thread] call_once regression or it is planed so?
by Antony Polukhin 04 Jun '13

04 Jun '13

Hi, With 1.54.0_beta1 following code fails to compile: #include <boost/thread/once.hpp> void init_host(int); void init_host(); boost::once_flag instance_flag = BOOST_ONCE_INIT; int main() { boost::call_once(&init_host, instance_flag); } In 1.53 it worked fine. Is that meant to be so and no workaround is possible, or is it a bug? -- Best regards, Antony Polukhin

3 2

Asking for permission to merge small bugfix (Spirit)
by Hartmut Kaiser 04 Jun '13

04 Jun '13

I would like to merge a small bugfix to the release branch (commit set 84631, patch below). Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu Index: C:/CVS/boost/boost/spirit/home/lex/lexer/support_functions.hpp =================================================================== --- C:/CVS/boost/boost/spirit/home/lex/lexer/support_functions.hpp (revision 84630) +++ C:/CVS/boost/boost/spirit/home/lex/lexer/support_functions.hpp (revision 84631) @@ -49,7 +49,7 @@ { typedef typename typename remove_reference< - remove_const< + typename remove_const< typename mpl::at_c<typename Env::args_type, 4>::type >::type >::type

2 1

[1.54.0] Accidentally committed to release docs fix
by Antony Polukhin 04 Jun '13

04 Jun '13

Hi, Without permission, accidentally committed r84603 that fixes docs of Boost.Any. Is it OK to leave that commit or reverting it is preferable? Commit is small and fixes only a single line in docs. -- Best regards, Antony Polukhin

2 1

[1.54.0] Beta Release Candidates available
by Marshall Clow 04 Jun '13

04 Jun '13

Release candidate files for 1.54.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: 31266b7dcc6f557ad839e4e87317cd6e *boost_1_54_0_beta1_rc1.tar.gz fbf7be9cbaf9ea6fb21ae73d0c17100d *boost_1_54_0_beta1_rc1.tar.bz2 7de4299ab69c941e83fe3fc46dddc15f *boost_1_54_0_beta1_rc1.zip c73e5118ff585d9f1d68542f96a0758a *boost_1_54_0_beta1_rc1.7z Thanks, --The release managers

11 17

[1.54.0] [log] Permission to merge bugfix to release
by Andrey Semashev 04 Jun '13

04 Jun '13

Hi, May I merge the following changesets to the release branch? In short, it fixes the ticket [1] for Boost.Log and the similar issue for string_ref - incorrect handling of width specification with stream IO. Boost.Log: https://svn.boost.org/trac/boost/changeset/84512 https://svn.boost.org/trac/boost/changeset/84514 string_ref: https://svn.boost.org/trac/boost/changeset/84511 https://svn.boost.org/trac/boost/changeset/84513 https://svn.boost.org/trac/boost/changeset/84518 The tests are green. Also, there's a small fix for MinGW 4.4 tests of Boost.Log: https://svn.boost.org/trac/boost/changeset/84515 MinGW 4.4 tests have not been run for quite some time, but I believe it's safe to merge it as well. [1] https://svn.boost.org/trac/boost/ticket/8614

2 1

Request to contribute boost::FFT
by Nathan Bliss 03 Jun '13

03 Jun '13

Dear Boost Community Members, I am writing to ask if I could contribute a C++ FFT implementation to the boost library. I noticed that there is a boost::CRC so I thought it would be a good addition to have boost::FFT as well. MIT have an existing open-source FFTW library, but it is GPL-licensed which is much more restrictive than the Boost license. I should imagine a commercial FFTW license would be very expensive. I have working FFT code which I have tested on Ubuntu Linux GNU gcc and also Visual Studio Express 2012 (MS VC++) for Windows. My code, when run as a 2048-point FFT, agrees with the MIT FFTW one to a max error margin of 6 parts per million. It is implemented using templates in a .hpp file and is very easy to use: ------------------------------------------------------------------------------------------------------------[fft.hpp] template<class FLOAT_TYPE, int FFT_SIZE, int NUM_THREADS>class FFT;///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////[Invocation example] typedef double My_type;FFT<My_type, 2048, 4> user_fft;user_fft.initialise_FFT();get_input_samples(*user_fft.input_value_array, user_fft.m_fft_size);user_fft.execute_FFT();print_output_csv(user_fft.output_value_array, 2048);------------------------------------------------------------------------------------------------------------ It's uniqueness compared to other FFT implementations is that it fully utilises the boost::thread library, to the extent that the user can give the number of threads they want to use as a parameter to the class template (above case is for 4 parallel threads). It is structured and organised so that users could customise/optimise it to specific processor architectures. I've also tried to develop it in the spirit of Boost in that all class members which users should not access are private, only making public what is necessary to the API. My code is a decimation-in-time radix-2 FFT, and users could in theory use the existing API as a basis to extend it to more complex implementations such as the Reverse/Inverse FFT, bit-reversal of inputs/outputs and multi-dimensional FFTs. I look forward to your reply. Kind regards,Nathan Bliss

14 21

web page copyrights
by Charles_J_Wilson＠Dell.com 03 Jun '13

03 Jun '13

I was reading the 1.54.0 beta 1 release notes and managed to scroll down to the bottom of the page. I noticed that the copyright information was not current, so I looked at the main page. It's not current either. As this probably falls on any number of people, I'm posting instead of opening an issue. Charles Wilson Principal Software Development Engineer Dell | Enterprise Solutions Group

2 1

Request for permission to apply a multi library patch (misspell on comment only)
by Vicente J. Botet Escriba 03 Jun '13

03 Jun '13

HI, https://svn.boost.org/trac/boost/ticket/8558 "some misspell fixes" contains a patch that concerns some misspell on comments only code or on documentation. The patch is quite big and concerns almost all the Boost libraries. Could I apply it all at once, e.g. just after the release 1.54 is delivered? Best, Vicente

1 0

[1.54.0] release branch reopened for bug fixes ONLY
by Marshall Clow 03 Jun '13

03 Jun '13

Now that we have released the first beta, the release branch is open for bug fixes. Only bug fixes, please.[*] No new features. No new libraries. You do not need a release manager's approval to merge a bug fix. The earlier you can merge your bug fixes, the better. The branch will close again for final release preparations on June 24. As usual, you can see the release calendar here: http://www.boost.org/development/index.html [*] Changes to documentation are always allowed. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

1 0

weirdness in documentation of boost::chrono?
by Anthony Foiani 01 Jun '13

01 Jun '13

Greetings -- The online reference for boost::chrono seems to have an odd error in it. If one looks at: http://www.boost.org/doc/libs/1_53_0/doc/html/chrono/reference.html#chrono.… (or: http://preview.tinyurl.com/lcl8j3c ) There is an "operator*==" (note double '='). The actual live link is to "operator*=", and the link works. I took a quick look, and this glitch does not seem to be present in the HTML documentation included in the 1_53_0 tarball. Am I just imagining things? Is my browser being stunningly clever in a way I don't understand? Thanks, Tony

2 1

Re: [boost] [Boost-users] [Thread] Can't compile package_task code with 1.54
by Vicente J. Botet Escriba 01 Jun '13

01 Jun '13

Le 01/06/13 07:30, Vicente J. Botet Escriba a écrit : > Le 01/06/13 00:56, Szymon Gatner a écrit : >> Hi, >> >> I just tried to compile my 1.52- based code with 1.54 beta and run >> into package_task compilation issue. >> >> In 1.52 I was using BOOST_THREAD_VERSION=3 define but with 1.54 I >> complied with =4. >> >> Test program: >> >> #define BOOST_THREAD_VERSION 4 >> >> #include <boost/thread/future.hpp> >> #include <boost/function.hpp> >> >> struct MyFunc >> { >> void operator()()const {} >> }; >> >> int main() >> { >> boost::function<void()> f; >> MyFunc mf; >> >> boost::packaged_task<void()> t1(f); // error 1 >> boost::packaged_task<void()> t2(mf); // error 2 >> } >> >> >> error 1 being: >> >> d:\devel\boost_1_54_0_beta1\boost\thread\future.hpp(2848): error >> C2664: >> 'boost::detail::task_object<F,R>::task_object(boost::detail::task_object<F,R> >> &)' : cannot convert parameter 1 from 'boost::function<Signature>' to >> 'boost::detail::task_object<F,R> &' >> >> and error 2 similarly: >> >> d:\devel\boost_1_54_0_beta1\boost\thread\future.hpp(2848): error >> C2664: >> 'boost::detail::task_object<F,R>::task_object(boost::detail::task_object<F,R> >> &)' : cannot convert parameter 1 from 'MyFunc' to >> 'boost::detail::task_object<F,R> &' >> >> (I tried with custom functor because I thought maybe error was >> related to boost function) >> >> Compiling with Visual Studio 2012 Update 3 >> >> > Hi, > > this is related to https://svn.boost.org/trac/boost/ticket/8596 which > is fixed now, but maybe it doesn't works for you. > Note that the trunk regression test since revision 84414 run with this > compiler pass ( > libs/thread/test/sync/futures/packaged_task/func_ctor_pass.cpp) > <https://svn.boost.org/trac/boost/browser/branches/release/libs/thread/test/…> > http://www.boost.org/development/tests/trunk/developer/thread.html. > > Unfortunately not a single msvc tester has run after revision 84468 on > release branch. > > I have no the possibility to reproduce it now. Please could you send > the whole log? (privately if you prefer? Or via a ticket? > I have found the error. My tests don't test for packaged_task<void()>. The following patch should fix the issue (see attached file) Please could you apply it a tell me if it fix with your compiler? Best, Vicente svn diff future.hpp Index: future.hpp =================================================================== --- future.hpp (revision 84547) +++ future.hpp (working copy) @@ -2362,18 +2362,12 @@ task_object(task_object&); public: F f; -#ifndef BOOST_NO_CXX11_RVALUE_REFERENCES - task_object(BOOST_THREAD_RV_REF(F) f_): - f(boost::forward<F>(f_)) - {} -#else task_object(F const& f_): f(f_) {} task_object(BOOST_THREAD_RV_REF(F) f_): - f(boost::move(f_)) // TODO forward + f(boost::move(f_)) {} -#endif #if defined BOOST_THREAD_PROVIDES_SIGNATURE_PACKAGED_TASK && defined(BOOST_THREAD_PROVIDES_VARIADIC_THREAD) void do_apply(BOOST_THREAD_RV_REF(ArgTypes) ... args) @@ -2616,18 +2610,12 @@ task_object(task_object&); public: F f; -#ifndef BOOST_NO_CXX11_RVALUE_REFERENCES - task_object(BOOST_THREAD_RV_REF(F) f_): - f(boost::forward<F>(f_)) - {} -#else task_object(F const& f_): f(f_) {} task_object(BOOST_THREAD_RV_REF(F) f_): - f(boost::move(f_)) // TODO forward + f(boost::move(f_)) {} -#endif #if defined BOOST_THREAD_PROVIDES_SIGNATURE_PACKAGED_TASK && defined(BOOST_THREAD_PROVIDES_VARIADIC_THREAD) void do_apply(BOOST_THREAD_RV_REF(ArgTypes) ... args)

1 0

Re: [boost] Migrating www.boost.org to another server
by DongInn Kim 31 May '13

31 May '13

Any news from Beman? Regards, -- - DongInn On May 21, 2013, at 12:14 AM, Daniel James <daniel(a)calamity.org.uk> wrote: > On 21 May 2013 05:00, Marshall Clow <mclow.lists(a)gmail.com> wrote: >> On May 20, 2013, at 8:54 PM, Daniel James <daniel(a)calamity.org.uk> wrote: >> >>> On 21 May 2013 02:34, Marshall Clow <mclow.lists(a)gmail.com> wrote: >>>> [ Off-list ] >>>> Just as an update - Beman was _not_ at C++Now this year (the first time he has missed it). >>> >>> Do you know if he's available? >> >> Well, not at the moment - he's on the east coast (GMT-4), but in general, yes. > > I'll send him an email later then. Cc'd emails can get lost in the > noise of the list.

5 35

May I ask community to make a small review of the high-level network library we released?
by Dmitry Timoshenko 31 May '13

31 May '13

We released the beta version accessible here http://libunicomm.org. We would be really appreciated if this could happen. Thanx, Dmitry.

1 0

Git Modularization Review no vote heads-up
by Beman Dawes 31 May '13

31 May '13

If the steering committee's Git Modularization Review vote were held today, I've vote no since I think that we aren't yet ready. Since my concerns are apparently easy to fix technically, I'm mentioning them here to give Dave and Daniel a chance to address them before the actual Git Modularization Review starts. Concerns: 1) The mapping of svn branch names to modular git branch names needs to be revised: Svn "trunk" needs to become modular git "develop", not "master". Modular git needs to have a branch "master" that represents the latest stable release. Whether the content is identical to the last boost release or to branches/release at point of conversion needs to be decided, as does what the history, if any, of this branch looks like. 2) The procedures described in https://svn.boost.org/trac/boost/wiki/TryModBoost need to be updated, the dependency on CMake needs to be removed, and the procedures need to work. These are blocking issues because they prevent development and testing of modular boost testing procedures, developers procedures, release procedures, installation procedures, and documentation. Until they are resolved, the entire modular boost conversion rests on the shoulders of Dave and Daniel. Once they are resolved, others can pitch in and help since from that point forward we will be in a pure git environment and detailed knowledge of the conversion process from svn is not required. --Beman

9 25

[Atomic] Rationale for preventing copy construction/assignment?
by Collin Dauphinee 31 May '13

31 May '13

I've recently noticed that boost::atomic<T> prevents assignment from boost::atomic<T>, as well as copy construction. I'm having trouble understanding why this decision was made, as it makes boost::atomic<T> (and classes with a boost::atomic<T> member) very hard to store in containers, and I can't immediately see any safety issues that would be caused by allowing copy operations. What is the rationale for not allowing assignment or copy construction from another boost::atomic<T>?

6 10

Re: [boost] Git Modularization Review no vote heads-up
by "Jürgen Hunold" 30 May '13

30 May '13

Hi Dave, > Gesendet: Donnerstag, 23. Mai 2013 um 07:28 Uhr > Von: "Dave Abrahams" <dave(a)boostpro.com> > An: boost(a)lists.boost.org > Betreff: Re: [boost] Git Modularization Review no vote heads-up > > > on Wed May 22 2013, Jürgen Hunold <jhunold-AT-gmx.eu> wrote: > > > But this can easily be done after the conversion. > > > > I think we already lost too much time with failed rewrite attempts, so let us > > get a working repository first. Then Volodya can test git mv v2/* . and report > > results. Afterwards, we can always try rewriting in a separate clone. Done this myself yesterday. Works like a charm, git blame shows undisrupted history after git commit shows "rename" with 100% on each file moved. > Rewriting _published_ history is most strongly discouraged by the Git > people, for several good reasons. *If* there is to be any > rearrangement, it should happen before the switchover, so it doesn't > bork people who are doing work based on the history originally > published. Yes, the basic rule of git. > However, I am loath to do any rearrangement that doesn't (reasonably) > faithfully reflect how things were set up in the past. Otherwise, > someone will check out an old state of the super-module and find that > things have the wrong path relationships. Of course, path relationships > will not match SVN anyway (because we don't have a modular layout in > SVN), but people on this list made it quite clear that modularizing > history was important to them, so I presume they want the Git history to > reflect reality with maximal fidelity. Correct. > That said, if the consensus is that things should be rearranged in the > build repository, we can do that. We just need clear and explicit > instructions that cover what to do with *all* the paths that have been > used in Boost.Build (including branches and tags) throughout time. As > you can see from > https://github.com/ryppl/Boost2Git/blob/master/repositories.txt#L2261 > and following lines, just preserving the existing structure was > nontrivial. That one starts with repository build : common_branches { submodule of "boost" : "tools/build"; content { "tools/build/" : "build"; "tools/jam/" : "jam"; } right? So, this now creates "tools/build/build" with the contents of "tools/build" and "tools/build/jam" with the contents of "tools/jam" which is long gone. The former is wrong, as it does not preserve the current structure despite the thing you wrote above. I think that a one-to-one mapping like: repository build : common_branches { submodule of "boost" : "tools/build"; content { "tools/build/" ; } is the way to go now. If something goes wrong, please put "tools/jam/" somewhere else. Btw. would repository build : common_branches { submodule of "boost" : "tools/build"; content { "tools/build/v2" ; } be the right way to move v2 one directory up? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! juergen.hunold(a)gmx.eu * voice: 0049 4257 300 ! Fährstraße 1 * fax : 0049 4257 300 ! 31609 Balge/Sebbenhausen * mobil: 0049 178 186 1566 ! Germany

10 36

Re: [boost] [gsoc] Getting started with a repository (Was: Re: Live read-only GIT mirrors of Boost trunk SVN)
by Niall Douglas 30 May '13

30 May '13

> > I think the GIT team should make a decision NOW about whether GSOC > > students should use GIT or not. > > > I think I'm against this, on the grounds that there is a lot to go > > wrong, and much critical students Google-time, especially with those > > who may be even ranker amateurs than me ;-) > > +1 > > > Unless there is a firm commitment from the GIT team to support > > students using GIT, then I think they should stick to boost-sandbox > > and do things "the old way". > > > Views from the GIT team? > > Paul > > ...Or their mentors! > > I'm mentoring a project and I'm a total, absolute git-beginner (used it, like, only > sporadically for one small repo). > > Is there any way to send git newbies like me and my student to the sandbox, at > least one more year? GSoC Boost.AFIO lives at https://github.com/ned14/boost.afio but will auto mirror itself into Boost Sandbox once Paul registers for Boost SVN commit privs. If there's interest on how I configured this, do let me know. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

3 3