[Rd] Problem with types on 64-bit
Hi Everyone,
I have a problem using some working 32-bit R code with 64-bit machine ( I am
using version R-2.4.1 ). The problem occurs when I am trying to detect a NULL
STRSXP type. ( Perhaps I am doing this detection in the wrong way? )
On 32-bit the following works, and correctly identifies if I am passing NULL
or a valid string object:
if ( v_dta_start != R_NilValue && STRING_ELT( v_dta_start, 0 ) != R_NilValue )
{
dta.start = CHAR( STRING_ELT( v_dta_start, 0 ) );
}
Yet on a 64-bit machine I get the following errors:
(1) when I pass NULL it goes into the if clause and then when it tries to set
dta.start it displays:
CHAR() can only be applied to a 'CHARSXP', not a 'NULL'
(2) if I pass a valid string such as "hello", I get the following:
CHAR() can only be applied to a 'CHARSXP', not a 'character'
I have tried converting using AS_CHARACTER but that just brings up the same
messages. I have also seen S4 and PROMSXP types come up in these error
messages.
What I don't understand is why this happens - any ideas?
If I can supply any more info let me know, below is the CPU information for
the 64-bit machine.
Many thanks for your help
Tom
64-BIT CPU INFO
===
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 5
model name : AMD Opteron(tm) Processor 144
stepping: 10
cpu MHz : 1794.932
cache size : 1024 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat
pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow
bogomips: 3597.08
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Cross-compilation
More information for you. In order to test some ideas I had I first attempted to compile the gafit package which is just a single file - this compiled fine (this is a C package). I then added the iostream library to it as so: #include and altered the extension from c to cpp so it would compile as a C++ program and I get the following: * START OUTPUT * export PATH=/my/path/RCrossBuild/cross-tools/bin:/my/path/RCrossBuild/cross-tools/mingw32/bin:/usr/local/pgsql/bin:/home/tmccallum/sbin:/usr/java/jdk1.5.0_06/bin:/usr/java/jdk1.5.0_06/jre/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/tmccallum/bin; \ export mypkg=`echo gafittest | cut -d'_' -f1,1`; \ export mypkg_v=gafittest; \ cd /my/path/RCrossBuild/pkgsrc; \ rm -rf $mypkg; \ tar zxf gafittest.tar.gz; \ echo ---$mypkg--; \ cd /my/path/RCrossBuild/WinR/R-2.4.0/src/gnuwin32/; \ make PKGDIR=/my/path/RCrossBuild/pkgsrc RLIB=/my/path/RCrossBuild/WinRlibs STAMP=no pkg-$mypkg; \ mkdir -p /my/path/RCrossBuild/WinRlibs; \ cd /my/path/RCrossBuild/WinRlibs; \ rm -rf $mypkg_v.zip; \ zip -rl $mypkg_v.zip $mypkg -x \*.so \*.dll \*.RData \*.rda \*.gz \*.zip \*.rds \*.pdf \*.ps;\ zip -r9 $mypkg_v.zip $mypkg -i \*.so \*.dll \*.RData \*.rda \*.gz \*.zip \*.rds \*.pdf \*.ps;\ rm -rf $mypkg_v --- gafittest-- make[1]: Entering directory `/my/path/RCrossBuild/WinR/R-2.4.0/src/gnuwin32' -- Making package gafittest adding build stamp to DESCRIPTION making DLL ... making gafit.d from gafit.cpp In file included from /my/path/RCrossBuild/cross-tools/bin/../lib/gcc/i586-mingw32/3.4.5/../../../../include/c++/3.4.5/bits/locale_facets.h:1533, from /my/path/RCrossBuild/cross-tools/bin/../lib/gcc/i586-mingw32/3.4.5/../../../../include/c++/3.4.5/bits/basic_ios.h:44, from /my/path/RCrossBuild/cross-tools/bin/../lib/gcc/i586-mingw32/3.4.5/../../../../include/c++/3.4.5/ios:51, from /my/path/RCrossBuild/cross-tools/bin/../lib/gcc/i586-mingw32/3.4.5/../../../../include/c++/3.4.5/ostream:45, from /my/path/RCrossBuild/cross-tools/bin/../lib/gcc/i586-mingw32/3.4.5/../../../../include/c++/3.4.5/iostream:45, from gafit.cpp:22: /my/path/RCrossBuild/cross-tools/bin/../lib/gcc/i586-mingw32/3.4.5/../../../../include/c++/3.4.5/bits/codecvt.h:219:45: macro "length" passed 4 arguments, but takes just 1 make[4]: *** [gafit.d] Error 1 make[3]: *** [srcDynlib] Error 2 make[2]: *** [all] Error 2 make[1]: *** [pkg-gafittest] Error 2 make[1]: Leaving directory `/my/path/RCrossBuild/WinR/R-2.4.0/src/gnuwin32' adding: gafittest/ (stored 0%) adding: gafittest/DESCRIPTION (deflated 41%) adding: gafittest/Meta/ (stored 0%) adding: gafittest/COPYING (deflated 62%) adding: gafittest/Meta/package.rds (deflated 54%) * END OUTPUT * I have checked the search paths and it is using the includes in gcc 3.4.5 that come with mingW32 as the docs say it should. Line 22 of gafit that it points to is where I include iostream (have tried both and "iostream" to see if it made any difference). So I think that the g++ version of mingW32 may be the problem. Any suggestions, Tom "Tom McCallum" <[EMAIL PROTECTED]> wrote: > Thanks for your reply, as an example it appears to have difficulty linking > to even ostream library of the standard C++, as shown below: > > /home/tmccallum/ritzel/RItzel/src/Classifier.cpp:209: undefined reference > to `_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc' > Classifier.o: In function `operator<<': > /usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/ostream:218: > > undefined reference to `_ZNSolsEd' > /usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/ostream:196: > > undefined reference to `_ZNSolsEl' > > I am currently working R-2.4.0 as downloaded today. > > I know the g++ has gone through some alterations and wondered if you knew > the version of g++ you cross-compiled your package with for comparison - > mine is g++ (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8). > > Many thanks > > Tom > > > On Wed, 25 Oct 2006 18:10:40 +0100, Ramon Diaz-Uriarte <[EMAIL PROTECTED]> > wrote: > > > Dear Tom, > > > > It has worked for me out-of-the box in at least two times, one a while > > ago > > with R-2.2-something and recently with R-2.4.0. In both cases, I was > > running > > Debian (with a mix of testing and unstable) on x86. I never had to do > > anything, just run the script and at least in one case I did > > crosscompile a > > package with C++. > > > > > > R. > > > > O
Re: [Rd] Cross-compilation
False alarm, those errors were due to the old iostream R.h ordering required - so not a lead after all. Tom [EMAIL PROTECTED] wrote: > More information for you. > > In order to test some ideas I had I first attempted to compile the gafit > package which is just a single file - this compiled fine (this is a C > package). > > I then added the iostream library to it as so: > > #include > > and altered the extension from c to cpp so it would compile as a C++ program > and I get the following: > > * >START OUTPUT > * > export > PATH=/my/path/RCrossBuild/cross-tools/bin:/my/path/RCrossBuild/cross-tools/mingw32/bin:/usr/local/pgsql/bin:/home/tmccallum/sbin:/usr/java/jdk1.5.0_06/bin:/usr/java/jdk1.5.0_06/jre/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/tmccallum/bin; > \ > export mypkg=`echo gafittest | cut -d'_' -f1,1`; \ > export mypkg_v=gafittest; \ > cd /my/path/RCrossBuild/pkgsrc; \ > rm -rf $mypkg; \ > tar zxf gafittest.tar.gz; \ > echo ---$mypkg--; \ > cd /my/path/RCrossBuild/WinR/R-2.4.0/src/gnuwin32/; \ > make PKGDIR=/my/path/RCrossBuild/pkgsrc RLIB=/my/path/RCrossBuild/WinRlibs > STAMP=no pkg-$mypkg; \ > mkdir -p /my/path/RCrossBuild/WinRlibs; \ > cd /my/path/RCrossBuild/WinRlibs; \ > rm -rf $mypkg_v.zip; \ > zip -rl $mypkg_v.zip $mypkg -x \*.so \*.dll \*.RData \*.rda \*.gz \*.zip > \*.rds \*.pdf \*.ps;\ > zip -r9 $mypkg_v.zip $mypkg -i \*.so \*.dll \*.RData \*.rda \*.gz \*.zip > \*.rds \*.pdf \*.ps;\ > rm -rf $mypkg_v > --- gafittest-- > make[1]: Entering directory `/my/path/RCrossBuild/WinR/R-2.4.0/src/gnuwin32' > > -- Making package gafittest > adding build stamp to DESCRIPTION > making DLL ... > making gafit.d from gafit.cpp > In file included from > /my/path/RCrossBuild/cross-tools/bin/../lib/gcc/i586-mingw32/3.4.5/../../../../include/c++/3.4.5/bits/locale_facets.h:1533, > from > /my/path/RCrossBuild/cross-tools/bin/../lib/gcc/i586-mingw32/3.4.5/../../../../include/c++/3.4.5/bits/basic_ios.h:44, > from > /my/path/RCrossBuild/cross-tools/bin/../lib/gcc/i586-mingw32/3.4.5/../../../../include/c++/3.4.5/ios:51, > from > /my/path/RCrossBuild/cross-tools/bin/../lib/gcc/i586-mingw32/3.4.5/../../../../include/c++/3.4.5/ostream:45, > from > /my/path/RCrossBuild/cross-tools/bin/../lib/gcc/i586-mingw32/3.4.5/../../../../include/c++/3.4.5/iostream:45, > from gafit.cpp:22: > /my/path/RCrossBuild/cross-tools/bin/../lib/gcc/i586-mingw32/3.4.5/../../../../include/c++/3.4.5/bits/codecvt.h:219:45: > macro "length" passed 4 arguments, but takes just 1 > make[4]: *** [gafit.d] Error 1 > make[3]: *** [srcDynlib] Error 2 > make[2]: *** [all] Error 2 > make[1]: *** [pkg-gafittest] Error 2 > make[1]: Leaving directory `/my/path/RCrossBuild/WinR/R-2.4.0/src/gnuwin32' > adding: gafittest/ (stored 0%) > adding: gafittest/DESCRIPTION (deflated 41%) > adding: gafittest/Meta/ (stored 0%) > adding: gafittest/COPYING (deflated 62%) > adding: gafittest/Meta/package.rds (deflated 54%) > > * >END OUTPUT > * > > I have checked the search paths and it is using the includes in gcc 3.4.5 that > come with mingW32 as the docs say it should. Line 22 of gafit that it points > to is where I include iostream (have tried both and "iostream" to > see if it made any difference). So I think that the g++ version of mingW32 > may be the problem. > > Any suggestions, > > Tom > > > > > > "Tom McCallum" <[EMAIL PROTECTED]> wrote: > > > Thanks for your reply, as an example it appears to have difficulty linking > > to even ostream library of the standard C++, as shown below: > > > > /home/tmccallum/ritzel/RItzel/src/Classifier.cpp:209: undefined reference > > to `_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc' > > Classifier.o: In function `operator<<': > > > /usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/ostream:218: > > > > undefined reference to `_ZNSolsEd' > > > /usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/ostream:196: > > > > undefined reference to `_ZNSolsEl' > > > > I am currently working R-2.4.0 as downloaded today. > > > > I know the g++ has gone through some alterations and wondered if you knew > > the version of g++ you cross-compiled your package with for comparison - > > mine is g++ (
[Rd] Windows 2000 crash while using rbind (PR#8225)
Windows 2000 reports that "Rgui.exe has generated errors and will be =
closed by Windows. You will need to restart the program." when using =
rbind.=20
df1 <- data.frame(cbind(x=3D1, y=3D1:1000), fac=3Dsample(LETTERS[1:3], =
1000, repl=3DTRUE))
df2 <- data.frame(cbind(x=3D1, y=3D1:10), fac=3Dsample(LETTERS[4:6], =
10, repl=3DTRUE))
df3 <- data.frame(cbind(x=3D1, y=3D1:100), =
fac=3Dsample(LETTERS[1:3], 100, repl=3DTRUE))
df4 <- rbind(df1,df2)
df5 <- rbind(df2,df3)
=20
=20
Since this only happens intermittantly and appears to be related to the =
size of the objects I ran the following code.
sink("rbind test.txt")
df1 <- data.frame(cbind(x=3D1, y=3D1:10), fac=3Dsample(LETTERS[4:6], 10, =
repl=3DTRUE))
for (j in seq(10,100,1)){
df2 <- data.frame(cbind(x=3D1, y=3D1:j), fac=3Dsample(LETTERS[1:3], j, =
repl=3DTRUE))
print(j)
df3 <- rbind(df2,df1)
}
sink()
the output of rbind test.txt is
[1] 10
[1] 11
[1] 12
...
[1] 51
[1] 52
I then ran=20
sink("rbind test 2.txt")
df1 <- data.frame(cbind(a =3D 1, b =3D 2, c =3D 3, d =3D 4, e =3D 5, f =
=3D 6, x=3D1, y=3D1:10), fac=3Dsample(LETTERS[4:6], 10, repl=3DTRUE))
for (j in seq(10,100,1)){
df2 <- data.frame(cbind(a =3D 1, b =3D 2, c =3D 3, d =3D 4, e =3D 5, f =
=3D 6, x=3D1, y=3D1:j), fac=3Dsample(LETTERS[1:3], j, repl=3DTRUE))
print(j)
df3 <- rbind(df2,df1)
}
sink()
which also stopped at 52.
I tried to narrow down where the crash takes place but it would appear =
that it is a moving feast, however both pieces of code always stopped =
with the same number, somewhere around 52.
> version
_ =20
platform i386-pc-mingw32
arch i386 =20
os mingw32 =20
system i386, mingw32 =20
status =20
major2 =20
minor2.0 =20
year 2005 =20
month10=20
day 06=20
svn rev 35749 =20
language R=20
One of the examples that has failed for me looks like
pop <- rbind(om.tp[,c(6,2,4,5,3)],eas[,c(2,1,3,4,5)])
> str(om.tp[,c(6,2,4,5,3)])
`data.frame': 1001384 obs. of 5 variables:
$ age5 : Factor w/ 18 levels "0 to 4","5 to 9",..: 1 1 1 1 1 2 2 2 2 2 =
...
$ sex : Factor w/ 2 levels "Females","Males": 1 1 1 1 1 1 1 1 1 1 ...
$ lga : Factor w/ 142 levels "Albany (C)","Armadale (C)",..: 21 21 21 =
21 21 21 21 21 21 21 ...
$ count: num 7.33 7.45 7.05 6.31 5.71 ...
$ year : Factor w/ 41 levels "2001","2002",..: 1 1 1 1 1 1 1 1 1 1 ...
> str(eas[,c(2,1,3,4,5)])
`data.frame': 25342 obs. of 5 variables:
$ age5 : Factor w/ 18 levels "0 to 4","5 to 9",..: 1 1 1 1 1 1 1 1 1 1 =
...
$ sex : Factor w/ 2 levels "Females","Males": 2 2 2 2 2 2 2 2 2 2 ...
$ lga : Factor w/ 142 levels "Albany (C)","Armadale (C)",..: 1 2 3 4 5 =
6 7 8 9 10 ...
$ count: num 1107 2163 532 294 479 ...
$ year : Factor w/ 5 levels "1991","1996",..: 1 1 1 1 1 1 1 1 1 1 ...
> gc()
used (Mb) gc trigger (Mb) max used (Mb)
Ncells 3255820 87.06193578 165.4 5266303 140.7
Vcells 22096825 168.6 32770865 250.1 32114295 245.1
Tom Mulholland
Senior Demographer
Spatial Information and Research
State and Regional Policy
Department for Planning and Infrastructure
Perth, Western Australia
+61 (08) 9264 7936
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] javascript device for R
Romain Francois free.fr> writes: > > Hi, > > Has anyone started a javascript device for R. > I don't see something like that googling or at on > http://www.stat.auckland.ac.nz/~paul/R/devices.html > For example, using that graphics library : > http://www.walterzorn.com/jsgraphics/jsgraphics_e.htm > (I cc that message to the author.) > > ps : this is not a feature request, i will do it. But if someone has > started that, let me know. > > Romain > Not that I know of, but here are some pointers that might get you started. Here's an example of a graph in SVG done in the Dojo javascript toolkit: http://archive.dojotoolkit.org/nightly/tests/widget/test_Chart.html The idea is that it generates SVG for SVG-capable browsers and VML for Internet Explorer (although I don't think they finished the IE part yet). Another option is to use the canvas tag available in Firefox and Safari. You can use this to emulate the canvas tag in IE: http://me.eae.net/archive/2005/12/29/canvas-in-ie/ - Tom __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Build failure on powerpc64
Hi R folks, Went to build R 3.6.2 for Fedora/EPEL and got failures across the board. Disabling the test suite for all non-intel architectures resolves most of the failures, but powerpc64 dies in the compiler, specifically here: gcc -m64 -I../../src/extra/xdr -I. -I../../src/include -I../../src/include -I/usr/local/include -I../../src/nmath -DHAVE_CONFIG_H -fopenmp -fPIC -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mcpu=power8 -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection -c arithmetic.c -o arithmetic.o arithmetic.c:180:26: error: initializer element is not constant 180 | static LDOUBLE q_1_eps = (1 / LDBL_EPSILON); | ^ make[3]: *** [../../Makeconf:124: arithmetic.o] Error 1 Took me a bit to figure out why, but this is happening because on powerpc64, gcc is compiled with -mlong-double-128, and the long double format used on PPC is IBM's 128bit long double which is two doubles added together. As a result, gcc can't safely do const assignments to long doubles on ppc64, so it dies there. The fix is easy enough, do not try to assign a value to a static long double on ppc64. --- ./src/main/arithmetic.c.orig2019-12-12 18:30:12.416334062 + +++ ./src/main/arithmetic.c 2019-12-12 18:30:44.966334062 + @@ -179,7 +179,10 @@ void attribute_hidden InitArithmetic() #endif } -#if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE) +/* PowerPC 64 (when gcc has -mlong-double-128) breaks here because + * of issues constant folding 128bit IBM long doubles. + */ +#if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE) && !__PPC64__ static LDOUBLE q_1_eps = 1 / LDBL_EPSILON; #else static double q_1_eps = 1 / DBL_EPSILON; Hope that helps someone else. Tom [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Build failure on powerpc64
An excellent question. It is important to remember two key facts:
1. With gcc on ppc64, long doubles exist, they can be used, just not safely
as constants (and maybe they still can be used safely under specific
conditions?).
2. I am not an expert in either PowerPC64 or gcc. :)
Looking at connections.c, we have (in order):
* handling long double as a valid case in a switch statement checking size
* adding long double as a field in the u union define
* handling long double as a valid case in a switch statement checking size
* handling long double as a valid case in a switch statement checking size
* memcpy from the address of a long double
In format.c, we have (in order):
* conditionally creating private_nearbyintl for R_nearbyintl
* defining a static const long double tbl[]
* use exact scaling factor in long double precision
For most of these, it seems safe to leave them as is for ppc64. I would
have thought that the gcc compiler might have had issue with:
connections.c:
static long double ld1;
for (i = 0, j = 0; i < len; i++, j += size) {
ld1 = (long double) REAL(object)[i];
format.c:
static const long double tbl[] =
... but it doesn't. Perhaps the original code at issue:
arithmetic.c:
static LDOUBLE q_1_eps = 1 / LDBL_EPSILON;
only makes gcc unhappy because of the very large value trying to be stored
in the static long double, which would make it span the "folded double" on
that architecture.
*
It seems that the options are:
A) Patch the one place where the compiler determines it is not safe to use
a static long double on ppc64.
B) Treat PPC64 as a platform where it is never safe to use a static long
double
FWIW, I did run the test suite after applying my patch and all of the tests
pass on ppc64.
Tom
On Fri, Dec 13, 2019 at 5:44 AM Martin Maechler
wrote:
> >>>>> Tom Callaway
> >>>>> on Thu, 12 Dec 2019 14:21:10 -0500 writes:
>
> > Hi R folks,
>
> > Went to build R 3.6.2 for Fedora/EPEL and got failures across the
> board.
>
> > Disabling the test suite for all non-intel architectures resolves
> most of
> > the failures, but powerpc64 dies in the compiler, specifically here:
>
> > gcc -m64 -I../../src/extra/xdr -I. -I../../src/include
> -I../../src/include
> > -I/usr/local/include -I../../src/nmath -DHAVE_CONFIG_H -fopenmp
> -fPIC
> > -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> > -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
> > -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mcpu=power8
> > -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection
> -c
> > arithmetic.c -o arithmetic.o
> > arithmetic.c:180:26: error: initializer element is not constant
> > 180 | static LDOUBLE q_1_eps = (1 / LDBL_EPSILON);
> > | ^
> > make[3]: *** [../../Makeconf:124: arithmetic.o] Error 1
>
> > Took me a bit to figure out why, but this is happening because on
> > powerpc64, gcc is compiled with -mlong-double-128, and the long
> double
> > format used on PPC is IBM's 128bit long double which is two doubles
> added
> > together. As a result, gcc can't safely do const assignments to long
> > doubles on ppc64, so it dies there.
>
> > The fix is easy enough, do not try to assign a value to a static long
> > double on ppc64.
> > --- ./src/main/arithmetic.c.orig2019-12-12
> 18:30:12.416334062 +
> > +++ ./src/main/arithmetic.c 2019-12-12 18:30:44.966334062 +
> > @@ -179,7 +179,10 @@ void attribute_hidden InitArithmetic()
> > #endif
> > }
>
> > -#if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE)
> > +/* PowerPC 64 (when gcc has -mlong-double-128) breaks here because
> > + * of issues constant folding 128bit IBM long doubles.
> > + */
> > +#if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE) &&
> !__PPC64__
> > static LDOUBLE q_1_eps = 1 / LDBL_EPSILON;
> > #else
> > static double q_1_eps = 1 / DBL_EPSILON;
>
>
> > Hope that helps someone else.
> > Tom
>
> Thank you, Tom. That is "interesting" ...
>
> The piece in question had been added by me,
>
> r77193 | maechler | 2019-09-18 13:21:49 +0200 (Wed, 18 Sep 2019) | 1 line
>
> x %% +/- Inf now typically return non-NaN; fix the "FIXME" in C
> --
Re: [Rd] Build failure on powerpc64
No, that does not change the issue: arithmetic.c:180:26: error: initializer element is not constant 180 | static LDOUBLE q_1_eps = 1.L / LDBL_EPSILON; Tom On Fri, Dec 13, 2019 at 11:56 AM Serguei Sokol wrote: > Le 13/12/2019 à 17:06, Tom Callaway a écrit : > > arithmetic.c: > > static LDOUBLE q_1_eps = 1 / LDBL_EPSILON; > Just a thought: can it be that it's "1" which is at the origin of > compiler complaint? > In this case, would the syntax "1.L" be sufficient to keep it calm? > > Serguei. > > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Providing R binaries compiled against a multithreaded BLAS like Intel MKL by default?
threads equal to the nr of physical cores... I was wondering if any of you would have any thoughts about which of these two methods would be most recommended? After restarting RStudio we can check that it works, e.g. using a small SVD benchmark on my Intel Core i7-4700HQ 2.4GHz 4 core/8 thread laptop: getMKLthreads() 4 # Singular Value Decomposition m <- 1 n <- 2000 A <- matrix (runif (m*n),m,n) system.time (S <- svd (A,nu=0,nv=0)) user system elapsed 15.200.644.17 > sessionInfo() R version 3.6.2 (2019-12-12) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 10 x64 (build 18362) Matrix products: default locale: [1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252 LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] RevoUtils_11.0.3 RevoUtilsMath_11.0.0 loaded via a namespace (and not attached): [1] compiler_3.6.2 tools_3.6.2 That same benchmark without Intel MKL installed ran at user system elapsed 35.110.10 35.21 Unfortunately calling the RevoUtilsMath::setMKLthreads() function crashes RStudio (this was already the case in MRO 3.5.3 as well though), but it does work OK when called from the R console. If any of you would happen to know of a better non-crashing alternative, please let me know! In general I think it would be really handy if R binaries, compiled against some optimized BLAS like Intel MKL or OpenBlas would be readily available on all systems, including Windows, as this partly determines how one would develop packages (e.g. veering towards the use of RcppEigen, which uses multithreaded matrix algebra on all systems independently of the BLAS one has installed, or RcppArmadillo, which uses whatever BLAS one has compiled R against, but which is only a good option then if R versions with multithreaded BLAS are readily available on all systems). Or even, if it could be made possible to switch the type of BLAS used also on Windows, as is possible on Ubuntu... Any thoughts most welcome! cheers & happy holidays, Tom Prof. Tom Wenseleers Laboratory of Socioecology and Social Evolution Dept. of Biology University of Leuven Naamsestraat 59 3000 Leuven Belgium https://bio.kuleuven.be/ento/wenseleers/twenseleers.htm [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Build failure on powerpc64
This change seems correct, but as we don't have any non-PPC64 systems or
build targets in the Fedora buildsystem, it won't affect Fedora if it
doesn't make it.
Tom
On Wed, Mar 25, 2020, 6:16 AM peter dalgaard wrote:
> Do note that 3.6-patched will only be live for a day or two as we branch
> for 4.0.0 on Friday. Anything committed there is unlikely to make it into
> an official release (in principle, the 3.6 branch can be revived but it
> would take a very strong incentive to do so.)
>
> If you want an R-3.6.3-for-ppc, I think a vendor patch is the way. AFAIR
> (it's been more than a decade since I looked at this stuff) the RPM spec
> files make it fairly easy to apply changes to the sources before building.
>
> -pd
>
> > On 25 Mar 2020, at 10:00 , Martin Maechler
> wrote:
> >
> >>>>>> Martin Maechler
> >>>>>>on Tue, 17 Dec 2019 11:25:31 +0100 writes:
> >
> >>>>>> Tom Callaway
> >>>>>>on Fri, 13 Dec 2019 11:06:25 -0500 writes:
> >
> >>> An excellent question. It is important to remember two key
> >>> facts:
> >
> >>> 1. With gcc on ppc64, long doubles exist, they can
> >>> be used, just not safely as constants (and maybe they
> >>> still can be used safely under specific conditions?).
> >
> >>> 2. I am not an expert in either PowerPC64 or gcc. :)
> >
> >>> Looking at connections.c, we have (in order):
> >>> * handling long double as a valid case in a switch statement checking
> size
> >>> * adding long double as a field in the u union define
> >>> * handling long double as a valid case in a switch statement checking
> size
> >>> * handling long double as a valid case in a switch statement checking
> size
> >>> * memcpy from the address of a long double
> >
> >>> In format.c, we have (in order):
> >>> * conditionally creating private_nearbyintl for R_nearbyintl
> >>> * defining a static const long double tbl[]
> >>> * use exact scaling factor in long double precision
> >
> >>> For most of these, it seems safe to leave them as is for ppc64. I would
> >>> have thought that the gcc compiler might have had issue with:
> >
> >>> connections.c:
> >>> static long double ld1;
> >>> for (i = 0, j = 0; i < len; i++, j += size) {
> >>> ld1 = (long double) REAL(object)[i];
> >
> >>> format.c:
> >>> static const long double tbl[] =
> >
> >>> ... but it doesn't. Perhaps the original code at issue:
> >
> >>> arithmetic.c:
> >>> static LDOUBLE q_1_eps = 1 / LDBL_EPSILON;
> >
> >>> only makes gcc unhappy because of the very large value trying to be
> stored
> >>> in the static long double, which would make it span the "folded
> double" on
> >>> that architecture.
> >
> >>> *
> >
> >>> It seems that the options are:
> >
> >>> A) Patch the one place where the compiler determines it is not safe to
> use
> >>> a static long double on ppc64.
> >>> B) Treat PPC64 as a platform where it is never safe to use a static
> long
> >>> double
> >
> >>> FWIW, I did run the test suite after applying my patch and all of the
> tests
> >>> pass on ppc64.
> >
> >>> Tom
> >
> >> Thank you, Tom.
> >> You were right... and only A) is needed.
> >
> >> In the mean time I've also been CC'ed in a corresponding debian
> >> bug report on the exact same architecture.
> >
> >> In the end, after explanation and recommendation by Tomas
> >> Kalibera, I've committed a slightly better change to R's
> >> sources, both in the R-devel (trunk) and the "R-3.6.x patched"
> >> branch: Via a macro, it continues to use long double also for
> >> the PPC 64 in this case:
> >
> >> $ svn diff -c77587
> >> Index: src/main/arithmetic.c
> >> ===
> >> --- src/main/arithmetic.c(Revision 77586)
> >> +++ src/main/arithmetic.c(Revision 77587)
> >> @@ -176,8 +176,14 @@
> >> #endif
> >> }
> >
> >> +
> >> #if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE)
> >> +# ifdef __PPC64__
> >> + // PowerPC 64 (when gcc has -mlong-double-128) fails constant folding
> with LDOUBLE
&
[Rd] License for Rembedded.h
Possibly more of a legal question than a technical development question, but here goes. In the doc\COPYRIGHTS file it is made clear that the intention is that you can write R packages and distribute them under licenses not compatible with GPL, by making the relevant header files available under the LGPL. This was an explicit change that was made in February 2001, and allows for DLLs that require the API header files for compilation and are linked against R.dll to not be "infected" with the GPL. However the Rembedded.h header file isn't included in the list in the doc\COPYRIGHTS file, and the copyright statement in the Rembedded.h header file lists the GPL and not the LGPL as the relevant license. So it doesn't look like it is allowed that I be able to use the R invocation API to launch R and embed it in my product (such as a new GUI, or integration with another product) and ship that product under a license not compatible with GPL? Is this correct? Or is it the intention that I be able to write a commercial front-end of some kind for R? Thanks! [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] License for Rembedded.h
I've looked at various threads on the r-devel archive and it looks like this may have been discussed before, but as far as could tell, not to any great resolution, and not, it seems, specifically covering this angle. My understanding of LGPL is that ALL of the source files that go into R.dll (and indeed all libraries that R.dll itself linked to, apart from those covered by the system library exception) would need to be released under LGPL in order to allow me to link to R.dll and not have my program subject to GPL. This would apply to native libraries (dlls) providing functions in addon packages too. If that weren't the situation then I could take a library covered by GPL, write a different interface to it, put LGPL on those headers compile up a new DLL and I've then got LGPL access to a library previously released under GPL, which can't be the intention, otherwise LGPL would drive a coach and horses through GPL. There is provision in the GPL license (it's mentioned in the FAQ) for providing for linking to a GPL library through one specific interface by providing specific exception text in the copyright header in all of the files that make up the library. That would only be possible if the copyright holders of all relevant GPL code agreed to that, as that would be an extra grant to the license. So if R linked to any third party GPL code, this wouldn't be possible I don't think. So I guess the question here is what the intention is of the R authors with respect to the limitations or freedoms that they are intending to allow. After all, as the copyright owners they aren't going to sue if a use falls outside of their intention, even if on a strict interpretation of the license such use wouldn't be allowed. So it seems to be the intention that I can write a DLL to provide R functions in an add on package, which requires linkage to R.dll. Not convinced that the license it set up right to cover that, but that appears to be the intention. Question is whether at the other end, at the invocation API end, whether it is the intention to be able to use the invocation API and link to R.dll without my program being subjected to GPL. Note that I'm not talking here about anything to do with code written in the language of R. This is purely concerned with treating R as a library with an interface and wanting to link to that interface and whether the intention or the actuality of the license allow that. Thanks! -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of Tom Quarendon Sent: 03 August 2010 13:23 To: r-devel@r-project.org Subject: [Rd] License for Rembedded.h Possibly more of a legal question than a technical development question, but here goes. In the doc\COPYRIGHTS file it is made clear that the intention is that you can write R packages and distribute them under licenses not compatible with GPL, by making the relevant header files available under the LGPL. This was an explicit change that was made in February 2001, and allows for DLLs that require the API header files for compilation and are linked against R.dll to not be "infected" with the GPL. However the Rembedded.h header file isn't included in the list in the doc\COPYRIGHTS file, and the copyright statement in the Rembedded.h header file lists the GPL and not the LGPL as the relevant license. So it doesn't look like it is allowed that I be able to use the R invocation API to launch R and embed it in my product (such as a new GUI, or integration with another product) and ship that product under a license not compatible with GPL? Is this correct? Or is it the intention that I be able to write a commercial front-end of some kind for R? Thanks! [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ Information from ESET NOD32 Antivirus, version of virus signature database 5336 (20100803) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 5338 (20100803) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 5338 (20100803) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Support for transparency in metafile export & support for export to Powerpoint
Dear all, For vector-based output, PDF export of R graphs works well, but unfortunately Office on Windows provide poor support for PDF and importing & exporting to other formats using Inkscape can be buggy. Enhanced metafile export in turn does not support transparency (also not in package devEMF - are there any plans to support this perhaps in the future?). And rasterising graphs to a PNG I often find dissatisfactory, as vector-based graphs should ideally stay in vector format, especially when it comes to axes and axes labels etc. So this means that by default, there are rather few good options left to export all those beautiful R graphs in high-quality vector format. I recently discovered that package ReporteRs provides near-perfect export of R graphs in fully editable vector format to Powerpoint or Word using the Office native DrawingML format, with full upport for transparency, in a much better quality than what is provided by default in grDevices. This made me wonder if exporting a graph to Powerpoint could perhaps also be supported in grDevices? In ReporteRs the code e.g. to export a ggplot would be library( ReporteRs ) require( ggplot2 ) mydoc = pptx( ) mydoc = addSlide( mydoc, slide.layout = "Title and Content" ) mydoc = addTitle( mydoc, "Plot examples" ) myplot = qplot(Sepal.Length, Petal.Length , data = iris, color = Species , size = Petal.Width, alpha = I(0.7) ) mydoc = addPlot( mydoc, function( ) print( myplot ), vector.graphic=TRUE) writeDoc( mydoc, file = "test plot.pptx" ) I was thinking it could be nice though to provide this capability also in base R - so that e.g. windows() plot(...) File...Save as...would also provide an option to save as Powerpoint, with options for the width, height, font and font size used for export, or that there would be an extra command dev.copy2ppt or a combination of ppt ( ) and dev.off() to export to Powerpoint, using the code available in ReporteRs. Especially for use in the classroom this would be super handy, as windows users are now pretty much tied to using bitmap-based PNG, thereby limiting the ease with which the final layout of R graphs can be edited ! best regards, Tom Wenseleers Prof Tom Wenseleers University of Leuven Naamsestraat 59 3000 Leuven, Belgium https://bio.kuleuven.be/ento/wenseleers/twenseleers.htm [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Support for transparency in metafile export & support for export to Powerpoint
Dear all,
Further to my previous message I now made a one-line convencience function to
export your currently active graphics window/plot to either Word or Powerpoint
in Office-native vector-based DrawingML format using either
export2ppt(file="plot.pptx")
or
export2doc(file="plot.docx") :
see
http://stackoverflow.com/questions/31212659/r-function-to-capture-r-plot-in-current-graphics-device-and-export-it-to-powerp/31221813#31221813
(analogous in syntax to function dev.copy2pdf in grDevices)
The code of the function is:
export2office = function(file = "plot", type="PPT", scaling = 90, aspectr=NULL,
vector.graphic = TRUE, fontname = "Arial", pointsize=20) {
file=sub("^(.*)[.].*", "\\1", file)
if (type=="PPT"|type=="PPTX") {ext=".pptx";type="PPT"} else
{ext=".docx";type="DOC"}
require(ReporteRs)
captureplot = function() {p = invisible(recordPlot())
dev.copy()
return(p)}
p = captureplot()
plotsize = dev.size()
plotaspectr = plotsize[[1]]/plotsize[[2]]
if (!is.null(aspectr)) plotaspectr=aspectr
myplot=function(pl=p) print(pl)
if (type=="PPT") {doc = pptx();doc = addSlide(doc, slide.layout =
"Blank");pagesize = dim(doc)$slide.dim} else {doc = docx();pagesize =
dim(doc)$page-dim(doc)$margins[c(4,3)]}
pageaspectr = pagesize["width"]/pagesize["height"]
if (pageaspectr>plotaspectr) {xf=plotaspectr/pageaspectr;yf=1} else
{xf=1;yf=pageaspectr/plotaspectr}
w = (scaling/100)*pagesize["width"]*xf;
h = (scaling/100)*pagesize["height"]*yf
if (type=="PPT") {doc = addPlot( doc, myplot, vector.graphic =
vector.graphic, fontname = fontname, pointsize = pointsize,
offx = (pagesize["width"]-w)/2, offy =
(pagesize["height"]-h)/2,
width = w, height = h) } else {doc = addPlot( doc, myplot,
vector.graphic = vector.graphic, fontname = fontname, pointsize = pointsize,
width = w,
height = h)}
writeDoc( doc, paste0(file,ext) )
}
export2ppt = function(type="PPT", ...) export2office(type=type,...)
export2doc = function(type="DOC", ...) export2office(type=type,...)
# Examples:
require(ggplot2)
qplot(Sepal.Length, Petal.Length, data = iris, color = Species, size =
Petal.Width, alpha = I(0.7))
export2ppt(file="plot.pptx")
export2ppt(file="plot.pptx",aspectr=1.7,fontname="Times New Roman")
heatmap(as.matrix(eurodist))
export2ppt(file="heatmap.pptx")
In Powerpoint you can then right click on the graph and Ungroup it, thereby
allowing you to make minor changes to the layout if need be, before saving it
as PDF from PPT. The quality is much better than what you get if you try to do
the editing in the PDF version using Inkscape. It works with ggplot2 and
lattice plots as well as base R plots and also fully supports transparency
(unlike e.g. EPS or EMF export in R - EMF in the meantime I found out does not
support transparency at all, and can only deal with it by rasterizing all
semi-tranparent graphics elements).
Given the widespread use of Office/LibreOffice/OpenOffice I think it would be
very handy if this kind of functionality were provided as part of base R at one
stage or another (as would Excel import and export, for that matter). So if
anyone on this list thinks it would be a good idea to incorporate this function
in grDevices or something, please do! (would be handy e.g. if powerpoint export
also showed in the File...Save as... interactive graphics devices, like
windows() )
Otherwise I'll be in touch with the ReporteRs author to try to convince him to
add it there.
cheers,
Tom
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Support for high DPI 4K screens
I was recently testing R and RStudio on a high dpi 4K monitor under Windows and noticed that the plot window cannot be scaled or zoomed without affecting the relative sizing of all plot elements (line widths, font sizes, legend spacing etc). RStudio seems to try to overcome this by enabling dpi scaling for the plot window on high dpi screens, but this results in really fuzzy text and graphics (e.g. causing colour fringing when using Cleartype). This made me wonder if the assumed dpi of the screen could perhaps be set using some global option, so that all graphics could be made to scale their contents in a correct way, without affecting the size relative to the size of the plot window (I think now it is always assumed to be 72 dpi)? I recently asked a related question re how to scale R graphics proportionally to the size of the plot window on Stackoverflow, http://stackoverflow.com/questions/31381066/r-function-to-make-plot-symbols-line-widths-and-text-in-ggplot2-lattice-and-b/32412384#32412384 but nobody seemed to be able to come up with a good answer/solution. This made me wonder if there could perhaps be some low-level solution to this? best regards, Tom [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Default location where packages are stored under Windows
With a default installation of R on Windows platforms, packages are stored under Program Files/R/R-3.X.X/library. This often causes permission problems, as this directory is always read only by default, requiring the user to either change permissions for that directory or to change the directory where packages are stored later on option wise through modification of .libPaths in .Rprofile. For most users I imagine this is slightly annoying, having to do this over and over. I was just wondering if the default directory to store packages on Windows platforms could therefore not better be made the personal library folder, Users/Username/Documents/R/win-library/3.XX/, or perhaps even better, Users/All Users/Documents/R/win-library/3.XX/, so that downloaded packages are available for all users ? [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Default location where packages are stored under Windows
Hi Jeroen, Yes I noticed this - but with students etc it often still causes confusion, and I was just wondering if it would not be better to make it the default during installation of a new R version, as opposed to only changing over the first time you try to install a package and R noticing that the default directory is not writable... cheers, Tom From: Jeroen Ooms [jeroeno...@gmail.com] Sent: 05 September 2015 14:45 To: Tom Wenseleers Cc: r-devel@r-project.org Subject: Re: [Rd] Default location where packages are stored under Windows On Sat, Sep 5, 2015 at 2:05 PM, Tom Wenseleers wrote: > I was just wondering if the default directory to store packages on Windows > platforms could therefore not better be made the personal library folder, > Users/Username/Documents/R/win-library/3.XX/ I think this is already the case? The first time you try to install a package as non-admin, you will be prompted with a message that the global library is not writable and if you want to create a user library. Once the user library exists, R will make that the default by putting it on the head of .libPaths() at the start of every R session. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Support for high DPI 4K screens
Hi Brian, Thanks for your message. Just to clarify - I've seen this problem on Windows both under Windows 8.1 and Windows 10, and the RStudio people were also aware of the problem (it's also a known problem on Linux btw, https://support.rstudio.com/hc/communities/public/questions/201913407-RStudioGD-option-to-set-screen-DPI?locale=en-us )... I gathered that part of the problem is the difficulty to scale a graphics window without affecting the relative scaling of the plot elements (text, line widths etc), which is why in RStudio they now rely on the inbuilt dpi scaling of Windows, which merely upscales the low res image by a factor of 2 if you set the zoom factor to 2 (resulting in a blurry plot window). Not using dpi scaling or zooming is also an option, but then one typically has to make one's plot window larger, thereby requiring one to adjust the scaling of all plot elements, e.g. in ggplot2, ie text sizes, plot symbol sizes, line sizes etc due to the fact that all those sizes are ! specified as absolute sizes... Other problem is that without zooming the default text sizes of all standard ggplot2 themes e.g. are much too small. This made me wonder if in some future edition such problems could not be solved by allowing graphics to scale proportionally, maybe with some optional zoom factor or something, or by being able to specify how many ppi one's screen is? Many people I know that use R would also love to be able to maximize their plot window without it affecting the scaling of all the text etc in the graph. Right now one is pretty much tied to exporting as PDF and then viewing that full screen... Or am I overlooking something? I am just asking this question here as I have a feeling that a solution to this problem would probably be most conveniently addressed somewhere at a low level in grDevices or grid... best regards, Tom From: R-devel [r-devel-boun...@r-project.org] on behalf of Brian G. Peterson [br...@braverock.com] Sent: 05 September 2015 15:56 To: r-devel@r-project.org Subject: Re: [Rd] Support for high DPI 4K screens On 09/05/2015 06:46 AM, Tom Wenseleers wrote: > I was recently testing R and RStudio on a high dpi 4K monitor under > Windows and noticed that the plot window cannot be scaled or zoomed > without affecting the relative sizing of all plot elements (line > widths, font sizes, legend spacing etc). RStudio seems to try to > overcome this by enabling dpi scaling for the plot window on high dpi > screens, but this results in really fuzzy text and graphics (e.g. > causing colour fringing when using Cleartype). This made me wonder if > the assumed dpi of the screen could perhaps be set using some global > option, so that all graphics could be made to scale their contents in > a correct way, without affecting the size relative to the size of the > plot window (I think now it is always assumed to be 72 dpi)? I > recently asked a related question re how to scale R graphics > proportionally to the size of the plot window on Stackoverflow, > http://stackoverflow.com/questions/31381066/r-function-to-make-plot-symbols-line-widths-and-text-in-ggplot2-lattice-and-b/32412384#32412384 > but nobody seemed to be able to come up with a good answer/solution. > This made me wonder if there could perhaps be some low-level solution > to this? R-help or RStudio support seem more appropriate for this? 'The correct way' is a very subjective term. I really don't want R or any other application or operating system assuming that I bought a whole bunch of expensive 4k displays for smoother lines. I bought them for pixel count. We routinely use R and RStudio on 4k displays, I'm doing so right now. The problem you are likely having is an old version of Windows, and has little or nothing to do with R or RStudio. Windows 8 and higher have extensive application scaling support. Of course, Macs and Linux have good scaling support also, and you get better R performance on Macs and Linux as well. Even on Windows, we typically run almost all our applications on 4k displays at native resolution, and only change title bar and menu scaling based on distance to the screen. We also use all those pixels. Your use cases, of course, may vary. Which, in part, is why R has so much control over the types of graphic devices you create, and how you choose to control them. Regards, Brian -- Brian G. Peterson http://braverock.com/brian/ Ph: 773-459-4973 IM: bgpbraverock __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Return options used to configure R
Is there any way to print out the options that where passed to configure when R was built? I want to build a later version to the one I have on my machine, and I want to build it in the same way, with the same configure options. Thanks. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Return options used to configure R
So in English what you are saying is that there's a file called Makeconf in the
etc directory under the R_HOME that contains the information.
That certainly seems to be true for Linux.
Thanks.
-Original Message-
From: Gábor Csárdi [mailto:csardi.ga...@gmail.com]
Sent: 22 January 2016 11:37
To: Tom Quarendon
Cc: r-devel@r-project.org
Subject: Re: [Rd] Return options used to configure R
A one liner that should work on most systems:
grep("configure", readLines(file.path(R.home(), "etc", "Makeconf")), value=TRUE)
Gabor
On Thu, Jan 21, 2016 at 5:38 PM, Tom Quarendon
wrote:
> Is there any way to print out the options that where passed to configure when
> R was built?
> I want to build a later version to the one I have on my machine, and I want
> to build it in the same way, with the same configure options.
>
> Thanks.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Return options used to configure R
I did have a search, but searching for "configure" just brought up loads of results for how to configure R. I'm sure it is in the manual, once you know where to look for it and if you know all the manuals inside out. Looking at the help for R CMD config, it's not actually clear that these relate to the options specified on configure, and it doesn't tell you things like --enable-R-shlib, or --prefix etc. Anyway, thanks for the info. The Makeconf file is what I want. At least on Linux, doesn't appear to exist on our OSX installation, but we probably installed that from a pre-built package. Ditto Windows. -Original Message- From: Dirk Eddelbuettel [mailto:e...@debian.org] Sent: 22 January 2016 12:07 To: Tom Quarendon Cc: Gábor Csárdi ; r-devel@r-project.org Subject: Re: [Rd] Return options used to configure R On 22 January 2016 at 11:40, Tom Quarendon wrote: | So in English what you are saying is that there's a file called Makeconf in the etc directory under the R_HOME that contains the information. | That certainly seems to be true for Linux. And Debian / Ubuntu have a convenience softlink to make this /etc/R/ Also note that 'R CMD config varname' extracts each of these values from the command-line, rather than R. And all of this is in the fine manuals you are cordially invited to peruse at your lesiure ... Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [RFC] A case for freezing CRAN
For me, the most important aspect is being able to reproduce my own
work. Some other tools offer interesting approaches to managing
packages:
* NPM -- The Node Package Manager for Node.js loads a local copy of
all packages and dependencies. This helps ensure reproducibility and
avoids dependency issues. Different projects in different directories
can then use different package versions.
* Julia -- Julia's package manager is based on git, so users should
have a local copy of all package versions they've used. Theoretically,
you could use separate git repos for different projects, and merge as
desired.
I've thought about putting my local R library into a git repository.
Then, I could clone that into a project directory and use
.libPaths(".Rlibrary") in a .Rprofile file to set the library
directory to the clone. In addition to handling package versions, this
might be nice for installing packages that are rarely used (my library
directory tends to get cluttered if I start trying out packages).
Another addition could be a local script that starts a specific
version of R.
For now, I don't have much incentive to do this. For the packages that
I use, R's been pretty good to me with backwards compatibility.
I do like the idea of a CRAN mirror that's under version control.
On Tue, Mar 18, 2014 at 4:24 PM, Jeroen Ooms wrote:
> This came up again recently with an irreproducible paper. Below an
> attempt to make a case for extending the r-devel/r-release cycle to
> CRAN packages. These suggestions are not in any way intended as
> criticism on anyone or the status quo.
>
> The proposal described in [1] is to freeze a snapshot of CRAN along
> with every release of R. In this design, updates for contributed
> packages treated the same as updates for base packages in the sense
> that they are only published to the r-devel branch of CRAN and do not
> affect users of "released" versions of R. Thereby all users, stacks
> and applications using a particular version of R will by default be
> using the identical version of each CRAN package. The bioconductor
> project uses similar policies.
>
> This system has several important advantages:
>
> ## Reproducibility
>
> Currently r/sweave/knitr scripts are unstable because of ambiguity
> introduced by constantly changing cran packages. This causes scripts
> to break or change behavior when upstream packages are updated, which
> makes reproducing old results extremely difficult.
>
> A common counter-argument is that script authors should document
> package versions used in the script using sessionInfo(). However even
> if authors would manually do this, reconstructing the author's
> environment from this information is cumbersome and often nearly
> impossible, because binary packages might no longer be available,
> dependency conflicts, etc. See [1] for a worked example. In practice,
> the current system causes many results or documents generated with R
> no to be reproducible, sometimes already after a few months.
>
> In a system where contributed packages inherit the r-base release
> cycle, scripts will behave the same across users/systems/time within a
> given version of R. This severely reduces ambiguity of R behavior, and
> has the potential of making reproducibility a natural part of the
> language, rather than a tedious exercise.
>
> ## Repository Management
>
> Just like scripts suffer from upstream changes, so do packages
> depending on other packages. A particular package that has been
> developed and tested against the current version of a particular
> dependency is not guaranteed to work against *any future version* of
> that dependency. Therefore, packages inevitably break over time as
> their dependencies are updated.
>
> One recent example is the Rcpp 0.11 release, which required all
> reverse dependencies to be rebuild/modified. This updated caused some
> serious disruption on our production servers. Initially we refrained
> from updating Rcpp on these servers to prevent currently installed
> packages depending on Rcpp to stop working. However soon after the
> Rcpp 0.11 release, many other cran packages started to require Rcpp >=
> 0.11, and our users started complaining about not being able to
> install those packages. This resulted in the impossible situation
> where currently installed packages would not work with the new Rcpp,
> but newly installed packages would not work with the old Rcpp.
>
> Current CRAN policies blame this problem on package authors. However
> as is explained in [1], this policy does not solve anything, is
> unsustainable with growing repository size, and sets completely the
> wrong incentives for contributing code. Progress comes with breaking
> changes, and the system should be able to accommodate this. Much of
> the trouble could have been prevented by a system that does not push
> bleeding edge updates straight to end-users, but has a devel branch
> where conflicts are resolved before publishing them in the next
> r-release.
>
>
[Rd] Please make Pre-3.1 read.csv (type.convert) behavior available
Hi, We at 0xdata use Java and R together, and the new behavior for read.csv has made R unable to read the output of Java’s Double.toString(). This, needless to say, is disruptive for us. (Actually, it was downright shocking.) +1 for restoring old behavior. Thanks, Tom __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Please make Pre-3.1 read.csv (type.convert) behavior available
Hi Duncan,
Please allow me to add a bit more context, which I probably should have added
to my original message.
We actually did see this in an R 3.1 beta which was pulled by an apt-get and
thought it had been released
accidentally. From my user perspective, the parsing of a string like
1.2345678901234567890 into a
factor was so surprising, I actually assumed it was just a really bad bug that
would be fixed before the
real" release. I didnt bother reporting it since I assumed beta users would
be heavily impacted and
there is no way it wouldnt be fixed. Apologies for that mistake on my part.
After discovering this new behavior really got released GA, I went searching to
see what was going on.
I found this bug, which states If you wish to express your opinion about the
new behavior, please do so
on the R-devel mailing list."
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=15751
So Im sharing my opinion, as suggested. Thanks to all for the time spent
reading my opinion.
Let me also say, we are huge fans of R; many of our customers use R, and we
greatly appreciate the
efforts of the R core team. We are in the process of contributing an H2O
package back to the R
community and thanks to the CRAN moderators, as well, for their assistance in
this process.
CRAN is a fantastic resource.
I would like to share a little more insight on how this behavior affects us, in
particular. These merits
have probably already been debated, but let me state them here again to provide
the appropriate
context.
1. When dealing with larger and larger data, things become cumbersome. Your
comment that
specifying column types would work is true. But when there are thousands+ of
columns, specifying
them one by one becomes more and more of a burden, and it becomes easier to
make a mistake.
And when you do make a mistake, you can imagine a tool writer choosing to just
do what its told
and swallowing the mistake. (Trying not to be smarter than the user.)
2. When working with datasets that have more and more rows, sometimes there is
a bad row.
Big data is messy. Having one bad value in one bad row contaminate the entire
dataset can be
undesirable for some. When you have millions of rows or more, each row becomes
less precious.
Many people would rather just ignore the effects of the bad row than try to fix
it. Especially in this
case, when bad means a bit of extra precision that likely wont have a
negative impact on the result.
(In our case, this extra precision was the output of Javas Double.toString().)
Our users want to use R as a driver language and a reference tool. Being able
to interchange
data easily (even just snippets) between tools is very valuable.
Thanks,
Tom
Below is an example of how you can create a million row dataset which works
fine (parses as a
numeric), but then adding just one bad row (which still *looks* numeric!) flips
the entire column to
a factor. Finding that one row out of a million+ can be quite a challenge.
# Script to generate dataset.
$ cat genDataset.py
#!/usr/bin/env python
for x in range(0, 100):
print (str(x) + ".1")
# Generate the dataset.
$ ./genDataset.py > million.csv
# R 3.1 thinks its a numeric.
$ R
> df = read.csv("million.csv")
> str(df)
'data.frame': 99 obs. of 1 variable:
$ X0.1: num 1.1 2.1 3.1 4.1 5.1 6.1 7.1 8.1 9.1 10.1 ...
# Add one more over-precision row.
$ echo "1.2345678901234567890" >> million.csv
# Now R 3.1 thinks its a factor.
$ R
> df2 = read.csv("million.csv")
> str(df2)
'data.frame': 100 obs. of 1 variable:
$ X0.1: Factor w/ 100 levels "1.1","1.2345678901234567890",..: 1 13
24 35 46 57 666668 79 90 3 ...
On Apr 26, 2014, at 4:28 AM, Duncan Murdoch wrote:
> On 26/04/2014, 12:23 AM, Tom Kraljevic wrote:
>>
>> Hi,
>>
>> We at 0xdata use Java and R together, and the new behavior for read.csv has
>> made R unable to read the output of Javas Double.toString().
>
> It may be less convenient, but it's certainly not "unable". Use colClasses.
>
>
>>
>> This, needless to say, is disruptive for us. (Actually, it was downright
>> shocking.)
>
> It wouldn't have been a shock if you had tested pre-release versions.
> Commercial users of R should be contributing to its development, and that's a
> really easy way to do so.
>
> Duncan Murdoch
>
>>
>> +1 for restoring old behavior.
>
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Please make Pre-3.1 read.csv (type.convert) behavior available
Hi Dirk, Thanks for taking the time to respond (both here and in other forums). Most of what I wanted to share I put in a followup response to Duncan (please read that thread if you’re interested). I would like to comment on the last point you brought up, though, in case anyone else finds it beneficial. For data which is exchanged programmatically machine-to-machine, I was able to use Java’s Double.toHexString() as a direct replacement for toString(). R is able to read this lossless (but still text) format. So this addresses some of the challenges we have with this change. Thanks, Tom On Apr 26, 2014, at 5:26 AM, Dirk Eddelbuettel wrote: > > On 26 April 2014 at 07:28, Duncan Murdoch wrote: > | On 26/04/2014, 12:23 AM, Tom Kraljevic wrote: > | > > | > Hi, > | > > | > We at 0xdata use Java and R together, and the new behavior for read.csv > has > | > made R unable to read the output of Java’s Double.toString(). > | > | It may be less convenient, but it's certainly not "unable". Use colClasses. > | > | > | > > | > This, needless to say, is disruptive for us. (Actually, it was downright > shocking.) > | > | It wouldn't have been a shock if you had tested pre-release versions. > | Commercial users of R should be contributing to its development, and > | that's a really easy way to do so. > > Seconded. For what it is worth, I made five pre-release available within > Debian. Testing thses each was just an apt-get away. > > In any event, you can also farm out the old behaviour to a (local or even > CRAN) package that provides the old behaviour if your life depends upon it. > > Or you could real serialization rather than relying on the crutch that is csv. > > Dirk > > -- > Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Please make Pre-3.1 read.csv (type.convert) behavior available
Hi, One additional follow-up here. Unfortunately, I hit what looks like an R parsing bug that makes the Java Double.toHexString() output unreliable for reading by R. (This is really unfortunate, because the format is intended to be lossless and it looks like it’s so close to fully working.) You can see the spec for the conversion here: http://docs.oracle.com/javase/7/docs/api/java/lang/Double.html#toHexString(double) The last value in the list below is not parsed by R in the way I expected, and causes the column to flip from numeric to factor. -0x1.8ff831c7dp-1 -0x1.aff831c7dp-1 -0x1.bff831c7dp-1 -0x1.cff831c7dp-1 -0x1.dff831c7dp-1 -0x1.eff831c7dp-1 -0x1.fff831c7dp-1 <<<<< this value is not parsed as a number and flips the column from numeric to factor. Below is the R output from adding one row at a time to “bad.csv”. The last attempt results in a factor rather than a numeric column. What’s really odd about it is that the .a through .e case work fine but the .f case doesn’t. Thanks, Tom > bad.df = read.csv(file="/Users/tomk/bad.csv", header=F) > str(bad.df) 'data.frame': 1 obs. of 1 variable: $ V1: num -0.781 > bad.df = read.csv(file="/Users/tomk/bad.csv", header=F) > str(bad.df) 'data.frame': 2 obs. of 1 variable: $ V1: num -0.781 -0.844 > bad.df = read.csv(file="/Users/tomk/bad.csv", header=F) > str(bad.df) 'data.frame': 3 obs. of 1 variable: $ V1: num -0.781 -0.844 -0.875 > bad.df = read.csv(file="/Users/tomk/bad.csv", header=F) > str(bad.df) 'data.frame': 4 obs. of 1 variable: $ V1: num -0.781 -0.844 -0.875 -0.906 > bad.df = read.csv(file="/Users/tomk/bad.csv", header=F) > str(bad.df) 'data.frame': 5 obs. of 1 variable: $ V1: num -0.781 -0.844 -0.875 -0.906 -0.937 > bad.df = read.csv(file="/Users/tomk/bad.csv", header=F) > str(bad.df) 'data.frame': 6 obs. of 1 variable: $ V1: num -0.781 -0.844 -0.875 -0.906 -0.937 ... > bad.df = read.csv(file="/Users/tomk/bad.csv", header=F) > str(bad.df) 'data.frame': 7 obs. of 1 variable: $ V1: Factor w/ 7 levels "-0x1.8ff831c7dp-1",..: 1 2 3 4 5 6 7 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Please make Pre-3.1 read.csv (type.convert) behavior available
Hi Duncan,
This program and output should answer your question regarding java behavior.
Basically the character toHexString() representation is shown to be lossless
for this
example (in Java).
Please let me know if there is any way I can help further. Id love for this
to work!
I would be happy to put all this into an R bug report if that is convenient for
you.
Thanks,
Tom
$ cat example.java
class example {
public static void main(String[] args) {
String value_as_string = "-0x1.fff831c7dp-1";
double value = Double.parseDouble(value_as_string);
System.out.println("Starting string: " + value_as_string);
System.out.println("value toString() : " + Double.toString(value));
System.out.println("value toHexString(): " + Double.toHexString(value));
long bits = Double.doubleToRawLongBits(value);
boolean isNegative = (bits & 0x8000L) != 0;
long biased_exponent = (bits & 0x7ff0L) >> 52;
long exponent = biased_exponent - 1023;
long mantissa = bits & 0x000fL;
System.out.println("isNegative : " + isNegative);
System.out.println("biased exponent: " + biased_exponent);
System.out.println("exponent : " + exponent);
System.out.println("mantissa : " + mantissa);
System.out.println("mantissa as hex: " +
Long.toHexString(mantissa));
}
}
$ javac example.java
$ java example
Starting string: -0x1.fff831c7dp-1
value toString() : -0.40448440611
value toHexString(): -0x1.fff831c7dp-1
isNegative : true
biased exponent: 1022
exponent : -1
mantissa : 4503063234609149
mantissa as hex: fff831c7d
$ java -version
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
On Apr 26, 2014, at 2:18 PM, Duncan Murdoch wrote:
> On 26/04/2014, 4:12 PM, Tom Kraljevic wrote:
>>
>> Hi,
>>
>>
>> One additional follow-up here.
>>
>> Unfortunately, I hit what looks like an R parsing bug that makes the Java
>> Double.toHexString() output
>> unreliable for reading by R. (This is really unfortunate, because the
>> format is intended to be lossless
>> and it looks like its so close to fully working.)
>>
>> You can see the spec for the conversion here:
>>
>> http://docs.oracle.com/javase/7/docs/api/java/lang/Double.html#toHexString(double)
>>
>> The last value in the list below is not parsed by R in the way I expected,
>> and causes the column to flip
>> from numeric to factor.
>>
>>
>> -0x1.8ff831c7dp-1
>> -0x1.aff831c7dp-1
>> -0x1.bff831c7dp-1
>> -0x1.cff831c7dp-1
>> -0x1.dff831c7dp-1
>> -0x1.eff831c7dp-1
>> -0x1.fff831c7dp-1 <<<<< this value is not parsed as a number
>> and flips the column from numeric to factor.
>
> That looks like a bug in the conversion code. It uses the same test for lack
> of accuracy for hex doubles as it uses for decimal ones, but hex doubles can
> be larger before they lose precision. I believe the largest integer that can
> be represented exactly is 2^53 - 1, i.e.
>
> 0x1.fp52
>
> in this notation; can you confirm that your Java code reads it and writes the
> same string? This is about 1% bigger than the limit at which type.convert
> switches to strings or factors.
>
> Duncan Murdoch
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Interface between R and a Open Load Flow tool (Gridlabd or OpenDSS)
It's certainly possible. The best approach depends mainly on how tightly you need to bind to input and output data and how much of the internals you need to access. Here are a couple of approaches that I've used with OpenDSS: * Batch mode -- Generate inputs, run OpenDSS (or Gridlab-D), then read the text outputs. * COM interface -- Under windows, you can access OpenDSS via a COM interface. I think the OpenDSS website has examples of doing this from Python and Matlab. It's similar under R. Beyond that, there should be more direct ways to interface to either. On Wed, Jul 30, 2014 at 4:42 AM, Yamshid wrote: > Dear all, > > I want to know if it would be possible to have an interface between R and an > electrical load flow tool. > It would be interesting with Gridlab-D, an open-source tool that works in > C++. > > The idea is that we can develop a R programm that internally calls Gridlab-D > and process directly the results (also able to develop internal loops). > > In case that is not possible yet. Would someone be interested into develop > this interface together? > > Thank you. > > > > -- > View this message in context: > http://r.789695.n4.nabble.com/Interface-between-R-and-a-Open-Load-Flow-tool-Gridlabd-or-OpenDSS-tp4694752.html > Sent from the R devel mailing list archive at Nabble.com. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R process (and forked children via system2) are limited to 1 core?
Hi,
(Using R 3.1.1 on Ubuntu 12.04.4 LTS)
What is the recommended way for R to fork a (non-R) process that is not CPU
limited?
Currently I am using R's system2() call, and this is inheriting the environment
of the R process.
I notice that (at least on Linux) when I am poking around /proc that the R
process itself is setting up cpu limitations for itself (max 1 core).
Using strace, I see the following:
(strace output)
out.20612:sched_setaffinity(0, 128, {100, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0}) = 0
And proc shows:
(cat /proc/nnn/status)
Cpus_allowed: 0001
Cpus_allowed_list: 0
See that the Cpus_allowed bitmask is a single core. Normally it's fff...f.
I want my child process (java in this case) not to share this limitation. What
is the recommended way of doing this from R?
Any ideas or suggestions appreciated!
Thanks,
Tom
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R process (and forked children via system2) are limited to 1 core?
Hi Nathaniel,
Thanks for the suggestion.
Im actually not really using R to do any real work.
Im starting the R H2O package (a Java machine learning package) and forwarding
all the work to H2O.
This is the list of packages I have in R:
> search()
[1] ".GlobalEnv""package:h2o" "package:tools"
[4] "package:statmod" "package:rjson" "package:RCurl"
[7] "package:bitops""package:stats" "package:graphics"
[10] "package:grDevices" "package:utils" "package:datasets"
[13] "package:methods" "Autoloads" "package:base"
And here is the /proc info
tomk@mr-0xb4:~$ ps -efww | grep R | grep tomk
tomk 8366 13845 1 14:25 pts/000:00:01 /usr/lib/R/bin/exec/R
tomk 12960 27363 0 14:27 pts/300:00:00 grep --color=auto R
tomk@mr-0xb4:~$ grep Cpus /proc/8366/status
Cpus_allowed: 0001
Cpus_allowed_list: 0
As you can see, my R is super vanilla. I havent configured hardly anything.
Im just loading a few plain packages.
Thanks,
Tom
On Aug 6, 2014, at 2:20 PM, Nathaniel Smith wrote:
> On Wed, Aug 6, 2014 at 6:01 AM, Tom Kraljevic wrote:
>>
>> Hi,
>>
>>
>> (Using R 3.1.1 on Ubuntu 12.04.4 LTS)
>>
>>
>> What is the recommended way for R to fork a (non-R) process that is not CPU
>> limited?
>> Currently I am using R's system2() call, and this is inheriting the
>> environment of the R process.
>>
>>
>> I notice that (at least on Linux) when I am poking around /proc that the R
>> process itself is setting up cpu limitations for itself (max 1 core).
>>
>>
>> Using strace, I see the following:
>>
>> (strace output)
>> out.20612:sched_setaffinity(0, 128, {100, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
>> 0, 0, 0, 0}) = 0
>>
>>
>> And proc shows:
>>
>> (cat /proc/nnn/status)
>> Cpus_allowed: 0001
>> Cpus_allowed_list: 0
>>
>>
>> See that the Cpus_allowed bitmask is a single core. Normally it's fff...f.
>
> When I run R I see:
>
> Cpus_allowed:ff
> Cpus_allowed_list:0-7
>
> It's possible (likely?) that the culprit here isn't R but rather some
> other library that R is loading. Are you using OpenBLAS? By default
> OpenBLAS will set an obnoxious cpu mask, unless you override this
> using some obscure build system settings. (There might be a runtime
> option for disabling it too, I don't remember. Note also that this is
> just one of several obnoxious things OpenBLAS does unless you override
> a bunch of obscure build system defaults -- building OpenBLAS
> correctly is highly non-trivial.)
>
> -n
>
> --
> Nathaniel J. Smith
> Postdoctoral researcher - Informatics - University of Edinburgh
> http://vorpus.org
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R process (and forked children via system2) are limited to 1 core?
Hi,
(Using R 3.1.1 on Ubuntu 12.04.4 LTS)
What is the recommended way for R to fork a (non-R) process that is not CPU
limited?
Currently I am using R’s system2() call, and this is inheriting the environment
of the R process.
I notice that (at least on Linux) when I am poking around /proc that the R
process itself is setting up cpu limitations for itself (max 1 core).
Using strace, I see the following:
(strace output)
out.20612:sched_setaffinity(0, 128, {100, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0}) = 0
And proc shows:
(cat /proc/nnn/status)
Cpus_allowed: 0001
Cpus_allowed_list: 0
See that the Cpus_allowed bitmask is a single core. Normally it’s fff…f.
I want my child process (java in this case) not to share this limitation. What
is the recommended way of doing this from R?
Any ideas or suggestions appreciated!
Thanks,
Tom
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R process (and forked children via system2) are limited to 1 core?
Nathaniel, that did the trick. Thanks so much for your help. Tom $ export OPENBLAS_MAIN_FREE=1 $ R $ cat /proc/1538/status | grep Cpus_allowed Cpus_allowed: Cpus_allowed_list: 0-31 On Aug 6, 2014, at 2:41 PM, Nathaniel Smith wrote: > On Wed, Aug 6, 2014 at 10:31 PM, Tom Kraljevic wrote: >> >> Hi Nathaniel, >> >> >> >> Thanks for the suggestion. >> >> Im actually not really using R to do any real work. >> Im starting the R H2O package (a Java machine learning package) and >> forwarding all the work to H2O. >> >> >> >> This is the list of packages I have in R: >> >> >>> search() >> [1] ".GlobalEnv""package:h2o" "package:tools" >> [4] "package:statmod" "package:rjson" "package:RCurl" >> [7] "package:bitops""package:stats" "package:graphics" >> [10] "package:grDevices" "package:utils" "package:datasets" >> [13] "package:methods" "Autoloads" "package:base" >> >> >> And here is the /proc info >> >> tomk@mr-0xb4:~$ ps -efww | grep R | grep tomk >> tomk 8366 13845 1 14:25 pts/000:00:01 /usr/lib/R/bin/exec/R >> tomk 12960 27363 0 14:27 pts/300:00:00 grep --color=auto R >> tomk@mr-0xb4:~$ grep Cpus /proc/8366/status >> Cpus_allowed: 0001 >> Cpus_allowed_list: 0 >> >> >> >> As you can see, my R is super vanilla. I havent configured hardly >> anything. Im just loading a few plain packages. > > My suggestion is just a guess, really, but: R always uses (and thus > loads by default) some underlying C library to implement its core > linear algebra routines. OpenBLAS is one of the libraries that it > might possibly be using, depending on how your R was set up. > > Anyway, it looks like the quick way to check for this particular > possible culprit is to run > > env OPENBLAS_MAIN_FREE=1 R > > and see if that helps. > > -n > > -- > Nathaniel J. Smith > Postdoctoral researcher - Informatics - University of Edinburgh > http://vorpus.org [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R Segfault reported in Fedora 17
Full details, including all sorts of logs here: https://bugzilla.redhat.com/show_bug.cgi?id=857655 A very quick look doesn't show anything obvious, in fact, it might be a readline bug, but readline is remarkably stable and boring these days. ~tom == Fedora Project __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R Segfault reported in Fedora 17
On 09/17/2012 01:55 PM, peter dalgaard wrote: > Very hard to find this sort of bug without reproducibility instructions. I agree, especially if the bug is in readline somewhere. > But the bug report says that it is a SIGABRT, not SIGSEGV. That's a different > kettle of fish isn't it? Yep. It sure is. Just wanted to put in on your radar in case it ends up being helpful. I don't have any real plans to try to dig deeper into it, since this is the first such report (and Fedora has automated mechanisms for reporting crashed apps). ~tom == Fedora Project __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inaccurate complex arithmetic of R (Matlab is accurate)
I checked, and both octave and yorick use multiplication for z^i where i is an integer, leading to better accuracy. Octave uses an integer power if it's stored as a double if it's close enough to an integer. See: http://hg.savannah.gnu.org/hgweb/octave/file/fb22dd5d6242/src/xpow.cc http://yorick.sourcearchive.com/documentation/2.1.01cvs20060706/ops2_8c-source.html - Tom __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Grid Graphics Documentation: color specification with gpar() (PR#14013)
Full_Name: Tom Gottfried Version: 2.9.2 OS: Mac OS X 10.4.11 Submission from: (NULL) (93.104.160.207) Dear R-Developers, on the help page for gpar() is the following paragraph: "Specifying the value NULL for a parameter is the same as not specifying any value for that parameter, except for col and fill, where NULL indicates not to draw a border or not to fill an area (respectively)." The mentioned exception for col and fill does not hold. Actually what is said in the section "Color Specification" on the help page for par() is true also for gpar(): "transparent" and NA specify transparency respectively no drawing. To verify this: grid.newpage() grid.rect(width=.5, height=.5) grid.rect(width=.25, height=.25, gp=gpar(col=NULL)) # draws the box despite col=NULL grid.rect(width=.125, height=.125, gp=gpar(col=NA, fill=2)) # does not draw the box regards, Tom __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug reporting system inquiry plus a bug report related to sort
Is the bug-reporting system working okay? Two days ago, I submitted the following bug report via email to r-b...@r-project.org. I didn't see a confirmation, and it didn't see it at http://bugs.r-project.org/. Now, http://bugs.r-project.org/ seems to be down. Anyway, here's the bug report related to sort.list and sort(..., index.return = TRUE) with na.last = NA I think that both sort.list(x, na.last = NA) and sort(x, na.last = NA, index.return = TRUE)$ix give incorrect answers with na.last. With na.last, both of these return answers equivalent to sort.list(na.omit(x)), and I think they should be the equivalent of order(x, na.last=NA) as follows. > x <- c(1L, 6L, NA, 2L) > order(x, na.last = NA) # right [1] 1 4 2 > sort.list(x, na.last = NA, method = "radix") # wrong, I think [1] 1 3 2 > sort.list(x, na.last = NA, method = "quick") # wrong [1] 1 3 2 > sort(x, na.last = NA, index.return = TRUE)$ix # wrong [1] 1 3 2 I've included a patch for the "radix" and "shell" methods of sort.list. The sort and "quick" method of sort.list (which uses sort) look more challenging. With the patch, I get: > sort.list(x, na.last = NA, method = "radix") # good [1] 1 4 2 > sort.list(x, na.last = NA, method = "shell") # good [1] 1 4 2 > sort.list(x, na.last = NA, method = "quick") # still bad [1] 1 3 2 By the way, having the radix sort is great. It's really fast for factors. - Tom Tom Short Electric Power Research Institute (EPRI) > sessionInfo() R version 2.10.1 (2009-12-14) i386-pc-mingw32 locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Speed of for loops
Hi Everyone,
I have a question about for loops. If you have something like:
f <- function(x) {
y <- rep(NA,10);
for( i in 1:10 ) {
if ( i > 3 ) {
if ( is.na(y[i-3]) == FALSE ) {
# some calculation F which depends on one or
more of the previously
generated values in the series
y[i] = y[i-1]+x[i];
} else {
y[i] <- x[i];
}
}
}
y
}
e.g.
> f(c(1,2,3,4,5,6,7,8,9,10,11,12));
[1] NA NA NA 4 5 6 13 21 30 40
is there a faster way to process this than with a 'for' loop? I have
looked at lapply as well but I have read that lapply is no faster than a
for loop and for my particular application it is easier to use a for loop.
Also I have seen 'rle' which I think may help me but am not sure as I have
only just come across it, any ideas?
Many thanks
Tom
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The c...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Speed of for loops
Thank you all for your advice and tips. In the end, I think the for loop
is the easiest way forward due to other requirements but its good to know
that I haven't missed anything too obvious.
Tom
On Tue, 30 Jan 2007 23:42:27 -, Oleg Sklyar <[EMAIL PROTECTED]> wrote:
> It is surely an elegant way of doing things (although far from being
> easy to parse visually) but is it really faster than a loop?
>
> After all, the indexing problem is the same and sapply simply does the
> same job as for in this case, plus "<<-" will _search_ through the
> environment on every single step. Where is the gain?
>
> Oleg
>
> --
> Dr Oleg Sklyar | EBI-EMBL, Cambridge CB10 1SD, UK | +44-1223-494466
>
>
> Byron Ellis wrote:
>> Actually, why not use a closure to store previous value(s)?
>>
>> In the simple case, which depends on x_i and y_{i-1}
>>
>> gen.iter = function(x) {
>> y = NA
>> function(i) {
>>y <<- if(is.na(y)) x[i] else y+x[i]
>> }
>> }
>>
>> y = sapply(1:10,gen.iter(x))
>>
>> Obviously you can modify the function for the bookkeeping required to
>> manage whatever lag you need. I use this sometimes when I'm
>> implementing MCMC samplers of various kinds.
>>
>>
>> On 1/30/07, Herve Pages <[EMAIL PROTECTED]> wrote:
>>> Tom McCallum wrote:
>>>> Hi Everyone,
>>>>
>>>> I have a question about for loops. If you have something like:
>>>>
>>>> f <- function(x) {
>>>> y <- rep(NA,10);
>>>> for( i in 1:10 ) {
>>>> if ( i > 3 ) {
>>>> if ( is.na(y[i-3]) == FALSE ) {
>>>> # some calculation F which depends on
>>>> one or more of the previously
>>>> generated values in the series
>>>> y[i] = y[i-1]+x[i];
>>>> } else {
>>>> y[i] <- x[i];
>>>> }
>>>> }
>>>> }
>>>> y
>>>> }
>>>>
>>>> e.g.
>>>>
>>>>> f(c(1,2,3,4,5,6,7,8,9,10,11,12));
>>>> [1] NA NA NA 4 5 6 13 21 30 40
>>>>
>>>> is there a faster way to process this than with a 'for' loop? I have
>>>> looked at lapply as well but I have read that lapply is no faster
>>>> than a
>>>> for loop and for my particular application it is easier to use a for
>>>> loop.
>>>> Also I have seen 'rle' which I think may help me but am not sure as I
>>>> have
>>>> only just come across it, any ideas?
>>> Hi Tom,
>>>
>>> In the general case, you need a loop in order to propagate calculations
>>> and their results across a vector.
>>>
>>> In _your_ particular case however, it seems that all you are doing is a
>>> cumulative sum on x (at least this is what's happening for i >= 6).
>>> So you could do:
>>>
>>> f2 <- function(x)
>>> {
>>> offset <- 3
>>> start_propagate_at <- 6
>>> y_length <- 10
>>> init_range <- (offset+1):start_propagate_at
>>> y <- rep(NA, offset)
>>> y[init_range] <- x[init_range]
>>> y[start_propagate_at:y_length] <-
>>> cumsum(x[start_propagate_at:y_length])
>>> y
>>> }
>>>
>>> and it will return the same thing as your function 'f' (at least when
>>> 'x' doesn't
>>> contain NAs) but it's not faster :-/
>>>
>>> IMO, using sapply for propagating calculations across a vector is not
>>> appropriate
>>> because:
>>>
>>> (1) It requires special care. For example, this:
>>>
>>> > x <- 1:10
>>> > sapply(2:length(x), function(i) {x[i] <- x[i-1]+x[i]})
>>>
>>> doesn't work because the 'x' symbol on the left side of the <-
>>> in the
>>> anonymous function doesn't refer to the 'x' symbol defined in
>>> the global
>>> environment. So you need to use tricks like this:
>>>
>>> > sapply(2:length(x),
>>> function(i) {x[i] <- x[i-1]+x[i]; assign("x", x,
>>> envir=.GlobalEnv); x[i]})
>>>
>>> (2) Because of this kind of tricks, then it is _very_ slow (about 10
>>> times
>>> slower or more than a 'for' loop).
>>>
>>> Cheers,
>>> H.
>>>
>>>
>>>> Many thanks
>>>>
>>>> Tom
>>>>
>>>>
>>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The c...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Best Practise
Hello,
Just a quick question on best practise. I am converting quite a bit of
legacy C code into R packages and have the following situation:
(1) Legacy object with a double* array in, all over code so don't want to
change any more than I have to.
(2) Do something like:
SEXP arrayToPassToR;
PROTECT( arrayToPassToR = allocVector( REALSXP, n ) );
for(i=0; i < n; i++) {
REAL(arrayToPassToR)[i] = oldCarray[i]; < very slow way
to copy
data, can I use memcpy/pointer assignment here to remove the loop without
running into garbage collector?
}
UNPROTECT( arrayToPassToR );
SEXP returnValueFromR;
(3) Have made it to call back to an R function which returns a new /
different SEXP double array.
returnValueFromR = Test_tryEval(...);
(4) Copy back to oldCArray
for(i=0; i < n; i++) {
oldCarray[i] = REAL(returnValueFromR)[i]; <--- can I use
memcpy/pointer
assignment here to remove loop?
}
UNPROTECT(1);
I have done the long winded copy as I am a bit paranoid about the garbage
collection. My question is is it legitimate to do the following
double* oldCArray = REAL(arrayToPassToR);
UNPROTECT(1); // where the 1 would remove protection from
arrayToPassToR
and potential garbage collection
-- assume arrayToPassToR was garbage collected by R --
Rprintf("%f", oldCArray[0]);
because if arrayToPassToR is garbage collected then oldCArray will cause a
SEGFAULT when it is accessed afterwards, won't it?
Many thanks
Tom
--
PS Note this is the new email address - delete [EMAIL PROTECTED] as it
won't work soon!
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave/ESS-like tools for HTML
See this link for more on creating/converting to HTML: http://biostat.mc.vanderbilt.edu/twiki/bin/view/Main/SweaveConvert For using ESS with mixed HTML/R files, see this: https://stat.ethz.ch/pipermail/ess-help/2006-December/003826.html - Tom Tom Short Electric Power Research Institute __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] DataTime field when converting between database formats
I was recently converting a MS-Access database to MySQL when I came across this error: Error in fromchar(unclass(x)) : character string is not in a standard unambiguous format The error occurs because the NULL value of a DateTime field, if not properly setup or on export to a CSV, can be set to '-00-00 00:00:00' which fails the NA test in R-2.6.2/src/library/base/R/datetime.R on line 32. Can I recommend that this either raises a more specific error, or that it automatically converts this value to NA and perhaps outputs a warning. For now I have fixed the incoming data, but thought I would register this behaviour in case anyone else came across it. Best, Tom __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Constructing logical expressions dynamically
Hello,
I am trying to construct a logical expression dynamically, for use in the
subset() function. I am puzzled by problems with the code that follows
below.
Probably there's an easier way to select rows of a data frame according to
some dynamic criteria--and I'd love to hear about it--but I'd also like to
understand what I'm doing incorrectly in constructing the expression in my
code.
Thanks in advance,
tm
# These two expressions print the same, at least.
e1 = expression(name == 'a')
e2 = substitute(expression(cname == 'a'), list(cname=as.symbol('name')))
print (e1)
print (e2)
# But they do not evaluate the same!
# This works.
data = data.frame(name=c('a', 'b', 'c', 'a'), age=c(1,2,3,4))
d1 = subset(data, eval(e1))
print (d1)
# This gives the error:
# Error in subset.data.frame(data, eval(e2)) :
# 'subset' must evaluate to logical
d2 = subset(data, eval(e2))
print (d2)
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] RODBC Close Memory Leak Question
Hi everyone,
In relation to the RODBC odbcClose bug which was fixed back in the
changelog below:
Version: 1.2-3 (2008-01-24, released)
* Plug a memory leak in inRODBCClose (closing a connection),
reported by Stephan Henne.
* Use translateChar() on character data sent in.
Background:
I am running some data from a SQL Server database, through unixODBC
(freetds) into R via the RODBC package. If I make many calls to
odbcConnect, perform a query and then close the connection over a period
of time the memory attached appears never to be freed and the process
eventually - say 4 hours into the run - dies due to lack of memory.
Research:
I have created a dummy piece of code which shows the growing memory
allocation shown below. Each call brings back between 20-100 pieces of
data which fits into a one column vector - so not a lot of data. The
varible x is normally returns from a function and used subsequently but
for the purposes of this test I have kept it simple.
library("RODBC")
for( i in 1:100 ) {
conn <- odbcConnect()
<-- anonymised
x <- sqlQuery(conn, "SELECT * FROM table_name"); <--
anonymised
odbcClose(conn);
}
quit()
I am not sure whether the leak is related to this previous bug or if it is
related to the way the garbage collection works, but either way if I run
this piece of code the memory attached to the database handle is never
freed so as I bring back more and more data over a large number of runs my
memory slowly fills up and the application crashes, unable to allocate any
more memory.
Just to make sure I was running the latest and greatest RODBC I installed
it again from source, but the initial installation was only done last
month so I presume .install.packages would have got this latest version
anyway.
Any advice on where to start searching to patch this as it is a real
pain. I have included below version information and the valgrind
output. If this is a new bug I will add it the bug tracker but I wanted
to make sure I was not missing anything blindingly obvious to someone in
the know.
Thanks for your help,
Tom
version
_
platform i686-pc-linux-gnu
arch i686
os linux-gnu
system i686, linux-gnu
status
major 2
minor 7.0
year 2008
month 04
day22
svn rev45424
language R
version.string R version 2.7.0 (2008-04-22)
==8682== Memcheck, a memory error detector.
==8682== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==8682== Using LibVEX rev 1471, a library for dynamic binary translation.
==8682== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==8682== Using valgrind-3.1.0, a dynamic binary instrumentation framework.
==8682== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==8682== For more details, rerun with: -v
==8682==
R version 2.7.0 (2008-04-22)
Copyright (C) 2008 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
library("RODBC")
--8682-- WARNING: unhandled syscall: 311
--8682-- You may be able to write your own handler.
--8682-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
for( i in 1:100 ) {
+ conn <- odbcConnect() <--
anonymised
+ x <- sqlQuery(conn, "SELECT * FROM table_name"); <--
anonymised
+ odbcClose(conn);
+ }
quit()
==8682==
==8682== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 255 from 1)
==8682== malloc/free: in use at exit: 13,470,816 bytes in 6,739 blocks.
==8682== malloc/free: 121,121 allocs, 114,382 frees, 134,084,145 bytes
allocated.
==8682== For counts of detected errors, rerun with: -v
==8682== searching for pointers to 6,739 not-freed blocks.
==8682== checked 13,332,140 bytes.
==8682==
==8682== 56 bytes in 1 blocks are possibly lost in loss record 15 of 55
==8682==at 0x40045EB: calloc (vg_replace_malloc.c:279)
==8682==by 0x805AA60: R_chk_calloc (memory.c:2368)
==8682==by 0x57C89D6: RODBCDriverConnect (RODBC.c:244)
==8682==by 0x8160A68: do_dotcall (dotcode.c:863)
==8682==by 0x81857CE: Rf_eval (eval.c:489)
==8682==by 0x81895B7: do_set (eva
[Rd] RODBC Seg Fault
Hi Everyone,
At the end of this email is a transcript of a problem I have found in
RODBC version 2.3-1. It appears that the bug fix in odbcClose for the
memory leak has meant that the garbage collector is falling over when it
tries to free up the extPtr attribute of the RODBC connection pointer.
Any advice on how to fix this?
Thanks for your help,
Tom
##---
platform i686-pc-linux-gnu
arch i686
os linux-gnu
system i686, linux-gnu
status
major 2
minor 7.1
year 2008
month 06
day23
svn rev45970
language R
version.string R version 2.7.1 (2008-06-23)
##---
Run using the command
$ R -d gdb
##---
Starting program: /usr/local/lib/R/bin/exec/R
R version 2.7.1 (2008-06-23)
Copyright (C) 2008 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
[Previously saved workspace restored]
library("RODBC")
[Thread debugging using libthread_db enabled]
[New Thread -1208248640 (LWP 14060)]
Error while reading shared library symbols:
Cannot find new threads: generic error
gctorture(TRUE)
for(i in 1:10) { print(i); conn <- odbcConnect("***", "***", "***");
print(conn); odbcClose(conn) }
[1] 1
RODB Connection 2
Details:
case=nochange
DSN=***
UID=***
PWD=***
[1] 2
RODB Connection 3
Details:
case=nochange
DSN=***
UID=***
PWD=***
[1] 3
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208248640 (LWP 14060)]
0x08059036 in R_ClearExternalPtr (s=0x0) at memory.c:2445
2445memory.c: No such file or directory.
in memory.c
(gdb) bt
#0 0x08059036 in R_ClearExternalPtr (s=0x0) at memory.c:2445
#1 0x006b17cb in inRODBCClose (thisHandle=0x8c1f358) at RODBC.c:1250
#2 0x006b190d in chanFinalizer (ptr=0x9100380) at RODBC.c:1271
#3 0x0805b6eb in R_RunWeakRefFinalizer (w=0x90da4f8) at memory.c:1062
#4 0x0805b810 in RunFinalizers () at memory.c:1107
#5 0x0805cf17 in R_gc_internal (size_needed=1) at memory.c:2205
#6 0x0805da69 in Rf_allocVector (type=16, length=1) at memory.c:1968
#7 0x006b3955 in RODBCDriverConnect (connection=0x90b0208, id=0x90b0288,
useNRows=0x90b02c8) at RODBC.c:277
#8 0x08161a19 in do_dotcall (call=0x89b9ba8, op=0x85518dc, args=optimized out>, env=0x9100e44) at dotcode.c:863
#9 0x0818683f in Rf_eval (e=0x89b9ba8, rho=0x9100e44) at eval.c:489
#10 0x0818a628 in do_set (call=0x89b9b1c, op=0x8546120, args=optimized out>, rho=0x9100e44) at eval.c:1424
#11 0x08186621 in Rf_eval (e=0x89b9b1c, rho=0x9100e44) at eval.c:463
#12 0x0818737f in do_begin (call=0x89ba260, op=0x8547788, args=0x89b9b00,
rho=0x9100e44) at eval.c:1176
#13 0x08186621 in Rf_eval (e=0x89ba260, rho=0x9100e44) at eval.c:463
#14 0x08188a15 in Rf_applyClosure (call=0x89bbda4, op=0x89bac60,
arglist=0x9100bf8, rho=0x9100a38, suppliedenv=0x855a084) at eval.c:669
#15 0x081864da in Rf_eval (e=0x89bbda4, rho=0x9100a38) at eval.c:507
#16 0x0818737f in do_begin (call=0x89bb90c, op=0x8547788, args=0x89bbd88,
rho=0x9100a38) at eval.c:1176
#17 0x08186621 in Rf_eval (e=0x89bb90c, rho=0x9100a38) at eval.c:463
#18 0x08188a15 in Rf_applyClosure (call=0x8e5bcd0, op=0x89bcc80,
arglist=0x9100894, rho=0x855a068, suppliedenv=0x855a084) at eval.c:669
#19 0x081864da in Rf_eval (e=0x8e5bcd0, rho=0x855a068) at eval.c:507
#20 0x0818a628 in do_set (call=0x8e5ba30, op=0x8546120, args=optimized out>, rho=0x855a068) at eval.c:1424
#21 0x08186621 in Rf_eval (e=0x8e5ba30, rho=0x855a068) at eval.c:463
#22 0x0818737f in do_begin (call=0x8e5991c, op=0x8547788, args=0x8e597e8,
rho=0x855a068) at eval.c:1176
#23 0x08186621 in Rf_eval (e=0x8e5991c, rho=0x855a068) at eval.c:463
#24 0x08189fb3 in do_for (call=0x8e59820, op=0x8536d78, args=0x8e59938,
rho=0x855a068) at eval.c:1075
#25 0x08186621 in Rf_eval (e=0x8e59820, rho=0x855a068) at eval.c:463
#26 0x080587e0 in Rf_ReplIteration (rho=0x855a068, savestack=0,
browselevel=0, state=0xbf833d28) at main.c:257
#27 0x08058b4a in R_ReplConsole (rho=0x855a068, savestack=0,
browselevel=0) at main.c:306
#28 0x08058e28 in run_Rmainloop () at main.c:967
#29 0x08056731 in main (ac=Cannot access memory at address
[Rd] Simple class with an automatic printing issue
I don't understand the following behavior for a simple S3 class. The
auto-printing at the command line
doesn't behave as I expect. I'm probably missing something, but it might be
a bug.
> print.testClass <- function(x, ...) cat("Class:", class(x), ":", x, "\n")
> structure(1, class = "testClass")
Class: testClass : 1
> print(1 * structure(1, class = "testClass"))
Class: testClass : 1
> 1 * structure(1, class = "testClass") # why doesn't auto-printing call
print.testClass here?
[1] 1
attr(,"class")
[1] "testClass"
> structure(1, class = "testClass") * 1
Class: testClass : 1
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status RC
major 2
minor 9.0
year 2009
month 04
day10
svn rev48318
language R
version.string R version 2.9.0 RC (2009-04-10 r48318)
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Simple class with an automatic printing issue
Thanks, Bill. Searching R-devel based on your input shows that this is
a known issue as pointed out by Martin Maechler:
https://stat.ethz.ch/pipermail/r-devel/2008-October/051109.html
- Tom
On Sun, Apr 12, 2009 at 11:34 PM, William Dunlap wrote:
>
> It may have to do with the results of is.object():
>
> > is.object(1*structure(1,class="testClass"))
> [1] FALSE
> > is.object(structure(1,class="testClass")*1)
> [1] TRUE
> > is.object(structure(1,class="testClass"))
> [1] TRUE
>
> is.object(x) should be true if x has a class attribute,
> but 1*structute(1,class="testClass") makes a thing
> with a class attribute but without the 'OBJECT' bit set.
>
> Bill Dunlap
> TIBCO Software Inc - Spotfire Division
> wdunlap tibco.com
>
> > -Original Message-
> > From: r-devel-boun...@r-project.org
> > [mailto:r-devel-boun...@r-project.org] On Behalf Of Tom Short
> > Sent: Sunday, April 12, 2009 4:00 PM
> > To: r-devel@r-project.org
> > Subject: [Rd] Simple class with an automatic printing issue
> >
> > I don't understand the following behavior for a simple S3 class. The
> > auto-printing at the command line
> > doesn't behave as I expect. I'm probably missing something,
> > but it might be
> > a bug.
> >
> > > print.testClass <- function(x, ...) cat("Class:", class(x),
> > ":", x, "\n")
> >
> > > structure(1, class = "testClass")
> > Class: testClass : 1
> >
> > > print(1 * structure(1, class = "testClass"))
> > Class: testClass : 1
> >
> > > 1 * structure(1, class = "testClass") # why doesn't
> > auto-printing call
> > print.testClass here?
> > [1] 1
> > attr(,"class")
> > [1] "testClass"
> >
> > > structure(1, class = "testClass") * 1
> > Class: testClass : 1
> >
> >
> > platform i386-pc-mingw32
> > arch i386
> > os mingw32
> > system i386, mingw32
> > status RC
> > major 2
> > minor 9.0
> > year 2009
> > month 04
> > day 10
> > svn rev 48318
> > language R
> > version.string R version 2.9.0 RC (2009-04-10 r48318)
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Memory problems with a custom R package
Hi everyone,
I have been attempting to build a very simple R package interfacing with
some very simple C++ code. Everything I try though results in the
function working but on return it produces a memory error. Here is the
output:
***OUTPUT***
> library(MyPackage)
> hello();
*** caught segfault ***
address 0x3, cause 'memory not mapped'
**END OUTPUT*
I have read that some time this occurs because it cannot find the function
in the shared library but I have tested this theory with a simple text
message and this is displayed but again the memory error occurs.
The C++ code has been reduced to the simplest possible:
*** helloworld.h
extern "C" void helloworld(void);
*** helloworld.cpp
#include
#include "helloworld.h"
void helloworld(void) {
// This was my test line that was displayed as described above.
// std::cout << "My first R Package Test." << std::endl;
}
I also wrote an R wrapper called hello as follows:
*** helloworld.R
hello <- function()
{
.Call("helloworld", PACKAGE="MyPackage");
}
The namespaces file (NAMESPACE) is as follows:
useDynLib(MyPackage)
export(hello)
I have compared mine against other package sources available that do the
same thing and cannot find the key difference.
Thank you for your help in advance,
Tom
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] time_t handling in R
Hello all, I am converting some C code into a package for R and wondered what the proper way of handling time_t types from C in R was. time_t is a typedef for long, but R seems to only deal in Integers or Reals, so what is the proper way of handling time in an R to C conversion ( or visa versa )? Many thanks Tom -- Thomas McCallum Systems Architect LevelE Limited Phone: 0131 - 4724813 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Cross-compilation
Hi everyone, I am trying to cross-compile a package I wrote using the Yan and Rossini tutorial "Building Microsoft Windows versions of R and R packages using Intel Linux". I have got reasonably far with this but when doing the linking using the line: i586-mingw32-g++ -shared -s -o mylibrary.dll mylibrary.def mylibrary.o mylibrary_res.o -L/my/path/RCrossBuild/WinR/R-2.4.0/bin -lR I get lots of these type of messages: /my/path/to/mylibrary.cpp:43: undefined reference to `_GLOBAL_OFFSET_TABLE_' and other similar linker errors for virtually every object and command in the program. After some googling I have found that there may be problems with the libgcc.a library and its default -fPIC argument during compilation. Has anyone got this tutorial to work and if so how did they overcome this? I am attempting to do this on Fedora Core 4 on a 32-bit machine, having completed all the previous sections of the tutorial for building a cross-platform version of R. Many thanks Tom -- --- Tom McCallum WWW: http://www.tom-mccallum.com Tel: 0131-4783393 Mobile: 07866-470257 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Cross-compilation
Thanks for your reply, as an example it appears to have difficulty linking to even ostream library of the standard C++, as shown below: /home/tmccallum/ritzel/RItzel/src/Classifier.cpp:209: undefined reference to `_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc' Classifier.o: In function `operator<<': /usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/ostream:218: undefined reference to `_ZNSolsEd' /usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/ostream:196: undefined reference to `_ZNSolsEl' I am currently working R-2.4.0 as downloaded today. I know the g++ has gone through some alterations and wondered if you knew the version of g++ you cross-compiled your package with for comparison - mine is g++ (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8). Many thanks Tom On Wed, 25 Oct 2006 18:10:40 +0100, Ramon Diaz-Uriarte <[EMAIL PROTECTED]> wrote: > Dear Tom, > > It has worked for me out-of-the box in at least two times, one a while > ago > with R-2.2-something and recently with R-2.4.0. In both cases, I was > running > Debian (with a mix of testing and unstable) on x86. I never had to do > anything, just run the script and at least in one case I did > crosscompile a > package with C++. > > > R. > > On Wednesday 25 October 2006 18:03, Tom McCallum wrote: >> Hi everyone, >> >> I am trying to cross-compile a package I wrote using the Yan and Rossini >> tutorial "Building Microsoft Windows versions of R and R packages using >> Intel Linux". I have got reasonably far with this but when doing the >> linking using the line: >> >> i586-mingw32-g++ -shared -s -o mylibrary.dll mylibrary.def mylibrary.o >> mylibrary_res.o -L/my/path/RCrossBuild/WinR/R-2.4.0/bin -lR >> >> I get lots of these type of messages: >> /my/path/to/mylibrary.cpp:43: undefined reference to >> `_GLOBAL_OFFSET_TABLE_' >> >> and other similar linker errors for virtually every object and command >> in >> the program. After some googling I have found that there may be >> problems >> with the libgcc.a library and its default -fPIC argument during >> compilation. >> >> Has anyone got this tutorial to work and if so how did they overcome >> this? >> >> I am attempting to do this on Fedora Core 4 on a 32-bit machine, having >> completed all the previous sections of the tutorial for building a >> cross-platform version of R. >> >> Many thanks >> >> Tom > -- --- Tom McCallum WWW: http://www.tom-mccallum.com Tel: 0131-4783393 Mobile: 07866-470257 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Overloading functions
Hi Everyone
I have a function f which does something using a function g. Function f
is in a library and g has a default stub in the library but will be mainly
overloaded in a later R script. For example:
## In a compiled package 'P' #
g <- function() {
cat("Original function g");
}
f <- function( newGsource=NULL ) {
if( is.null(newGsource) == FALSE ) {
source( newGsource ); # load new function g
}
g();
return(1);
}
#
If I call f() then I get "Original function g".
But I want to overload g so I do the following in the file newg.R:
### CONTENTS of newg.R ##
g <- function() {
cat("New function g in newg.R");
}
END CONTENTS ###
and call f( newGsource="newg.R" ) but I still get "Original function g".
Any suggestions?
Tom
--
---
Tom McCallum
WWW: http://www.tom-mccallum.com
Tel: 0131-4783393
Mobile: 07866-470257
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Overloading functions
On Fri, 27 Oct 2006 14:49:15 +0100, Paul Roebuck <[EMAIL PROTECTED]>
wrote:
> On Fri, 27 Oct 2006, Tom McCallum wrote:
>
>> I have a function f which does something using a function g. Function f
>> is in a library and g has a default stub in the library but will be
>> mainly
>> overloaded in a later R script. For example:
>>
>> ## In a compiled package 'P' #
>> g <- function() {
>> cat("Original function g");
>> }
>>
>> f <- function( newGsource=NULL ) {
>> if( is.null(newGsource) == FALSE ) {
>> source( newGsource ); # load new function g
>> }
>> g();
>> return(1);
>> }
>> #
>>
>> If I call f() then I get "Original function g".
>>
>> But I want to overload g so I do the following in the file newg.R:
>>
>> ### CONTENTS of newg.R ##
>> g <- function() {
>> cat("New function g in newg.R");
>> }
>> END CONTENTS ###
>>
>> and call f( newGsource="newg.R" ) but I still get "Original function g".
>>
>> Any suggestions?
>
> ?environment
>
> --
> SIGSIG -- signature too long (core dumped)
>
>
Thanks for that, have almost figured out how to do it, have got my
namespace but when I "assign" the new value
I get "cannot change value of a locked binding". Is there any way to say
that a particular item in a package
is able to be overridden using assign?
I assume when I export a function in the NAMESPACE file it is locking the
value to the name. So I assume it is here I need
to change something - if this is even possible to do.
Cheers
Tom
--
---
Tom McCallum
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Overloading functions
On Fri, 27 Oct 2006 15:54:40 +0100, Tom McCallum <[EMAIL PROTECTED]>
wrote:
> On Fri, 27 Oct 2006 14:49:15 +0100, Paul Roebuck <[EMAIL PROTECTED]>
> wrote:
>
>> On Fri, 27 Oct 2006, Tom McCallum wrote:
>>
>>> I have a function f which does something using a function g. Function
>>> f
>>> is in a library and g has a default stub in the library but will be
>>> mainly
>>> overloaded in a later R script. For example:
>>>
>>> ## In a compiled package 'P' #
>>> g <- function() {
>>> cat("Original function g");
>>> }
>>>
>>> f <- function( newGsource=NULL ) {
>>> if( is.null(newGsource) == FALSE ) {
>>> source( newGsource ); # load new function g
>>> }
>>> g();
>>> return(1);
>>> }
>>> #
>>>
>>> If I call f() then I get "Original function g".
>>>
>>> But I want to overload g so I do the following in the file newg.R:
>>>
>>> ### CONTENTS of newg.R ##
>>> g <- function() {
>>> cat("New function g in newg.R");
>>> }
>>> END CONTENTS ###
>>>
>>> and call f( newGsource="newg.R" ) but I still get "Original function
>>> g".
>>>
>>> Any suggestions?
>>
>> ?environment
>>
>> --
>> SIGSIG -- signature too long (core dumped)
>>
>>
>
> Thanks for that, have almost figured out how to do it, have got my
> namespace but when I "assign" the new value
> I get "cannot change value of a locked binding". Is there any way to say
> that a particular item in a package
> is able to be overridden using assign?
>
> I assume when I export a function in the NAMESPACE file it is locking the
> value to the name. So I assume it is here I need
> to change something - if this is even possible to do.
>
> Cheers
>
> Tom
>
found the use of assignInNamespace - done!
Thanks for your help.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] variable problem
Hi everyone,
I am not sure this is possible so I would be interested in your
responses. Say I have a variable 'v' with the string "myargument" in and
I have a function 'f' that takes this argument as follows;
f <- function( myargument=5 ) {
... does something...
}
Is there anyway I can say something like;
f( v=10 ) such that it will be evaluated as f( myargument=10 ).
I presume there may be some use eval and substitute but if someone could
point me in the right direction then that would be great.
The end idea is to have a list of m items, declared somewhere else, which
can be evaluated as particular arguments named after their list names
e.g
mylist <- list( "a"=1, "b"=2, "c"=3 )
which can be passed to a function taking arguments a,b, or c and it will
be able to evaluate them accordingly :
long hand this would evaluate to something like
f( a=mylist[["a"]] );
f( b=mylist[["b"]] );
f( c=mylist[["c"]] );
but I would have actually rewritten something like
for ( myvar in names( mylist ) ) {
f( some_clever_substitution_to_act_as_argument(myvar) =
mylist[[ myvar
]] );
}
I hope I have explained myself clearly enough, if not please say so and I
will try and give a better example.
Many thanks for your help
Tom
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The contents of
this e-mail are privileged and/or confidential. If you are not the
intended recipient, please
notify the sender and ensure this e-mail is deleted and not read, copied
or disclosed. It is your responsibility to scan this e-mail and any
attachments for
computer viruses or other defects. Level E does not accept liability for
any loss or damage which may result from this e-mail or any attachment.
E-mail is not secure
and can be intercepted, corrupted or amended. Level E does not accept
liability for errors or omissions arising as a result of interrupted or
defective transmission.
Any views, opinions, conclusions or other information in this e-mail which
do not relate to the business of Level E Limited are not authorised by
Level E. Unless
specifically stated and authorised by Level E, nothing in this e-mail
shall be taken to be an offer or acceptance of any contract of any nature.
E-mail entering or leaving Level E's system is subject to random
monitoring and recording.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] variable problem
Works like a charm - thank you very much.
Tom
On Tue, 07 Nov 2006 20:45:04 -, Vladimir Dergachev
<[EMAIL PROTECTED]> wrote:
> On Tuesday 07 November 2006 3:28 pm, Tom McCallum wrote:
>> Hi everyone,
>
> Hi Tom,
>
> Would this snippet work:
>
> for(i in 1:length(mylist))do.call(f, mylist[i])
>
> On the other hand it is not easy to see why you would want to call
> the
> same function with differently named arguments - perhaps what you are
> really
> trying to do has a different (and better) solution ?
>
>best
>
> Vladimir Dergachev
>
>>
>> I am not sure this is possible so I would be interested in your
>> responses. Say I have a variable 'v' with the string "myargument" in
>> and
>> I have a function 'f' that takes this argument as follows;
>>
>> f <- function( myargument=5 ) {
>>... does something...
>> }
>>
>> Is there anyway I can say something like;
>>
>> f( v=10 ) such that it will be evaluated as f( myargument=10 ).
>>
>> I presume there may be some use eval and substitute but if someone could
>> point me in the right direction then that would be great.
>>
>> The end idea is to have a list of m items, declared somewhere else,
>> which
>> can be evaluated as particular arguments named after their list names
>>
>> e.g
>>
>> mylist <- list( "a"=1, "b"=2, "c"=3 )
>>
>> which can be passed to a function taking arguments a,b, or c and it will
>> be able to evaluate them accordingly :
>>
>> long hand this would evaluate to something like
>> f( a=mylist[["a"]] );
>> f( b=mylist[["b"]] );
>> f( c=mylist[["c"]] );
>>
>> but I would have actually rewritten something like
>> for ( myvar in names( mylist ) ) {
>> f( some_clever_substitution_to_act_as_argument(myvar) =
>> mylist[[ myvar
>> ]] );
>> }
>>
>> I hope I have explained myself clearly enough, if not please say so and
>> I
>> will try and give a better example.
>>
>> Many thanks for your help
>>
>> Tom
>
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The contents of
this e-mail are privileged and/or confidential. If you are not the
intended recipient, please
notify the sender and ensure this e-mail is deleted and not read, copied
or disclosed. It is your responsibility to scan this e-mail and any
attachments for
computer viruses or other defects. Level E does not accept liability for
any loss or damage which may result from this e-mail or any attachment.
E-mail is not secure
and can be intercepted, corrupted or amended. Level E does not accept
liability for errors or omissions arising as a result of interrupted or
defective transmission.
Any views, opinions, conclusions or other information in this e-mail which
do not relate to the business of Level E Limited are not authorised by
Level E. Unless
specifically stated and authorised by Level E, nothing in this e-mail
shall be taken to be an offer or acceptance of any contract of any nature.
E-mail entering or leaving Level E's system is subject to random
monitoring and recording.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Retrieving function name
Hi,
Does anyone know how I can retrieve a function name, for example
If I have a function f as follows:
f <- function( myfunc ) {
print( name_of(myfunc) );
}
I want to know what I should have as "name_of" such that I could call this
with :
f( median )
and it would print "median"
or f( my_function_name ) and it would print "m_function_name".
So far all I can get is the function definition that myfunc points to.
I thought the structure command might do it but this also just gives back
the function definition and not the original name.
Any suggestions?
Tom
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The contents of
this e-mail are privileged and/or confidential. If you are not the
intended recipient, please
notify the sender and ensure this e-mail is deleted and not read, copied
or disclosed. It is your responsibility to scan this e-mail and any
attachments for
computer viruses or other defects. Level E does not accept liability for
any loss or damage which may result from this e-mail or any attachment.
E-mail is not secure
and can be intercepted, corrupted or amended. Level E does not accept
liability for errors or omissions arising as a result of interrupted or
defective transmission.
Any views, opinions, conclusions or other information in this e-mail which
do not relate to the business of Level E Limited are not authorised by
Level E. Unless
specifically stated and authorised by Level E, nothing in this e-mail
shall be taken to be an offer or acceptance of any contract of any nature.
E-mail entering or leaving Level E's system is subject to random
monitoring and recording.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] String to list and visa versa
Hi, I need to collapse a list into a string and then reparse it back into the list. Normally when I need to do this I simply use write.csv and read.csv, but I need to do this in memory within R rather than writing out to file. Are there any bespoke commands that any knows of that does something like this or any tips for doing this that anyone can suggest? I basically don't care upon the string representation, only that I can manipulate the list as a string and then reparse it back to a valid list object. Many thanks for your help, Tom -- Dr. Thomas McCallum Systems Architect, Level E Limited ETTC, The King's Buildings Mayfield Road, Edinburgh EH9 3JL, UK Work +44 (0) 131 472 4813 Fax: +44 (0) 131 472 4719 http://www.levelelimited.com Email: [EMAIL PROTECTED] Level E is a limited company incorporated in Scotland. The contents of this e-mail are privileged and/or confidential. If you are not the intended recipient, please notify the sender and ensure this e-mail is deleted and not read, copied or disclosed. It is your responsibility to scan this e-mail and any attachments for computer viruses or other defects. Level E does not accept liability for any loss or damage which may result from this e-mail or any attachment. E-mail is not secure and can be intercepted, corrupted or amended. Level E does not accept liability for errors or omissions arising as a result of interrupted or defective transmission. Any views, opinions, conclusions or other information in this e-mail which do not relate to the business of Level E Limited are not authorised by Level E. Unless specifically stated and authorised by Level E, nothing in this e-mail shall be taken to be an offer or acceptance of any contract of any nature. E-mail entering or leaving Level E's system is subject to random monitoring and recording. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] String to list and visa versa
On Wed, 15 Nov 2006 05:00:28 -, Prof Brian Ripley
<[EMAIL PROTECTED]> wrote:
> On Tue, 14 Nov 2006, Vladimir Dergachev wrote:
>
>> On Tuesday 14 November 2006 12:28 pm, Prof Brian Ripley wrote:
>>> This approach won't work in very many cases (but then nor will
>>> write.csv).
>>>
>>> The safest way I know is to use serialize() and unserialize(). Next to
>>> that, deparse(control="all") and parse(text=) are quite good and give a
>>> human-readable character representation.
>>>
>>> If fidelity is not the main issue, as.character and toString spring to
>>> mind. unlist is recursive, and is not going to come close to being
>>> faithful for other than very simple lists. And what if ',' is a
>>> character
>>> in one of the list elements?
>>
>> Yes, but then one can replace ',' with something rarely used like \007.
>> I picked ',' because write.csv/read.csv worked before.
>
> But it quotes strings
>
>> You are right, for storage serialize/unserialize seem best, however for
>> manipulation one would usually prefer a well-defined format.
>
>
Thanks for the information, I think I am going to use the
serialize/unserialize methods, which will mean I can't manipulate them
outside R, but I can alter other parts of the project to accomodate this.
Tom
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The c...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Manipulating R lists in C
Hi,
I have been studying the R manual on lists but cannot seem to create a
simple R list in C - I keep on getting "'dimnames' applied to non-array"
whenever I attempt to assign names to the list elements:
Wanted output a list structure something like
[ type="Bid", price=2.0, volume=1000 ]
I can get up to a list of
[ "Bid2, 2.0, 1000 ]
But for the life of me I can't assign the names to the list items - any
suggestions?
Below is what I already have - any comments on things I don't really need
to do as well in terms of creating extra string objects etc are also
helpful.
Many thanks
Tom
==EXTRACT=
SEXP typeStr, volumeStr, priceStr, typeValStr;
SEXP priceList;
// create main list of vectors (unspecific items )
PROTECT( priceList = allocVector( VECSXP, 3 ) );
// for each item create a label and attach value
PROTECT( typeValStr = allocVector( STRSXP, 1 ) );
SET_STRING_ELT( typeValStr, 0,
mkChar( getPriceDataTypeAsString( p.getData().getType() ).c_str() ) );
SET_STRING_ELT( priceList, 0, typeValStr) ;
SEXP priceSXP;
PROTECT( priceSXP = allocVector( REALSXP, 1) );
REAL(priceSXP)[0] = p.getData().getPrice();
SET_VECTOR_ELT( priceList, 1, priceSXP);
SEXP volumeSXP;
PROTECT( volumeSXP = allocVector( REALSXP, 1 ) );
REAL(volumeSXP)[0] = p.getData().getVolume();
SET_VECTOR_ELT( priceList, 2, volumeSXP);
WORKS UP TO HERE*
// add the names of the list items (type,price,volume)
SEXP dimnames;
PROTECT( dimnames = allocVector( VECSXP, 3 ) );
// first create string objects
PROTECT( typeStr = allocVector( STRSXP,1 ) );
SET_STRING_ELT( typeStr, 0, mkChar("type") );
PROTECT( priceStr = allocVector( STRSXP,1 ) );
SET_STRING_ELT( priceStr, 0, mkChar("price") );
PROTECT( volumeStr = allocVector( STRSXP,1 ) );
SET_STRING_ELT( volumeStr, 0, mkChar("volume") );
// assign string objects to vector
SET_VECTOR_ELT( dimnames, 0, typeStr );
SET_VECTOR_ELT( dimnames, 1, priceStr);
SET_VECTOR_ELT( dimnames, 2, volumeStr );
// assign vector to original list of data
setAttrib( priceList, R_DimNamesSymbol, dimnames ); <- I think this
is wrong but I don;t know what it should be
===END EXTRACT===
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The c...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Manipulating R lists in C
Thank you so much!! - that works now.
Tom
On Fri, 17 Nov 2006 14:40:38 -, Roger Bivand <[EMAIL PROTECTED]>
wrote:
> On Fri, 17 Nov 2006, Tom McCallum wrote:
>
>> Hi,
>>
>> I have been studying the R manual on lists but cannot seem to create a
>> simple R list in C - I keep on getting "'dimnames' applied to non-array"
>> whenever I attempt to assign names to the list elements:
>
> Maybe:
>
>setAttrib( priceList, R_NamesSymbol, dimnames );
>
> why should a list have dimnames?
>
> In addition, your dimnames is a list, and likely ought to be a character
> vector. That way you can get away with many fewer PROTECT().
>
> Roger
>
>>
>> Wanted output a list structure something like
>> [ type="Bid", price=2.0, volume=1000 ]
>>
>> I can get up to a list of
>> [ "Bid2, 2.0, 1000 ]
>>
>> But for the life of me I can't assign the names to the list items - any
>> suggestions?
>>
>> Below is what I already have - any comments on things I don't really
>> need
>> to do as well in terms of creating extra string objects etc are also
>> helpful.
>>
>> Many thanks
>>
>> Tom
>>
>>
>> ==EXTRACT=
>>
>>
>>SEXP typeStr, volumeStr, priceStr, typeValStr;
>>SEXP priceList;
>>
>>// create main list of vectors (unspecific items )
>>PROTECT( priceList = allocVector( VECSXP, 3 ) );
>>
>>// for each item create a label and attach value
>>PROTECT( typeValStr = allocVector( STRSXP, 1 ) );
>>SET_STRING_ELT( typeValStr, 0,
>> mkChar( getPriceDataTypeAsString( p.getData().getType() ).c_str() ) );
>>SET_STRING_ELT( priceList, 0, typeValStr) ;
>>
>>SEXP priceSXP;
>>PROTECT( priceSXP = allocVector( REALSXP, 1) );
>>REAL(priceSXP)[0] = p.getData().getPrice();
>>SET_VECTOR_ELT( priceList, 1, priceSXP);
>>
>>SEXP volumeSXP;
>>PROTECT( volumeSXP = allocVector( REALSXP, 1 ) );
>>REAL(volumeSXP)[0] = p.getData().getVolume();
>>SET_VECTOR_ELT( priceList, 2, volumeSXP);
>>
>>WORKS UP TO HERE*
>>
>>// add the names of the list items (type,price,volume)
>>SEXP dimnames;
>>PROTECT( dimnames = allocVector( VECSXP, 3 ) );
>>
>>// first create string objects
>>PROTECT( typeStr = allocVector( STRSXP,1 ) );
>>SET_STRING_ELT( typeStr, 0, mkChar("type") );
>>
>>PROTECT( priceStr = allocVector( STRSXP,1 ) );
>>SET_STRING_ELT( priceStr, 0, mkChar("price") );
>>
>>PROTECT( volumeStr = allocVector( STRSXP,1 ) );
>>SET_STRING_ELT( volumeStr, 0, mkChar("volume") );
>>
>>// assign string objects to vector
>>SET_VECTOR_ELT( dimnames, 0, typeStr );
>>SET_VECTOR_ELT( dimnames, 1, priceStr);
>>SET_VECTOR_ELT( dimnames, 2, volumeStr );
>>
>>// assign vector to original list of data
>>setAttrib( priceList, R_DimNamesSymbol, dimnames ); <- I think
>> this
>> is wrong but I don;t know what it should be
>>
>> ===END EXTRACT===
>>
>>
>
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The c...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Data table in C
After getting one list done, I am now struggling to form a data frame in C.
I tried to do a list of lists which gives me :
$
$[[1]]
[1] "BID"
$[[2]]
[1] 0.6718
$[[3]]
[1] 3e+06
$
$[[1]]
[1] "BID"
$[[2]]
[1] 0.6717
$[[3]]
[1] 5e+06
$
$[[1]]
[1] "BID"
$[[2]]
[1] 0.6717
$[[3]]
[1] 1720
and then as.data.frame them in R but this gives me
> print(l);
X0.type X0.price X0.volume X1.type X1.price X1.volume X2.type X2.price
1 BID 0.6723 3e+06 BID 0.6722 5e+06 BID 0.67195
X2.volume X3.type X3.price X3.volume X4.type X4.price X4.volume X5.type
1 1940 BID 0.6723 3e+06 BID 0.6722 5e+06 BID
X5.price X5.volume X6.type X6.price X6.volume X7.type X7.price X7.volume
1 0.6723 3e+06 BID 0.6723 3e+06 BID 0.67195 1940
X8.type X8.price X8.volume X9.type X9.price X9.volume X10.type X10.price
1 BID 0.6723 3e+06 BID 0.67215 1e+07 BID0.6723
X10.volume X11.type X11.price X11.volume X12.type X12.price X12.volume
1 5e+06 BID 0.67215 1e+07 BID0.6723 3e+06
and so on.
Is the only way in C to do this or is there a better way of creating a 2
dimensional data frame with names columns? I could not find a
"data.frame" object so I assume one has to use lists but I can't see how
to get a 3 column list as the example below shows:
a b d
1 1 4 7
2 2 5 8
3 3 6 9
Tom
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The c...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dyn.load
To answer my own question - you can use DllMain with Rwin_fpset() to get
around this error message.
Am still struggling though as it crashes when it tries to call a function
in the wrapped DLL - any ideas on how to debug this?
Hope this is of help to some one
Tom
On Tue, 21 Nov 2006 17:30:56 -, Tom McCallum
<[EMAIL PROTECTED]> wrote:
> Hi everyone,
>
> Now I know there is information on this in the help files - which I have
> read. I am very close to implementing this but can't quite get how to
> remove this final hurdle.
>
> I have a DLL called "X.DLL" which I have no original code for, just the
> DLL.
> I have created a wrapper C file for the calls in X.DLL, and have
> successfully (I think) created a wrapper DLL for X called, lets say,
> WRAPX.DLL.
>
> On performing:
>
>> dyn.load("WRAPX.dll")
>
> in the Rgui terminal, I then received this warning:
>
> Warning message:
> DLL attempted to change FPU control word from 8001f to 9001f
>
> Getting rid of this error was part of the reason for writing WRAPX.DLL,
> as
> X.DLL seems to play about with this register.
>
> So having another look at the manual entry, I then used the function
> Rwin_fpset() (in gnuwin32/extra.c) to reset the FPU control register when
> I leave all the functions in WRAPX.DLL. But the problem persists. In
> the
> Delphi example in the manual, which I have put at the end of this
> message,
> ( and I have never programmed in Delphi before so I am guessing ) there
> is
> the opportunity on loading the dynamic library to set this register, but
> I
> am wondering where in the C file I can put this command so that when
> dyn.load is called it is not upset by X.DLL changing this register. I
> think I need the following passage of play to occur:
>
> USER : > dyn.load("WRAPX.DLL");
> R : Calls WRAPX.DLL
> WRAPX.DLL : WRAPX.DLL initialises X.DLL which interferes with FPU
> register
> WRAPX.DLL : Calls Rwin_fpset() to reset FPU register
> R : R tests FPU register and is happy
> USER : Sees "Success library is loaded!" or something to that effect
> :)
>
> Any ideas on how to achieve this?
>
> Many thanks
>
> Tom
>
> DELPHI CODE=
>
> procedure Rwin_fpset; cdecl; external 'R.dll';
>
> function Get8087CW:word;
> begin
>asm
> fstcw result
>end;
> end;
>
> begin
>Rwin_fpset(); <== these lines I think is called on
> loading
> of the DLL to reset the register
>Set8087CW(Get8087CW); <
> end.
>
> ===END DELPHI CODE=
>
>
>
> --
> Dr. Thomas McCallum
> Systems Architect,
> Level E Limited
> ETTC, The King's Buildings
> Mayfield Road,
> Edinburgh EH9 3JL, UK
> Work +44 (0) 131 472 4813
> Fax: +44 (0) 131 472 4719
> http://www.levelelimited.com
> Email: [EMAIL PROTECTED]
>
> Level E is a limited company incorporated in Scotland. The
> c...{{dropped}}
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The c...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Ralloc clash
Hi everyone,
Have been trying to include windows.h (from MinGW) and R.h into a package
and have found that Ralloc is coming up as a clash no matter which include
ordering I use. In windows it has 2 arguments and is defined in objidl.h
and in R.h it is 3 arguments. Any ideas of how to work round this? Have
checked the web and have not seen anyone else comment on this.
Many thanks
Tom
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The c...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Ralloc clash
Thank you for your reply. My mistake - I meant Realloc (missed the 'e').
This morning I reinstalled MinGW with all the patches suggested by the
Install R on Windows Help page, including w32api-3.7, just to make sure
all was as it should be. I have put
#define WIN32_LEAN_AND_MEAN
at the top of my cpp file (which I did not know about so that was
interesting) but it is still saying there is a conflict between Realloc in
objidl.h and windows.h. Interesting I had a C file which I _did_ manage
to compile with the R.h and windows.h file in without this error coming
up. Could there be something going on with g++ that gcc is ignoring? I
am no sure it iss a clash now as I cannot find Realloc in the R includes
but below is some output I have gathered which may be of assistance.
In objidl.h (line 532):
STDMETHOD_(void*,Realloc)(THIS_ void*,ULONG) PURE;
In R.h it has the solitary line:
/* for PROBLEM ... Calloc, Realloc, Free, Memcpy, F77_ */
Can only find a R_alloc but no Realloc.
==ERROR MSG OUTPUT==
$ R CMD SHLIB callcdeclcall.cpp
making callcdeclcall.d from callcdeclcall.cpp
In file included from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/objbase.h:73,
from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/ole2.h:9,
from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/windows.h:111,
from callcdeclcall.cpp:4:
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/objidl.h:532:45:
macro "Realloc" requires 3 arguments, but only 2 given
make: *** [callcdeclcall.d] Error 1
==END ERROR MSG OUTPUT==
Headers in CPP file are:
#include
#include
#include
#include
#include
Thanks,
Tom
On Wed, 22 Nov 2006 21:21:15 -, Prof Brian Ripley
<[EMAIL PROTECTED]> wrote:
> Where exactly did you get windows.h from? The recommended source is
> w32api-3.7.tar.gz, and there is no Ralloc in any of its header files,
> including objidl.h.
>
> BTW, do you know about defining WIN32_LEAN_AND_MEAN when including
> windows.h? If not, it is worth finding out about.
>
>
> On Wed, 22 Nov 2006, Tom McCallum wrote:
>
>> Hi everyone,
>>
>> Have been trying to include windows.h (from MinGW) and R.h into a
>> package
>> and have found that Ralloc is coming up as a clash no matter which
>> include
>> ordering I use. In windows it has 2 arguments and is defined in
>> objidl.h
>> and in R.h it is 3 arguments. Any ideas of how to work round this?
>> Have
>> checked the web and have not seen anyone else comment on this.
>
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The c...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Ralloc clash
But from R_ext/RS.h you have (my comments are given by <-- some text):
BEGIN
EXTRACT
#ifndef STRICT_R_HEADERS
<-- fair enough this is defined but it
ends ...
#define R_PROBLEM_BUFSIZE 4096
/* Parentheses added for FC4 with gcc4 and -D_FORTIFY_SOURCE=2 */
#define PROBLEM {char
R_problem_buf[R_PROBLEM_BUFSIZE];(sprintf)(R_problem_buf,
#define MESSAGE {char
R_problem_buf[R_PROBLEM_BUFSIZE];(sprintf)(R_problem_buf,
#define ERROR ),error(R_problem_buf);}
#define RECOVER(x) ),error(R_problem_buf);}
#define WARNING(x) ),warning(R_problem_buf);}
#define LOCAL_EVALUATOR /**/
#define NULL_ENTRY /**/
#define WARNWARNING(NULL)
#endif
<-- ifndef clause ends here
/* S Like Memory Management */
extern void *R_chk_calloc(size_t, size_t);
extern void *R_chk_realloc(void *, size_t);
extern void R_chk_free(void *);
#define Calloc(n, t) (t *) R_chk_calloc( (size_t) (n), sizeof(t) )
#define Realloc(p,n,t) (t *) R_chk_realloc( (void *)(p), (size_t)((n) *
sizeof(t)) ) <-- This is still defined therefore, is it not?
/* S-PLUS 3.x but not 5.x NULLs the pointer in the following */
#ifndef STRICT_R_HEADERS
#define Free(p)(R_chk_free( (void *)(p) ), (p) = NULL)
#endif
#define R_Free(p) (R_chk_free( (void *)(p) ), (p) = NULL)
#define Memcpy(p,q,n) memcpy( p, q, (size_t)( (n) * sizeof(*p) ) )
END
EXTRACT
The STRICT_R_HEADERS does not go around the Realloc function so even with
STRICT_R_HEADERS defined the problem persists.
To test I placed "#define STRICT_R_HEADERS" at the top of my single cpp
file before all the include lines as I am not sure how to pass the -D
function through to the g++ when doing R CMD SHLIB - would putting it in
one of the PKG_ environment variables work - if so which?
Tom
On Thu, 23 Nov 2006 11:13:44 -, Prof Brian Ripley
<[EMAIL PROTECTED]> wrote:
> Realloc is defined in R_ext/RS.h, and only if STRICT_R_HEADERS is not
> defined. This *is* documented in 'Writing R Extensions'.
>
> On Thu, 23 Nov 2006, Tom McCallum wrote:
>
>> Thank you for your reply. My mistake - I meant Realloc (missed the
>> 'e').
>> This morning I reinstalled MinGW with all the patches suggested by the
>> Install R on Windows Help page, including w32api-3.7, just to make sure
>> all was as it should be. I have put
>>
>> #define WIN32_LEAN_AND_MEAN
>>
>> at the top of my cpp file (which I did not know about so that was
>> interesting) but it is still saying there is a conflict between Realloc
>> in
>> objidl.h and windows.h. Interesting I had a C file which I _did_ manage
>> to compile with the R.h and windows.h file in without this error coming
>> up. Could there be something going on with g++ that gcc is ignoring? I
>> am no sure it iss a clash now as I cannot find Realloc in the R includes
>> but below is some output I have gathered which may be of assistance.
>>
>> In objidl.h (line 532):
>> STDMETHOD_(void*,Realloc)(THIS_ void*,ULONG) PURE;
>>
>> In R.h it has the solitary line:
>> /* for PROBLEM ... Calloc, Realloc, Free, Memcpy, F77_ */
>> Can only find a R_alloc but no Realloc.
>>
>> ==ERROR MSG OUTPUT==
>> $ R CMD SHLIB callcdeclcall.cpp
>> making callcdeclcall.d from callcdeclcall.cpp
>> In file included from
>> c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/objbase.h:73,
>> from
>> c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/ole2.h:9,
>> from
>> c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/windows.h:111,
>> from callcdeclcall.cpp:4:
>> c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/objidl.h:532:45:
>> macro "Realloc" requires 3 arguments, but only 2 given
>> make: *** [callcdeclcall.d] Error 1
>> ==END ERROR MSG OUTPUT==
>>
>> Headers in CPP file are:
>> #include
>> #include
>> #include
>> #include
>> #include
>>
>> Thanks,
>>
>> Tom
>>
>>
>> On Wed, 22 Nov 2006 21:21:15 -, Prof Brian Ripley
>> <[EMAIL PROTECTED]> wrote:
>>
>>> Where exactly did you get windows.h from? The recommended source is
>>> w32api-3.7.tar.gz, and there is no Ralloc in any of
Re: [Rd] Ralloc clash
Thank you that did the job.
Tom
On Thu, 23 Nov 2006 13:06:29 -, Prof Brian Ripley
<[EMAIL PROTECTED]> wrote:
> On Thu, 23 Nov 2006, Prof Brian Ripley wrote:
>
>> Realloc is defined in R_ext/RS.h, and only if STRICT_R_HEADERS is not
>> defined. This *is* documented in 'Writing R Extensions'.
>
> That was the general intention, but seems not to cover this example.
> Howver,
>
> #include
> #undef Realloc
> #define R_Realloc(p,n,t) (t *) R_chk_realloc( (void *)(p), (size_t)((n)
> * sizeof(t)) )
> #include
>
> seems to work.
>
>
>> On Thu, 23 Nov 2006, Tom McCallum wrote:
>>
>>> Thank you for your reply. My mistake - I meant Realloc (missed the
>>> 'e').
>>> This morning I reinstalled MinGW with all the patches suggested by the
>>> Install R on Windows Help page, including w32api-3.7, just to make sure
>>> all was as it should be. I have put
>>> #define WIN32_LEAN_AND_MEAN
>>> at the top of my cpp file (which I did not know about so that was
>>> interesting) but it is still saying there is a conflict between
>>> Realloc in
>>> objidl.h and windows.h. Interesting I had a C file which I _did_
>>> manage
>>> to compile with the R.h and windows.h file in without this error coming
>>> up. Could there be something going on with g++ that gcc is ignoring?
>>> I
>>> am no sure it iss a clash now as I cannot find Realloc in the R
>>> includes
>>> but below is some output I have gathered which may be of assistance.
>>> In objidl.h (line 532):
>>> STDMETHOD_(void*,Realloc)(THIS_ void*,ULONG) PURE;
>>> In R.h it has the solitary line:
>>> /* for PROBLEM ... Calloc, Realloc, Free, Memcpy, F77_ */
>>> Can only find a R_alloc but no Realloc.
>>> ==ERROR MSG OUTPUT==
>>> $ R CMD SHLIB callcdeclcall.cpp
>>> making callcdeclcall.d from callcdeclcall.cpp
>>> In file included from
>>> c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/objbase.h:73,
>>> from
>>> c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/ole2.h:9,
>>> from
>>> c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/windows.h:111,
>>> from callcdeclcall.cpp:4:
>>> c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/objidl.h:532:45:
>>> macro "Realloc" requires 3 arguments, but only 2 given
>>> make: *** [callcdeclcall.d] Error 1
>>> ==END ERROR MSG OUTPUT==
>>> Headers in CPP file are:
>>> #include
>>> #include
>>> #include
>>> #include
>>> #include
>>> Thanks,
>>> Tom
>>> On Wed, 22 Nov 2006 21:21:15 -, Prof Brian Ripley
>>> <[EMAIL PROTECTED]> wrote:
>>>
>>>> Where exactly did you get windows.h from? The recommended source is
>>>> w32api-3.7.tar.gz, and there is no Ralloc in any of its header files,
>>>> including objidl.h.
>>>> BTW, do you know about defining WIN32_LEAN_AND_MEAN when including
>>>> windows.h? If not, it is worth finding out about.
>>>> On Wed, 22 Nov 2006, Tom McCallum wrote:
>>>>
>>>>> Hi everyone,
>>>>> Have been trying to include windows.h (from MinGW) and R.h into a
>>>>> package
>>>>> and have found that Ralloc is coming up as a clash no matter which
>>>>> include
>>>>> ordering I use. In windows it has 2 arguments and is defined in
>>>>> objidl.h
>>>>> and in R.h it is 3 arguments. Any ideas of how to work round this?
>>>>> Have
>>>>> checked the web and have not seen anyone else comment on this.
>>>>
>>>
>>
>>
>
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The c...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Floating point maths in R
Hi,
I am not sure if this is just me using R (R-2.3.1 and R-2.4.0) in the
wrong way or if there is a more serious bug. I was having problems
getting some calculations to add up so I ran the following tests:
> (2.34567 - 2.0) == 0.34567 <--- should be true
[1] FALSE
> (2.23-2.00) == 0.23 <--- should be true
[1] FALSE
> 4-2==2
[1] TRUE
> (4-2)==2
[1] TRUE
> (4.0-2)==2
[1] TRUE
> (4.0-2.0)==2
[1] TRUE
> (4.0-2.0)==2.0
[1] TRUE
> (4.2-2.2)==2.0
[1] TRUE
> (4.20-2.20)==2.00
[1] TRUE
> (4.23-2.23)==2.00 <--- should be true
[1] FALSE
> (4.230-2.230)==2.000 <--- should be true
[1] FALSE
> (4.230-2.230)==2.00 <--- should be true
[1] FALSE
> (4.230-2.23)==2.00 <--- should be true
[1] FALSE
I have tried these on both 64 and 32-bit machines. Surely R should be
able to do maths to 2 decimal places and be able to test these simple
expressions? The problem occurs as in the 16th decimal place junk is
being placed by the FPU it seems. I have also tried:
> (4.2300-2.230) == 2
[1] FALSE
> a <- (4.2300-2.230)
> a == 2
[1] FALSE
> (4.2300-2.230) == 2.
[1] FALSE
> (4.2300-2.230) == 2.0004 <-- correct
> when add 16th decimal place to 4
[1] TRUE
> (4.2300-2.230) == 2.00043 <-- any
> values after the 16th decimal place mean that the expression is true
[1] TRUE
> (4.2300-2.230) == 2.000435
[1] TRUE
Also :
> (4.2300-2.230) == 2.0001
[1] FALSE
> (4.2300-2.230) == 2.0003
[1] TRUE
> (4.2300-2.230) == 2.0004
[1] TRUE
> (4.2300-2.230) == 2.0005
[1] TRUE
> (4.2300-2.230) == 2.0006 <-- 3,5 I
> can understand being true if rounding occurring, but 6?
[1] TRUE
> (4.2300-2.230) == 2.0007
[1] FALSE
> (4.2300-2.230) == 2.0008
[1] FALSE
> (4.2300-2.230) == 2.0009
[1] FALSE
> (4.2300-2.230) == 2.0010
This is an example of junk being added in the FPU
> formatC(a, digits=20)
[1] "2.0004441"
I don't know if this is just a formatC error when using more than 16
decimal places or if this junk is what is stopping the equality from being
true:
> formatC(a, digits=16)
[1] "2"
> formatC(a, digits=17) <-- 16 decimal places, 17 significant figures
> shown
[1] "2.0004" <-- the problem is the 4 at the end
Obviously the bytes are divided between the exponent and mantissa in
16-16bit share it seems, but this doesn't account for the 16th decimal
place behaviour does it?
If any one has a work around or reason why this should occur it would be
useful to know.
what I would like is to be able to do sums such as (2.3456 - 2 ) == 0.3456
and get a sensible answer - any suggestions? Currently the only way is
for formatC the expression to a known number of decimal places - is there
a better way?
Many thanks
Tom
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The c...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Floating point maths in R
Many thanks for pointing that out.
Tom
On Sat, 09 Dec 2006 13:48:06 -, Peter Dalgaard
<[EMAIL PROTECTED]> wrote:
> Tom McCallum wrote:
>> Hi,
>>
>> I am not sure if this is just me using R (R-2.3.1 and R-2.4.0) in the
>> wrong way or if there is a more serious bug. I was having problems
>> getting some calculations to add up so I ran the following tests:
>>
>>
> Please read FAQ 7.31 and the reference therein.
>
> http://cran.r-project.org/doc/FAQ/R-FAQ.html#Why-doesn_0027t-R-think-these-numbers-are-equal_003f
>
> (short answer: You can not represent thirds exactly in decimal nor
> tenths in binary.)
>>> (2.34567 - 2.0) == 0.34567 <--- should be true
>>>
>> [1] FALSE
>>
>>> (2.23-2.00) == 0.23 <--- should be true
>>>
>> [1] FALSE
>>
>>> 4-2==2
>>>
>> [1] TRUE
>>
>>> (4-2)==2
>>>
>> [1] TRUE
>>
>>> (4.0-2)==2
>>>
>> [1] TRUE
>>
>>> (4.0-2.0)==2
>>>
>> [1] TRUE
>>
>>> (4.0-2.0)==2.0
>>>
>> [1] TRUE
>>
>>> (4.2-2.2)==2.0
>>>
>> [1] TRUE
>>
>>> (4.20-2.20)==2.00
>>>
>> [1] TRUE
>>
>>> (4.23-2.23)==2.00 <--- should be true
>>>
>> [1] FALSE
>>
>>> (4.230-2.230)==2.000 <--- should be true
>>>
>> [1] FALSE
>>
>>> (4.230-2.230)==2.00 <--- should be true
>>>
>> [1] FALSE
>>
>>> (4.230-2.23)==2.00 <--- should be true
>>>
>> [1] FALSE
>>
>> I have tried these on both 64 and 32-bit machines. Surely R should be
>> able to do maths to 2 decimal places and be able to test these simple
>> expressions? The problem occurs as in the 16th decimal place junk is
>> being placed by the FPU it seems. I have also tried:
>>
>>
>>> (4.2300-2.230) == 2
>>>
>> [1] FALSE
>>
>>> a <- (4.2300-2.230)
>>> a == 2
>>>
>> [1] FALSE
>>
>>> (4.2300-2.230) == 2.
>>>
>> [1] FALSE
>>
>>> (4.2300-2.230) == 2.0004 <--
>>> correct when add 16th decimal place to 4
>>>
>> [1] TRUE
>>
>>> (4.2300-2.230) == 2.00043 <--
>>> any values after the 16th decimal place mean that the expression is
>>> true
>>>
>> [1] TRUE
>>
>>> (4.2300-2.230) == 2.000435
>>>
>> [1] TRUE
>>
>> Also :
>>
>>
>>> (4.2300-2.230) == 2.0001
>>>
>> [1] FALSE
>>
>>> (4.2300-2.230) == 2.0003
>>>
>> [1] TRUE
>>
>>> (4.2300-2.230) == 2.0004
>>>
>> [1] TRUE
>>
>>> (4.2300-2.230) == 2.0005
>>>
>> [1] TRUE
>>
>>> (4.2300-2.230) == 2.0006 <-- 3,5
>>> I can understand being true if rounding occurring, but 6?
>>>
>> [1] TRUE
>>
>>> (4.2300-2.230) == 2.0007
>>>
>> [1] FALSE
>>
>>> (4.2300-2.230) == 2.0008
>>>
>> [1] FALSE
>>
>>> (4.2300-2.230) == 2.0009
>>>
>> [1] FALSE
>>
>>> (4.2300-2.230) == 2.0010
>>>
>>
>>
>> This is an example of junk being added in the FPU
>>
>>> formatC(a, digits=20)
>>>
>> [1] "2.0004441"
>>
>> I don't know if this is just a formatC error when using more than 16
>> decimal places or if this junk is what is stopping the equality from
>> being true:
>>
>>
>>> formatC(a, digits=16)
>>>
>> [1] "2"
>>
>>> formatC(a, digits=17) <-- 16 decimal places, 17 significant figures
>>> shown
>>>
>> [1] "2.0004" <-- the problem is the 4 at the end
>>
>> Obviously the bytes are divided between the exponent and mantissa in
>> 16-16bit share it seems, but this doesn't account for the 16th decimal
>> place behaviour does it?
>>
>> If any one has a work around or reason why this should occur it would
>> be useful to know.
>>
>> what I would like is to be able to do sums such as (2.3456 - 2 ) ==
>> 0.3456 and get a sensible answer - any suggestions? Currently the
>> only way is for formatC the expression to a known number of decimal
>> places - is there a better way?
>>
>> Many thanks
>>
>> Tom
>>
>>
>>
>
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The c...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] looks in liblapack.a not liblapack.so
On Thu, 2005-09-22 at 10:36 +0100, Prof Brian Ripley wrote: > Probably because it is discussed in the R-admin manual as having > previously appeared in Debian and being traced to an erroneous patch to > the Lapack 3.0 sources. You wouldn't happen to have more specific details on this, would you? :) I know there is a fair amount of cruft in the Fedora lapack package, and I'd like to clean it out, but I want to make sure I don't remove any legitimate bug-fixes in the process. (See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169399 for some semi-related discussion of lapack and its patching) Thanks, ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] make error for R 2.13.0 (and 2.12.0)
On 10/18/2010 03:03 AM, Peter Dalgaard wrote: > On 10/18/2010 02:39 AM, Radford Neal wrote: >> Regarding Tengfei Yin's post about an error trying to install >> "cluster" in 2.13.0, I have gotten an error with this package when >> trying to install the released version of 2.12.0. Here is the output >> on an Ubuntu Linux system: > > Hmm, g77 along with a recent gcc? It is usually gfortran on current > linux systems. It's strange that it got past the configure step though. > What did the configure output look like? A look at "nm cluster.so" could > also be informative. RHEL 4 throws the same error (RHEL 5, RHEL 6, and all current Fedora targets (F12-F15) are fine): * installing *source* package 'cluster' ... ** libs make[3]: Entering directory `/tmp/RtmpbbtMdO/R.INSTALL5ad6c5f4/cluster/src' gcc -m64 -std=gnu99 -I/builddir/build/BUILD/R-2.12.0/include -I/usr/local/include-fpic -O2 -g -pipe -m64 -c clara.c -o clara.o g77 -m64 -fpic -O2 -g -pipe -m64 -c daisy.f -o daisy.o g77 -m64 -fpic -O2 -g -pipe -m64 -c dysta.f -o dysta.o gcc -m64 -std=gnu99 -I/builddir/build/BUILD/R-2.12.0/include -I/usr/local/include-fpic -O2 -g -pipe -m64 -c fanny.c -o fanny.o gcc -m64 -std=gnu99 -I/builddir/build/BUILD/R-2.12.0/include -I/usr/local/include-fpic -O2 -g -pipe -m64 -c init.c -o init.o g77 -m64 -fpic -O2 -g -pipe -m64 -c meet.f -o meet.o g77 -m64 -fpic -O2 -g -pipe -m64 -c mona.f -o mona.o gcc -m64 -std=gnu99 -I/builddir/build/BUILD/R-2.12.0/include -I/usr/local/include-fpic -O2 -g -pipe -m64 -c pam.c -o pam.o gcc -m64 -std=gnu99 -I/builddir/build/BUILD/R-2.12.0/include -I/usr/local/include-fpic -O2 -g -pipe -m64 -c sildist.c -o sildist.o gcc -m64 -std=gnu99 -I/builddir/build/BUILD/R-2.12.0/include -I/usr/local/include-fpic -O2 -g -pipe -m64 -c spannel.c -o spannel.o g77 -m64 -fpic -O2 -g -pipe -m64 -c twins.f -o twins.o gcc -m64 -std=gnu99 -shared -L/usr/local/lib64 -o cluster.so clara.o daisy.o dysta.o fanny.o init.o meet.o mona.o pam.o sildist.o spannel.o twins.o -lg2c -lm -L/builddir/build/BUILD/R-2.12.0/lib -lR make[3]: Leaving directory `/tmp/RtmpbbtMdO/R.INSTALL5ad6c5f4/cluster/src' installing to /builddir/build/BUILD/R-2.12.0/library/cluster/libs ** R ** data ** moving datasets to lazyload DB ** inst ** preparing package for lazy loading ** help *** installing help indices converting help for package 'cluster' finding HTML links ... done agnes html agnes.objecthtml agriculture html animals html bannerplot html chorSub html clara html clara.objecthtml clusplothtml clusplot.defaulthtml Rd warning: /tmp/RtmpbbtMdO/R.INSTALL5ad6c5f4/cluster/man/clusplot.default.Rd:198: missing file link 'cov.mve' clusplot.partition html cluster-internalhtml coef.hclust html daisy html diana html dissimilarity.objecthtml ellipsoidhull html Rd warning: /tmp/RtmpbbtMdO/R.INSTALL5ad6c5f4/cluster/man/ellipsoidhull.Rd:36: missing file link 'cov.mve' Rd warning: /tmp/RtmpbbtMdO/R.INSTALL5ad6c5f4/cluster/man/ellipsoidhull.Rd:86: missing file link 'cov.mve' fanny html fanny.objecthtml flower html lower.to.upper.tri.inds html monahtml mona.object html pam html pam.object html partition.objecthtml plantTraits html plot.agnes html Rd warning: /tmp/RtmpbbtMdO/R.INSTALL5ad6c5f4/cluster/man/plot.agnes.Rd:73: missing file link 'plot.dendrogram' plot.diana html plot.mona html plot.partition html pltree html pltree.twinshtml pluton html predict.ellipsoid html print.agnes html print.clara html print.diana html print.dissimilarity html Rd warning: /tmp/RtmpbbtMdO/R.INSTALL5ad6c5f4/cluster/man/print.dissimilarity.Rd:27: missing file link 'print.dist' print.fanny html print.mona html print.pa
Re: [Rd] make error for R 2.13.0 (and 2.12.0)
On 11/05/2010 07:59 AM, Johann Hibschman wrote: > "Tom \"spot\" Callaway" writes: > >> Full build log is here: >> http://koji.fedoraproject.org/koji/getfile?taskID=2571563&name=build.log >> >> Default gcc in RHEL 4 is 3.4.6-10, which has g77 rather than gfortran. >> It looks like this code no longer compiles properly with g77. >> >> Thankfully, RHEL 4 also includes a copy of gcc 4.1, so I should be able >> to work around this by using that instead. > > Did you have any luck with this? I'm also stuck on RHEL 4, also facing > that same error, but I've not been able to find gfortran anywhere on the > system. Yes, I was able to get this working by installing the gcc4-gfortran and gcc4-c++ packages on RHEL 4, and setting CC=gcc4, CXX=g++4, FC=gfortran and F77=gfortran. I pushed this package into EPEL (http://fedoraproject.org/wiki/EPEL), so if you'd rather just use my builds instead of trying your own, 2.12.0 is available now. ( For this specific update, see: https://admin.fedoraproject.org/updates/R-2.12.0-1.el4.1 ) Thanks, ~spot __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Stack smashing in RODBC
This is R 2.10.1, from Fedora 12 and RODBC 1.3-1 (although 1.3-0 has the
same problem) on i686.
Originally reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=557953
Reproducer and output below:
[s...@f12.i386 src]$ R
R version 2.10.1 (2009-12-14)
Copyright (C) 2009 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> library(RODBC)
> channel <- odbcConnect("foo", uid="bar")
*** stack smashing detected ***: /usr/lib/R/bin/exec/R terminated
=== Backtrace: =
/lib/libc.so.6(__fortify_fail+0x4d)[0x59d1ed]
/lib/libc.so.6[0x59d19a]
/usr/lib/R/library/RODBC/libs/RODBC.so(+0x6164)[0x753164]
/usr/lib/R/library/RODBC/libs/RODBC.so(RODBCDriverConnect+0x4ed)[0x74f072]
/usr/lib/R/lib/libR.so(+0x8601c)[0x1c901c]
/usr/lib/R/lib/libR.so(Rf_eval+0x7f2)[0x1eca82]
/usr/lib/R/lib/libR.so(+0xabfd5)[0x1eefd5]
/usr/lib/R/lib/libR.so(Rf_eval+0x568)[0x1ec7f8]
/usr/lib/R/lib/libR.so(+0xac0eb)[0x1ef0eb]
/usr/lib/R/lib/libR.so(Rf_eval+0x568)[0x1ec7f8]
/usr/lib/R/lib/libR.so(Rf_applyClosure+0x2e7)[0x1f0ac7]
/usr/lib/R/lib/libR.so(Rf_eval+0x40d)[0x1ec69d]
/usr/lib/R/lib/libR.so(+0xaa43a)[0x1ed43a]
/usr/lib/R/lib/libR.so(+0xf5e9e)[0x238e9e]
/usr/lib/R/lib/libR.so(Rf_eval+0x568)[0x1ec7f8]
/usr/lib/R/lib/libR.so(Rf_applyClosure+0x2e7)[0x1f0ac7]
/usr/lib/R/lib/libR.so(Rf_eval+0x40d)[0x1ec69d]
/usr/lib/R/lib/libR.so(+0xac0eb)[0x1ef0eb]
/usr/lib/R/lib/libR.so(Rf_eval+0x568)[0x1ec7f8]
/usr/lib/R/lib/libR.so(Rf_applyClosure+0x2e7)[0x1f0ac7]
/usr/lib/R/lib/libR.so(Rf_eval+0x40d)[0x1ec69d]
/usr/lib/R/lib/libR.so(+0xac0eb)[0x1ef0eb]
/usr/lib/R/lib/libR.so(Rf_eval+0x568)[0x1ec7f8]
/usr/lib/R/lib/libR.so(Rf_applyClosure+0x2e7)[0x1f0ac7]
/usr/lib/R/lib/libR.so(Rf_eval+0x40d)[0x1ec69d]
/usr/lib/R/lib/libR.so(+0xabfd5)[0x1eefd5]
/usr/lib/R/lib/libR.so(Rf_eval+0x568)[0x1ec7f8]
/usr/lib/R/lib/libR.so(Rf_ReplIteration+0x23d)[0x22764d]
/usr/lib/R/lib/libR.so(+0xe49a5)[0x2279a5]
/usr/lib/R/lib/libR.so(run_Rmainloop+0x66)[0x228236]
/usr/lib/R/lib/libR.so(Rf_mainloop+0x1d)[0x22826d]
/usr/lib/R/bin/exec/R(main+0x39)[0x8048699]
/lib/libc.so.6(__libc_start_main+0xe6)[0x4bfbb6]
/usr/lib/R/bin/exec/R[0x8048591]
=== Memory map:
0011-00138000 r-xp fd:00 478/lib/libm-2.11.1.so
00138000-00139000 r--p 00027000 fd:00 478/lib/libm-2.11.1.so
00139000-0013a000 rw-p 00028000 fd:00 478/lib/libm-2.11.1.so
0013a000-0013d000 r-xp fd:00 479/lib/libdl-2.11.1.so
0013d000-0013e000 r--p 2000 fd:00 479/lib/libdl-2.11.1.so
0013e000-0013f000 rw-p 3000 fd:00 479/lib/libdl-2.11.1.so
00143000-003b3000 r-xp fd:00 223583 /usr/lib/R/lib/libR.so
003b3000-003c1000 rw-p 0027 fd:00 223583 /usr/lib/R/lib/libR.so
003c1000-00457000 rw-p 00:00 0
00457000-00469000 r-xp fd:00 630/lib/libz.so.1.2.3
00469000-0046a000 rw-p 00011000 fd:00 630/lib/libz.so.1.2.3
0046a000-0048 r-xp fd:00 17315 /lib/libtinfo.so.5.7
0048-00483000 rw-p 00015000 fd:00 17315 /lib/libtinfo.so.5.7
00487000-004a5000 r-xp fd:00 462/lib/ld-2.11.1.so
004a5000-004a6000 r--p 0001d000 fd:00 462/lib/ld-2.11.1.so
004a6000-004a7000 rw-p 0001e000 fd:00 462/lib/ld-2.11.1.so
004a9000-00618000 r-xp fd:00 463/lib/libc-2.11.1.so
00618000-0061a000 r--p 0016e000 fd:00 463/lib/libc-2.11.1.so
0061a000-0061b000 rw-p 0017 fd:00 463/lib/libc-2.11.1.so
0061b000-0061e000 rw-p 00:00 0
0061e000-006f3000 r-xp fd:00 46452
/usr/lib/libgfortran.so.3.0.0
006f3000-006f5000 rw-p 000d4000 fd:00 46452
/usr/lib/libgfortran.so.3.0.0
006f5000-0070b000 r-xp fd:00 476/lib/libpthread-2.11.1.so
0070b000-0070c000 r--p 00015000 fd:00 476/lib/libpthread-2.11.1.so
0070c000-0070d000 rw-p 00016000 fd:00 476/lib/libpthread-2.11.1.so
0070d000-0070f000 rw-p 00:00 0
0070f000-0072c000 r-xp fd:00 356
/lib/libgcc_s-4.4.2-20091222.so.1
0072c000-0072d000 rw-p 0001c000 fd:00 356
/lib/libgcc_s-4.4.2-20091222.so.1
0072d000-0074c000 r-xp fd:00 225135
/usr/lib/R/library/grDevices/libs/grDevices.so
0074c000-0074d000 rw-p 0001f000 fd:00 225135
/usr/lib/R/library/grDevices/libs/grDevices.so
0074d000-00755000 r-xp fd:00 22
/usr/lib/R/library/RODBC/libs/RODBC.so
00755000-00756000 rw-p 7000 fd:00 22
/usr/lib/R/library/RODBC/libs/RODBC.so
00756000-00757000 rw-p 00:00 0
0079a000-007cf000 r-xp 0
Re: [Rd] Stack smashing in RODBC
On 01/25/2010 09:14 PM, Dirk Eddelbuettel wrote: > I cannot replicate this on Debian. The error gets trapped just fine. This may > be particular to your builds or setup. I don;t see an R error (but of course > do not speak for R Core). Here is a short version, it is the same in normal > interactive mode. I don't think Debian builds with stack protection in glibc, whereas Fedora does (and I think Ubuntu Hardy and onward also do). ~spot __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Stack smashing in RODBC
On 01/26/2010 06:17 AM, Dirk Eddelbuettel wrote:
>
> On 26 January 2010 at 01:23, "Tom \"spot\" Callaway" wrote:
> | On 01/25/2010 09:14 PM, Dirk Eddelbuettel wrote:
> | > I cannot replicate this on Debian. The error gets trapped just fine. This
> may
> | > be particular to your builds or setup. I don;t see an R error (but of
> course
> | > do not speak for R Core). Here is a short version, it is the same in
> normal
> | > interactive mode.
> |
> | I don't think Debian builds with stack protection in glibc, whereas
> | Fedora does (and I think Ubuntu Hardy and onward also do).
>
> As I get the exact same result on Ubuntu, I continue to suspect that the
> issue with Fedora.
We're not modifying the RODBC or R code at all, so I suspect that it is
a legitimate bug that Fedora is better at reproducing.
The Fedora optflags tend to be more restrictive than some other Linux
distributions, here is how RODBC is compiled by default:
gcc -m32 -std=gnu99 -I/usr/include/R -I. -I/usr/local/include-fpic
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom
-fasynchronous-unwind-tables -c RODBC.c -o RODBC.o
gcc -m32 -std=gnu99 -shared -L/usr/local/lib -o RODBC.so RODBC.o -lodbc
-L/usr/lib/R/lib -lR
I compiled RODBC without any -O and with -ggdb for debugging, but it
didn't prevent the crash.
[s...@f12.i386 ~]$ echo 'library(RODBC); channel <- odbcConnect("foo",
uid="bar")' | R --slave
*** stack smashing detected ***: /usr/lib/R/bin/exec/R terminated
=== Backtrace: =
/lib/libc.so.6(__fortify_fail+0x4d)[0x2041ed]
/lib/libc.so.6(-0xffa62e66)[0x20419a]
/usr/lib/R/library/RODBC/libs/RODBC.so(+0x6164)[0x2c9164]
/usr/lib/R/library/RODBC/libs/RODBC.so(RODBCDriverConnect+0x4ed)[0x2c5072]
/usr/lib/R/lib/libR.so[0x85c01c]
/usr/lib/R/lib/libR.so(Rf_eval+0x7f2)[0x87fa82]
/usr/lib/R/lib/libR.so[0x881fd5]
/usr/lib/R/lib/libR.so(Rf_eval+0x568)[0x87f7f8]
/usr/lib/R/lib/libR.so[0x8820eb]
/usr/lib/R/lib/libR.so(Rf_eval+0x568)[0x87f7f8]
/usr/lib/R/lib/libR.so(Rf_applyClosure+0x2e7)[0x883ac7]
/usr/lib/R/lib/libR.so(Rf_eval+0x40d)[0x87f69d]
/usr/lib/R/lib/libR.so[0x88043a]
/usr/lib/R/lib/libR.so[0x8cbe9e]
/usr/lib/R/lib/libR.so(Rf_eval+0x568)[0x87f7f8]
/usr/lib/R/lib/libR.so(Rf_applyClosure+0x2e7)[0x883ac7]
/usr/lib/R/lib/libR.so(Rf_eval+0x40d)[0x87f69d]
/usr/lib/R/lib/libR.so[0x8820eb]
/usr/lib/R/lib/libR.so(Rf_eval+0x568)[0x87f7f8]
/usr/lib/R/lib/libR.so(Rf_applyClosure+0x2e7)[0x883ac7]
/usr/lib/R/lib/libR.so(Rf_eval+0x40d)[0x87f69d]
/usr/lib/R/lib/libR.so[0x8820eb]
/usr/lib/R/lib/libR.so(Rf_eval+0x568)[0x87f7f8]
/usr/lib/R/lib/libR.so(Rf_applyClosure+0x2e7)[0x883ac7]
/usr/lib/R/lib/libR.so(Rf_eval+0x40d)[0x87f69d]
/usr/lib/R/lib/libR.so[0x881fd5]
/usr/lib/R/lib/libR.so(Rf_eval+0x568)[0x87f7f8]
/usr/lib/R/lib/libR.so(Rf_ReplIteration+0x23d)[0x8ba64d]
/usr/lib/R/lib/libR.so[0x8ba9a5]
/usr/lib/R/lib/libR.so(run_Rmainloop+0x66)[0x8bb236]
/usr/lib/R/lib/libR.so(Rf_mainloop+0x1d)[0x8bb26d]
/usr/lib/R/bin/exec/R(main+0x39)[0x8048699]
/lib/libc.so.6(__libc_start_main+0xe6)[0x126bb6]
/usr/lib/R/bin/exec/R[0x8048591]
=== Memory map:
0011-0027f000 r-xp fd:00 463/lib/libc-2.11.1.so
0027f000-00281000 r--p 0016e000 fd:00 463/lib/libc-2.11.1.so
00281000-00282000 rw-p 0017 fd:00 463/lib/libc-2.11.1.so
00282000-00285000 rw-p 00:00 0
00285000-0029b000 r-xp fd:00 17315 /lib/libtinfo.so.5.7
0029b000-0029e000 rw-p 00015000 fd:00 17315 /lib/libtinfo.so.5.7
0029e000-002bb000 r-xp fd:00 356
/lib/libgcc_s-4.4.2-20091222.so.1
002bb000-002bc000 rw-p 0001c000 fd:00 356
/lib/libgcc_s-4.4.2-20091222.so.1
002bc000-002c2000 r-xp fd:00 225678
/usr/lib/R/library/methods/libs/methods.so
002c2000-002c3000 rw-p 5000 fd:00 225678
/usr/lib/R/library/methods/libs/methods.so
002c3000-002cb000 r-xp fd:00 22
/usr/lib/R/library/RODBC/libs/RODBC.so
002cb000-002cc000 rw-p 7000 fd:00 22
/usr/lib/R/library/RODBC/libs/RODBC.so
002cc000-002cd000 rw-p 00:00 0
002cd000-00339000 r-xp fd:00 25406 /usr/lib/libodbc.so.2.0.0
00339000-0033e000 rw-p 0006b000 fd:00 25406 /usr/lib/libodbc.so.2.0.0
00487000-004a5000 r-xp fd:00 462/lib/ld-2.11.1.so
004a5000-004a6000 r--p 0001d000 fd:00 462/lib/ld-2.11.1.so
004a6000-004a7000 rw-p 0001e000 fd:00 462/lib/ld-2.11.1.so
004e2000-00538000 r-xp fd:00 226761
/usr/lib/R/library/stats/libs/stats.so
00538000-0053a000 rw-p 00055000 fd:00 226761
/usr/lib/R/library/stats/libs/stats.so
0053c000-0053d000 r-xp 00:00 0 [vdso]
005bd000-005c8000 r-xp fd:00 31904 /lib/libnss_files-2.11.1.so
005c8000-005c9000 r--p a000 fd:00 31904 /lib/libnss_files-2.11.1.so
005c9000-005ca000 rw-p b000 fd:00 31904 /lib/libnss
[Rd] Support for noarch packages in /usr/share/R/library
As originally raised here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231220 It has been proposed that R should support noarch packages in /usr/share/R/library in addition to architecture specific packages in /usr/lib/R/library or /usr/lib64/R/library. For example, the mAr addon doesn't have any architecture specific bits. Strictly speaking, the Filesystem Hierarchy Standard says it doesn't belong in /usr/lib, but rather, /usr/share. Ideas on the best way to resolve this would be greatly appreciated. Thanks in advance, ~spot __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] make check-all fails on F8
On Fri, 2007-11-09 at 11:41 -0600, Marc Schwartz wrote:
> I have been looking ("tunnel vision") at this now for several hours
> going back to last night, and am probably missing something basic here,
> but is this the result of a change in the behavior of diff on F8, or is
> something else going on that I am just missing?
https://bugzilla.redhat.com/show_bug.cgi?id=363831
It's a bug in diff. There's a fixed package in that bug report.
~spot
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Security issue with javareconf script (PR#12636)
On Fri, 2008-08-29 at 20:04 +0200, Peter Dalgaard wrote: > OK, committed. Not the easiest hole to exploit, I'd say (notice that > we > only compile something, not execute it). > > > . > > Oh, sh*! This is not portable! Needs code like INSTALL. Will refix. Sorry about that. I forgot that people cared about *nix that has a supported Java but no mktemp implementation... :) ~spot __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Configure error when compiling on "sh" architecture
Amusingly enough, the SuperH (or sh for short) architecture isn't one of the many I have handy, but someone seems to be porting Fedora to that arch. They filed a bug against R, which isn't really an R bug, but is more an inherited bug from autoconf. Specifically, the R configure script invokes gcc(gfortran) which then passes "-little" to gas when compiling for backward compatibility. This fails on sh, and they proposed that it be added to the list of "flags to ignore" in configure. See: https://bugzilla.redhat.com/show_bug.cgi?id=464055 https://bugzilla.redhat.com/show_bug.cgi?id=456886 I've attached the same patch that is in 464055 to this email. Hopefully, at some point before the sun explodes, that fix will end up in autoconf, and upstreams will pick it up when they run the fixed autoconf on their tree. Thanks, ~tom --- R-2.7.2/configure.org 2008-09-25 15:00:20.0 +0900 +++ R-2.7.2/configure 2008-09-25 15:00:35.0 +0900 @@ -26995,7 +26995,7 @@ ;; # Ignore these flags. --lang* | -lcrt*.o | -lc | -lgcc* | -lSystem | -libmil | -LANG:=* | -LIST:* | -LNO:*) +-little | -lang* | -lcrt*.o | -lc | -lgcc* | -lSystem | -libmil | -LANG:=* | -LIST:* | -LNO:*) ;; -lkernel32) test x"$CYGWIN" != xyes && ac_cv_f77_libs="$ac_cv_f77_libs $ac_arg" __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] HAVE_BZLIB_H not set
When building 2.8.0 this morning for Fedora, I noticed that it was
building the included bzlib2 source and using it rather than the system
bzip2 libraries and headers. I tracked down the reason to this section
of configure:
cat >>conftest.$ac_ext <<_ACEOF
/* end confdefs.h. */
#ifdef HAVE_BZLIB_H
#include
#endif
int main() {
char *ver = BZ2_bzlibVersion();
exit(strcmp(ver, "1.0.5") < 0);
}
_ACEOF
That code wasn't working at all because HAVE_BZLIB_H never gets set
anywhere, even though the configure script had found the system bzip2
bits. This patch adds it to m4/R.m4 and configure, against 2.8.0. With
the patch, R now properly detects bzip2 1.0.5 in Fedora and uses that
rather than the local copy.
~spot
diff -up R-2.8.0/configure.BAD R-2.8.0/configure
--- R-2.8.0/configure.BAD 2008-10-26 11:51:56.0 -0400
+++ R-2.8.0/configure 2008-10-26 11:52:31.0 -0400
@@ -44779,6 +44779,11 @@ else
have_bzlib=no
fi
if test "x${have_bzlib}" = xyes; then
+
+cat >>confdefs.h <<\_ACEOF
+#define HAVE_BZLIB_H 1
+_ACEOF
+
{ echo "$as_me:$LINENO: checking if bzip2 version >= 1.0.5" >&5
echo $ECHO_N "checking if bzip2 version >= 1.0.5... $ECHO_C" >&6; }
if test "${r_cv_have_bzlib+set}" = set; then
diff -up R-2.8.0/m4/R.m4.BAD R-2.8.0/m4/R.m4
--- R-2.8.0/m4/R.m4.BAD 2008-09-21 18:05:06.0 -0400
+++ R-2.8.0/m4/R.m4 2008-10-26 11:53:05.0 -0400
@@ -3055,6 +3055,7 @@ else
have_bzlib=no
fi
if test "x${have_bzlib}" = xyes; then
+AC_DEFINE(HAVE_BZLIB_H, 1, [Define to 1 if you have bzlib.h.])
AC_CACHE_CHECK([if bzip2 version >= 1.0.5], [r_cv_have_bzlib],
[AC_LANG_PUSH(C)
r_save_LIBS="${LIBS}"
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eval(match.call()) (PR#9339)
On Sat, 2006-11-04 at 00:07 +0100, [EMAIL PROTECTED] wrote: > On Fri, 2006-11-03 at 14:14 -0800, Bill Dunlap wrote: > > On Fri, 3 Nov 2006 [EMAIL PROTECTED] wrote: > > > > > > > On Fri, 2006-11-03 at 21:15 +0100, Peter Dalgaard wrote: > > > > > > > x <- quote(match.call()) > > > > > > > eval(x) > > > > > > *** buffer overflow detected ***: /usr/lib/R/bin/exec/R terminated > > > > > > /lib/libc.so.6(__chk_fail+0x41)[0x1f1161] > > > > > > /lib/libc.so.6[0x1f0617] > > > > > > > > > does look like something that just Should Not Happen... > > > > > > I think valgrind shows the problem is in deparse.c: > > 245 strncpy(data, CHAR(STRING_ELT(svec, 0)), 10); > > 246 if (strlen(CHAR(STRING_ELT(svec, 0))) > 10) strcat(data, > > "..."); > > You need to put a '\0' into data[10] after that strncpy > > so strcat can find the end of the string when the length > > of the copied string is >=10. It currently runs into > > uninitialized memory at the end of ".Primitive". > > > > (This is in a copy of R source from June 2006.) I was halfway to identifying this when Bill figured it out. :) New packages are built for FC-4, FC-5, FC-6, and devel which bring us up to the 11-03 patched level. Thanks for the fix, ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
