Dear list,
here is a problem I met when trying to use a method for an S4 object,
without loading the package in which the method was defined. I do not
know if this is a bug, or a mistake of mine. Normally, I think the
package in which the appropriate method is defined is loaded
automatically
Duncan Murdoch wrote:
After some offline followups, I'm pretty sure the issue here is with the
"Start in" directory that the installer puts in the shortcut.
Unfortunately, as far as I can determine, there is no way to tell
Windows to set the working directory to the user's personal director
The conversion of RGB to CMYK takes place in PostScriptSetCol() starting at
line 2900 of R-2.7.0/src/library/grDevices/src/devPS.c
if(strcmp(mm, "cmyk") == 0) {
double c = 1.0-r, m=1.0-g, y=1.0-b, k=c;
k = fmin2(k, m);
k = fmin2(k, y);
if(k =
One more follow-up here before I head out for the weekend.
I added a PrintValue(gvp); immediately after the gvp = ... around line
647 in grid.c in function L_unsetviewport.
Then I recompile R, and run the code loop below, and resize the window,
very small, then large, repeated) until I see th
Hi Thibaut --
The short answer seems to be that this is fixed in the devel
implementation of S4 (at least, my effort at reproducing this was
successful in 2.7 but not R version 2.8.0 Under development (unstable)
(2008-05-22 r45762)).
I think it is like this
http://tolstoy.newcastle.edu.au/R
The two statements below with 'names' are conceptually
the same. The second performs the desired operation
while the first does not.
> xx <- list(A=c(a=1, b=2))
> names(xx$A[1]) <- "changed"
> xx
$A
a b
1 2
> names(xx$A)[1] <- "changed"
> xx
$A
changed b
1 2
This is observed i
On 5/23/2008 2:22 PM, Patrick Burns wrote:
The two statements below with 'names' are conceptually
the same. The second performs the desired operation
while the first does not.
> xx <- list(A=c(a=1, b=2))
> names(xx$A[1]) <- "changed"
> xx
$A
a b
1 2
> names(xx$A)[1] <- "changed"
> xx
$A
c
On Thu 22 May 2008 at 07:09:51 PM +0100, Prof Brian Ripley wrote:
> Why not raise your limits to more reasonable levels? These failures are
> warning you that your limits (stack, it looks) are too low.
These are the default netbsd levels (soft limit). As a user I
can raise the stack to 3072 and