updating Boost and Eigen

[Bob Carpenter]

Both Boost and Eigen have newer versions than what
we're using.

I think we should update. (Yes, I know that it's not
the done thing in the Linux/R world, but we're bringing
in our own copies of these, so I don't see that there's
really a problem here.)

- Bob

[Daniel Lee]

No objections from me.

- Bob

--
You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Ben Goodrich]

Eigen changes more on a relative basis than Boost because it is a younger project, but I don't see anything here

http://eigen.tuxfamily.org/index.php?title=ChangeLog#Eigen_3.2.1

that is super-relevant to Stan.

Boost 1.55 apparently doesn't (entirely?) work with Visual Studio 2013 which some guy on stan-users recently got to work

http://www.boost.org/users/history/version_1_55_0.html

but it is harder to keep track of the changelog of Boost and know whether there is something of benefit to those that don't do Visual Studio.

Ben

[Bob Carpenter]

On Mar 5, 2014, at 5:57 PM, Ben Goodrich <goodri...@gmail.com> wrote:

> Eigen changes more on a relative basis than Boost because it is a younger project, but I don't see anything here
>
> http://eigen.tuxfamily.org/index.php?title=ChangeLog#Eigen_3.2.1
>
> that is super-relevant to Stan.

Mainly bug fixes and speed improvements.

> Boost 1.55 apparently doesn't (entirely?) work with Visual Studio 2013 which some guy on stan-users recently got to work
>
> http://www.boost.org/users/history/version_1_55_0.html
>
> but it is harder to keep track of the changelog of Boost and know whether there is something of benefit to those that don't do Visual Studio.

It's not critical that we update, either. It just seems easier
to me to keep updating as we go than do it all in one big lump
later. Maybe that's not the case.

- Bob

[Ido Rosen]

Might be offtopic, but: Supporting a range of Boost and Eigen versions
rather than just the latest is valuable, because most
OSes/distributions do not always package the latest-and-greatest.
This probably means not packaging Boost/Eigen/GTest with Stan directly
where possible, and using something like Vagrant or Docker to create
CI/build slaves that build/test in each OS/distribution, then simply
stating Boost, Eigen, etc. as dependencies and checking for them in
the configure/make step.

Barring that, more fodder for why following latest stable seems like a
good idea: it's hard to justify "you have to use specific version X of
this dependency and specific version Y of that dependency" to users if
those versions aren't the latest version when an inevitable
incompatibility/interface change happens.

That said, I understand the Eigen dependency is indivisible, but for
Boost if you want to reduce overhead, it is possible to just
use/package the libraries of boost that stan uses specifically rather
than all of boost. [1][2][3]

[1] https://svn.boost.org/trac/boost/wiki/ModBigPicture
[2] https://github.com/boostorg/boost
[3] https://svn.boost.org/trac/boost/wiki/CMakeModularizationStatus

[Ben Goodrich]

On Wednesday, March 5, 2014 12:02:09 PM UTC-5, Bob Carpenter wrote:

On Mar 5, 2014, at 5:57 PM, Ben Goodrich <goodri...@gmail.com> wrote:

> Eigen changes more on a relative basis than Boost because it is a younger project, but I don't see anything here
>
> http://eigen.tuxfamily.org/index.php?title=ChangeLog#Eigen_3.2.1
>
> that is super-relevant to Stan.

Mainly bug fixes and speed improvements.

I was just saying that I don't think those bug fixes and speed improvements are that applicable to Stan.
 

> Boost 1.55 apparently doesn't (entirely?) work with Visual Studio 2013 which some guy on stan-users recently got to work
>
> http://www.boost.org/users/history/version_1_55_0.html
>
> but it is harder to keep track of the changelog of Boost and know whether there is something of benefit to those that don't do Visual Studio.

It's not critical that we update, either.  It just seems easier
to me to keep updating as we go than do it all in one big lump
later.  Maybe that's not the case.

I think if we were planning to update Boost or Eigen, we should do it in develop right after a non-hotfix release of Stan. That way we have the most time to test it before the next non-hotfix release of Stan.

Ben

[Bob Carpenter]

We do split out what we need from Boost and Eigen for RStan to
reduce size. But Boost likes to include other packages, so it's
a big tangle. And we only need a bit of each package we use.

We left everything in for the regular distribution
because we tend to develop from there and are continually bringing
in new pieces.

