Re: [Rd] Notes on building a gcc toolchain for Rtools (but not multilib)

[Avraham Adler]

> On Mon, Mar 9, 2015 at 10:40 AM, Duncan Murdoch
>  wrote:
> It's now on the main site at CRAN, and should propagate to the mirrors
> reasonably quickly.  I'm hoping that tomorrow's R-devel build will use it,
> but there may be some last minute problems.

Using Rtools 3.3, once it propagated through the cran servers, I have
successfully built a 64-bit version of R on Windows 7, up through make
rinstaller. This one includes using ICU_531, and also includes linking
to 64-bit OpenBLAS 2.13 (4 threads).

As with yesterday's build using 4.9.2.-seh (although that one left ICU
out) the only issue that seems to have failed in make check-all is the
internet connectivity, which is disabled by default. Loading R and
passing setinternet2() fixes that, and I plan on using the options
built into the installer I create to have that set at install (like
SDI). Is it at all possible to have that setting exposed in
Mkrules.dist so as to be set at compile?

I also built microbenchmark, which requires packages ‘colorspace’,
‘Rcpp’, ‘stringr’, ‘RColorBrewer’, ‘dichromat’, ‘munsell’, ‘labeling’,
‘plyr’, ‘digest’, ‘gtable’, ‘reshape2’, ‘scales’, ‘proto’, and
‘ggplot2’, and they all worked fine. For what it is worth, I forgot to
uncomment (unhash) Hsiu-Khuern's addition to the NM filter, yet Rcpp
built fine and compiled C++ code fine as well, although about 3%-5%
slower than what I recall from last night's seh version.

So, outside of this hiccup with somehow now needing internet2 (which
may have to do with microsoft Windows patches for all I know) which
cannot be set at default, it seems as if the toolchain is behaving
well! I have not tried building with curl, though; that looks a bit
more hairy, although it may address the internet2 issue, who knows.

For interest sakes, below is a comparison of speed across various
versions/compilers which may prove of interest. The takeaway for me is
that for matrix code a fast BLAS is significantly more important than
which version of GCC and exception handling is used. For non-BLAS
specific code, at least on my machine, the SJLJ performed about 1%–2%
*faster*. Go figure! Maybe someone will run Simon Urbanek's benchmark
against them.

Regardless, I'm much less apprehensive about 3.2's release in April.
Thank you, Duncan and all!


Avi



== Speed results compiled over a few months (except for the last two) ==

For the record, all code run on an Intel i7-2600K overclocked to
4.6Ghz, 16GB RAM, Windows 7 64bit Matrices A and B are 1000x1000 dense
matrices, of which A is positive semi-definite and B is not. I use
this to test BLAS builds. I hope that the fixed width works in plain
text model.

=== Non-BLAS dependent ===

#Test code
library(microbenchmark)
A <- as.matrix(read.csv(file="F:/R/A.csv", colClasses='numeric'))
B <- as.matrix(read.csv(file="F:/R/B.csv", colClasses='numeric'))
colnames(A) <- colnames(B) <- NULL
Z <- microbenchmark(A + 2, A - 2, A * 2, A / 2, A + B, A - B, A * B, A
/ B, A ^ 2, sqrt(A), control=list(order = 'block'), times = 1000L)


 R-devel_2015-03-08 compiled using
x86_64-4.9.2-release-win32-seh-rt_v3-rev1 (EOPTS = -O3 -march=native
-mfpmath=sse -msse2avx -mavx256-split-unaligned-load
-mavx256-split-unaligned-store -mvzeroupper -std=gnu++11 -pipe)
 OpenBLAS 2.13 - Multi-threaded (max 4 threads) - compiled under GCC
4.9.1 (MinGW-64)

 Unit: microseconds
expr   minlq  meanmedianuq  max neval
   A + 2   923.001  1844.215  2205.385  1858.957  1990.900 21714.18  1000
   A - 2  1742.652  1830.215  2196.901  1844.810  2507.798 21778.22  1000
   A * 2  1743.247  1843.023  2208.374  1860.298  2547.112 21776.43  1000
 A/2  2025.598  2111.375  2438.503  2122.097  2701.243 22034.06  1000
   A + B  2016.662  2124.182  2554.006  2143.690  2948.896 21964.07  1000
   A - B  2004.153  2103.930  2527.219  2128.203  2982.552 22295.27  1000
   A * B  2023.215  2119.715  2540.680  2141.010  3154.553 22074.27  1000
 A/B  3256.265  3354.700  3633.556  3368.252  3953.950 23189.67  1000
 A^2  1745.332  1835.279  2204.023  1850.469  2554.856 21869.66  1000
 sqrt(A) 49945.064 50066.434 50506.344 50187.356 50883.403 70006.25  1000


