[Rd] NEWS typos, download.file.Rd tweaks

[Ben Bolker]

  Some small changes (typo, punctuation fix) to the NEWS file, and some
suggested changes to download.file.Rd (I found some of the phrasing
awkward/hard to parse, and got carried away).  (I *think* .txt
attachments are OK on the list?)

  FWIW I started fixing the download.file man page because I went there
to understand/be horrified by the following (documented!) infelicity:
with the default settings (on Unix at least), failing to download what
is intended to be a new version of a file will wipe out the original,
leaving an empty file.  So, for example, a temporary network problem can
lead to a pipeline being unworkable (because a critical file has been
emptied) until the network comes back ...  I don't suppose there's any
chance this behaviour could be changed ... ??

> What happens to the destination file(s) in the case of error
 depends on the method and R version. Currently the ‘"internal"’,
 ‘"wininet"’ and ‘"libcurl"’ methods will remove the file if there
 the URL is unavailable except when ‘mode’ specifies appending when
 the file should be unchanged.

Obligatory xkcd: https://xkcd.com/293/

 cheers
   Ben Bolker
Index: doc/NEWS.Rd
===
--- doc/NEWS.Rd (revision 75424)
+++ doc/NEWS.Rd (working copy)
@@ -141,7 +141,7 @@
   i.e., all help pages. show platform-independent information (rather
   than Windows or Unix-alike specifics visible only on that platform).
   Consequently, the Windows version of \code{X11()} / \code{x11()}
-  got identical formal arguments the unix one.
+  now has identical formal arguments to the Unix version.
 
   \item \code{sessionInfo()$running} has been factored out in a new
   variable \code{osVersion}. % precomputed at utils namespace load time
@@ -283,7 +283,7 @@
 
   \item The documentation for \code{identify()} incorrectly claimed
   that the indices of identified points were returned in the order
-  that the points were selected..  \code{identify()} now has a new
+  that the points were selected.  \code{identify()} now has a new
   argument \code{order} to allow the return value to include the
   order in which points were identified; the documentation has been
   updated.  Reported by Richard Rowe and Samuel Granjeaud.
Index: src/library/utils/man/download.file.Rd
===
--- src/library/utils/man/download.file.Rd  (revision 75424)
+++ src/library/utils/man/download.file.Rd  (working copy)
@@ -133,15 +133,16 @@
   \code{"libcurl"} method values of the option less than 2 give verbose
   output.
 
-  A progress bar tracks the transfer platform specifically:
+  A progress bar tracks the transfer, with behavior depending on the
+  platform:
   \describe{
 \item{On Windows}{If the file length is known, the
   full width of the bar is the known length.  Otherwise the initial
   width represents 100 Kbytes and is doubled whenever the current width
-  is exceeded.  (In non-interactive use this uses a text version.  If the
-  file length is known, an equals sign represents 2\% of the transfer
-  completed: otherwise a dot represents 10Kb.)}
-\item{On a unix-alike}{If the file length is known, an
+  is exceeded.  (In non-interactive use the progress bar uses
+  a text version which follows the Unix-alike behavior described
+  below.)}
+\item{On a Unix-alike}{If the file length is known, an
   equals sign represents 2\% of the transfer completed: otherwise a dot
   represents 10Kb.}
   }