We don't really have any dependencies on particular versions
of Boost or Eigen. The main problem with supporting multiple versions is
that we don't have the testing compute power or person power to
run all the combinatorics.

- Bob

[Allen Riddell]

I'd like to echo this point. If we ever want to get into the Debian/Ubuntu or
Redhat/Centos ecosystem (which would be great since it would elimiate the
initial compile of libstan.a) it would be useful/mandatory to be able to compile
against the distribution's version of Boost and Eigen.

For example, the new Ubuntu 14.04 (due in April and a "long term support"
version) will have boost 1.54.0 and Eigen 3.2.0 available.

Best,

-a

[Bob Carpenter]

On Mar 8, 2014, at 4:46 PM, Allen Riddell <a...@ariddell.org> wrote:

> I'd like to echo this point.

The point that we should support multiple versions?
The makefiles for CmdStan let you specify which versions to
use and as far as I know, we don't have any issues with specific
versions.

Now how we're going to test that we maintain compatibility with
multiple versions going forward is more problematic.

Which versions of each do we need to support?

> If we ever want to get into the Debian/Ubuntu or
> Redhat/Centos ecosystem (which would be great since it would elimiate the
> initial compile of libstan.a) it would be useful/mandatory to be able to compile
> against the distribution's version of Boost and Eigen.

Got it.

> For example, the new Ubuntu 14.04 (due in April and a "long term support"
> version) will have boost 1.54.0 and Eigen 3.2.0 available.

Are those the oldest versions we'll need to support?

My question, though, was really about which version to release with
CmdStan. I guess there's the risk that if we add newer versions,
we'll come to depend on newer features, which is why if this is
important we're going to need testing in place w.r.t. older versions.

- Bob

[Ben Goodrich]

On Saturday, March 8, 2014 2:22:06 PM UTC-5, Bob Carpenter wrote:

On Mar 8, 2014, at 4:46 PM, Allen Riddell <a...@ariddell.org> wrote:

> I'd like to echo this point.

The point that we should support multiple versions?
The makefiles for CmdStan let you specify which versions to
use and as far as I know, we don't have any issues with specific
versions.

Now how we're going to test that we maintain compatibility with
multiple versions going forward is more problematic.

Which versions of each do we need to support?

I think CRAN is a more relevant target than Linux distributions because there are many more problems installing from source on Mac / Windows than there are Linux users of Stan. But if we were to satisfy CRAN, then satisfying Linux distributions would be easier if not automatic.

At the moment, RcppEigen is at 0.3.2.1.x, which is the version we are considering upgrading to. In general, the greater problem with RcppEigen is that it might get upgraded before Stan is ready to do so, but Eigen is hyper-concerned with backward compatibility.

