Re: [Bioc-devel] TabixFileList() constructor broken in devel

[Martin Morgan]

On 12/29/2016 12:25 PM, Vincent Carey wrote:

A while ago Martin and I discussed the possibility of idempotence for
TabixFile ... this seemed
to make sense and so


TabixFile


function (file, index = paste(file, "tbi", sep = "."), ..., yieldSize =
NA_integer_)

{

if (is(file, "TabixFile"))

return(file)

tryCatch({

.io_check_exists(c(file, index))

}, error = function(err) {

stop(sprintf("TabixFile: %s", conditionMessage(err)),

call. = FALSE)

})

.RsamtoolsFile(.TabixFile, file, index, yieldSize = yieldSize,

...)

}




TabixFileList could behave similarly, working either from character paths,
or from

a list of TabixFile instances, or from a TabixFileList ... might be a
design practice to

promote for S4 programming



TabixFileList


function (file, index = paste(file, "tbi", sep = "."), ..., yieldSize =
NA_integer_)

{

index <- as.character(index)

.RsamtoolsFileList(file, index, ..., yieldSize = yieldSize,

class = "TabixFile")

}



On Thu, Dec 29, 2016 at 11:55 AM, Robert Castelo 
wrote:


hi Lori,

thanks for the clarification. if this is an intended change then i'd say
the documentation needs to be updated since, as i showed in my email
below, it currently says that for functions such as 'TabixFileList()'
the input 'file' argument should be a 'TabixFile' instance and not a
character vector.

this change also means the input is switching from a 'TabixFile'
instance to a 'character' vector, so pipelines or packages doing calls
to 'TabixFileList()' that have been passing 'TabixFile' instances as
arguments will have to update those calls to pass a character vector.

  i'd suggest that if there's no good reason to switch, it would be
safer to add the character vector as an additional possibility in the
input argument 'file', just as with 'countTabix()', and minimize
possible breaks of pipelines/packages using 'TabixFileList()'. i've
encountered this problem because my own package VariantFiltering calls
'TabixFileList()' although is not a big deal to fix it.

cheers,

robert.

On 28/12/2016 19:44, Shepherd, Lori wrote:


Thank you for bringing this to our attention. There were some updates
made a few weeks ago to the behavior and input of 'TabixFileList()' .
 Its current implementation will work with a character vector as
input.  I will investigate further into why this change was made and
if it needs to be addressed.


In the meantime:

TabixFileList(tbx)
will throw an ERROR, but you can still use the same file that was used
to create the TabixFile
tbx <- open(TabixFile(fl, yieldSize=100))
TabixFileList(fl)


The original behavior has been restored; both TabixFile() and 
TabixFileList() are idempotent. Sorry for introducing the bug.


Martin





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
Robert Castelo 
*Sent:* Wednesday, December 28, 2016 11:50:58 AM
*To:* bioc-devel@r-project.org
*Subject:* [Bioc-devel] TabixFileList() constructor broken in devel
hi,

the 'TabixFileList()' constructor in Rsamtools seems to be broken in
devel:

library(Rsamtools)
example(TabixFileList) ## which actually does not construct any
'TabixFileList'
TabixFileList(tbx)
Error in as.vector(x, "character") :
   cannot coerce type 'environment' to vector of type 'character'

while in release this works fine:

library(Rsamtools)
example(TabixFileList) ## which actually does not construct any
'TabixFileList'
TabixFileList(tbx)
TabixFileList of length 1
names(1): example.gtf.gz

the man page has not changed between devel and release and the current
description of the argument 'file' supports the use of a 'TabixFile'
instance as input:

 file: For TabixFile(), A character(1) vector to the tabix file
   path; can be remote (http://, ftp://). For ‘countTabix’, a
   character(1) or ‘TabixFile’ instance. For others, a
   ‘TabixFile’ instance.

please find below my session information for the devel run.

thanks!

robert.

sessionInfo()
R Under development (unstable) (2016-11-17 r71661)
Platform: x86_64-apple-darwin16.1.0 (64-bit)
Running under: macOS Sierra 10.12.2

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] stats4parallel  stats graphics  grDevices utils datasets
[8] methods   base

