Re: [Rd] Updated Windows toolchain
For the records: This rsync infelicity has been solved in the meantime. Uwe Ligges On 19.01.2012 02:03, Dan Tenenbaum wrote: Hi Uwe, 2012/1/18 Uwe Ligges: On 18.01.2012 01:09, Dan Tenenbaum wrote: Hello, On Mon, Jan 9, 2012 at 12:28 AM, Prof Brian Ripley wrote: CRAN Windows binary packages built for R-devel are now online, and Uwe's winbuilder has gained the ability to check source packages under R-devel. Windows check results are available from http://cran.r-project.org/bin/windows/contrib/checkSummaryWin.html and in due course from the main CRAN check page. There have been a few updates to the toolchain: (i) It is now based on a beta of gcc 4.6.3, and so reports almost the same compilation warnings/errors as the CRAN check machines. Is the binary R-devel provided by CRAN built against this toolchain? If it is, should I expect "R --arch x64 CMD config CC" to report "gcc"? It still reports "x86_64-w64-mingw32-gcc" (R-devel 58077). Actually "gcc -m64" and that is also the case when I just tried yesterday's CRAN version (which is 58125). I guess you have an older version of R in your PATH? I can't seem to download the latest R-devel. When I try and download this file: http://cran.r-project.org/bin/windows/base/R-devel-win.exe and install that, it turns out to be r58077. I've tried with two different browsers and with curl, and with another CRAN mirror. I tried this on a fresh machine with no previous R installations or installer .exes lying around. The web page http://cran.r-project.org/bin/windows/base/rdevel.html says I should be downloading r58133 but that doesn't seem to be the casecan you look into this? Also, I have the latest Rtools installed (VERSION.txt reads "Rtools version 2.15.0.1911") and it is first on my PATH. I expect "gcc --version" to report 4.6.3 but it still says 4.5.0. "x86_64-w64-mingw32-gcc --version" reports 4.5.2. "which gcc" reports "/cygdrive/c/Rtools215/MinGW/bin/gcc". "which x86_64-w64-mingw32-gcc" reports "/cygdrive/c/Rtools215/MinGW64/bin/x86_64-w64-mingw32-gcc". Yes, these are the version you need for old versions of R that are included in the Rtools, but it has a third gcc in subdir gcc-4.6.3 which is the one you should have first in the path in order to use the new toolchain. Good, I did not know about this directory. I will put it first in my PATH after I am able to get a recent R-devel binary. Thanks, Dan Uwe Ligges (ii) There are various bug-fixes to the toolchain: notably x^n and exp(x) use gradual underflow to denormal numbers rather than abrubtly underflowing to zero. (iii) This is a 'multilib' toolchain: the compiler is named 'gcc.exe' for both architectures, selected by flag -m32 (the default) and -m64. Looks like to check gcc versions I should (instead of what I do above) do simply "gcc --version". I imagine that "gcc -m32 --version" would report the same thing as "gcc -m64 --version". Thanks, Dan On 29/11/2011 07:56, Prof Brian Ripley wrote: An updated toolchain is now being used for Windows' builds of R-devel: details are in the R-admin manual and at http://www.murdoch-sutherland.com/Rtools/ and http://www.stats.ox.ac.uk/pub/Rtools/ Both 32- and 64-bit parts of the toolchain use v2.0.1 of the Mingw-w64 project's runtime and a beta of gcc 4.5.4: the Mingw.org project's builds are no longer used. This should mean that code which compiles for 64-bit Windows also compiles for 32-bit Windows, and v.v. unless code makes (incorrect but common) assumptions that pointers fit into longs. A very few packages will need modifications because they contain declarations which clash with the headers in this toolchain: where we are aware of problems the maintainers have been informed. At DLL level different Windows' toolchains should be compatible: at C level they mostly are but at C++ level they are pretty much incompatible (so that for example GDAL has to be re-compiled for every toolchain: and Rcpp users need to be careful to use only one toolchain for Rcpp and their packages). All the external software previously made available (and more) is made available at http://www.stats.ox.ac.uk/pub/Rtools . The toolchain has support for OpenMP and pthreads: however OpenMP support is not enabled by default in R (it is too slow to be much use). If you do make use of it in your packages, be aware that you will need to ship the appropriate pthreads DLL(s). It is expected that there will be several further minor updates prior to the release of 2.15.0 in ca 4 months, but this step is the major one. -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailm
[Rd] Capturing interrupts during the execution of system/system2
Dear R Team
I have a question about the system/system2 command in R on linux. My goal is to
run a system command (which can take a long time) and to detect if it was
successful or not. If i understood correctly the return value of system should
give me exactly this information. However if i try to do this, system returns
0, even if i interrupt the execution with CTRL-C (which is the event i would
like to detect). Here is an example (just piping /dev/zero to /dev/null) to
illustrate the behavior after pressing CTRL-C.
> ret <- system("cat /dev/zero > /dev/null"); print(ret)
^C[1] 0
I also tried to use a tryCatch block to detect this event but pressing CTRL-C
during the execution of the system command does not result in a capture of this
interrupt event. Only releasing resources is called which happens in any case:
> tryCatch({
+ ret <- system("cat /dev/zero > /dev/null"); print(ret)
+ }, interrupt = function(ex) {
+ cat("An interrupt was detected.\n");
+ print(ex);
+ }, error = function(ex) {
+ cat("An error was detected.\n");
+ print(ex);
+ }, finally = {
+ cat("Releasing resources...");
+ cat("done\n");
+ })
^C[1] 0
Releasing resources...done
Is there still a way to find out if the user stopped the R script while the
system command was running?
R version 2.14.1 (2011-12-22)
Platform: x86_64-unknown-linux-gnu (64-bit)
Kind regards
Dimos Gaidatzis
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] RApache installation problems
Hi all I was trying to isntall RApache last week but ran into strnge problems that no one else seems to be experiencing. At least I couldn't find anything after extensive googling. First off, the machine I'm installing on looks like this: Dell Optiplex 745 32 bit 2GB RAM Fedora 15 httpd -v Server version: Apache/2.2.21 (Unix) Server built: Sep 13 2011 13:46:23 R: R-2.14.0-3.fc15.i686 perl perl-5.12.4-164.fc15.i686 What I did was the following: · Downloaded the package, rapache-1.1.15.tar.gz · Ran configure --with-apache2-apxs=/usr/sbin/apxs, make, make install. · Added this to my httpd.conf: o LoadModule R_module /usr/lib/httpd/modules/mod_R.so o o # Output R errors and warnings to the browser o ROutputErrors o o # Displays information about rapache and R o o SetHandler r-info o Also added the Directory directives but commented them when I was trying to get this to work. I figured if I couldn't see the r-info, nothing would work. Then I navigated to /RApacheInfo on the machine and got an internal server error. The log says this: [Thu Jan 19 14:37:33 2012] [error] [client 10.101.77.150] rApache Notice! No RApache Directive specified for 'SetHandler r-info' I figured that had to be coming from the R module. I tried searching for this error message but it seemed like no one has been experiencing it. After this I decided to revisit the configure script. I ran it again, this time I added the -with-R switch: ./configure --with-apache2-apxs=/usr/sbin/apxs --with-R=/usr/bin/R I examined the output and saw that there seemed to be an error but still the script ended with apparent success. [root@keilir rapache-1.1.15]# ./configure --with-apache2-apxs=/usr/sbin/apxs --with-R=/usr/bin/R checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for ar... ar checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for sys/types.h... (cached) yes checking for unistd.h... (cached) yes checking for stdlib.h... (cached) yes checking for uname... /bin/uname checking for apxs2... checking for R Program... /usr/bin/R checking for apreq2-conf
Re: [Rd] use of UTF-8 \uxxxx escape sequences in function arguments
On Thursday 19 January 2012, peter dalgaard wrote:
> On Jan 18, 2012, at 23:54 , Thomas Zumbrunn wrote:
> > plain("Zürich") ## works
> > plain("Z\u00BCrich") ## fails
> > escaped("Zürich") ## fails
> > escaped("Z\u00BCrich") ## works
>
> Using the correct UTF-8 code helps quite a bit:
>
> U+00BC¼ c2 bc VULGAR FRACTION ONE QUARTER
> U+00FCü c3 bc LATIN SMALL LETTER U WITH DIAERESIS
Thank you for pointing that out. How embarrassing - I systematically used the
wrong representations. Even worse, I didn't carefully read "Writing R
Extensions" which speaks of "Unicode as \u escapes" rather than "UTF-8 as
\u escapes", so e.g. looking up the UTF-16 byte representations would have
done the trick.
I didn't find a recommended method of replacing non-ASCII characters with
Unicode \u escape sequences and ended up using the Unix command line tool
"iconv". However, the iconv version installed on my GNU/Linux machine
(openSUSE 11.4) seems to be outdated and doesn't support the very useful "--
unicode-subst" option yet. I installed "libiconv" from
http://www.gnu.org/software/libiconv/, and now I can easily replace all non-
ASCII characters in my UTF-8 encoded R files with:
iconv -f UTF-8 -t ASCII --unicode-subst="\u%04X" my-utf-8-encoded-file.R
Thomas Zumbrunn
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] use of UTF-8 \uxxxx escape sequences in function arguments
> > I installed "libiconv" from http://www.gnu.org/software/libiconv/, and > now I can easily replace all non- ASCII characters in my UTF-8 encoded R > files with: iconv -f UTF-8 -t ASCII --unicode-subst="\u%04X" > my-utf-8-encoded-file.R Maybe it would be possible to create an R package that exposes an R interface to libiconv, in a smililar spirt as how the package XML interfaces to libxml2 and RCurl to libcurl, etc [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Updated Windows toolchain
2012/1/19 Uwe Ligges : > For the records: This rsync infelicity has been solved in the meantime. I can confirm that it works; just downloaded r58140. Thanks! Dan > > Uwe Ligges > > > On 19.01.2012 02:03, Dan Tenenbaum wrote: >> >> Hi Uwe, >> >> 2012/1/18 Uwe Ligges: >>> >>> >>> >>> On 18.01.2012 01:09, Dan Tenenbaum wrote: Hello, On Mon, Jan 9, 2012 at 12:28 AM, Prof Brian Ripley wrote: > > > CRAN Windows binary packages built for R-devel are now online, and > Uwe's > winbuilder has gained the ability to check source packages under > R-devel. > > Windows check results are available from > http://cran.r-project.org/bin/windows/contrib/checkSummaryWin.html > and in due course from the main CRAN check page. > > There have been a few updates to the toolchain: > > (i) It is now based on a beta of gcc 4.6.3, and so reports almost the > same > compilation warnings/errors as the CRAN check machines. > Is the binary R-devel provided by CRAN built against this toolchain? If it is, should I expect "R --arch x64 CMD config CC" to report "gcc"? It still reports "x86_64-w64-mingw32-gcc" (R-devel 58077). >>> >>> >>> >>> Actually "gcc -m64" and that is also the case when I just tried >>> yesterday's >>> CRAN version (which is 58125). I guess you have an older version of R in >>> your PATH? >>> >> >> >> I can't seem to download the latest R-devel. When I try and download this >> file: >> http://cran.r-project.org/bin/windows/base/R-devel-win.exe >> >> and install that, it turns out to be r58077. I've tried with two >> different browsers and with curl, and with another CRAN mirror. I >> tried this on a fresh machine with no previous R installations or >> installer .exes lying around. >> >> The web page >> http://cran.r-project.org/bin/windows/base/rdevel.html >> says I should be downloading r58133 but that doesn't seem to be the >> casecan you look into this? >> >> >>> >>> >>> Also, I have the latest Rtools installed (VERSION.txt reads "Rtools version 2.15.0.1911") and it is first on my PATH. I expect "gcc --version" to report 4.6.3 but it still says 4.5.0. "x86_64-w64-mingw32-gcc --version" reports 4.5.2. "which gcc" reports "/cygdrive/c/Rtools215/MinGW/bin/gcc". "which x86_64-w64-mingw32-gcc" reports "/cygdrive/c/Rtools215/MinGW64/bin/x86_64-w64-mingw32-gcc". >>> >>> >>> >>> >>> Yes, these are the version you need for old versions of R that are >>> included >>> in the Rtools, but it has a third gcc in subdir gcc-4.6.3 which is the >>> one >>> you should have first in the path in order to use the new toolchain. >> >> >> >> Good, I did not know about this directory. I will put it first in my >> PATH after I am able to get a recent R-devel binary. >> Thanks, >> Dan >> >> >> >> >>> >>> Uwe Ligges >>> >>> >>> >>> >>> > (ii) There are various bug-fixes to the toolchain: notably x^n and > exp(x) > use gradual underflow to denormal numbers rather than abrubtly > underflowing > to zero. > > (iii) This is a 'multilib' toolchain: the compiler is named 'gcc.exe' > for > both architectures, selected by flag -m32 (the default) and -m64. Looks like to check gcc versions I should (instead of what I do above) do simply "gcc --version". I imagine that "gcc -m32 --version" would report the same thing as "gcc -m64 --version". Thanks, Dan > > > On 29/11/2011 07:56, Prof Brian Ripley wrote: >> >> >> >> An updated toolchain is now being used for Windows' builds of R-devel: >> details are in the R-admin manual and at >> http://www.murdoch-sutherland.com/Rtools/ and >> http://www.stats.ox.ac.uk/pub/Rtools/ >> >> Both 32- and 64-bit parts of the toolchain use v2.0.1 of the Mingw-w64 >> project's runtime and a beta of gcc 4.5.4: the Mingw.org project's >> builds are no longer used. This should mean that code which compiles >> for >> 64-bit Windows also compiles for 32-bit Windows, and v.v. unless code >> makes (incorrect but common) assumptions that pointers fit into longs. >> >> A very few packages will need modifications because they contain >> declarations which clash with the headers in this toolchain: where we >> are aware of problems the maintainers have been informed. >> >> At DLL level different Windows' toolchains should be compatible: at C >> level they mostly are but at C++ level they are pretty much >> incompatible >> (so that for example GDAL has to be re-compiled for every toolchain: >> and >> Rcpp users need to be careful to use only one toolchain for Rcpp and >> their packages). All the external software previously made available >> (and more) is made available at http://www.stats.ox.ac.uk/pub/Rtools . >> >> The toolchain has support for OpenM
Re: [Rd] use of UTF-8 \uxxxx escape sequences in function arguments
On Jan 19, 2012, at 6:39 PM, Thomas Zumbrunn wrote:
> On Thursday 19 January 2012, peter dalgaard wrote:
>> On Jan 18, 2012, at 23:54 , Thomas Zumbrunn wrote:
>>> plain("Zürich") ## works
>>> plain("Z\u00BCrich") ## fails
>>> escaped("Zürich") ## fails
>>> escaped("Z\u00BCrich") ## works
>>
>> Using the correct UTF-8 code helps quite a bit:
>>
>> U+00BC ¼ c2 bc VULGAR FRACTION ONE QUARTER
>> U+00FC ü c3 bc LATIN SMALL LETTER U WITH DIAERESIS
>
> Thank you for pointing that out. How embarrassing - I systematically used the
> wrong representations. Even worse, I didn't carefully read "Writing R
> Extensions" which speaks of "Unicode as \u escapes" rather than "UTF-8 as
> \u escapes", so e.g. looking up the UTF-16 byte representations would
> have
> done the trick.
>
> I didn't find a recommended method of replacing non-ASCII characters with
> Unicode \u escape sequences and ended up using the Unix command line tool
> "iconv". However, the iconv version installed on my GNU/Linux machine
> (openSUSE 11.4) seems to be outdated and doesn't support the very useful "--
> unicode-subst" option yet. I installed "libiconv" from
> http://www.gnu.org/software/libiconv/, and now I can easily replace all non-
> ASCII characters in my UTF-8 encoded R files with:
>
> iconv -f UTF-8 -t ASCII --unicode-subst="\u%04X" my-utf-8-encoded-file.R
>
You can actually do that with R alone:
## you'll have to make sure that you're in C locale so R does the conversion
for you
Sys.setlocale(,"C")
utf8conv <- function(conn)
gsub("","u\\1",capture.output(writeLines(readLines(conn,encoding="UTF-8"
> writeLines(utf8conv("test.txt"))
M\u00F6gliche L\u00F6sung
ne nebezpe\u010Dn\u00E9
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] use of UTF-8 \uxxxx escape sequences in function arguments
On Jan 19, 2012, at 7:27 PM, Jeroen Ooms wrote: >> >> I installed "libiconv" from http://www.gnu.org/software/libiconv/, and >> now I can easily replace all non- ASCII characters in my UTF-8 encoded R >> files with: iconv -f UTF-8 -t ASCII --unicode-subst="\u%04X" >> my-utf-8-encoded-file.R > > > Maybe it would be possible to create an R package that exposes an R > interface to libiconv, in a smililar spirt as how the package XML > interfaces to libxml2 and RCurl to libcurl, etc > Well, R does that - see ?iconv ... __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] nobs() and logLik()
Dear all, I am studying a bit the various support functions that exist for extracting information from fitted model objects. >From the help files it is not completely clear to me whether the number returned by nobs() should be the same as the "nobs" attribute of the object returned by logLik(). If so, then there is a slight inconsistency in the methods for 'nls' objects with logLik.nls() taking zero weights into account while nobs.nls() does not. Admittedly, the help page of nobs() states that: For 'lm' and 'glm' fits, observations with zero weight are not included. i.e. does not comment on what nls does. But I wonder whether the following behaviour is desirable: R> DNase1 <- subset(DNase, Run == 1) R> fm3DNase2 <- nls(density ~ Asym/(1 + exp((xmid - log(conc))/scal)), + data = DNase1, weights=c(0,rep(1,14),0), + start = list(Asym = 3, xmid = 0, scal = 1)) R> nobs(fm3DNase2) [1] 16 > logLik(fm3DNase2) 'log Lik.' 42.62777 (df=4) > nobs(logLik(fm3DNase2)) [1] 14 Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] nobs() and logLik()
I do wonder why people use zero weights rather than 'subset', and I don't particularly like the discontinuity as a weight goes to zero. But this came up for glm() and it would be better to be consistent, so thanks for pointing out the nls() cases. We'll alter them. On 20/01/2012 05:30, Berwin A Turlach wrote: Dear all, I am studying a bit the various support functions that exist for extracting information from fitted model objects. From the help files it is not completely clear to me whether the number returned by nobs() should be the same as the "nobs" attribute of the object returned by logLik(). If so, then there is a slight inconsistency in the methods for 'nls' objects with logLik.nls() taking zero weights into account while nobs.nls() does not. Admittedly, the help page of nobs() states that: For 'lm' and 'glm' fits, observations with zero weight are not included. i.e. does not comment on what nls does. But I wonder whether the following behaviour is desirable: R> DNase1<- subset(DNase, Run == 1) R> fm3DNase2<- nls(density ~ Asym/(1 + exp((xmid - log(conc))/scal)), + data = DNase1, weights=c(0,rep(1,14),0), + start = list(Asym = 3, xmid = 0, scal = 1)) R> nobs(fm3DNase2) [1] 16 logLik(fm3DNase2) 'log Lik.' 42.62777 (df=4) nobs(logLik(fm3DNase2)) [1] 14 Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] nobs() and logLik()
G'day Brian, On Fri, 20 Jan 2012 06:20:30 + Prof Brian Ripley wrote: > I do wonder why people use zero weights rather than 'subset', and I > don't particularly like the discontinuity as a weight goes to zero. I completely agree, and for developers it is a bit of a pain to make sure that all possible combinations of 'subset' and 'weights' play "nicely" together. One reason that I can see for people to use zero weights rather than 'subset' is that fitted() and predict() in the former case readily produce fitted values for the observations that received a zero weight. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