R-devel_2015-03-09 compiled using Rtools 3.3 (GCC 4.9.2, SJLJ, EOPTS =
-O3 -march=native -mfpmath=sse -msse2avx -mavx256-split-unaligned-load
-mavx256-split-unaligned-store -mvzeroupper -std=gnu++11 -pipe)
OpenBLAS 2.13 - Multi-threaded (max 4 threads) - compiled under GCC
4.9.1 (MinGW-64)

Unit: microseconds
expr   minlq  meanmedianuq  max neval
   A + 2   925.980  1777.350  2167.326  1791.795  2384.641 21660.28  1000
   A - 2  1673.256  1777.648  2188.756  1806.687  2670.715 21724.01  1000
   A * 2  1680.999  1786.434  2221.432  1835.130  2766.916 22254.16  1000
 A/2  1992.836  2085.165  2450.455  2108.694  2865.203 22803.08  1000
   A + B  1977.646  2089.632  2559.912  2121.204  3031.397 22884.99  1000
   A - B  1979.135  2081.591  2516.943  2101.398  3003.548 22377.77  1000
   

Re: [Rd] ICU_531 and sjlj vs.seh

[Avraham Adler]

Just to close the loop (and prevent this xkcd cartoon from becoming
even more true ), the answer to this question
was addressed in this post
 and
subsequent.

Avi

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Notes on building a gcc toolchain for Rtools (but not multilib)

[Duncan Murdoch]

On 09/03/2015 11:02 PM, Hsiu-Khuern Tang wrote:
> Hi Duncan,
> 
> On Mon, Mar 9, 2015 at 10:40 AM, Duncan Murdoch
>  wrote:
>> On 09/03/2015 11:07 AM, Hsiu-Khuern Tang wrote:
>>>
>>> On Mon, Mar 9, 2015 at 3:50 AM, Duncan Murdoch 
>>> wrote:
 On 08/03/2015 10:02 PM, Hsiu-Khuern Tang wrote:
> Hi,
>
> [This is a follow-up to the "New version of Rtools for Windows" thread
> in January, but I just subscribed and don't know how to reply to an
> old thread -- my apologies.]

 I am planning to put a new Rtools online today that uses a different
 build of gcc 4.9.2.  I will be concentrating on getting it to work with
 all the external libraries before the 3.2.0 release next month.  I'm not
 planning to try to get it to work with R-patched, and I expect it won't:
  I needed to make a number of patches to R-devel for compatibility.
>>>
>>> I also worked off R-devel (I said wrongly that it was R-patched in my
>>> original post) and benefited from your compatibility changes.
>>>
>>> I look forward to the new Rtools and will test it by compiling some
>>> packages.
>>
>>
>> It's now on the main site at CRAN, and should propagate to the mirrors
>> reasonably quickly.  I'm hoping that tomorrow's R-devel build will use it,
>> but there may be some last minute problems.
> 
> Is the new Rtools at
> http://cran.r-project.org/bin/windows/Rtools/Rtools33.exe?  I'm still
> getting "Error 404 object not found".

There were some permission problems on the file for a while yesterday;
perhaps the index page got propagated but the actual file didn't.

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] R_HOME default setting

[Karim Mezhoud]

Dear All,
I would like to reset default R_HOME PATH for R.3.1.3.
I installed R-devel in /usr/local/R-devel but I can't install many packages
as tcltk.
I uninstalled R-devel and I would reuse R.3.1.3 but the PATH is remaining
to  /usr/local/R-devel.

I touch ~.Renviron file with

R_HOME=/usr/lib/R/bin/
RSTUDIO_R_HOME=/usr/lib/R/bin/

R_LIBS=~/R/x86_64-pc-linux-gnu-library/3.1

R_LIBS_USER=${R_LIBS_USER-'~/R/x86_64-pc-linux-gnu-library/3.1'}

Without success.
Any idea?
which file has the R_HOME setting?
Thanks
Karim

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Notes on building a gcc toolchain for Rtools (but not multilib)

[Dan Tenenbaum]