other attached packages:
  [1] Rsamtools_1.27.9  Biostrings_2.43.1 XVector_0.15.0
  [4] GenomicRanges_1.27.17 GenomeInfoDb_1.11.6 IRanges_2.9.14
  [7] S4Vectors_0.13.5  BiocGenerics_0.21.1 setwidth_1.0-4
[10] colorout_1.1-0

loaded via a namespace (and not attached):
[1] zlibbioc_1.21.0compiler_3.4.0 tools_3.4.0 BiocParallel_1.9.3
[5] bitops_1.0-6

Re: [Rd] seq.int/seq.default

[Mick Jordan]

On 1/4/17 8:15 AM, Mick Jordan wrote:

Here is another difference that I am guessing is unintended.

> y <- seq.int(1L, 3L, length.out=2)
> typeof(y)
[1] "double"
> x <- seq.default(1L, 3L, length.out=2)
> typeof(x)
[1] "integer"

The if (by == R_MissingArg) branch at line 842 doesn't contain a check 
for "all INTSXP" unlike the if (to == R_MissingArg) branch.


Mick

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

Re: [Rd] seq.int/seq.default

[Mick Jordan]

On 1/4/17 1:26 AM, Martin Maechler wrote:

Mick Jordan 
 on Tue, 3 Jan 2017 07:57:15 -0800 writes:

 > This is a message for someone familiar with the implementation.
 > Superficially the R code for seq.default and the C code for seq.int
 > appear to be semantically very similar. My question is whether, in fact,
 > it is intended that behave identically for all inputs.

Strictly speaking, "no":  As usual, RT?Manual (;-)

The help page says in the very first paragraph ('Description'):

   ‘seq’ is a standard generic with a default method.
   ‘seq.int’ is a primitive which can be much faster but has a few restrictions.

 > I have found two cases so far where they differ, first
 > that seq.int will coerce a character string to a real (via
 > Rf_asReal) whereas seq.default appears to coerce it to NA
 > and then throws an error:

 >> seq.default("2", "5")
 > Error in seq.default("2", "5") : 'from' cannot be NA, NaN or infinite
 >> seq.int("2", "5")
 > [1] 2 3 4 5
 >>

this may be a bit surprising (if one does _not_ look at the code),
indeed, notably because seq.int() is mentioned to have more
restrictions than seq() which here calls seq.default().
"Surprising" also when considering

> "2":"5"
[1] 2 3 4 5

and the documentation of ':' claims 'from:to' to be the same as
rep(from,to)  apart from the case of factors.

--- I am considering a small change in  seq.default()
which would make it work for this case, compatibly with ":" and seq.int().


 > and second, that the error messages for non-numeric arguments differ:

