Re: [Rd] Graphics Device API change

[frederik]

Thank you Paul for taking care of these patches. I'm very glad to see
them finally applied in r-devel.

Frederick

On Mon, Feb 27, 2017 at 01:31:39PM +1300, Paul Murrell wrote:
> Hi
> 
> r72261 in r-devel has modified the graphics device API and bumped
> R_GE_version in GraphicsEngine.h (to satisfy PR 16951).
> 
> This means that ...
> 
> (i) third-party graphics device packages need to be reinstalled.
> 
> (ii) third-party graphics device packages will ideally need a new version
> for r-devel.
> 
> (iii) any packages that make use of getGraphicsEvent() should test against
> r-devel (and let me know of any problems).
> 
> Thanks
> 
> Paul
> -- 
> Dr Paul Murrell
> Department of Statistics
> The University of Auckland
> Private Bag 92019
> Auckland
> New Zealand
> 64 9 3737599 x85392
> p...@stat.auckland.ac.nz
> http://www.stat.auckland.ac.nz/~paul/
> 
> __
> 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] covr

[Stephanie M. Gogarten]

Hi Estefania,

After you commit to your github repository, you will need to explicitly 
push those changes to svn to get them into Bioconductor devel. I 
recommend following the instructions under "Dealing with prior history / 
merge conflicts" on this page:


http://www.bioconductor.org/developers/how-to/git-mirrors/

Using the "git cherry-pick" command seems to avoid a lot of errors 
others have seen in trying to move commits from git to svn. (At least, 
it worked for me.)


If you have not already done so, make sure to run the 
"update_remotes.sh" script referenced on that page.


Stephanie

On 2/23/17 9:11 AM, Estefania Mancini wrote:

Thanks Herve!

I will try to include test code in the next version of the package.

By the way, I am a little lost with changes in the package. I want to modify 
the code of the accepted package and  I want to add people to my project in 
GitHub so I think is better for us continuing using it repository. What do you 
suggest? I have a version in GitHub, linked to Bioconductor repository. Does 
commit impact on my devel version of the package? I dont understand clearly 
where I should commit.

Thanks in advance,

Estefania


De: Hervé Pagès [hpa...@fredhutch.org]
Enviado: lunes, 13 de febrero de 2017 03:15 p.m.
Para: Estefania Mancini; bioc-devel@r-project.org
Asunto: Re: [Bioc-devel] covr

Hi Estefania,

See here

   https://bioconductor.org/developers/how-to/unitTesting-guidelines/

for our guidelines to how to add unit tests to your package.

Cheers,
H.

On 02/13/2017 04:17 AM, Estefania Mancini wrote:

Hi,
I would like to add coverage test to my package. What should I do? Thanks in 
advance

Estefania

  [[alternative HTML version deleted]]

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



--
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

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



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

Re: [Rd] rep/rep.int: in NEWS, but not yet ported from trunk

[Suharto Anggono Suharto Anggono via R-devel]

For R 3.3.3, if 3.3.3 is really the last in 3.3.x series, I suggest reverting 
to R 3.3.2 code (and removing the corresponding NEWS entry), if possible. 
Failure of something like
rep(5, list(6))
makes some previously working R code broken in some situation. It is not good 
to have in an R release that will last long, I think.

On Mon, 27/2/17, Martin Maechler  wrote:

 Subject: Re: [Rd] rep/rep.int: in NEWS, but not yet ported from trunk

 Cc: R-devel@r-project.org
 Date: Monday, 27 February, 2017, 4:20 PM
 
> Suharto Anggono Suharto Anggono via R-devel 
> on Sun, 26 Feb 2017 12:02:44 + writes:

> According to "CHANGES IN R 3.3.2 patched" in NEWS, rep(x,
> times) and rep.int(x, times) also work when 'times' has
> length greater than one and has element larger than the
> maximal integer. In fact, it is still not the case in R
> 3.3.3 beta r72259. In seq.c
> (https://svn.r-project.org/R/branches/R-3-3-branch/src/main/seq.c),
> 'times' that is a vector with storage mode "double" and
> length greater than one is still changed first to storage
> mode "integer". Number in 'times' that represents an
> integer that is larger than the maximal integer becomes NA
> and error is issued for such 'times'.  
> I have put a comment,
> https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16932#c30
> .

[[elided Yahoo spam]]

- I've changed the NEWS entry for R-patched (and moved the more
general statement to a new entry for R-devel). 
- The changes were quite substantial so I did not port them to
R-patched at the time..  We could have ported them later, but
not now, immediately before code freeze (of R 3.3.3).

- I would say   rep(5, list(6))  was never "meant to" work and had worked
  incidentally only.
  OTOH, you are correct with your comments 11 & 29 in the about
  bug report, and your proposal to make the simple case   rep(s, list(7))
  work as previously seems ok to me.

However, for all this, we will concentrate on R-devel (to become
R 3.4.0).

Best regards,
Martin Maechler

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

Re: [Rd] Test suite failures in R-devel_2017-02-25_r72256

[Martin Maechler]