- Original Message -
> From: "Duncan Murdoch" 
> To: "Hsiu-Khuern Tang" , r-devel@r-project.org
> Sent: Monday, March 9, 2015 10:40:02 AM
> Subject: Re: [Rd] Notes on building a gcc toolchain for Rtools (but not   
> multilib)
> 
> On 09/03/2015 11:07 AM, Hsiu-Khuern Tang wrote:
> > On Mon, Mar 9, 2015 at 3:50 AM, Duncan Murdoch
> >  wrote:
> > > On 08/03/2015 10:02 PM, Hsiu-Khuern Tang wrote:
> > >> Hi,
> > >>
> > >> [This is a follow-up to the "New version of Rtools for Windows"
> > >> thread
> > >> in January, but I just subscribed and don't know how to reply to
> > >> an
> > >> old thread -- my apologies.]
> > >
> > > I am planning to put a new Rtools online today that uses a
> > > different
> > > build of gcc 4.9.2.  I will be concentrating on getting it to
> > > work with
> > > all the external libraries before the 3.2.0 release next month.
> > >  I'm not
> > > planning to try to get it to work with R-patched, and I expect it
> > > won't:
> > >  I needed to make a number of patches to R-devel for
> > >  compatibility.
> >
> > I also worked off R-devel (I said wrongly that it was R-patched in
> > my
> > original post) and benefited from your compatibility changes.
> >
> > I look forward to the new Rtools and will test it by compiling some
> > packages.
> 
> It's now on the main site at CRAN, and should propagate to the
> mirrors
> reasonably quickly.  I'm hoping that tomorrow's R-devel build will
> use
> it, but there may be some last minute problems.
> 

Thanks to you and everyone who worked on this. Is there a way to tell which 
toolchain built a given R-devel binary?
If not, can you let us know when there is one on CRAN that was built with the 
new Rtools?

Thanks,
Dan


> Duncan Murdoch
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Seed in 'parallel' vignette

[Martin Maechler]

> Marius Hofert 
> on Sun, 8 Mar 2015 11:19:45 -0400 writes:

> On Tue, Feb 3, 2015 at 10:39 AM, Marius Hofert
>  wrote:
>> Hi,
>> 
>> This is most likely only a minor technicality, but I saw the
>> following: On page 6 of the 'parallel' vignette
>> (http://stat.ethz.ch/R-manual/R-devel/library/parallel/doc/parallel.pdf),
>> the random-number generator "L'Ecuyer-CMRG" is said to have seed
>> "(x_n, x_{n-1}, x_{n-2}, y_n, y_{n-1}, y_{n-2})". However, in L'Ecuyer
>> et al. (2002), the seed is given with 'increasing' indices, so should
>> rather be "(x_{n-2}, x_{n-1}, x_n, y_{n-2}, y_{n-1}, y_n)" (or, even
>> more intuitively, "(x_{n-3}, x_{n-2}, x_{n-1}, y_{n-3}, y_{n-2},
>> y_{n-1})"). The question is how it's done in R (?):

> ... in the meanwhile, I found out that this is indeed a typo in the
> vignette. I suggest to change it to "(x_{n-3}, x_{n-2}, x_{n-1},
> y_{n-3}, y_{n-2}, y_{n-1})" on page 6 in the version of October 31, 2014.

Thank you, Marius.
I've committed this change now.

With regards: Martin

>> If as given in the
>> vignette, one should maybe point this out as other (languages)
>> following L'Ecuyer et al. (2002) might obtain different random numbers
>> then. And if it's implemented as in L'Ecuyer, then one probably wants
>> to adjust the vignette to reflect this.
>> 
>> Other minor suggestions to improve the vignette (if that's what's also
>> done in R; I couldn't easily figure that out from ./src/main/RNG.c):
>> 1) when defining u_n, I would write u_n = z_n / (2^32-208) [as it is
>> immediately clear then that one divides by the modulus of the first
>> linear congruential generator + 1]
>> 2) The case z_n=0 is not provided (for a reason?). If z_n=0, L'Ecuyer
>> suggests to set u_n to "(2^32-209)/(2^32-208)".
>> 
>> Cheers,
>> Marius
>> 
>> 
>> 
>> 
>> --
>> Marius Hofert, Dr. rer. nat.
>> Assistant Professor
>> Department of Statistics and Actuarial Science
>> Faculty of Mathematics
>> University of Waterloo
>> 200 University Avenue West, Waterloo, ON, N2L 3G1
>> +1-519-888-4567, ext. 31394 (office M3 4207)
>> http://math.uwaterloo.ca/~mhofert



