[Rd] parsing Rd files and \deqn{}
Hi
[R-2.9.0]
I am having difficulty including a LaTeX formula in an Rd
file.
The example given in section 2.7 in 'Parsing Rd files' is:
\deqn{ f(x) = \left\{
\begin{array}{ll}
0 x0 \\
1 x\ge 0
\end{array}
\right. }{non latex}
For me, this gives:
\deqn{ f(x) = \left\{
\begin{array}{ll}
0 \ x0 \bsl{}
1 \ x\ge 0
\end{array}
\right. }{}
in the tex file, which is not desired because the ampersand
is escaped; the '' symbol appears in the dvi file, and I
want an ampersand to indicate alignment.
Also, the '\\' appears as \bsl{}, which is undesired; the
resulting dvi file (made by R CMD Rd2dvi) looks wrong.
How do I write the Rd file so as to produce non-escaped
ampersands?
--
Robin K. S. Hankin
Uncertainty Analyst
University of Cambridge
19 Silver Street
Cambridge CB3 9EP
01223-764877
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] unexpected behavior of rpart 3.1-43, loss matrix
Hi, I just noticed that rpart behaves unexpectecly, when performing classification learning and specifying a loss matrix. if the response variable y is a factor and if not all levels of the factor occur in the observations, rpart exits with an error: df=data.frame(attr=1:5,class=factor(c(2,3,1,5,3),levels=1:6)) rpart(class~attr,df,parms=list(loss=matrix(0,6,6))) Error in (get(paste(rpart, method, sep = .)))(Y, offset, parms, wt) : Wrong length for loss matrix note that while the levels of the factor range from 1:6, for the concrete obseration data, only levels 1, 2, 3, 5 do occur. the error is caused by the code of rpart.class: fy - as.factor(y) y - as.integer(fy) numclass - max(y[!is.na(y)]) ... temp2 - parms$loss if (length(temp2) != numclass^2) stop(Wrong length for loss matrix) for the example, numclass is set to 5 instead of 6. while for that small example, it may be discussable whether or not numclass should be 6, consider a set of data for that the response variable has a certain range. Then, it may be the case that for some data, not all levels of the response variable do occur. at the same time, it is desirable to use the same loss matrix when training a deicision tree from the data. having said that, i am very happy with the rpart package and with its high configurability. best regards lars __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NA_real_ op NaN - NA or NaN, should we care?
William Dunlap wdun...@tibco.com on Thu, 30 Apr 2009 10:51:43 -0700 writes: On Linux when I compile R 2.10.0(devel) (src/main/arithmetic.c in particular) with gcc 3.4.5 using the flags -g -O2 I get noncommutative behavior when is this really gcc 3.4.5 (which is quite old) ? Without being an expert, I'd tend to claim this to be a compiler (optimization) bug but most probably the ANSI / ISO C (and libc ?) standards would not define the exact behavior of arithmetic with NaNs. adding NA and NaN: NA_real_ + NaN [1] NaN NaN + NA_real_ [1] NA If I compile src/main/arithmetic.c without optimization (just -g) then both of those return NA. On Windows, using a precompiled R 2.8.1 from CRAN I get NA for both answers. On Linux, after compiling src/main/arithmetic.c with -g -O2 the bit patterns for NA_real_ and as.numeric(NA) are different: my_numeric_NA - as.numeric(NA) writeBin(my_numeric_NA, ptmp-pipe(od -x, open=wb));close(ptmp) 000 07a2 7ff8 010 writeBin(NA_real_, ptmp-pipe(od -x, open=wb));close(ptmp) 000 07a2 7ff0 010 On Linux, after compiling with -g the bit patterns for NA_real_ and as.numeric(NA) are identical. my_numeric_NA - as.numeric(NA) writeBin(my_numeric_NA, ptmp-pipe(od -x, open=wb));close(ptmp) 000 07a2 7ff8 010 writeBin(NA_real_, ptmp-pipe(od -x, open=wb));close(ptmp) 000 07a2 7ff8 010 On Windows, using precompiled R 2.8.1 and cygwin/bin/od, both of those gave the 7ff8 version. Is this confounding of NA and NaN of concern or does R not promise to keep NA and NaN distinct? Hmm, I'd say it *is* of some concern that + is not commutative in the narrow sense, even if I don't know what exactly R promises. I haven't followed all the macros, but it looks like arithmetic.c just does result[i]=x[i]+y[i] and lets the compiler/floating point unit decide what to do when x[i] and y[i] are different NaN values (NA is a NaN value). I haven't looked at the C code for the initialization of NA_real_. Adding explicit tests for NA-ness in the binary operators (as S+ does) adds a fairly significant cost. Yes, I would be quite reluctant to add such tests, because such costs are to be expected. Maybe we (R :-) should explicitly state that operations mixing NA NaN give a result which is NA in the sense of fulfilling is.na(.) but *not* promise anything further. Martin Maechler, ETH Zurich Bill Dunlap TIBCO Software Inc - Spotfire Division wdunlap tibco.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NA_real_ op NaN - NA or NaN, should we care?
MM == Martin Maechler maech...@stat.math.ethz.ch
on Fri, 1 May 2009 14:14:58 +0200 writes:
William Dunlap wdun...@tibco.com
on Thu, 30 Apr 2009 10:51:43 -0700 writes:
On Linux when I compile R 2.10.0(devel) (src/main/arithmetic.c in
particular)
with gcc 3.4.5 using the flags -g -O2 I get noncommutative behavior when
MM is this really gcc 3.4.5 (which is quite old) ?
MM Without being an expert, I'd tend to claim this to be a
MM compiler (optimization) bug but most probably the ANSI /
MM ISO C (and libc ?) standards would not define the exact
MM behavior of arithmetic with NaNs.
adding NA and NaN:
NA_real_ + NaN
[1] NaN
NaN + NA_real_
[1] NA
If I compile src/main/arithmetic.c without optimization (just -g)
then both of those return NA.
On Windows, using a precompiled R 2.8.1 from CRAN I get
NA for both answers.
On Linux, after compiling src/main/arithmetic.c with -g -O2 the bit
patterns for NA_real_ and as.numeric(NA) are different:
my_numeric_NA - as.numeric(NA)
writeBin(my_numeric_NA, ptmp-pipe(od -x, open=wb));close(ptmp)
000 07a2 7ff8
010
writeBin(NA_real_, ptmp-pipe(od -x, open=wb));close(ptmp)
000 07a2 7ff0
010
On Linux, after compiling with -g the bit patterns for NA_real_
and as.numeric(NA) are identical.
my_numeric_NA - as.numeric(NA)
writeBin(my_numeric_NA, ptmp-pipe(od -x, open=wb));close(ptmp)
000 07a2 7ff8
010
writeBin(NA_real_, ptmp-pipe(od -x, open=wb));close(ptmp)
000 07a2 7ff8
010
On Windows, using precompiled R 2.8.1 and cygwin/bin/od, both of those
gave the 7ff8 version.
I've run a couple of
echo 'c(NA+NaN, NaN+NA)' | R --slave --vanilla
on 3 different platforms, all Linux, and many installed versions
of R -- all of which compiled with defaults, i.e. '-O2',
and depending on its release date, compiled with
different versions of gcc {I can still check these
because I run R from the installation directory, with
all configure results ..}
on a given platform, and have observed the following:
The result is always NA NA (as desired!) iff the platform is 32-bit,
whereas it isNaN NA for the 64-bit platform and older
versions of R (R = 2.3.1)
and NA NaN for versions of R (= 2.4.1)
{{but note: the versions of R are confounded with the versions of gcc ...}}
Further, as the 64-bit platform can also use the 32-bit versions of R,
I've tested a few and found that indeed, the 32-bit version of R
would return NA NA also on the 64-bit platform.
Martin
Is this confounding of NA and NaN of concern or does R not promise to
keep NA and NaN distinct?
MM Hmm, I'd say it *is* of some concern that + is not commutative
MM in the narrow sense, even if I don't know what exactly R promises.
I haven't followed all the macros, but it looks like arithmetic.c just
does
result[i]=x[i]+y[i]
and lets the compiler/floating point unit decide what to do when x[i]
and y[i]
are different NaN values (NA is a NaN value). I haven't looked at the C
code
for the initialization of NA_real_. Adding explicit tests for NA-ness
in the
binary operators (as S+ does) adds a fairly significant cost.
MM Yes, I would be quite reluctant to add such
MM tests, because such costs are to be expected.
MM Maybe we (R :-) should explicitly state that operations mixing
MM NA NaN give a result which is NA in the sense of fulfilling is.na(.)
MM but *not* promise anything further.
MM Martin Maechler, ETH Zurich
Bill Dunlap
TIBCO Software Inc - Spotfire Division
wdunlap tibco.com
MM __
MM R-devel@r-project.org mailing list
MM 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] NA_real_ op NaN - NA or NaN, should we care?
On 5/1/2009 8:14 AM, Martin Maechler wrote: William Dunlap wdun...@tibco.com on Thu, 30 Apr 2009 10:51:43 -0700 writes: On Linux when I compile R 2.10.0(devel) (src/main/arithmetic.c in particular) with gcc 3.4.5 using the flags -g -O2 I get noncommutative behavior when is this really gcc 3.4.5 (which is quite old) ? Without being an expert, I'd tend to claim this to be a compiler (optimization) bug but most probably the ANSI / ISO C (and libc ?) standards would not define the exact behavior of arithmetic with NaNs. Here are a few bits of information, not particularly well organized: I don't know if the IEEE 754 (or the ISO equivalent) specifies the behaviour, but the hardware handling of NaNs is inconsistent on Intel chips. If two NaNs are involved in an operation, it returns the one with the larger significand when operations are done in the FPU, it returns the first one when they are done in the SSE. Our NA has a bigger significand than the default NaN, but there are NaNs that are bigger. (We're unlikely to see those in the results of arithmetic under our control, but there's nothing to stop external code from returning one, or getting one via readBin from a file.) The type can be either quiet or signalling; our NA is a signalling NaN, and the one Bill was getting from the as.numeric conversion is a quiet NaN. However, our IsNA test doesn't look at the bits determining that status, it only looks at the 07a2 part, so both are displayed as NA. I haven't traced the coercion code to know why they aren't identical, but I think it doesn't matter: the FPU and SSE methods are inconsistent for most pairs of operands. All of which leads me to conclude that we should either say we don't guarantee what happens when you mix NA with NaN, or we should add an explicit test to every operation. I'd prefer the no guarantees solution. Duncan Murdoch adding NA and NaN: NA_real_ + NaN [1] NaN NaN + NA_real_ [1] NA If I compile src/main/arithmetic.c without optimization (just -g) then both of those return NA. On Windows, using a precompiled R 2.8.1 from CRAN I get NA for both answers. On Linux, after compiling src/main/arithmetic.c with -g -O2 the bit patterns for NA_real_ and as.numeric(NA) are different: my_numeric_NA - as.numeric(NA) writeBin(my_numeric_NA, ptmp-pipe(od -x, open=wb));close(ptmp) 000 07a2 7ff8 010 writeBin(NA_real_, ptmp-pipe(od -x, open=wb));close(ptmp) 000 07a2 7ff0 010 On Linux, after compiling with -g the bit patterns for NA_real_ and as.numeric(NA) are identical. my_numeric_NA - as.numeric(NA) writeBin(my_numeric_NA, ptmp-pipe(od -x, open=wb));close(ptmp) 000 07a2 7ff8 010 writeBin(NA_real_, ptmp-pipe(od -x, open=wb));close(ptmp) 000 07a2 7ff8 010 On Windows, using precompiled R 2.8.1 and cygwin/bin/od, both of those gave the 7ff8 version. Is this confounding of NA and NaN of concern or does R not promise to keep NA and NaN distinct? Hmm, I'd say it *is* of some concern that + is not commutative in the narrow sense, even if I don't know what exactly R promises. I haven't followed all the macros, but it looks like arithmetic.c just does result[i]=x[i]+y[i] and lets the compiler/floating point unit decide what to do when x[i] and y[i] are different NaN values (NA is a NaN value). I haven't looked at the C code for the initialization of NA_real_. Adding explicit tests for NA-ness in the binary operators (as S+ does) adds a fairly significant cost. Yes, I would be quite reluctant to add such tests, because such costs are to be expected. Maybe we (R :-) should explicitly state that operations mixing NA NaN give a result which is NA in the sense of fulfilling is.na(.) but *not* promise anything further. Martin Maechler, ETH Zurich Bill Dunlap TIBCO Software Inc - Spotfire Division wdunlap tibco.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
Re: [Rd] NA_real_ op NaN - NA or NaN, should we care?
From: Martin Maechler [mailto:maech...@stat.math.ethz.ch]
Sent: Friday, May 01, 2009 5:15 AM
To: William Dunlap
Cc: r-devel@r-project.org
Subject: Re: [Rd] NA_real_ op NaN - NA or NaN, should we care?
William Dunlap wdun...@tibco.com
on Thu, 30 Apr 2009 10:51:43 -0700 writes:
On Linux when I compile R 2.10.0(devel)
(src/main/arithmetic.c in
particular)
with gcc 3.4.5 using the flags -g -O2 I get
noncommutative behavior when
is this really gcc 3.4.5 (which is quite old) ?
Yes, it was 3.4.5, but here is a self-contained example of the same
issue using gcc 4.1.3 on an Ubuntu Linux machine:
% gcc -O2 t.c -o a.out ; ./a.out
NA : 7ff007a2
NaN: fff8
NA+NaN: 7ff807a2
NaN+NA: fff8
% gcc t.c -o a.out ; ./a.out
NA : 7ff007a2
NaN: fff8
NA+NaN: 7ff807a2
NaN+NA: 7ff807a2
% gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1
--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug
--enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
% cat t.c
#include stdio.h
#include stdint.h
#include string.h
int main(int argc, char *argv[])
{
int64_t NA_int64 = 0x7ff007a2LL ;
int64_t NaN_int64 = 0xfff8LL ;
int64_t sum_int64 ;
double NA_double, NaN_double, sum_double ;
memcpy((void*)NA_double, (void*)NA_int64, 8) ;
memcpy((void*)NaN_double, (void*)NaN_int64, 8) ;
NaN_double = 1/0.0 - 1/0.0 ;
printf(NA : %Lx\n, *(int64_t*)NA_double);
printf(NaN: %Lx\n, *(int64_t*)NaN_double);
sum_double = NA_double + NaN_double ;
memcpy((void*)sum_int64, (void*)sum_double, 8) ;
printf(NA+NaN: %Lx\n, sum_int64) ;
sum_double = NaN_double + NA_double ;
memcpy((void*)sum_int64, (void*)sum_double, 8) ;
printf(NaN+NA: %Lx\n, sum_int64);
return 0 ;
}
When I add -Wall to the -O2 then it gives me some warnings about the
*(int64_t)doubleVal in the printf statements for the inputs, but I used
memcpy() to avoid the warnings when printing the outputs.
% gcc -Wall -O2 t.c -o a.out ; ./a.out
t.c: In function âmainâ:
t.c:17: warning: dereferencing type-punned pointer will break strict-aliasing
rules
t.c:18: warning: dereferencing type-punned pointer will break strict-aliasing
rules
NA : 7ff007a2
NaN: fff8
NA+NaN: 7ff807a2
NaN+NA: fff8
Bill Dunlap
TIBCO Software Inc - Spotfire Division
wdunlap tibco.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NA_real_ op NaN - NA or NaN, should we care?
The optimizer in gcc 4.2 (but not 4.1) on Linux seems to get this
issue right on one of my test machines (a 32-bit Ubuntu box).
4.1 fails on a 64-bit Linux but I don't have a newer gcc on any
64-bit Linux machine I can find.
A cleaner version of the test is:
% cat t.c
#include stdio.h
#include stdint.h
#include string.h
void print_double(char *text, double x_double)
{
int64_t x_int64 ;
memcpy((void*)x_int64, (void*)x_double, 8) ;
printf(%s: %Lx (%g)\n, text, x_int64, x_double) ;
}
int main(int argc, char *argv[])
{
int64_t NA_int64 = 0x7ff007a2LL ;
int64_t NaN_int64 = 0xfff8LL ;
double NA_double, NaN_double, sum_double ;
memcpy((void*)NA_double, (void*)NA_int64, 8) ;
memcpy((void*)NaN_double, (void*)NaN_int64, 8) ;
print_double( NA, NA_double);
print_double(NaN, NaN_double);
sum_double = NA_double + NaN_double ;
print_double(NA+NaN, sum_double) ;
sum_double = NaN_double + NA_double ;
print_double(NaN+NA, sum_double);
return 0 ;
}
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 William Dunlap
Sent: Friday, May 01, 2009 7:50 AM
To: Martin Maechler
Cc: r-devel@r-project.org
Subject: Re: [Rd] NA_real_ op NaN - NA or NaN, should we care?
From: Martin Maechler [mailto:maech...@stat.math.ethz.ch]
Sent: Friday, May 01, 2009 5:15 AM
To: William Dunlap
Cc: r-devel@r-project.org
Subject: Re: [Rd] NA_real_ op NaN - NA or NaN, should we care?
William Dunlap wdun...@tibco.com
on Thu, 30 Apr 2009 10:51:43 -0700 writes:
On Linux when I compile R 2.10.0(devel)
(src/main/arithmetic.c in
particular)
with gcc 3.4.5 using the flags -g -O2 I get
noncommutative behavior when
is this really gcc 3.4.5 (which is quite old) ?
Yes, it was 3.4.5, but here is a self-contained example of the same
issue using gcc 4.1.3 on an Ubuntu Linux machine:
% gcc -O2 t.c -o a.out ; ./a.out
NA : 7ff007a2
NaN: fff8
NA+NaN: 7ff807a2
NaN+NA: fff8
% gcc t.c -o a.out ; ./a.out
NA : 7ff007a2
NaN: fff8
NA+NaN: 7ff807a2
NaN+NA: 7ff807a2
% gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang
--prefix=/usr --enable-shared --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.1.3
--program-suffix=-4.1 --enable-__cxa_atexit
--enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
% cat t.c
#include stdio.h
#include stdint.h
#include string.h
int main(int argc, char *argv[])
{
int64_t NA_int64 = 0x7ff007a2LL ;
int64_t NaN_int64 = 0xfff8LL ;
int64_t sum_int64 ;
double NA_double, NaN_double, sum_double ;
memcpy((void*)NA_double, (void*)NA_int64, 8) ;
memcpy((void*)NaN_double, (void*)NaN_int64, 8) ;
NaN_double = 1/0.0 - 1/0.0 ;
printf(NA : %Lx\n, *(int64_t*)NA_double);
printf(NaN: %Lx\n, *(int64_t*)NaN_double);
sum_double = NA_double + NaN_double ;
memcpy((void*)sum_int64, (void*)sum_double, 8) ;
printf(NA+NaN: %Lx\n, sum_int64) ;
sum_double = NaN_double + NA_double ;
memcpy((void*)sum_int64, (void*)sum_double, 8) ;
printf(NaN+NA: %Lx\n, sum_int64);
return 0 ;
}
When I add -Wall to the -O2 then it gives me some warnings about the
*(int64_t)doubleVal in the printf statements for the inputs,
but I used
memcpy() to avoid the warnings when printing the outputs.
% gcc -Wall -O2 t.c -o a.out ; ./a.out
t.c: In function âmainâ:
t.c:17: warning: dereferencing type-punned pointer will break
strict-aliasing rules
t.c:18: warning: dereferencing type-punned pointer will break
strict-aliasing rules
NA : 7ff007a2
NaN: fff8
NA+NaN: 7ff807a2
NaN+NA: fff8
Bill Dunlap
TIBCO Software Inc - Spotfire Division
wdunlap tibco.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] a statement about package licenses
We are writing on behalf of the R Foundation, to clarify our position on the licenses under which developers may distribute R packages. Readers should also see FAQ 2.11: this message is not legal advice, which we never offer. Readers should also be aware that besides the R Foundation, R has many other copyright holders, listed in the copyright notices in the source. Each of those copyright holders may have a different opinion on the issues discussed here. We welcome packages that extend the capabilities of R, and believe that their value to the community is increased if they can be offered with open-source licenses. At the same time, we have no desire to discourage other license forms that developers feel are required. Of course, such licenses as well as the contents of the package and the way in which it is distributed must respect the rights of the copyright holders and the terms of the R license. When we think that a package is in violation of these rights, we contact the author directly, and so far package authors have always agreed to comply with our license (or convinced us that they are already in compliance). We have no desire to be involved in legal actions---our interest is in providing good software. However, everyone should understand that there are conceivable circumstances in which we would be obliged to take action. Our experience to date and the assurances of some fine commercial developers make us optimistic that these circumstances will not arise. The R Foundation __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] nlminb - Port library codes
Having looked at documentation and codes, I'm still looking to find out who did the installation of the Port libraries. As I work on optimization code improvements, there are often choices of settings (tolerances etc.), and I'd prefer to learn if there are particular reasons for choices before diving in and making any adjustments. It is also worth giving credit where it is due. Given the complexity of the Port code structure, adapting them to R must have been a lot of work. JN __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] crash after using graphics in Rcmdr (PR#13679)
This happens to me every time I try a plot command from TextWrangler with the following applescript tell application TextWrangler set the_selection to (selection of front window as string) if (the_selection) is then set the_selection to line (get startLine of selection) of front window as string end if end tell tell application R64 cmd the_selection end tell I don't know if that sheds any light on the situation. I do like TextWrangler but can't use it because any time I send a plot command over it plots fine with Quartz, but when I close the window (manually or with dev.off()) I get the segfault. Rob Goedman-3 wrote: John, To the best of my knowledge this problem in R.app has been around at least since the R-2.8 days, but likely much longer. I never use R from a Terminal, so don't know if it occurs or not outside R.app. It's not related to Rcmdr and you're observation is indeed one of the better ways to kind of reproduce the issue. Not sure if it always does though. If you have a 'hard' way of crashing R.app, please let me know the sequence. In cases when no output is written to the console of R.app I tend to make sure I enter an empty line before closing the graphics window. This issue and sometimes very long sequences of plots (never have been able to make that reproducible, sometimes the crash happens up to a minute after R finishes a series of plots and I'm working in an external editor like TextMate) are hard to pin down. Regards, Rob Note: Hope you don't mind I've removed the R-bugs R-devel Cc's. On Apr 30, 2009, at 6:29 AM, John Fox wrote: Dear Neil, I had R 2.8.0 installed on my Mac Book, also with OS X 10.5.6, and was unable to duplicate this problem. I then installed R 2.9.0 and observed the same problem that you did. In both cases, I used the latest version of the Rcmdr package, 1.4-10. I also observed the following: (1) The problem occurred only if I closed the Quartz graphics device after the first graph was plotted; if I plotted another graph and then closed the device, the problem did not occur. (2) The problem did not occur if I ran R from a terminal with an X11 graphics device rather than using R.app. I'm afraid that there's not much more that I can do at this point, since my familiarity with Macs is minimal. I'm copying this message to Rob Goedman, who has proven helpful in the past. Of course, if there's something in the Rcmdr that's causing the problem and I can fix it, I will. Regards, John -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org ] On Behalf Of nhepb...@ualberta.ca Sent: April-28-09 1:25 PM To: r-de...@stat.math.ethz.ch Cc: r-b...@r-project.org Subject: [Rd] crash after using graphics in Rcmdr (PR#13679) Full_Name: Neil Hepburn Version: 2.81 and 2.90 OS: OS-X 10.5.6 Submission from: (NULL) (142.244.28.93) When I create graphs using Rcmdr and then close the quartz display, R blows up and tells me of a segmentation fault. It then gives me *** caught segfault *** address 0xc023, cause 'memory not mapped' Possible actions: 1: abort (with core dump, if enabled) 2: normal R exit 3: exit R without saving workspace 4: exit R saving workspace Selection: This only happens if I create the graphics from within Rcmdr. If I create the graphics manually, there is no problem. This occurs on my laptop with R 2.8.1 (I uninstalled 2.9 and reinstall 2.8.1 to see if the problem existed there) and also on my iMac with R2.9. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- View this message in context: http://www.nabble.com/crash-after-using-graphics-in-Rcmdr-%28PR-13679%29-tp23312961p23337174.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
