Re: [Bioc-devel] Handling larger data in vignette

[Levi Waldron]

There are also weekly "long test" builds with a 6h timeout:

https://stat.ethz.ch/pipermail/bioc-devel/2017-November/012326.html

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Is biocLite() working for you right now? Could be a problem on our side. Issue with DelayedArray install with a PC on R 3.5.0

[Tim Triche, Jr.]

are you sure his tmp directory isn't full

--t


On Mon, Jul 30, 2018 at 3:25 PM Leonardo Collado Torres 
wrote:

> From Richard:
>
> > BiocManager::install("DelayedArray")
>
> Bioconductor version 3.7 (BiocManager 1.30.1), R 3.5.0 (2018-04-23)
>
> Installing package(s) 'BiocVersion', 'DelayedArray'
>
> trying URL '
> https://bioconductor.org/packages/3.7/bioc/bin/windows/contrib/3.5/BiocVersion_3.7.4.zip
> '
>
> Content type 'application/zip' length 8649 bytes
>
> downloaded 8649 bytes
>
>
>
> package ‘BiocVersion’ successfully unpacked and MD5 sums checked
>
>
>
> The downloaded binary packages are in
>
>C:\Users\Richard
> Straub\AppData\Local\Temp\RtmpQNrgbq\downloaded_packages
>
> installing the source package ‘DelayedArray’
>
>
>
> trying URL '
> https://bioconductor.org/packages/3.7/bioc/src/contrib/DelayedArray_0.6.2.tar.gz
> '
>
> Content type 'application/x-gzip' length 486139 bytes (474 KB)
>
> downloaded 474 KB
>
>
>
> Error in untar2(tarfile, files, list, exdir, restore_times) :
>
>   incomplete block on file
>
> In R CMD INSTALL
>
>
>
> The downloaded source packages are in
>
>‘C:\Users\Richard
> Straub\AppData\Local\Temp\RtmpQNrgbq\downloaded_packages’
>
> installation path not writeable, unable to update packages: foreign,
> MASS, mgcv, survival
>
> Update old packages: 'openssl', 'stringi'
>
> Update all/some/none? [a/s/n]:
>
> n
>
> Warning message:
>
> In install.packages(pkgs = doing, lib = lib, repos = repos, ...) :
>
>   installation of package ‘DelayedArray’ had non-zero exit status
>
> >
>
>
>
> Also, at
> http://bioconductor.org/packages/release/bioc/html/DelayedArray.html
> I don't see the tar for the Windows binary.
>
>
>
>
> On Mon, Jul 30, 2018 at 2:57 PM Tim Triche, Jr. 
> wrote:
> >
> > BiocManager::install(whatever) doesn't work?
> >
> > biocLite is supposed to die, you see...
> >
> >
> > --t
> >
> >
> > On Mon, Jul 30, 2018 at 2:45 PM Leonardo Collado Torres <
> lcoll...@jhu.edu> wrote:
> >>
> >> Hi bioc-devel,
> >>
> >> A co-worker of mine (Richard) tried several times to install the
> >> DelayedArray package. We got a couple of errors but it ultimately
> >> looks like it's an internet connection problem. The truth is that
> >> might be something affecting us on our side since I can't access
> >> http://www.comunidadbioinfo.org/ either but collaborators in Mexico
> >> (cc'ed) can right now. Me (on a Mac) and Emily (on a PC) on the same
> >> network can't access that website.
> >>
> >> One of the errors we saw with Richard (on a PC) was about a missing
> >> tar block. We failed to save that error message (for what's it's
> >> worth, that was using RStudio). We then tried again and ran into this
> >> error:
> >>
> >> > ## try http:// if https:// URLs are not supported
> >>
> >> > source("https://bioconductor.org/biocLite.R;)
> >>
> >> Error in file(filename, "r", encoding = encoding) :
> >>
> >>   cannot open the connection
> >>
> >> In addition: Warning message:
> >>
> >> In file(filename, "r", encoding = encoding) :
> >>
> >>   InternetOpenUrl failed: 'A connection with the server could not be
> >> established'
> >>
> >> > source("http://bioconductor.org/biocLite.R;)
> >>
> >> Error in file(filename, "r", encoding = encoding) :
> >>
> >>   cannot open the connection
> >>
> >> In addition: Warning message:
> >>
> >> In file(filename, "r", encoding = encoding) :
> >>
> >>   InternetOpenUrl failed: 'A connection with the server could not be
> >> established'
> >>
> >> > sessionInfo()
> >>
> >> R version 3.5.0 (2018-04-23)
> >>
> >> Platform: x86_64-w64-mingw32/x64 (64-bit)
> >>
> >> Running under: Windows 10 x64 (build 17134)
> >>
> >>
> >>
> >> Matrix products: default
> >>
> >>
> >>
> >> locale:
> >>
> >> [1] LC_COLLATE=English_United States.1252  LC_CTYPE=English_United
> >> States.1252LC_MONETARY=English_United States.1252
> >>
> >> [4] LC_NUMERIC=C   LC_TIME=English_United
> States.1252
> >>
> >>
> >>
> >> attached base packages:
> >>
> >> [1] stats graphics  grDevices utils datasets  methods   base
> >>
> >>
> >>
> >> loaded via a namespace (and not attached):
> >>
> >> [1] compiler_3.5.0
> >>
> >>
> >>
> >>
> >> On my Mac however, I can install DelayedArray.
> >>
> >> > source('http://bioconductor.org/biocLite.R')
> >> Bioconductor version 3.7 (BiocInstaller 1.30.0), ?biocLite for help
> >> > biocLite('DelayedArray')
> >> BioC_mirror: https://bioconductor.org
> >> Using Bioconductor 3.7 (BiocInstaller 1.30.0), R 3.5.1 (2018-07-02).
> >> Installing package(s) ‘DelayedArray’
> >> trying URL '
> https://bioconductor.org/packages/3.7/bioc/bin/macosx/el-capitan/contrib/3.5/DelayedArray_0.6.2.tgz
> '
> >> Content type 'application/x-gzip' length 1308365 bytes (1.2 MB)
> >> ==
> >> downloaded 1.2 MB
> >> > sessionInfo()
> >> R version 3.5.1 (2018-07-02)
> >> Platform: x86_64-apple-darwin15.6.0 (64-bit)
> >> Running under: macOS High Sierra 10.13.6
> >>
> >> Matrix products: 

Re: [Bioc-devel] Is biocLite() working for you right now? Could be a problem on our side. Issue with DelayedArray install with a PC on R 3.5.0

[Tim Triche, Jr.]

BiocManager::install(whatever) doesn't work?

biocLite is supposed to die, you see...


--t


On Mon, Jul 30, 2018 at 2:45 PM Leonardo Collado Torres 
wrote:

> Hi bioc-devel,
>
> A co-worker of mine (Richard) tried several times to install the
> DelayedArray package. We got a couple of errors but it ultimately
> looks like it's an internet connection problem. The truth is that
> might be something affecting us on our side since I can't access
> http://www.comunidadbioinfo.org/ either but collaborators in Mexico
> (cc'ed) can right now. Me (on a Mac) and Emily (on a PC) on the same
> network can't access that website.
>
> One of the errors we saw with Richard (on a PC) was about a missing
> tar block. We failed to save that error message (for what's it's
> worth, that was using RStudio). We then tried again and ran into this
> error:
>
> > ## try http:// if https:// URLs are not supported
>
> > source("https://bioconductor.org/biocLite.R;)
>
> Error in file(filename, "r", encoding = encoding) :
>
>   cannot open the connection
>
> In addition: Warning message:
>
> In file(filename, "r", encoding = encoding) :
>
>   InternetOpenUrl failed: 'A connection with the server could not be
> established'
>
> > source("http://bioconductor.org/biocLite.R;)
>
> Error in file(filename, "r", encoding = encoding) :
>
>   cannot open the connection
>
> In addition: Warning message:
>
> In file(filename, "r", encoding = encoding) :
>
>   InternetOpenUrl failed: 'A connection with the server could not be
> established'
>
> > sessionInfo()
>
> R version 3.5.0 (2018-04-23)
>
> Platform: x86_64-w64-mingw32/x64 (64-bit)
>
> Running under: Windows 10 x64 (build 17134)
>
>
>
> Matrix products: default
>
>
>
> locale:
>
> [1] LC_COLLATE=English_United States.1252  LC_CTYPE=English_United
> States.1252LC_MONETARY=English_United States.1252
>
> [4] LC_NUMERIC=C   LC_TIME=English_United
> States.1252
>
>
>
> attached base packages:
>
> [1] stats graphics  grDevices utils datasets  methods   base
>
>
>
> loaded via a namespace (and not attached):
>
> [1] compiler_3.5.0
>
>
>
>
> On my Mac however, I can install DelayedArray.
>
> > source('http://bioconductor.org/biocLite.R')
> Bioconductor version 3.7 (BiocInstaller 1.30.0), ?biocLite for help
> > biocLite('DelayedArray')
> BioC_mirror: https://bioconductor.org
> Using Bioconductor 3.7 (BiocInstaller 1.30.0), R 3.5.1 (2018-07-02).
> Installing package(s) ‘DelayedArray’
> trying URL '
> https://bioconductor.org/packages/3.7/bioc/bin/macosx/el-capitan/contrib/3.5/DelayedArray_0.6.2.tgz
> '
> Content type 'application/x-gzip' length 1308365 bytes (1.2 MB)
> ==
> downloaded 1.2 MB
> > sessionInfo()
> R version 3.5.1 (2018-07-02)
> Platform: x86_64-apple-darwin15.6.0 (64-bit)
> Running under: macOS High Sierra 10.13.6
>
> Matrix products: default
> BLAS:
> /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.0.dylib
> LAPACK:
> /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib
>
> locale:
> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> other attached packages:
> [1] BiocInstaller_1.30.0
>
> loaded via a namespace (and not attached):
> [1] compiler_3.5.1 tools_3.5.1
>
>
> So, I have no idea how to approach this and just wanted to double
> check that things are ok from your side.
>
>
> Thanks,
> Leo
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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

[Rd] Code Optimization: print.data.frame + as.data.frame(head(x, n = options("max.print")))

[Juan Telleria Ruiz de Aguirre]

Dear R Developers,

I would like to propose a simple optimization for print.data.frame
base function:

To add: x <- as.data.frame(head(x, n = options("max.print")))

This would prevent that, if for example, we have a 10GB data.frame
(e.g.: Instead of a data.table), and we accidentally print it, the R
Session does not "collapse", forcing us to press ESC or kill the
RSession.

function (x, ..., digits = NULL, quote = FALSE, right = TRUE,
  row.names = TRUE)
{
  n <- length(row.names(x))
  if (length(x) == 0L) {
cat(sprintf(ngettext(n, "data frame with 0 columns and %d row",
 "data frame with 0 columns and %d rows"), n), "\n",
sep = "")
  }
  else if (n == 0L) {
print.default(names(x), quote = FALSE)
cat(gettext("<0 rows> (or 0-length row.names)\n"))
  }
  else {

x <- as.data.frame(head(x, n = options("max.print")))

m <- as.matrix(format.data.frame(x, digits = digits,
 na.encode = FALSE))
if (!isTRUE(row.names))
  dimnames(m)[[1L]] <- if (isFALSE(row.names))
rep.int("", n)
else row.names
print(m, ..., quote = quote, right = right)
  }
  invisible(x)
}

Thank you.

Best,
Juan

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

[Bioc-devel] Is biocLite() working for you right now? Could be a problem on our side. Issue with DelayedArray install with a PC on R 3.5.0

[Leonardo Collado Torres]

Hi bioc-devel,

A co-worker of mine (Richard) tried several times to install the
DelayedArray package. We got a couple of errors but it ultimately
looks like it's an internet connection problem. The truth is that
might be something affecting us on our side since I can't access
http://www.comunidadbioinfo.org/ either but collaborators in Mexico
(cc'ed) can right now. Me (on a Mac) and Emily (on a PC) on the same
network can't access that website.

One of the errors we saw with Richard (on a PC) was about a missing
tar block. We failed to save that error message (for what's it's
worth, that was using RStudio). We then tried again and ran into this
error:

> ## try http:// if https:// URLs are not supported

> source("https://bioconductor.org/biocLite.R;)

Error in file(filename, "r", encoding = encoding) :

  cannot open the connection

In addition: Warning message:

In file(filename, "r", encoding = encoding) :

  InternetOpenUrl failed: 'A connection with the server could not be
established'

> source("http://bioconductor.org/biocLite.R;)

Error in file(filename, "r", encoding = encoding) :

  cannot open the connection

In addition: Warning message:

In file(filename, "r", encoding = encoding) :

  InternetOpenUrl failed: 'A connection with the server could not be
established'

> sessionInfo()

R version 3.5.0 (2018-04-23)

Platform: x86_64-w64-mingw32/x64 (64-bit)

Running under: Windows 10 x64 (build 17134)



Matrix products: default



locale:

[1] LC_COLLATE=English_United States.1252  LC_CTYPE=English_United
States.1252LC_MONETARY=English_United States.1252

[4] LC_NUMERIC=C   LC_TIME=English_United States.1252



attached base packages:

[1] stats graphics  grDevices utils datasets  methods   base



loaded via a namespace (and not attached):

[1] compiler_3.5.0




On my Mac however, I can install DelayedArray.

> source('http://bioconductor.org/biocLite.R')
Bioconductor version 3.7 (BiocInstaller 1.30.0), ?biocLite for help
> biocLite('DelayedArray')
BioC_mirror: https://bioconductor.org
Using Bioconductor 3.7 (BiocInstaller 1.30.0), R 3.5.1 (2018-07-02).
Installing package(s) ‘DelayedArray’
trying URL 
'https://bioconductor.org/packages/3.7/bioc/bin/macosx/el-capitan/contrib/3.5/DelayedArray_0.6.2.tgz'
Content type 'application/x-gzip' length 1308365 bytes (1.2 MB)
==
downloaded 1.2 MB
> sessionInfo()
R version 3.5.1 (2018-07-02)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS High Sierra 10.13.6

Matrix products: default
BLAS: 
/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.0.dylib
LAPACK: 
/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

other attached packages:
[1] BiocInstaller_1.30.0

loaded via a namespace (and not attached):
[1] compiler_3.5.1 tools_3.5.1


So, I have no idea how to approach this and just wanted to double
check that things are ok from your side.


Thanks,
Leo

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

[Rd] trace in uniroot() ?

[J C Nash]

In looking at rootfinding for the histoRicalg project (see 
gitlab.com/nashjc/histoRicalg),
I thought I would check how uniroot() solves some problems. The following short 
example

ff <- function(x){ exp(0.5*x) - 2 }
ff(2)
ff(1)
uniroot(ff, 0, 10)
uniroot(ff, c(0, 10), trace=1)
uniroot(ff, c(0, 10), trace=TRUE)


shows that the trace parameter, as described in the Rd file, does not seem to
be functional except in limited situations (and it suggests an
integer, then uses a logical for the example, e.g.,
 ## numerically, f(-|M|) becomes zero :
 u3 <- uniroot(exp, c(0,2), extendInt="yes", trace=TRUE)
)

When extendInt is set, then there is some information output, but trace alone
produces nothing.

I looked at the source code -- it is in R-3.5.1/src/library/stats/R/nlm.R and
calls zeroin2 code from R-3.5.1/src/library/stats/src/optimize.c as far as I
can determing. My code inspection suggests trace does not show the iterations
of the rootfinding, and only has effect when the search interval is allowed
to be extended. It does not appear that there is any mechanism to ask
the zeroin2 C code to display intermediate work.

This isn't desperately important for me as I wrote an R version of the code in
package rootoned on R-forge (which Martin Maechler adapted as unirootR.R in
Rmpfr so multi-precision roots can be found). My zeroin.R has 'trace' to get
the pattern of different steps. In fact it is a bit excessive. Note
unirootR.R uses 'verbose' rather than 'trace'. However, it would be nice to be
able to see what is going on with uniroot() to verify equivalent operation at
the same precision level. It is very easy for codes to be very slightly
different and give quite widely different output.

Indeed, even without the trace, we see (zeroin from rootoned here)

> zeroin(ff, c(0, 10), trace=FALSE)
$root
[1] 1.386294

$froot
[1] -5.658169e-10

$rtol
[1] 7.450581e-09

$maxit
[1] 9

> uniroot(ff, c(0, 10), trace=FALSE)
$root
[1] 1.38629

$f.root
[1] -4.66072e-06

$iter
[1] 10

$init.it
[1] NA

$estim.prec
[1] 6.103516e-05

>

Is the lack of trace a bug, or at least an oversight? Being able to follow 
iterations is a
classic approach to checking that computations are proceeding as they should.

Best, JN

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

[Rd] Problem with parseData

[Barbara Lerner]

Hi,

I have run into a problem with parseData from the utils package.  When 
an assignment is done with = instead of <-, the information provided by 
parseData does not include an entry for the assignment.

For this input, stored in file "BadPosition.R":

y <- 5
foo = 7

And running this code:

parsed <- parse("BadPosition.R", keep.source=TRUE)
parsedData <- utils::getParseData (parsed, includeText=TRUE)
print(paste("parseData =", parsedData))

I get the following output:

[1] "parseData = c(1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2)"
[2] "parseData = c(1, 1, 1, 3, 6, 6, 1, 1, 5, 7, 7)"
[3] "parseData = c(1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2)"
[4] "parseData = c(6, 1, 1, 4, 6, 6, 3, 3, 5, 7, 7)"
[5] "parseData = c(7, 1, 3, 2, 4, 5, 10, 12, 11, 13, 14)"
[6] "parseData = c(0, 3, 7, 7, 5, 7, 12, 0, 0, 14, 0)"
[7] "parseData = c(\"expr\", \"SYMBOL\", \"expr\", \"LEFT_ASSIGN\", 
\"NUM_CONST\", \"expr\", \"SYMBOL\", \"expr\", \"EQ_ASSIGN\", 
\"NUM_CONST\", \"expr\")"
[8] "parseData = c(FALSE, TRUE, FALSE, TRUE, TRUE, FALSE, TRUE, FALSE, 
TRUE, TRUE, FALSE)"
[9] "parseData = c(\"y <- 5\", \"y\", \"y\", \"<-\", \"5\", \"5\", 
\"foo\", \"foo\", \"=\", \"7\", \"7\")"

Notice how there is an entry for "y <- 5" beginning on line 1, column 1, 
ending at line 1, column 6, but there is no analogous entry for "foo = 7".

I am running R 3.5.0 on a Mac running 10.12.6.

Thanks for your help and please let me know if you need any further 
information.

Barbara

-- 
Barbara Lerner
Associate Professor
Computer Science Department
Mount Holyoke College



[[alternative HTML version deleted]]

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

Re: [Rd] Fwd: help building very old R

[Dirk Eddelbuettel]

On 30 July 2018 at 16:26, David Hugh-Jones wrote:
| Thanks for the tip. That could be a huge timesaver. But it lists only a
| single package for versions 0.90.1-2 ... how does that work?

The lookip is source or binary-package based. Eg here are three binaries
built from source 'r-base':

  http://snapshot.debian.org/binary/r-base-core/
  http://snapshot.debian.org/binary/r-base-dev/
  http://snapshot.debian.org/binary/r-mathlib/

etc pp

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [Rd] Fwd: help building very old R

[David Hugh-Jones]

Thanks for the tip. That could be a huge timesaver. But it lists only a
single package for versions 0.90.1-2 ... how does that work?
David


On Mon, 30 Jul 2018 at 12:27, Dirk Eddelbuettel  wrote:

>
> On 30 July 2018 at 05:35, David Hugh-Jones wrote:
> | Hi guys,
> |
> | Perhaps someone here can help.
> |
> | I am trying to build versions of R 1 for the rcheology package (just
> | arrived on CRAN).
> |
> | For R prior to 1.5.0, I cannot configure support for tcl-tk.
> |
> | I am building on Debian Woody (provided by Docker debian/eol) and have
> the
> | following packages installed:
> | r-base-dev tclx8.3-dev tk8.3-dev xvfb xbase-clients x-window-system-core
> |
> | I download R source from http://cran.r-project.org/src/base/R-1 and run
> |
> | ./configure --with-tcl-tk=yes
> | --with-tcl-config=/usr/lib/tcl8.3/tclConfig.sh
> |   --with-tk-config=/usr/lib/tk8.3/tkConfig.sh
> |
> | These are the locations for the relevant tkConfig.sh and tclConfig.sh
> files.
> | This gives output as follows:
> |
> | R is now configured for x86_64-unknown-linux-gnu
> |
> |   Source directory:  .
> |   Installation directory:/usr/local
> |
> |   C compiler:gcc  -g -O2
> |   C++ compiler:  c++  -g -O2
> |   FORTRAN compiler:  g77  -g -O2
> |   X11 support:   yes
> |   Gnome support: no
> |   Tcl/Tk support:no
> |   R profiling support:   yes
> |   R as a shared library: no
> |
> | And config.log reveals:
> | configure:13099: checking for /usr/lib/tcl8.3/tclConfig.sh
> | configure:13134: checking for /usr/lib/tk8.3/tkConfig.sh
> | configure:13204: checking for /usr/include/tcl8.3/tcl.h
> | configure:13214: gcc -E -I/usr/local/include conftest.c >/dev/null
> | 2>conftest.out
> | configure:13313: checking for /usr/include/tk8.3/tk.h
> | configure:13323: gcc -E -I/usr/local/include -I/usr/X11R6/include
> | -I/usr/include
> | /tcl8.3 conftest.c >/dev/null 2>conftest.out
> | configure:13319: /usr/include/tk8.3/tk.h: No such file or directory
> | configure: failed program was:
> | #line 13318 "configure"
> | #include "confdefs.h"
> | #include 
> | configure:13348: checking for /usr/include/tk.h
> | configure:13358: gcc -E -I/usr/local/include -I/usr/X11R6/include
> | -I/usr/include
> | /tcl8.3 conftest.c >/dev/null 2>conftest.out
> | configure:13354: /usr/include/tk.h: No such file or directory
> | configure: failed program was:
> | #line 13353 "configure"
> | #include "confdefs.h"
> | #include 
> | configure:13385: checking for tk.h
> | configure:13389: tk.h: No such file or directory
> |
> | In fact, tk.h is in  /usr/include/tcl8.3/ , despite the failed program
> | compilation report.
> |
> | R 1.5.0 and above work fine. Can anyone remember far back, if something
> | changed in the configure script?
> |
> | Alternatively, those who are feeling brave can download the Docker image
> | creation scripts from github.com/hughjonesd/rcheology .
>
> Have you considered the actual Debian packages from "way back then" ?
> Debian has this nifty snapshot archive where you can get old binaries:
>
>   http://snapshot.debian.org/
>
> For (source package) r-base we see 3.5.1 all the way down to 0.61.2
>
>   http://snapshot.debian.org/package/r-base/
>
> Alternatively, the package itself is now (finally, my bad) in a git repo
> which goes back to 0.61.2 as well (using snapshot as the feeder)
>
>   https://salsa.debian.org/edd/r-base/commits/master
>
> Hth,  Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>

[[alternative HTML version deleted]]

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

Re: [Rd] apply with zero-row matrix

[David Hugh-Jones]

Interesting discussion. I'm not wholly convinced by Martin's and Emil's
arguments. The behaviour seems to violate an obvious expectation (fun is
called once per row) to satisfy a subtle one (result has a guaranteed
dimension and type).

In any case, here's a suggested chunk of rd to go at the end of the "Value":

If \code{dim(X)[MARGIN]} is zero, then \code{FUN} is called once, with an
argument of the appropriate dimensions. The argument's type is the same as
\code{typeof(m)}, and the argument values are those returned by
\code{vector(typeof(m))}. For example, if m is numeric, the argument will
be a vector (or matrix or array) of zeroes. The type and length of the
value returned by \code{FUN} is used to determine the type of the result.

And at the end of "Details":

\code{FUN} is always called at least once, see below.


David


On Mon, 30 Jul 2018 at 15:05, Gabor Grothendieck 
wrote:

> Try pmap and related functions in purrr:
>
>   pmap(as.data.frame(m), ~ { cat("Called...\n"); print(c(...)) })
>   ## list()
>
> On Mon, Jul 30, 2018 at 12:33 AM, David Hugh-Jones
>  wrote:
> > Forgive me if this has been asked many times before, but I couldn't find
> > anything on the mailing lists.
> >
> > I'd expect apply(m, 1, foo) not to call `foo` if m is a matrix with zero
> > rows.
> > In fact:
> >
> > m <- matrix(NA, 0, 5)
> > apply(m, 1, function (x) {cat("Called...\n"); print(x)})
> > ## Called...
> > ## [1] FALSE FALSE FALSE FALSE FALSE
> >
> > Similarly for apply(m, 2,...) if m has no columns.
> > Is there a reason for this? Could it be documented?
> >
> > David
> > --
> > Sent from Gmail Mobile
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
> --
> Statistics & Software Consulting
> GKX Group, GKX Associates Inc.
> tel: 1-877-GKX-GROUP
> email: ggrothendieck at gmail.com
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] EXTERNAL: Re: Synching version numbers went wrong

[Turaga, Nitesh]

Typo, I mean

1.7.1 


> On Jul 30, 2018, at 10:38 AM, ni41435_ca  
> wrote:
> 
> Hi Shana,
> 
> It seems that this occurred because of a merge gone bad and then followed by 
> a series of version changes which are wrong.
> 
> I’ll just fix your version number to (1.7.2) for now and it’s your 
> responsibility to sync again with your Github.
> 
> Best,
> 
> Nitesh 
> 
> 
> 
>> On Jul 30, 2018, at 5:51 AM, Mike Smith  wrote:
>> 
>> Hi Shana,
>> 
>> Sorry for the delay in replying - I've been on vacation.  I tested this
>> with one of my own packages and found the same problem.  I'm not sure how
>> you managed to commit the lower version number in the first place (I'm not
>> going to test that since I'll get stuck too!) but I guess the logic for
>> allowing commits has a loophole somewhere.  I'll raise a query in the Slack
>> channel and hopefully someone with power over the git repository will get
>> back to you soon.
>> 
>> Mike
>> 
>> On Mon, 23 Jul 2018 at 21:20, White, Shana (vandersm) 
>> wrote:
>> 
>>> Hi Mike,
>>> 
>>> 
>>> My colleague and I have spent a few hours attempting to fix this problem;
>>> we can only propogate changes with version numbers 1.5x and cannot do 1.6x
>>> or 1.7x on the devel branch - it seems like the  Bioconductor automatic
>>> checks are preventing us from updating the files and at this point we
>>> believe the version number can only be fixed from within Bioconductor.
>>> Does the Bioconductor team need to manually change the version number or
>>> should we try to force push the changes ourselves? Please let me know if
>>> you need any additional details.
>>> 
>>> 
>>> Best,
>>> 
>>> 
>>> 
>>> Shana White
>>> Ph. D Candidate  - Biostatistics + Bioinformatics
>>> 
>>> Predoctoral Fellow - MECEH
>>> 
>>> Room 318 Kettering Labs
>>> vande...@mail.uc.edu
>>> 937-657-8289
>>> 
>>> 
>>> --
>>> *From:* Mike Smith 
>>> *Sent:* Thursday, July 12, 2018 4:57:55 AM
>>> *To:* White, Shana (vandersm)
>>> *Cc:* bioc-devel
>>> *Subject:* Re: [Bioc-devel] Synching version numbers went wrong
>>> 
>>> Hi Shana,
>>> 
>>> It looks like the release version of KEGGlincs is 1.6.x and the devel
>>> version should be 1.7.x.When you're committing to the master branch of
>>> git.bioconductor.org this equates to the devel version and there's a
>>> check in place to prevent even version numbers being committed here.  My
>>> recommendation is to make sure that your DESCRIPTION file for that commit
>>> has a version number of 1.7.x which should put things back on track.
>>> 
>>> If you also need to add your changes to the release version (I guess the
>>> current build error means you do) then you can see the instructions at
>>> https://bioconductor.org/developers/how-to/git/bug-fix-in-release-and-devel/
>>> Step 4 details incorporating changes from one branch to another, and then
>>> you need to manually make sure the DESCRIPTION file for committing to the
>>> RELEASE_3_7 branch contains a 1.6.x version number.
>>> 
>>> Mike
>>> 
>>> On Wed, 11 Jul 2018 at 18:19, White, Shana (vandersm) <
>>> vande...@mail.uc.edu> wrote:
>>> 
>>> Hello, when attempting to fix a bug [introduced into my package] and
>>> propagate the changes I somehow managed to roll back the middle version
>>> number on one of my branches and ended up with the following error message
>>> when attempting to correct my mistake:
>>> 
>>> 
>>> 
>>> Error message:
>>> 
>>> 
>>> shanas-macbook:KEGGlincs shanabanana$ git push upstream master
>>> 
>>> Counting objects: 3, done.
>>> 
>>> Delta compression using up to 4 threads.
>>> 
>>> Compressing objects: 100% (3/3), done.
>>> 
>>> Writing objects: 100% (3/3), 298 bytes | 0 bytes/s, done.
>>> 
>>> Total 3 (delta 2), reused 0 (delta 0)
>>> 
>>> remote: Error: Illegal version bump from '1.5.1' to '1.6.1'. Check
>>> 
>>> remote: http://bioconductor.org/developers/how-to/version-numbering/
>>> 
>>> remote: for details
>>> 
>>> 
>>> Many thanks,
>>> 
>>> 
>>> Shana White
>>> Ph. D Candidate  - Biostatistics + Bioinformatics<
>>> https://med.uc.edu/eh/divisions/bio>
>>> Predoctoral Fellow - MECEH<
>>> https://med.uc.edu/eh/divisions/epi/programs/meceh>
>>> Room 318 Kettering Labs
>>> vande...@mail.uc.edu
>>> 937-657-8289
>>> 
>>> 
>>>   [[alternative HTML version deleted]]
>>> 
>>> ___
>>> Bioc-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>> 
>>> 
>> 
>>  [[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 

Re: [Bioc-devel] EXTERNAL: Re: Synching version numbers went wrong

[Turaga, Nitesh]

Hi Shana,

It seems that this occurred because of a merge gone bad and then followed by a 
series of version changes which are wrong.

I’ll just fix your version number to (1.7.2) for now and it’s your 
responsibility to sync again with your Github.

Best,

Nitesh 



> On Jul 30, 2018, at 5:51 AM, Mike Smith  wrote:
> 
> Hi Shana,
> 
> Sorry for the delay in replying - I've been on vacation.  I tested this
> with one of my own packages and found the same problem.  I'm not sure how
> you managed to commit the lower version number in the first place (I'm not
> going to test that since I'll get stuck too!) but I guess the logic for
> allowing commits has a loophole somewhere.  I'll raise a query in the Slack
> channel and hopefully someone with power over the git repository will get
> back to you soon.
> 
> Mike
> 
> On Mon, 23 Jul 2018 at 21:20, White, Shana (vandersm) 
> wrote:
> 
>> Hi Mike,
>> 
>> 
>> My colleague and I have spent a few hours attempting to fix this problem;
>> we can only propogate changes with version numbers 1.5x and cannot do 1.6x
>> or 1.7x on the devel branch - it seems like the  Bioconductor automatic
>> checks are preventing us from updating the files and at this point we
>> believe the version number can only be fixed from within Bioconductor.
>> Does the Bioconductor team need to manually change the version number or
>> should we try to force push the changes ourselves? Please let me know if
>> you need any additional details.
>> 
>> 
>> Best,
>> 
>> 
>> 
>> Shana White
>> Ph. D Candidate  - Biostatistics + Bioinformatics
>> 
>> Predoctoral Fellow - MECEH
>> 
>> Room 318 Kettering Labs
>> vande...@mail.uc.edu
>> 937-657-8289
>> 
>> 
>> --
>> *From:* Mike Smith 
>> *Sent:* Thursday, July 12, 2018 4:57:55 AM
>> *To:* White, Shana (vandersm)
>> *Cc:* bioc-devel
>> *Subject:* Re: [Bioc-devel] Synching version numbers went wrong
>> 
>> Hi Shana,
>> 
>> It looks like the release version of KEGGlincs is 1.6.x and the devel
>> version should be 1.7.x.When you're committing to the master branch of
>> git.bioconductor.org this equates to the devel version and there's a
>> check in place to prevent even version numbers being committed here.  My
>> recommendation is to make sure that your DESCRIPTION file for that commit
>> has a version number of 1.7.x which should put things back on track.
>> 
>> If you also need to add your changes to the release version (I guess the
>> current build error means you do) then you can see the instructions at
>> https://bioconductor.org/developers/how-to/git/bug-fix-in-release-and-devel/
>> Step 4 details incorporating changes from one branch to another, and then
>> you need to manually make sure the DESCRIPTION file for committing to the
>> RELEASE_3_7 branch contains a 1.6.x version number.
>> 
>> Mike
>> 
>> On Wed, 11 Jul 2018 at 18:19, White, Shana (vandersm) <
>> vande...@mail.uc.edu> wrote:
>> 
>> Hello, when attempting to fix a bug [introduced into my package] and
>> propagate the changes I somehow managed to roll back the middle version
>> number on one of my branches and ended up with the following error message
>> when attempting to correct my mistake:
>> 
>> 
>> 
>> Error message:
>> 
>> 
>> shanas-macbook:KEGGlincs shanabanana$ git push upstream master
>> 
>> Counting objects: 3, done.
>> 
>> Delta compression using up to 4 threads.
>> 
>> Compressing objects: 100% (3/3), done.
>> 
>> Writing objects: 100% (3/3), 298 bytes | 0 bytes/s, done.
>> 
>> Total 3 (delta 2), reused 0 (delta 0)
>> 
>> remote: Error: Illegal version bump from '1.5.1' to '1.6.1'. Check
>> 
>> remote: http://bioconductor.org/developers/how-to/version-numbering/
>> 
>> remote: for details
>> 
>> 
>> Many thanks,
>> 
>> 
>> Shana White
>> Ph. D Candidate  - Biostatistics + Bioinformatics<
>> https://med.uc.edu/eh/divisions/bio>
>> Predoctoral Fellow - MECEH<
>> https://med.uc.edu/eh/divisions/epi/programs/meceh>
>> Room 318 Kettering Labs
>> vande...@mail.uc.edu
>> 937-657-8289
>> 
>> 
>>[[alternative HTML version deleted]]
>> 
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> 
>> 
> 
>   [[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. 

Re: [Rd] apply with zero-row matrix

[Gabor Grothendieck]

Try pmap and related functions in purrr:

  pmap(as.data.frame(m), ~ { cat("Called...\n"); print(c(...)) })
  ## list()

On Mon, Jul 30, 2018 at 12:33 AM, David Hugh-Jones
 wrote:
> Forgive me if this has been asked many times before, but I couldn't find
> anything on the mailing lists.
>
> I'd expect apply(m, 1, foo) not to call `foo` if m is a matrix with zero
> rows.
> In fact:
>
> m <- matrix(NA, 0, 5)
> apply(m, 1, function (x) {cat("Called...\n"); print(x)})
> ## Called...
> ## [1] FALSE FALSE FALSE FALSE FALSE
>
> Similarly for apply(m, 2,...) if m has no columns.
> Is there a reason for this? Could it be documented?
>
> David
> --
> Sent from Gmail Mobile
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com

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

Re: [Rd] apply with zero-row matrix

[Emil Bode]

Hi David,

Besides Martins point, there is also the issue that for a lot of cases you 
would still like to have the right class returned.
Right now these are returns:

> apply(matrix(NA_integer_,0,5), 1, class)
character(0)
> apply(matrix(NA_integer_,0,5), 1, identity)
integer(0)
> apply(matrix(NA,0,5), 1, identity)
logical(0)

In your case, these would all return NULL, so I think there is value in 
running FUN at least once (Say if you'd want to check if FUN always returns the 
right class). 
And from a philosophical point of view, R is mostly a functional 
programming language, I think if you want side-effects a for-loop would look 
better.


Best regards, 
Emil Bode
 
Data-analyst
 
+31 6 43 83 89 33
emil.b...@dans.knaw.nl
 
DANS: Netherlands Institute for Permanent Access to Digital Research 
Resources
Anna van Saksenlaan 51 | 2593 HW Den Haag | +31 70 349 44 50 | 
i...@dans.knaw.nl  | dans.knaw.nl 

DANS is an institute of the Dutch Academy KNAW  and 
funding organisation NWO . 

On 30/07/2018, 11:12, "R-devel on behalf of David Hugh-Jones" 
 wrote:

Hi Martin,

Fair enough for R functions in general. But the behaviour of apply 
violates
the expectation that apply(m, 1, fun) calls fun n times when m has n 
rows.
That seems pretty basic.

Also, I understand from your argument why it makes sense to call apply 
and
return a special result (presumably NULL) for an empty argument; but why
should apply call fun?

Cheers
David

On Mon, 30 Jul 2018 at 08:41, Martin Maechler 

wrote:

> > David Hugh-Jones
> > on Mon, 30 Jul 2018 05:33:19 +0100 writes:
>
> > Forgive me if this has been asked many times before, but I
> > couldn't find anything on the mailing lists.
>
> > I'd expect apply(m, 1, foo) not to call `foo` if m is a
> > matrix with zero rows.  In fact:
>
> > m <- matrix(NA, 0, 5)
> > apply(m, 1, function (x) {cat("Called...\n"); print(x)})
> > ## Called...
> > ## [1] FALSE FALSE FALSE FALSE FALSE
>
>
> > Similarly for apply(m, 2,...) if m has no columns.  Is
> > there a reason for this?
>
> Yes :
>
> The reverse is really true for almost all basic R functions:
>
> They *are* called and give an "empty" result automatically
> when the main argument is empty.
>
> What you basicaly propose is to add an extra
>
>  if()
>  return()
>
> to all R functions.  While that makes sense for high-level R
> functions that do a lot of things, this would really be a bad
> idea in general :
>
> This would make all of these basic functions larger {more to 
maintain} and
> slightly slower for all non-zero cases just to make them
> slightly faster for the rare zero-length case.
>
> Martin Maechler
> ETH Zurich and R core Team
>
> --
Sent from Gmail Mobile

[[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] apply with zero-row matrix

[Martin Maechler]

> David Hugh-Jones 
> on Mon, 30 Jul 2018 10:12:24 +0100 writes:

> Hi Martin, Fair enough for R functions in general. But the
> behaviour of apply violates the expectation that apply(m,
> 1, fun) calls fun n times when m has n rows.  That seems
> pretty basic.

Well, that expectation is obviously wrong ;-)  see below

> Also, I understand from your argument why it makes sense
> to call apply and return a special result (presumably
> NULL) for an empty argument; but why should apply call fun?

> Cheers David

The reason is seen e.g. in

> apply(matrix(,0,3), 2, quantile)
 [,1] [,2] [,3]
0% NA   NA   NA
25%NA   NA   NA
50%NA   NA   NA
75%NA   NA   NA
100%   NA   NA   NA
> 

and that is documented (+/-) in the first paragraph of the
'Value:' section of help(apply) :

 > Value:
 > 
 >  If each call to ‘FUN’ returns a vector of length ‘n’, then ‘apply’
 >  returns an array of dimension ‘c(n, dim(X)[MARGIN])’ if ‘n > 1’.
 >  If ‘n’ equals ‘1’, ‘apply’ returns a vector if ‘MARGIN’ has length
 >  1 and an array of dimension ‘dim(X)[MARGIN]’ otherwise.  If ‘n’ is
 >  ‘0’, the result has length 0 but not necessarily the ‘correct’
 >  dimension.


To determine 'n', the function *is* called once even when
length(X) ==  0

It may indeed be would helpful to add this explicitly to the
help page  ( /src/library/base/man/apply.Rd ).
Can you propose a wording (in *.Rd if possible) ?

With regards,
Martin

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

Re: [Rd] Fwd: help building very old R

[Dirk Eddelbuettel]

On 30 July 2018 at 05:35, David Hugh-Jones wrote:
| Hi guys,
| 
| Perhaps someone here can help.
| 
| I am trying to build versions of R 1 for the rcheology package (just
| arrived on CRAN).
| 
| For R prior to 1.5.0, I cannot configure support for tcl-tk.
| 
| I am building on Debian Woody (provided by Docker debian/eol) and have the
| following packages installed:
| r-base-dev tclx8.3-dev tk8.3-dev xvfb xbase-clients x-window-system-core
| 
| I download R source from http://cran.r-project.org/src/base/R-1 and run
| 
| ./configure --with-tcl-tk=yes
| --with-tcl-config=/usr/lib/tcl8.3/tclConfig.sh
|   --with-tk-config=/usr/lib/tk8.3/tkConfig.sh
| 
| These are the locations for the relevant tkConfig.sh and tclConfig.sh files.
| This gives output as follows:
| 
| R is now configured for x86_64-unknown-linux-gnu
| 
|   Source directory:  .
|   Installation directory:/usr/local
| 
|   C compiler:gcc  -g -O2
|   C++ compiler:  c++  -g -O2
|   FORTRAN compiler:  g77  -g -O2
|   X11 support:   yes
|   Gnome support: no
|   Tcl/Tk support:no
|   R profiling support:   yes
|   R as a shared library: no
| 
| And config.log reveals:
| configure:13099: checking for /usr/lib/tcl8.3/tclConfig.sh
| configure:13134: checking for /usr/lib/tk8.3/tkConfig.sh
| configure:13204: checking for /usr/include/tcl8.3/tcl.h
| configure:13214: gcc -E -I/usr/local/include conftest.c >/dev/null
| 2>conftest.out
| configure:13313: checking for /usr/include/tk8.3/tk.h
| configure:13323: gcc -E -I/usr/local/include -I/usr/X11R6/include
| -I/usr/include
| /tcl8.3 conftest.c >/dev/null 2>conftest.out
| configure:13319: /usr/include/tk8.3/tk.h: No such file or directory
| configure: failed program was:
| #line 13318 "configure"
| #include "confdefs.h"
| #include 
| configure:13348: checking for /usr/include/tk.h
| configure:13358: gcc -E -I/usr/local/include -I/usr/X11R6/include
| -I/usr/include
| /tcl8.3 conftest.c >/dev/null 2>conftest.out
| configure:13354: /usr/include/tk.h: No such file or directory
| configure: failed program was:
| #line 13353 "configure"
| #include "confdefs.h"
| #include 
| configure:13385: checking for tk.h
| configure:13389: tk.h: No such file or directory
| 
| In fact, tk.h is in  /usr/include/tcl8.3/ , despite the failed program
| compilation report.
| 
| R 1.5.0 and above work fine. Can anyone remember far back, if something
| changed in the configure script?
| 
| Alternatively, those who are feeling brave can download the Docker image
| creation scripts from github.com/hughjonesd/rcheology .

Have you considered the actual Debian packages from "way back then" ?
Debian has this nifty snapshot archive where you can get old binaries:

  http://snapshot.debian.org/

For (source package) r-base we see 3.5.1 all the way down to 0.61.2

  http://snapshot.debian.org/package/r-base/

Alternatively, the package itself is now (finally, my bad) in a git repo
which goes back to 0.61.2 as well (using snapshot as the feeder)

  https://salsa.debian.org/edd/r-base/commits/master

Hth,  Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [Bioc-devel] Synching version numbers went wrong

[Mike Smith]

Hi Shana,

Sorry for the delay in replying - I've been on vacation.  I tested this
with one of my own packages and found the same problem.  I'm not sure how
you managed to commit the lower version number in the first place (I'm not
going to test that since I'll get stuck too!) but I guess the logic for
allowing commits has a loophole somewhere.  I'll raise a query in the Slack
channel and hopefully someone with power over the git repository will get
back to you soon.

Mike

On Mon, 23 Jul 2018 at 21:20, White, Shana (vandersm) 
wrote:

> Hi Mike,
>
>
> My colleague and I have spent a few hours attempting to fix this problem;
> we can only propogate changes with version numbers 1.5x and cannot do 1.6x
> or 1.7x on the devel branch - it seems like the  Bioconductor automatic
> checks are preventing us from updating the files and at this point we
> believe the version number can only be fixed from within Bioconductor.
> Does the Bioconductor team need to manually change the version number or
> should we try to force push the changes ourselves? Please let me know if
> you need any additional details.
>
>
> Best,
>
>
>
> Shana White
> Ph. D Candidate  - Biostatistics + Bioinformatics
> 
> Predoctoral Fellow - MECEH
> 
> Room 318 Kettering Labs
> vande...@mail.uc.edu
> 937-657-8289
>
>
> --
> *From:* Mike Smith 
> *Sent:* Thursday, July 12, 2018 4:57:55 AM
> *To:* White, Shana (vandersm)
> *Cc:* bioc-devel
> *Subject:* Re: [Bioc-devel] Synching version numbers went wrong
>
> Hi Shana,
>
> It looks like the release version of KEGGlincs is 1.6.x and the devel
> version should be 1.7.x.When you're committing to the master branch of
> git.bioconductor.org this equates to the devel version and there's a
> check in place to prevent even version numbers being committed here.  My
> recommendation is to make sure that your DESCRIPTION file for that commit
> has a version number of 1.7.x which should put things back on track.
>
> If you also need to add your changes to the release version (I guess the
> current build error means you do) then you can see the instructions at
> https://bioconductor.org/developers/how-to/git/bug-fix-in-release-and-devel/
> Step 4 details incorporating changes from one branch to another, and then
> you need to manually make sure the DESCRIPTION file for committing to the
> RELEASE_3_7 branch contains a 1.6.x version number.
>
> Mike
>
> On Wed, 11 Jul 2018 at 18:19, White, Shana (vandersm) <
> vande...@mail.uc.edu> wrote:
>
> Hello, when attempting to fix a bug [introduced into my package] and
> propagate the changes I somehow managed to roll back the middle version
> number on one of my branches and ended up with the following error message
> when attempting to correct my mistake:
>
>
>
> Error message:
>
>
> shanas-macbook:KEGGlincs shanabanana$ git push upstream master
>
> Counting objects: 3, done.
>
> Delta compression using up to 4 threads.
>
> Compressing objects: 100% (3/3), done.
>
> Writing objects: 100% (3/3), 298 bytes | 0 bytes/s, done.
>
> Total 3 (delta 2), reused 0 (delta 0)
>
> remote: Error: Illegal version bump from '1.5.1' to '1.6.1'. Check
>
> remote: http://bioconductor.org/developers/how-to/version-numbering/
>
> remote: for details
>
>
> Many thanks,
>
>
> Shana White
> Ph. D Candidate  - Biostatistics + Bioinformatics<
> https://med.uc.edu/eh/divisions/bio>
> Predoctoral Fellow - MECEH<
> https://med.uc.edu/eh/divisions/epi/programs/meceh>
> Room 318 Kettering Labs
> vande...@mail.uc.edu
> 937-657-8289
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>

[[alternative HTML version deleted]]

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

Re: [Rd] apply with zero-row matrix

[David Hugh-Jones]

Hi Martin,

Fair enough for R functions in general. But the behaviour of apply violates
the expectation that apply(m, 1, fun) calls fun n times when m has n rows.
That seems pretty basic.

Also, I understand from your argument why it makes sense to call apply and
return a special result (presumably NULL) for an empty argument; but why
should apply call fun?

Cheers
David

On Mon, 30 Jul 2018 at 08:41, Martin Maechler 
wrote:

> > David Hugh-Jones
> > on Mon, 30 Jul 2018 05:33:19 +0100 writes:
>
> > Forgive me if this has been asked many times before, but I
> > couldn't find anything on the mailing lists.
>
> > I'd expect apply(m, 1, foo) not to call `foo` if m is a
> > matrix with zero rows.  In fact:
>
> > m <- matrix(NA, 0, 5)
> > apply(m, 1, function (x) {cat("Called...\n"); print(x)})
> > ## Called...
> > ## [1] FALSE FALSE FALSE FALSE FALSE
>
>
> > Similarly for apply(m, 2,...) if m has no columns.  Is
> > there a reason for this?
>
> Yes :
>
> The reverse is really true for almost all basic R functions:
>
> They *are* called and give an "empty" result automatically
> when the main argument is empty.
>
> What you basicaly propose is to add an extra
>
>  if()
>  return()
>
> to all R functions.  While that makes sense for high-level R
> functions that do a lot of things, this would really be a bad
> idea in general :
>
> This would make all of these basic functions larger {more to maintain} and
> slightly slower for all non-zero cases just to make them
> slightly faster for the rare zero-length case.
>
> Martin Maechler
> ETH Zurich and R core Team
>
> --
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [Rd] apply with zero-row matrix

[Martin Maechler]

> David Hugh-Jones 
> on Mon, 30 Jul 2018 05:33:19 +0100 writes:

> Forgive me if this has been asked many times before, but I
> couldn't find anything on the mailing lists.

> I'd expect apply(m, 1, foo) not to call `foo` if m is a
> matrix with zero rows.  In fact:

> m <- matrix(NA, 0, 5)
> apply(m, 1, function (x) {cat("Called...\n"); print(x)})
> ## Called...
> ## [1] FALSE FALSE FALSE FALSE FALSE


> Similarly for apply(m, 2,...) if m has no columns.  Is
> there a reason for this?

Yes :

The reverse is really true for almost all basic R functions:

They *are* called and give an "empty" result automatically
when the main argument is empty.

What you basicaly propose is to add an extra

 if()
 return()

to all R functions.  While that makes sense for high-level R
functions that do a lot of things, this would really be a bad
idea in general :

This would make all of these basic functions larger {more to maintain} and
slightly slower for all non-zero cases just to make them
slightly faster for the rare zero-length case.

Martin Maechler
ETH Zurich and R core Team

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

Re: [Rd] odd behavior of names

[Martin Maechler]

> William Dunlap via R-devel 
> on Sun, 29 Jul 2018 10:06:40 -0700 writes:

> Bugzilla issue 16101 describes another
> first-list-name-printed-differently oddity with 
> the Windows GUI version of R:
  

Indeed:
1) "first-list-name-printed" [i.e "names" only in that
 context of printing]
2) Windows GUI version of R only
   (not 'Rterm', i.e., not in ESS (emacs speaks
   statistics), nor in Rstudio on Windows

Kevin Ushey has reported this last week in an official (and
perfect) bug report to R's bugzilla bug reporting site:

 https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17447

Bug ID: 17447
   Summary: list() prints first variable name in backticks
   
 Component: Windows GUI / Window specific
  Reporter: kevinushey ..  gmail ..

His minimal REPREX was even much simpler:

   > list(a = 1, b = 2)
$`a`
[1] 1

$b
[1] 2


Thank you, Bill, for the nice extra example.

Martin Maechler
ETH Zurich and R Core Team



> > a <- "One is \u043E\u0434\u0438\u043D\nTwo is \u0434\u0432\u0430\n"
> > Encoding(a) # expect "UTF-8"
> [1] "UTF-8"
> > sapply(strsplit(a, "\n")[[1]], charToRaw)[c(1,1,2)]
> $`One is один`
>  [1] 4f 6e 65 20 69 73 20 d0 be d0 b4 d0
> [13] b8 d0 bd
> 
> $`One is `
>  [1] 4f 6e 65 20 69 73 20 d0 be d0 b4 d0
> [13] b8 d0 bd
> 
> $`Two is `
>  [1] 54 77 6f 20 69 73 20 d0 b4 d0 b2 d0
> [13] b0
> 
> > names(.Last.value)
> [1] "One is один" "One is один"
> [3] "Two is два"
> 
> 
> 
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com

[..]

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

Re: [R-pkg-devel] Get an empty note for "checking DESCRIPTION meta-information" when I run devtools::build_win()

[Eggleston, Barry]

OK,

I submitted the package via the webform with "rth" as a role for Diane.  It 
failed the automatic testing for two notes and was archived within a few 
minutes.  One note indicated the package was a new submission, while the other 
was related to my use of "rth".  I responded to all and referred to this 
discussion on R-package-devel.  The actual notes received were:

Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
Check: CRAN incoming feasibility, Result: NOTE
  Maintainer: 'Barry Eggleston '
  
  New submission

Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
Check: DESCRIPTION meta-information, Result: NOTE


Thanks,
Barry
  

-Original Message-
From: Martin Maechler  
Sent: Thursday, July 26, 2018 11:40 AM
To: Eggleston, Barry 
Cc: Roman Flury ; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Get an empty note for "checking DESCRIPTION 
meta-information" when I run devtools::build_win()

> Eggleston, Barry 
> on Wed, 25 Jul 2018 21:53:30 + writes:

> This is great news Roman.
> The "rth" role stands for "Research team head", and I got it from the 
http://www.loc.gov/marc//relators/relaterm.html website.

and it *IS*  a correct role also in R,  using non-API function
(non-API: do *not* use it in reproducible code, pkgs, etc !) :

  > utils:::.canonicalize_person_role("rth")
  [1] "rth"

tells us that this is a correct role,
whereas these are not :

> utils:::.canonicalize_person_role("Rth")
character(0)
Warning message:
In utils:::.canonicalize_person_role("Rth") :
  Invalid role specification: ‘Rth’.
> utils:::.canonicalize_person_role("Foobar")
character(0)
Warning message:
In utils:::.canonicalize_person_role("Foobar") :
  Invalid role specification: ‘Foobar’.
> 

So the bug is really in the Windows version of R that was
running for you when you've used devtools::build_win()   or in
build_win()  itself.

"rth" is a correct role and you should *NOT* replace it by something less 
appropriate ...

Martin Maechler
ETH Zurich and R Core Team


> This issue here is Diane Catellier provided the funds and management for 
us to develop this package.  I did not know about the person() function.  When 
I looked at the help page for person(), I see that I can use "fnd" for funder 
and that will define Diane's role sufficiently well.  I'll make the change and 
run through my checks again.

> Thank you,
> Barry

> -Original Message-
> From: Roman Flury  
> Sent: Wednesday, July 25, 2018 5:27 PM
> To: Eggleston, Barry 
> Cc: Hugh Parsonage ; 
r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] Get an empty note for "checking DESCRIPTION 
meta-information" when I run devtools::build_win()

> Barry,

> sorry did not anticipate the behaving of the emailer. I could reproduce 
your error with the DESCRIPTION file below with a helloworld pkg

> Package: test
> Type: Package
> Title: What the Package Does (Title Case)
> Version: 0.1.0
> Authors@R: c(person("Roman", "Flury", email = "roman.fl...@math.uzh.ch", 
role = c("aut", "cre")),
>  person("Test", "person", email = "testm...@test.org", role = 
c("fnd", "rth")))
> Description: Short description to describe this package.
> Depends: R (>= 3.5.0)
> License: GPL-3
> Encoding: UTF-8
> LazyData: true
> Imports: eha (>= 2.5.1),
>     ggplot2 (>= 2.2.1),
>     survival (>= 2.41-3),
>     reshape2 (>= 1.4.3),
>     stats (>= 3.5.0)
> RoxygenNote: 6.0.1

> this passes R CMD check --as-cran on a unix system, but not on windwos. 
> The problem seems to be the role "rth", which is also not listed in 
?person. What does this role stand for?

> best, Roman

> On 25.07.2018 16:21, Eggleston, Barry wrote:
>> Roman,
>> 
>> Not sure why my emailer added all those  items, but 
none of them are in my original DESCRIPTION file.  So my Maintainer line, for 
example, simply reads Barry Eggleston , where email address is 
simply beggles...@rti.org.
>> 
>> Thanks for the observation,
>> Barry
>> 
>> 
>> -Original Message-
>> From: Roman Flury 
>> Sent: Wednesday, July 25, 2018 9:42 AM
>> To: Eggleston, Barry 
>> Cc: Hugh Parsonage ; 
>> r-package-devel@r-project.org
>> Subject: Re: [R-pkg-devel] Get an empty note for "checking DESCRIPTION 
>> meta-information" when I run devtools::build_win()
>> 
>> Hello,
>> 
>> after https://cran.r-project.org/doc/manuals/r-release/R-exts.html the 
‘Maintainer’ field should give a single name followed by a valid (RFC 2822) 
email address in angle brackets.
>> but beggles...@rti.org is not a valid RFC 
>> 2822 email address, you could check this for instance with 
>> https://proxy2.de/email-validation.php
>> 
>> you could omit the 'Maintainer' field, since a suitable