[R-pkg-devel] *not* re-making package if contents haven't changed

[Greg Minshall]

hi.  i use emacs org-mode to write my literate (semi-, in my case)
code.  then, 'tangle' the results into package/R/foo.R, etc.

the tangling is driven by a makefile.  (my methodology is to make the
package source tree as a subdirectory of where my makefile sits; i
realize this is non-standard, and in many respects sub-optimal.)

the makefile then proceeds to R-CMD-build, R-CMD-check, and, assuming
those pass, Rscript-install the package.

i would like to *not* do the build/check/install if, in fact, nothing
has changed in the tangled files since the last time the
build/check/install ran.  the *dates* of the files (which is what make
typically looks at) *will* have changed.  but, i want to rely on the
contents, not on the dates.

i can imagine various hacks to accomplish this.  but, i thought that
someone on the list may have run into this before and have a
recommendation.

if so, i'm all ears!  thanks in advance.

cheers, Greg

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

[Rd] eval and Calling Frames

[brodie gaslam via R-devel]

 I ran into an interesting issue with `evalq` (and also
`eval(quote(...))`):

 f <- function() {
   list(
 sys.parent(1),
 evalq(sys.parent(1)),
 evalq((function() sys.parent(2))()),  # add an anon fun layer
 evalq((function() sys.parent(1))())
   )
 }
 res <- f()
 str(res)
 ## List of 4
 ##  $ : int 0 # sys.parent(1)
 ##  $ : int 2 # evalq(sys.parent(1))
 ##  $ : int 0 # evalq((function() sys.parent(2))())
 ##  $ : int 1 # evalq((function() sys.parent(1))())

In order of least to most surprising:

1. `sys.parent(1)` and `evalq(sys.parent(1))` are not the same
2. `evalq(sys.parent(1))` and `evalq((function() sys.parent(2))())`
   are not the same
3. `evalq((function() sys.parent(1))())` returns a lower frame number
   than `evalq(sys.parent(1))`

The root cause of this is that the `evalq` **closure** sets a context,
but then the C-level `do_eval` it invokes sets another one[1] with the
new `evalq` context as the calling frame (`cptr->sysparent`)[2].  This
then interacts with how `sys.parent` resolves parents when a target
frame appears more than once in the context stack.  `sys.parent`
returns the oldest context that matches[3], and in this case `f`'s
frame appears twice because `evalq` adds it via `do_eval`.

One option is to change what `sysparent` of the `evalq` `envir`.
For example, if we set it to be the same as it would be for commands
outside the `evalq` we get:

 str(res)
 ## List of 4
 ##  $ : int 0 # sys.parent(1)
 ##  $ : int 0 # evalq(sys.parent(1))
 ##  $ : int 0 # evalq((function() sys.parent(2))())
 ##  $ : int 1 # evalq((function() sys.parent(1))())

There is precedent for doing this in S3 generics and their methods
where method `sysparent` is set to be that of the generic.  Now
`evalq` no longer interferes with the resolution of calling frames.
It seems reasonable to set evaluation environments without affecting
what the calling frame is. Indeed that happens when we do something like
`environment(fun) <- blah` as the calling frame is unaffected when `fun` is
invoked.

I attach a patch that implements this change.  The patch is a
hack-job intended solely for illustrative purposes, though it does
pass `make check-all` on a current version of r-devel.  I also ran the
`rlang` tests as those probably push the envelope in this area.  There
only one failed with 2,613 passing.  The failed one is for a
deprecated function that was specifically checking for the repeated
`evalq` contexts[7].

I also attach a document with additional examples and commentary for
those interested.

Best,

Brodie.

PS: for a loosely related issue see #15531[8].