> -- 
> Marius Hofert, Dr. rer. nat.
> Assistant Professor
> Department of Statistics and Actuarial Science
> Faculty of Mathematics
> University of Waterloo
> 200 University Avenue West, Waterloo, ON, N2L 3G1
> +1-519-888-4567, ext. 31394 (office M3 4207)
> http://math.uwaterloo.ca/~mhofert

> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Notes on building a gcc toolchain for Rtools (but not multilib)

[Hsiu-Khuern Tang]

On Tue, Mar 10, 2015 at 4:07 AM, Duncan Murdoch
 wrote:
> On 09/03/2015 11:02 PM, Hsiu-Khuern Tang wrote:
>> Hi Duncan,
>>
>> On Mon, Mar 9, 2015 at 10:40 AM, Duncan Murdoch
>>  wrote:
>>> On 09/03/2015 11:07 AM, Hsiu-Khuern Tang wrote:

 On Mon, Mar 9, 2015 at 3:50 AM, Duncan Murdoch 
 wrote:
> On 08/03/2015 10:02 PM, Hsiu-Khuern Tang wrote:
>> Hi,
>>
>> [This is a follow-up to the "New version of Rtools for Windows" thread
>> in January, but I just subscribed and don't know how to reply to an
>> old thread -- my apologies.]
>
> I am planning to put a new Rtools online today that uses a different
> build of gcc 4.9.2.  I will be concentrating on getting it to work with
> all the external libraries before the 3.2.0 release next month.  I'm not
> planning to try to get it to work with R-patched, and I expect it won't:
>  I needed to make a number of patches to R-devel for compatibility.

 I also worked off R-devel (I said wrongly that it was R-patched in my
 original post) and benefited from your compatibility changes.

 I look forward to the new Rtools and will test it by compiling some
 packages.
>>>
>>>
>>> It's now on the main site at CRAN, and should propagate to the mirrors
>>> reasonably quickly.  I'm hoping that tomorrow's R-devel build will use it,
>>> but there may be some last minute problems.
>>
>> Is the new Rtools at
>> http://cran.r-project.org/bin/windows/Rtools/Rtools33.exe?  I'm still
>> getting "Error 404 object not found".
>
> There were some permission problems on the file for a while yesterday;
> perhaps the index page got propagated but the actual file didn't.
>
> Duncan Murdoch
>

Got it now, thanks!  Are you planning to publish the build scripts for
the new Rtools as well?

I did the following limited test on the new Rtools:

R CMD INSTALL --no-multiarch Rcpp_0.11.5.tar.gz

I did this under various settings:

- the default settings
- with -std=c++11 added to CXXFLAGS in my .R\Makevars file.

This was done under the newly released R-3.1.3, using the 64-bit R binary.

Here are my findings:

- With the default settings, the command succeeded

- With -std=c++11, there were two problems:
  + api.cpp failed to compile because it could not find execinfo.h
* I worked around this by using CXXFLAGS=-DWIN32 -std=c++11
* CXXFLAGS=-std=gnu++11 also works around this
* Maybe Rcpp needs to guard against this?
  + the package could not be loaded because some of the object files
contain symbols named .refptr.* and .weak.*, which should be excluded
from the exports list
* To work around this, put this line in .R\Makevars: NM_FILTER = |
sed -e '/\.refptr\./d; /\.weak\./d'


- Hsiu-Khuern

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Notes on building a gcc toolchain for Rtools (but not multilib)

[Duncan Murdoch]

On 10/03/2015 12:54 PM, Dan Tenenbaum wrote:


- Original Message -
> From: "Duncan Murdoch" 
> To: "Hsiu-Khuern Tang" , r-devel@r-project.org
> Sent: Monday, March 9, 2015 10:40:02 AM
> Subject: Re: [Rd] Notes on building a gcc toolchain for Rtools (but not
multilib)
>
> On 09/03/2015 11:07 AM, Hsiu-Khuern Tang wrote:
> > On Mon, Mar 9, 2015 at 3:50 AM, Duncan Murdoch
> >  wrote:
> > > On 08/03/2015 10:02 PM, Hsiu-Khuern Tang wrote:
> > >> Hi,
> > >>
> > >> [This is a follow-up to the "New version of Rtools for Windows"
> > >> thread
> > >> in January, but I just subscribed and don't know how to reply to
> > >> an
> > >> old thread -- my apologies.]
> > >
> > > I am planning to put a new Rtools online today that uses a
> > > different
> > > build of gcc 4.9.2.  I will be concentrating on getting it to
> > > work with
> > > all the external libraries before the 3.2.0 release next month.
> > >  I'm not
> > > planning to try to get it to work with R-patched, and I expect it
> > > won't:
> > >  I needed to make a number of patches to R-devel for
> > >  compatibility.
> >
> > I also worked off R-devel (I said wrongly that it was R-patched in
> > my
> > original post) and benefited from your compatibility changes.
> >
> > I look forward to the new Rtools and will test it by compiling some
> > packages.
>
> It's now on the main site at CRAN, and should propagate to the
> mirrors
> reasonably quickly.  I'm hoping that tomorrow's R-devel build will
> use
> it, but there may be some last minute problems.
>

