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)
>>
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
%
>>
=20
>>> I see this on Fedora 7 too. I suspect that the earlier report was=20
>>> thought to be Mac specific.
>>
>>
>> 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=3D"complete",
> method=3D"pearson")
>
> # This induces error
> by(testdata[,c("aa", "bb")], testdata$gr, cor, use=3D"complete",
> method=3D"spearman")
>
> 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-3""0.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:
> 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:
>
>> 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:
>
>> 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-d
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
[Rd] R can't source() long lines (PR#10383)
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 human-written code won't contain lines that long,
dump()ed data structures may reasonably contain strings longer than that (as in
my case).
What's more, R will happily help you to create such files:
x = paste(rep("12345678", 1024), collapse="")
dump("x")
source("dumpdata.R") ## this fails (on Linux & Vista)
I'm now using save/load, which is probably better in that case anyway. Still, I
would be nice if source() worked or at least dump() would break lines to avoid
this issue.
Best regards,
Martin Kober
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R can't source() long lines (PR#10383)
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 source a file if it contains lines longer than about 8192 bytes
> ("input buffer overflow").
>
> While it's save to say that human-written code won't contain lines that long,
> dump()ed data structures may reasonably contain strings longer than that (as
> in
> my case).
>
> What's more, R will happily help you to create such files:
>
> x = paste(rep("12345678", 1024), collapse="")
> dump("x")
> source("dumpdata.R") ## this fails (on Linux & Vista)
>
> I'm now using save/load, which is probably better in that case anyway.
> Still, I would be nice if source() worked or at least dump() would break
> lines to avoid this issue.
It would be even nicer if users read the documentation rather than
expected the developers to do so for them.
> Best regards,
> Martin Kober
>
> __
> 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] a package depending on other packages does not pass checking on windows
>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 reading the documentation. On Mon, 29 Oct 2007, 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 > -- 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