[1]: https://github.com/wch/r-source/blob/tags/R-4-0-0/src/main/eval.c#L3329
[2]: https://github.com/wch/r-source/blob/tags/R-4-0-0/src/main/context.c#L260
[3]: https://github.com/wch/r-source/blob/tags/R-4-0-0/src/main/context.c#L433
[4]: https://github.com/wch/r-source/blob/tags/R-4-0-0/src/main/eval.c#L1815
[5]: https://cran.r-project.org/doc/manuals/r-devel/R-ints.html#Contexts
[6]: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=15531
[7]: 
https://github.com/r-lib/rlang/blob/v0.4.6/tests/testthat/test-retired.R#L437
[8]: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=15531


Index: src/library/base/R/eval.R
===
--- src/library/base/R/eval.R   (revision 78619)
+++ src/library/base/R/eval.R   (working copy)
@@ -23,7 +23,7 @@
 function(expr, envir = parent.frame(),
 enclos = if(is.list(envir) || is.pairlist(envir))
parent.frame() else baseenv())
-.Internal(eval(expr, envir, enclos))
+.Internal(eval(expr, envir, enclos, parent.frame(2L)))
 
 eval.parent <- function(expr, n = 1) {
 p <- parent.frame(n + 1)
@@ -33,7 +33,7 @@
 evalq <-
 function (expr, envir = parent.frame(), enclos = if (is.list(envir) ||
 is.pairlist(envir)) parent.frame() else baseenv())
-  .Internal(eval(substitute(expr), envir, enclos))
+ .Internal(eval(substitute(expr), envir, enclos, parent.frame(2L)))
 
 new.env <- function (hash = TRUE, parent = parent.frame(), size = 29L)
 .Internal(new.env(hash, parent, size))
Index: src/library/base/baseloader.R
===
--- src/library/base/baseloader.R   (revision 78619)
+++ src/library/base/baseloader.R   (working copy)
@@ -97,7 +97,7 @@
 
 ..lazyLoad(basedb, baseenv())
 
-}), .Internal(new.env(FALSE, baseenv(), 29L)), baseenv()))
+}), .Internal(new.env(FALSE, baseenv(), 29L)), baseenv(), baseenv()))
 
 ## keep in sync with R/zzz.R
 as.numeric <- as.double
Index: src/main/eval.c
===
--- src/main/eval.c (revision 78619)
+++ src/main/eval.c (working copy)
@@ -3267,7 +3267,7 @@
 
 SEXP attribute_hidden 

Re: [Rd] r-project.org SSL certificate issues

[Gábor Csárdi]

Btw. it would be also possible to create a macOS R installer that
embeds a static or dynamic libcurl with Secure Transport, instead of
the Apple default LibreSSL.

This might be too late for R 4.0.1, I don't know.

Gabor

