[Rd] Grid Graphics Documentation: color specification with gpar() (PR#14013)
Full_Name: Tom Gottfried Version: 2.9.2 OS: Mac OS X 10.4.11 Submission from: (NULL) (93.104.160.207) Dear R-Developers, on the help page for gpar() is the following paragraph: Specifying the value NULL for a parameter is the same as not specifying any value for that parameter, except for col and fill, where NULL indicates not to draw a border or not to fill an area (respectively). The mentioned exception for col and fill does not hold. Actually what is said in the section Color Specification on the help page for par() is true also for gpar(): transparent and NA specify transparency respectively no drawing. To verify this: grid.newpage() grid.rect(width=.5, height=.5) grid.rect(width=.25, height=.25, gp=gpar(col=NULL)) # draws the box despite col=NULL grid.rect(width=.125, height=.125, gp=gpar(col=NA, fill=2)) # does not draw the box regards, Tom __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rscript not returning zero
On 18 October 2009 at 06:22, Prof Brian Ripley wrote: | On Sat, 17 Oct 2009, Rodrigo Flores wrote: | Is there any way to get the Rscript returning zero ? | | Have a successful script | | You have not told us the 'at a minimum' information asked for in the | posting guide, whereas I get (under sh) | | sh-3.2$ Rscript -e 'sessionInfo()' | R version 2.9.2 (2009-08-24) | x86_64-unknown-linux-gnu | | locale: | LC_CTYPE=en_GB.utf8;LC_NUMERIC=C;LC_TIME=en_GB.utf8;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=en_GB.utf8;LC_PAPER=en_GB.utf8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_GB.utf8;LC_IDENTIFICATION=C | | attached base packages: | [1] stats graphics grDevices utils datasets base | sh-3.2$ echo $? | 0 | | so please give a reproducible example of a successful script not | returning zero. Moreover, Rscript and r (i.e. littler) both support custom return codes: e...@ron:~$ Rscript -e 'q(42,save=no)' e...@ron:~$ echo $? 42 e...@ron:~$ r -e 'q(42,save=no)' e...@ron:~$ echo $? 42 e...@ron:~$ Dirk -- Three out of two people have difficulties with fractions. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Specifying (set of random) port numbers for the help HTML server (Was: Re: Fixing html help port in 2.10)
On 17/10/2009 12:08 AM, Henrik Bengtsson wrote: On Fri, Oct 16, 2009 at 7:54 AM, Duncan Murdoch murd...@stats.uwo.ca wrote: On 10/16/2009 10:39 AM, Dieter Menne wrote: I noted that the new html-help in 2.10 under Windows uses a random port on my computer. This cause a problem, because when I create a link such as: http://127.0.0.1:28027/library/stats/html/addmargins.html this is for one-time use only. Is it possible to fix the port? Not currently. If you look in tools:::startDynamicHelp you can see how it is set up; you could duplicate that setup as a temporary workaround. You might be better off to build R with static help instead. What is the application where you want to be able to give out links? Perhaps we could consult an environment variable or option() to choose the port instead of leaving it completely random. The reason it is random is the worry that multiple R instances on the same machine might collide. All processes on the machine see the same ports. Related: I'd like to suggest an option/environment variable that specifies the set of port numbers sampled from, e.g. 6800:6850 or similar. I've added an option help.ports to set this. It will try your specified ports in order; if you want a random selection, permute them yourself, e.g. options(help.ports = sample(6800:6850)) This will make it into 2.10.0. Duncan Murdoch The reason is that in some places, the user don't have admin privileges on the computer and most/all ports are blocked from running servers, and there is a sysadm that needs to approve each port to be unblocked. With such a security polices it is possible to have the smaller set of port number unblocked (but not the full 0-65535 range). This applies at least to regular users on Windows. My $.02 /Henrik Duncan Murdoch __ 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Specifying (set of random) port numbers for the help HTML server (Was: Re: Fixing html help port in 2.10)
Duncan Murdoch-2 wrote: options(help.ports = sample(6800:6850)) Nice. So just in case I want options(help.ports = sample(6800:6800)) What would be the adverse effects (besides me having to check that that port is reasonable)? Dieter -- View this message in context: http://www.nabble.com/Re%3A-Specifying-%28set-of-random%29-port-numbers-for-the-help-HTML-server-%28Was%3A-Re%3A-Fixing-html-help-port-in-2.10%29-tp25935271p25947460.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Specifying (set of random) port numbers for the help HTML server (Was: Re: Fixing html help port in 2.10)
On 18/10/2009 11:14 AM, Dieter Menne wrote: Duncan Murdoch-2 wrote: options(help.ports = sample(6800:6850)) Nice. So just in case I want options(help.ports = sample(6800:6800)) What would be the adverse effects (besides me having to check that that port is reasonable)? That will choose a random port between 1 and 6800, then another, and so on, potentially trying all 6800. This is because of the dumb behaviour of sample(6800), nothing to do with the help system. If you specify options(help.ports=6800), then R will try to use port 6800. If it happens to be in use by some other process, then it will fail. If you put this in your startup script, then only the first instance of R on your system would be able to use HTML help; the others would fail to start their servers. If you are on a multi-user system, restricting the range is more likely to lead to collisions. There's also the security issue: restricting the range makes it easier for another user on your system to guess your port. If you are developing a top secret package, they'll be able to read its help pages if they know your port number. (They could always do a port scan to find it, but perhaps your security system would be more likely to detect that if they had to scan more ports.) On a single user system I can't see much problem with restricting the range to a few dozen choices. You're unlikely to have more than a few instances of R running. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] linking to package directories broken in R = 2.10 beta
On 17/10/2009 1:57 PM, Thomas Petzoldt wrote: Duncan Murdoch wrote: Thomas Petzoldt wrote: [...] This is fine, but in contrast to older versions (= 2.9.2) no automatic index is created for the linked directory, so we now get: URL /library/foo/examples/ was not found but linking to *individual files* (e.g. examples/example.R) works as expected. We can, of course, add manually maintained index files but I would much prefer if a default index would be created for the directory if no index.html is found. By index in R = 2.9.2, you mean the default directory listing produced by the web server, rather than something produced by R, right? Yes, I mean the default directory listing produced by (most) web servers. The R server does that now if the directory is named doc, but not for an arbitrary path. We are concerned about security: any user on your system who can guess your port number can access your help system, so we want to be sure that such users can't access private files. Hmm, I see and have some tendency to understand that this may be an issue for certain multi-user systems. Looking into the svn log (and compiling R) it appears that the remaining possibilities where also regarded as security issue and are now locked down too. Well, I'm not yet completely convinced that this was a good idea. 1) It does not completely solve security issues; what is so different between the library/foo/doc and library/foo/examples ??? The doc directory is known to be visible. It might surprise someone if arbitrary directories were visible, and readable by any user. 2) The change will introduce additional work for package authors that used internal links within their packages. I can, of course, reorganize everything below doc, e.g. /library/foo/doc/examples ... but this means that these things are even more hidden. Why would someone know to look in .../examples? Just update whatever hint you gave them to look there, and tell them to look in .../doc/examples instead. I don't think it's likely that most people would discover either directory without a hint somewhere. If they were looking for examples, they'd look in the documented places, the Examples section of man pages, or in the vignettes. 3) However, according to the changed R-Exts, it was obviously decided that this was necessary, so *I* will do the required reorganization. I think it was not so much a decision that this was necessary, as that it was prudent. Duncan Murdoch I hope that other package authors accept this change of the rules too. Nevertheless, thank you very much for the new help system. Thomas P. __ 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] linking to package directories broken in R = 2.10 beta
Duncan Murdoch wrote: [...] The doc directory is known to be visible. It might surprise someone if arbitrary directories were visible, and readable by any user. 2) The change will introduce additional work for package authors that used internal links within their packages. I can, of course, reorganize everything below doc, e.g. /library/foo/doc/examples ... but this means that these things are even more hidden. Why would someone know to look in .../examples? Just update whatever hint you gave them to look there, and tell them to look in .../doc/examples instead. I don't think it's likely that most people would discover either directory without a hint somewhere. If they were looking for examples, they'd look in the documented places, the Examples section of man pages, or in the vignettes. 3) However, according to the changed R-Exts, it was obviously decided that this was necessary, so *I* will do the required reorganization. I think it was not so much a decision that this was necessary, as that it was prudent. Duncan Murdoch [...] ok, I will agree, but let me add one final thought: What is with the /demo directory? Thomas P. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] linking to package directories broken in R = 2.10 beta
On 18/10/2009 4:45 PM, Thomas Petzoldt wrote:
Duncan Murdoch wrote:
[...]
The doc directory is known to be visible. It might surprise someone if
arbitrary directories were visible, and readable by any user.
2) The change will introduce additional work for package authors
that used internal links within their packages. I can, of course,
reorganize everything below doc, e.g. /library/foo/doc/examples ... but
this means that these things are even more hidden.
Why would someone know to look in .../examples? Just update whatever
hint you gave them to look there, and tell them to look in
.../doc/examples instead. I don't think it's likely that most people
would discover either directory without a hint somewhere. If they were
looking for examples, they'd look in the documented places, the Examples
section of man pages, or in the vignettes.
3) However, according to the changed R-Exts, it was obviously decided
that this was necessary, so *I* will do the required reorganization.
I think it was not so much a decision that this was necessary, as that
it was prudent.
Duncan Murdoch
[...]
ok, I will agree, but let me add one final thought: What is with the
/demo directory?
It's not displayed by the help system, it is displayed by the demo()
function. There wasn't a way to get to it through the help system in
previous versions, was there? (If you were running a browser you could
browse files on the local file system, and you could construct a \url{}
in a man page, but I don't think there were any links to the demo
directory generated by R, were there?)
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug with .First in R 2.10
Under R2.10.0 beta (2009-10-14 r50082) my .First does not run reliably. I
reported this last week, but not reproducibly, and it seemed to go away, so I
thought it might be installation-related. But it has now recurred reproducibly,
at least on my machine.
The website ftp://ftp.csiro.au/MarkBravington contains two .RData files each
containing (only) a .First. One of them does what it should, and one of them
doesn't. Confusingly, the OK one will actually trigger an error message for
you, because it tries to do things that are specific to my machines. The not-OK
one says skipping .First, as below, and you'll see why it shouldn't be doing
that. Obvioulsy, the files need renaming before you can test them.
I haven't been able to condense the .First to something more succinct that
shows the same fault; saving a modified .First frequently makes the problem go
away, seemingly regardless of what the change is.
The transcript from the not-OK version is given below
Mark
--
Mark Bravington
CSIRO Mathematical Information Sciences
Marine Laboratory
Castray Esplanade
Hobart 7001
TAS
ph (+61) 3 6232 5118
fax (+61) 3 6232 5012
mob (+61) 438 315 623
R version 2.10.0 beta (2009-10-14 r50082)
Copyright (C) 2009 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
[Previously saved workspace restored]
NOFIRST
Skipping .First
head( .First) # what was it trying to do?
1 function (skip.First = Sys.getenv(NOFIRST) != )
2 {
3 print(Sys.getenv(NOFIRST))
4 if (skip.First) {
5 cat(Skipping .First\\n)
6 return(invisible(NULL))
--please do not edit the information below--
Version:
platform = i386-pc-mingw32
arch = i386
os = mingw32
system = i386, mingw32
status = beta
major = 2
minor = 10.0
year = 2009
month = 10
day = 14
svn rev = 50082
language = R
version.string = R version 2.10.0 beta (2009-10-14 r50082)
Windows XP Professional x64 (build 3790) Service Pack 2
Locale:
LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252
Search Path:
.GlobalEnv, package:stats, package:graphics, package:grDevices, package:utils,
package:datasets, package:methods, Autoloads, package:base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug with .First in R 2.10
On 18/10/2009 6:20 PM, mark.braving...@csiro.au wrote: Under R2.10.0 beta (2009-10-14 r50082) my .First does not run reliably. I reported this last week, but not reproducibly, and it seemed to go away, so I thought it might be installation-related. But it has now recurred reproducibly, at least on my machine. The website ftp://ftp.csiro.au/MarkBravington contains two .RData files each containing (only) a .First. One of them does what it should, and one of them doesn't. Confusingly, the OK one will actually trigger an error message for you, because it tries to do things that are specific to my machines. The not-OK one says skipping .First, as below, and you'll see why it shouldn't be doing that. Obvioulsy, the files need renaming before you can test them. I haven't been able to condense the .First to something more succinct that shows the same fault; saving a modified .First frequently makes the problem go away, seemingly regardless of what the change is. The transcript from the not-OK version is given below I can reproduce the problem running the .First in the notOK.RData file. (I don't need to rename it; just loading that file and explicitly running .First() will do it.) However, if I dump the function and source it, the problem goes away. So I suspect there is something wrong in the notOK.RData file. How did you create it? Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug with .First in R 2.10
I started the same version of R in my usual starting directory (where there's a larger .RData, whose .First is running OK right now) and then did save( .First, file=whatever) I'm not sure exactly where the .First came from before that; I use a couple of different machines and (in the runup to 2.10) a couple of R versions. Mark -- Mark Bravington CSIRO Mathematical Information Sciences Marine Laboratory Castray Esplanade Hobart 7001 TAS ph (+61) 3 6232 5118 fax (+61) 3 6232 5012 mob (+61) 438 315 623 Duncan Murdoch wrote: On 18/10/2009 6:20 PM, mark.braving...@csiro.au wrote: Under R2.10.0 beta (2009-10-14 r50082) my .First does not run reliably. I reported this last week, but not reproducibly, and it seemed to go away, so I thought it might be installation-related. But it has now recurred reproducibly, at least on my machine. The website ftp://ftp.csiro.au/MarkBravington contains two .RData files each containing (only) a .First. One of them does what it should, and one of them doesn't. Confusingly, the OK one will actually trigger an error message for you, because it tries to do things that are specific to my machines. The not-OK one says skipping .First, as below, and you'll see why it shouldn't be doing that. Obvioulsy, the files need renaming before you can test them. I haven't been able to condense the .First to something more succinct that shows the same fault; saving a modified .First frequently makes the problem go away, seemingly regardless of what the change is. The transcript from the not-OK version is given below I can reproduce the problem running the .First in the notOK.RData file. (I don't need to rename it; just loading that file and explicitly running .First() will do it.) However, if I dump the function and source it, the problem goes away. So I suspect there is something wrong in the notOK.RData file. How did you create it? Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] weird warning in [.data.frame with 2.10
I'm getting the following warnings under 2.10 v50082 but not v49613 In addition: Warning messages: 1: In `[.data.frame`(df, -(1:nrow(df)), , drop = FALSE) : named arguments other than 'drop' are discouraged 5: In `[.data.frame`(object, !omit, , drop = FALSE) : named arguments other than 'drop' are discouraged In neither case are there any named arguments, as the messages themselves point out. The errors are popping up while running my 'debug' package. They are associated with another sporadic new warning nearby about number of items... replacement length, which is more of a direct worry. This has never happened before in 'debug'; it makes me think that something more sinister may be going on in the bowels of R, but I haven't tracked it down clearly enough to report it. Mark -- Mark Bravington CSIRO Mathematical Information Sciences Marine Laboratory Castray Esplanade Hobart 7001 TAS ph (+61) 3 6232 5118 fax (+61) 3 6232 5012 mob (+61) 438 315 623 --please do not edit the information below-- Version: platform = i386-pc-mingw32 arch = i386 os = mingw32 system = i386, mingw32 status = beta major = 2 minor = 10.0 year = 2009 month = 10 day = 14 svn rev = 50082 language = R version.string = R version 2.10.0 beta (2009-10-14 r50082) Windows XP Professional x64 (build 3790) Service Pack 2 Locale: LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252 Search Path: .GlobalEnv, package:grDevices, package:ad, package:chstuff, package:handy2, package:tweedie, package:statmod, package:handy, package:debug, package:mvbutils, mvb.session.info, package:tools, package:tcltk, package:stats, package:graphics, package:utils, package:methods, Autoloads, package:base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Specifying (set of random) port numbers for the help HTML server (Was: Re: Fixing html help port in 2.10)
On Sun, Oct 18, 2009 at 7:57 AM, Duncan Murdoch murd...@stats.uwo.ca wrote: On 17/10/2009 12:08 AM, Henrik Bengtsson wrote: On Fri, Oct 16, 2009 at 7:54 AM, Duncan Murdoch murd...@stats.uwo.ca wrote: On 10/16/2009 10:39 AM, Dieter Menne wrote: I noted that the new html-help in 2.10 under Windows uses a random port on my computer. This cause a problem, because when I create a link such as: http://127.0.0.1:28027/library/stats/html/addmargins.html this is for one-time use only. Is it possible to fix the port? Not currently. If you look in tools:::startDynamicHelp you can see how it is set up; you could duplicate that setup as a temporary workaround. You might be better off to build R with static help instead. What is the application where you want to be able to give out links? Perhaps we could consult an environment variable or option() to choose the port instead of leaving it completely random. The reason it is random is the worry that multiple R instances on the same machine might collide. All processes on the machine see the same ports. Related: I'd like to suggest an option/environment variable that specifies the set of port numbers sampled from, e.g. 6800:6850 or similar. I've added an option help.ports to set this. It will try your specified ports in order; if you want a random selection, permute them yourself, e.g. options(help.ports = sample(6800:6850)) This will make it into 2.10.0. Thanks. -Henrik Duncan Murdoch The reason is that in some places, the user don't have admin privileges on the computer and most/all ports are blocked from running servers, and there is a sysadm that needs to approve each port to be unblocked. With such a security polices it is possible to have the smaller set of port number unblocked (but not the full 0-65535 range). This applies at least to regular users on Windows. My $.02 /Henrik Duncan Murdoch __ 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R292 on AIX53 using gcc
Hello -- after my previous post, I tried to compile R 2.9.2 using xlc. The config.site changes are: == OBJECT_MODE=64 AR=ar -X64 R_SHELL=/usr/bin/bash CONFIG_SHELL=/usr/bin/bash CC=xlc_r -q64 CFLAGS=-O -qstrict CPPFLAGS=-I/usr/include -I/usr/local/include -I/opt/freeware/include -I/usr/X11R6/include CXX=xlC_r -q64 CXXFLAGS=-O -qstrict LDFLAGS=-L/opt/freeware/lib64 -L/opt/freeware/64/lib -L/opt/freeware/lib -L/usr/local/lib -L/usr/lib F77=xlf_r -q64 FFLAGS=-O -qstrict FC=xlf95 -q64 FCFLAGS=-O -qstrict MAKE=/opt/freeware/bin/make == Error -- mkdir ../../../../library/grDevices/libs Warning in solve.default(rgb) : unable to load shared library '/usr/local/R-2.9.2/modules//lapack.so': rtld: 0712-001 Symbol idamax was referenced from module /usr/local/R-2.9.2/lib/libRlapack.so(), but a runtime definition of the symbol was not found. rtld: 0712-001 Symbol dger was referenced from module /usr/local/R-2.9.2/lib/libRlapack.so(), but a runtime definition of the symbol was not found. .. Error in solve.default(rgb) : lapack routines cannot be loaded Error: unable to load R code in package 'grDevices' Execution halted make: The error code from the last command is 1. Thanks in advance. I would really appreciate any help. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
