[Rd] Bug in file.access on Windows when using network shares

[Nick Kennedy]

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

Re: [R-pkg-devel] Errors from Suggests or Enhances not in mainstream repositories

[Uwe Ligges]

On 03.07.2018 00:41, Ben Bolker wrote:

Thanks, Uwe.  Responses inline.

On Mon, Jul 2, 2018 at 6:23 PM Uwe Ligges
 wrote:




On 03.07.2018 00:13, Ben Bolker wrote:

I got something similar.  I have a few thoughts:

(1) you should use  "if (require(citrus)) { ... }" in your examples;
"Suggests" and "Enhances" packages are supposed to be *optional*, i.e.
examples and tests should be able to run even if they're not installed
(I would imagine that "Writing R Extensions" and/or the CRAN policies
say something to this effect, but I haven't checked)
(2) I can imagine that win-builder is looking for *binary* versions of
the package (I'm not sure why this would be the default, and why it
couldn't fall back and install from source, but that would be my
guess); do you have binary versions, for the appropriate major R
version (i.e. 3.5 for release, maybe?? 3.4 for oldrelease??), in your
repo. (In my example, I don't; I was going to try compiling a binary
version and putting it in the repo. This is a bit of a chicken-and-egg
problem if you can't get a binary built because the examples fail, but
if you implement step #1 I think it should work).

My point (3) is a follow-on question that I would love an answer to,
or hints. I get a *message* similar to the one found in throm's
win-builder logs, i.e. "Suggests or Enhances not in mainstream
repositories: ..." - but since it's not labeled as a WARNING or an
ERROR (or even a NOTE), I am wondering what its status is in the
CRAN-maintainers' eyes - is it a CRAN-submission-blocking problem? Or
a "we'd rather you didn't do that but we'll accept it this time?" or
...



Uwe> Ideally packages are in mainstream repositories.

   Agreed.

Uwe> For waek dependencies such as Suggests or Enhances, and if the package
Uwe> is in some repository, you can declare it via the
Uwe> Additional_Repositories field.

   I did that (so did the OP). Speaking for myself (since I'm not sure
of the OP's exact situation), I know that the source tarball is in my
repo, and it gets installed successfully on Linux and MacOS. On
Windows (win-builder), the package is not detected in the repo. I can
try adding a Windows binary to the repo to see if that solves the
problem.


Ah, no, it won't be installed. We only isntall from mainstream repositories.




   FWIW, one of the off-CRAN packages I Suggest: is INLA (which is
beyond my control). The other is glmmADMB, which includes a binary
blob and can't go on CRAN.  I would like to offer some support for
these packages, if at all possible.

I just don't know if the message about the package *not* being found
in the repo suggested by Additional_repositories: will be
CRAN-blocking (and would prefer not to waste everyone's time by
submitting if it is ...)


If it is correctly declared, it is not blocking.

Best,
Uwe


Uwe> Finally, if not even in a repository, explain in the Descripton field
Uwe> how to get it.


Best,
Uwe Ligges



 I'm not asking anyone (except possibly CRAN maintainers) to speak
for the CRAN maintainers, but if anyone has any experience or guesses
(or pointers to parts of the CRAN policies/Writing R Extensions
document that I overlooked) I'd appreciate hearing about it.

cheers
   Ben Bolker
On Mon, Jul 2, 2018 at 5:28 PM Throm, Allison  wrote:


Hi all,


I'm trying to submit a package to the CRAN that further examines results from the 
"citrus" package as done for an accepted publication (available on Github: 
).


I do not get any errors when using devtools::check() on my Mac, which already has the 
citrus package installed. However, I am getting errors during the CRAN submission 
check 
.


I've tried searching Stack Overload and other CRAN packages with 
Additional_repositories fields, but none of the applicable solutions have worked. I'm 
pretty sure it's the loading of the citrus package that is causing the error and have 
added the Additional_repositories field with a link the package on Github, but still 
haven't been able to resolve the issue. There are very specific installation 
instructions for the package 
, which may be 
contributing to issues.


How should I properly specify dependencies on the 
nolanlab/citrus Github package for my CRAN 
package?


Thank you in advance,

Allison






  [[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[Rd] MARGIN in base::unique.matrix() and base::unique.array()

[Hervé Pagès]

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: [R-pkg-devel] Errors from Suggests or Enhances not in mainstream repositories

[Ben Bolker]

Thanks, Uwe.  Responses inline.

On Mon, Jul 2, 2018 at 6:23 PM Uwe Ligges
 wrote:
>
>
>
> On 03.07.2018 00:13, Ben Bolker wrote:
> > I got something similar.  I have a few thoughts:
> >
> > (1) you should use  "if (require(citrus)) { ... }" in your examples;
> > "Suggests" and "Enhances" packages are supposed to be *optional*, i.e.
> > examples and tests should be able to run even if they're not installed
> > (I would imagine that "Writing R Extensions" and/or the CRAN policies
> > say something to this effect, but I haven't checked)
> > (2) I can imagine that win-builder is looking for *binary* versions of
> > the package (I'm not sure why this would be the default, and why it
> > couldn't fall back and install from source, but that would be my
> > guess); do you have binary versions, for the appropriate major R
> > version (i.e. 3.5 for release, maybe?? 3.4 for oldrelease??), in your
> > repo. (In my example, I don't; I was going to try compiling a binary
> > version and putting it in the repo. This is a bit of a chicken-and-egg
> > problem if you can't get a binary built because the examples fail, but
> > if you implement step #1 I think it should work).
> >
> > My point (3) is a follow-on question that I would love an answer to,
> > or hints. I get a *message* similar to the one found in throm's
> > win-builder logs, i.e. "Suggests or Enhances not in mainstream
> > repositories: ..." - but since it's not labeled as a WARNING or an
> > ERROR (or even a NOTE), I am wondering what its status is in the
> > CRAN-maintainers' eyes - is it a CRAN-submission-blocking problem? Or
> > a "we'd rather you didn't do that but we'll accept it this time?" or
> > ...
>
Uwe> Ideally packages are in mainstream repositories.

  Agreed.

Uwe> For waek dependencies such as Suggests or Enhances, and if the package
Uwe> is in some repository, you can declare it via the
Uwe> Additional_Repositories field.

  I did that (so did the OP). Speaking for myself (since I'm not sure
of the OP's exact situation), I know that the source tarball is in my
repo, and it gets installed successfully on Linux and MacOS. On
Windows (win-builder), the package is not detected in the repo. I can
try adding a Windows binary to the repo to see if that solves the
problem.

  FWIW, one of the off-CRAN packages I Suggest: is INLA (which is
beyond my control). The other is glmmADMB, which includes a binary
blob and can't go on CRAN.  I would like to offer some support for
these packages, if at all possible.

I just don't know if the message about the package *not* being found
in the repo suggested by Additional_repositories: will be
CRAN-blocking (and would prefer not to waste everyone's time by
submitting if it is ...)

Uwe> Finally, if not even in a repository, explain in the Descripton field
Uwe> how to get it.
>
> Best,
> Uwe Ligges
>
> >
> > I'm not asking anyone (except possibly CRAN maintainers) to speak
> > for the CRAN maintainers, but if anyone has any experience or guesses
> > (or pointers to parts of the CRAN policies/Writing R Extensions
> > document that I overlooked) I'd appreciate hearing about it.
> >
> >cheers
> >   Ben Bolker
> > On Mon, Jul 2, 2018 at 5:28 PM Throm, Allison  wrote:
> >>
> >> Hi all,
> >>
> >>
> >> I'm trying to submit a package to the CRAN that further examines results 
> >> from the "citrus" package as done for an accepted publication (available 
> >> on Github: ).
> >>
> >>
> >> I do not get any errors when using devtools::check() on my Mac, which 
> >> already has the citrus package installed. However, I am getting errors 
> >> during the CRAN submission check 
> >> .
> >>
> >>
> >> I've tried searching Stack Overload and other CRAN packages with 
> >> Additional_repositories fields, but none of the applicable solutions have 
> >> worked. I'm pretty sure it's the loading of the citrus package that is 
> >> causing the error and have added the Additional_repositories field with a 
> >> link the package on Github, but still haven't been able to resolve the 
> >> issue. There are very specific installation instructions for the package 
> >> , which may be 
> >> contributing to issues.
> >>
> >>
> >> How should I properly specify dependencies on the 
> >> nolanlab/citrus Github package for my 
> >> CRAN package?
> >>
> >>
> >> Thank you in advance,
> >>
> >> Allison
> >>
> >>
> >>
> >>
> >>
> >>
> >>  [[alternative HTML version deleted]]
> >>
> >> __
> >> R-package-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >

Re: [R-pkg-devel] Errors from Suggests or Enhances not in mainstream repositories

[Uwe Ligges]

On 03.07.2018 00:13, Ben Bolker wrote:

I got something similar.  I have a few thoughts:

(1) you should use  "if (require(citrus)) { ... }" in your examples;
"Suggests" and "Enhances" packages are supposed to be *optional*, i.e.
examples and tests should be able to run even if they're not installed
(I would imagine that "Writing R Extensions" and/or the CRAN policies
say something to this effect, but I haven't checked)
(2) I can imagine that win-builder is looking for *binary* versions of
the package (I'm not sure why this would be the default, and why it
couldn't fall back and install from source, but that would be my
guess); do you have binary versions, for the appropriate major R
version (i.e. 3.5 for release, maybe?? 3.4 for oldrelease??), in your
repo. (In my example, I don't; I was going to try compiling a binary
version and putting it in the repo. This is a bit of a chicken-and-egg
problem if you can't get a binary built because the examples fail, but
if you implement step #1 I think it should work).

My point (3) is a follow-on question that I would love an answer to,
or hints. I get a *message* similar to the one found in throm's
win-builder logs, i.e. "Suggests or Enhances not in mainstream
repositories: ..." - but since it's not labeled as a WARNING or an
ERROR (or even a NOTE), I am wondering what its status is in the
CRAN-maintainers' eyes - is it a CRAN-submission-blocking problem? Or
a "we'd rather you didn't do that but we'll accept it this time?" or
...


Ideally packages are in mainstream repositories.
For waek dependencies such as Suggests or Enhances, and if the package 
is in some repository, you can declare it via the 
Additional_Repositories field.
Finally, if not even in a repository, explain in the Descripton field 
how to get it.


Best,
Uwe Ligges



I'm not asking anyone (except possibly CRAN maintainers) to speak
for the CRAN maintainers, but if anyone has any experience or guesses
(or pointers to parts of the CRAN policies/Writing R Extensions
document that I overlooked) I'd appreciate hearing about it.

   cheers
  Ben Bolker
On Mon, Jul 2, 2018 at 5:28 PM Throm, Allison  wrote:


Hi all,


I'm trying to submit a package to the CRAN that further examines results from the 
"citrus" package as done for an accepted publication (available on Github: 
).


I do not get any errors when using devtools::check() on my Mac, which already has the 
citrus package installed. However, I am getting errors during the CRAN submission 
check 
.


I've tried searching Stack Overload and other CRAN packages with 
Additional_repositories fields, but none of the applicable solutions have worked. I'm 
pretty sure it's the loading of the citrus package that is causing the error and have 
added the Additional_repositories field with a link the package on Github, but still 
haven't been able to resolve the issue. There are very specific installation 
instructions for the package 
, which may be 
contributing to issues.


How should I properly specify dependencies on the 
nolanlab/citrus Github package for my CRAN 
package?


Thank you in advance,

Allison






 [[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Errors from Suggests or Enhances not in mainstream repositories

[Ben Bolker]

I got something similar.  I have a few thoughts:

(1) you should use  "if (require(citrus)) { ... }" in your examples;
"Suggests" and "Enhances" packages are supposed to be *optional*, i.e.
examples and tests should be able to run even if they're not installed
(I would imagine that "Writing R Extensions" and/or the CRAN policies
say something to this effect, but I haven't checked)
(2) I can imagine that win-builder is looking for *binary* versions of
the package (I'm not sure why this would be the default, and why it
couldn't fall back and install from source, but that would be my
guess); do you have binary versions, for the appropriate major R
version (i.e. 3.5 for release, maybe?? 3.4 for oldrelease??), in your
repo. (In my example, I don't; I was going to try compiling a binary
version and putting it in the repo. This is a bit of a chicken-and-egg
problem if you can't get a binary built because the examples fail, but
if you implement step #1 I think it should work).

My point (3) is a follow-on question that I would love an answer to,
or hints. I get a *message* similar to the one found in throm's
win-builder logs, i.e. "Suggests or Enhances not in mainstream
repositories: ..." - but since it's not labeled as a WARNING or an
ERROR (or even a NOTE), I am wondering what its status is in the
CRAN-maintainers' eyes - is it a CRAN-submission-blocking problem? Or
a "we'd rather you didn't do that but we'll accept it this time?" or
...

   I'm not asking anyone (except possibly CRAN maintainers) to speak
for the CRAN maintainers, but if anyone has any experience or guesses
(or pointers to parts of the CRAN policies/Writing R Extensions
document that I overlooked) I'd appreciate hearing about it.

  cheers
 Ben Bolker
On Mon, Jul 2, 2018 at 5:28 PM Throm, Allison  wrote:
>
> Hi all,
>
>
> I'm trying to submit a package to the CRAN that further examines results from 
> the "citrus" package as done for an accepted publication (available on 
> Github: ).
>
>
> I do not get any errors when using devtools::check() on my Mac, which already 
> has the citrus package installed. However, I am getting errors during the 
> CRAN submission check 
> .
>
>
> I've tried searching Stack Overload and other CRAN packages with 
> Additional_repositories fields, but none of the applicable solutions have 
> worked. I'm pretty sure it's the loading of the citrus package that is 
> causing the error and have added the Additional_repositories field with a 
> link the package on Github, but still haven't been able to resolve the issue. 
> There are very specific installation instructions for the package 
> , which may be 
> contributing to issues.
>
>
> How should I properly specify dependencies on the 
> nolanlab/citrus Github package for my 
> CRAN package?
>
>
> Thank you in advance,
>
> Allison
>
>
>
>
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Errors from Suggests or Enhances not in mainstream repositories

[Throm, Allison]

Hi all,


I'm trying to submit a package to the CRAN that further examines results from 
the "citrus" package as done for an accepted publication (available on Github: 
).


I do not get any errors when using devtools::check() on my Mac, which already 
has the citrus package installed. However, I am getting errors during the CRAN 
submission check 
.


I've tried searching Stack Overload and other CRAN packages with 
Additional_repositories fields, but none of the applicable solutions have 
worked. I'm pretty sure it's the loading of the citrus package that is causing 
the error and have added the Additional_repositories field with a link the 
package on Github, but still haven't been able to resolve the issue. There are 
very specific installation instructions for the package 
, which may be 
contributing to issues.


How should I properly specify dependencies on the 
nolanlab/citrus Github package for my CRAN 
package?


Thank you in advance,

Allison






[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Rd] base::mean not consistent about NA/NaN

[Barry Rowlingson]

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: [Bioc-devel] Merging master to RELEASE brance

[Shepherd, Lori]

The RELEASE_3_6 branch is frozen and cannot be updated but I assume you mean 
RELEASE_3_7 ...


For the record,  unless these changes are bug corrections it is not recommended 
to update the RELEASE_3_7 branch.


The easiest and safest way is to cherry-pick commits from the master branch to 
your RELEASE_3_7 branch and adjusting any versions bumps to be appropriate for 
release.


See

http://bioconductor.org/developers/how-to/git/bug-fix-in-release-and-devel/

http://bioconductor.org/developers/how-to/version-numbering/






Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Christian Page 

Sent: Monday, July 2, 2018 1:48:53 PM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Merging master to RELEASE brance

Hi,

What are it easiest (and safest) way to merge to updates from the devel
(master) branch to the RELEASE_3_6 branch in git?

Best,
Christian

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Merging master to RELEASE brance

[Christian Page]

Hi,

What are it easiest (and safest) way to merge to updates from the devel
(master) branch to the RELEASE_3_6 branch in git?

Best,
Christian

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] base::mean not consistent about NA/NaN

[Duncan Murdoch]

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

[Duncan Murdoch]

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

[Ista Zahn]

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

[Jan Gorecki]

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

[Duncan Murdoch]

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

[Witold E Wolski]

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

[Duncan Murdoch]

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