Re: [Rd] (PR#10379) Re: x11(....) kills R without DISPLAY
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/Linux Submission from: (NULL) (24.61.47.236) snipped Example (start R without DISPLAY from bash): % DISPLAY=3D R x11(localhost:11.0)# this is my valid=20 DISPLAY Error: Couldn't find per display information % snipped =20 I see this on Fedora 7 too. I suspect that the earlier report was=20 thought to be Mac specific. snipped I was experimenting with xvfb last week and didn't see the catatrophic = problem like that, so I tried again. Is it possible that this has=20 already been fixed in R 2.6.0 ? (I am on fedora 7, x86_64 as well). -- $ export -n DISPLAY $ R R version 2.6.0 (2007-10-03) ... x11() Error in X11(display, width, height, pointsize, if (is.null(gamma)) 1=20 else gamma, : unable to start device X11 In addition: Warning message: In x11() : unable to open connection to X11 display '' q() Save workspace image? [y/n/c]: n $ export DISPLAY=3D $ R R version 2.6.0 (2007-10-03) ... x11() Error in X11(display, width, height, pointsize, if (is.null(gamma)) 1=20 else gamma, : unable to start device X11 In addition: Warning message: In x11() : unable to open connection to X11 display '' q() Save workspace image? [y/n/c]: n -- 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] ~]$ DISPLAY=3D R -q x11(localhost:10.0) Error: Couldn't find per display information [EMAIL PROTECTED] ~]$ uname -a Linux janus 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007 x86_64=20 x86_64 x86_64 GNU/Linux [EMAIL PROTECTED] ~]$ cat /etc/issue Fedora release 7 (Moonshine) Kernel \r on an \m --=20 O__ Peter Dalgaard =D8ster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327= 918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327= 907 __ 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
Re: [Rd] Bug with Cor(..., method='spearman) and by() (PR#9921)
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(na.omit(X))
Error in cor(na.omit(X)) : 'x' is empty
I would say that consistency requires that both examples give an error.
On Thu, 20 Sep 2007, [EMAIL PROTECTED] wrote:
I posted this on R help, and a few others responded indicating they too
were able to replicate the error as a function of missing data. I
believe this should not be the case and hence and reporting it here.
But you have failed to explain to us why such an example must work: your
'belief' is not relevant here. As the FAQ says, do not report as a bug
something you do not 'know for certain'.
### Code provided on R-Help by Ivar Herfindal
# Simulate data
testdata - cbind.data.frame(gr=3Drep(letters[1:4], each=3D5), =
aa=3Drnorm(20),
bb=3Drnorm(20))
# Introduce some missingness
testdata[1:5, 2] - NA
# This works fine
by(testdata[,c(aa, bb)], testdata$gr, cor, use=3Dcomplete,
method=3Dpearson)
# This induces error
by(testdata[,c(aa, bb)], testdata$gr, cor, use=3Dcomplete,
method=3Dspearman)
Error in FUN(data[x, ], ...) : 'x' is empty
## Alternatively, we can try this
# This works fine
by(testdata[,c('aa', 'bb')], testdata$gr, cor, use=3D'complete',
method=3D'pearson')
## This induces the same error
by(testdata[,c('aa', 'bb')], testdata$gr, cor, use=3D'complete',
method=3D'spearman')
Error in FUN(data[x, ], ...) : 'x' is empty
I am using Windows XP with session info below
Harold Doran
sessionInfo()
R version 2.5.0 (2007-04-23)=20
i386-pc-mingw32=20
locale:
LC_COLLATE=3DEnglish_United States.1252;LC_CTYPE=3DEnglish_United
States.1252;LC_MONETARY=3DEnglish_United
States.1252;LC_NUMERIC=3DC;LC_TIME=3DEnglish_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets
methods base=20
other attached packages:
mlmRevlme4 Matrix lattice=20
0.995-1 0.99875-2 0.99875-30.15-4=20
__
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] pairs, par
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. I'm purely interested in knowing where subsequent points will be plotted on the device. However, after using pairs, the par information (omd, fig, plt, and usr) don't reflect what points does. For example: pairs(iris[1:5]) par(xpd = NA) points(0 - 0.01 * 1:100, 0 - 0.01 * 1:100) points(0 - 0.01 * 1:100, 1 + 0.01 * 1:100) points(1 + 0.01 * 1:100, 0 - 0.01 * 1:100) points(1 + 0.01 * 1:100, 1 + 0.01 * 1:100) par(c(omd, fig, plt, usr)) The resulting plot shows that the corners of the are approximately 0.05 user coordinate units from the boundaries of the plot region. According to par, though, there is a margin around the plotting region that is clearly not symmetric and does not correspond to around 0.05 units. If we use pairs(iris[1:2]) and repeat the rest, the corners are now 0.02 user coordinate units. par provides the same information as before. So: 1. How do I figure out where coordinates I give to points will display on the figure? 2. More generally (for my own understanding), why does the par information not do what I expect? Do I have some fundamental misunderstanding of the arrangement of plotting, figure, display, and margin regions within the device? Is there a bug in pairs and/or par? I'm using R 2.5.1, and this behavior occurs on a fresh R console. Thanks! Oliver -- Oliver Soong Donald Bren School of Environmental Science Management University of California, Santa Barbara Santa Barbara, CA 93106-5131 805-893-7044 (office) 610-291-9706 (cell) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] pairs, par
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, under Windows), I see a line on the plot, but not in a place that corresponds to the axis that were drawn by the 'plot()' command: par(mfrow=c(2,2)) plot(1:2) par(mfrow=c(1,1)) lines(1:2,1:2) (and if you want to be able to set up a new coordinate system on the plotting device to draw on top of the plot left by pairs(), look at par(new) something like plot(0:1, type='n', axes=F, xlab=)) hope this helps, Tony Plate Oliver Soong wrote: 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. I'm purely interested in knowing where subsequent points will be plotted on the device. However, after using pairs, the par information (omd, fig, plt, and usr) don't reflect what points does. For example: pairs(iris[1:5]) par(xpd = NA) points(0 - 0.01 * 1:100, 0 - 0.01 * 1:100) points(0 - 0.01 * 1:100, 1 + 0.01 * 1:100) points(1 + 0.01 * 1:100, 0 - 0.01 * 1:100) points(1 + 0.01 * 1:100, 1 + 0.01 * 1:100) par(c(omd, fig, plt, usr)) The resulting plot shows that the corners of the are approximately 0.05 user coordinate units from the boundaries of the plot region. According to par, though, there is a margin around the plotting region that is clearly not symmetric and does not correspond to around 0.05 units. If we use pairs(iris[1:2]) and repeat the rest, the corners are now 0.02 user coordinate units. par provides the same information as before. So: 1. How do I figure out where coordinates I give to points will display on the figure? 2. More generally (for my own understanding), why does the par information not do what I expect? Do I have some fundamental misunderstanding of the arrangement of plotting, figure, display, and margin regions within the device? Is there a bug in pairs and/or par? I'm using R 2.5.1, and this behavior occurs on a fresh R console. Thanks! Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#10379) Re: x11(....) kills R without DISPLAY
Peter Dalgaard wrote: snipped 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] ~]$ DISPLAY= R -q x11(localhost:10.0) Error: Couldn't find per display information [EMAIL PROTECTED] ~]$ uname -a Linux janus 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux [EMAIL PROTECTED] ~]$ cat /etc/issue Fedora release 7 (Moonshine) Kernel \r on an \m Agh, sorry. Yes, x11() (with or without $DISPLAY set) doesn't die catatrophically, x11(validinfo) does. HTL __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] pairs, par
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))
print(opar)
}
f()
par(xpd = NA)
par(c(omd, fig, plt, usr))
points(0 - 0.01 * 1:100, 0 - 0.01 * 1:100)
points(0 - 0.01 * 1:100, 1 + 0.01 * 1:100)
points(1 + 0.01 * 1:100, 0 - 0.01 * 1:100)
points(1 + 0.01 * 1:100, 1 + 0.01 * 1:100)
My guess is that there are 2 sets of graphical parameters, the ones
stored in par and the ones used by the plotting functions. Before
par(opar) gets called, the two are synchronized. When par(opar) gets
called, we somehow set new values for par without changing the ones
used by the plotting functions, and the data used by points becomes
out of sync with the par information.
This is reflected in this much simpler example:
x11()
par(c(omd, fig, plt, usr))
points(0, 0)
Again, par is defined, but this time the data used by the plotting
functions has not been set, and an error occurs.
Thanks for the workaround suggestion. I guess I can always define a
new plotting region to force par and the plotting data to
re-synchronize. It might be nice if those two didn't go out of sync,
as I had assumed par would always be reliable.
Oliver
On 10/29/07, Tony Plate [EMAIL PROTECTED] wrote:
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, under Windows), I see a line on the plot, but not in a place
that corresponds to the axis that were drawn by the 'plot()' command:
par(mfrow=c(2,2))
plot(1:2)
par(mfrow=c(1,1))
lines(1:2,1:2)
(and if you want to be able to set up a new coordinate system on the
plotting device to draw on top of the plot left by pairs(), look at
par(new) something like plot(0:1, type='n', axes=F, xlab=))
hope this helps,
Tony Plate
Oliver Soong wrote:
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. I'm purely interested in knowing where subsequent
points will be plotted on the device. However, after using pairs, the
par information (omd, fig, plt, and usr) don't reflect what points
does. For example:
pairs(iris[1:5])
par(xpd = NA)
points(0 - 0.01 * 1:100, 0 - 0.01 * 1:100)
points(0 - 0.01 * 1:100, 1 + 0.01 * 1:100)
points(1 + 0.01 * 1:100, 0 - 0.01 * 1:100)
points(1 + 0.01 * 1:100, 1 + 0.01 * 1:100)
par(c(omd, fig, plt, usr))
The resulting plot shows that the corners of the are approximately
0.05 user coordinate units from the boundaries of the plot region.
According to par, though, there is a margin around the plotting region
that is clearly not symmetric and does not correspond to around 0.05
units.
If we use pairs(iris[1:2]) and repeat the rest, the corners are now
0.02 user coordinate units. par provides the same information as
before.
So:
1. How do I figure out where coordinates I give to points will display
on the figure?
2. More generally (for my own understanding), why does the par
information not do what I expect? Do I have some fundamental
misunderstanding of the arrangement of plotting, figure, display, and
margin regions within the device? Is there a bug in pairs and/or par?
I'm using R 2.5.1, and this behavior occurs on a fresh R console.
Thanks!
Oliver
--
Oliver Soong
Donald Bren School of Environmental Science Management
University of California, Santa Barbara
Santa Barbara, CA 93106-5131
805-893-7044 (office)
610-291-9706 (cell)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#10379) Re: x11(....) kills R without DISPLAY
Hin-Tak Leung wrote: Peter Dalgaard wrote: snipped 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] ~]$ DISPLAY= R -q x11(localhost:10.0) Error: Couldn't find per display information [EMAIL PROTECTED] ~]$ uname -a Linux janus 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux [EMAIL PROTECTED] ~]$ cat /etc/issue Fedora release 7 (Moonshine) Kernel \r on an \m Agh, sorry. Yes, x11() (with or without $DISPLAY set) doesn't die catatrophically, x11(validinfo) does. HTL The culprit would seem to be this bit of devX11.c 1302xtdpy = XtOpenDisplay(app_con, NULL, r_x11, R_x11, 1303 NULL, 0, zero, NULL); 1304toplevel = XtAppCreateShell(NULL, R_x11, The 2nd arg to XtOpenDisplay is listed as display_string, so passing a NULL here seems like trouble when the default ways of finding the display do not work. Looks like a fix is to insert p instead of NULL. (Tested rudimentarily.) -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#10379) Re: x11(....) kills R without DISPLAY
Hin-Tak Leung wrote: Peter Dalgaard wrote: snipped 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] ~]$ DISPLAY=3D R -q x11(localhost:10.0) Error: Couldn't find per display information [EMAIL PROTECTED] ~]$ uname -a Linux janus 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007=20 x86_64 x86_64 x86_64 GNU/Linux [EMAIL PROTECTED] ~]$ cat /etc/issue Fedora release 7 (Moonshine) Kernel \r on an \m Agh, sorry. Yes, x11() (with or without $DISPLAY set) doesn't die catatrophically, x11(validinfo) does. HTL The culprit would seem to be this bit of devX11.c 1302xtdpy =3D XtOpenDisplay(app_con, NULL, r_x11,=20 R_x11, 1303 NULL, 0, zero, NULL); 1304toplevel =3D XtAppCreateShell(NULL, R_x11, The 2nd arg to XtOpenDisplay is listed as display_string, so passing a=20 NULL here seems like trouble when the default ways of finding the=20 display do not work. Looks like a fix is to insert p instead of NULL. (Tested rudimentarily.) --=20 O__ Peter Dalgaard =D8ster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327= 918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327= 907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] a package depending on other packages does not pass checking on windows
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, when I try to `R CMD check' my package, R complains about the dependencies being not available. I believe the reason is the option --vanilla set in $R_HOME/bin/check that prevents R from reading my .Renviron. This problem manifests itself with R 2.5.1 under Windows XP but not with the same version under Linux. (Yes, I know this is not the latest version, sorry about that :) ) How do I convince `R CMD check' to find the packages installed in the private library? Thanks in advance for your help! WBR Mstislav Elagin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] pairs, par
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 = red)
On 10/29/07, Oliver Soong [EMAIL PROTECTED] wrote:
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))
print(opar)
}
f()
par(xpd = NA)
par(c(omd, fig, plt, usr))
points(0 - 0.01 * 1:100, 0 - 0.01 * 1:100)
points(0 - 0.01 * 1:100, 1 + 0.01 * 1:100)
points(1 + 0.01 * 1:100, 0 - 0.01 * 1:100)
points(1 + 0.01 * 1:100, 1 + 0.01 * 1:100)
My guess is that there are 2 sets of graphical parameters, the ones
stored in par and the ones used by the plotting functions. Before
par(opar) gets called, the two are synchronized. When par(opar) gets
called, we somehow set new values for par without changing the ones
used by the plotting functions, and the data used by points becomes
out of sync with the par information.
This is reflected in this much simpler example:
x11()
par(c(omd, fig, plt, usr))
points(0, 0)
Again, par is defined, but this time the data used by the plotting
functions has not been set, and an error occurs.
Thanks for the workaround suggestion. I guess I can always define a
new plotting region to force par and the plotting data to
re-synchronize. It might be nice if those two didn't go out of sync,
as I had assumed par would always be reliable.
Oliver
On 10/29/07, Tony Plate [EMAIL PROTECTED] wrote:
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, under Windows), I see a line on the plot, but not in a place
that corresponds to the axis that were drawn by the 'plot()' command:
par(mfrow=c(2,2))
plot(1:2)
par(mfrow=c(1,1))
lines(1:2,1:2)
(and if you want to be able to set up a new coordinate system on the
plotting device to draw on top of the plot left by pairs(), look at
par(new) something like plot(0:1, type='n', axes=F, xlab=))
hope this helps,
Tony Plate
Oliver Soong wrote:
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. I'm purely interested in knowing where subsequent
points will be plotted on the device. However, after using pairs, the
par information (omd, fig, plt, and usr) don't reflect what points
does. For example:
pairs(iris[1:5])
par(xpd = NA)
points(0 - 0.01 * 1:100, 0 - 0.01 * 1:100)
points(0 - 0.01 * 1:100, 1 + 0.01 * 1:100)
points(1 + 0.01 * 1:100, 0 - 0.01 * 1:100)
points(1 + 0.01 * 1:100, 1 + 0.01 * 1:100)
par(c(omd, fig, plt, usr))
The resulting plot shows that the corners of the are approximately
0.05 user coordinate units from the boundaries of the plot region.
According to par, though, there is a margin around the plotting region
that is clearly not symmetric and does not correspond to around 0.05
units.
If we use pairs(iris[1:2]) and repeat the rest, the corners are now
0.02 user coordinate units. par provides the same information as
before.
So:
1. How do I figure out where coordinates I give to points will display
on the figure?
2. More generally (for my own understanding), why does the par
information not do what I expect? Do I have some fundamental
misunderstanding of the arrangement of plotting, figure, display, and
margin regions within the device? Is there a bug in pairs and/or par?
I'm using R 2.5.1, and this behavior occurs on a fresh R console.
Thanks!
Oliver
--
Oliver Soong
Donald Bren School of Environmental Science Management
University of California, Santa Barbara
Santa Barbara, CA 93106-5131
805-893-7044 (office)
610-291-9706 (cell)
__
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] a package depending on other packages does not pass checking on windows
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 putting the following in your .Rprofile .libPaths(SOMEDIR) But of these are accessed by R CMD ... Kasper On Oct 29, 2007, at 3:45 PM, Mstislav Elagin wrote: 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, when I try to `R CMD check' my package, R complains about the dependencies being not available. I believe the reason is the option --vanilla set in $R_HOME/bin/check that prevents R from reading my .Renviron. This problem manifests itself with R 2.5.1 under Windows XP but not with the same version under Linux. (Yes, I know this is not the latest version, sorry about that :) ) How do I convince `R CMD check' to find the packages installed in the private library? Thanks in advance for your help! WBR Mstislav Elagin __ 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] Using SJava? (was R-devel Digest, Vol 56, Issue 27)
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.path. One way to do this is to add it to your system PATH variable. so this is most likely an error in the package you are using (SJava?), not in R. Please do read and follow the R posting guide at http://www.r-project.org/posting-guide.html (including using a reasonable subject line). On Sun, 28 Oct 2007, Íõ»¢ wrote: Dear R expert: I have the problems with calling R from Java on Windows XP_SP2/Eclipse3.1/JDK1.5 problems: Loading RInterpreter library Exception in thread main java.lang.UnsatisfiedLinkError: no RInterpreter in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1682) at java.lang.Runtime.loadLibrary0(Runtime.java:822) at java.lang.System.loadLibrary(System.java:992) at org.omegahat.R.Java.ROmegahatInterpreter.(ROmegahatInterpreter.java :28) at org.omegahat.R.Java.Examples.lmTest.main(lmTest.java:8) and Exception in thread main java.lang.UnsatisfiedLinkError: no SJava in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1682) at java.lang.Runtime.loadLibrary0(Runtime.java:822) at java.lang.System.loadLibrary(System.java:992) at org.omegahat.R.Java.RForeignReference.(RForeignReference.java:22) at ne.Test.main(Test.java:11) help me!Thanks! name:wanghu(from china) [[alternative HTML version deleted]] __ 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 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#10379) Re: x11(....) kills R without DISPLAY
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 1302xtdpy = XtOpenDisplay(app_con, NULL, r_x11, R_x11, 1303 NULL, 0, zero, NULL); 1304toplevel = XtAppCreateShell(NULL, R_x11, The 2nd arg to XtOpenDisplay is listed as display_string, so passing a NULL here seems like trouble when the default ways of finding the display do not work. Looks like a fix is to insert p instead of NULL. (Tested rudimentarily.) Prof. Ripley replaced that NULL with dsp -- p is normally the same. It's in svn (r43300 on he trunk, r43301 on R-2-6-branch). It built without a hitch, and the fix solves my problem. P. Dalgaard also pinpointed the problem. And confirmed Xt was involved :-) Apparently an XOpenDisplay on the specified display may be followed by an XtOpenDisplay, previously on the default display. Thanks to everyone who helped figure this out and fix the problem! /Christian Brechbuehler [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