Thanks to you and everyone who worked on this. Is there a way to tell which 
toolchain built a given R-devel binary?
If not, can you let us know when there is one on CRAN that was built with the 
new Rtools?


If you look in etc/*/Makeconf, you'll see something like this:

BINPREF ?= $(RTOOLS)gcc492_64/bin/

hopefully from tomorrow onwards.  If today's build was with the new 
toolchain, you should see a hardcoded path to where I have Rtools 
installed on the build machine, which isn't so helpful.  The previous 
toolchain left BINPREF blank.


If you want to use your own toolchain, just edit those files.  If you 
want to install the standard Rtools somewhere else, set an environment 
variable like


RTOOLS = C:/Rtools/

(where the terminal / is required.)

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Notes on building a gcc toolchain for Rtools (but not multilib)

[Duncan Murdoch]

On 10/03/2015 2:26 PM, Hsiu-Khuern Tang wrote:

On Tue, Mar 10, 2015 at 4:07 AM, Duncan Murdoch
 wrote:
> On 09/03/2015 11:02 PM, Hsiu-Khuern Tang wrote:
>> Hi Duncan,
>>
>> On Mon, Mar 9, 2015 at 10:40 AM, Duncan Murdoch
>>  wrote:
>>> On 09/03/2015 11:07 AM, Hsiu-Khuern Tang wrote:

 On Mon, Mar 9, 2015 at 3:50 AM, Duncan Murdoch 
 wrote:
> On 08/03/2015 10:02 PM, Hsiu-Khuern Tang wrote:
>> Hi,
>>
>> [This is a follow-up to the "New version of Rtools for Windows" thread
>> in January, but I just subscribed and don't know how to reply to an
>> old thread -- my apologies.]
>
> I am planning to put a new Rtools online today that uses a different
> build of gcc 4.9.2.  I will be concentrating on getting it to work with
> all the external libraries before the 3.2.0 release next month.  I'm not
> planning to try to get it to work with R-patched, and I expect it won't:
>  I needed to make a number of patches to R-devel for compatibility.

 I also worked off R-devel (I said wrongly that it was R-patched in my
 original post) and benefited from your compatibility changes.

 I look forward to the new Rtools and will test it by compiling some
 packages.
>>>
>>>
>>> It's now on the main site at CRAN, and should propagate to the mirrors
>>> reasonably quickly.  I'm hoping that tomorrow's R-devel build will use it,
>>> but there may be some last minute problems.
>>
>> Is the new Rtools at
>> http://cran.r-project.org/bin/windows/Rtools/Rtools33.exe?  I'm still
>> getting "Error 404 object not found".
>
> There were some permission problems on the file for a while yesterday;
> perhaps the index page got propagated but the actual file didn't.
>
> Duncan Murdoch
>

Got it now, thanks!  Are you planning to publish the build scripts for
the new Rtools as well?


Yes, they are on pre-CRAN now (that's where I put things, CRAN picks 
them up from there, the mirrors pick them up from CRAN).  Not sure when 
they'll propagate, but the URL is


bin/windows/Rtools/scripts

I'm going to be uploading a new Rtools33.exe in a few minutes.  It puts 
back gdb, which had been included in the 4.6.3 build but not this one; 
it is now in Rtools/bin as gdb.exe for 32 bits and gdb64.exe for 64 
bits.  It also cleans up the PATH editing; the new scheme doesn't need 
gcc to be on the PATH.  And the index page points to the scripts.


Duncan Murdoch


I did the following limited test on the new Rtools:

R CMD INSTALL --no-multiarch Rcpp_0.11.5.tar.gz

I did this under various settings:

- the default settings
- with -std=c++11 added to CXXFLAGS in my .R\Makevars file.

This was done under the newly released R-3.1.3, using the 64-bit R binary.

Here are my findings:

- With the default settings, the command succeeded

- With -std=c++11, there were two problems:
   + api.cpp failed to compile because it could not find execinfo.h
 * I worked around this by using CXXFLAGS=-DWIN32 -std=c++11
 * CXXFLAGS=-std=gnu++11 also works around this
 * Maybe Rcpp needs to guard against this?
   + the package could not be loaded because some of the object files
contain symbols named .refptr.* and .weak.*, which should be excluded
from the exports list
 * To work around this, put this line in .R\Makevars: NM_FILTER = |
sed -e '/\.refptr\./d; /\.weak\./d'


- Hsiu-Khuern

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Notes on building a gcc toolchain for Rtools (but not multilib)

[Dan Tenenbaum]

- Original Message -
> From: "Duncan Murdoch" 
> To: "Dan Tenenbaum" 
> Cc: "Hsiu-Khuern Tang" , r-devel@r-project.org
> Sent: Tuesday, March 10, 2015 11:37:12 AM
> Subject: Re: [Rd] Notes on building a gcc toolchain for Rtools (but not 
> multilib)
> 
> On 10/03/2015 12:54 PM, Dan Tenenbaum wrote:
> >
> > - Original Message -
> > > From: "Duncan Murdoch" 
> > > To: "Hsiu-Khuern Tang" , r-devel@r-project.org
> > > Sent: Monday, March 9, 2015 10:40:02 AM
> > > Subject: Re: [Rd] Notes on building a gcc toolchain for Rtools
> > > (but not  multilib)
> > >
> > > On 09/03/2015 11:07 AM, Hsiu-Khuern Tang wrote:
> > > > On Mon, Mar 9, 2015 at 3:50 AM, Duncan Murdoch
> > > >  wrote:
> > > > > On 08/03/2015 10:02 PM, Hsiu-Khuern Tang wrote:
> > > > >> Hi,
> > > > >>
> > > > >> [This is a follow-up to the "New version of Rtools for
> > > > >> Windows"
> > > > >> thread
> > > > >> in January, but I just subscribed and don't know how to
> > > > >> reply to
> > > > >> an
> > > > >> old thread -- my apologies.]
> > > > >
> > > > > I am planning to put a new Rtools online today that uses a
> > > > > different
> > > > > build of gcc 4.9.2.  I will be concentrating on getting it to
> > > > > work with
> > > > > all the external libraries before the 3.2.0 release next
> > > > > month.
> > > > >  I'm not
> > > > > planning to try to get it to work with R-patched, and I
> > > > > expect it
> > > > > won't:
> > > > >  I needed to make a number of patches to R-devel for
> > > > >  compatibility.
> > > >
> > > > I also worked off R-devel (I said wrongly that it was R-patched
> > > > in
> > > > my
> > > > original post) and benefited from your compatibility changes.
> > > >
> > > > I look forward to the new Rtools and will test it by compiling
> > > > some
> > > > packages.
> > >
> > > It's now on the main site at CRAN, and should propagate to the
> > > mirrors
> > > reasonably quickly.  I'm hoping that tomorrow's R-devel build
> > > will
> > > use
> > > it, but there may be some last minute problems.
> > >
> >
> > Thanks to you and everyone who worked on this. Is there a way to
> > tell which toolchain built a given R-devel binary?
> > If not, can you let us know when there is one on CRAN that was
> > built with the new Rtools?
> 
> If you look in etc/*/Makeconf, you'll see something like this:
> 
> BINPREF ?= $(RTOOLS)gcc492_64/bin/
> 
> hopefully from tomorrow onwards.  If today's build was with the new
> toolchain, you should see a hardcoded path to where I have Rtools
> installed on the build machine, which isn't so helpful.  The previous
> toolchain left BINPREF blank.
> 
> If you want to use your own toolchain, just edit those files.  If you
> want to install the standard Rtools somewhere else, set an
> environment
> variable like
> 
> RTOOLS = C:/Rtools/
> 
> (where the terminal / is required.)
> 