> Peter Simons 
> on Mon, 27 Feb 2017 10:30:39 +0100 writes:

> Hi, I tried compiling the latest pre-release for R 3.3.3
> for the NixOS Linux distribution [1], but the build fails
> during the "make check" phase because of the following 2
> issues:

> 1) The "tools" test in "tests/Examples" requires network
> access, which it doesn't have in our build
> environment. 

One may argue that the 'make check' (or even 'make check-all')
tests could / should be allowed more resources than the pure
build environment.

> Therefore, it fails as follows according to
> "tools-Ex.Rout.fail":

> | [...]
> | > set.seed(11)
> | > ## End(Don't show)
> | > pdb <- CRAN_package_db()
> | Warning in url(sprintf("%s/%s", cran, path), open = "rb") :
> |   URL 'http://CRAN.R-project.org/web/packages/packages.rds': status was 
'Couldn't resolve host name'
> | Error in url(sprintf("%s/%s", cran, path), open = "rb") :
> |   cannot open the connection to 
'http://CRAN.R-project.org/web/packages/packages.rds'
> | Calls: CRAN_package_db -> as.data.frame -> read_CRAN_object -> gzcon -> 
url
> | Execution halted

> I'm wondering whether it would be possible to extend the test suite
> with a configure-time flag that disable tests which depend on network
> access? My experience is that most modern Linux distributions run
> their builds in a restricted environment and therefore will run into
> trouble if the suite assumes that it can access the Internet.

[see above] Is it necessary to also run the 'make check' part in
that restricted environment?  Or could that ('checking") not get
more priviledges?

Note that you can only run  "make check" if you don't install
recommended packages, whereas more thorough testing would
include
make check-devel
or even
make check-all

but these do have quite a bit more requirements including
recommended packages being present.


> 2) When R is compiled with the --without-recommended-packages flag
> (which is our preferred configuration), the "base" test in
> "tests/Examples" fails, apparently because it depends on MASS. I'm
> citing from "base-Ex.Rout.fail":

> | >  ## The string "foo" and the symbol 'foo' can be used interchangably 
here:
> | >  stopifnot( identical(isNamespaceLoaded(  "foo"   ), FALSE),
> | + identical(isNamespaceLoaded(quote(foo)), FALSE),
> | + identical(isNamespaceLoaded(quote(stats)), statL))
> | >
> | > hasM <- isNamespaceLoaded("MASS") # (to restore if needed)
> | > Mns <- asNamespace("MASS") # loads it if not already
> | Error in loadNamespace(name) : there is no package called 'MASS'
> | Calls: asNamespace ... tryCatch -> tryCatchList -> tryCatchOne -> 

> | Execution halted

Yes, that example should not have assumed a recommended package
to be available unconditionally.

I've changed it, thank you!


> I hope this helps!

> Best regards,
> Peter



> [1] http://nixos.org/

> __
> 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] Single Package Builder

[Shepherd, Lori]

The Single Package Builder is now online.  Thank you for your patience.


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 Shepherd, Lori 

Sent: Monday, February 27, 2017 9:14:45 AM
To: Martin Morgan
Subject: [Bioc-devel] Single Package Builder

The Single Package Builder is currently offline.  We are working on restoring 
and will update when it is back online.


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


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


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] Single Package Builder

[Shepherd, Lori]

The Single Package Builder is currently offline.  We are working on restoring 
and will update when it is back online.


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


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

Re: [Bioc-devel] Bioc releases and Bioconda

[Kasper Daniel Hansen]

On Mon, Feb 27, 2017 at 3:54 AM, Elena Grassi  wrote:

>
> Bioconda developers are reasoning on a way to annotate bioc version, this
> should fix the issue without any work needed on single packages versions.
>

You need this; your current approach will not work.  You cannot assume that
package authors make this dependency information explicit, although they
sometimes do.

Best,
Kasper

[[alternative HTML version deleted]]

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

[Rd] Test suite failures in R-devel_2017-02-25_r72256

[Peter Simons]

Hi,

I tried compiling the latest pre-release for R 3.3.3 for the NixOS Linux
distribution [1], but the build fails during the "make check" phase
because of the following 2 issues:

1) The "tools" test in "tests/Examples" requires network access, which
   it doesn't have in our build environment. Therefore, it fails as
   follows according to "tools-Ex.Rout.fail":

   | [...]
   | > set.seed(11)
   | > ## End(Don't show)
   | > pdb <- CRAN_package_db()
   | Warning in url(sprintf("%s/%s", cran, path), open = "rb") :
   |   URL 'http://CRAN.R-project.org/web/packages/packages.rds': status was 
'Couldn't resolve host name'
   | Error in url(sprintf("%s/%s", cran, path), open = "rb") :
   |   cannot open the connection to 
'http://CRAN.R-project.org/web/packages/packages.rds'
   | Calls: CRAN_package_db -> as.data.frame -> read_CRAN_object -> gzcon -> url
   | Execution halted

   I'm wondering whether it would be possible to extend the test suite
   with a configure-time flag that disable tests which depend on network
   access? My experience is that most modern Linux distributions run
   their builds in a restricted environment and therefore will run into
   trouble if the suite assumes that it can access the Internet.