@@ -248,7 +249,7 @@
   Note that the root certificates used by \R may or may not be the same
   as used in a browser, and indeed different browsers may use different
   certificate bundles (there is typically a build option to choose
-  either their own or the system ones).
+  either their own or those from the system).
 }
 \section{FTP sites}{
   \samp{ftp:} URLs are accessed using the FTP protocol which has a
@@ -284,8 +285,8 @@
   What happens to the destination file(s) in the case of error depends
   on the method and \R{} version. Currently the \code{"internal"},
   \code{"wininet"} and \code{"libcurl"} methods will remove the file if
-  there the URL is unavailable except when \code{mode} specifies
-  appending when the file should be unchanged.
+  the URL is unavailable except when \code{mode} specifies
+  appending, in which case the file will not be changed.
 }
 \seealso{
   \code{\link{options}} to set the \code{HTTPUserAgent}, \code{timeout}
Index: src/main/eval.c
===
--- src/main/eval.c (revision 75424)
+++ src/main/eval.c (working copy)
@@ -1,4 +1,4 @@
-/*
+   /*
  *  R : A Computer Language for Statistical Data Analysis
  *  Copyright (C) 1998--2018   The R Core Team.
  *  Copyright (C) 1995, 1996   Robert Gentleman and Ross Ihaka

Re: [Rd] bug with OutDec option and deferred_string altrep object

[Tierney, Luke]

This is now fixed in R-devel. Will port to R_patched in due course.
R_inspect also now handles pairlists ending with dotted pairs.

Best,

luke

On Tue, 9 Oct 2018, Tierney, Luke wrote:

> Thanks for the report. The approach you outlines below should work --
> I'll look into it.
>
> Best,
>
> luke
>
> On Mon, 8 Oct 2018, Michael Sannella wrote:
>
>> While implementing R's new 'altrep' functionality in the TERR engine,
>> I discovered a bug in R's 'deferred_string' altrep object: it is not
>> using the correct value of the 'OutDec' option when it expands a
>> deferred_string.  See the following example:
>>
>> R 3.5.1: (same results in R 3.6.0 devel engine built 10/5)
>>     > options(scipen=0, OutDec=".")
>>     > as.character(123.456)
>>     [1] "123.456"
>>     > options(scipen=-5, OutDec=",")
>>     > as.character(123.456)
>>     [1] "1,23456e+02"
>>     > xx <- as.character(123.456)
>>     > options(scipen=0, OutDec=".")
>>     > xx
>>     [1] "1.23456e+02"
>>     >
>>
>> In the example above, the variable 'xx' is set to a deferred_string
>> while OutDec is ','.  However, when the string is actually formatted
>> (when xx is printed), it uses the current option value OutDec='.' to
>> format the string.  I think that deferred_string should use the value
>> OutDec=',' from when as.character was called.
>>
>> Note that the behavior is different with the 'scipen' option: The
>> deferred_string object records the scipen=-5 value when as.character
>> is called, and uses this value when xx is printed.  Looking at the
>> deferred_string object, it appears that CDR(R_altrep_data1()) is
>> set to a scalar integer containing the scipen value at the time the
>> deferred_string was created.
>>
>> Ideally, the deferred_string object would save both the scipen and
>> OutDec option values.  I'd suggest saving these values as regular
>> pairlist values, say by setting the data1 field to pairlist(,
>> scipen=-5L, OutDec=',') for the value of xx above.  To save space, you
>> could avoid saving these values in the common case where scipen=0L,
>> OutDec='.'.  It would also be better if the data1 field was a
>> well-formed pairlist; the current value of the data1 field causes
>> R_inspect to segfault.
>>
>> I understand that you probably wouldn't want to change the
>> deferred_string structure.  An alternative fix would be to avoid this
>> case by:
>>   1. Never create a deferred_string if OutDec is not '.'.
>>   2. When expanding an element of a deferred_string, temporarily set
>> OutDec to '.'.
>>
>>   ~~ Michael Sannella
>>
>>
>>
>
>

-- 
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa  Phone: 319-335-3386
Department of Statistics andFax:   319-335-3017
Actuarial Science
241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Bioc-devel] Package simulatorZ timeout under Windows on the release but not the devel branch

[Yuqing Zhang]

Hi all,

I received an email saying that my package, simulatorZ, is timing out. In
the current report, it is timing out under Windows in the release branch.
But it passes all builds and checks in the devel branch on all platforms
(on Windows it passes the check in about 5 minutes). I haven't changed
anything in the package, so I'm confused how I got this timeout issue...

Could anyone please advise what I need to do about this?

Thanks,
Yuqing


-- 
Yuqing Zhang
PhD Candidate in Bioinformatics, Boston University
BS in Applied Mathematics, Peking University
Cell:(617)909-3594
Email:zhangyuqing.pku...@gmail.com

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Invalid Parameter - /figure-html

[Obenchain, Valerie]

Hi Tiago,

I'm looking into this.

Valerie


On 9/27/18 7:43 AM, Tiago Chedraoui Silva wrote:

Hello,

The workflow I'm maintaining is giving this message "Invalid Parameter -
/figure-html"  in the devel and release windows environment.

http://bioconductor.org/checkResults/devel/workflows-LATEST/TCGAWorkflow/tokay1-buildsrc.html

It seems other users had the same problem before:
https://stackoverflow.com/questions/48747959/biocstyle-vignettes-invalid-parameter-figure-html?rq=1

Please, someone knows how that could be fixed?

Best regards,
Tiago Chedraoui Silva

[[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: [Bioc-devel] avoiding circular dependencies between a Data package and a Software package

[Tim Triche, Jr.]

awesome, thanks.

--t


On Tue, Oct 9, 2018 at 3:29 PM Obenchain, Valerie <
valerie.obench...@roswellpark.org> wrote:

> I'm not sure what you mean by flipping the script ...?
>
> Looks like I was out of date with my advice on the .BBSoptions. A few
> months ago the BBS was modified to install all packages so the
>
> ForceInstall: True
>
> is no longer needed. You can remove the .BBSoptions file - sorry for the
> confusion.
>
> Lori will be updating the docs (
> https://github.com/Bioconductor/Contributions#submitting-related-packages)
> with more detail on handling packages with mutual (circular) dependencies.
> I see your package was assigned to Herve - if you are still having problems
> with the build you can ask @lshep or @hpages for help on the issue.
>
> Thanks for the pull request, it's been merged.
>
> Val
>
>
> On 10/8/18 7:23 AM, Tim Triche, Jr. wrote:
>
> D'oh.  Does this mean that I should flip the script a second time?
>
> I went ahead and added the .BBSoptions file as suggested and flushed out
> some additional irritants; it seemed that having the main package Suggest:
> the Data package went more smoothly (no cycles) so I had updated the ticket
> to reflect this. I also updated the support site question to reflect that
> suggestion. But now I am not sure if that's right.
>
> It is a bit confusing. I'd send a PR except I'm not really qualified to
> patch it. However, there was a reference to Subversion that stuck in my
> head after submission, and I did track that down; see
> https://github.com/Bioconductor/Contributions/pull/916 for details ;-)
>
> Thank you,
>
>
>
> --t
>
>
> On Mon, Oct 8, 2018 at 8:44 AM Shepherd, Lori <
> lori.sheph...@roswellpark.org> wrote:
>
>> Hello,
>>
>>
>> The Single Package builder (SPB) does check the .BBSOptions but only for
>> UnsupportedPlatforms.  This is because the single package builder
>> automatically installs each package before the build and check stage as
>> part of the process.  Each package that goes through the single package
>> builder for new submits temporarily gets its own directory to use for
>> installing and referencing dependencies -  This is why we document that
>> packages with additional or supporting packages should be built under the
>> same issue as then they will be able to find each other.  The submission
>> process where the data package that "suggests" the software package is
>> submitted first, followed by the software package that "depends" on the
>> data package is correct.
>>
>>
>> Its a little confusing at first but the following will/should happen on
>> the SPB:
>>
>>
>>
>>1.  The data package will be submitted and fail because the software
>>package is not available (but it will be installed in the Rlibs directory
>>for the issue)
>>2. The software package is submitted and fails because the data
>>package can't be found (but also installs)
>>3. The maintainer should do an arbitrary version bump on the data
>>package to kick off a new build that should now pass as it will find the
>>software package
>>4. Do any additional debugging on the data package to ensure the data
>>package has a clean build and check.
>>5. The maintainer should do an arbitrary version bump on the software
>>package, only after the data package is building and checking cleanly, to
>>rebuild the software package
>>6. Review process continues and packages are accepted
>>
>>
>> The same failure scheme will happen on the main builders once the package
>> is accepted, the only difference is the maintainer will not have to version
>> bump for the new builds since the daily builds builds and checks all
>> packages automatically (daily for software and  Sun/Tue/Thru for data
>> packages)- The ERRORS will clean up on there own after 3-5 days depending
>> on when it is accepted and added to the main builders in reference to the
>> schedule of the building of data packages (Sun/Tue/Thur).  Once the
>> packages are both installed once, the circular dependency issue will be
>> resolved.
>>
>> Cheers,
>>
>>
>>
>> Lori Shepherd
>>
>> Bioconductor Core Team
>>
>> Roswell Park Cancer Institute
>>
>> Department of Biostatistics & Bioinformatics
>>
>> Elm & Carlton Streets
>>
>> Buffalo, New York 14263
>> --
>> *From:* Bioc-devel  on behalf of
>> Obenchain, Valerie 
>> 
>> *Sent:* Sunday, October 7, 2018 11:54:46 AM
>> *To:* Michael Lawrence; Tim Triche, Jr.
>> *Cc:* packa...@bioconductor.org; bioc-devel
>> *Subject:* Re: [Bioc-devel] avoiding circular dependencies between a
>> Data package and a Software package
>>
>> I forgot to add the .BBSoptions file should be located at the 'top' level
>> of the package, e.g., MTseekerData/.BBSoptions. You might as well add that
>> now instead of waiting until the packages are approved. I think the SPB was
>> modified to be aware of the .BBSoptions file so it may require it too (Lori
>> would know). If the SPB does require .BBSoptions we should 

Re: [Bioc-devel] avoiding circular dependencies between a Data package and a Software package

[Obenchain, Valerie]

I'm not sure what you mean by flipping the script ...?

Looks like I was out of date with my advice on the .BBSoptions. A few months 
ago the BBS was modified to install all packages so the

ForceInstall: True

is no longer needed. You can remove the .BBSoptions file - sorry for the 
confusion.

Lori will be updating the docs 
(https://github.com/Bioconductor/Contributions#submitting-related-packages) 
with more detail on handling packages with mutual (circular) dependencies. I 
see your package was assigned to Herve - if you are still having problems with 
the build you can ask @lshep or @hpages for help on the issue.

Thanks for the pull request, it's been merged.

Val


On 10/8/18 7:23 AM, Tim Triche, Jr. wrote:
D'oh.  Does this mean that I should flip the script a second time?

I went ahead and added the .BBSoptions file as suggested and flushed out some 
additional irritants; it seemed that having the main package Suggest: the Data 
package went more smoothly (no cycles) so I had updated the ticket to reflect 
this. I also updated the support site question to reflect that suggestion. But 
now I am not sure if that's right.

It is a bit confusing. I'd send a PR except I'm not really qualified to patch 
it. However, there was a reference to Subversion that stuck in my head after 
submission, and I did track that down; see 
https://github.com/Bioconductor/Contributions/pull/916 for details ;-)

Thank you,



--t


On Mon, Oct 8, 2018 at 8:44 AM Shepherd, Lori 
mailto:lori.sheph...@roswellpark.org>> wrote:

Hello,


The Single Package builder (SPB) does check the .BBSOptions but only for 
UnsupportedPlatforms.  This is because the single package builder automatically 
installs each package before the build and check stage as part of the process.  
Each package that goes through the single package builder for new submits 
temporarily gets its own directory to use for installing and referencing 
dependencies -  This is why we document that packages with additional or 
supporting packages should be built under the same issue as then they will be 
able to find each other.  The submission process where the data package that 
"suggests" the software package is submitted first, followed by the software 
package that "depends" on the data package is correct.


Its a little confusing at first but the following will/should happen on the SPB:


  1.   The data package will be submitted and fail because the software package 
is not available (but it will be installed in the Rlibs directory for the issue)
  2.  The software package is submitted and fails because the data package 
can't be found (but also installs)
  3.  The maintainer should do an arbitrary version bump on the data package to 
kick off a new build that should now pass as it will find the software package
  4.  Do any additional debugging on the data package to ensure the data 
package has a clean build and check.
  5.  The maintainer should do an arbitrary version bump on the software 
package, only after the data package is building and checking cleanly, to 
rebuild the software package
  6.  Review process continues and packages are accepted

The same failure scheme will happen on the main builders once the package is 
accepted, the only difference is the maintainer will not have to version bump 
for the new builds since the daily builds builds and checks all packages 
automatically (daily for software and  Sun/Tue/Thru for data packages)- The 
ERRORS will clean up on there own after 3-5 days depending on when it is 
accepted and added to the main builders in reference to the schedule of the 
building of data packages (Sun/Tue/Thur).  Once the packages are both installed 
once, the circular dependency issue will be resolved.

Cheers,



Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel 
mailto:bioc-devel-boun...@r-project.org>> on 
behalf of Obenchain, Valerie 

Sent: Sunday, October 7, 2018 11:54:46 AM
To: Michael Lawrence; Tim Triche, Jr.
Cc: packa...@bioconductor.org; bioc-devel
Subject: Re: [Bioc-devel] avoiding circular dependencies between a Data package 
and a Software package

I forgot to add the .BBSoptions file should be located at the 'top' level of 
the package, e.g., MTseekerData/.BBSoptions. You might as well add that now 
instead of waiting until the packages are approved. I think the SPB was 
modified to be aware of the .BBSoptions file so it may require it too (Lori 
would know). If the SPB does require .BBSoptions we should document that in

https://github.com/Bioconductor/Contributions/blob/master/CONTRIBUTING.md

Valerie

On 10/7/18 8:39 AM, Obenchain, Valerie wrote:

Hi Tim,

As Michael said, the usual case is the data package 'Suggests' the software and 
the software 'Depends' or 'Imports' 

Re: [Rd] Buglet in handling times in R-3.5.1

[Marco Atzeri]

Am 09.10.2018 um 16:56 schrieb Russell, George:

Dear R developers,

I have found a minute bug in R-3.5.1 (Windows version), about how times not an 
exact number of seconds are displayed.

as.POSIXct("1969-01-01 01:00")+0.3

[1] "1969-01-01 01:00:01 CET"

as.POSIXct("1970-01-01 01:00")+0.3

[1] "1970-01-01 01:00:00 CET"

So for 1969, adding 0.3 of a second means you round UP, for 1970 you round 
DOWN. But I think it should be consistent.


More likely a bug in the underlining C library
The Cygwin build does not show the problem

> as.numeric(as.POSIXct("1969-01-01 01:00")+0.3)
[1] -31535999.7
> as.POSIXct("1969-01-01 01:00")+0.3
[1] "1969-01-01 01:00:00 CET"
> as.numeric(as.POSIXct("1969-01-01 01:00"))
[1] -31536000
> as.POSIXct("1969-01-01 01:00")
[1] "1969-01-01 01:00:00 CET"

> R.version
   _
platform   x86_64-unknown-cygwin
arch   x86_64
os cygwin
system x86_64, cygwin
status
major  3
minor  5.1
year   2018
month  07
day02
svn rev74947
language   R
version.string R version 3.5.1 (2018-07-02)
nickname   Feather Spray


---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

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

Re: [Rd] Buglet in handling times in R-3.5.1

[Emil Bode]

Here on my Mac it looks worse: not a rounding difference, but an off-by-one 
error for fractional seconds before 1970, looks like the conversion to POSIXlt 
is doing something wrong:

Options(digits=12)
as.numeric(as.POSIXlt(as.POSIXct('1969-01-01')))
[1] -31539600
# As expected
as.numeric(as.POSIXlt(as.POSIXct('1969-01-01')+.1))
[1] -31539598.9
# An additional second disappears (and no, there was no (negative) leap second)

I'm not enough at home in C to get to the core of it, the problem is in the 
.Internal call
Hoping somebody can investigate further.
Specs: R 3.5.1; macOS 10.13.6

Best regards, 
Emil Bode
 

On 09/10/2018, 17:27, "R-devel on behalf of Russell, George" 
 wrote:

Dear R developers,

I have found a minute bug in R-3.5.1 (Windows version), about how times not 
an exact number of seconds are displayed.
> as.POSIXct("1969-01-01 01:00")+0.3
[1] "1969-01-01 01:00:01 CET"
> as.POSIXct("1970-01-01 01:00")+0.3
[1] "1970-01-01 01:00:00 CET"

So for 1969, adding 0.3 of a second means you round UP, for 1970 you round 
DOWN. But I think it should be consistent.

At the end of this message I have put the usual version information.

Thanks for all your help and for your work on this wonderful product.


> R.version
   _
platform   x86_64-w64-mingw32
arch   x86_64
os mingw32
system x86_64, mingw32
status
major  3
minor  5.1
year   2018
month  07
day02
svn rev74947
language   R
version.string R version 3.5.1 (2018-07-02)
nickname   Feather Spray

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


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

[Rd] Buglet in handling times in R-3.5.1

[Russell, George]

Dear R developers,

I have found a minute bug in R-3.5.1 (Windows version), about how times not an 
exact number of seconds are displayed.
> as.POSIXct("1969-01-01 01:00")+0.3
[1] "1969-01-01 01:00:01 CET"
> as.POSIXct("1970-01-01 01:00")+0.3
[1] "1970-01-01 01:00:00 CET"

So for 1969, adding 0.3 of a second means you round UP, for 1970 you round 
DOWN. But I think it should be consistent.

At the end of this message I have put the usual version information.

Thanks for all your help and for your work on this wonderful product.


> R.version
   _
platform   x86_64-w64-mingw32
arch   x86_64
os mingw32
system x86_64, mingw32
status
major  3
minor  5.1
year   2018
month  07
day02
svn rev74947
language   R
version.string R version 3.5.1 (2018-07-02)
nickname   Feather Spray

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

Re: [Rd] R_ext/Altrep.h should be more C++-friendly

[Romain Francois]

I successfully use this workaround in this package: 
https://github.com/romainfrancois/altrepisode

(which is just my way to get familiar with altrep, nothing serious)

> Le 9 oct. 2018 à 17:00, Gabe Becker  a écrit :
> 
> Michael,
> 
> Thanks for reaching out. This was brought up by Romaine Francois offline to 
> me as well. What he does as a workaround is 
> 
> 
> #define class klass
> extern "C" {
>   #include 
> }
> #undef class
> 
> While we consider changing Altrep.h, the above should work for you  in the 
> immediate term.
> 
> Let me know if it doesn't.
> 
> ~G
> 
> 
> 
> 
> 
>> On Mon, Oct 8, 2018 at 4:17 PM, Michael Sannella via R-devel 
>>  wrote:
>> I am not able to #include "R_ext/Altrep.h" from a C++ file.  I think
>> it needs two changes:
>> 
>> 1. add the same __cplusplus check as most of the other header files:
>> #ifdef  __cplusplus
>> extern "C" {
>> #endif
>> ...
>> #ifdef  __cplusplus
>> }
>> #endif
>> 
>> 2. change the line
>> R_new_altrep(R_altrep_class_t class, SEXP data1, SEXP data2);
>>  to
>> R_new_altrep(R_altrep_class_t cls, SEXP data1, SEXP data2);
>>  since C++ doesn't like an argument named 'class'
>> 
>>   ~~ Michael Sannella
>> 
>> [[alternative HTML version deleted]]
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
> 
> 
> 
> -- 
> Gabriel Becker, Ph.D
> Scientist
> Bioinformatics and Computational Biology
> Genentech Research

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] cTRAP: WARNINGS in package submission

[Shepherd, Lori]

I'm sure your reviewer could offer additional advice as well, but first thought 
is are you downloading the data each time the package is run or each time a 
vignette or example is run?  Perhaps caching the file using  BiocFileCache 
would save some additional time (or be costly the first run but then be 
expedited on future runs)  See 
https://bioconductor.org/packages/devel/bioc/vignettes/BiocFileCache/inst/doc/BiocFileCache.html#cache-to-manage-package-data




Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Nuno Agostinho 

Sent: Tuesday, October 9, 2018 10:51:56 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] cTRAP: WARNINGS in package submission

Dear all,

I am the developer of cTRAP , a 
package that I recently submitted for approval to Bioconductor: 
https://github.com/Bioconductor/Contributions/issues/906 
.

The package makes use of ENCODE and L1000 datasets downloaded from the web and 
the examples for such functions include downloading some sample files. However, 
this makes R CMD check take more than 5 minutes and labels my package with 
WARNING. Should I simply mark the examples of "slow" functions with \dontrun? I 
do not think that is the optimal approach, but it is certainly the easiest 
solution to pass the 5 minute requirement of R CMD check.

Thank you for your time!

Best regards,
Nuno Agostinho
[[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: [Rd] R_ext/Altrep.h should be more C++-friendly

[Gabe Becker]

Michael,

Thanks for reaching out. This was brought up by Romaine Francois offline to
me as well. What he does as a workaround is


#define class klass
extern "C" {
  #include 
}
#undef class

While we consider changing Altrep.h, the above should work for you  in the
immediate term.

Let me know if it doesn't.

~G





On Mon, Oct 8, 2018 at 4:17 PM, Michael Sannella via R-devel <
r-devel@r-project.org> wrote:

> I am not able to #include "R_ext/Altrep.h" from a C++ file.  I think
> it needs two changes:
>
> 1. add the same __cplusplus check as most of the other header files:
> #ifdef  __cplusplus
> extern "C" {
> #endif
> ...
> #ifdef  __cplusplus
> }
> #endif
>
> 2. change the line
> R_new_altrep(R_altrep_class_t class, SEXP data1, SEXP data2);
>  to
> R_new_altrep(R_altrep_class_t cls, SEXP data1, SEXP data2);
>  since C++ doesn't like an argument named 'class'
>
>   ~~ Michael Sannella
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>


-- 
Gabriel Becker, Ph.D
Scientist
Bioinformatics and Computational Biology
Genentech Research

[[alternative HTML version deleted]]

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

[Bioc-devel] cTRAP: WARNINGS in package submission

[Nuno Agostinho]

Dear all,

I am the developer of cTRAP , a 
package that I recently submitted for approval to Bioconductor: 
https://github.com/Bioconductor/Contributions/issues/906 
. 

The package makes use of ENCODE and L1000 datasets downloaded from the web and 
the examples for such functions include downloading some sample files. However, 
this makes R CMD check take more than 5 minutes and labels my package with 
WARNING. Should I simply mark the examples of "slow" functions with \dontrun? I 
do not think that is the optimal approach, but it is certainly the easiest 
solution to pass the 5 minute requirement of R CMD check.

Thank you for your time!

Best regards,
Nuno Agostinho
[[alternative HTML version deleted]]

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

Re: [Rd] unexpected behavior of unzip with list=T and unzip=/usr/bin/unzip

[Tomas Kalibera]

Hi Paul,

thanks for the report. Fixed in R-devel 75417.

Best
Tomas

On 07/04/2018 10:08 PM, Paul Schrimpf wrote:

Hello,

I encountered some unexpected behavior of unzip when using info-zip's unzip
instead of R's internal program. Specifically, unzip("file.zip", list=TRUE,
unzip=/usr/bin/unzip) produces incorrect output if the zip archive has
filenames with spaces, and results in an error if the zip archive includes
an archive comment or file comments.

Here is some code to reproduce along with the attached files

## (mostly) expected behavior
res.intern <- unzip("noSpaces.zip",list=TRUE)
res.infozip <- unzip("noSpaces.zip",list=TRUE,unzip="/usr/bin/unzip")

identical(res.intern,res.infozip) ## will be false, but expected from
   ## documentation about dates
identical(res.infozip$Name,res.intern$Name) ## True
res.infozip$Length==res.intern$Length   ## TRUE
identical(res.infozip$Length,res.intern$Length) ## FALSE, because
 ## former numeric, later
integer

## More problematic cases
print(unzip("fileNameWithSpaces.zip",list=TRUE))
print(unzip("fileNameWithSpaces.zip",list=TRUE,unzip="/usr/bin/unzip"))
   ## read.table is used to parse output of unzip -l, and gets
   ## confused by extra spaces

print(unzip("withArchiveComment.zip",list=TRUE))
print(unzip("withArchiveComment.zip",list=TRUE,unzip="/usr/bin/unzip"))
   ## produces an error

print(unzip("entryComments.zip",list=TRUE))
print(unzip("entryComments.zip",list=TRUE,unzip="/usr/bin/unzip"))
   ## produces an error

Looking at the code for R's unzip, the basic problem is that it makes a
bunch of assumptions about the format of the output of "unzip -l"  that are
not always true and are not verified.

It's unclear to me whether R's unzip should be expected to be compatible
with all sorts of external unzip programs, so perhaps a sufficient solution
is simply to revise the documentation (which already mentions potential
problems  with dates and unzip, list=TRUE, and external programs).

Alternatively, R's unzip function could be changed to work with info-zip
unzip by :
(1) add "-ql" instead of just "-l" when list=TRUE to eliminate the printing
of comments
(2) not use read.table to parse the output of unzip, instead to something
like the following (which is an admittedly messy workaround)

 res <- if (WINDOWS)
 system2(unzip, c("-ql", shQuote(zipfile)), stdout = TRUE)
 else system2(unzip, c("-ql", shQuote(zipfile)), stdout = TRUE,
 env = c("TZ=UTC"))
 dashes <- grep("--",res)
 s <- dashes[1]+1
 l <- dashes[2]-1
 starts <- gregexpr("-+",res[dashes[1]])[[1]]
 ends <- gregexpr("[[:space:]]+",res[dashes[1]])[[1]]
 z <- data.frame(
 Name=sapply(res[s:l], function(x) {
   substr(x, starts[4], stop=nchar(x))
 }),
 Length=sapply(res[s:l], function(x) {
   as.numeric(substr(x, starts[1], stop=ends[1]))
 }),
 Date=sapply(res[s:l], function(x) {
   substr(x, starts[2], stop=ends[2])
 }),
 Time=sapply(res[s:l], function(x) {
   substr(x, starts[3], stop=ends[3])
 }),
 stringsAsFactors=FALSE
 )
 rownames(z) <- NULL

I can submit a patch if this is appropriate. I'm really not sure though
because I am new to R-devel. Also, this has the downsides of relying on the
behavior of info-zip unzip, which might change in future versions and is
unlikely to be the same for other external unzip programs. On the other
hand, the current code also relies on the behavior of info-zip unzip, but
also doesn't work in some cases.

Thanks,
Paul

P.S.

My sessionInfo is


sessionInfo()

R version 3.5.1 (2018-07-02)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Arch Linux

Matrix products: default
BLAS/LAPACK: /usr/lib/libopenblas_haswellp-r0.3.1.so

locale:
  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
  [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
LC_PAPER=en_US.UTF-8   LC_NAME=C
  [9] LC_ADDRESS=C   LC_TELEPHONE=C
LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

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

other attached packages:
[1] devtools_1.13.5

loaded via a namespace (and not attached):
[1] compiler_3.5.1 tools_3.5.1withr_2.1.2memoise_1.1.0
digest_0.6.15

And unzip -v

UnZip 6.00 of 20 April 2009, by Info-ZIP.  Maintained by C. Spieler.  Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for
details.

Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.

Compiled with gcc 

[Rd] Surprise with plot.lm()

[Peter Dalgaard via R-devel]

Here's a silly little stunt:

> Y <- rexp(10) ; x <- 1:10
> plot(lm(I(Y^.3)~x))
Hit  to see next plot: 
Hit  to see next plot: 
Error: $ operator is invalid for atomic vectors

The root cause is that the "AsIs" class lingers on the intercept passed to 
abline() via qqline(), so abline sees that it has been passed an object and 
uses coef() and coef.default() looks for object$coefficients, and... poof!

The immediate workaround is just to drop the I(), but as I() is frequently 
needed on the right hand side of formulas, this looks like a rather easy 
mistake to make, so it might be worth fixing, but how? 

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

[Rd] R_ext/Altrep.h should be more C++-friendly

[Michael Sannella via R-devel]

I am not able to #include "R_ext/Altrep.h" from a C++ file.  I think
it needs two changes:

1. add the same __cplusplus check as most of the other header files:
#ifdef  __cplusplus
extern "C" {
#endif
...
#ifdef  __cplusplus
}
#endif

2. change the line
R_new_altrep(R_altrep_class_t class, SEXP data1, SEXP data2);
 to
R_new_altrep(R_altrep_class_t cls, SEXP data1, SEXP data2);
 since C++ doesn't like an argument named 'class'

  ~~ Michael Sannella

[[alternative HTML version deleted]]

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

[Rd] bug with OutDec option and deferred_string altrep object

[Michael Sannella via R-devel]

While implementing R's new 'altrep' functionality in the TERR engine,
I discovered a bug in R's 'deferred_string' altrep object: it is not
using the correct value of the 'OutDec' option when it expands a
deferred_string.  See the following example:

R 3.5.1: (same results in R 3.6.0 devel engine built 10/5)
> options(scipen=0, OutDec=".")
> as.character(123.456)
[1] "123.456"
> options(scipen=-5, OutDec=",")
> as.character(123.456)
[1] "1,23456e+02"
> xx <- as.character(123.456)
> options(scipen=0, OutDec=".")
> xx
[1] "1.23456e+02"
>

In the example above, the variable 'xx' is set to a deferred_string
while OutDec is ','.  However, when the string is actually formatted
(when xx is printed), it uses the current option value OutDec='.' to
format the string.  I think that deferred_string should use the value
OutDec=',' from when as.character was called.

Note that the behavior is different with the 'scipen' option: The
deferred_string object records the scipen=-5 value when as.character
is called, and uses this value when xx is printed.  Looking at the
deferred_string object, it appears that CDR(R_altrep_data1()) is
set to a scalar integer containing the scipen value at the time the
deferred_string was created.

Ideally, the deferred_string object would save both the scipen and
OutDec option values.  I'd suggest saving these values as regular
pairlist values, say by setting the data1 field to pairlist(,
scipen=-5L, OutDec=',') for the value of xx above.  To save space, you
could avoid saving these values in the common case where scipen=0L,
OutDec='.'.  It would also be better if the data1 field was a
well-formed pairlist; the current value of the data1 field causes
R_inspect to segfault.

I understand that you probably wouldn't want to change the
deferred_string structure.  An alternative fix would be to avoid this
case by:
  1. Never create a deferred_string if OutDec is not '.'.
  2. When expanding an element of a deferred_string, temporarily set
OutDec to '.'.

  ~~ Michael Sannella

[[alternative HTML version deleted]]

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