[Rd] minor tick marks for plots (PR#13616)
Hello, I think I found a bug: > windows(1,width = 10, height = 10, pointsize = 5,xpos = 0, ypos = 0 ) > hdata[1:3,1] <- c(1,10,15) > hdata[1:3,2] <- c(2,1,4) > plot(hdata[,1],hdata[,2],xaxt="n") > axis(1,at=c(2,10,14)) > minor.tick(nx=2, ny=1,tick.ratio=1) the minor tick marks appear between the tick marks which would have been drawn without the option xaxt="n". I use R.2.8.1. Best Regards Bernd Wiese Dr. Bernd Wiese Dipl.-Ing., MSc Centre for CO2 Storage Phone.: +49 (0)331/288-1823 FAX: +49 (0)331/288-1529 Email: wi...@gfz-potsdam.de Building A34, room 204 ___ Helmholtz Centre Potsdam GFZ German Research Centre For Geosciences Public Law Foundation State of Brandenburg Telegrafenberg, 14473 Potsdam __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] minor tick marks for plots (PR#13616)
On 20/03/2009 3:00 PM, wi...@gfz-potsdam.de wrote: Hello, I think I found a bug: > windows(1,width = 10, height = 10, pointsize = 5,xpos = 0, ypos = 0 ) > hdata[1:3,1] <- c(1,10,15) > hdata[1:3,2] <- c(2,1,4) > plot(hdata[,1],hdata[,2],xaxt="n") > axis(1,at=c(2,10,14)) > minor.tick(nx=2, ny=1,tick.ratio=1) the minor tick marks appear between the tick marks which would have been drawn without the option xaxt="n". minor.tick is not a base R function, so this is not an R bug, if it's a bug at all. There's a function by that name in the Hmisc package, but you don't give enough information (e.g. printing sessionInfo()) so I can't tell if that's the one you used. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] unlink fails to remove symbolic links
unlink fails to remove symbolic links. This is more prominent now --
when a package creates symbolic links during installation, 00LOCK is
not removed.
Martin
> setwd(tempdir())
> fl <- tempfile(); file.create(fl)
[1] TRUE
> lnFile <- tempfile(); system(paste("ln -s", fl, lnFile))
> list.files()
[1] "file19495cff" "file74b0dc51"
> unlink(fl); unlink(lnFile)
> list.files()
[1] "file19495cff"
> lnFile
[1] "/tmp/Rtmpb0kd7B/file19495cff"
> sessionInfo()
R version 2.10.0 Under development (unstable) (2009-03-21 r48173)
x86_64-unknown-linux-gnu
locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-\
8;LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_2.10.0
--
Martin Morgan
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M2 B169
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unlink fails to remove symbolic links
A little more precisely, unlink fails when the file being unlinked is
a broken symbolic link (as in the example below). This is because
R_FileExists checks stat() == 0, and stat fails (returns -1) when
trying to resolve the broken link. Perhaps lstat() is more
appropriate?
Martin
Martin Morgan writes:
> unlink fails to remove symbolic links. This is more prominent now --
> when a package creates symbolic links during installation, 00LOCK is
> not removed.
>
> Martin
>
>> setwd(tempdir())
>> fl <- tempfile(); file.create(fl)
> [1] TRUE
>> lnFile <- tempfile(); system(paste("ln -s", fl, lnFile))
>> list.files()
> [1] "file19495cff" "file74b0dc51"
>> unlink(fl); unlink(lnFile)
>> list.files()
> [1] "file19495cff"
>> lnFile
> [1] "/tmp/Rtmpb0kd7B/file19495cff"
>
>> sessionInfo()
> R version 2.10.0 Under development (unstable) (2009-03-21 r48173)
> x86_64-unknown-linux-gnu
>
> locale:
> LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-\
> 8;LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> loaded via a namespace (and not attached):
> [1] tools_2.10.0
--
Martin Morgan
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M2 B169
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] vignette index not linked into HTML help system for package
On 16/03/2009 7:16 AM, Thomas Petzoldt wrote: Dear R developers, I observed that the html help page index entry "Read overview or browse directory" for package vignettes is missing in recent R-devel. Thanks for the report. This is fixed now and will make it into the next release. The code to build the HTML page was translated from Perl to R, and the lines to do this part were accidentally omitted. Duncan Murdoch This happened on two independent computers (WinXP Prof. SP3, German) with R-devel compiled from sources svn rev. 48125 resp. 48128 It's the same for my own and also for more prominent packages as well (e.g. grid). The vignettes and the index.html files exist and vignette() as well as browseVignettes() work as expected. I have not found anything about this in NEWS or "Writing R extensions", which says: "At install time an HTML index for all vignettes is automatically created from the \VignetteIndexEntry statements unless a file index.html exists in directory inst/doc. This index is linked into the HTML help system for each package." Have I missed something? Thanks a lot Thomas Petzoldt __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unlink fails to remove symbolic links
On Sat, 21 Mar 2009, Martin Morgan wrote:
A little more precisely, unlink fails when the file being unlinked is
a broken symbolic link (as in the example below). This is because
R_FileExists checks stat() == 0, and stat fails (returns -1) when
trying to resolve the broken link. Perhaps lstat() is more
appropriate?
lstat is not portable, and I don't think it is appropriate for most
uses of R_FileExists.
I don't think there is anything new about this, and it does seem only
to apply to broken links. At a quick look the best solution looks to
be to remove the pretest, but I need to check in more detail.
Martin
Martin Morgan writes:
unlink fails to remove symbolic links. This is more prominent now --
when a package creates symbolic links during installation, 00LOCK is
not removed.
Martin
setwd(tempdir())
fl <- tempfile(); file.create(fl)
[1] TRUE
lnFile <- tempfile(); system(paste("ln -s", fl, lnFile))
list.files()
[1] "file19495cff" "file74b0dc51"
unlink(fl); unlink(lnFile)
list.files()
[1] "file19495cff"
lnFile
[1] "/tmp/Rtmpb0kd7B/file19495cff"
sessionInfo()
R version 2.10.0 Under development (unstable) (2009-03-21 r48173)
x86_64-unknown-linux-gnu
locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-\
8;LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_2.10.0
--
Martin Morgan
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M2 B169
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
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] documenting datasets with more than one object
I am trying to put an rda (R save image) file that contains multiple R objects in a contributed package. From the example of the BJsales data in package "datasets" it seems this is o. k. But I am puzzled by some of what "Writing R Extensions" says. Section 1.1.3 mentions datalist files. Do I have to have one in this case? Section 2.1.2 says The \usage entry is always bar or (for packages which do not use lazy-loading of data) data(bar). (In particular, only document a single data object per Rd file.) What does that mean? I have to describe all of the objects in the file, but I only "document" one of them? Is the Rd file for BJsales just wrong? What if the rda file is sim.rda and so data(sim) is used to load it, but "sim" is not the name of one of the R objects in rda file? Is there a better example for how to do this? My package passes R CMD check but I don't want to ship it to CRAN if it is doing something considered harmful. -- Charles Geyer Professor, School of Statistics University of Minnesota __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] gsub('(.).(.)(.)', '\\3\\2\\1', 'gsub')
there seems to be something wrong with r's regexing. consider the
following example:
gregexpr('a*|b', 'ab')
# positions: 1 2
# lengths: 1 1
gsub('a*|b', '.', 'ab')
# ..
where the pattern matches any number of 'a's or one b, and replaces the
match with a dot, globally. the answer is correct (assuming a dfa
engine). however,
gregexpr('a*|b', 'ab', perl=TRUE)
# positions: 1 2
# lengths: 1 0
gsub('a*|b', '.', 'ab', perl=TRUE)
# .b.
where the pattern is identical, but the result is wrong. perl uses an
nfa (if it used a dfa, the result would still be wrong), and in the
above example it should find *four* matches, collectively including
*all* letters in the input, thus producing *four* dots (and *only* dots)
in the output:
perl -le '
$input = qq|ab|;
print qq|match: "$_"| foreach $input =~ /a*|b/g;
$input =~ s/a*|b/./g;
print qq|output: "$input"|;'
# match: "a"
# match: ""
# match: "b"
# match: ""
# output: ""
since with perl=TRUE both gregexpr and gsub seem to use pcre, i've
checked the example with pcretest, and also with a trivial c program
(available on demand) using the pcre api; there were four matches,
exactly as in the perl bit above.
the results above are surprising, and suggest a bug in r's use of pcre
rather than in pcre itself. possibly, the issue is that when an empty
sting is matched (with a*, for example), the next attempt is not trying
to match a non-empty string at the same position, but rather an empty
string again at the next position. for example,
gsub('a|b|c', '.', 'abc', perl=TRUE)
# "...", correct
gsub('a*|b|c', '.', 'abc', perl=TRUE)
# ".b.c.", wrong
gsub('a|b*|c', '.', 'abc', perl=TRUE)
# "..c.", wrong (but now only 'c' remains)
gsub('a|b*|c', '.', 'aba', perl=TRUE)
# "...", incidentally correct
without detailed analysis of the code, i guess the bug is located
somewhere in src/main/pcre.c, and is distributed among the do_p*
functions, so that multiple fixes may be needed.
vQ
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
