[Rd] Fw: alpha transparency crashes R
I'm forwarding a bug report from Jeff Gove that didn't make it to the list.
-Deepayan
--- Original Message
Subject:alpha transparency crashes R
Date: Fri, 07 Nov 2008 14:32:27 -0500
From: jeff gove <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
I ran into a problem with R crashing when a certain number of
transparent objects (e.g., symbols) are sent to a PDF output device.
This has happened on R 2.71, 2.7.2 (Fedora 8 and Ububtu 8.04
platforms) and now 2.8.0 (I've only tried Fedora 8). The current
pertinent R system stats are...
R.version
_
platform x86_64-redhat-linux-gnu
arch x86_64
os linux-gnu
system x86_64, linux-gnu
status
major 2
minor 8.0
year 2008
month 10
day20
svn rev46754
language R
version.string R version 2.8.0 (2008-10-20)
The following small example program when run with n large enough
(e.g., n=1000) and transparency will crash R...
alphaBomb.r = function(n=100, wantAlpha=T) {
df = data.frame(a=rnorm(n),b=runif(n))
if(wantAlpha)
alpha=runif(n)
else
alpha = 1
j = xyplot(b~a, df, alpha=alpha, pch=19)
print(j)
trellis.device('pdf',file='alphaBomb.pdf',version='1.4')
print(j)
dev.off()
}
Please note that the crash seems to occur in the dev.off() component,
and that the file actually seems to get written out correctly. The
trace of the bomb is found below, excluding the memory map. Please
also note that it may be somehow related to grid, as the following
code (supplied by Deepayan Sarkar) using base graphics does not crash
R, even with n=10...
pdf()
n = 1000
plot(rnorm(n), rnorm(n), col = rgb(0, 0, 0, alpha = runif(n)), pch = 16)
dev.off()
The error trace from the above alphaBomb.r() code is...
R> alphaBomb.r(100) #this is fine
X11cairo
2
R> alphaBomb.r(1000,F) #also fine
R> alphaBomb.r(1000)
*** glibc detected *** /usr/lib64/R/bin/exec/R: double free or
corruption (!prev): 0x032c1d90 ***
=== Backtrace: =
/lib64/libc.so.6[0x3ee8c72832]
/lib64/libc.so.6(cfree+0x8c)[0x3ee8c75f2c]
/usr/lib64/R/library/grDevices/libs/grDevices.so[0x2aaab000b0fc]
/usr/lib64/R/lib/libR.so[0x3d1f48ddd3]
/usr/lib64/R/lib/libR.so[0x3d1f48e2dc]
/usr/lib64/R/lib/libR.so[0x3d1f4ec81c]
/usr/lib64/R/lib/libR.so(Rf_eval+0x42e)[0x3d1f4be8ae]
/usr/lib64/R/lib/libR.so[0x3d1f4bf572]
/usr/lib64/R/lib/libR.so(Rf_eval+0x42e)[0x3d1f4be8ae]
/usr/lib64/R/lib/libR.so(Rf_applyClosure+0x291)[0x3d1f4c0bf1]
/usr/lib64/R/lib/libR.so(Rf_eval+0x303)[0x3d1f4be783]
/usr/lib64/R/lib/libR.so[0x3d1f4bf572]
/usr/lib64/R/lib/libR.so(Rf_eval+0x42e)[0x3d1f4be8ae]
/usr/lib64/R/lib/libR.so(Rf_applyClosure+0x291)[0x3d1f4c0bf1]
/usr/lib64/R/lib/libR.so(Rf_eval+0x303)[0x3d1f4be783]
/usr/lib64/R/lib/libR.so(Rf_ReplIteration+0x188)[0x3d1f4dc878]
/usr/lib64/R/lib/libR.so[0x3d1f4dcb90]
/usr/lib64/R/lib/libR.so(run_Rmainloop+0x50)[0x3d1f4dcec0]
/usr/lib64/R/bin/exec/R(main+0x1b)[0x40082b]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x3ee8c1e074]
/usr/lib64/R/bin/exec/R[0x400729]
=== Memory map:
etc...
Please note that R only crashes with PDF output; tiff, png and eps
(even though it doesn't accept transparency) all exit cleanly.
My version of glibc is 2.7.
Thanks, I hope that the problem is already resolved!
Jeff
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem with postscript/pdf plots, locales and embedded R
You start from a false premise, and it seems that you are reporting a
serious bug in Rpy to the wrong list:
Note that R expects to be run with the locale category `LC_NUMERIC' set
to its default value of C, and so should not be embedded into an
application which changes that.
('Writing R Extensions').
On Sat, 15 Nov 2008, laurent wrote:
Thanks for the quick answer.
The documentation for Sys.setlocale mentions the possibility of warning
when LC_NUMERIC is set.
After checking it is looking like setting LC_NUMERIC from Sys.setlocale
does issue a warning, but there is does not seem to be a warning when
LC_NUMERIC is set in the parent shell. In the case the later is likely
to cause trouble, would it be appropriate to issue a warning when R is
initialized ?
Of course R does not violate its own documentation. None of the R
executables reset the LC_NUMERIC locale category, and all C programs start
in the 'C' locale (both facts you should have known from the homework
you did before posting).
BDR
Laurent
On Fri, 2008-11-14 at 19:37 +, Prof Brian Ripley wrote:
On Fri, 14 Nov 2008, laurent wrote:
Dear list,
A problem with creating pdf or postscript plots from an embedded R, and
in an environment where a locale is defined, was recently reported on
the rpy (Python->R interface) mailing list.
The problem appears to be that whenever the locale defines ',' as a
separator for the decimal part of a numerical value, the pdf/ps file
generated still has the ',' instead of a '.' causing problem when open
the resulting file with a postscript/pdf viewer.
Of course, an obvious workaround would be to force the locale for
numbers to C ( LC_NUMERIC = "C" ), but that could be overriding
internationalization features otherwise in R.
Any advice ?
Don't set LC_NUMERIC with R: ?Sys.setlocale did warn you about that.
It used to cause far more problems than this.
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Computing minimal detectable differences for general ANOVA models
Dear Developers, I would like to contribute to the R Project. I implemented a C function the can be used to calculate minimal detectable differences for general ANOVA models (sample size calculations, power analysis). A demo program and the source code is available from my website: http://reliablecomputing.eu/ncbeta.html What should i do in order to make my ncbeta function part of the R project source distribution? Probably the most troublesome parts of my code are those where error may occur, i do not know much about the proper error handling in R. Many thanks, Ali P.S. I see my suggestions https://stat.ethz.ch/pipermail/r-devel/2008-April/049317.html were considered in R 2.8.0. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem with postscript/pdf plots, locales and embedded R
That might also be reporting something that can be felt like a brittle
aspect of R when embedded.
I am very tempted to ask why enforcing LC_NUMERIC to "C" for the
whole process while this only concerns numerical values written into
"data" files. I am understanding that at least postscript/pdf files are
affected, and so might files representing R serialized objects.
Functions like glib's 'g_ascii_dtostr()/g_ascii_strtod()' appear to have
been developed for such purposes, for example.
L.
On Sun, 2008-11-16 at 12:40 +, Prof Brian Ripley wrote:
> You start from a false premise, and it seems that you are reporting a
> serious bug in Rpy to the wrong list:
>
>Note that R expects to be run with the locale category `LC_NUMERIC' set
>to its default value of C, and so should not be embedded into an
>application which changes that.
>
> ('Writing R Extensions').
>
> On Sat, 15 Nov 2008, laurent wrote:
>
> > Thanks for the quick answer.
> >
> > The documentation for Sys.setlocale mentions the possibility of warning
> > when LC_NUMERIC is set.
> >
> > After checking it is looking like setting LC_NUMERIC from Sys.setlocale
> > does issue a warning, but there is does not seem to be a warning when
> > LC_NUMERIC is set in the parent shell. In the case the later is likely
> > to cause trouble, would it be appropriate to issue a warning when R is
> > initialized ?
>
> Of course R does not violate its own documentation. None of the R
> executables reset the LC_NUMERIC locale category, and all C programs start
> in the 'C' locale (both facts you should have known from the homework
> you did before posting).
>
> BDR
>
> >
> >
> > Laurent
> >
> >
> >
> > On Fri, 2008-11-14 at 19:37 +, Prof Brian Ripley wrote:
> >> On Fri, 14 Nov 2008, laurent wrote:
> >>
> >>> Dear list,
> >>>
> >>> A problem with creating pdf or postscript plots from an embedded R, and
> >>> in an environment where a locale is defined, was recently reported on
> >>> the rpy (Python->R interface) mailing list.
> >>>
> >>> The problem appears to be that whenever the locale defines ',' as a
> >>> separator for the decimal part of a numerical value, the pdf/ps file
> >>> generated still has the ',' instead of a '.' causing problem when open
> >>> the resulting file with a postscript/pdf viewer.
> >>>
> >>> Of course, an obvious workaround would be to force the locale for
> >>> numbers to C ( LC_NUMERIC = "C" ), but that could be overriding
> >>> internationalization features otherwise in R.
> >>>
> >>> Any advice ?
> >>
> >> Don't set LC_NUMERIC with R: ?Sys.setlocale did warn you about that.
> >> It used to cause far more problems than this.
> >>
> >
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Computing minimal detectable differences for general ANOVA models
On Sun, 16 Nov 2008, Ali Baharev wrote: Dear Developers, I would like to contribute to the R Project. I implemented a C function the can be used to calculate minimal detectable differences for general ANOVA models (sample size calculations, power analysis). A demo program and the source code is available from my website: http://reliablecomputing.eu/ncbeta.html What should i do in order to make my ncbeta function part of the R project source distribution? Everyone can contribute code as a package: code in the source distribution is by members of R-core only, including in a few cases code they choose to adopt (with permission) from others. Most importantly, R-core has to commit to maintenance of such code indefinitely, and these days we are very reluctant to do so. Probably the most troublesome parts of my code are those where error may occur, i do not know much about the proper error handling in R. So you need to find out before distributing a package. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Computing minimal detectable differences for general ANOVA models
Ali Baharev wrote: Dear Developers, I would like to contribute to the R Project. I implemented a C function the can be used to calculate minimal detectable differences for general ANOVA models (sample size calculations, power analysis). A demo program and the source code is available from my website: http://reliablecomputing.eu/ncbeta.html What should i do in order to make my ncbeta function part of the R project source distribution? As Brian said in a separate message, build an R package and distribute one or more R documented functions that all the C code. See the Writing R Extension's manual. Probably the most troublesome parts of my code are those where error may occur, i do not know much about the proper error handling in R. Calls to exit() as in your C code should be replaced with calls to PROBLEM "the error message" ERROR Again, the R manuals (Writing R Extensions) will give you the information you need. Many thanks, Ali P.S. I see my suggestions https://stat.ethz.ch/pipermail/r-devel/2008-April/049317.html were considered in R 2.8.0. __ 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] 'by' with one-dimensional array
I've played a bit with the problem that Jeff Laake
reported on R-help:
# create data:
jl <- data.frame(x=rep(1, 3), y=tapply(1:9, rep(c('A','B','C'), each=3),
sum))
jl2 <- jl
jl2$y <- as.numeric(jl2$y)
# do the test:
> tapply(jl$y, jl$x, length)
1
3
> tapply(jl2$y, jl2$x, length)
1
3
> by(jl2$y, jl2$x, length)
jl2$x: 1
[1] 3
> by(jl$y, jl$x, length)
INDICES: 1
[1] 1
The result of 'by' on the 1-dimensional array is
giving the correct answer to a question that I don't
think many of us thought we were asking.
Once upon a time 'by' gave 3 as the answer in both
situations.
'by.default' used to be a one-liner, but now decides
what to do based on 'length(dim(data))'.
This specific problem goes away if the line:
if (length(dim(data)))
is replaced by:
if(length(dim(data)) > 1)
But I don't know what other mischief such a change
would make.
Patrick Burns
[EMAIL PROTECTED]
+44 (0)20 8525 0696
http://www.burns-stat.com
(home of S Poetry and "A Guide for the Unwilling S User")
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Diagnosing Crashes on garbage collection
I'm having problems with an access violation error on some compiled code that I'm writing and I was hoping that some one had insights as to what might be causing the access violation and possibly how to remedy it. Here's the situation. The compiled code performs an EM algorithm on the data for given penalty parameters. The penalty parameters are estimated through optim on the cross validated log likelihood. The program works most of the time. When the EM Algorithm fails to converge the program crashes on garbage collection. Although this makes little sense, as there is no special computations when the algorithm fails to converge. The compiled code can either free it's used memory or let R's garbage collection take care of it, it makes no differeence, the program still crashes. Any help on trying to either fix or even help on figuring it out, like tools to use, would be a great help. Thanks, Andrew [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Diagnosing Crashes on garbage collection
On Sun, 16 Nov 2008, Andrew Redd wrote: I'm having problems with an access violation error on some compiled code that I'm writing and I was hoping that some one had insights as to what might be causing the access violation and possibly how to remedy it. If you are using (or can use) Linux, then valgrind is an excellent tool for this. There's some documentation in 'Writing R Extensions'. Valgrind runs your code in a virtual machine and tracks all memory accesses, so it often will even find bugs in C code that are hard to reproduce. -thomas Thomas Lumley Assoc. Professor, Biostatistics [EMAIL PROTECTED] University of Washington, Seattle __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fw: alpha transparency crashes R
Hi
Deepayan Sarkar wrote:
> I'm forwarding a bug report from Jeff Gove that didn't make it to the list.
> -Deepayan
>
> --- Original Message
> Subject: alpha transparency crashes R
> Date: Fri, 07 Nov 2008 14:32:27 -0500
> From: jeff gove <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
>
>
> I ran into a problem with R crashing when a certain number of
> transparent objects (e.g., symbols) are sent to a PDF output device.
> This has happened on R 2.71, 2.7.2 (Fedora 8 and Ububtu 8.04
> platforms) and now 2.8.0 (I've only tried Fedora 8). The current
> pertinent R system stats are...
>
> R.version
>_
> platform x86_64-redhat-linux-gnu
> arch x86_64
> os linux-gnu
> system x86_64, linux-gnu
> status
> major 2
> minor 8.0
> year 2008
> month 10
> day20
> svn rev46754
> language R
> version.string R version 2.8.0 (2008-10-20)
>
> The following small example program when run with n large enough
> (e.g., n=1000) and transparency will crash R...
>
> alphaBomb.r = function(n=100, wantAlpha=T) {
>df = data.frame(a=rnorm(n),b=runif(n))
>if(wantAlpha)
> alpha=runif(n)
>else
> alpha = 1
>j = xyplot(b~a, df, alpha=alpha, pch=19)
>print(j)
>trellis.device('pdf',file='alphaBomb.pdf',version='1.4')
>print(j)
>dev.off()
> }
>
> Please note that the crash seems to occur in the dev.off() component,
> and that the file actually seems to get written out correctly. The
> trace of the bomb is found below, excluding the memory map. Please
> also note that it may be somehow related to grid, as the following
> code (supplied by Deepayan Sarkar) using base graphics does not crash
> R, even with n=10...
>
> pdf()
> n = 1000
> plot(rnorm(n), rnorm(n), col = rgb(0, 0, 0, alpha = runif(n)), pch = 16)
> dev.off()
Grid runs laughing from your puny accusations!
This will tickle the problem too:
plot(rnorm(n), rnorm(n), col = rgb(0, 0, 0, alpha = runif(n)), pch = 19)
The issue appears to be in the PDF device driver, which has a fixed-size
integer array called pd->pos and those larger examples are generating
"too many" different alpha values so that we end up assigning values
out-of-range for that array.
The simple fix is to bump up the initial size of the pd->pos array, but
there is some heuristic code in devPS.c (PDF_NewPage) that appears to be
trying to resize the array on-the-fly based on how many pages are being
generated, so perhaps this needs a bit more thought.
Thanks for the bug report!
Paul
> The error trace from the above alphaBomb.r() code is...
>
> R> alphaBomb.r(100) #this is fine
> X11cairo
>2
>
> R> alphaBomb.r(1000,F) #also fine
>
> R> alphaBomb.r(1000)
> *** glibc detected *** /usr/lib64/R/bin/exec/R: double free or
> corruption (!prev): 0x032c1d90 ***
> === Backtrace: =
> /lib64/libc.so.6[0x3ee8c72832]
> /lib64/libc.so.6(cfree+0x8c)[0x3ee8c75f2c]
> /usr/lib64/R/library/grDevices/libs/grDevices.so[0x2aaab000b0fc]
> /usr/lib64/R/lib/libR.so[0x3d1f48ddd3]
> /usr/lib64/R/lib/libR.so[0x3d1f48e2dc]
> /usr/lib64/R/lib/libR.so[0x3d1f4ec81c]
> /usr/lib64/R/lib/libR.so(Rf_eval+0x42e)[0x3d1f4be8ae]
> /usr/lib64/R/lib/libR.so[0x3d1f4bf572]
> /usr/lib64/R/lib/libR.so(Rf_eval+0x42e)[0x3d1f4be8ae]
> /usr/lib64/R/lib/libR.so(Rf_applyClosure+0x291)[0x3d1f4c0bf1]
> /usr/lib64/R/lib/libR.so(Rf_eval+0x303)[0x3d1f4be783]
> /usr/lib64/R/lib/libR.so[0x3d1f4bf572]
> /usr/lib64/R/lib/libR.so(Rf_eval+0x42e)[0x3d1f4be8ae]
> /usr/lib64/R/lib/libR.so(Rf_applyClosure+0x291)[0x3d1f4c0bf1]
> /usr/lib64/R/lib/libR.so(Rf_eval+0x303)[0x3d1f4be783]
> /usr/lib64/R/lib/libR.so(Rf_ReplIteration+0x188)[0x3d1f4dc878]
> /usr/lib64/R/lib/libR.so[0x3d1f4dcb90]
> /usr/lib64/R/lib/libR.so(run_Rmainloop+0x50)[0x3d1f4dcec0]
> /usr/lib64/R/bin/exec/R(main+0x1b)[0x40082b]
> /lib64/libc.so.6(__libc_start_main+0xf4)[0x3ee8c1e074]
> /usr/lib64/R/bin/exec/R[0x400729]
> === Memory map:
> etc...
>
> Please note that R only crashes with PDF output; tiff, png and eps
> (even though it doesn't accept transparency) all exit cleanly.
>
> My version of glibc is 2.7.
>
> Thanks, I hope that the problem is already resolved!
>
> Jeff
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
[EMAIL PROTECTED]
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Fwd: Fwd: SWIG with R and C++ STL
On Thu, Nov 6, 2008 at 11:29 AM, Whit Armstrong <[EMAIL PROTECTED]>wrote:
> did you wrap your function prototype in extern "C" ?
>
> -Whit
>
>
>
Hi Whit,
Thanks for replying my question. I already gave up my own code and now I am
trying with the examples from SWIG Doc 1.3. I can not even reproduce one of
their examples in section 5.4.9. I wonder if you can have a look at my code
and figure out what's wrong there for me. I used the extern "C" this time
and the details is as following:
-test.i--
%module test
%{
#include "test.h"
%}
%include "test.h"
%callback("%s_cb");
int myadd( int, int ); //myadd_cb
int mysub( int, int ); //mysub_cb
int mymul( int, int ); //mymul_cb
%nocallback;
---test.h--
extern "C"{
int binary_op(int a, int b, int (*op)(int,int) );
int myadd( int a, int b ) { return a+b; };
int mysub( int a, int b ) { return a-b; };
int mymul( int a, int b ) { return a*b; };
}
-
--error message--
> dyn.load("test.so")
Error in dyn.load("test.so") :
unable to load shared library '/home/charlie/workspace/lla/test.so':
/home/charlie/workspace/lla/test.so: undefined symbol: binary_op
--
--compiling message--
swig -v -r -c++ -o test_wrap.cpp test.i
LangSubDir: r
Search paths:
./
./swig_lib/r/
/usr/local/share/swig/1.3.36/r/
./swig_lib/
/usr/local/share/swig/1.3.36/
Preprocessing...
Starting language-specific parse...
Processing types...
C++ analysis...
Generating wrappers...
Type: p.f(int,int).int
Return type: int
R CMD SHLIB test.cpp test_wrap.cpp
make[1]: Entering directory `/home/charlie/workspace/lla'
g++ -I/usr/local/lib/R/include -I/usr/local/lib/R/include
-I/usr/local/include-fpic -g -O2 -c test_wrap.cpp -o test_wrap.o
g++ -shared -L/usr/local/lib -o test.so test.o test_wrap.o
make[1]: Leaving directory `/home/charlie/workspace/lla'
--
Many thanks!
Charlie
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fwd: Fwd: SWIG with R and C++ STL
I don't know about your examples from section 5.4.9 of the swig manual, but
the very basic SWIG example I have played with still works:
[EMAIL PROTECTED]:~/src/progs/swig/R> cat example.c
/* File : example.c */
double My_variable = 3.0;
/* Compute factorial of n */
int fact(int n) {
if (n <= 1) return 1;
else return n*fact(n-1);
}
/* Compute n mod m */
int my_mod(int n, int m) {
return(n % m);
}
[EMAIL PROTECTED]:~/src/progs/swig/R> cat example.i
/* File : example.i */
%module example
%{
/* Put headers and other declarations here */
extern double My_variable;
extern intfact(int);
extern intmy_mod(int n, int m);
%}
extern double My_variable;
extern intfact(int);
extern intmy_mod(int n, int m);
[EMAIL PROTECTED]:~/src/progs/swig/R> cat testR.r
#!/usr/bin/r
dyn.load("example_wrap.so")
source("example_wrap.R")
print(fact(4))
print(My_variable_get())
print(my_mod(77,66))
[EMAIL PROTECTED]:~/src/progs/swig/R> cat makeR.sh
#!/bin/sh
set +e
set +u
rm -vf *.o *.so
swig -r example.i
PKG_LIBS="example.c" R CMD SHLIB example_wrap.c
#./testR.sh
./testR.r
./[EMAIL PROTECTED]:~/src/progs/swig/R> ./makeR.sh
removed `example_wrap.o'
removed `example_wrap.so'
gcc -std=gnu99 -I/usr/share/R/include -fpic -g -O2 -c example_wrap.c -o
example_wrap.o
gcc -std=gnu99 -shared -o example_wrap.so example_wrap.o example.c
-L/usr/lib/R/lib -lR
Creating a new generic function for "print" in ".GlobalEnv"
[1] 24
[1] 3
[1] 11
[EMAIL PROTECTED]:~/src/progs/swig/R>
I haven't really tried anything much more complicated.
Swig 1.3.36, R 2.8.0, g++ 4.3.2 on Debian testing.
Hope this helps, Dirk
--
Three out of two people have difficulties with fractions.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Diagnosing Crashes on garbage collection
On Sun, 16 Nov 2008, Thomas Lumley wrote: On Sun, 16 Nov 2008, Andrew Redd wrote: I'm having problems with an access violation error on some compiled code that I'm writing and I was hoping that some one had insights as to what might be causing the access violation and possibly how to remedy it. If you are using (or can use) Linux, then valgrind is an excellent tool for this. There's some documentation in 'Writing R Extensions'. Valgrind runs your code in a virtual machine and tracks all memory accesses, so it often will even find bugs in C code that are hard to reproduce. And if it is R's garbage collection that is the issue, using gctorture(TRUE) (with valgrind if possible) will provoke the problem at the earlist opportunity. There is a section in 'Writing R Extensions' on that too. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] chisq.test with simulate.p.value=TRUE (PR#13292)
Full_Name: Reginaldo Constantino Version: 2.8.0 OS: Ubuntu Hardy (32 bit, kernel 2.6.24) Submission from: (NULL) (189.61.88.2) For many tables, chisq.test with simulate.p.value=TRUE gives a p value that is obviously incorrect and inversely proportional to the number of replicates: > data(HairEyeColor) > x <- margin.table(HairEyeColor, c(1, 2)) > chisq.test(x,simulate.p.value=TRUE,B=2000) Pearson's Chi-squared test with simulated p-value (based on 2000 replicates) data: x X-squared = 138.2898, df = NA, p-value = 0.0004998 > chisq.test(x,simulate.p.value=TRUE,B=1) X-squared = 138.2898, df = NA, p-value = 1e-04 > chisq.test(x,simulate.p.value=TRUE,B=10) X-squared = 138.2898, df = NA, p-value = 1e-05 > chisq.test(x,simulate.p.value=TRUE,B=100) X-squared = 138.2898, df = NA, p-value = 1e-06 ... Also tested the same R version under Windows XP and got the same results. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#13287) Line breaks in mathematical formulae in Rd files
Thanks, Prof Ripley, I do have noticed the manual; what I mean is the
"displaymath" environment might not be appropriate for R documentation
when there are multiple lines of formulae; I'm sorry this seems to be
a suggestion rather than a bug... According to your response, the only
solution is write several displayed equations when a single equation
is too long?
Regards,
Yihui
--
Yihui Xie <[EMAIL PROTECTED]>
Phone: +86-(0)10-82509086 Fax: +86-(0)10-82509086
Mobile: +86-15810805877
Homepage: http://www.yihui.name
School of Statistics, Room 1037, Mingde Main Building,
Renmin University of China, Beijing, 100872, China
On Sat, Nov 15, 2008 at 12:29 AM, Prof Brian Ripley
<[EMAIL PROTECTED]> wrote:
> I think the 'problem' is a lack of attention to the manual.
>
> deqn gives "displayed equations" (as in LaTeX's displaymath environment,
> or TeX's $$...$$).
>
> seems pretty clear to me, and I hope to any LaTeX user.
>
> On Fri, 14 Nov 2008, [EMAIL PROTECTED] wrote:
>
>> Hi,
>>
>> This is a problem about writing R documentation (R-exts 2.6). The
>> command "\deqn" defined in "Rd.sty" is:
>>
>> \newcommand{\deqn}[2]{\[#1\]}
>>
>> which will put mathematical formulae in the "displaymath" environment;
>
> Well, surprise, surprise it does what it is documented to do!
>
I didn't mean there was something wrong - I was just explaining the
definition which could be modified as below.
>> that means line breaks are not allowed (or will not be shown) in
>> formulae, but sometimes we do need multiple lines of formulae. One
>> solution is to write several equations using "\deqn", but I think to
>> change the definition of "\deqn" is better:
>>
>> \newcommand{\deqn}[2]{\begin{eqnarray*}#1\end{eqnarray*}}
>
> That will change the spacing.
>
>> This will not change the pdfLaTeX output effect, moreover, line breaks
>> and alignments using "&" will be available in math formulae.
>
> Not to the non-latex conversions.
OK, I see. Thanks!
>
>> Regards,
>> Yihui
>> --
>> Yihui Xie <[EMAIL PROTECTED]>
>> Phone: +86-(0)10-82509086 Fax: +86-(0)10-82509086
>> Mobile: +86-15810805877
>> Homepage: http://www.yihui.name
>> School of Statistics, Room 1037, Mingde Main Building,
>> Renmin University of China, Beijing, 100872, China
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> --
> Brian D. Ripley, [EMAIL PROTECTED]
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] help.start() displays index.html in emacs (PR#13293)
Full_Name: Juergen Rose
Version: 2.8.0 (2008-10-20)
OS: Linux 2.6.27.4 x86_64 Intel
Submission from: (NULL) (87.185.220.122)
If I start as ordinary user rose R and help.start(), the help is displayed in
emacs. If I do as the user root, file:///tmp/Rtmpyzlc7Y/.R/doc/html/index.html
is shown as expected in a firefox windows. So it seems to be connected with my
private configuration. But I can not find such a configurations:
[EMAIL PROTECTED]:/home/rose(114)$ ll ~/.R*
-rw-r--r-- 1 rose users 2369 Jan 20 2008 /home/rose/.RapidSVN
I also tried to start R with strace:
[EMAIL PROTECTED]:/home/rose(119)$ strace -f -o R_strace.log R
and greped for mime:
[EMAIL PROTECTED]:/home/rose(120)$ grep "open.*rose.*mime" R_strace.log
7221 open("/home/rose/.local/share//mime/mime.cache", O_RDONLY) = 14
7221 open("/home/rose/.local/share/applications/mimeinfo.cache", O_RDONLY) =
14
7221 open("/home/rose/.local/share/applications/mimeapps.list", O_RDONLY) = 14
7223 open("/home/rose/.local/share//mime/mime.cache", O_RDONLY) = 7
and then I searched for emacs in these files:
[EMAIL PROTECTED]:/home/rose(121)$ for f in
/home/rose/.local/share//mime/mime.cache
/home/rose/.local/share/applications/mimeinfo.cache
/home/rose/.local/share/applications/mimeapps.list
/home/rose/.local/share//mime/mime.cache; do echo "-- f=$f
--"; grep emacs $f ; done
-- f=/home/rose/.local/share//mime/mime.cache --
-- f=/home/rose/.local/share/applications/mimeinfo.cache
--
application/x-x509-ca-cert=emacs-21-usercustom.desktop
-- f=/home/rose/.local/share/applications/mimeapps.list
--
-- f=/home/rose/.local/share//mime/mime.cache --
But I could not find anything suspicious
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