which I find fine... if the functions where meant to be
identical, we (the R developers) would be silly to have both,
notably as the ".int" suffix  has emerged as confusing the
majority of useRs (who don't read help pages).

Rather it has been meant as saying "internal" (including "fast") also for other
such R functions, but the suffix of course is a potential clash
with S3 method naming schemes _and_ the fact that 'int' is used
as type name for integer in other languages, notably C.

 > seq.default(to=quote(b), by=2)
 > Error in is.finite(to) : default method not implemented for type 'symbol'

which I find a very appropriate and helpful message

 > seq.int(to=quote(b), by=2)
 > Error in seq.int(to = quote(b), by = 2) :
 > 'to' cannot be NA, NaN or infinite

which is true, as well, and there's no "default method" to be
mentioned, but you are right that it would be nicer if the
message mentioned 'symbol' as well.
Thanks for the clarifications. It was surprising that seq.int supported 
more types than seq.default. I was expecting the reverse.


BTW, There are a couple of, admittedly odd, cases, exposed by brute 
force testing, where seq.int will actually return "missing", which I 
presume is not intended, and seq.default behaves differently, vis:


> seq.default(to=1,by=2)
[1] 1
> seq.int(to=1,by=2)

> > x <- seq.int(to=1,by=2)
> x
Error: argument "x" is missing, with no default

Lines 792 and 799 of seq.c return the incoming argument (as opposed to a 
value based on its coercion to double via asReal) and this can, as in 
the above example, be "missing".




 > Please reply off list.

[which I understand as that we should  CC you (which of course is
  netiquette to do)]


Yes

Thanks
Mick Jordan

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

[Bioc-devel] Code quality and bug reports

[Lluís Revilla]

Dear Guangchuang and all,

Quality of the packages has been a preoccupation of the project from
the  beginning  (see
https://stat.ethz.ch/pipermail/bioc-devel/2014-May/005810.html for
more references and other discussions about bug reports.) Despite not
being in a goal of the project, it is necessary to do a reproducible
research, which it is a goal: "To further scientific understanding by
producing high-quality documentation and reproducible research.".
Although it seems that this discussion appears periodically
Bioconductor I don't know any solution in the project.

I have never submitted a package to Bioconductor or CRAN, and I am
quite new to R (and is my first mail to the list), but one thing that
I keep thinking (before publishing a package) is the maintainability
of it. I don't know how much time/desires will I have to dedicate to a
package (if it is accepted) in the future, but at the same time I want
to make useful code to be used in further research beyond my own
project.

However the Bioconductor core team may be already too busy to deal
with the issues of all packages. Maybe it would be better to bring
CRAN's policy to orphan packages (see:
https://cran.r-project.org/src/contrib/Orphaned/README):

"Possible reasons for orphanizing a package:

1) The current maintainer actively wants to orphanize the package,
   e.g., due to no longer having time or interest to act as package
   maintainer.

2) Emails sent to the current maintainer by the CRAN admins bounced, or
   were not answered for longer periods of time.
"
Example of an orhpan package is clusterRepro.

To orphanize a package the current maintainer could post it here on
the devel list and ask for a maintainer on the support site, and it is
his/her decision to whom is passed the responsibility.
Otherwise, maybe the limit of time without answering mails/posts in
support could be 3 months/6 months. (I don't know the CRAN decision
when not answering mails)

Once the orphaned status is reached maybe however who wants could send
patches or take the maintenance of the package for another 3 months or
more.

This status would not make bugs easier to fix or control, but could
mark that a package is not in the best maintenance status.

Hope this helps,

Lluís



Date: Wed, 4 Jan 2017 15:38:53 +0800
From: "Yu, Guangchuang" 
To: bioc-devel 
Subject: [Bioc-devel] report package issue to Bioconductor
Message-ID:

Content-Type: text/plain; charset="UTF-8"

Dear all,

Some packages never updated after they publish a paper, and they just
ignore bug report.

I think we need somewhere, maybe on github, to post code review and
Bioconductor core team can take action if maintainer fail to fix issue.

Here is a quick look of the CorMut package:
https://gist.github.com/GuangchuangYu/91b3396c7e49ab42c565a9cda3c35e18.

There should be more issues than I can found with quick look of the source
code.

Best wishes,
Guangchuang
?
--
--~--~-~--~~~---~--~~
Guangchuang Yu, PhD Candidate
State Key Laboratory of Emerging Infectious Diseases
School of Public Health
The University of Hong Kong
Hong Kong SAR, China
www: https://guangchuangyu.github.io
-~--~~~~--~~--~--~---

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

Re: [Bioc-devel] How to get further assessment for newly submitted package?

[Martin Morgan]

On 01/04/2017 04:13 AM, Jurat Shayidin wrote:

Dear Lori :