More problematic, BH is at 1.51, which does not include odeint and a couple other things. I imagine we could request that BH go to 1.54, but I haven't done so yet because I haven't managed to get consensus that having RStan on CRAN would be worthwhile. I suspect that Dirk either uses 1.51 at his day job or is waiting until Debian Testing transitions to a more recent Boost (96% there to 1.54 according to https://release.debian.org/transitions/ but this may actually turn into Boost 1.55).

The point I keep trying to emphasize is that if we were to get RStan onto CRAN, then we would have less of a maintenance burden overall

• Binary installs are easier so more people install it and thus field-test it on hardware that we don't have
• We would be covered by CRAN policies so uploads of Rcpp (or RcppEigen or BH) that break RStan builds or unit-tests aren't allowed
• Easier for R developers who are depending on RStan

So, if that means that we have to maintain 1+ versions, either by putting patched versions of Boost or Eigen headers into RStan earlier on the PATH or even different versions of the libraries for CmdStan, I think it would be worth it.

Ben

[Bob Carpenter]

Having RStan on CRAN would be great for all the reasons
Ben mentions. In addition, I imagine some people don't take
non-CRAN packages seriously and won't even consider trying
to install them.

Can we somehow guarantee that if Rcpp works, then RStan will work?
Installing Rcpp has been problematic for some users, despite its
being on CRAN, but the question is really whether it will assume
enough of a C++ toolchain for us? Or are there still make issues
that can bite us or version issues with C++ compilers?

As to testing (vs. Rcpp, RcppEigen, Boost tools, etc.), are we going to
be able to compile models and test running them and extracting results part
of our tests? I thought there were serious limitations on the time CRAN will
allow. In fact, I thought the compile time for bin/stanc was a dealbreaker
in and of itself for getting RStan on CRAN.

Would CRAN distribution mean our binary will go out with -O2 compilation
through some version of g++? If so, I'd like to test the performance hit
(if any). Or can we specify our own optimization level? I'm not
very good at remembering all the dependencies (hence my obsession with
reducing their number), but don't we have optimization-level dependencies
with Windows?

- Bob

[Bob Carpenter]

To be even more clear, I think Jiqiang, Ben, and Andrew
should be the ones deciding what to do with RStan w.r.t.
CRAN.

My only concern not related to the sheer difficulty of
getting RStan on CRAN is execution speed once it's there.
But even that I think the three of you should decide.

- Bob

> --
> You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

[Jiqiang Guo]

I am not worrying about the speed since if that really matters, we can compile all the model code in O3.  The source code in the package mainly includes stanc, which is fine under not O3 if cran does not allow our current O3 configuration.

Besides that now I hate cran after my first attempt, compiling stanc is one concern since it takes some time that cran cannot spare.  I don't even see a slim opportunity to get rstan on cran, so why trying to get humiliated?

Also I don't like the idea if we need have boost files from different places.

--
Jiqiang

On Mar 8, 2014 5:45 PM, "Bob Carpenter" <ca...@alias-i.com> wrote:

To be even more clear, I think Jiqiang, Ben, and Andrew
should be the ones deciding what to do with RStan w.r.t.
CRAN.

My only concern not related to the sheer difficulty of
getting RStan on CRAN is execution speed once it's there.
But even that I think the three of you should decide.

- Bob


On Mar 8, 2014, at 11:12 PM, Ben Goodrich <goodri...@gmail.com> wrote:

> On Saturday, March 8, 2014 2:22:06 PM UTC-5, Bob Carpenter wrote:
>
> On Mar 8, 2014, at 4:46 PM, Allen Riddell <a...@ariddell.org> wrote:
>
> > I'd like to echo this point.
>
> The point that we should support multiple versions?
> The makefiles for CmdStan let you specify which versions to
> use and as far as I know, we don't have any issues with specific
> versions.
>
> Now how we're going to test that we maintain compatibility with
> multiple versions going forward is more problematic.
>
> Which versions of each do we need to support?
>
> I think CRAN is a more relevant target than Linux distributions because there are many more problems installing from source on Mac / Windows than there are Linux users of Stan. But if we were to satisfy CRAN, then satisfying Linux distributions would be easier if not automatic.
>
> At the moment, RcppEigen is at 0.3.2.1.x, which is the version we are considering upgrading to. In general, the greater problem with RcppEigen is that it might get upgraded before Stan is ready to do so, but Eigen is hyper-concerned with backward compatibility.
>
> More problematic, BH is at 1.51, which does not include odeint and a couple other things. I imagine we could request that BH go to 1.54, but I haven't done so yet because I haven't managed to get consensus that having RStan on CRAN would be worthwhile. I suspect that Dirk either uses 1.51 at his day job or is waiting until Debian Testing transitions to a more recent Boost (96% there to 1.54 according to https://release.debian.org/transitions/ but this may actually turn into Boost 1.55).
>
> The point I keep trying to emphasize is that if we were to get RStan onto CRAN, then we would have less of a maintenance burden overall

>       * Binary installs are easier so more people install it and thus field-test it on hardware that we don't have
>       * We would be covered by CRAN policies so uploads of Rcpp (or RcppEigen or BH) that break RStan builds or unit-tests aren't allowed
>       * Easier for R developers who are depending on RStan

[Ben Goodrich]

On Saturday, March 8, 2014 5:36:16 PM UTC-5, Bob Carpenter wrote:

Can we somehow guarantee that if Rcpp works, then RStan will work?

Beyond RStan's unit tests, no. But there is the CRAN principle (that Dirk follows as maintainer of Rcpp, BH, and RcppEigen) that if a new version of a dependency package causes RStan's unit tests to fail, then it is supposed to get sorted out before the new dependency package goes onto CRAN.
 

Installing Rcpp has been problematic for some users, despite its
being on CRAN, but the question is really whether it will assume
enough of a C++ toolchain for us?  Or are there still make issues
that can bite us or version issues with C++ compilers?

Installing Rcpp has been a problem, but we really should just refer those problems to the Rcpp list. There is reason to think that things will be better with the next version of R in April, which will have an environmental variable to compile under the C++11 standard (meaning with clang++ instead of llvm-g++-4.2 for Macs). So, we could probably abandon llvm-g++-4.2 at that point. RStan users would still have to have a toolchain to compile their models, but we could think about splitting RStan into two parts so that users would be able to run models that someone else compiled (e.g. CRAN for rstanarm).
 

As to testing (vs. Rcpp, RcppEigen, Boost tools, etc.), are we going to
be able to compile models and test running them and extracting results part
of our tests?  I thought there were serious limitations on the time CRAN will
allow.  In fact, I thought the compile time for bin/stanc was a dealbreaker
in and of itself for getting RStan on CRAN.

Not the compile time, the "minimum necessary size on disk". We were deemed not minimal due to bundling a giant chunk of Boost that could have been a system requirement (or a dependency on a future BH package). There is a limit of 5 minutes of wall time for testing / vignettes but we could do a couple of simple models.
 

Would CRAN distribution mean our binary will go out with -O2 compilation
through some version of g++?  If so, I'd like to test the performance hit
(if any).   Or can we specify our own optimization level?  I'm not
very good at remembering all the dependencies (hence my obsession with
reducing their number), but don't we have optimization-level dependencies
with Windows?

The package flags trump the R flags (and are trumped by the user's flags, but there is no user on CRAN). But I think stanc compiles under Windows with -O2 as long as there is no -g.

Ben

[Ben Goodrich]

On Saturday, March 8, 2014 6:28:51 PM UTC-5, Jiqiang Guo wrote:

I am not worrying about the speed since if that really matters, we can compile all the model code in O3.  The source code in the package mainly includes stanc, which is fine under not O3 if cran does not allow our current O3 configuration.

Besides that now I hate cran after my first attempt, compiling stanc is one concern since it takes some time that cran cannot spare.  I don't even see a slim opportunity to get rstan on cran, so why trying to get humiliated?

There isn't a limit on build time, just 5 minutes of test time.
 

Also I don't like the idea if we need have boost files from different places.

It isn't ideal, but if we had to do it for a couple of files because there was a bad bug in the CRAN version of BH or RcppEigen, it is an option. But if there is a bad bug in the CRAN version, then I would guess there would be a new version of it quickly because there are other packages that depend on them.

Ben
 

[Jiqiang Guo]

On Sat, Mar 8, 2014 at 6:44 PM, Ben Goodrich <goodri...@gmail.com> wrote:

On Saturday, March 8, 2014 6:28:51 PM UTC-5, Jiqiang Guo wrote:

I am not worrying about the speed since if that really matters, we can compile all the model code in O3.  The source code in the package mainly includes stanc, which is fine under not O3 if cran does not allow our current O3 configuration.

Besides that now I hate cran after my first attempt, compiling stanc is one concern since it takes some time that cran cannot spare.  I don't even see a slim opportunity to get rstan on cran, so why trying to get humiliated?

There isn't a limit on build time, just 5 minutes of test time.
 

Also I don't like the idea if we need have boost files from different places.

It isn't ideal, but if we had to do it for a couple of files because there was a bad bug in the CRAN version of BH or RcppEigen, it is an option. But if there is a bad bug in the CRAN version, then I would guess there would be a new version of it quickly because there are other packages that depend on them.

Ben
 

I was afraid that rstan needs boost files that are not included in BH.  But it looks like that BH is a big package now, so there might just a few files missing for rstan.  So the more important is to get BH upgraded to a version that Stan is fine with (and it would be nicer that additional files for rstan can be added). 

Jiqiang 

[Bob Carpenter]

On Mar 11, 2014, at 1:34 AM, Jiqiang Guo <guo...@gmail.com> wrote:

> I was afraid that rstan needs boost files that are not included in BH. But it looks like that BH is a big package now, so there might just a few files missing for rstan. So the more important is to get BH upgraded to a version that Stan is fine with (and it would be nicer that additional files for rstan can be added).

I think Stan's OK with Boost versions going pretty far back,
but you can always test in CmdStan.

- Bob

[Jiqiang Guo]

Not 1.51.0 (the one with part of it on CRAN):

--- Linking C++ model ---

g++ -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -DBOOST_DISABLE_ASSERTS -I src -I stan/src -isystem stan/lib/eigen_3.2.0 -isystem stan/lib/boost_1.51.0 -Wall -pipe -Wno-unused-function -ftemplate-depth-256    -O3 -o foo/bar src/cmdstan/main.cpp -include foo/bar.cpp -Lbin -lstan

In file included from <built-in>:167:

In file included from <command line>:4:

In file included from foo/bar.cpp:3:

In file included from stan/src/stan/model/model_header.hpp:34:

In file included from stan/src/stan/prob/distributions.hpp:4:

In file included from stan/src/stan/prob/distributions/univariate.hpp:4:

In file included from stan/src/stan/prob/distributions/univariate/continuous.hpp:20:

stan/src/stan/prob/distributions/univariate/continuous/skew_normal.hpp:436:20: error: no member named

      'skew_normal_distribution' in namespace 'boost::math'

      boost::math::skew_normal_distribution<>dist (mu, sigma, alpha);

      ~~~~~~~~~~~~~^

stan/src/stan/prob/distributions/univariate/continuous/skew_normal.hpp:436:45: error: expected expression

      boost::math::skew_normal_distribution<>dist (mu, sigma, alpha);

                                            ^

stan/src/stan/prob/distributions/univariate/continuous/skew_normal.hpp:436:46: error: use of undeclared identifier 'dist'

      boost::math::skew_normal_distribution<>dist (mu, sigma, alpha);

                                             ^

stan/src/stan/prob/distributions/univariate/continuous/skew_normal.hpp:450:23: error: use of undeclared identifier 'dist'; did

      you mean 'math::dist'?

      return quantile(dist, stan::prob::uniform_rng(0.0,1.0,rng));

                      ^~~~

                      math::dist

stan/src/stan/math/functions/dist.hpp:11:19: note: 'math::dist' declared here

    inline double dist(const std::vector<double>& x, const std::vector<double>& y) {

                  ^

4 errors generated.

make: *** [foo/bar] Error 1

 

- Bob

[Ben Goodrich]

On Monday, March 10, 2014 10:07:05 PM UTC-4, Jiqiang Guo wrote:

Not 1.51.0 (the one with part of it on CRAN):

I got it to build, install, pass check, and run examples/demo.R with BH on CRAN after a few changes. We will need BH to go to 1.54 for some things like odeint. But this is a project for May anyway after the new R release / change in policy about C++11.

Ben

[Bob Carpenter]

I'm not sure we're going to need C++11. We're not using it
now.

Michael --- what are you planning to do with C++11 in the
new autodiff stuff and is it critical? Is it just using
auto and calling another of a class's own constructors on init
lists?

- Bob

[Michael Betancourt]

auto, a bunch of other template stuff, final.  We might be able to get away with using

Boost for auto and the template stuff if absolutely necessary.  final was a nontrivial

speedup but we might be able to refactor around it.

[Bob Carpenter]

Thanks --- I didn't even realize final was a C++11 thing --- I'm
just so used to it from Java, where it started out being critical,
then the compilers got better and it didn't make much difference.

I'd just as soon move to C++11 if we can. I think R's really the only
holdup, and maybe some Windows tools, who knows.

- Bob

[Ben Goodrich]

On Tuesday, March 11, 2014 9:00:22 AM UTC-4, Bob Carpenter wrote:

Thanks --- I didn't even realize final was a C++11 thing --- I'm
just so used to it from Java, where it started out being critical,
then the compilers got better and it didn't make much difference.

I'd just as soon move to C++11 if we can.  I think R's really the only
holdup, and maybe some Windows tools, who knows.

If so (and I'm not disagreeing), then we should change the makefile(s), so that C++11 = true by default, and you just have to switch it to false if you are using llvm-g++-4.2 or some other old version of g++. Then, mingw-g++-4.6 on Windows becomes the least common denominator

http://gcc.gnu.org/gcc-4.6/cxx0x_status.html

and we can start to see what we can get away with using.

Ben

[Bob Carpenter]

The driving factor will be Michael's re-do of auto-diff, and I
don't think that's going to be ready to merge into Stan for a while.

If we go to C++11 in the code, we're going to need to use C++11 = true
always, not just by default. Before that, we need to make sure C++11
will run everywhere we need it to.

I can't keep track of all these Windows compilers --- is mingw-g++-4.6
what's distributed with Rtools? I can't make heads or tails of this
page:

http://cran.r-project.org/bin/windows/Rtools/

It'd be nice if they said which tools were included :-) And why in
the world don't they freeze a version for the latest release of R? This
is more helpful:

http://cran.r-project.org/bin/windows/Rtools/Rtools.txt

Our life would be so much easier without supporting either Windows or R
(of course, then we'd lose most of our users, though I guess that'd make
support easier, too :-)).

- Bob

[Daniel Lee]

On Tue, Mar 11, 2014 at 9:27 AM, Bob Carpenter <ca...@alias-i.com> wrote:

The driving factor will be Michael's re-do of auto-diff, and I
don't think that's going to be ready to merge into Stan for a while.

If we go to C++11 in the code, we're going to need to use C++11 = true
always, not just by default.  Before that, we need to make sure C++11
will run everywhere we need it to.

I can't keep track of all these Windows compilers --- is mingw-g++-4.6
what's distributed with Rtools?  I can't make heads or tails of this
page:

   http://cran.r-project.org/bin/windows/Rtools/

It'd be nice if they said which tools were included :-)  And why in
the world don't they freeze a version for the latest release of R?  This
is more helpful:

   http://cran.r-project.org/bin/windows/Rtools/Rtools.txt

It's a prerelease version of g++ 4.6.3. The output from `g++ -v` on our build box is at the end of this message.

Hopefully it covers enough of the C++11 standard for it to be really usable.

 

Our life would be so much easier without supporting either Windows or R
(of course, then we'd lose most of our users, though I guess that'd make
support easier, too :-)).

=). R is tricky. I'll send a message out, but I'm in a really bad state with my R / RStan installation.

 

C:\Users\daniel>g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=c:/rtools/gcc-4.6.3/bin/../libexec/gcc/i686-w64-mingw32/4.6.
3/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: /data/gannet/ripley/Sources/mingw-test3/src/gcc/configure --hos
t=i686-w64-mingw32 --build=x86_64-linux-gnu --target=i686-w64-mingw32 --with-sys
root=/data/gannet/ripley/Sources/mingw-test3/mingw32mingw32/mingw32 --prefix=/da
ta/gannet/ripley/Sources/mingw-test3/mingw32mingw32/mingw32 --with-gmp=/data/gan
net/ripley/Sources/mingw-test3/mingw32mingw32/prereq_install --with-mpfr=/data/g
annet/ripley/Sources/mingw-test3/mingw32mingw32/prereq_install --with-mpc=/data/
gannet/ripley/Sources/mingw-test3/mingw32mingw32/prereq_install --disable-shared
 --enable-static --enable-targets=all --enable-languages=c,c++,fortran --enable-
libgomp --enable-sjlj-exceptions --enable-fully-dynamic-string --disable-nls --d
isable-werror --enable-checking=release --disable-win32-registry --disable-rpath
 --disable-werror CFLAGS='-O2 -mtune=core2 -fomit-frame-pointer' LDFLAGS=
Thread model: win32
gcc version 4.6.3 20111208 (prerelease) (GCC)


 

[Ben Goodrich]

On Tuesday, March 11, 2014 9:27:16 AM UTC-4, Bob Carpenter wrote:

The driving factor will be Michael's re-do of auto-diff, and I
don't think that's going to be ready to merge into Stan for a while.

If we go to C++11 in the code, we're going to need to use C++11 = true
always, not just by default.  Before that, we need to make sure C++11
will run everywhere we need it to.

That's what I was saying that we need to try it out by default, particularly on Windows, for a little while before merging Michael's branch.
 

I can't keep track of all these Windows compilers --- is mingw-g++-4.6
what's distributed with Rtools?  I can't make heads or tails of this
page:

   http://cran.r-project.org/bin/windows/Rtools/

Yes, it says so on that page "R-patched subsequent to Jan 22, 2012, R-devel, and releases after 2.14.1 will use a new toolchain based on pre-4.6.3 gcc, put together by Prof. Brian Ripley" but more useful is

http://cran.r-project.org/web/checks/check_flavors.html
 

It'd be nice if they said which tools were included :-)  And why in
the world don't they freeze a version for the latest release of R?  

They bridge Rtools releases over R releases, so the currently unfrozen version of Rtools will work for R 3.1 when it is released in April and then Rtools will be frozen sometime thereafter. And a new unfrozen version will be started that works with 3.1 and 3.2. That said, they haven't actually changed much in Rtools for a couple of years.