[Rd] Bug in file.access on Windows when using network shares
Dear R-Devel, I've run into an issue with a package (vcfR) that uses file.access to check a file is readable before opening it. The issue is actually in base R though. I've looked into the package code, and it calls file.access(path, mode = 4). I've created a minimal working example of the code in winAccessW from src/gnuwin32/extra.c, and the problem arises when GetFileSecurityW is called on shared files under certain circumstances. One situation I've seen it in are when a file is shared from a non-Windows host (e.g. Linux), which is similar to the situation documented at https://social.msdn.microsoft.com/Forums/sqlserver/en-US/f57928d3-d89b-426d-a174-d06d97355afc/how-to-check-if-a-filefolder-is-writable-or-not?forum=windowssdk . The other situation arises when a file is cached offline by Windows Offline files feature. The call to GetFileSecurityW works fine when the network is up (and so the file is being accessed from the share), but fails when the network is down and the file is being accessed from the offline files cache. Is there any reason that there is a custom function here? Windows supports the use of access (as is used on other OSes), although the ISO C++ _waccess would be preferred. This seems to work well even in situations where the current code does not. BW Nick [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] MARGIN in base::unique.matrix() and base::unique.array()
Hi,
The man page for base::unique.matrix() and base::unique.array() says
that MARGIN is expected to be a single integer. OTOH the code in charge
of checking the user supplied MARGIN is:
if (length(MARGIN) > ndim || any(MARGIN > ndim))
stop(gettextf("MARGIN = %d is invalid for dim = %d",
MARGIN, dx), domain = NA)
which doesn't really make sense.
As a consequence the user gets an obscure error message when specifying
a MARGIN that satisfies the above check but is in fact invalid:
> unique(matrix(1:10, ncol=2), MARGIN=1:2)
Error in args[[MARGIN]] <- !duplicated.default(temp, fromLast =
fromLast, :
object of type 'symbol' is not subsettable
Also the code used by the above check to generate the error message
is broken:
> unique(matrix(1:10, ncol=2), MARGIN=1:3)
Error in sprintf(gettext(fmt, domain = domain), ...) :
arguments cannot be recycled to the same length
> unique(matrix(1:10, ncol=2), MARGIN=3)
Error in unique.matrix(matrix(1:10, ncol = 2), MARGIN = 3) :
c("MARGIN = 3 is invalid for dim = 5", "MARGIN = 3 is invalid for
dim = 2")
Thanks,
H.
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] base::mean not consistent about NA/NaN
And for a starker example of this (documented) inconsistency, arithmetic addition is not commutative: > NA + NaN [1] NA > NaN + NA [1] NaN On Mon, Jul 2, 2018 at 5:32 PM, Duncan Murdoch wrote: > On 02/07/2018 11:25 AM, Jan Gorecki wrote: >> Hi, >> base::mean is not consistent in terms of handling NA/NaN. >> Mean should not depend on order of its arguments while currently it is. > > The result of mean() can depend on the order even with regular numbers. > For example, > > > x <- rep(c(1, 10^(-15)), 100) > > mean(sort(x)) - 0.5 > [1] 5.551115e-16 > > mean(rev(sort(x))) - 0.5 > [1] 0 > > >> >> mean(c(NA, NaN)) >> #[1] NA >> mean(c(NaN, NA)) >> #[1] NaN >> >> I created issue so in case of no replies here status of it can be looked up >> at: >> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17441 > > The help page for ?NaN says, > > "Computations involving NaN will return NaN or perhaps NA: which of > those two is not guaranteed and may depend on the R platform (since > compilers may re-order computations)." > > And ?NA says, > > "Numerical computations using NA will normally result in NA: a possible > exception is where NaN is also involved, in which case either might > result (which may depend on the R platform). " > > So I doubt if this inconsistency will be fixed. > > Duncan Murdoch > >> >> Best, >> Jan >> >> [[alternative HTML version deleted]] >> >> __ >> 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] base::mean not consistent about NA/NaN
On 02/07/2018 11:25 AM, Jan Gorecki wrote: Hi, base::mean is not consistent in terms of handling NA/NaN. Mean should not depend on order of its arguments while currently it is. The result of mean() can depend on the order even with regular numbers. For example, > x <- rep(c(1, 10^(-15)), 100) > mean(sort(x)) - 0.5 [1] 5.551115e-16 > mean(rev(sort(x))) - 0.5 [1] 0 mean(c(NA, NaN)) #[1] NA mean(c(NaN, NA)) #[1] NaN I created issue so in case of no replies here status of it can be looked up at: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17441 The help page for ?NaN says, "Computations involving NaN will return NaN or perhaps NA: which of those two is not guaranteed and may depend on the R platform (since compilers may re-order computations)." And ?NA says, "Numerical computations using NA will normally result in NA: a possible exception is where NaN is also involved, in which case either might result (which may depend on the R platform). " So I doubt if this inconsistency will be fixed. Duncan Murdoch Best, Jan [[alternative HTML version deleted]] __ 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] Parametrized Vignettest in R packages
On 02/07/2018 11:22 AM, Witold E Wolski wrote:
Hello,
Thank you for the questions as well as remaining me of the default
parameters in the yaml session.
Indeed this seems to be the solution.
But how would I assign package data as a default parameter?
So originally I thought to render the markdown with :
data(sample_analysis)
data(skylineconfig)
x <- rmarkdown::render("report.Rmd", output_format = "html_document",
params = list(data = sample_analysis,
configuration =
skylineconfig),envir = new.env())
I do not think I can write:
params:
configuration: !r data(sample_analysis)
data: !r data(skylineconfig)
since data does not return the package just puts them in the env as a
side effect. Is there a different base function to achieve it.
I think you could use
params:
configuration: !r get(data(sample_analysis))
data: !r get(data(skylineconfig))
but if that doesn't work, a longer version is
params:
configuration: !r {data(sample_analysis); sample_analysis}
data: !r {data(skylineconfig); skylineconfig}
Duncan Murdoch
Thank you
Witek
On 2 July 2018 at 16:56, Duncan Murdoch wrote:
On 02/07/2018 10:30 AM, Witold E Wolski wrote:
Hello,
I have a package which includes some parameterized r-markdown report
which I would also like to build as package vignettes.
Is there a way to run the parameterized vignette creation with the
package build or package check?
Doesn't the usual method work? You can specify defaults for parameters in
the YAML header; I'd expect those to be the parameter values that get used.
You can give instructions to your users on how to rebuild the reports with
different parameters.
Duncan Murdoch
Thank you
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] base::mean not consistent about NA/NaN
The current behavior is as documented. See ?NA, which says "Numerical computations using ‘NA’ will normally result in ‘NA’: a possible exception is where ‘NaN’ is also involved, in which case either might result" --Ista On Mon, Jul 2, 2018 at 11:25 AM, Jan Gorecki wrote: > Hi, > base::mean is not consistent in terms of handling NA/NaN. > Mean should not depend on order of its arguments while currently it is. > > mean(c(NA, NaN)) > #[1] NA > mean(c(NaN, NA)) > #[1] NaN > > I created issue so in case of no replies here status of it can be looked up > at: > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17441 > > Best, > Jan > > [[alternative HTML version deleted]] > > __ > 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] base::mean not consistent about NA/NaN
Hi, base::mean is not consistent in terms of handling NA/NaN. Mean should not depend on order of its arguments while currently it is. mean(c(NA, NaN)) #[1] NA mean(c(NaN, NA)) #[1] NaN I created issue so in case of no replies here status of it can be looked up at: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17441 Best, Jan [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Parametrized Vignettest in R packages
On 02/07/2018 10:34 AM, Gabe Becker wrote: Witold, Vignettes, in the package sense, are and must be entirely self-contained as far as I know. They are run automatically in completely clean R sessions. I'm not sure a parameterized vignette makes a ton of sense within that context. The defaults for parameters are contained in the source, so a vignette using default parameter values would be completely self-contained. It seems like a good way to document parameterized reports: Include one as a vignette that has more explanation about what the parameters mean, how they are used, etc. Then users can try it out with new parameter values before customizing it to their own needs. Duncan Murdoch Can you explain what you would want to have happen when the package is built that would require parameterization? ~G On Mon, Jul 2, 2018 at 7:30 AM, Witold E Wolski wrote: Hello, I have a package which includes some parameterized r-markdown report which I would also like to build as package vignettes. Is there a way to run the parameterized vignette creation with the package build or package check? Thank you -- Witold Eryk Wolski __ 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] Parametrized Vignettest in R packages
Hello,
Thank you for the questions as well as remaining me of the default
parameters in the yaml session.
Indeed this seems to be the solution.
But how would I assign package data as a default parameter?
So originally I thought to render the markdown with :
data(sample_analysis)
data(skylineconfig)
x <- rmarkdown::render("report.Rmd", output_format = "html_document",
params = list(data = sample_analysis,
configuration =
skylineconfig),envir = new.env())
I do not think I can write:
params:
configuration: !r data(sample_analysis)
data: !r data(skylineconfig)
since data does not return the package just puts them in the env as a
side effect. Is there a different base function to achieve it.
Thank you
Witek
On 2 July 2018 at 16:56, Duncan Murdoch wrote:
> On 02/07/2018 10:30 AM, Witold E Wolski wrote:
>>
>> Hello,
>>
>> I have a package which includes some parameterized r-markdown report
>> which I would also like to build as package vignettes.
>>
>> Is there a way to run the parameterized vignette creation with the
>> package build or package check?
>
>
>
> Doesn't the usual method work? You can specify defaults for parameters in
> the YAML header; I'd expect those to be the parameter values that get used.
>
> You can give instructions to your users on how to rebuild the reports with
> different parameters.
>
> Duncan Murdoch
>
>>
>> Thank you
>>
>
--
Witold Eryk Wolski
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Parametrized Vignettest in R packages
On 02/07/2018 10:30 AM, Witold E Wolski wrote: Hello, I have a package which includes some parameterized r-markdown report which I would also like to build as package vignettes. Is there a way to run the parameterized vignette creation with the package build or package check? Doesn't the usual method work? You can specify defaults for parameters in the YAML header; I'd expect those to be the parameter values that get used. You can give instructions to your users on how to rebuild the reports with different parameters. Duncan Murdoch Thank you __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Parametrized Vignettest in R packages
Witold, Vignettes, in the package sense, are and must be entirely self-contained as far as I know. They are run automatically in completely clean R sessions. I'm not sure a parameterized vignette makes a ton of sense within that context. Can you explain what you would want to have happen when the package is built that would require parameterization? ~G On Mon, Jul 2, 2018 at 7:30 AM, Witold E Wolski wrote: > Hello, > > I have a package which includes some parameterized r-markdown report > which I would also like to build as package vignettes. > > Is there a way to run the parameterized vignette creation with the > package build or package check? > > Thank you > > -- > Witold Eryk Wolski > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- Gabriel Becker, Ph.D Scientist Bioinformatics and Computational Biology Genentech Research [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Parametrized Vignettest in R packages
Hello, I have a package which includes some parameterized r-markdown report which I would also like to build as package vignettes. Is there a way to run the parameterized vignette creation with the package build or package check? Thank you -- Witold Eryk Wolski __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
