[Rd] Very slow plot rendering with X11 on CentOS 5.5
I am connecting from a PC to a Linux system running CentOS
release 5.5 (Final) and it is extremely slow to render plots
to the X11 device.
This is not R's fault but I wonder if anyone can offer
guidance so I can help the system administrators address
the problem.
I can connect to the Linux server using a NoMachine NX client
for Windows or using X-Win32. I also have access to R running
on my Windows PC and an older version of R on Solaris which
I connect to using X-Win32.
Using a test function of:
f <- function(n){
for(i in 1:n) qqnorm(rnorm(100))
}
system.time(f(20))
I get typical timings of:
Platform Version Client'type' user system elapsed
Linux2.11.0 NX client cairo 1.012 0.131 7.155
Linux2.11.0 NX client Xlib 0.964 0.127 7.119
Linux2.11.0 X-Win32cairo 1.141 0.211 20.287
Linux2.11.0 X-Win32Xlib 1.116 0.207 20.152
Solaris 2.8.1 X-Win32cairo 0.172 0.020 0.356
Solaris 2.8.1 X-Win32Xlib 0.173 0.019 0.364
Win322.11.1 Native0.030.220.25
The Linux timings are just awful, particularly using
X-Win32. Cairo vs. Xlib doesn't seem to matter much.
Does anybody have any suggestions on what to look into?
I can work around the Linux problems by not using the X11
device and instead writing a plot to a temporary PNG or
PDF and using Eye of GNOME or Evince but that isn't ideal.
But I would welcome any tips in this regard.
The Linux sessionInfo is:
R version 2.11.0 (2010-04-22)
x86_64-unknown-linux-gnu
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=C LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Thank you,
Stephen
--
Stephen Weigand, Statistician II
Biomedical Statistics and Informatics
(507) 266-1650; fax (507) 284-9542
Mayo Clinic; 200 First St. SW
Rochester, Minn., 55905 USA
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Very slow plot rendering with X11 on CentOS 5.5
Many, many thanks for the effort Russ. I'm not clear on next steps
but think I need to look at CentOS vs. others in terms of X.
-Original Message-
From: R P Herrold [mailto:herr...@owlriver.com]
Sent: Wednesday, September 29, 2010 8:40 AM
On Tue, 28 Sep 2010, R P Herrold wrote:
>> I am connecting from a PC to a Linux system running CentOS release
>> 5.5 (Final) and it is extremely slow to render plots to the X11
>> device.
> f <- function(n){
for(i in 1:n) qqnorm(rnorm(100))
}
system.time(f(20))
> I'll get a packaging built under CentOS 5 on that other architecture
> overnight, and supplement this post
done -- same sources and build environment, but a i686 rather than a a
x86_64 architecture. Similar hardware at the remove unit in the local
subnet
It is noticeably sluggish in the rendering compared to local X client to
X server
> f <- function(n){
+for(i in 1:n) qqnorm(rnorm(100))
+ }
> system.time(f(20))
user system elapsed
0.953 0.185 36.992
-- Russ herrold
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] tiff(), jpeg(), and png() in R 2.7.0: problems if 'units = "in"' but default height and width
I love the new tiff(), jpeg(), and png() in R 2.7.0 but found
an issue that I didn't see reported.
When specifying 'units = "in"' but forgetting to change the
default height and width (so the figure is unintentionally
going to be 480 inches by 480 inches) I run into problems.
Here's the reproducible example:
tiff("a.tiff", units = "in", res = 1200,
compression = "lzw")
hist(rnorm(10))
dev.off()
Before dev.off(), I get these warnings:
Warning messages:
1: In title(main = main, sub = sub, xlab = xlab, ylab = ylab,
... :
X11 protocol error: BadAlloc (insufficient resources for
operation)
2: In title(main = main, sub = sub, xlab = xlab, ylab = ylab,
... :
X11 protocol error: BadDrawable (invalid Pixmap or Window
parameter)
and the dev.off() line will give me:
*** caught segfault ***
address 48, cause 'memory not mapped'
Traceback:
1: dev.off()
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
My sessionInfo()
R version 2.7.0 (2008-04-22)
sparc-sun-solaris2.10
locale:
C
attached base packages:
[1] stats graphics grDevices utils
[5] datasets methods base
My capabilities()
jpeg pngtcltk X11
TRUE TRUE TRUE TRUE
aqua http/ftp sockets libxml
FALSE TRUE TRUE TRUE
fifo clediticonv NLS
TRUE TRUE TRUE TRUE
profmemcairo
FALSEFALSE
Thanks,
Stephen
--
::
Stephen Weigand
Division of Biostatistics
Mayo Clinic Rochester, Minn., USA
Phone (507) 266-1650, fax 284-9542
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] foreign:::writeForeignSAS patch not released?
Hello, In May 2018 there was some R-devel discussion about a bug in foreign:::writeForeignSAS. See here: https://stat.ethz.ch/pipermail/r-devel/2018-May/076220.html and it resulted in a patch. See: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17256 And I see the changes in Subversion here: https://svn.r-project.org/R-packages/trunk/foreign/R/writeForeignSAS.R But I don't think the patched version is being released with R or on CRAN. Subversion shows version 0.8-72 of the 'foreign' package but CRAN and 'R-3.6.0.tar.gz' both have version 0.8-71. Sincerely, Stephen __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] foreign:::writeForeignSAS patch not released?
Hi, Thank you to R-core since this issue is solved. Both CRAN and R-devel_2019-12-03_r77513.tar.gz have version 0.8-72 of the foreign package which includes the improvements to foreign:::writeForeignSAS. Thank you again, Stephen -Original Message- Sent: Tuesday, June 04, 2019 8:27 AM Hello, In May 2018 there was some R-devel discussion about a bug in foreign:::writeForeignSAS. See here: https://stat.ethz.ch/pipermail/r-devel/2018-May/076220.html and it resulted in a patch. See: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17256 And I see the changes in Subversion here: https://svn.r-project.org/R-packages/trunk/foreign/R/writeForeignSAS.R But I don't think the patched version is being released with R or on CRAN. Subversion shows version 0.8-72 of the 'foreign' package but CRAN and 'R-3.6.0.tar.gz' both have version 0.8-71. Sincerely, Stephen __ 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] What should dnorm(0, 0, -Inf) return?
Hi, Apropos of a recent Inf question, I've previously wondered if dnorm "does the right thing" with dnorm(0, 0, -Inf) which gives zero. Should that be zero or NaN (or NA)? The help says "'sd < 0' is an error and returns 'NaN'" and since -Inf < 0 is TRUE, then... is this a bug? Thank you, Stephen Rochester, MN USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [EXTERNAL] Adding RtangleRuncode and RtangleFinish to exports of utils
Hi,
For what it's worth, I would like to second this. I have a small Sweave driver
(https://r-forge.r-project.org/R/?group_id=1857) that uses:
RtangleRtf <- function(){
list(setup = RtangleSetup,
runcode = utils:::RtangleRuncode, # <---
writedoc = RtangleWritedoc,
finish = utils:::RtangleFinish, # <---
checkopts = RweaveRtfOptions)
}
And of course using ':::' generates warnings. Elsewhere I use
utils:::SweaveParseOptions(opts, object$options,
RweaveRtfOptions)
and so if it is sensible to also export 'SweaveParseOptions' then that would be
great.
With appreciation,
Stephen
-Original Message-
From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Vincent
Goulet via R-devel
Sent: Wednesday, July 08, 2020 10:28 AM
To: R-devel@r-project.org
Subject: [EXTERNAL] [Rd] Adding RtangleRuncode and RtangleFinish to exports of
utils
Hi,
Could R-Core consider adding 'RtangleRuncode' and 'RtangleFinish' to the
exports of utils. Their weave equivalent 'makeRweaveLatexCodeRunner' and
'RweaveLatexFinish' are exported, as well as the other tangle utility
functions 'RtangleSetup' and 'RtangleWritedoc'.
The rationale is not just symmetry. ;-)
I'm finishing a small package that will provide "enhanced" drivers for Sweave
that are heavily based on the standard RweaveLatex and Rtangle drivers. So much
so that I can reuse most of the utiity functions called by RweaveLatex() and
Rtangle(). Now, 'RtangleRuncode' and 'RtangleFinish' are not exported and 'R
CMD check' really does not like that I use the ::: operator to reach the
functions.
The alternative is to duplicate the code verbatim in my package. This does not
seem very sensible, especially since I would then need to track any changes to
the aforementioned functions to remain in line.
Here is the proposed patch against the current r-devel tree:
Index: src/library/utils/NAMESPACE
===
--- src/library/utils/NAMESPACE (revision 78794)
+++ src/library/utils/NAMESPACE (working copy)
@@ -166,9 +166,9 @@
Sweave, SweaveSyntConv, SweaveSyntaxLatex, SweaveSyntaxNoweb,
RtangleWritedoc, RweaveChunkPrefix, RweaveEvalWithOpt,
RweaveTryStop, SweaveHooks, RweaveLatexWritedoc,
- RweaveLatexOptions, RweaveLatexFinish,
+ RweaveLatexOptions, RweaveLatexFinish, RtangleFinish,
.RtangleCodeLabel,
- makeRweaveLatexCodeRunner)
+ makeRweaveLatexCodeRunner, RtangleRuncode)
if(tools:::.OStype() == "unix") {
export(nsl)
Best,
v.
__
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
