Re: [Rd] Graphics Device API change

2017-02-27 Thread 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: [Rd] rep/rep.int: in NEWS, but not yet ported from trunk

2017-02-27 Thread 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

2017-02-27 Thread 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


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

2017-02-27 Thread 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

2017-02-27 Thread 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

2017-02-27 Thread 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