2) When R is compiled with the --without-recommended-packages flag
   (which is our preferred configuration), the "base" test in
   "tests/Examples" fails, apparently because it depends on MASS. I'm
   citing from "base-Ex.Rout.fail":

   | >  ## The string "foo" and the symbol 'foo' can be used interchangably 
here:
   | >  stopifnot( identical(isNamespaceLoaded(  "foo"   ), FALSE),
   | + identical(isNamespaceLoaded(quote(foo)), FALSE),
   | + identical(isNamespaceLoaded(quote(stats)), statL))
   | >
   | > hasM <- isNamespaceLoaded("MASS") # (to restore if needed)
   | > Mns <- asNamespace("MASS") # loads it if not already
   | Error in loadNamespace(name) : there is no package called 'MASS'
   | Calls: asNamespace ... tryCatch -> tryCatchList -> tryCatchOne -> 

   | Execution halted

I hope this helps!

Best regards,
Peter



[1] http://nixos.org/

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

Re: [Rd] stats::median

[Martin Maechler]

> Rob J Hyndman 
> on Wed, 15 Feb 2017 21:48:56 +1100 writes:

> The generic stats::median method is defined as median <-
> function (x, na.rm = FALSE) {UseMethod("median")}

> I suggest that this should become median <- function (x,
> na.rm = FALSE, ...)  {UseMethod("median")}

> This would allow additional S3 methods to be developed
> with additional arguments.

and  S4  methods, too.

> Currently I have to over-ride this generic definition in
> the demography package because median.demogdata has
> several other arguments.

> This shouldn't break any code, and will make it easier for
> new S3 methods to be developed. It is also consistent with
> almost all other S3 methods which do include an ellipsis.

"shouldn't break any code"   is almost always quite optimistic
   nowadays,

Actually it probably will break things when people start using
the new R version which implements the above *AND* use packages
installed with a previous version of R.
I agree that this does not count as "breaking any code".

In spite of all that  *and*
the perennial drawback that a '...' will allow argument name
typos to go unnoticed

I agree you have a good argument nowadays, that median() should
be the same as many similar "basic statistics" R functions and
so I'll commit such a change to R-devel (to become R 3.4.0 in April).

Thank you for the suggestion!
Martin Maechler,
ETH Zurich

> -
> Rob J Hyndman Professor of Statistics, Monash University
> www.robjhyndman.com

> __
> 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] rep/rep.int: in NEWS, but not yet ported from trunk

[Martin Maechler]

> Suharto Anggono Suharto Anggono via R-devel 
> on Sun, 26 Feb 2017 12:02:44 + writes:

> According to "CHANGES IN R 3.3.2 patched" in NEWS, rep(x,
> times) and rep.int(x, times) also work when 'times' has
> length greater than one and has element larger than the
> maximal integer. In fact, it is still not the case in R
> 3.3.3 beta r72259. In seq.c
> (https://svn.r-project.org/R/branches/R-3-3-branch/src/main/seq.c),
> 'times' that is a vector with storage mode "double" and
> length greater than one is still changed first to storage
> mode "integer". Number in 'times' that represents an
> integer that is larger than the maximal integer becomes NA
> and error is issued for such 'times'.  
> I have put a comment,
> https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16932#c30
> .

Thank you for noticing!

- I've changed the NEWS entry for R-patched (and moved the more
general statement to a new entry for R-devel). 
- The changes were quite substantial so I did not port them to
R-patched at the time..  We could have ported them later, but
not now, immediately before code freeze (of R 3.3.3).

- I would say   rep(5, list(6))  was never "meant to" work and had worked
  incidentally only.
  OTOH, you are correct with your comments 11 & 29 in the about
  bug report, and your proposal to make the simple case   rep(s, list(7))
  work as previously seems ok to me.

However, for all this, we will concentrate on R-devel (to become
R 3.4.0).

Best regards,
Martin Maechler

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

Re: [Bioc-devel] Bioc releases and Bioconda

[Elena Grassi]

On Fri, Feb 24, 2017 at 9:09 PM, Nitesh  wrote:

> Could you tell me more about which package you are trying to wrap a recipe
> for?
>

Right now my packages: the recipes are working, but the helper skeleton
script that create dependencies gets them from DESCRIPTION and if lower
limits for version are not there it cannot infer them.


> And could you give me an example for what you mean by " determining
> dependencies limits when one of the packages that you depend on changes
> its public interface." ?
>

Package A depends on package B. Versions 1.0.0 of both packages work well
together. In version 1.2.0 package B changes something that A uses, so A
adapts to this change in 1.2.0, if this is not reflected in the DESCRIPTION
with
a pin on B version >=1.2.0 the corresponding bioconda packages could not
fit well together (imagine someone with B version 1.0.0 and A version
1.2.0).
Bioconda developers are reasoning on a way to annotate bioc version, this
should fix the issue without any work needed on single packages versions.

E.

[[alternative HTML version deleted]]

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