On Sun, May 31, 2020 at 4:09 PM Gábor Csárdi  wrote:
>
> On Sat, May 30, 2020 at 11:32 PM Gábor Csárdi  wrote:
> [...]
> > Btw. why does this affect openssl? That root cert was published in
> > 2010, surely openssl should know about it? Maybe libcurl / openssl
> > only uses the chain provided by the server? Without trying to use an
> > alternate chain?
>
> Yes, indeed it seems that old OpenSSL versions cannot handle
> alternative certificate chains. This has been fixed in OpenSSL in
> 2015, so modern Linux systems should be fine. However, macOS uses
> LibreSSL, and LibreSSL never fixed this issue. E.g.
> https://github.com/libressl-portable/portable/issues/595
>
> r-project.org can be updated to send the new root certificate, which
> will solve most of our problems, but we'll probably have issues with
> other web sites that'll update slower or never.
>
> FWIW I built macOS binaries for the curl package, using a static
> libcurl and macOS Secure Transport, so these binaries does not have
> this issue.
>
> They are at https://files.r-hub.io/curl-macos-static and they can be
> installed with
> install.packages("curl", repos =
> "https://files.r-hub.io/curl-macos-static;, type = "binary")
>
> They support R 3.2 and up, including R 4.1, and should work on all
> macOS versions that the given R release supports.
>
> Gabor

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

Re: [Rd] r-project.org SSL certificate issues

[Gábor Csárdi]

On Sat, May 30, 2020 at 11:32 PM Gábor Csárdi  wrote:
[...]
> Btw. why does this affect openssl? That root cert was published in
> 2010, surely openssl should know about it? Maybe libcurl / openssl
> only uses the chain provided by the server? Without trying to use an
> alternate chain?

Yes, indeed it seems that old OpenSSL versions cannot handle
alternative certificate chains. This has been fixed in OpenSSL in
2015, so modern Linux systems should be fine. However, macOS uses
LibreSSL, and LibreSSL never fixed this issue. E.g.
https://github.com/libressl-portable/portable/issues/595

r-project.org can be updated to send the new root certificate, which
will solve most of our problems, but we'll probably have issues with
other web sites that'll update slower or never.

FWIW I built macOS binaries for the curl package, using a static
libcurl and macOS Secure Transport, so these binaries does not have
this issue.

They are at https://files.r-hub.io/curl-macos-static and they can be
installed with
install.packages("curl", repos =
"https://files.r-hub.io/curl-macos-static;, type = "binary")

They support R 3.2 and up, including R 4.1, and should work on all
macOS versions that the given R release supports.

Gabor

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

Re: [Rd] order function called on a data.frame?

[Jan Gorecki]

So maybe for now just warning/error?
Should be much smaller change then those proposed by William and Michael.

Rui,
Your example of order list does raise error, but if you remove second
argument, it won't raise error anymore.

On Mon, May 18, 2020 at 5:27 PM William Dunlap via R-devel
 wrote:
>
> do.call(order, df).  ->  do.call(order, unname(df)).
>
> While you are looking at order(), it would be nice if ';decreasing' could
> be a vector the the length of list(...) so you could ask to sort some
> columns in increasing order and some decreasing.  I thought I put this on
> bugzilla eons ago, but perhaps not.
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
>
> On Mon, May 18, 2020 at 8:52 AM Michael Lawrence via R-devel <
> r-devel@r-project.org> wrote:
>
> > I guess we could make it do the equivalent of do.call(order, df).
> >
> > On Mon, May 18, 2020 at 8:32 AM Rui Barradas  wrote:
> > >
> > > Hello,
> > >
> > > There is a result with lists? I am getting
> > >
> > >
> > > order(list(letters, 1:26))
> > > #Error in order(list(letters, 1:26)) :
> > > #  unimplemented type 'list' in 'orderVector1'
> > >
> > > order(data.frame(letters, 1:26))
> > > # [1] 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
> > > #[22] 48 49 50 51 52  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16
> > > #[43] 17 18 19 20 21 22 23 24 25 26
> > >
> > >
> > > And I agree that order with data.frames should give a warning. The
> > > result is indeed useless:
> > >
> > > data.frame(letters, 1:26)[order(data.frame(letters, 1:26)), ]
> > >
> > >
> > > Hope this helps,
> > >
> > > Rui Barradas
> > >
> > >
> > > Às 00:19 de 18/05/20, Jan Gorecki escreveu:
> > > > Hi,
> > > > base::order main input arguments are defined as:
> > > >
> > > > a sequence of numeric, complex, character or logical vectors, all of
> > > > the same length, or a classed R object
> > > >
> > > > When passing a list or a data.frame, the resuts seems to be a bit
> > > > useless. Shouldn't that raise an error, or at least warning?
> > > >
> > > > Best Regards,
> > > > Jan Gorecki
> > > >
> > > > __
> > > > 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
> >
> >
> >
> > --
> > Michael Lawrence
> > Senior Scientist, Data Science and Statistical Computing
> > Genentech, A Member of the Roche Group
> > Office +1 (650) 225-7760
> > micha...@gene.com
> >
> > Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> [[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: [Bioc-devel] [External] Re: Package Submission Limbo

[Haibe-Kains, Benjamin]

Thanks Martin, your prompt reply is mostly appreciated. Any chance that RadioGx 
and ToxicoGx will be reviewed before July? This would be really beneficial for 
our Bioconductor workshop.

Thanks to all maintainers and reviewers for their great job, these are 
difficult times and it is great to see the community doubling down on the work 
to get Bioconductor better every day.

Regards

---
Benjamin Haibe-Kains, PhD
Senior Scientist
Princess Margaret Cancer Centre
University Health Network
Associate Professor
University of Toronto
Department of Medical Biophysics

http://www.pmgenomics.ca/bhklab/

This e-mail may contain confidential and/or privileged information for the sole 
use of the intended recipient. Any review or distribution by anyone other than 
the person for whom it was originally intended is strictly prohibited. If you 
have received this e-mail in error, please contact the sender and delete all 
copies. Opinions, conclusions or other information contained in this e-mail may 
not be that of the organization.

On May 30, 2020, 17:04 -0400, Martin Morgan , wrote:
Sorry that your packages have not been reviewed more promptly.

We try to have an initial review in two weeks, how long a full review takes 
depends on many factors, including complexity of the review process. Your own 
packages were I believe handled relatively efficiently initially. The release 
at the end of April) is a major activity for us, and necessarily slows the 
overall process down.

We are exploring processes to reduce the reviewer burden so that packages like 
yours are added to Bioconductor more promptly; a major concern is to do so in a 
manner that does not compromise the overall quality of accepted packages.

Martin

On 5/30/20, 4:52 PM, "Bioc-devel on behalf of Chris Eeles" 
 
wrote:

Hello Bioconductor team and community,

My name is Christopher Eeles and I am a software developer in the Benjamin 
Haibe-Kains laboratory at Princess Margaret Cancer Research Centre in Toronto, 
Ontario, Canada.

I am concerned due to inaction on the part of my reviewer for two of my package 
submissions, and am not sure how to move forward.

Initially, I submitted three packages - CoreGx, ToxicoGx and RadioGx - on April 
4th, 2020 hoping to get included in the May Bioconductor release. It became 
apparent that approval would not be possible in time, as such I requested to 
expedite acceptance of CoreGx (on which the latter two packages depend) so it 
could be included. My reviewer obliged and I am thankful for that.

I was told to resubmit ToxicoGx and RadioGx on separate issues and that the 
review process would continue from where it was for the resubmissions. This 
occurred on April 25th, 2020. Before resubmission I had replied to a round of 
reviewer comments and was waiting for a reply before making more changes.

However, since resubmission I have received no further reviewer comments and no 
reply to my code updates since the last review. RadioGx will be a part of a 
workshop our lab is putting together for Bioconductor conference in July, but 
without acceptance of the package it will have to be installed from GitHub.

Additionally, ToxicoGx is the package that was used to curate data for our web 
application, ToxicoDB, which has been accepted to the NAR web server edition. 
We had assumed that the package would be accepted by now and have had criticism 
from our NAR reviewers about it's lack of availability. Both of these packages 
were available on CRAN before our submission to Bioconductor.

My question is, how do I move forward? Without response from my reviewer I do 
not know which conditions I need to meet for package acceptance? I am available 
to respond to criticism.

Initial submission of these packages occurred almost 2 months ago, and it has 
been over a month since the resubmissions. Is this normal? Are there 
extenuating circumstances of which I am unaware?

Our lab put a lot of time and effort into these packages and wish to share them 
with the Bioconductor community. Does anyone have advice on what I can do to 
get the ball rolling again?

Thanks for your assistance.

Best,
---
Christopher Eeles
Software Developer
BHK Laboratory
Princess Margaret Cancer Centre
University Health Network




[[alternative HTML version deleted]]

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

This e-mail may contain confidential and/or privileged information for the sole 
use of the intended recipient.
Any review or distribution by anyone other than the person for whom it was 
originally intended is strictly prohibited.
If you have received this e-mail in error, please contact the sender and delete 
all copies.
Opinions, conclusions or other information