[Rd] Build R-2.3.1 on Red Hat AS release 4
Hi, I attempted to build R-2.3.1 with gcc and g77 version 3.4.4 on a cluster that runs Red Hat AS 4. The configuration step went through without any problem, * R is now configured for x86_64-unknown-linux-gnu Source directory: . Installation directory:/usr/local C compiler:gcc -g -O2 -std=gnu99 Fortran 77 compiler: g77 -g -O2 C++ compiler: g++ -g -O2 Fortran 90/95 compiler:g77 -g -O2 Interfaces supported: X11 External libraries:readline Additional capabilities: iconv, MBCS, NLS Options enabled: R profiling Recommended packages: yes But when I tried to run "make" or "make distclean", the process went into an infinite loop. Has anyone built R-2.3.1 with gcc and g77 3.4.4? If yes, can you share your experience on this? Thanks! I have successfully built R-2.2.1 on the same machine with same version of gcc and g77 few months ago. So it seems odd that R-2.3.1 build failed. Is there any change in R-2.3.1 that I should use newer version of compiler? any help is greatly appreciated! Thanks! Here are some OS and compiler info: $ cat /etc/redhat-release Red Hat Enterprise Linux AS release 4 (Nahant Update 2) $ uname -a Linux node1 2.6.9-22.ELsmp #1 SMP Mon Sep 19 18:00:54 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux $ gcc -v Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=x86_64-redhat-linux Thread model: posix $ g77 -v Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=x86_64-redhat-linux Thread model: posix gcc version 3.4.4 20050721 (Red Hat 3.4.4-2) Regards, Jennifer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] compile R with Portland Group compiler
value is passed to a nonprototyped function - argument #3 (regex.c: 5510) PGC-W-0155-Long value is passed to a nonprototyped function - argument #3 (regex.c: 5695) PGC-W-0155-Long value is passed to a nonprototyped function - argument #3 (regex.c: 6071) PGC-W-0155-Long value is passed to a nonprototyped function - argument #6 (regex.c: 6790) PGC-W-0155-Long value is passed to a nonprototyped function - argument #3 (regex.c: 7483) PGC-W-0155-Long value is passed to a nonprototyped function - argument #2 (regex.c: 7494) PGC-W-0155-Long value is passed to a nonprototyped function - argument #3 (regex.c: 7502) PGC-W-0155-Long value is passed to a nonprototyped function - argument #7 (regex.c: 10317) PGC/x86-64 Linux/x86-64 6.0-5: compilation completed with severe errors make[3]: *** [regex.o] Error 2 make[3]: Leaving directory `/home/cuser/AMD_BENCH/R-2.1.1/src/main' make[2]: *** [R] Error 2 Any help is greatly appreciated. Thanks, Jennifer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] compile R with Portland Group compiler
ot;R"
| #define PACKAGE_VERSION "2.2.0"
| #define PACKAGE_STRING "R 2.2.0"
| #define PACKAGE_BUGREPORT "[EMAIL PROTECTED]"
| #define PACKAGE "R"
| #define VERSION "2.2.0"
| #define R_PLATFORM "x86_64-unknown-linux-gnu"
| #define R_CPU "x86_64"
| #define R_VENDOR "unknown"
| #define R_OS "linux-gnu"
| #define Unix 1
| /* end confdefs.h. */
| extern "C" void std::exit (int); using std::exit;
| #include
| int
| main ()
| {
| exit (42);
| ;
| return 0;
| }
configure:5796: /usr/pgi/linux86-64/6.0/bin/pgCC -c -g
-I/usr/pgi/linux86-64/6.0/include -I/usr/pgi/linux86-64/6.0/include/CC
conftest.cc >&5
"/usr/include/stdlib.h", line 640: error: omission of exception
specification
is incompatible with previous function "exit" (declared at line 16
of "conftest.cc")
extern void exit (int __status) __THROW __attribute__ ((__noreturn__));
^
1 error detected in the compilation of "conftest.cc".
configure:5802: $? = 2
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME "R"
| #define PACKAGE_TARNAME "R"
| #define PACKAGE_VERSION "2.2.0"
| #define PACKAGE_STRING "R 2.2.0"
| #define PACKAGE_BUGREPORT "[EMAIL PROTECTED]"
| #define PACKAGE "R"
| #define VERSION "2.2.0"
| #define R_PLATFORM "x86_64-unknown-linux-gnu"
| #define R_CPU "x86_64"
| #define R_VENDOR "unknown"
| #define R_OS "linux-gnu"
| #define Unix 1
| /* end confdefs.h. */
| extern "C" void exit (int) throw ();
| #include
| int
| main ()
| {
| exit (42);
| ;
| return 0;
| }
configure:5796: /usr/pgi/linux86-64/6.0/bin/pgCC -c -g
-I/usr/pgi/linux86-64/6.0/include -I/usr/pgi/linux86-64/6.0/include/CC
conftest.cc >&5
NOTE: your evaluation license will expire in 14 days, 5.7 hours.
For a permanent license, please read the order acknowledgement
that you received. Connect to https://www.pgroup.com/License with
the username and password in the order acknowledgement.
Name:lai
User:lai
Email:[EMAIL PROTECTED]
Hostid:PGI=1AE0193111621CB217
configure:5802: $? = 0
configure:5806: test -z
|| test ! -s conftest.err
configure:5809: $? = 0
configure:5812: test -s conftest.o
configure:5815: $? = 0
configure:5841: /usr/pgi/linux86-64/6.0/bin/pgCC -c -g
-I/usr/pgi/linux86-64/6.0/include -I/usr/pgi/linux86-64/6.0/include/CC
conftest.cc >&5
NOTE: your evaluation license will expire in 14 days, 5.7 hours.
For a permanent license, please read the order acknowledgement
that you received. Connect to https://www.pgroup.com/License with
the username and password in the order acknowledgement.
Name:lai
User:lai
Email:[EMAIL PROTECTED]
Hostid:PGI=1AE0193111621CB217
configure:5847: $? = 0
configure:5851: test -z
|| test ! -s conftest.err
configure:5854: $? = 0
configure:5857: test -s conftest.o
configure:5860: $? = 0
configure:5888: checking how to run the C++ preprocessor
configure:5919: /usr/pgi/linux86-64/6.0/bin/pgCC -E
-I/usr/pgi/linux86-64/6.0/include -I/usr/pgi/linux86-64/6.0/include/CC
conftest.cc
configure:5925: $? = 0
configure:5957: /usr/pgi/linux86-64/6.0/bin/pgCC -E
-I/usr/pgi/linux86-64/6.0/include -I/usr/pgi/linux86-64/6.0/include/CC
conftest.cc
"conftest.cc", line 19: catastrophic error: could not open source file
"ac_nonexistent.h"
#include
^
1 catastrophic error detected in the compilation of "conftest.cc".
Compilation terminated.
configure:5963: $? = 2
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME "R"
| #define PACKAGE_TARNAME "R"
| #define PACKAGE_VERSION "2.2.0"
| #define PACKAGE_STRING "R 2.2.0"
| #define PACKAGE_BUGREPORT "[EMAIL PROTECTED]"
| #define PACKAGE "R"
| #define VERSION "2.2.0"
| #define R_PLATFORM "x86_64-unknown-linux-gnu"
| #define R_CPU "x86_64"
| #define R_VENDOR "unknown"
| #define R_OS "linux-gnu"
| #define Unix 1
| #ifdef __cplusplus
| extern "C" void exit (int);
| #endif
| /* end confdefs.h. */
| #include
configure:6002: result: /usr/pgi/linux86-64/6.0/bin/pgCC -E
configure:6026: /usr/pgi/linux86-64/6.0/bin/pgCC -E
-I/usr/pgi/linux86-64/6.0/include -I/usr/pgi/linux86-64/6.0/include/CC
conftest.cc
configure:6032: $? = 0
configure:6064: /usr/pgi/linux86-64/6.0/bin/pgCC -E
-I/usr/pgi/linux86-64/6.0/include -I/usr/pgi/linux86-64/6.0/include/CC
conftest.cc
"conftest.cc", line 19: catastrophic error: could not open source file
"ac_nonexistent.h"
#include
^
1 ca
Re: [Rd] compile R with Portland Group compiler
Hi, After getting some help from Portland Group, I was able to pass the initial stage of building R with Portland Group Compiler on AMD Opeteron. For anyone who is interested in building R with PG compiler, here is a list of set flags used in config.site, CC=/usr/pgi/linux86-64/6.0/bin/pgcc CFLAGS='-g -O2 -mieee-fp' CPPFLAGS='-I/usr/pgi/linux86-64/6.0/include -I/usr/pgi/linux86-64/6.0/include/CC' F77=/usr/pgi/linux86-64/6.0/bin/pgf77 FFLAGS=-O2 CPICFLAGS=-fpic FPICFLAGS=-fpic SHLIB_LDFLAGS=-shared LDFLAGS='-L/usr/pgi/linux86-64/6.0/libso -L/usr/lib64' CXX=/usr/pgi/linux86-64/6.0/bin/pgCC CXXPICFLAGS=-fpic SHLIB_CXXLDFLAGS=-shared After installing R, I went ahead to install simpleaffy package. However, came across the following errors. PGC-S-0035-Syntax error: Recovery attempted by replacing '/' by double 0.0E+0 (simpleaffy.c: 455) PGC-S-0035-Syntax error: Recovery attempted by replacing identifier by by '!=' (simpleaffy.c: 455) PGC-S-0035-Syntax error: Recovery attempted by replacing integer 15 by '!=' (simpleaffy.c: 455) PGC-S-0039-Use of undeclared variable added (simpleaffy.c: 455) PGC-S-0037-Syntax error: Recovery attempted by deleting identifier march (simpleaffy.c: 455) PGC-S-0039-Use of undeclared variable Crispin (simpleaffy.c: 455) PGC-S-0035-Syntax error: Recovery attempted by replacing identifier with by '!=' (simpleaffy.c: 455) PGC-S-0035-Syntax error: Recovery attempted by replacing identifier in by '!=' (simpleaffy.c: 455) PGC-S-0039-Use of undeclared variable deals (simpleaffy.c: 455) PGC-S-0035-Syntax error: Recovery attempted by replacing identifier largest by '!=' (simpleaffy.c: 455) PGC-S-0039-Use of undeclared variable ties (simpleaffy.c: 455) PGC-S-0035-Syntax error: Recovery attempted by replacing '...' by ',' (simpleaffy.c: 455) PGC-S-0039-Use of undeclared variable the (simpleaffy.c: 455) PGC-S-0039-Use of undeclared variable ranks (simpleaffy.c: 455) PGC/x86-64 Linux/x86-64 6.0-5: compilation completed with severe errors make: *** [simpleaffy.o] Error 2 ERROR: compilation failed for package 'simpleaffy' Apparently, PG compiler doesn't like "//" style for comments. So, by changing "//" to "/* */" style fixed above errors. The commenting style errors also happened in other packages, such as affy. Since "/* */" comment style is acceptable by both PG Compiler and gcc, it is probably worthwhile to use "/* */" consistently throughout R packages. Regards, Jennifer Prof Brian Ripley wrote: > Let us be clear: some things in config.log are designed to fail, so > only unexpected errors are a cause to look there. The regex.c > warnings are it seems from an over-zealous compiler. > > The problems here seem to be the unknown use of .lo (which it seems to > have coped with) and a problem in the PG's own libc, which it seems > cannot be used in a shared object. That issue discussed in the > R-admin manual, and seems something you do need to take up with PG. > The crucial part is > >> /usr/bin/ld: /usr/pgi/linux86-64/6.0/lib/libpgc.a(fastmath.o): >> relocation >> R_X86_64_PC32 against `__fvdlog' can not be used when making a shared >> object; >> recompile with -fPIC > > > which is asking you to recompile their static library. If you can't > use a dynamic library then this is fatal. > > > On Wed, 24 Aug 2005, Jennifer Lai wrote: > >> I downloaded R-devel and compiled it with pgcc. This time, instead of >> breaking in src/main, compilation breaks in src/modules with the >> following error messages. >> >> Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved. >> Copyright 2000-2005, STMicroelectronics, Inc. All Rights Reserved. >> /usr/pgi/linux86-64/6.0/bin/pgcc -shared >> -L/usr/pgi/linux86-64/6.0/lib -L/usr/lib64 -o R_X11.so dataentry.lo >> devX11.lo rotated.lo rbitmap.lo -lSM -lICE -L/usr/X11R6/lib64 -lX11 >> -ljpeg -lpng -lz >> File with unknown suffix passed to linker: dataentry.lo >> File with unknown suffix passed to linker: devX11.lo >> File with unknown suffix passed to linker: rotated.lo >> File with unknown suffix passed to linker: rbitmap.lo >> /usr/bin/ld: /usr/pgi/linux86-64/6.0/lib/libpgc.a(fastmath.o): >> relocation R_X86_64_PC32 against `__fvdlog' can not be used when >> making a shared object; recompile with -fPIC >> /usr/bin/ld: final link failed: Bad value >> make[4]: *** [R_X11.so] Error 2 >> make[4]: Leaving directory `/home/cuser/R-devel/src/modules/X11' >> make[3]: *** [R] Error 2 >> make[3]: Leaving directory `/home/cuser/R-devel/src/modules/X11' >> make[2]: *** [R] Error 1
[Rd] Build Portland Group Compiler
Hi, I built R with Portland Group compiler, but I noticed one thing that when I ran configure for the first time on AMD machine, I got the following error: checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. so I tried to set host=x86_64-unknown-linux-gnu, which seems to work, except what puzzles me is that there is warning messages indicating C longs are 4 bytes. *** % configure --host=x86_64-unknown-linux-gnu . . . R is now configured for x86_64-unknown-linux-gnu Source directory: . Installation directory:/usr/local/R.pgcc C compiler:/usr/pgi/linux86-64/6.0/bin/pgcc -g -O2 -mieee-fp C++ compiler: /usr/pgi/linux86-64/6.0/bin/pgCC -g Fortran compiler: /usr/pgi/linux86-64/6.0/bin/pgf77 -O2 Interfaces supported: X11 External libraries:readline Additional capabilities: PNG, JPEG, MBCS, NLS Options enabled: R profiling Recommended packages: yes configure: WARNING: assuming C ints are 4 byte on x86_64-unknown-linux-gnu configure: WARNING: assuming C longs are 4 byte on x86_64-unknown-linux-gnu configure: WARNING: you cannot build info or html versions of the R manuals Am I defining a wrong host? Thanks, Jennifer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Build Portland Group Compiler
I can't duplicate the error message. After running "configure --host=x86_64-unknow-linux-gnu" for the first time, I was able to run configure without providing --host argument. Even start with a fresh copy of R-devel didn't help me to get the original error. Is the host info been cached somewhere in R? Regards, Jennifer Peter Dalgaard wrote: >Jennifer Lai <[EMAIL PROTECTED]> writes: > > > >>Hi, >>I built R with Portland Group compiler, but I noticed one thing that >>when I ran configure for the first time on AMD machine, I got the >>following error: >> >> >>checking whether the C compiler works... configure: error: cannot run C >>compiled programs. >>If you meant to cross compile, use `--host'. >>See `config.log' for more details. >> >> >> >>so I tried to set host=x86_64-unknown-linux-gnu, which seems to work, >>except what puzzles me is that there is warning messages indicating C >>longs are 4 bytes. >> >>*** >>% configure --host=x86_64-unknown-linux-gnu >>. >>. >>. >>R is now configured for x86_64-unknown-linux-gnu >> >> Source directory: . >> Installation directory:/usr/local/R.pgcc >> >> C compiler:/usr/pgi/linux86-64/6.0/bin/pgcc -g -O2 >>-mieee-fp >> C++ compiler: /usr/pgi/linux86-64/6.0/bin/pgCC -g >> Fortran compiler: /usr/pgi/linux86-64/6.0/bin/pgf77 -O2 >> >> Interfaces supported: X11 >> External libraries:readline >> Additional capabilities: PNG, JPEG, MBCS, NLS >> Options enabled: R profiling >> >> Recommended packages: yes >> >>configure: WARNING: assuming C ints are 4 byte on x86_64-unknown-linux-gnu >>configure: WARNING: assuming C longs are 4 byte on x86_64-unknown-linux-gnu >>configure: WARNING: you cannot build info or html versions of the R manuals >> >> >>Am I defining a wrong host? >> >> > >You're not doing yourself a favour, anyway. 4-byte longs are >definitely not a good idea on Linux. What is worse, you are building a >cross-target, which means that configure is not even going to try >running any compiled programs, not that they work any better than >before. > >The thing to do is to look inside config.log and see what causes >configure to conclude that you cannot run C compiled programs. > > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Build Portland Group Compiler
Forgot to mention, here are #define long and int value in config.log from second configure run (without --host argument) | #define SIZEOF_INT 4 | #define INT_32_BITS 1 | #define SIZEOF_LONG 8 | #define SIZEOF_LONG_LONG 8 | #define SIZEOF_LONG_DOUBLE 16 Regards, Jennifer Jennifer Lai wrote: > I can't duplicate the error message. After running "configure > --host=x86_64-unknow-linux-gnu" for the first time, I was able to run > configure without providing --host argument. Even start with a fresh > copy of R-devel didn't help me to get the original error. Is the host > info been cached somewhere in R? > > Regards, > Jennifer > > Peter Dalgaard wrote: > >> Jennifer Lai <[EMAIL PROTECTED]> writes: >> >> >> >>> Hi, >>>I built R with Portland Group compiler, but I noticed one thing >>> that when I ran configure for the first time on AMD machine, I got >>> the following error: >>> >>> >>> checking whether the C compiler works... configure: error: cannot >>> run C compiled programs. >>> If you meant to cross compile, use `--host'. >>> See `config.log' for more details. >>> >>> >>> >>> so I tried to set host=x86_64-unknown-linux-gnu, which seems to >>> work, except what puzzles me is that there is warning messages >>> indicating C longs are 4 bytes. >>> >>> *** >>> % configure --host=x86_64-unknown-linux-gnu >>> . >>> . >>> . >>> R is now configured for x86_64-unknown-linux-gnu >>> >>> Source directory: . >>> Installation directory:/usr/local/R.pgcc >>> >>> C compiler:/usr/pgi/linux86-64/6.0/bin/pgcc -g -O2 >>> -mieee-fp >>> C++ compiler: /usr/pgi/linux86-64/6.0/bin/pgCC -g >>> Fortran compiler: /usr/pgi/linux86-64/6.0/bin/pgf77 -O2 >>> >>> Interfaces supported: X11 >>> External libraries:readline >>> Additional capabilities: PNG, JPEG, MBCS, NLS >>> Options enabled: R profiling >>> >>> Recommended packages: yes >>> >>> configure: WARNING: assuming C ints are 4 byte on >>> x86_64-unknown-linux-gnu >>> configure: WARNING: assuming C longs are 4 byte on >>> x86_64-unknown-linux-gnu >>> configure: WARNING: you cannot build info or html versions of the R >>> manuals >>> >>> >>> Am I defining a wrong host? >>> >> >> >> You're not doing yourself a favour, anyway. 4-byte longs are >> definitely not a good idea on Linux. What is worse, you are building a >> cross-target, which means that configure is not even going to try >> running any compiled programs, not that they work any better than >> before. >> >> The thing to do is to look inside config.log and see what causes >> configure to conclude that you cannot run C compiled programs. >> >> >> > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Build Portland Group Compiler
My silly mistake. I didn't get the error message the second time is because I have set LD_LIBRARY_PATH. If this value is unset, I would have gotten the same error message, checking for C compiler default output file name... a.out checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. Thank you for the help! Sincerely, Jennifer Peter Dalgaard wrote: >Jennifer Lai <[EMAIL PROTECTED]> writes: > > > >>I can't duplicate the error message. After running "configure >>--host=x86_64-unknow-linux-gnu" for the first time, I was able to run >>configure without providing --host argument. Even start with a fresh >>copy of R-devel didn't help me to get the original error. Is the host >>info been cached somewhere in R? >> >> > >Not that I know of... Back in the old days we had config.cache playing >tricks on people, but it shouldn't be there anymore. > >If you're not already doing so, do yourself a favour and build in a >separate directory, keeping the sources untouched. It's much easier to >clean up and start over that way. > > > >>>>Hi, >>>> I built R with Portland Group compiler, but I noticed one thing >>>>that when I ran configure for the first time on AMD machine, I got >>>>the following error: >>>> >>>> >>>>checking whether the C compiler works... configure: error: cannot >>>>run C compiled programs. >>>>If you meant to cross compile, use `--host'. >>>>See `config.log' for more details. >>>> >>>> >>>> >>>>so I tried to set host=x86_64-unknown-linux-gnu, which seems to >>>>work, except what puzzles me is that there is warning messages >>>>indicating C longs are 4 bytes. >>>> >>>>*** >>>>% configure --host=x86_64-unknown-linux-gnu >>>>. >>>>. >>>>. >>>>R is now configured for x86_64-unknown-linux-gnu >>>> >>>> Source directory: . >>>> Installation directory:/usr/local/R.pgcc >>>> >>>> C compiler:/usr/pgi/linux86-64/6.0/bin/pgcc -g >>>>-O2 -mieee-fp >>>> C++ compiler: /usr/pgi/linux86-64/6.0/bin/pgCC -g >>>> Fortran compiler: /usr/pgi/linux86-64/6.0/bin/pgf77 -O2 >>>> >>>> Interfaces supported: X11 >>>> External libraries:readline >>>> Additional capabilities: PNG, JPEG, MBCS, NLS >>>> Options enabled: R profiling >>>> >>>> Recommended packages: yes >>>> >>>>configure: WARNING: assuming C ints are 4 byte on x86_64-unknown-linux-gnu >>>>configure: WARNING: assuming C longs are 4 byte on x86_64-unknown-linux-gnu >>>>configure: WARNING: you cannot build info or html versions of the R manuals >>>> >>>> >>>>Am I defining a wrong host? >>>> >>>> >>>> >>>You're not doing yourself a favour, anyway. 4-byte longs are >>>definitely not a good idea on Linux. What is worse, you are building a >>>cross-target, which means that configure is not even going to try >>>running any compiled programs, not that they work any better than >>>before. >>> >>>The thing to do is to look inside config.log and see what causes >>>configure to conclude that you cannot run C compiled programs. >>> >>> >>> >>> >> >> >> > > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Build R with ATLAS
Hi, I followed this message, https://stat.ethz.ch/pipermail/r-devel/2004-February/028942.html, to compile ATLAS with gcc and g77 on AMD Opteron. I then followed the instructions on this message, https://stat.ethz.ch/pipermail/r-devel/2004-February/028966.html, to convert static libraries to dynamic libraries. However, when I tried to configure R-devel, I got the following error messages in config.log: configure:33172: checking for sgemm_ in -lf77blas configure:33210: /usr/pgi/linux86-64/6.0/bin/pgcc -o conftest -g -O2 -mieee-fp -I/usr/pgi/linux86-64/6.0/include -I/usr/pgi/l\ inux86-64/6.0/include/CC -L/usr/pgi/linux86-64/6.0/libso -L/usr/lib64 -L/usr/local/lib64 conftest.c -lf77blas -latlas -lpgftn\ rtl -lnspgc -lpgc -lm -ldl -lm >&5 pgcc-Warning-Unknown switch: -mieee-fp NOTE: your evaluation license will expire in 14 days, 0.426 hours. For a permanent license, please read the order acknowledgement that you received. Connect to https://www.pgroup.com/License with the username and password in the order acknowledgement. Name: lai User: lai Email: [EMAIL PROTECTED] Hostid: PGI=1AE0190CAB621CB217 /usr/local/lib64/libf77blas.so: undefined reference to `e_wsfe' /usr/local/lib64/libf77blas.so: undefined reference to `do_fio' /usr/local/lib64/libf77blas.so: undefined reference to `s_stop' /usr/local/lib64/libf77blas.so: undefined reference to `s_wsfe' My LD_LIBRARY_PATH=/usr/pgi/linux86-64/libso:/usr/local/lib64 Can anyone advise me on how to build R with ATLAS? Thanks, Jennifer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Build R with AMD pgi compiled ACML library
Hi, Has anyone had any luck in using portland group compiler to build R(-devel) with AMD's pgi compiled ACML library? I've downloaded the packages and set LD_LIBRARY_PATH, and run configuration script as follow: % ./configure --prefix=/usr/local/R.pgcc --with-blas='-lacml' However, it failed to pick up double complex BLAS, checking for sgemm_ in -lacml... yes checking whether double complex BLAS can be used... no Can anyone advise me on how to fix this problem? Thank you in advance for your help! Sincerely, Jennifer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] complex.h in R
Hi, How does complex.h used in R? Whether a compiler support complex.h or not, does it affect R's performance? I used PGI compiler to build R-devel on AMD Opteron, but the configuration file failed to link BLAS library despite the fact it is located in the usual location, /usr/lib64. PGI said they don't support complex.h. R configuration script printed out that doublecomplex is not supported. Are "supporting complex.h" and "linking BLAS library" related? any comments on this issue? note: I can ignore linking BLAS and proceed to compile R with PGI compiler successfully. Regards, Jennifer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] complex.h in R
Hi, I checked config.log and BLAS_LIBS was not set. However, I have set BLAS_LIBS='-L/usr/lib64 -lblas' in config.site file. I can't figure out why BLAS_LIBS is not set, when PGI compiler is used. When gcc is used, BLAS_LIBS need not be set in config.site and automatically get picked up by the configuration script. Here is a snapshot of the configuration script output (for buidling R with PGI compiler): checking for complex.h... yes checking for double complex... no checking for sgemm_ in -L/usr/lib64 -lblas... yes checking whether double complex BLAS can be used... no Is there other thing I should look into in the config.log? Your help is very much appreicated. Thanks, Jennifer Prof Brian Ripley wrote: >On Sat, 24 Sep 2005, Jennifer Lai wrote: > > > >>Hi, >>How does complex.h used in R? Whether a compiler support complex.h >>or not, does it affect R's performance? >> >> > >complex.h will only used in future (2.2.0-to-be) versions of R, and only >if configure finds enough C99 support. Otherwise R's own C-level complex >support is used, as it always was. One would expect the OS's support to >be faster and more accurate (but one could be disappointed, we have >found). > > > >>I used PGI compiler to build >>R-devel on AMD Opteron, but the configuration file failed to link BLAS >>library despite the fact it is located in the usual location, >>/usr/lib64. >> >> > >Look in config.log to find out why. > > > >>PGI said they don't support complex.h. R configuration >>script printed out that doublecomplex is not supported. >> >> > >That is *FORTRAN* DOUBLE COMPLEX, and that does affect the operation of R, >as without it you will not have complex linear algebra support. > > > >>Are "supporting >>complex.h" and "linking BLAS library" related? >> >> > >No. They are completely orthoogonal concepts. > > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] complex.h in R
Hi, Prof Brian Ripley wrote: > On Mon, 26 Sep 2005, Jennifer Lai wrote: > >> Hi, >> I checked config.log and BLAS_LIBS was not set. However, I have set >> BLAS_LIBS='-L/usr/lib64 -lblas' in config.site file. >> I can't figure out why BLAS_LIBS is not set, when PGI compiler is >> used. When gcc is used, BLAS_LIBS need not be set in config.site and >> automatically get picked up by the configuration script. >> >> Here is a snapshot of the configuration script output (for buidling R >> with PGI compiler): >> checking for complex.h... yes >> checking for double complex... no >> checking for sgemm_ in -L/usr/lib64 -lblas... yes >> checking whether double complex BLAS can be used... no >> >> Is there other thing I should look into in the config.log? > > > You need to look for the evidence for the line > >> checking for sgemm_ in -L/usr/lib64 -lblas... yes > > > in config.log. I very much doubt that -L/usr/lib64 helps you: surely > that should be in your library path. But you will probably find you > cannot mix code compiled under different compilers, especially as > -lblas is likely to be Fortran compiled with g77. (You may need > -lblas -lg2c, but you would be better off using the BLAS built into R.) > "-lg2c -lblas" didn't work. I am not sure if mixing code compiled under different compilers is the problem, because I built R with ACML library (PGI compiled), and config.log still shows that BLAS_LIBS is not set. Sorry for being ignorant, but where is the BLAS built into R? Is configuring R with "--without-blas" option pick up the BLAS built into R? I thought it's to build R with BLAS package. Your help is very much appreciated. Thanks, Jennifer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] FFT
Hi, Is FFT implemented in R takes advantage of multi-processors? I ran this benchmark from from http://www.sciviews.org, and AMD Opteron 2.2 GHz performs better than AMD Opteron 1.8 GHz on all test cases, except FFT operation. Both machines run same OSs (RedHat WS 3) and 2.2 GHz has more memory (2 GB RAM) than 1.8 GHz (1 GB RAM). The only difference is that 1.8 GHz is a dual-processor machine, and 2.2 GHz is a single processor machine. Could this be the reason? Does anyone has insights on this? Thanks, Jennifer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] additional comments on building R with PGI compiler
Hi, I have additional comments on building R with PGI compiler. If one wants to use external BLAS library, then pgf90 instead of pgf77 should be used, and BLAS_LIBS flags should be set. e.g. F77 = $PG_HOME/bin/pgf90 BLAS_LIBS='-L/opt/acml2.7.0/pgi64/ -lacml' # for ACML library BLAS_LIBS='-L/usr/lib64 -lg2c -lblas' # for generic BLAS library that comes with OS distribution. Regards, Jennifer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Building R on Windows
Hi, I"m a newbie on building R on Windows. I followed the instructions cited here, http://www.murdoch-sutherland.com/Rtools/ to build R-2.2.0. Everything works fine up till when package base needs to be compiled. here is the error message, -- Making package base adding build stamp to DESCRIPTION Error in library.dynam(lib, package, package.lib) : shared library 'tools' not found Execution halted make[4]: *** [frontmatter] Error 1 make[3]: *** [all] Error 2 make[2]: *** [pkg-base] Error 2 make[1]: *** [rpackage] Error 2 make: *** [all] Error 2 Has anyone seen this error message before? Where can I find shared library tools? Thanks, Jennifer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building R on Windows
Prof Brian Ripley wrote: >On Thu, 13 Oct 2005, Jennifer Lai wrote: > > > >>Hi, >> I"m a newbie on building R on Windows. I followed the instructions >>cited here, >>http://www.murdoch-sutherland.com/Rtools/ to build R-2.2.0. >>Everything works fine up till when package base needs to be compiled. >>here is the error message, >> >>-- Making package base >> adding build stamp to DESCRIPTION >>Error in library.dynam(lib, package, package.lib) : >> shared library 'tools' not found >>Execution halted >>make[4]: *** [frontmatter] Error 1 >>make[3]: *** [all] Error 2 >>make[2]: *** [pkg-base] Error 2 >>make[1]: *** [rpackage] Error 2 >>make: *** [all] Error 2 >> >>Has anyone seen this error message before? Where can I find shared >>library tools? >> >> > >It was built at the bootstrapping phase, or should have been. > > > Is there something like config.log for Windows port? I didn't see anything suspcicious that helped me in finding where shared library tools should be built. There were couple of warning messges related to dlapack, but these are not related to tools, right? In file included from dlapack0.f:0: dlapack0.f:203: warning: 'ipv' might be used uninitialized in this function dlapack0.f:203: warning: 'jpv' might be used uninitialized in this function dlapack0.f:204: warning: 'smin' might be used uninitialized in this function Many Thanks, Jennifer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building R on Windows
Prof Brian Ripley wrote: > On Thu, 13 Oct 2005, Jennifer Lai wrote: > >> Prof Brian Ripley wrote: >> >>> On Thu, 13 Oct 2005, Jennifer Lai wrote: >>> >>> >>>> Hi, >>>> I"m a newbie on building R on Windows. I followed the instructions >>>> cited here, >>>> http://www.murdoch-sutherland.com/Rtools/ to build R-2.2.0. >>>> Everything works fine up till when package base needs to be compiled. >>>> here is the error message, >>>> >>>> -- Making package base >>>> adding build stamp to DESCRIPTION >>>> Error in library.dynam(lib, package, package.lib) : >>>> shared library 'tools' not found >>>> Execution halted >>>> make[4]: *** [frontmatter] Error 1 >>>> make[3]: *** [all] Error 2 >>>> make[2]: *** [pkg-base] Error 2 >>>> make[1]: *** [rpackage] Error 2 >>>> make: *** [all] Error 2 >>>> >>>> Has anyone seen this error message before? Where can I find shared >>>> library tools? >>>> >>> >>> It was built at the bootstrapping phase, or should have been. >>> >>> >> Is there something like config.log for Windows port? > > > No. You will need to start again and show us what happens around the > boot it says it is bootstrapping. > > >> I didn't see anything suspcicious that helped me in finding where >> shared library tools should be built. >> There were couple of warning messges related to dlapack, but these >> are not related to tools, right? >> >> In file included from dlapack0.f:0: >> dlapack0.f:203: warning: 'ipv' might be used uninitialized in this >> function >> dlapack0.f:203: warning: 'jpv' might be used uninitialized in this >> function >> dlapack0.f:204: warning: 'smin' might be used uninitialized in this >> function > > > You will get many of those. > > I was able to build R for Windows successfully with a clean copy of R-2.2.0, rather than using "make clean" to remove all object files. Thanks, Jennifer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] performance of nchar
Hi,
Is nchar function knowingly slow in R? I'm doing some string
formatting that requires multiple call to nchar, and nchar seems to be
very slow.
Experiment 1, pass nchar inside sprintf, and it takes 0.7 seconds
> system.time(for (i in 1:1)
+ str = sprintf('0005%020d', nchar(op))
+ )[3]
[1] 0.7
Experiment 2, get the length of op separately using nchar, and then pass
the value to sprintf.
> len = nchar(op)
> system.time(for (i in 1:1)
+ str = sprintf('0005%020d', len)
+ )[3]
[1] 0.03
Experiment 3, time nchar for 1 iterations
> system.time(for (i in 1:1)
+ nchar(op)
+ )[3]
[1] 0.66
Is there any faster way of getting the length of string in R?
Thank you in advance for your help!
Sincerely,
Jennifer
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readLines function with R >= 3.5.0
Hi:
I have also just stumbled into this bug. Unfortunately, I can not
change the data my program receives from stdin. My code runs in a
larger system and stdin is sent to a Docker container running my R
code. The protocol is I read a line, readLines("stdin", n=1), do some
actions, send output on stdout, and wait for the next set of data. I
don't have control over this protocol, so I can't use the ^D
workaround.
I am open for other workaround suggestions. The single line is
actually JSON and can be quite large. If there isn't something else
cleaner, I am going to try readChar() in a while loop looking for \n
but I'm guessing that would likely be too slow. I am open to other
workaround solutions. For the moment I have reverted back to R 3.4.4.
Thanks for any suggestions.
Jen.
>> > Martin Maechler
>> > on Mon, 28 May 2018 10:28:01 +0200 writes:
>>
>> > Ralf Stubner
>> > on Fri, 25 May 2018 19:18:58 +0200 writes:
>>
>> >> Dear all, I would like to draw you attention to this
>> >> question on SO:
>> >>
https://stackoverflow.com/questions/50372043/readlines-function-with-new-version-of-r
>>
>>
>> >> Based on the OP's code I used the script
>>
>> >> ###
>> >> create_matrix <- function() {
>> >> cat("Write the numbers of vertices: ")
>> >> user_input <- readLines("stdin", n=1)
>> >> user_input <- as.numeric(user_input)
>> >> print(user_input)
>> >> }
>> >> create_matrix()
>> >> ###
>>
>> >> and called it with "R -f " from the command line.
>>
>> >> With 'R version 3.4.4 (2018-03-15) -- "Someone to Lean On"' the
script
>> >> prints the inputed number as expected. With both 'R version 3.5.0
>> >> (2018-04-23) -- "Joy in Playing"' and 'R Under development
(unstable)
>> >> (2018-05-19 r74746) -- "Unsuffered Consequences"' the script does
not
>> >> continue after inputing a number.
>>
>> > I can confirm.
>> > It "works" if you additionally (the [Enter], i.e., EOL) you also
>> > "send" an EOF -- in Unix alikes via -D
>>
>> > The same happens if you use 'Rscript '
>>
>> > I'm not the expert here, but am close to sure that we (R core)
>> > did not intend this change, when fixing other somewhat subtle
>> > bugs in Rscript / 'R -f'
>>
>> > Martin Maechler
>>
>> The same behavior in regular R , no need for a script etc.
>>
>> > str(readLines("stdin", n=1))
>>
>> then in addition to the input you need to "give" an EOF (Ctrl D) in R
>= 3.5.0
>>
>> Interestingly, everything works fine if you use stdin() instead
>> of "stdin" :
>>
>> > rr <- readLines(stdin(), n=1)
>> foo
>> > rr
>> [1] "foo"
>> >
>> --
>>
>> So, for now use stdin() which is much clearer than the string
>> "stdin" anyway
>>
>> Martin Maechler
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readLines function with R >= 3.5.0
Hi Michael:
I can confirm Martin's comment. I tested my software with r-devel (r74914)
and it works, while with r-patched (r74914) it does not work (it hangs, as
it did in R 3.5.0). I apologize for it taking so long for me to test this,
but is there any chance this fix could make into R 3.5.1?
Thanks.
Jen.
On Wed, Jun 13, 2018 at 6:24 AM, Michael Lawrence wrote:
> Are you sure it's not available in patched? It's definitely in the
> source since 6/1.
>
> Michael
>
>
> On Wed, Jun 13, 2018 at 2:19 AM, Martin Maechler
> wrote:
> >>>>>> Michael Lawrence
> >>>>>> on Tue, 12 Jun 2018 19:27:49 -0700 writes:
> >
> > > Hi Jen, This was already resolved for R 3.5.1 by just
> > > disabling buffering on terminal file connections like stdin.
> >
> > and before R 3.5.1 exists, *and*
> > as the change is also not yet available in R patched (!)
> > this means using a version of
> > "R-devel", e.g. for Windows available from
> >https://cloud.r-project.org/bin/windows/base/rdevel.html
> >
> > Martin
> >
> > > Sounds like you might want to be running a web service or
> > > something instead though.
> >
> > > Michael
> >
> > > On Tue, Jun 12, 2018 at 4:46 PM, Jennifer Lyon
> > > wrote:
> > >> Hi:
> > >>
> > >> I have also just stumbled into this bug. Unfortunately, I
> > >> can not change the data my program receives from
> > >> stdin. My code runs in a larger system and stdin is sent
> > >> to a Docker container running my R code. The protocol is
> > >> I read a line, readLines("stdin", n=1), do some actions,
> > >> send output on stdout, and wait for the next set of data.
> > >> I don't have control over this protocol, so I can't use
> > >> the ^D workaround.
> > >>
> > >> I am open for other workaround suggestions. The single
> > >> line is actually JSON and can be quite large. If there
> > >> isn't something else cleaner, I am going to try
> > >> readChar() in a while loop looking for \n but I'm
> > >> guessing that would likely be too slow. I am open to
> > >> other workaround solutions. For the moment I have
> > >> reverted back to R 3.4.4.
> > >>
> > >> Thanks for any suggestions.
> > >>
> > >> Jen.
> > >>
> > >>
> > >>>> >>>>> Martin Maechler >>>>> on Mon, 28 May 2018
> > >>>> 10:28:01 +0200 writes:
> > >>>>
> > >>>> >>>>> Ralf Stubner >>>>> on Fri, 25 May 2018 19:18:58
> > >>>> +0200 writes:
> > >>>>
> > >>>> >> Dear all, I would like to draw you attention to this
> > >>>> >> question on SO:
> > >>>> >>
> > >> https://stackoverflow.com/questions/50372043/readlines-
> function-with-new-version-of-r
> > >>>>
> > >>>>
> > >>>> >> Based on the OP's code I used the script
> > >>>>
> > >>>> >> ###
> > >>>> >> create_matrix <- function() { >> cat("Write the
> > >>>> numbers of vertices: ") >> user_input <-
> > >>>> readLines("stdin", n=1) >> user_input <-
> > >>>> as.numeric(user_input) >> print(user_input) >> } >>
> > >>>> create_matrix()
> > >>>> >> ###
> > >>>>
> > >>>> >> and called it with "R -f " from the
> > >>>> command line.
> > >>>>
> > >>>> >> With 'R version 3.4.4 (2018-03-15) -- "Someone to
> > >>>> Lean On"' the
> > >> script
> > >>>> >> prints the inputed number as expected. With both 'R
> > >>>> version 3.5.0 >> (2018-04-23) -- "Joy in Playing"' and
> > >>>> 'R Under development
> > >> (unstable)
> > >>>>
Re: [Rd] Bug 17432 in readLines with R >= 3.5.0 still a problem
Michael:
I don't see any comments on Bug 17432 (
https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17432) later than June
1, 2018. Would you please supply a link pointing to the followup to this
discussion on bugzilla?
Thanks.
Jen.
> On Thu Sep 13 14:14:46 CEST 2018 Michael Lawrence wrote:
>
> Thanks, I responded to this on bugzilla.
> On Wed, Sep 12, 2018 at 9:04 AM Chris Culnane
> wrote:
> >
> > Bug 17432 (https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17432)
is still a problem when using pipes for IPC.
> >
> > The bug is evident when calling R from another process and trying to
communicate via StdIn. R will buffer the input and not read lines until the
buffer is exceeded or StdIn is closed by the sending process. This prevents
interactive communication between a calling process and a child R process.
> >
> > From a quick look at the source code, it looks like the bug is caused
by only disabling buffering when isatty() returns true for a file
descriptor (connections.c). This fixes the original bug when the script is
run in a terminal, but doesn't help for pipes, which will return false for
isatty().
> >
> > An example R script and python script are provided to demonstrate the
problem:
> >
> > R script (example.r):
> >
> > f <- file("stdin")
> > open(f)
> > while(length(line <- readLines(f,n=1)) > 0) {
> > write(line, stderr())
> > }
> >
> > Python3 script:
> >
> > import sys, os, subprocess
> > process = subprocess.Popen(['Rscript', 'example.r'],
stdin=subprocess.PIPE, stdout=subprocess.PIPE)
> > for line in sys.stdin:
> > process.stdin.write((line + '\n').encode('utf-8'))
> > process.stdin.flush()
> >
> >
> > Expected Behaviour:
> > Run python script, each line entered is echoed back immediately by the
R script - which is what happens on 3.4.4
> >
> > Observed Behaviiour on >=3.5.0 (include devel):
> > The R script does not process lines as they are sent, it only receives
them when StdIn is closed.
> >
> >
> > Best Regards
> >
> > Chris
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] writing Unicode text to the Windows clipboard
Hello,
I'm interested in moving text from and to the clipboard that cannot
necessarily be represented in the native encoding. So, really, this is
about Windows.
I can successfully read from the clipboard by specifying the format that
corresponds to unicode text.
>From R >=2.7.0, it seems you should also be able to write unicode text
to the Windows clipboard.
https://github.com/wch/r-source/blob/5a156a0865362bb8381dcd69ac335f5174a4f60c/src/gnuwin32/CHANGES0#L535-L536
However, in my hands, this does not seem to be true. I can make it work
with this change:
diff --git a/src/library/utils/src/windows/util.c
b/src/library/utils/src/windows/util.c
index 373049495dd..fc3dc39e3a7 100644
--- a/src/library/utils/src/windows/util.c
+++ b/src/library/utils/src/windows/util.c
@@ -318,7 +318,7 @@ SEXP writeClipboard(SEXP text, SEXP sformat)
warning(_("unable to open the clipboard"));
GlobalFree(hglb);
} else {
- success = SetClipboardData(CF_TEXT, hglb) != 0;
+ success = SetClipboardData(format, hglb) != 0;
if(!success) {
warning(_("unable to write to the clipboard"));
GlobalFree(hglb);
Example:
"≧" is "GREATER-THAN OVER EQUAL TO", which is unicode , has
UTF-16LE bytes 67 22, and is not representable in latin1.
I copy ≧ to the Windows clipboard and attempt a round trip. I see:
x <- readClipboard(format = 13, raw = TRUE) # 13 <--> "Unicode text"
#> [1] 67 22 00 00
writeClipboard(x, format = 13L)
readClipboard(format = 13, raw = TRUE)
#> [1] 67 00 22 00 00 00 00 00
and, literally, pasting yields: g"
If I build r-devel with the patch, the same process yields
x <- readClipboard(format = 13, raw = TRUE)
#> [1] 67 22 00 00
writeClipboard(x, format = 13)
readClipboard(format = 13, raw = TRUE)
#> [1] 67 22 00 00
and pasting returns the original input: ≧
Passing the `format` to SetClipboardData() instead of hard-wiring
"CF_TEXT" brings behaviour in line with the docs.
-- Jenny
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] writing Unicode text to the Windows clipboard
Hello,
I'm interested in moving text from and to the clipboard that cannot
necessarily be represented in the native encoding. So, really, this is
about Windows.
I can successfully read from the clipboard by specifying the format that
corresponds to unicode text.
>From R >=2.7.0, it seems you should also be able to write unicode text
to the Windows clipboard.
https://github.com/wch/r-source/blob/5a156a0865362bb8381dcd69ac335f5174a4f60c/src/gnuwin32/CHANGES0#L535-L536
However, in my hands, this does not seem to be true. I can make it work
with this change:
diff --git a/src/library/utils/src/windows/util.c
b/src/library/utils/src/windows/util.c
index 373049495dd..fc3dc39e3a7 100644
--- a/src/library/utils/src/windows/util.c
+++ b/src/library/utils/src/windows/util.c
@@ -318,7 +318,7 @@ SEXP writeClipboard(SEXP text, SEXP sformat)
warning(_("unable to open the clipboard"));
GlobalFree(hglb);
} else {
- success = SetClipboardData(CF_TEXT, hglb) != 0;
+ success = SetClipboardData(format, hglb) != 0;
if(!success) {
warning(_("unable to write to the clipboard"));
GlobalFree(hglb);
Example:
"≧" is "GREATER-THAN OVER EQUAL TO", which is unicode , has
UTF-16LE bytes 67 22, and is not representable in latin1.
I copy ≧ to the Windows clipboard and attempt a round trip. I see:
x <- readClipboard(format = 13, raw = TRUE) # 13 <--> "Unicode text"
#> [1] 67 22 00 00
writeClipboard(x, format = 13L)
readClipboard(format = 13, raw = TRUE)
#> [1] 67 00 22 00 00 00 00 00
and, literally, pasting yields: g"
If I build r-devel with the patch, the same process yields
x <- readClipboard(format = 13, raw = TRUE)
#> [1] 67 22 00 00
writeClipboard(x, format = 13)
readClipboard(format = 13, raw = TRUE)
#> [1] 67 22 00 00
and pasting returns the original input: ≧
Passing the `format` to SetClipboardData() instead of hard-wiring
"CF_TEXT" brings behaviour in line with the docs.
-- Jenny
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] eliminate a partial argument match warning in R CMD check
Hello,
I'm seeing a nuisance warning when I run `R CMD check --as-cran
whatever_x.y.z.tar.gz`.
I generally work with these options set:
options(
warnPartialMatchArgs = TRUE,
warnPartialMatchAttr = TRUE,
warnPartialMatchDollar = TRUE
)
And I see this:
* checking use of SHLIB_OPENMP_*FLAGS in Makefiles ...Warning in dir("src",
patt = "[.]c$") :
partial argument match of 'patt' to 'pattern'
Warning in dir("src", patt = "[.](cc|cpp)$") :
partial argument match of 'patt' to 'pattern'
Warning in dir("src", patt = "[.]f$") :
partial argument match of 'patt' to 'pattern'
Warning in dir("src", patt = "[.]f9[05]$") :
partial argument match of 'patt' to 'pattern'
It's not a big deal but it would be nice to silence it. Patch below.
Thanks,
Jenny
diff --git a/src/library/tools/R/check.R b/src/library/tools/R/check.R
index 21d192af485..199029bda73 100644
--- a/src/library/tools/R/check.R
+++ b/src/library/tools/R/check.R
@@ -2933,10 +2933,10 @@ add_dummies <- function(dir, Log)
any <- msg <- character()
for (m in makefiles) {
lines <- readLines(m, warn = FALSE)
-have_c <- length(dir('src', patt = "[.]c$", recursive
= TRUE)) > 0L
-have_cxx <- length(dir('src', patt = "[.](cc|cpp)$",
recursive = TRUE)) > 0L
-have_f <- length(dir('src', patt = "[.]f$", recursive
= TRUE)) > 0L
-have_f9x <- length(dir('src', patt = "[.]f9[05]$",
recursive = TRUE)) > 0L
+have_c <- length(dir('src', pattern = "[.]c$",
recursive = TRUE)) > 0L
+have_cxx <- length(dir('src', pattern =
"[.](cc|cpp)$", recursive = TRUE)) > 0L
+have_f <- length(dir('src', pattern = "[.]f$",
recursive = TRUE)) > 0L
+have_f9x <- length(dir('src', pattern = "[.]f9[05]$",
recursive = TRUE)) > 0L
for (f in c("C", "CXX", "F", "FC", "CPP")) {
this <- paste0(f, "FLAGS")
this2 <- paste0("PKG_", this)
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] What is the best way to determine the version of an `.rds`?
Hi, I am writing a test that consults the serialization version of an `.rds` file. An attractive way to get this is: tools:::get_serialization_version() # reports just version which calls .Internal(serializeInfoFromConn() # reports much more but neither is truly exported for public use. Is there an official, exported way to get the serialization version? It is possible to get this information with R code yourself, but it doesn't feel very elegant. If not, could we have this? It's pretty easy these days to acquire a version 3 file, without real intent, which risks making the package require R >= 3.5. Thanks, Jenny [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] readBin should check that its endian argument is a legal value
I think it would be helpful if readBin checked that its endian argument is a legal value. Why? I was reviewing some of our code and noticed that the author had readBin(..., endian="network") and never having heard of "network", I looked at the man page for readBin, and it hadn't heard of "network" either. Not good. I then looked at the R code for readBin, which has this line: swap <- endian != .Platform$endian and swap is passed into the .Internal(readBin). Further use of Google revealed that "network" is a known endian in the universe, and our code was working by essentially a lucky chance that the data was "big" and our current machines are "little". Really not good. I don't know enough about endian stuff to know if it makes sense that "network" should be one of the choices for endian for readBin (which from the documentation currently are: "big", "little" or "swap"), but in my opinion R should have failed with the choice of "network" in our code in the current version of R. I did eventually find an aside in the R Data Import/Export document that "network" is "big" so I will patch our code to be legal. Of course some code may depend on this undocumented behavior, but I would guess that in the vast majority of cases an illegal value really is a mistake. Jen > sessionInfo() R version 3.6.1 (2019-07-05) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 18.04.3 LTS Matrix products: default BLAS: /home/mbr/r-project/R-3.6.1/lib/libRblas.so LAPACK: /home/mbr/r-project/R-3.6.1/lib/libRlapack.so locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=en_US.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_3.6.1 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readBin should check that its endian argument is a legal value
Thank you! Jen On Wed, Dec 18, 2019 at 4:12 AM Tomas Kalibera wrote: > Thank you for reporting this problem, R-devel now has a check in readBin > and writeBin. > > I've identified two CRAN packages with an incorrect value for "endian" > and reported to maintainers, unfortunately in their case the intention > was to specify "little". > > Best > Tomas > > On 11/18/19 11:22 PM, Jennifer Lyon wrote: > > I think it would be helpful if readBin checked that its endian argument > is > > a legal value. > > > > Why? I was reviewing some of our code and noticed that the author had > > readBin(..., endian="network") and never having heard of "network", I > > looked at the man page for readBin, and it hadn't heard of "network" > > either. Not good. > > > > I then looked at the R code for readBin, which has this line: > > swap <- endian != .Platform$endian > > > > and swap is passed into the .Internal(readBin). Further use of Google > > revealed that "network" is a known endian in the universe, and our code > was > > working by essentially a lucky chance that the data was "big" and our > > current machines are "little". Really not good. I don't know enough about > > endian stuff to know if it makes sense that "network" should be one of > the > > choices for endian for readBin (which from the documentation currently > are: > > "big", "little" or "swap"), but in my opinion R should have failed with > the > > choice of "network" in our code in the current version of R. I did > > eventually find an aside in the R Data Import/Export document that > > "network" is "big" so I will patch our code to be legal. Of course some > > code may depend on this undocumented behavior, but I would guess that in > > the vast majority of cases an illegal value really is a mistake. > > > > Jen > > > >> sessionInfo() > > R version 3.6.1 (2019-07-05) > > Platform: x86_64-pc-linux-gnu (64-bit) > > Running under: Ubuntu 18.04.3 LTS > > > > Matrix products: default > > BLAS: /home/mbr/r-project/R-3.6.1/lib/libRblas.so > > LAPACK: /home/mbr/r-project/R-3.6.1/lib/libRlapack.so > > > > locale: > > [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C > > [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 > > [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8 > > [7] LC_PAPER=en_US.UTF-8 LC_NAME=C > > [9] LC_ADDRESS=C LC_TELEPHONE=C > > [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C > > > > attached base packages: > > [1] stats graphics grDevices utils datasets methods base > > > > loaded via a namespace (and not attached): > > [1] compiler_3.6.1 > > > > [[alternative HTML version deleted]] > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Daily News about R-devel/NEWS is not updating
Hi: The "Daily News about R-devel/NEWS" webpage at http://developer.r-project.org/blosxom.cgi/R-devel/NEWS seems to not be updating. As of today, the latest entry is Tue, 14 Apr 2020. Thanks. Jen [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Daily News about R-devel/NEWS is not updating
Thank you! Jen On Fri, May 15, 2020 at 9:02 AM Duncan Murdoch wrote: > On 15/05/2020 10:39 a.m., Jennifer Lyon wrote: > > Hi: > > > > The "Daily News about R-devel/NEWS" webpage at > > http://developer.r-project.org/blosxom.cgi/R-devel/NEWS seems to not be > > updating. As of today, the latest entry is Tue, 14 Apr 2020. > > > > Thanks. > > > > Thanks for noticing that. It's now fixed. (The issue was that R-devel > on the news machine didn't have rJava installed; the highlighting of > differences is done by some old Java code.) > > Duncan Murdoch > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] print.POSIXct doesn't seem to use tz argument, as per its example
On the documentation page for DateTimeClasses, in the Examples section,
there are the following two lines:
format(.leap.seconds) # the leap seconds in your time zone
print(.leap.seconds, tz = "PST8PDT") # and in Seattle's
The second line (using print) seems to ignore the tz argument, and prints
the dates in my time zone, while:
format(.leap.seconds, tz = "PST8PDT")
does print the dates in PST. The code in
https://github.com/wch/r-source/blob/trunk/src/library/base/R/datetime.R
around line 234 looks like the ... argument is passed to print, not to
format.
print.POSIXct <-
print.POSIXlt <- function(x, ...)
{
max.print <- getOption("max.print", L)
if(max.print < length(x)) {
print(format(x[seq_len(max.print)], usetz = TRUE), ...)
cat(' [ reached getOption("max.print") -- omitted',
length(x) - max.print, 'entries ]\n')
} else print(if(length(x)) format(x, usetz = TRUE)
else paste(class(x)[1L], "of length 0"), ...)
invisible(x)
}
The documentation for print() on this page seems to be silent on tz as an
argument, but I do believe the example using print() does not work as
advertised.
Thanks.
Jen
sessionInfo()
R version 3.3.2 (2016-10-31)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.5 LTS
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] readLines() segfaults on large file & question on how to work around
Hi:
I have a 2.1GB JSON file. Typically I use readLines() and
jsonlite:fromJSON() to extract data from a JSON file.
When I try and read in this file using readLines() R segfaults.
I believe the two salient issues with this file are
1). Its size
2). It is a single line (no line breaks)
I can reproduce this issue as follows
#Generate a big file with no line breaks
# In R
> writeLines(paste0(c(letters, 0:9), collapse=""), "alpha.txt", sep="")
# in unix shell
cp alpha.txt file.txt
for i in {1..26}; do cat file.txt file.txt > file2.txt && mv -f file2.txt
file.txt; done
This generates a 2.3GB file with no line breaks
in R:
> moo <- readLines("file.txt")
*** caught segfault ***
address 0x7cff, cause 'memory not mapped'
Traceback:
1: readLines("file.txt")
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 3
I conclude:
I am potentially running up against a limit in R, which should give a
reasonable error, but currently just segfaults.
My question:
Most of the content of the JSON is an approximately 100K x 6K JSON
equivalent of a dataframe, and I know R can handle much bigger than this
size. I am expecting these JSON files to get even larger. My R code lives
in a bigger system, and the JSON comes in via stdin, so I have absolutely
no control over the data format. I can imagine trying to incrementally
parse the JSON so I don't bump up against the limit, but I am eager for
suggestions of simpler solutions.
Also, I apologize for the timing of this bug report, as I know folks are
working to get out the next release of R, but like so many things I have no
control over when bugs leap up.
Thanks.
Jen
> sessionInfo()
R version 3.4.1 (2017-06-30)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.5 LTS
Matrix products: default
BLAS: R-3.4.1/lib/libRblas.so
LAPACK:R-3.4.1/lib/libRlapack.so
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_3.4.1
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readLines() segfaults on large file & question on how to work around
Thank you for your suggestion. Unfortunately, while R doesn't segfault
calling readr::read_file() on the test file I described, I get the error
message:
Error in read_file_(ds, locale) : negative length vectors are not allowed
Jen
On Sat, Sep 2, 2017 at 1:38 PM, Ista Zahn wrote:
> As s work-around I suggest readr::read_file.
>
> --Ista
>
>
> On Sep 2, 2017 2:58 PM, "Jennifer Lyon" wrote:
>
>> Hi:
>>
>> I have a 2.1GB JSON file. Typically I use readLines() and
>> jsonlite:fromJSON() to extract data from a JSON file.
>>
>> When I try and read in this file using readLines() R segfaults.
>>
>> I believe the two salient issues with this file are
>> 1). Its size
>> 2). It is a single line (no line breaks)
>>
>> I can reproduce this issue as follows
>> #Generate a big file with no line breaks
>> # In R
>> > writeLines(paste0(c(letters, 0:9), collapse=""), "alpha.txt", sep="")
>>
>> # in unix shell
>> cp alpha.txt file.txt
>> for i in {1..26}; do cat file.txt file.txt > file2.txt && mv -f file2.txt
>> file.txt; done
>>
>> This generates a 2.3GB file with no line breaks
>>
>> in R:
>> > moo <- readLines("file.txt")
>>
>> *** caught segfault ***
>> address 0x7cff, cause 'memory not mapped'
>>
>> Traceback:
>> 1: readLines("file.txt")
>>
>> Possible actions:
>> 1: abort (with core dump, if enabled)
>> 2: normal R exit
>> 3: exit R without saving workspace
>> 4: exit R saving workspace
>> Selection: 3
>>
>> I conclude:
>> I am potentially running up against a limit in R, which should give a
>> reasonable error, but currently just segfaults.
>>
>> My question:
>> Most of the content of the JSON is an approximately 100K x 6K JSON
>> equivalent of a dataframe, and I know R can handle much bigger than this
>> size. I am expecting these JSON files to get even larger. My R code lives
>> in a bigger system, and the JSON comes in via stdin, so I have absolutely
>> no control over the data format. I can imagine trying to incrementally
>> parse the JSON so I don't bump up against the limit, but I am eager for
>> suggestions of simpler solutions.
>>
>> Also, I apologize for the timing of this bug report, as I know folks are
>> working to get out the next release of R, but like so many things I have
>> no
>> control over when bugs leap up.
>>
>> Thanks.
>>
>> Jen
>>
>> > sessionInfo()
>> R version 3.4.1 (2017-06-30)
>> Platform: x86_64-pc-linux-gnu (64-bit)
>> Running under: Ubuntu 14.04.5 LTS
>>
>> Matrix products: default
>> BLAS: R-3.4.1/lib/libRblas.so
>> LAPACK:R-3.4.1/lib/libRlapack.so
>>
>> locale:
>> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
>> [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
>> [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
>> [7] LC_PAPER=en_US.UTF-8 LC_NAME=C
>> [9] LC_ADDRESS=C LC_TELEPHONE=C
>> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>>
>> attached base packages:
>> [1] stats graphics grDevices utils datasets methods base
>>
>> loaded via a namespace (and not attached):
>> [1] compiler_3.4.1
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readLines() segfaults on large file & question on how to work around
Jeroen: Thank you for pointing me to ndjson, which I had not heard of and is exactly my case. My experience: jsonlite::stream_in - segfaults ndjson::stream_in - my fault, I am running Ubuntu 14.04 and it is too old so it won't compile the package corpus::read_ndjson - works!!! Of course it does a different simplification than jsonlite::fromJSON, so I have to change some code, but it works beautifully at least in simple tests. The memory-map option may be of use in the future. Another correspondent said that strings in R can only be 2^31-1 long, which is why any "solution" that tries to load the whole file into R first as a string, will fail. Thanks for suggesting a path forward for me! Jen On Sun, Sep 3, 2017 at 2:15 AM, Jeroen Ooms wrote: > On Sat, Sep 2, 2017 at 8:58 PM, Jennifer Lyon > wrote: > > I have a 2.1GB JSON file. Typically I use readLines() and > > jsonlite:fromJSON() to extract data from a JSON file. > > If your data consists of one json object per line, this is called > 'ndjson'. There are several packages specialized to read ndjon files: > > - corpus::read_ndjson > - ndjson::stream_in > - jsonlite::stream_in > > In particular the 'corpus' package handles large files really well > because it has an option to memory-map the file instead of reading all > of its data into memory. > > If the data is too large to read, you can preprocess it using > https://stedolan.github.io/jq/ to extract the fields that you need. > > You really don't need hadoop/spark/etc for this. > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] certain pipe() use cases not working in r-devel
Hello,
I've noticed a specific type of pipe() usage that works in released R, but
not in r-devel.
In 4.3.2 on macOS, I can write to a connection returned by pipe(), i.e.
"hello, world" prints here:
> R.version.string
[1] "R version 4.3.2 (2023-10-31)"
> con <- pipe("cat")
> writeLines("hello, world", con)
hello, world
But in r-devel on macOS, this is silent no-op, i.e. "hello, world" does not
print:
> R.version.string
[1] "R Under development (unstable) (2024-02-13 r85895)"
> con <- pipe("cat")
> writeLines("hello, world", con)
My colleague Lionel Henry confirms he sees the same results on linux.
This particular example with cat doesn't work on Windows, so I don't have
any useful observations for that OS.
You might say this is a weird example or use case. The actual usage where I
discovered this is the way folks read/write the clipboard on macOS using
pbcopy/pbpaste (and, in very similar ways, on linux using xsel or xclip).
This is mentioned in the "Clipboard" section of the connections help topic.
In 4.3.2 on macOS, I can successfully roundtrip with the clipboard:
> pb_write <- pipe("pbcopy")
> writeChar("hello clipboard!", pb_write, eos = NULL)
> pb_read <- pipe("pbpaste")
> readChar(pb_read, 16)
[1] "hello clipboard!"
In r-devel, it appears that the write operation silently does nothing:
> pb_write <- pipe("pbcopy")
> writeChar("hello clipboard!", pb_write, eos = NULL)
> pb_read <- pipe("pbpaste")
> readChar(pb_read, 16)
character(0)
If the clipboard is populated through other means, I can
use readChar(pipe("pbpaste"), ...) to read the clipboard even in r-devel.
So this seems to be specific to writing to the connection.
Is this change in behaviour intentional and will it be present in the next
release of R? FWIW, I did a crude search of the source of all CRAN packages
and there are quite a few currently using pipe() for clipboard access on
*nix.
-- Jenny
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] certain pipe() use cases not working in r-devel
I've now tested with:
> R.version.string
[1] "R Under development (unstable) (2024-02-16 r85931)"
and all of the previously mentioned examples now work as expected on macOS.
Thanks for the quick fix,
Jenny
On Thu, Feb 15, 2024 at 8:02 AM Tomas Kalibera
wrote:
>
> On 2/14/24 23:43, Jennifer Bryan wrote:
> > Hello,
> >
> > I've noticed a specific type of pipe() usage that works in released R,
> but
> > not in r-devel.
> >
> > In 4.3.2 on macOS, I can write to a connection returned by pipe(), i.e.
> > "hello, world" prints here:
> >
> >> R.version.string
> > [1] "R version 4.3.2 (2023-10-31)"
> >> con <- pipe("cat")
> >> writeLines("hello, world", con)
> > hello, world
> >
> > But in r-devel on macOS, this is silent no-op, i.e. "hello, world" does
> not
> > print:
> >
> >> R.version.string
> > [1] "R Under development (unstable) (2024-02-13 r85895)"
> >> con <- pipe("cat")
> >> writeLines("hello, world", con)
> > My colleague Lionel Henry confirms he sees the same results on linux.
> > This particular example with cat doesn't work on Windows, so I don't have
> > any useful observations for that OS.
> >
> > You might say this is a weird example or use case. The actual usage
> where I
> > discovered this is the way folks read/write the clipboard on macOS using
> > pbcopy/pbpaste (and, in very similar ways, on linux using xsel or xclip).
> > This is mentioned in the "Clipboard" section of the connections help
> topic.
> >
> > In 4.3.2 on macOS, I can successfully roundtrip with the clipboard:
> >
> >> pb_write <- pipe("pbcopy")
> >> writeChar("hello clipboard!", pb_write, eos = NULL)
> >> pb_read <- pipe("pbpaste")
> >> readChar(pb_read, 16)
> > [1] "hello clipboard!"
> >
> > In r-devel, it appears that the write operation silently does nothing:
> >
> >> pb_write <- pipe("pbcopy")
> >> writeChar("hello clipboard!", pb_write, eos = NULL)
> >> pb_read <- pipe("pbpaste")
> >> readChar(pb_read, 16)
> > character(0)
> >
> > If the clipboard is populated through other means, I can
> > use readChar(pipe("pbpaste"), ...) to read the clipboard even in r-devel.
> > So this seems to be specific to writing to the connection.
> >
> > Is this change in behaviour intentional and will it be present in the
> next
> > release of R? FWIW, I did a crude search of the source of all CRAN
> packages
> > and there are quite a few currently using pipe() for clipboard access on
> > *nix.
>
> This should be fixed now in R-devel. Thanks for the report and thanks to
> Ivan for the debugging. It would be great if you could test on your end
> with different examples and report any other issues.
>
> Thanks
> Tomas
>
> >
> > -- Jenny
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] typo in help page for log1p
There is a small typo in the Source section of the help page for log1p: Source: 'log1p' and 'expm1' may be taken from the operating system, but if not available there are based on the Fortran subroutine 'dlnrel' there -> they Jen > sessionInfo() R version 3.0.2 (2013-09-25) Platform: x86_64-unknown-linux-gnu (64-bit) locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=en_US.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_3.0.2 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem building R-patched on x86-64 with PGI 6.1
Prof Brian Ripley wrote: > >> As those of you who saw my post on R-help know, I've been trying to >> build >> R-patched on a dual Opteron box running Scyld Beowulf, using the PGI 6.1 >> compilers. The build went fine, but I couldn't get it to pass make >> check-all. Jennifer Lai, who reported success with PGI 6.0 previously, >> seems to have the same problem with 6.1. Here are the particulars: >> >> Since R requires IEEE754 conformance, the flag to use for PGI is -Kieee. >> (BTW, configure still insist on sticking in -mieee-fp, which generates a >> warning.) With that flag, the build runs into trouble with the first >> example in ?optim. Running it by hand gives me: > > > Well, configure insists on doing so because we were told it was correct. > (Will change.) Is -Kieee always correct for PG? > Looking at > > http://www.amd.com/us-en/assets/content_type/DownloadableAssets/dwamd_PGI_nov603.pdf > > > > suggests you might want to try -pc64 -Kieee. > Thanks, Prof. Ripley! The optim example pass the sanity check with -pc64 -Kieee flag. "make check" now fails at reg-tests-1.R Regards, Jennifer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem building R-patched on x86-64 with PGI 6.1
Jennifer Lai wrote: > Prof Brian Ripley wrote: > >> >>> As those of you who saw my post on R-help know, I've been trying to >>> build >>> R-patched on a dual Opteron box running Scyld Beowulf, using the PGI >>> 6.1 >>> compilers. The build went fine, but I couldn't get it to pass make >>> check-all. Jennifer Lai, who reported success with PGI 6.0 previously, >>> seems to have the same problem with 6.1. Here are the particulars: >>> >>> Since R requires IEEE754 conformance, the flag to use for PGI is >>> -Kieee. >>> (BTW, configure still insist on sticking in -mieee-fp, which >>> generates a >>> warning.) With that flag, the build runs into trouble with the first >>> example in ?optim. Running it by hand gives me: >> >> >> >> Well, configure insists on doing so because we were told it was correct. >> (Will change.) Is -Kieee always correct for PG? >> Looking at >> >> http://www.amd.com/us-en/assets/content_type/DownloadableAssets/dwamd_PGI_nov603.pdf >> >> >> >> suggests you might want to try -pc64 -Kieee. >> > Thanks, Prof. Ripley! The optim example pass the sanity check with > -pc64 -Kieee flag. > "make check" now fails at reg-tests-1.R > > Actually the -pc64 didn't help. I forgot that at some point my environment was configured to pick up PGI 6.0 compiler instead of PGI 6.1 (for testing purpose). The optim example compiled with PGI 6.0, but not PGI 6.1. Sorry for the confusion. - Jennifer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] build R with Visual Studio
Prof Brian Ripley wrote: > On Tue, 6 Jun 2006, Jennifer Lai wrote: > >> Hi, >>Has anyone had success in building R source with Visual Studio? I >> followed the instructions in README.packages, but failed on the very >> first step, where it's looking for R.dll. I looked through R source and >> couldn't find the file. Can someone point me to where this file is >> located or generated? Thanks! > > > R.dll is the main file generated, and the first step is to build > Rpwd.exe. > Do you really mean the R source? Yes, I would like to build the entire R source using Visual Studio instead of MinGW. Visual Studio seems the only way to build a 64-bit R currently. However, to go get there, I thought I'll try building a 32-bit version first. Regards, Jennifer > > People have built R for Windows with Visual Studio (using their own > projects/makefiles and other tools to generate .def files) but it did > not work correctly. It seems that the IEC60559 (aka IEEE754) > compliance of VC++ was not adequate -- as I recall it thought -Inf > 3. > > This isn't the list for such programming questions: R-devel would be > more appropriate. > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