I still didn't get any updated action from reviewer on our packages. We've
planned to complete package submission process by fixing possible issue
raised from Bioconductor team and proceed publication accordingly.we only
need brief, general evaluation on this package and make sure we can able to
do publication. Any chance to speed up package review process please ?
Thank you


It has been 12 days since you submitted your package, which is not a 
long time. We aim for a first review in two weeks. As the reviewer, I 
took some days off for the holiday season; you might expect a review at 
the end of next week.


Martin



Best regards :
Jurat

On Wed, Dec 28, 2016 at 1:43 PM, Shepherd, Lori <
lori.sheph...@roswellpark.org> wrote:



You will receive feedback soon.  Reviewers are assigned multiple packages
and will review them in the order they were received.  There is also a
delay because of the holidays season.


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 Jurat
Shayidin 
*Sent:* Wednesday, December 28, 2016 6:58:15 AM
*To:* bioc-devel@r-project.org
*Subject:* [Bioc-devel] How to get further assessment for newly submitted
package?

Dear BiocDevel, Bioconductor team :

I want to know how can I get further assessment and assist for my package
to Bioconductor Project. I've created issue to
https://github.com/Bioconductor/Contributions and system marked as
"Review

GitHub - Bioconductor/Contributions: Contribute Packages ...

github.com
README.md Table of Contents. Contributing a Bioconductor Package; Starting
the Submission Process; What to Expect; Adding a Web Hook; Submitting
Related Packages


in Progress", package reviewer was assigned. Since my submission, review
status still  is not updated, haven't receive any update message both from
system and reviewers. I doubt that's because of holiday session, reviewers
haven't ready for fresh evaluation. I believe Bioconductor packages
submission is lengthy process, so I am eager to optimize my packages to
make acceptance by Bioconductor project, getting brief assessment on my
package is needed. Any chance to get further evaluation on my packages that
I possibly work on during this holiday ? Thanks a lot

Best regards :
--
Jurat Shahidin

Dipartimento di Elettronica, Informazione e Bioingegneria
Politecnico di Milano
Piazza Leonardo da Vinci 32 - 20133 Milano, Italy
Mobile : +39 3279366608 <+39%20327%20936%206608>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Bioc-devel -- Bioconductor Developers' List - Homepage - SfS

stat.ethz.ch
The Developers' List for the Bioconductor project. Used for release and
development issues related to release. To see the collection of prior
postings to the list ...



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.








This email message may contain legally privileged and/or...{{dropped:2}}

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

Re: [Rd] seq.int/seq.default

[Martin Maechler]

> Mick Jordan 
> on Tue, 3 Jan 2017 07:57:15 -0800 writes:

> This is a message for someone familiar with the implementation.
> Superficially the R code for seq.default and the C code for seq.int 
> appear to be semantically very similar. My question is whether, in fact, 
> it is intended that behave identically for all inputs. 

Strictly speaking, "no":  As usual, RT?Manual (;-)

The help page says in the very first paragraph ('Description'):

  ‘seq’ is a standard generic with a default method.
  ‘seq.int’ is a primitive which can be much faster but has a few restrictions. 

> I have found two cases so far where they differ, first
> that seq.int will coerce a character string to a real (via
> Rf_asReal) whereas seq.default appears to coerce it to NA
> and then throws an error:

>> seq.default("2", "5")
> Error in seq.default("2", "5") : 'from' cannot be NA, NaN or infinite
>> seq.int("2", "5")
> [1] 2 3 4 5
>> 

this may be a bit surprising (if one does _not_ look at the code),
indeed, notably because seq.int() is mentioned to have more
restrictions than seq() which here calls seq.default().
"Surprising" also when considering

   > "2":"5"
   [1] 2 3 4 5

and the documentation of ':' claims 'from:to' to be the same as
rep(from,to)  apart from the case of factors.

--- I am considering a small change in  seq.default()
which would make it work for this case, compatibly with ":" and seq.int().