Thanks, that's very helpful. I also notice with the latest R-devel binary 
(67969, which is built with the new Rtools according to what you say above) 
that I need to do setInternet2(TRUE) before I can download from any URLs; I see 
some mention of that earlier in this thread, is this intended? If so is there a 
way to make this the default?

Thanks,
Dan


> 
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Notes on building a gcc toolchain for Rtools (but not multilib)

[Duncan Murdoch]

On 10/03/2015 2:56 PM, Dan Tenenbaum wrote:
> 
> 
> - Original Message -
>> From: "Duncan Murdoch" 
>> To: "Dan Tenenbaum" 
>> Cc: "Hsiu-Khuern Tang" , r-devel@r-project.org
>> Sent: Tuesday, March 10, 2015 11:37:12 AM
>> Subject: Re: [Rd] Notes on building a gcc toolchain for Rtools (but not 
>> multilib)
>>
>> On 10/03/2015 12:54 PM, Dan Tenenbaum wrote:
>>>
>>> - Original Message -
 From: "Duncan Murdoch" 
 To: "Hsiu-Khuern Tang" , r-devel@r-project.org
 Sent: Monday, March 9, 2015 10:40:02 AM
 Subject: Re: [Rd] Notes on building a gcc toolchain for Rtools
 (but not   multilib)

 On 09/03/2015 11:07 AM, Hsiu-Khuern Tang wrote:
