[Rd] Failing lm-tests due to extra 0 in scientific notation?
Hello.
I've compiled R on Windows many times, and this is the first time I've
seen this error. While running make check-all (and using
testInstalledBasic("both")), the lm-tests routines fail, and, as far
as I can tell, the diff is failing because in one file, answers are
coming back like this "3.11e-004" while in the save file they are
"3.11e-04". Every value is the same, outside the extra 0 in the
scientific notation. I've never seen R put two 0s in a row like that
before, and I cannot think of why that would happen. Is there a way to
change that so that it passes the tests?
Thank you,
Avi
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] New version of Rtools for Windows
I have just uploaded to CRAN a new version 3.2.0.1948 of Rtools for Windows. This will become visible there in a few hours, and be copied to mirrors thereafter. People who want to build packages that include compiled code can use this to supply the compilers, etc., that are necessary for the build. It also includes some extra materials for people who want to build R itself. This version includes only minor updates to the tools. I indicated last summer that I was hoping to update GCC from the current version 4.6.3 before the R 3.2.0 release, but this now looks unlikely, unless someone else with experience building it can help. (I need a new build script for it that I can run, not just a binary copy. So far I have been unsuccessful in updating the scripts inhttp://www.stats.ox.ac.uk/pub/Rtools/multilib/multi.zip , or finding other scripts online that work.) Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Failing lm-tests due to extra 0 in scientific notation?
Please let me clarify. When I said "is there a way to change that," I
meant, does anyone know why R would respond that way, and does anyone have
any suggestions as to what I can do or what I should investigate to get my
compilation to conform. I did *not* mean, "can we change the reference." I
apologize for any unintentional implications.
Avi
On Wed, Jan 7, 2015 at 1:24 AM, Avraham Adler
wrote:
> Hello.
>
> I've compiled R on Windows many times, and this is the first time I've
> seen this error. While running make check-all (and using
> testInstalledBasic("both")), the lm-tests routines fail, and, as far
> as I can tell, the diff is failing because in one file, answers are
> coming back like this "3.11e-004" while in the save file they are
> "3.11e-04". Every value is the same, outside the extra 0 in the
> scientific notation. I've never seen R put two 0s in a row like that
> before, and I cannot think of why that would happen. Is there a way to
> change that so that it passes the tests?
>
> Thank you,
>
> Avi
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Failing lm-tests due to extra 0 in scientific notation?
On 07/01/2015 06:24, Avraham Adler wrote:
Hello.
I've compiled R on Windows many times, and this is the first time I've
seen this error. While running make check-all (and using
testInstalledBasic("both")), the lm-tests routines fail, and, as far
as I can tell, the diff is failing because in one file, answers are
coming back like this "3.11e-004" while in the save file they are
"3.11e-04". Every value is the same, outside the extra 0 in the
scientific notation. I've never seen R put two 0s in a row like that
before, and I cannot think of why that would happen. Is there a way to
change that so that it passes the tests?
That is what the Windows runtime does, so it seems you did something in
your compilation that linked to the wrong printf function. R on Windows
should use that from the (modified version of) the trio library in the
sources.
You failed to follow the posting guide: we do not even know the version
of R nor if this is 32- or 64-bit nor the locale
But as one data point, a 64-bit build of current R-patched from SVN
checked for me a couple of hours ago.
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford
1 South Parks Road, Oxford OX1 3TG, UK
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] New version of Rtools for Windows
On Wed, Jan 7, 2015 at 8:00 AM, Duncan Murdoch wrote: > > This version includes only minor updates to the tools. I indicated last > summer that I was hoping to update GCC from the current version 4.6.3 before > the R 3.2.0 release, but this now looks unlikely, unless someone else with > experience building it can help. I have been looking into this a bit over the past few months, also with mixed success. Nevertheless, below some experiences that might be worth sharing. The guys from mingw-w64 recommended (quite strongly) to move away from multilib. They explained that the standard approach is to create two separate toolchains; one that targets win32 and the other one that targets win64 (both tool chains can compiled for win32). Hence the only difference for R would be that instead of passing "-m64" and "-m32", it would need to set the path to the proper compiler. There are several initiatives that provide very complete suites of precompiled mingw-w64 tools. I think the ideal scenario would be if we could take advantage of an existing tool chain as we do on other platforms, although perhaps I do not fully understand the R-specific requirements on the windows compiler. One project that looks very promising is msys2 [1,2]. It has a package manager (port of pacman from arch linux) and comes with a pretty complete set of msys [3] and other [4] packages that seems quite well maintained. The only issue I ran into with msys2 is that it uses a different c++ exception model (seh/dwarf) than the current Rtools (which uses sjlj). See also [5]. Therefore, if a library uses exceptions, we cannot use the current Rtools to link a static library that was created with msys2 [6]. I am not sure if it also be a problem the other way around, and if this is still the case for recent versions of gcc/mingw. Finally, Ruby has build very similar to Rtools called DevKit-mingw64 [7] that we might be able to borrow from. [1] https://msys2.github.io/ [2] http://stackoverflow.com/questions/25019057/how-are-msys-msys2-and-msysgit-related-to-each-other [3] https://github.com/Alexpux/MSYS2-packages [4] https://github.com/Alexpux/MINGW-packages [5] http://stackoverflow.com/questions/15670169/what-is-difference-between-sjlj-vs-dwarf-vs-seh [6] http://stackoverflow.com/questions/7751640/undefined-reference-to-gxx-personality-sj0 [7] http://rubyinstaller.org/downloads/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] gsub with perl=TRUE results in 'this version of PCRE is not compiled with Unicode property support' in R-devel
The following code:
res <- gsub("(*UCP)\\b(i)\\b",
"", "nhgrimelanomaclass", perl = TRUE)
results in:
Error in gsub(sprintf("(*UCP)\\b(%s)\\b", "i"), "", "nhgrimelanomaclass", :
invalid regular expression '(*UCP)\b(i)\b'
In addition: Warning message:
In gsub(sprintf("(*UCP)\\b(%s)\\b", "i"), "", "nhgrimelanomaclass", :
PCRE pattern compilation error
'this version of PCRE is not compiled with Unicode property support'
at '(*UCP)\b(i)\b'
on
R Under development (unstable) (2015-01-01 r67290)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: OS X 10.9.5 (Mavericks)
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
And also on the same version of R-devel on Snow Leopard, Windows, and Linux.
But it does not produce an error on
R version 3.1.2 (2014-10-31)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Dan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] New version of Rtools for Windows
On 07/01/2015 5:20 PM, Jeroen Ooms wrote: > On Wed, Jan 7, 2015 at 8:00 AM, Duncan Murdoch > wrote: >> >> This version includes only minor updates to the tools. I indicated last >> summer that I was hoping to update GCC from the current version 4.6.3 before >> the R 3.2.0 release, but this now looks unlikely, unless someone else with >> experience building it can help. > > I have been looking into this a bit over the past few months, also > with mixed success. Nevertheless, below some experiences that might be > worth sharing. > > The guys from mingw-w64 recommended (quite strongly) to move away from > multilib. They explained that the standard approach is to create two > separate toolchains; one that targets win32 and the other one that > targets win64 (both tool chains can compiled for win32). Hence the > only difference for R would be that instead of passing "-m64" and > "-m32", it would need to set the path to the proper compiler. > > There are several initiatives that provide very complete suites of > precompiled mingw-w64 tools. I think the ideal scenario would be if we > could take advantage of an existing tool chain as we do on other > platforms, although perhaps I do not fully understand the R-specific > requirements on the windows compiler. I feel quite strongly that we need to be able to build the toolchain, rather than relying on binaries produced by others. We may need to customize the toolchain, or we may need to rebuild it when a bug is identified. Lots of binary builders abandon their builds and you can't count on them to solve problems at a later date. > > One project that looks very promising is msys2 [1,2]. It has a package > manager (port of pacman from arch linux) and comes with a pretty > complete set of msys [3] and other [4] packages that seems quite well > maintained. Do they post complete instructions for building? That's what I'm looking for. I don't want to develop a build script (I don't know how), but I would like to have one. Duncan Murdoch > > The only issue I ran into with msys2 is that it uses a different c++ > exception model (seh/dwarf) than the current Rtools (which uses sjlj). > See also [5]. Therefore, if a library uses exceptions, we cannot use > the current Rtools to link a static library that was created with > msys2 [6]. I am not sure if it also be a problem the other way > around, and if this is still the case for recent versions of > gcc/mingw. > > Finally, Ruby has build very similar to Rtools called DevKit-mingw64 > [7] that we might be able to borrow from. > > > [1] https://msys2.github.io/ > [2] > http://stackoverflow.com/questions/25019057/how-are-msys-msys2-and-msysgit-related-to-each-other > [3] https://github.com/Alexpux/MSYS2-packages > [4] https://github.com/Alexpux/MINGW-packages > [5] > http://stackoverflow.com/questions/15670169/what-is-difference-between-sjlj-vs-dwarf-vs-seh > [6] > http://stackoverflow.com/questions/7751640/undefined-reference-to-gxx-personality-sj0 > [7] http://rubyinstaller.org/downloads/ > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