> and second, that the error messages for non-numeric arguments differ:

which I find fine... if the functions where meant to be
identical, we (the R developers) would be silly to have both,
notably as the ".int" suffix  has emerged as confusing the
majority of useRs (who don't read help pages).

Rather it has been meant as saying "internal" (including "fast") also for other
such R functions, but the suffix of course is a potential clash
with S3 method naming schemes _and_ the fact that 'int' is used
as type name for integer in other languages, notably C. 

> seq.default(to=quote(b), by=2)
> Error in is.finite(to) : default method not implemented for type 'symbol'

which I find a very appropriate and helpful message

> seq.int(to=quote(b), by=2)
> Error in seq.int(to = quote(b), by = 2) :
> 'to' cannot be NA, NaN or infinite

which is true, as well, and there's no "default method" to be
mentioned, but you are right that it would be nicer if the
message mentioned 'symbol' as well.

> Please reply off list.

[which I understand as that we should  CC you (which of course is
 netiquette to do)]

Martin Maechler
ETH Zurich

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

Re: [Bioc-devel] How to get further assessment for newly submitted package?

[Jurat Shayidin]

Dear Lori :

I still didn't get any updated action from reviewer on our packages. We've
planned to complete package submission process by fixing possible issue
raised from Bioconductor team and proceed publication accordingly.we only
need brief, general evaluation on this package and make sure we can able to
do publication. Any chance to speed up package review process please ?
Thank you

Best regards :
Jurat

On Wed, Dec 28, 2016 at 1:43 PM, Shepherd, Lori <
lori.sheph...@roswellpark.org> wrote:

>
> You will receive feedback soon.  Reviewers are assigned multiple packages
> and will review them in the order they were received.  There is also a
> delay because of the holidays season.
>
>
> 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 Jurat
> Shayidin 
> *Sent:* Wednesday, December 28, 2016 6:58:15 AM
> *To:* bioc-devel@r-project.org
> *Subject:* [Bioc-devel] How to get further assessment for newly submitted
> package?
>
> Dear BiocDevel, Bioconductor team :
>
> I want to know how can I get further assessment and assist for my package
> to Bioconductor Project. I've created issue to
> https://github.com/Bioconductor/Contributions and system marked as
> "Review
> 
> GitHub - Bioconductor/Contributions: Contribute Packages ...
> 
> github.com
> README.md Table of Contents. Contributing a Bioconductor Package; Starting
> the Submission Process; What to Expect; Adding a Web Hook; Submitting
> Related Packages
>
>
> in Progress", package reviewer was assigned. Since my submission, review
> status still  is not updated, haven't receive any update message both from
> system and reviewers. I doubt that's because of holiday session, reviewers
> haven't ready for fresh evaluation. I believe Bioconductor packages
> submission is lengthy process, so I am eager to optimize my packages to
> make acceptance by Bioconductor project, getting brief assessment on my
> package is needed. Any chance to get further evaluation on my packages that
> I possibly work on during this holiday ? Thanks a lot
>
> Best regards :
> --
> Jurat Shahidin
>
> Dipartimento di Elettronica, Informazione e Bioingegneria
> Politecnico di Milano
> Piazza Leonardo da Vinci 32 - 20133 Milano, Italy
> Mobile : +39 3279366608 <+39%20327%20936%206608>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> Bioc-devel -- Bioconductor Developers' List - Homepage - SfS
> 
> stat.ethz.ch
> The Developers' List for the Bioconductor project. Used for release and
> development issues related to release. To see the collection of prior
> postings to the list ...
>
>
>
> 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.




-- 
Jurat Shahidin

Dipartimento di Elettronica, Informazione e Bioingegneria
Politecnico di Milano
Piazza Leonardo da Vinci 32 - 20133 Milano, Italy
Mobile : +39 3279366608

[[alternative HTML version deleted]]

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