> On Mon, Mar 9, 2015 at 3:50 AM, Duncan Murdoch
>  wrote:
>> On 08/03/2015 10:02 PM, Hsiu-Khuern Tang wrote:
>>> Hi,
>>>
>>> [This is a follow-up to the "New version of Rtools for
>>> Windows"
>>> thread
>>> in January, but I just subscribed and don't know how to
>>> reply to
>>> an
>>> old thread -- my apologies.]
>>
>> I am planning to put a new Rtools online today that uses a
>> different
>> build of gcc 4.9.2.  I will be concentrating on getting it to
>> work with
>> all the external libraries before the 3.2.0 release next
>> month.
>>  I'm not
>> planning to try to get it to work with R-patched, and I
>> expect it
>> won't:
>>  I needed to make a number of patches to R-devel for
>>  compatibility.
>
> I also worked off R-devel (I said wrongly that it was R-patched
> in
> my
> original post) and benefited from your compatibility changes.
>
> I look forward to the new Rtools and will test it by compiling
> some
> packages.

 It's now on the main site at CRAN, and should propagate to the
 mirrors
 reasonably quickly.  I'm hoping that tomorrow's R-devel build
 will
 use
 it, but there may be some last minute problems.

>>>
>>> Thanks to you and everyone who worked on this. Is there a way to
>>> tell which toolchain built a given R-devel binary?
>>> If not, can you let us know when there is one on CRAN that was
>>> built with the new Rtools?
>>
>> If you look in etc/*/Makeconf, you'll see something like this:
>>
>> BINPREF ?= $(RTOOLS)gcc492_64/bin/
>>
>> hopefully from tomorrow onwards.  If today's build was with the new
>> toolchain, you should see a hardcoded path to where I have Rtools
>> installed on the build machine, which isn't so helpful.  The previous
>> toolchain left BINPREF blank.
>>
>> If you want to use your own toolchain, just edit those files.  If you
>> want to install the standard Rtools somewhere else, set an
>> environment
>> variable like
>>
>> RTOOLS = C:/Rtools/
>>
>> (where the terminal / is required.)
>>
> 
> Thanks, that's very helpful. I also notice with the latest R-devel binary 
> (67969, which is built with the new Rtools according to what you say above) 
> that I need to do setInternet2(TRUE) before I can download from any URLs; I 
> see some mention of that earlier in this thread, is this intended? If so is 
> there a way to make this the default?

That's a bug.  I haven't tracked down what's going wrong with our
regular code.  If I can't find that and fix it soon, I'll make Internet2
the default.  For now, you can do it yourself using the instructions on
?setInternet2.

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R_HOME default setting

[Gavin Simpson]

Wrong list, as you've been told several times yet you seemingly decided to
ignore the advice!

Your question would be on topic for R-Help. But please do your homework and
check that the issue is not documented somewhere first. You've spammed this
list enough already without you doing the same to R-Help.

G

On 10 March 2015 at 09:31, Karim Mezhoud  wrote:

> Dear All,
> I would like to reset default R_HOME PATH for R.3.1.3.
> I installed R-devel in /usr/local/R-devel but I can't install many packages
> as tcltk.
> I uninstalled R-devel and I would reuse R.3.1.3 but the PATH is remaining
> to  /usr/local/R-devel.
>
> I touch ~.Renviron file with
>
> R_HOME=/usr/lib/R/bin/
> RSTUDIO_R_HOME=/usr/lib/R/bin/
>
> R_LIBS=~/R/x86_64-pc-linux-gnu-library/3.1
>
> R_LIBS_USER=${R_LIBS_USER-'~/R/x86_64-pc-linux-gnu-library/3.1'}
>
> Without success.
> Any idea?
> which file has the R_HOME setting?
> Thanks
> Karim
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Gavin Simpson, PhD

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Notes on building a gcc toolchain for Rtools (but not multilib)

[Avraham Adler]

On Tue, Mar 10, 2015 at 3:17 PM, Duncan Murdoch
 wrote:
>
> That's a bug.  I haven't tracked down what's going wrong with our
> regular code.  If I can't find that and fix it soon, I'll make Internet2
> the default.  For now, you can do it yourself using the instructions on
> ?setInternet2.
>
> Duncan Murdoch

I successfully rebuilt R-devel_2015-03-09 with the most recent version
of Rtools tonight, building both ICU_531 and this time libcurl (7.39)
as well (and OpenBLAS, of course). The internet bug is still there,
but the rest of make-check all passed with flying colors, as did
building 'microbenchmark' from source (with all the other needed
packages, including Rcpp and Hsiu-Kheurn's change to NM was *not*
used). My non-BLAS test tonight ran faster than last night; maybe 1000
iterations aren't enough or I had something else eating up clock
cycles last night. Either way, outside the internet bug, it's looking
good for Windows 64bit (Win7 at least).

Thanks,

Avi

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Notes on building a gcc toolchain for Rtools (but not multilib)

[Hsiu-Khuern Tang]

On Tue, Mar 10, 2015 at 8:54 PM, Avraham Adler  wrote:
> On Tue, Mar 10, 2015 at 3:17 PM, Duncan Murdoch
>  wrote:
>>
>> That's a bug.  I haven't tracked down what's going wrong with our
>> regular code.  If I can't find that and fix it soon, I'll make Internet2
>> the default.  For now, you can do it yourself using the instructions on
>> ?setInternet2.
>>
>> Duncan Murdoch
>
> I successfully rebuilt R-devel_2015-03-09 with the most recent version
> of Rtools tonight, building both ICU_531 and this time libcurl (7.39)
> as well (and OpenBLAS, of course). The internet bug is still there,
> but the rest of make-check all passed with flying colors, as did
> building 'microbenchmark' from source (with all the other needed
> packages, including Rcpp and Hsiu-Kheurn's change to NM was *not*
> used).
> ...

The NM_FILTER change seems to be needed only when compiling C++ code
with -std=c++11 or -std=gnu++11.

Even though the current CRAN policy doesn't allow the C++11 standard,
it would still be useful to document this, perhaps in the Writing R
Extensions manual.

- Hsiu-Khuern

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Notes on building a gcc toolchain for Rtools (but not multilib)

[Avraham Adler]

On Wed, Mar 11, 2015 at 1:40 AM, Hsiu-Khuern Tang  wrote:
> On Tue, Mar 10, 2015 at 8:54 PM, Avraham Adler  
> wrote:
>>
>> I successfully rebuilt R-devel_2015-03-09 with the most recent version
>> of Rtools tonight, building both ICU_531 and this time libcurl (7.39)
>> as well (and OpenBLAS, of course). The internet bug is still there,
>> but the rest of make-check all passed with flying colors, as did
>> building 'microbenchmark' from source (with all the other needed
>> packages, including Rcpp and Hsiu-Kheurn's change to NM was *not*
>> used).
>> ...
>
> The NM_FILTER change seems to be needed only when compiling C++ code
> with -std=c++11 or -std=gnu++11.
>
> Even though the current CRAN policy doesn't allow the C++11 standard,
> it would still be useful to document this, perhaps in the Writing R
> Extensions manual.
>
> - Hsiu-Khuern

Hello, Hsiu-Khuern.

All the times I have built, I've passed -std-gnu++11. Specifically, I
pass: -march=native -O3 -mfpmath=sse -std=gnu++11 -msse2avx
-mavx256-split-unaligned-load -mavx256-split-unaligned-store
-mvzeroupper --param l1-cache-line-size=64 --param l1-cache-size=64
--param l2-cache-size=256. I live with the repeated warnings that it
isn't needed for gcc, but I know it takes as I see the same string
(gnu++11) passed when I build Rcpp from inside an R session.

Avi

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel