Re: [Rd] A bug understanding F relative to FALSE?

[Jan Gorecki]

I agree it is not good to have those symbols used in packages, but I
found to use those quite often in my developement workflow, which is
something like:

$ R -q
> cc(F)

where `cc` is my function to rebuild application to recent state. I
use it really often. Having to type FALSE every time makes this
workflow relatively longer.
IMO it would be best to warn about T/F symbols during package check,
but not necessarily removing them globally.

On Fri, Jan 17, 2020 at 4:01 PM Joris Meys  wrote:
>
> As others have pointed out, this is expected behaviour. Let me get on that
> hill I'll die on: it is absolutely not suitable. It is way beyond time to
> remove T and F as unprotected kind-of-synonyms for TRUE and FALSE, given
> the amount of times I had to point out that:
>
> T <- t(matrix(0:3,nrow=2))
> isTRUE(T)
>
> was the reason the code didn't do what it's supposed to do. (Also don't use
> T as short for "Transpose of my matrix", but that's another hill.)
>
> As we've become more strict on the use of T and F in packages, maybe 4.0.0
> is a good milestone to finally drop this relic from the past? One can
> dream...
>
> Kind regards
> Joris
>
> On Wed, Jan 15, 2020 at 3:14 PM IAGO GINÉ VÁZQUEZ  wrote:
>
> > Hi all,
> >
> > Is the next behaviour suitable?
> >
> > identical(F,FALSE)
> >
> > ## [1] TRUE
> >
> > utils::getParseData(parse(text = "c(F,FALSE)", keep.so=rce = TRUE))
> >
> > ##line1 col1 line2 col2 id parenttoken terminal  text
> > ## 14 11 1   10 14  0 exprFALSE
> > ## 1  11 11  1  3 SYMBOL_FUNCTION_CALL TRUE c
> > ## 3  11 11  3 14 exprFALSE
> > ## 2  12 12  2 14  '(' TRUE (
> > ## 4  13 13  4  6   SYMBOL TRUE F
> > ## 6  13 13  6 14 exprFALSE
> > ## 5  14 14  5 14  ',' TRUE ,
> > ## 9  15 19  9 10NUM_CONST TRUE FALSE
> > ## 10 15 19 10 14 exprFALSE
> > ## 11 1   10 1   10 11 14  ')' TRUE )
> >
> > I would expect that token for F is the same as token for FALSE.
> >
> >
> > Thank you!
> >
> > Iago
> >
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>
> --
> Joris Meys
> Statistical consultant
>
> Department of Data Analysis and Mathematical Modelling
> Ghent University
> Coupure Links 653, B-9000 Gent (Belgium)
> 
> ---
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>
> [[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] DeMixT issue

[py11]

Hi Lori,

I just pushed my new updated package into RELEASE_3_10 with version  
1.2.3(old one was 1.2.1); however, I didn't see the change in release  
version as well as no build report update in the following link,


http://bioconductor.org/checkResults/release/bioc-LATEST/DeMixT/

may I know how should address this issue? In the mean time, I  
successfully pushed version 1.3.3 into devel branch and has built  
successfully.


Thanks,
Peng


Quoting "Shepherd, Lori" :

We noticed the build report has not been updated since Fri Jan 17th.  
  We have corrected the issue and there should be a new report today  
or tomorrow.


Cheers,


Lori Shepherd

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of  
Shepherd, Lori 

Sent: Tuesday, January 21, 2020 9:06 AM
To: py11 ; Martin Morgan 
Cc: bioc-devel@r-project.org 
Subject: Re: [Bioc-devel] DeMixT issue

The current version on devel is 1.3.2 which is what is consistent  
with what is in

g...@git.bioconductor.org:packages/DeMixT.git

If you would like updates you need to update your version to 1.3.3   
in the next round of changes.



As Martin said previously,  the landing page will not update until  
you have a successful build.  You can see from the build report,   
the package is still timing out using version 1.3.2

http://bioconductor.org/checkResults/devel/bioc-LATEST/DeMixT/
Therefore the landing page remains at 1.3.1

Cheers



Lori Shepherd

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of  
py11 

Sent: Monday, January 20, 2020 3:11 PM
To: Martin Morgan 
Cc: bioc-devel@r-project.org 
Subject: Re: [Bioc-devel] DeMixT issue

Hello,

I pushed my updated package into biconductor master branch on Jan
18th; however, I still didn't see the version change in devel branch
as follow:

https://bioconductor.org/packages/devel/bioc/html/DeMixT.html

May I ask where can I find the build report for the latest update?

Thanks,
Peng

Quoting Martin Morgan :


The package is always built from the current git repository,
regardless of version. So your package will build.

A successfully built package (passing install / build / check) is
only 'pushed' to the public repository if the version is different
(higher) than the current published repository. Your original 1.3.2
version has not built successfully, it has not been pushed. If your
new 1.3.2 version builds successfully, it will be pushed.

BUT the best practice is simply to increment the version, so that
there is no confusion -- in the previous paragraph I had to say
'your original 1.3.2 version' and 'your new 1.3.2 version', but it
would have been much clearer to say version 1.3.2 and 1.3.3.

Martin

On 1/18/20, 5:39 PM, "py11"  wrote:

Hi Martin,

Thank you very much for the detailed report. I have noticed in  
the report


https://bioconductor.org/checkResults/devel/bioc-LATEST/DeMixT/

the build failed due to check out of time. I re-arrange the examples
in my Rd file, which guarantee the run time of R CMD check lower than
10 mins. So I pushed the package again into bioconductor with version
1.3.2 again. And my question is, is 1.3.2 the right version that I am
using for and will it be built in the following night?

Note the current devel version in our package page is 1.3.1 as shown
in link below:

https://bioconductor.org/packages/devel/bioc/html/DeMixT.html

Thanks,
Peng



Quoting Martin Morgan :

> I see
>
> DeMixT master$ grep Version DESCRIPTION
> Version: 1.3.2
>
> Which is fine.
>
> Remember that accepted Bioconductor packages are *built nightly*
> rather than on commit. This ensures that the current version of your
> package is working with the current version of all other packages in
> the Bioconductor ecosystem, and that that other Bioconductor
> packages that may depend on your package are working with it.
>
> Look at the build report for your package
>
>   https://bioconductor.org/checkResults/devel/bioc-LATEST/DeMixT/
>
> Note the publication date, which is when the last nightly build
> completed and the build report created
>
>   This page was generated on 2020-01-15 11:54:40 -0500 (Wed,
15 Jan 2020).
>
> Note the Snapshot date, the date and time when a clone of your
> repository was made to start the nightly build
>
>   Snapshot Date: 2020-01-14 16:46:51 -0500 (Tue, 14 Jan 2020)
>
> Finally, note from your repository the date of your last commit
>
>   DeMixT master$ git log -n 1
>   commit e86bea0d14ac39f3d019f8aed3612747acabb55f
>   Author: pengyang0411  

Re: [R-pkg-devel] CRAN rules re. web scraping?

[Spencer Graves]

  Thanks very much to Iñaki Ucar, Adam H Sparks, and Roy 
Mendelssohn for their replies that helped me understand what I needed to 
do to fix problems identified in the CRAN Checks.  I believe that those 
problems are not fixed in the development version of Ecfun available at 
"https://github.com/sbgraves237/Ecfun".  The package still needs more 
work, but I will make Prof. Ripley's Feb. 4 deadline.



  Thanks again,
  Spencer Graves


On 2020-01-23 01:55, Iñaki Ucar wrote:

On Thu, 23 Jan 2020 at 02:49, Spencer Graves
 wrote:

Hello, All:


GOOD NEWS AND BAD NEWS:


* First the good news:  I heard from Brian Ripley;  see below.
His web site says, "He retired in August 2014 on grounds of ill health."
(http://www.stats.ox.ac.uk/~ripley/)  I was pleased to see that he seems
to be well enough to send me the email below.


* BAD NEWS:  My Ecfun package is violating current CRAN rules
regarding "not writing anywhere in the file space".  (See below.)


QUESTION:


How do you suggest I respond to this?


It's hard for me to fix, because I cannot replicate the error and
I don't understand the rules Prof. Ripley is trying to enforce. The
"CRAN Package Check Results for" this package show an error on 1
platform (r-devel-linux-x86_64-fedora-gcc), NOTEs on 3 platforms
(Fedora-clang and Debian), and "OK" on 9 others.  I can program selected
tests not to run on CRAN, e.g., with (!fda::CRAN()).


However, I suspect I should be able to do better than that.


Suggestions?

The message from Prof. Ripley is crystal-clear, and exposes two issues
(Internet access, writing files) that have been discussed many times
in this list. A quick scan of the CRAN policy [1] yields:

- Packages which use Internet resources should fail gracefully with an
informative message if the resource is not available (and not give a
check warning nor error).

- Packages should not write in the user’s home filespace (including
clipboards), nor anywhere else on the file system apart from the R
session’s temporary directory.

[1] https://cran.r-project.org/web/packages/policies.html

Iñaki


Thanks,
Spencer Graves


p.s.  The development version of this package is available at
"https://github.com/sbgraves237/Ecfun;.


https://cloud.r-project.org/web/checks/check_results_Ecfun.html


 Forwarded Message 
Subject:CRAN package Ecfun
Date:   Tue, 21 Jan 2020 21:26:02 +
From:   Prof Brian Ripley 
Reply-To:   CRAN 
To: Spencer Graves 
CC: CRAN 



This has been intermittently failing its checks for a week: different
check runs failed (in the 24h prior to) the 14th, 15th, 17th and today.
The current failure is

Check: examples
Result: ERROR
Running examples in ‘Ecfun-Ex.R’ failed
The error most likely occurred in:

  > ### Name: read.testURLs
  > ### Title: Read a file produced by testURLs
  > ### Aliases: read.testURLs
  > ### Keywords: IO
  >
  > ### ** Examples
  >
  > # Test only 2 web sites, not the default 4,
  > # and test only twice, not the default 10 times:
  > tst <- testURLs(c(
+ PVI="http://en.wikipedia.org/wiki/Cook_Partisan_Voting_Index;,
+ house="http://house.gov/representatives;),
+ n=2, maxFail=2)
1
1579634784, PVI, TRUE 0.828
1579634785, house, FALSE 0.051
1579634785, house, FALSE 0.048
2
1579634785, PVI, TRUE 0.043
1579634785, house, FALSE 0.11
1579634785, house, FALSE 0.035
  >
  > # The above should have created a file 'testURLresults.csv'
  > # in the working directory. Read it.
  >
  > dat <- read.testURLs()
Error in read.table(file = file, header = header, sep = sep, quote =
quote, :
more columns than column names
Calls: read.testURLs -> read.csv -> read.table

That does not conform to the policy on Internet access, not least as no
attempt is made to check if the file was created, let alone that it has
the expected layout. Nor does it conform to the policy on not writing
anywhere in the file space (and that shows on its CRAN results page too).

Please correct ASAP and before Feb 4 to safely retain the package on CRAN.

--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford


 [[alternative HTML version deleted]]

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




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

Re: [R-pkg-devel] need help addressing future timestamp error

[Gábor Csárdi]

Yes, the time of R-hub's Solaris machine is probably off

Gabor

On Thu, Jan 23, 2020 at 9:17 PM Merlise Clyde, Ph.D.  wrote:
>
> I am checking my package for Solaris via rhub and this week have encountered 
> the following error:  "This system is set to the wrong time: please fix".  
> The output suggests that the time is off by 1 hour.  This occurs only on 
> Solaris, but I am not sure if that is because that is the only platform 
> checking timestamps and it is a problem in my setup -or- it is problem with 
> the rhub configuration.
>
> I have tried setting my MAC to use UTC timezone, but still encounter the 
> error. I am also encountering this when building the package under fedora and 
> submitting via rhub.
> (source code is at https://github.com/merliseclyde/BAS)
>
> Any suggestions ?   The error seems to stop the build, so I cannot verify if 
> the other parts of the check (testthat output in particular) are successful, 
> which are needed for the CRAN submission.
>
> Thanks in advance - Merlise
>
> Build ID:   BAS_1.5.5.tar.gz-44c32b29bc7a4127be3adfc60c81e330
> Platform:   Oracle Solaris 10, x86, 32 bit, R-patched (experimental)
> Submitted:  16 minutes 55 seconds ago
> Build time: 16 minutes 54.1 seconds
> ERRORS:
>
>
> * checking for future file timestamps ... ERROR
> This system is set to the wrong time: please correct
>system: 2020-01-23 21:14 (UTC)
>   correct: 2020-01-23 20:14 (UTC)
>
>
>
> Merlise A Clyde
> Professor Department of Statistical Science
> Duke University
> http://stat.duke.edu/~clyde
>
> cl...@duke.edu
> 919 681 8440
>
>
>
>
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[R-pkg-devel] need help addressing future timestamp error

[Merlise Clyde, Ph.D.]

I am checking my package for Solaris via rhub and this week have encountered 
the following error:  "This system is set to the wrong time: please fix".  The 
output suggests that the time is off by 1 hour.  This occurs only on Solaris, 
but I am not sure if that is because that is the only platform checking 
timestamps and it is a problem in my setup -or- it is problem with the rhub 
configuration.

I have tried setting my MAC to use UTC timezone, but still encounter the error. 
I am also encountering this when building the package under fedora and 
submitting via rhub.
(source code is at https://github.com/merliseclyde/BAS)

Any suggestions ?   The error seems to stop the build, so I cannot verify if 
the other parts of the check (testthat output in particular) are successful, 
which are needed for the CRAN submission.

Thanks in advance - Merlise

Build ID:   BAS_1.5.5.tar.gz-44c32b29bc7a4127be3adfc60c81e330
Platform:   Oracle Solaris 10, x86, 32 bit, R-patched (experimental)
Submitted:  16 minutes 55 seconds ago
Build time: 16 minutes 54.1 seconds
ERRORS:


* checking for future file timestamps ... ERROR
This system is set to the wrong time: please correct
   system: 2020-01-23 21:14 (UTC)
  correct: 2020-01-23 20:14 (UTC)



Merlise A Clyde
Professor Department of Statistical Science
Duke University
http://stat.duke.edu/~clyde

cl...@duke.edu
919 681 8440






[[alternative HTML version deleted]]

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

Re: [Rd] [External] Re: rpois(9, 1e10)

[Martin Maechler]

> Benjamin Tyner 
> on Thu, 23 Jan 2020 08:16:03 -0500 writes:

> On 1/20/20 12:33 PM, Martin Maechler wrote:
>> 
>> It's really something that should be discussed (possibly not
>> here, .. but then I've started it here ...).
>> 
>> The  NEWS  for R 3.0.0 contain (in NEW FEATURES) :
>> 
>> * Functions rbinom(), rgeom(), rhyper(), rpois(), rnbinom(),
>> rsignrank() and rwilcox() now return integer (not double)
>> vectors.  This halves the storage requirements for large
>> simulations.
>> 
>> and what I've been suggesting is to revert this change
>> (svn rev r60225-6) which was purposefully and diligently done by
>> a fellow R core member, so indeed must be debatable.
>> 
>> Martin

> For the record, I don't personally objects to the change here (as my 
> philosophy tends toward treating most warnings as errors anyway) but for 
> the sake of other useRs who may get bitten, perhaps we should be more 
> explicit that backwards-compatibility won't be preserved under certain 
> use patterns, for example:

> # works (with warning) in R 3.6.2 but fails (with error) in R-devel:
> vapply(list(1e9, 1e10),
>    function(lambda) {
>   rpois(1L, lambda)
>    },
>    FUN.VALUE = integer(1L)
>    )

Well, some people are too picky...
use numeric(), not integer() in such cases :

> vapply(1:10, function(i) if(runif(1) < 0.5) 1L else 2, FUN.VALUE=pi)
 [1] 1 1 2 2 2 2 1 1 2 1
> 

No, really,  I don't plan to spend time "bloating" the
documentation any further,
when noticing that only a "few parts in a billion"  people carefully read
our help pages where the remaining  99.999% percent rather try
things in the R console and draw (often) wrong conclusions...

I *am* glad and grateful for careful and accurate R users and
bug-squashing helpers such as you or Suharto or ...

Martin

> # in R-devel, a little extra work to achieve a warning as before:
> vapply(list(1e9, 1e10),
>    function(lambda) {
>   tmp <- rpois(1L, lambda)
>   if (!is.integer(tmp)) {
>  warning("NAs produced")
>  tmp <- NA_integer_
>   }
>   tmp
>    },
>    FUN.VALUE = integer(1L)
>    )

> (and yes I realize that rpois() vectorizes on lambda, so vapply is 
> re-inventing the wheel in this toy example, but there could be (?) a 
> justified use for it in more complicated simulations).

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

Re: [Bioc-devel] TensorFlow installations

[Shepherd, Lori]

Hello Simon,

The devel builders for tokay2 (windows) and malbec2 (linux) have tensorflow 2.x
tensorflow 2.0.0
tensorflow-estimator   2.0.1
tensorflow-probability 0.7.0


For the release builders
We have tensorflow 1.x installed on malbec1 (linux)
tensorflow (1.14.0)
tensorflow-estimator (1.14.0)
tensorflow-probability (0.7.0)

We have not updated tokay1 (windows) with python3 and python2 does not support 
tensorflow
We plan to update tokay1 and malbec1 when we do the next Bioconductor release 
in the spring following the principle that new and updated software should be 
introduced on the development branch and to keep the release branch as stable 
as possible.

Are current mac builders use El Capitan and because of constraints beyond our 
control we can not switch from El Capitan at this time. Tensorflow does not 
support El Capitan.   We have tried different work around but have been 
unsuccessful.

Cheers,



Lori Shepherd

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Simon Dirmeier 

Sent: Thursday, January 23, 2020 5:01 AM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] TensorFlow installations

Dear all,

I wanted to ask if there are any news regarding TensorFlow installations
on /tokay1/ and /merida1. /Is it already possible to use TF on these
servers? If not, can I maybe help out?

Thanks a lot.

Cheers,

Simon


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

Re: [R-pkg-devel] [CRAN-pretest-archived] CRAN submission EventDetectR 0.3.4

[Uwe Ligges]

Sorry, you asked for

Maintainer field differs from that derived from Authors@R
  Maintainer: ‘Sowmya Chandrasekaran’
  Authors@R:  ‘Frederik Rehbach ’


Obvisouly, both fields diaagree. Pkease omit the Mainainer field from 
the original sources. R CMD build will auto generate the maintainer 
field from the Authors@R field and indert the person with cre role as 
maintainer.


Please fix and resubmit.

Best,
Uwe Ligges




On 23.01.2020 15:21, Sowmya C wrote:

Dear CRAN/DEVEL Team,


I am looking forward for kind reply. The two NOTEs are intended changes
that we made and I think the rejection made is a false positive. Kindly do
the needful.

Regards
Sowmya Chandrasekaran

On Mon 13 Jan, 2020, 16:31 Sowmya C,  wrote:


Dear CRAN Team,

Thanks a lot for your quick response. This package is being developed as a
part of a funded research project. And currently i am working on this and
wish to be the maintainer of the package. And hence we wish to change the
maintainer from "Margarita Rebolledo " to ‘Sowmya
Chandrasekaran’. The same has been updated in the
description file and it is the two "Notes". Kindly do the needful.

Regards
Sowmya

##
1.
* checking CRAN incoming feasibility ... NOTE

Maintainer: ‘Sowmya Chandrasekaran’

New maintainer:
   Sowmya Chandrasekaran
Old maintainer(s):
   Margarita Rebolledo 

2.

* checking DESCRIPTION meta-information ... NOTE
Maintainer field differs from that derived from Authors@R
   Maintainer: ‘Sowmya Chandrasekaran’
   Authors@R:  ‘Frederik Rehbach ’



On Mon, Jan 13, 2020 at 4:19 PM  wrote:


Dear maintainer,

package EventDetectR_0.3.4.tar.gz does not pass the incoming checks
automatically, please see the following pre-tests:
Windows: <
https://win-builder.r-project.org/incoming_pretest/EventDetectR_0.3.4_20200113_160520/Windows/00check.log



Status: 2 NOTEs
Debian: <
https://win-builder.r-project.org/incoming_pretest/EventDetectR_0.3.4_20200113_160520/Debian/00check.log



Status: 2 NOTEs

Last released version's CRAN status: OK: 13
See: <
https://CRAN.R-project.org/web/checks/check_results_EventDetectR.html>

CRAN Web: 

Please fix all problems and resubmit a fixed version via the webform.
If you are not sure how to fix the problems shown, please ask for help on
the R-package-devel mailing list:

If you are fairly certain the rejection is a false positive, please
reply-all to this message and explain.

More details are given in the directory:
<
https://win-builder.r-project.org/incoming_pretest/EventDetectR_0.3.4_20200113_160520/



The files will be removed after roughly 7 days.

No strong reverse dependencies to be checked.

Best regards,
CRAN teams' auto-check service
Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
Check: CRAN incoming feasibility, Result: NOTE
   Maintainer: 'Sowmya Chandrasekaran'

   New maintainer:
 Sowmya Chandrasekaran
   Old maintainer(s):
 Margarita Rebolledo 

Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
Check: DESCRIPTION meta-information, Result: NOTE
   Maintainer field differs from that derived from Authors@R
 Maintainer: 'Sowmya Chandrasekaran'
 Authors@R:  'Frederik Rehbach '





[[alternative HTML version deleted]]



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

Re: [Rd] [External] Re: rpois(9, 1e10)

[Benjamin Tyner]

On 1/20/20 12:33 PM, Martin Maechler wrote:


It's really something that should be discussed (possibly not
here, .. but then I've started it here ...).

The  NEWS  for R 3.0.0 contain (in NEW FEATURES) :

 * Functions rbinom(), rgeom(), rhyper(), rpois(), rnbinom(),
   rsignrank() and rwilcox() now return integer (not double)
   vectors.  This halves the storage requirements for large
   simulations.

and what I've been suggesting is to revert this change
(svn rev r60225-6) which was purposefully and diligently done by
a fellow R core member, so indeed must be debatable.

Martin


For the record, I don't personally objects to the change here (as my 
philosophy tends toward treating most warnings as errors anyway) but for 
the sake of other useRs who may get bitten, perhaps we should be more 
explicit that backwards-compatibility won't be preserved under certain 
use patterns, for example:


   # works (with warning) in R 3.6.2 but fails (with error) in R-devel:
   vapply(list(1e9, 1e10),
   function(lambda) {
  rpois(1L, lambda)
   },
   FUN.VALUE = integer(1L)
   )

   # in R-devel, a little extra work to achieve a warning as before:
   vapply(list(1e9, 1e10),
   function(lambda) {
  tmp <- rpois(1L, lambda)
  if (!is.integer(tmp)) {
 warning("NAs produced")
 tmp <- NA_integer_
  }
  tmp
   },
   FUN.VALUE = integer(1L)
   )

(and yes I realize that rpois() vectorizes on lambda, so vapply is 
re-inventing the wheel in this toy example, but there could be (?) a 
justified use for it in more complicated simulations).


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

Re: [Bioc-devel] New bioconductor_docker image officially released

[Felix Ernst]

Hi Nitesh,

Thanks for the new image.

I have a question regarding the behavior of encountering logicals with a length 
higher than 1 and its coercion to logical(1) for an if statement.

I encountered a bit of a problem, when a unit test returned an error running R 
CMD check using the Bioconductor docker image:

'length(x) = 2 > 1' in coercion to 'logical(1)'

However in a normal session this didn't raise an error. After adding 

_R_CHECK_LENGTH_1_CONDITION_=true
_R_CHECK_LENGTH_1_LOGIC2_=true

to /usr/local/lib/R/etc/Renviron.site the behavior matched the output from R 
CMD check.

Is this behavior intended or would you consider adding this setting to the 
docker image?

Best regards
Felix

-Ursprüngliche Nachricht-
Von: Bioc-devel  Im Auftrag von Turaga, Nitesh
Gesendet: Dienstag, 21. Januar 2020 18:41
An: bioc-devel@r-project.org
Betreff: [Bioc-devel] New bioconductor_docker image officially released

Hello developers,

The new "bioconductor/bioconductor_docker" image is officially released.

The link to access it on Dockerhub is:  
https://hub.docker.com/repository/docker/bioconductor/bioconductor_docker.

The source code in on GitHub at: 
https://github.com/bioconductor/bioconductor_docker.

Please note there are currently two versions,

1. bioconductor/bioconductor_docker:devel

2. bioconductor/bioconductor_docker:RELEASE_3_10 or 
bioconductor/bioconductor_docker:latest

The previous set of images have been deprecated. The previous images have also 
been updated with a `LABEL` in the Dockerfile which refers to them as 
"Deprecated". You can see this information on your image if you do a  `docker 
pull ; docker inspect `. Please note, we will support 
these images through this release cycle.

We highly recommend that you shift to the new images, and use those containers. 
They come with all the system dependencies to install almost all of the 
Bioconductor packages, an RStudio interface, and with customizations which are 
specific to Bioconductor.

Docker images are now considered similar to Bioconductor packages. There will 
be official contributions from the community following our list of best 
practices.
 If you need more information on the docker images please refer to 
http://bioconductor.org/help/docker/.

As always, if you have any questions, please feel free to reply to this email.

Best regards,

Nitesh





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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Rd] Long vector support in data.frame

[Morgan Morgan]

Hi All,

Happy New Year!

I was wondering if there is a plan at some point to support long vectors in
data.frames?
I understand that it would need some internal changes to lift the current
limit.
If there is a plan what is currently preventing it from happening? Is it
time, resources? If so is there a way for people willing to help to
contribute or help the R-dev team? How?
I noticed that an increasing number of function are supporting long vectors
in base R. Is there more functions that need to support long vectors before
having long vectors support in data.frames?

Thank you
Best regards
Morgan

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Alternatives to R-devel on a Mac for package checking?

[David Hugh-Jones]

The other obvious online checker is rhub, via the rhub package.
David


On Wed, 15 Jan 2020 at 21:39, Jonathan Greenberg  wrote:

> One of the issues I'm running into is that it seems every time there's a
> Mac update something gets broken with regards to compilers, making it
> incredibly challenging to get the development install of R working with
> Rcpp (which is a requirement for the packages I need to use to check my
> packages).
>
> I'd like to start moving towards an easier approach rather than spending
> days fixing various issues on my Mac just to run a simple --as-cran check
> on a package with the latest  r-devel.  I was HOPING there is an up-to-date
> Docker for the r-development 4.0 version out in the wild, but it seems like
> the rocker r-devel is just 3.6.2.  Any ideas?
>
> docker run --rm -ti rocker/r-devel
>
> Alternatively, are there any decent online checkers (except the CRAN
> ones)?  r-forge seems to not do r-devel checks anymore.
>
> --j
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Bioconductor Developers Forum - Thursday 23rd January

[Mike Smith]

Just as a reminder, the next call is taking place today at 09:00 PST/ 12:00
EST / 18:00 CET

https://bluejeans.com/114067881 (Meeting ID: 114 067 881)

One topic for discussion is the new Windows toolchain being trialled on
CRAN.  Any other topics are welcome.

See you later,

Mike

On Mon, 20 Jan 2020 at 12:56, Mike Smith  wrote:

> Dear all,
>
> The next Bioconductor Developers' Forum is scheduled for Thursday 23rd
> January at 09:00 PST/ 12:00 EST / 18:00 CET
>
> We will be using BlueJeans and  the meeting can be joined via:
>
> https://bluejeans.com/114067881 (Meeting ID: 114 067 881)
>
> If you have any specific topics you'd like to raise please let me know or
> post in #developers-forum on Bioconductor Slack (
> https://bioc-community.herokuapp.com/)
>
> Best wishes,
>
> Mike
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Adding .exes to R package?

[Ivan Krylov]

On Wed, 22 Jan 2020 20:54:40 +
Jonathan Greenberg  wrote:

> Are there reasonable tutorials on how to do this?

If you absolutely have to do this, take a look at the tinytex package.
It is basically an installer for a preselected set of packages from TeX
Live inside a platform-specific directory. However, if you go this way,
I would like to ask you to preserve the use of manually-installed GDAL
as an option, because I consider manually installed (or distro-provided
in case of GNU/Linux) binaries much easier to trust than automatically
downloaded ones.

"Writing R extensions" mentions _building_ executables as part of the
package a few paragraphs down 1.1.5 Package subdirectories, but
describes such packages as "very special cases" and requiring a lot of
additional hassle: you'd have to provide src/Makefile{,.win} that
should manually build the shared object and the executables and
src/install.libs.R that would install both the shared object and the
executables. I don't think this approach is viable, since latest GDAL
sources are about 13M in size (compressed), and maintaining both the
package and the GDAL binaries would be a serious duplication of effort.

-- 
Best regards,
Ivan

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

[Bioc-devel] TensorFlow installations

[Simon Dirmeier]

Dear all,

I wanted to ask if there are any news regarding TensorFlow installations
on /tokay1/ and /merida1. /Is it already possible to use TF on these
servers? If not, can I maybe help out?

Thanks a lot.

Cheers,

Simon


[[alternative HTML version deleted]]

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

Re: [Rd] Memory error in the libcurl connection code

[Martin Maechler]

> Gábor Csárdi 
> on Wed, 22 Jan 2020 22:56:17 + writes:

> Hi All,
> I think there is a memory error in the libcurl connection code that
> typically happens when libcurl reads big chunks of data. This
> potentially affects all code that use url() with the libcurl download
> method, which is the default in most builds. In practice it tends to
> happen more with HTTP/2 and if the connection is wrapped into a
> gzcon(). macOS Catalina has a libcurl build with HTTP/2 error, so many
> users that upgraded macOS are starting to see this.

> The workaround is to avoid using url(), if you can. If you need an
> HTTP stream, you can use curl::curl(), which is a drop-in replacement.

> To reproduce, the easiest is a libcurl build that has HTTP/2 support
> and a server with HTTP/2 as well, e.g. the cloud mirror:

> 
> ~ # R --slave -e 'options(internet.info = 0); foo <-
> 
readRDS(gzcon(url("https://cran.rstudio.com/src/contrib/Meta/archive.rds;)))'
> *   Trying 13.33.54.118:443...
> * TCP_NODELAY set
> * Connected to cran.rstudio.com (13.33.54.118) port 443 (#0)
> * ALPN, offering h2
> * ALPN, offering http/1.1
> * successfully set certificate verify locations:
> *   CAfile: /etc/ssl/certs/ca-certificates.crt
> CApath: none
> * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
> * ALPN, server accepted to use h2
> * Server certificate:
> *  subject: CN=cran.rstudio.com
> *  start date: Jul 24 00:00:00 2019 GMT
> *  expire date: Aug 24 12:00:00 2020 GMT
> *  subjectAltName: host "cran.rstudio.com" matched cert's 
"cran.rstudio.com"
> *  issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
> *  SSL certificate verify ok.
> * Using HTTP2, server supports multi-use
> * Connection state changed (HTTP/2 confirmed)
> * Copying HTTP/2 data in stream buffer to connection buffer after 
upgrade: len=0
> * Using Stream ID: 1 (easy handle 0x56303c2910e0)
>> GET /src/contrib/Meta/archive.rds HTTP/2
> Host: cran.rstudio.com
> User-Agent: R (3.4.4 x86_64-pc-linux-gnu x86_64 linux-gnu)
> Accept: */*

> * Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
> < HTTP/2 200
> < content-length: 2483432
> < date: Wed, 22 Jan 2020 21:22:04 GMT
> < server: Apache/2.4.39 (Unix)
> < last-modified: Wed, 22 Jan 2020 17:10:22 GMT
> < etag: "25e4e8-59cbd998a0360"
> < accept-ranges: bytes
> < cache-control: max-age=1800
> < expires: Wed, 22 Jan 2020 21:52:04 GMT
> < x-cache: Hit from cloudfront
> < via: 1.1 6cbe48f9f9ff0c768f29d83804f75d4c.cloudfront.net (CloudFront)
> < x-amz-cf-pop: MAN50-C1
> < x-amz-cf-id: WwCQVQz9g8ZP6Az4m4n__h7aUW6vwlg0-AkiCv_DnVfGe10bzaFtfg==
> < age: 960
> <
> * 85 data bytes written
> Error in 
readRDS(gzcon(url("https://cran.rstudio.com/src/contrib/Meta/archive.rds;)))
> :
> reference index out of range
> * stopped the pause stream!
> * Connection #0 to host cran.rstudio.com left intact
> Execution halted
> 

> Sometimes you get a crash, sometimes a corrupt stream, etc. Sometimes
> is actually works.

> It seems that the fix is simply this:

> 
> --- src/modules/internet/libcurl.c~
> +++ src/modules/internet/libcurl.c
> @@ -762,6 +762,7 @@
> void *newbuf = realloc(ctxt->buf, newbufsize);
> if (!newbuf) error("Failure in re-allocation in rcvData");
ctxt-> buf = newbuf; ctxt->bufsize = newbufsize;
> +ctxt->current = ctxt->buf;
> }

> memcpy(ctxt->buf + ctxt->filled, ptr, add);
> 

> Best,
> Gabor

Thanks a lot, Gábor!

I can reproduce the problem (on Linux Fedora 30) and confirm
that your patch works.

Even more, the patch looks  "almost obvious",
because
ctxt->current = ctxt->buf

happens earlier in rcvData() after a change to ctxt->buf  and so
should be updated if buf is.

An even slightly "better" patch just moves that statement down
to after the  if(add) { .. }  clause.

I'll patch the sources, and will port to 'R 3.6.2 patched'.

Martin

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