This is as documented in ?source, and so is not a bug.
On Tue, 30 Oct 2007, [EMAIL PROTECTED] wrote:
> Full_Name: Martin Kober
> Version: 2.6.0
> OS: Vista & Linux
> Submission from: (NULL) (137.208.185.169)
>
>
> Hi!
>
> I just stumbled upon a problem with file source()ing:
>
> R will fail to so
>From the 'Writing R Extensions' manual:
R CMD check and R CMD build run R with
--vanilla, so none of the user's startup files are read. If
you need R_LIBS set (to find packages in a non-standard library)
you will need to set it in the environment.
so 'the problem' is your not readin
On 10/29/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
>
> The problem is that the XtOpenDisplay call did not specify the display.
> Easily fixed
>
On 10/29/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>
> The culprit would seem to be this bit of devX11.c
>
> 1302
Full_Name: Martin Kober
Version: 2.6.0
OS: Vista & Linux
Submission from: (NULL) (137.208.185.169)
Hi!
I just stumbled upon a problem with file source()ing:
R will fail to source a file if it contains lines longer than about 8192 bytes
("input buffer overflow").
While it's save to say that hum
On 10/28/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
>
> The error is:
>
> > Exception in thread "main" java.lang.UnsatisfiedLinkError: no SJava in
> > java.library.path
It sounds like you need to put the directory containing the dll's included
with the SJava package on your java.library.pat
I have been bitten by this myself. For that reason I have stopped
using .Renviron.
I believe the behavior is the same under Linux and Windows, so I
think you might have a different setup on the two machines.
You can fix it by explicitly setting
R_LIBS
as an environment variable or by putti
This hack will disable the on.exit temporarily:
pairs.data.frame <- function(x, ...) {
on.exit <- function(...) {}
environment(pairs.default) <- environment()
pairs.default(x, ...)
}
pairs(iris)
par("usr")
# add points to lower right square
points(1:10/10, 1:10/10, col = "r
Dear developers,
I am writing a package that depends on some other packages. The
dependencies are stated in the `description' file under "Depends". They
are installed in my private library, which is pointed to by setting
R_LIBS in .Renviron, and are available if R is started normally.
However, whe
Hin-Tak Leung wrote:
> Peter Dalgaard wrote:
>
>> You need x11() with a valid display to trigger the bug:
>>
>> [EMAIL PROTECTED] BUILD]$ ssh -Y 192.168.1.10
>> [EMAIL PROTECTED]'s password:
>> Last login: Sat Oct 27 02:40:16 2007 from 192.168.1.11
>> [EMAIL PROTECTED] ~]$ echo $DISPLAY
>> localho
Hin-Tak Leung wrote:
> Peter Dalgaard wrote:
>
>> You need x11() with a valid display to trigger the bug:
>>
>> [EMAIL PROTECTED] BUILD]$ ssh -Y 192.168.1.10
>> [EMAIL PROTECTED]'s password:
>> Last login: Sat Oct 27 02:40:16 2007 from 192.168.1.11
>> [EMAIL PROTECTED] ~]$ echo $DISPLAY
>> localho
I dug around in pairs, and I think it has something to do with the
on.exit(par(opar)) bit:
f <- function() {
opar <- par(mfrow = c(2, 2), mar = rep(0.5, 4), oma = rep(4, 4))
on.exit(par(opar))
for(i in 1:4) plot(0:1, 0:1)
par(c("mfg", "omd", "fig", "plt", "usr"))
Peter Dalgaard wrote:
> You need x11() with a valid display to trigger the bug:
>
> [EMAIL PROTECTED] BUILD]$ ssh -Y 192.168.1.10
> [EMAIL PROTECTED]'s password:
> Last login: Sat Oct 27 02:40:16 2007 from 192.168.1.11
> [EMAIL PROTECTED] ~]$ echo $DISPLAY
> localhost:10.0
> [EMAIL PROTECTED] ~]$
I would look into the code for pairs(). Among other things, it sets and
restores par(mfrow=...). I suspect this is the relevant issue, not the
use of pairs(). I would try to figure out what state a graphics device
is in after resetting par("mfrow"). When I try the following (R 2.6.0
patched
Hi,
I posted over at R-help, and didn't get a response, but perhaps that
was the wrong forum for this question. I'm having some confusion over
the coordinate system after using pairs. I'm not interested in the
content of the actual pairs plot, although the number of pairs seems
to matter a bit.
This is nothing whatsoever to do with by(), and it is cor, not Cor.
Try
X <- cbind(NA, 1:3)
cor(X, use = "complete")
cor(X, use = "complete", method="spearman")
In short, cor() behaves differently when given a vector of NAs. That's
perfectly reasonable, as the ranks are undefined.
Since
> cor
The problem is that the XtOpenDisplay call did not specify the display.
Easily fixed
On Sat, 27 Oct 2007, [EMAIL PROTECTED] wrote:
> Hin-Tak Leung wrote:
>> Peter Dalgaard wrote:
>>> [EMAIL PROTECTED] wrote:
Full_Name: Christian Brechbuehler
Version: 2.4.1, 2.5.1, OS: Ubuntu GNU/Li
16 matches
Mail list logo
