[Bioc-devel] News: Extended submission deadline for EuroBioc2020

[Kevin RUE]

Hello community!

The EuroBioc2020 submission deadline is extended to Monday, November 16th!

The organising committee welcomes submissions for talks, workshops,
posters, and birds-of-a-feather session topics.

The scope for submissions is far from limited to Bioconductor packages; we
welcome contributions as workflows, live demonstrations, interactive Shiny
applications, data visualisations, new concepts, packages in development,
calls for feedback and collaborations, … and all the many more hidden gems
produced by the community; surprise us!

Submit your contribution here!

https://openreview.net/group?id=bioconductor.org/EuroBioC/2020/Conference

We look forward to seeing you all online for this stimulating and
community-driven conference!

--

The EuroBioc2020 organising committee

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Build error for pwrEWAS

[Kevin RUE]

Hi Stefan,

Pasting the reply from Mike Smith, a few hours ago, in the email thread
"Error in building vignette for previously stable version":

This looks like the same problem a few others have reported.  The latest
> advice was to wait for BiocStyle to be updated to reflect changes in
> rmarkdown, so you don't need to do anything for now:
> https://stat.ethz.ch/pipermail/bioc-devel/2019-December/015870.html


Best,
Kevin

On Thu, Dec 5, 2019 at 4:23 PM Graw, Stefan H  wrote:

> Dear bioc-devel team,
>
> I have received a notification that the build of my package (without any
> changes) resulted in the following error. I would appreciate some
> assistance, because I don't know what is causing the error.
>
> Thanks,
> Stefan
>
>
> ! LaTeX Error: Command \VerbBar already defined.
>Or name \end... illegal, see p.192 of the manual.
>
> Error: processing vignette 'pwrEWAS.Rmd' failed with diagnostics:
> Failed to compile pwrEWAS.tex. See https://yihui.name/tinytex/r/#debugging
> for debugging tips. See pwrEWAS.log for more info.
> --- failed re-building 'pwrEWAS.Rmd'
>
> SUMMARY: processing the following file failed:
>   'pwrEWAS.Rmd'
>
> Error: Vignette re-building failed.
> Execution halted
>
> --
> Confidentiality Notice: This e-mail message, including a...{{dropped:10}}
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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

[Bioc-devel] Fwd: TVTB problems reported in the Multiple platform build/check report for BioC 3.10

[Kevin RUE]

Hi,

I've been getting a weird Latex-related error on the daily build recently,
_although I haven't updated the package in ages_.
https://master.bioconductor.org/checkResults/3.10/bioc-LATEST/TVTB/malbec1-buildsrc.html

I'm guessing some LaTeX package must have been updated recently and causes
trouble.
I'll have a look now, but any insights are welcome!

Kevin

I could switch the vignette over to PDF, but I prefer

-- Forwarded message -
From: 
Date: Wed, Dec 4, 2019 at 8:00 PM
Subject: TVTB problems reported in the Multiple platform build/check report
for BioC 3.10
To: 


[This is an automatically generated email. Please don't reply.]

Hi TVTB maintainer,

According to the Multiple platform build/check report for BioC 3.10,
the TVTB package has the following problem(s):

  o ERROR for 'R CMD build' on malbec1. See the details here:

https://master.bioconductor.org/checkResults/3.10/bioc-LATEST/TVTB/malbec1-buildsrc.html

Please take the time to address this by committing and pushing
changes to your package at git.bioconductor.org

Notes:

  * This was the status of your package at the time this email was sent to
you.
Given that the online report is updated daily (in normal conditions) you
could see something different when you visit the URL(s) above,
especially if
you do so several days after you received this email.

  * It is possible that the problems reported in this report are false
positives,
either because another package (from CRAN or Bioconductor) breaks your
package (if yours depends on it) or because of a Build System problem.
If this is the case, then you can ignore this email.

  * Please check the report again 24h after you've committed your changes
to the
package and make sure that all the problems have gone.

  * If you have questions about this report or need help with the
maintenance of your package, please use the Bioc-devel mailing list:

  https://bioconductor.org/help/mailing-list/

(all package maintainers are requested to subscribe to this list)

For immediate notification of package build status, please
subscribe to your package's RSS feed. Information is at:

https://bioconductor.org/developers/rss-feeds/

Thanks for contributing to the Bioconductor project!

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] scanVCF: _DNAencode(): invalid DNAString input character: '1'

[Kevin RUE]

Thanks for the update Valerie.
Needless to say, I ran R CMD check locally yesterday, and it crashed with
the same issue.

Naive question, without looking into the original issue: is it purely a
programming issue, or is there a chance that our (seqCAT and TVTB) VCF
files need to be updated to match any kind of new standard?

Best,
Kevin

On Wed, Jan 9, 2019 at 3:49 PM Obenchain, Valerie <
valerie.obench...@roswellpark.org> wrote:

> The problem is related to a change I made to handle buffer overflow:
>
> https://github.com/Bioconductor/VariantAnnotation/issues/19
>
> This clearly doesn't work for all cases, thanks for reporting the
> problems with seqCAT and TVTB. I've reverted the change so your packages
> will build and will re-think the fix.
>
> Valerie
>
>
> On 1/8/19 10:45 AM, Kevin RUE wrote:
> > Hi all,
> >
> > Same kind of error for my TVTB package
> > (
> https://master.bioconductor.org/checkResults/3.8/bioc-LATEST/TVTB/malbec1-checksrc.html).
>
> >
> > I'll run R CMD check locally ASAP to see whether I need to update TVTB
> > or if it's something upstream.
> >
> > Best,
> > Kevin
> >
> > On Tue, Jan 8, 2019 at 5:05 PM Obenchain, Valerie
> >  > <mailto:valerie.obench...@roswellpark.org>> wrote:
> >
> > Hi Erik,
> >
> > There have been a few changes to VariantAnnotation lately. I'll take
> a
> > look at seqCAT and get back to you.
> >
> > Valerie
> >
> >
> > On 1/8/19 6:07 AM, Erik Fasterius wrote:
> >  > I recently started to get a weird error when building the
> > vignette to my seqCAT package, related to a VCF file I use as
> > example data. The error itself looks like this:
> >  >
> >  > scanVcf: _DNAencode(): invalid DNAString input character: '1'
> > (byte value 49) path: (...)/seqCAT/extdata/example.vcf.gz
> >  >
> >  > I can also reproduce the error by a simple
> > `VariantAnnotation::readVCF()` call. It has worked fine until the
> > latest devel-updates of other Bioconductor packages, so I assumed it
> > was some new change that caused the error, but I cannot find
> > anything in the NEWS seemingly related to this. I also tried to
> > troubleshoot by manually inspecting my file, and it seems that the
> > ANN field is the culprit; I can read the VCF if I remove the
> > entirety of the INFO column. I cannot, however, seem to locate the
> > erroneous data itself.
> >  >
> >  > Does anybody have any idea what causes this?
> >  >
> >  >   [[alternative HTML version deleted]]
> >  >
> >  > ___
> >  > Bioc-devel@r-project.org <mailto: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.
> > ___
> > Bioc-devel@r-project.org <mailto: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] scanVCF: _DNAencode(): invalid DNAString input character: '1'

[Kevin RUE]

Hi all,

Same kind of error for my TVTB package (
https://master.bioconductor.org/checkResults/3.8/bioc-LATEST/TVTB/malbec1-checksrc.html
).
I'll run R CMD check locally ASAP to see whether I need to update TVTB or
if it's something upstream.

Best,
Kevin

On Tue, Jan 8, 2019 at 5:05 PM Obenchain, Valerie <
valerie.obench...@roswellpark.org> wrote:

> Hi Erik,
>
> There have been a few changes to VariantAnnotation lately. I'll take a
> look at seqCAT and get back to you.
>
> Valerie
>
>
> On 1/8/19 6:07 AM, Erik Fasterius wrote:
> > I recently started to get a weird error when building the vignette to my
> seqCAT package, related to a VCF file I use as example data. The error
> itself looks like this:
> >
> > scanVcf: _DNAencode(): invalid DNAString input character: '1' (byte
> value 49) path: (...)/seqCAT/extdata/example.vcf.gz
> >
> > I can also reproduce the error by a simple
> `VariantAnnotation::readVCF()` call. It has worked fine until the latest
> devel-updates of other Bioconductor packages, so I assumed it was some new
> change that caused the error, but I cannot find anything in the NEWS
> seemingly related to this. I also tried to troubleshoot by manually
> inspecting my file, and it seems that the ANN field is the culprit; I can
> read the VCF if I remove the entirety of the INFO column. I cannot,
> however, seem to locate the erroneous data itself.
> >
> > Does anybody have any idea what causes this?
> >
> >   [[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.
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] 80% of man pages must have runnable examples (package with numerous Shiny apps)

[Kevin RUE]

Glad to be of help!

Nice package too! I managed to install it and give it a run!

Best wishes,
Kevin

On Wed, Nov 21, 2018 at 4:29 PM L Rutter 
wrote:

> Hi Lori and Kevin:
>
> Thank you for your helpful responses! I was able to use "if
> (interactive()) { ... }" format and return the appDir object for the
> user. Thanks again!
>
> Lindsay
> On Mon, Nov 19, 2018 at 3:02 PM Kevin RUE  wrote:
> >
> > Hi Lindsay,
> >
> > Check out https://github.com/csoneson/iSEE/blob/master/R/iSEE-main.R
> function "iSEE" for an example of both the function return value, and the
> man page.
> >
> > First, I would suggest that your function _returns_ the "appDir" object
> to the user, and that you leave it to the user to call "shiny::runApp" with
> options appropriate to their system or preferences (e.g
> launch.browser=FALSE, port=1234, etc).
> >
> > Second, for the man page, you don't have to put the _entire_ @example
> block inside \dontrun{}. You can put everything that doesn't launch the
> Shiny app outside the \dontrun{} block and only put the one "shiny" line
> inside the \dontrun{}. The one line will represent less than 80% of the man
> page.
> >
> > However, even better, you can avoid the \dontrun{} option altogether and
> put the "shiny" statement within a "if (interactive()) { ... }" block.
> >
> > So adapting you existing code, I would have
> > #' @examples
> > #' # Example 1: Create an interactive litre plot for the logged data
> using
> > #' # default background of hexagons.
> > #'
> > #' data(soybean_ir_sub)
> > #' data(soybean_ir_sub_metrics)
> > #' soybean_ir_sub_log <- soybean_ir_sub
> > #' soybean_ir_sub_log[,-1] <- log(soybean_ir_sub[,-1]+1)
> > #' if (interactive()){
> > #' plotLitreApp(data = soybean_ir_sub_log, dataMetrics =
> soybean_ir_sub_metrics)
> > #' }
> > #'
> > #' # Example 2: Repeat the same process, only now plot background data as
> > #' # individual points. Note this may be too slow now that all points
> are drawn
> > #' # in the background.
> > #' if (interactive()){
> > #' plotLitreApp(data = soybean_ir_sub_log, dataMetrics =
> soybean_ir_sub_metrics,
> > #' option = "allPoints", pointColor = "red")
> > #' }
> >
> > However, once more, I suggest that you return "appDir", and you would
> then have something like:
> > #' app <- plotLitreApp(data = soybean_ir_sub_log, dataMetrics =
> soybean_ir_sub_metrics)
> > #' if (interactive()){
> > #'shiny::runApp(app, [options defined by your user])
> > #' }
> >
> > I hope this helps. Otherwise, let me know and I can chime in the review
> of your package
> >
> > Best wishes
> > Kevin
> >
> > On Mon, Nov 19, 2018 at 7:00 PM Shepherd, Lori <
> lori.sheph...@roswellpark.org> wrote:
> >>
> >> Submit with the dontrun{} and temporarily ignore the ERROR -  when
> submitting please reference the explanation below.  Your reviewer could
> provide more information and will decide how to proceed -  generally
> examples will be run manually to check for accuracy and an exception can be
> made.
> >>
> >>
> >> 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 L
> Rutter 
> >> Sent: Monday, November 19, 2018 1:49:50 PM
> >> To: bioc-devel@r-project.org
> >> Subject: [Bioc-devel] 80% of man pages must have runnable examples
> (package with numerous Shiny apps)
> >>
> >> Hello all:
> >>
> >> I am planning to submit a package to Bioconductor and have one last
> >> item from BiocCheck (error, warning, note) I have been unable to
> >> resolve:
> >>
> >> ERROR: At least 80% of man pages documenting exported objects must
> >> have runnable examples. The following pages do not: plotLitreApp.Rd,
> >> plotPCPApp.Rd, plotSMApp.Rd, plotVolcanoApp.Rd
> >>
> >> I have 18 man pages (9 function-related, 8 data-related, and 1
> >> package-related). Of these, 4 of the function-related man pages (the
> >> ones listed in the ERROR) are Shiny applications of the following
> >> format:
> >>
> >> appDir <- system.file("shiny-exampl

Re: [Bioc-devel] 80% of man pages must have runnable examples (package with numerous Shiny apps)

[Kevin RUE]

Hi Lindsay,

Check out https://github.com/csoneson/iSEE/blob/master/R/iSEE-main.R
function "iSEE" for an example of both the function return value, and the
man page.

First, I would suggest that your function _returns_ the "appDir" object to
the user, and that you leave it to the user to call "shiny::runApp" with
options appropriate to their system or preferences (e.g
launch.browser=FALSE, port=1234, etc).

Second, for the man page, you don't have to put the _entire_ @example block
inside \dontrun{}. You can put everything that doesn't launch the Shiny app
outside the \dontrun{} block and only put the one "shiny" line inside the
\dontrun{}. The one line will represent less than 80% of the man page.

However, even better, you can avoid the \dontrun{} option altogether and
put the "shiny" statement within a "if (interactive()) { ... }" block.

So adapting you existing code, I would have
#' @examples
#' # Example 1: Create an interactive litre plot for the logged data using
#' # default background of hexagons.
#'
#' data(soybean_ir_sub)
#' data(soybean_ir_sub_metrics)
#' soybean_ir_sub_log <- soybean_ir_sub
#' soybean_ir_sub_log[,-1] <- log(soybean_ir_sub[,-1]+1)
#' if (interactive()){
#' plotLitreApp(data = soybean_ir_sub_log, dataMetrics =
soybean_ir_sub_metrics)
#' }
#'
#' # Example 2: Repeat the same process, only now plot background data as
#' # individual points. Note this may be too slow now that all points are
drawn
#' # in the background.
#' if (interactive()){
#' plotLitreApp(data = soybean_ir_sub_log, dataMetrics =
soybean_ir_sub_metrics,
#' option = "allPoints", pointColor = "red")
#' }

However, once more, I suggest that you return "appDir", and you would then
have something like:
#' app <- plotLitreApp(data = soybean_ir_sub_log, dataMetrics =
soybean_ir_sub_metrics)
#' if (interactive()){
#'shiny::runApp(app, [options defined by your user])
#' }

I hope this helps. Otherwise, let me know and I can chime in the review of
your package

Best wishes
Kevin

On Mon, Nov 19, 2018 at 7:00 PM Shepherd, Lori <
lori.sheph...@roswellpark.org> wrote:

> Submit with the dontrun{} and temporarily ignore the ERROR -  when
> submitting please reference the explanation below.  Your reviewer could
> provide more information and will decide how to proceed -  generally
> examples will be run manually to check for accuracy and an exception can be
> made.
>
>
> 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 L Rutter
> 
> Sent: Monday, November 19, 2018 1:49:50 PM
> To: bioc-devel@r-project.org
> Subject: [Bioc-devel] 80% of man pages must have runnable examples
> (package with numerous Shiny apps)
>
> Hello all:
>
> I am planning to submit a package to Bioconductor and have one last
> item from BiocCheck (error, warning, note) I have been unable to
> resolve:
>
> ERROR: At least 80% of man pages documenting exported objects must
> have runnable examples. The following pages do not: plotLitreApp.Rd,
> plotPCPApp.Rd, plotSMApp.Rd, plotVolcanoApp.Rd
>
> I have 18 man pages (9 function-related, 8 data-related, and 1
> package-related). Of these, 4 of the function-related man pages (the
> ones listed in the ERROR) are Shiny applications of the following
> format:
>
> appDir <- system.file("shiny-examples", "plotLitreApp", package =
> "bigPint")
> shiny::runApp(appDir, display.mode = "normal")
>
> If I do not have \dontrun{} around these shiny app examples, then R
> CMD check permanently halts on the "checking examples..." step. If I
> do have \dontrun{} around these shiny app examples, then R CMD
> BiocCheck gives me the error above. My question is: What is the
> recommended procedure in such a situation where the package is being
> prepared for Bioconductor submission?
>
> An example of one script causing the error can be found at:
> https://github.com/lrutter/bigPint/blob/master/R/plotLitreApp.R
>
> Thank you for any advice!
> Lindsay
>
> ___
> 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
>

[[alternative HTML version deleted]]

Re: [Bioc-devel] Several vignettes with links between them

[Kevin RUE]

Hi David,

First off, I'd recommend introducing non-crucial changes like this one on
the devel branch (3.9). The devel branch is the developers' primary
playground. If you _really_ think that users can't live without those
vignette updates before the next release, then you can always `git
cherry-pick` (https://git-scm.com/docs/git-cherry-pick) the commits from
the devel branch and apply them to the release branch. Just triple-check
before pushing anything to the Bioconductor Git repository that you're not
introducing any bug (...which is why the release branch it is recommended
to only _fix_ bugs on the release branch).

Then, to answer your questions, I'm sure there are several examples of
packages that use links between their multiple vignettes. Here's my
(biased) suggestion of an example :
https://github.com/csoneson/iSEE/blob/master/vignettes/basic.Rmd#L216
For the result, see:
http://bioconductor.org/packages/release/bioc/vignettes/iSEE/inst/doc/basic.html


Best,
Kevin

On Wed, Nov 14, 2018 at 6:13 AM David Jimenez-Morales 
wrote:

> Dear all,
>
> I am working on creating several vignettes for my recently released package
> (artMS), instead of having only a long one (as suggested by the bioc
> reviewer). Two questions:
>
>- Is there a way to link vignettes between themselves? For example, if I
>have 3 new vignettes, let’s say
>
> vignettes/overviewQuickStart.Rmd
> vignettes/details01.Rmd
> vignettes/details02.Rmd
>
> and I want to add links in overview.Rmd to details01.Rmd and details02.Rmd…
> is this possible?
>
>- Is ok if I include this improvement in the RELEASE_3_8 branch?
>
> Thanks a lot!
> David
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] EXTERNAL: Question about Wercker continuous integration

[Kevin RUE]

Thanks Marcel, it works!

After clearing the cache (Wercker > Project > Options > Cache > "Clear
cache" button), R CMD check now works perfectly on Wercker.
Indeed, I think I initially used an older box, and didn't realise that the
cached box was being fetched instead of downloading the more recent one.

Many many thanks for the time and headache saved!

Best wishes,
Kevin


On Tue, Mar 20, 2018 at 11:52 PM, Marcel Ramos <marcel.ra...@roswellpark.org
> wrote:

> Hi Kevin,
>
> My hunch is that the image that you're working with is old. If you're
> working with an
> older image, you could run into that problem with different R versions
> used to install 'backports'.
>
> I would first ensure that I'm working with a clean image by stopping any
> active containers, removing them, and then doing `docker rmi` to remove
> the `bioconductor/devel_core2` image.
>
> Pull a clean image from docker hub and run `wercker build` with your
> `wercker.yml` file.
>
> Any new changes made by your `yml` file can be saved to a different image
> by doing
> `docker commit`.
> See: https://stackoverflow.com/questions/26322247/docker-
> revert-changes-to-container
>
> This allows you to preserve the `devel_core2` image as it was downloaded
> and try again with
> an updated 'wercker.yml' file.
>
> PS. A correction to the `wecker.yml` file:
>
> ```
> build:
>   steps:
> - script:
> name: Install devtools
> code: R -e "install.packages(c('devtools', 'backports'))"
> - jimhester/r-dependencies
> - jimhester/r-check
> - jimhester/r-coverage
> ```
>
> Also, the EXTERNAL tag is generated by the Roswell Park email system.
>
>
> Best regards,
>
> Marcel
>
>
>
>
> On 03/20/2018 05:14 PM, Kevin RUE wrote:
>
> Hi Marcel,
>
> Thanks for the reply. I tried your `wercker.yml` file (exactly as is),
> and still got the same issue:
>
> * creating vignettes ... ERROR
> Error: processing vignette 'MyPackage-vignette.Rmd' failed with
> diagnostics:
> package ‘backports’ was installed by an R version with different
> internals; it needs to be reinstalled for use with this R version
> Execution halted
> Error: Command failed (1)
> In addition: Warning message:
> `cleanup` is deprecated
> Execution halted
> Check Failed, dumping logs
> find: ‘./*.Rcheck’: No such file or directory
> failed: Check Failed
>
> I'll leave it be for now, and see if I can get it to work with the new
> release in April.
>
> Also, did my email really arrive as  "EXTERNAL" to the bioc-devel mailing
> list? That would be odd, I sent it from my bioc-devel registered email
> address :/
>
> Kind regards,
> Kevin
>
> On Tue, Mar 20, 2018 at 5:03 PM, Marcel Ramos <
> marcel.ra...@roswellpark.org> wrote:
>
>> Hi Kevin,
>>
>> Being that I am unable to fully reproduce the issue, I can only say that
>> I have been successful in running the steps in the Wercker build for a
>> different package.
>>
>> Please do a *clean* pull of the Bioconductor image from docker hub by
>> removing any stale images
>> first.
>>
>> Here is the wercker.yml that I used:
>>
>> >> wercker build --docker-local
>>
>> box: bioconductor/devel_core2
>>
>> build:
>>   steps:
>> - script:
>> name: Install devtools
>> code: R -e "install.packages('devtools')"
>> - jimhester/r-dependencies:
>> cran_dependencies: backports
>> - jimhester/r-check
>> - jimhester/r-coverage
>>
>>
>> *Note:*I removed the r-lint step because it was having some issues with
>> xml.
>>
>>
>> Regards,
>>
>> Marcel
>>
>>
>> On 03/16/2018 07:53 AM, Kevin RUE wrote:
>> > Dear all,
>> >
>> > I'm usually a big Travis CI fan, but I'm having a go at Wercker, using
>> the
>> > bioconductor/devel_core2 docker (I have also tried the rocker 'parent'
>> ones
>> > without further success).
>> > I am running into the following issue:
>> >
>> > [...]
>> > * creating vignettes ... ERROR
>> > Error: processing vignette 'NewPackage-vignette.Rmd' failed with
>> > diagnostics:
>> > package ‘backports’ was installed by an R version with different
>> internals;
>> > it needs to be reinstalled for use with this R version
>> > Execution halted
>> > Error: Command failed (1)
>> > In addition: Warning message:
>> > `cleanup` is deprecated
>> > Execution halted
>> > Check Failed, dumping logs
&

Re: [Bioc-devel] EXTERNAL: Question about Wercker continuous integration

[Kevin RUE]

Hi Marcel,

Thanks for the reply. I tried your `wercker.yml` file (exactly as is), and
still got the same issue:

* creating vignettes ... ERROR
Error: processing vignette 'MyPackage-vignette.Rmd' failed with diagnostics:
package ‘backports’ was installed by an R version with different internals;
it needs to be reinstalled for use with this R version
Execution halted
Error: Command failed (1)
In addition: Warning message:
`cleanup` is deprecated
Execution halted
Check Failed, dumping logs
find: ‘./*.Rcheck’: No such file or directory
failed: Check Failed

I'll leave it be for now, and see if I can get it to work with the new
release in April.

Also, did my email really arrive as  "EXTERNAL" to the bioc-devel mailing
list? That would be odd, I sent it from my bioc-devel registered email
address :/

Kind regards,
Kevin

On Tue, Mar 20, 2018 at 5:03 PM, Marcel Ramos <marcel.ra...@roswellpark.org>
wrote:

> Hi Kevin,
>
> Being that I am unable to fully reproduce the issue, I can only say that
> I have been successful in running the steps in the Wercker build for a
> different package.
>
> Please do a *clean* pull of the Bioconductor image from docker hub by
> removing any stale images
> first.
>
> Here is the wercker.yml that I used:
>
> >> wercker build --docker-local
>
> box: bioconductor/devel_core2
>
> build:
>   steps:
> - script:
> name: Install devtools
> code: R -e "install.packages('devtools')"
> - jimhester/r-dependencies:
> cran_dependencies: backports
> - jimhester/r-check
> - jimhester/r-coverage
>
>
> *Note:*I removed the r-lint step because it was having some issues with
> xml.
>
>
> Regards,
>
> Marcel
>
>
> On 03/16/2018 07:53 AM, Kevin RUE wrote:
> > Dear all,
> >
> > I'm usually a big Travis CI fan, but I'm having a go at Wercker, using
> the
> > bioconductor/devel_core2 docker (I have also tried the rocker 'parent'
> ones
> > without further success).
> > I am running into the following issue:
> >
> > [...]
> > * creating vignettes ... ERROR
> > Error: processing vignette 'NewPackage-vignette.Rmd' failed with
> > diagnostics:
> > package ‘backports’ was installed by an R version with different
> internals;
> > it needs to be reinstalled for use with this R version
> > Execution halted
> > Error: Command failed (1)
> > In addition: Warning message:
> > `cleanup` is deprecated
> > Execution halted
> > Check Failed, dumping logs
> > find: ‘./*.Rcheck’: No such file or directory
> > failed: Check Failed
> >
> > I've tried adding a task that re-installs the `backports` package from
> > source (CRAN), but I still get the same error.
> >
> > My wercker.yml looks like:
> > box: bioconductor/devel_core2
> > build:
> > steps:
> > - script:
> > name: Install devtools
> > code: R -e "install.packages('devtools')"
> > - script:
> > name: Install backports
> > code: R -e "install.packages('backports')"
> > - jimhester/r-dependencies
> > - jimhester/r-check
> > - jimhester/r-lint
> > - jimhester/r-coverage
> >
> >
> >
> > Any help/advice/experience with Wercker would be greatly appreciated!
> >
> > Best wishes,
> > Kevin
> >
> >   [[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...{{dropped:4}}
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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

[Bioc-devel] Question about Wercker continuous integration

[Kevin RUE]

Dear all,

I'm usually a big Travis CI fan, but I'm having a go at Wercker, using the
bioconductor/devel_core2 docker (I have also tried the rocker 'parent' ones
without further success).
I am running into the following issue:

[...]
* creating vignettes ... ERROR
Error: processing vignette 'NewPackage-vignette.Rmd' failed with
diagnostics:
package ‘backports’ was installed by an R version with different internals;
it needs to be reinstalled for use with this R version
Execution halted
Error: Command failed (1)
In addition: Warning message:
`cleanup` is deprecated
Execution halted
Check Failed, dumping logs
find: ‘./*.Rcheck’: No such file or directory
failed: Check Failed

I've tried adding a task that re-installs the `backports` package from
source (CRAN), but I still get the same error.

My wercker.yml looks like:
box: bioconductor/devel_core2
build:
steps:
- script:
name: Install devtools
code: R -e "install.packages('devtools')"
- script:
name: Install backports
code: R -e "install.packages('backports')"
- jimhester/r-dependencies
- jimhester/r-check
- jimhester/r-lint
- jimhester/r-coverage



Any help/advice/experience with Wercker would be greatly appreciated!

Best wishes,
Kevin

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Thanks to Andrzej...

[Kevin RUE]

As a user and package maintainer, I'm sure that I am only aware of the tip
of iceberg in terms of contributions from good souls like Andrzej. Their
kind help, advice, and feedback are a big part of what keeps the community
spirit alive (personal experience at
https://github.com/Bioconductor/BiocStyle/issues/7)

Thank you and best wishes!
Kevin

On Thu, Mar 1, 2018 at 1:44 AM, Vincent Carey 
wrote:

> Strongly seconded.  We will miss you Andrzej!
>
> On Wed, Feb 28, 2018 at 6:53 PM, Martin Morgan <
> martin.mor...@roswellpark.org> wrote:
>
> > I want to extend a sincere thanks to Andrzej Oleś. Andrzej has been
> making
> > many visible and hidden contributions to the project over the last
> several
> > years. Highlights include:
> >
> >   - Extensive development of the BiocStyle package
> >
> >   - Modifying our build system to use git rather than svn
> >
> >   - Supporting our bespoke workflow builders, and migrating the workflows
> > to our standard build system (project nearing completion)
> >
> >   - Providing robust code to chronicle Bioconductor literature citations
> (
> > https://bioconductor.org/help/publications/).
> >
> >   - Development and / or maintenance of EBImage, DEFormats, and other
> > packages.
> >
> > The Bioconductor core team really appreciates the help and first-rate
> work
> > that Andrzej has done, and wishes him the best as he transitions to a new
> > position.
> >
> > Martin Morgan
> > Bioconductor
> >
> >
> > 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
> >
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] R version check in BiocChech

[Kevin RUE]

Hi Alexey,

I do agree with you that there is no harm in testing against other version
of R. In a way, that is even good practice, considering that many HPC users
do not always have access to the latest version of R, and that Travis is
making this fairly easy.

Now, with regard to your latest reply, I am wondering whether we're having
confusion here between the "R≥x.x" requirement, and the version(s) of R
that you use to develop/test your package (the version of R installed on
your own machine).

First, I think the "R≥x.x" does not have an explicit rule.
To me, the point of this requirement is to declare the oldest version of R
that the package has been tested/validated for. This does not necessarily
have to be the _next_ version of R (see the core Bioc package S4Vectors:
https://bioconductor.org/packages/release/bioc/html/S4Vectors.html, and I
am sure there are older requirements in other packages).
Here, I think the decision here boils down to how far back in terms of R
versions the developer is willing to support the package. I suppose one
could state R≥2.3 if they're confident about it.

On a separate note, going back to the Bioc guideline that I initially
highlighted ("Package authors should develop against the version of *R* that
will be available to users when the *Bioconductor* devel branch becomes the
*Bioconductor* release branch."), this rather refers to the forward-looking
guideline that the cutting-edge version of any R package should be
compatible with the cutting edge version of R, and that developers should
be working with R-devel to ensure this.
In other words, this only refers to the version of R that the developer
should have installed on their own machine. It does not request users to
make R-devel a _requirement_ of their package.

I hope this addresses your question better, and I am curious to hear if
anyone else has an opinion or precisions to weigh in on this topic.

Best,
Kevin


On Mon, Feb 19, 2018 at 12:19 PM, Alexey Sergushichev <alserg...@gmail.com>
wrote:

> Hello Kevin,
>
> Well, bioc-devel packages are tested against bioc-devel (and R-3.5) in any
> case. What I'm saying is that aside from testing the package against
> bioc-devel, I can as well test against bioc-release too on my own. If the
> package doesn't work with bioc-devel it shouldn't pass bioc-devel checks,
> if the package is properly developed and has a good test coverage. So I see
> no problem in allowing developers to test against other versions, on top of
> developing against bioc-devel. And as it's only possible to install the
> package from github and not from Bioconductor, the developer alone is
> responsible for the package to work properly.
>
> I can't really see a scenario, where requiring R >= 3.5 helps to improve
> the package quality.
>
> > A short-term workaround can be to create a git branch (e.g. "3.4").
>
> That's the way I'm doing too, but supporting two branches different only
> in R version looks ridiculous and unnecessary.
>
> --
> Alexey
>
>
>
>
>
> On Mon, Feb 19, 2018 at 12:48 PM, Kevin RUE <kevinru...@gmail.com> wrote:
>
>> Dear Alexey,
>>
>> The reason is somewhat implicitly given at https://www.bioconductor.or
>> g/developers/how-to/useDevel/ :
>> "Package authors should develop against the version of *R* that will be
>> available to users when the *Bioconductor* devel branch becomes the
>> *Bioconductor* release branch."
>>
>> In other words, developing against the _next_ version of R ensures that
>> all packages in development are tested in the environment where they will
>> be released to the general community. In particular, that environment
>> includes the latest devel version of all Bioconductor packages, that will
>> become their next release version.
>> If developers were allowed to develop and test their package in the
>> _current_ version of R, there is no guarantee that those packages would
>> still work when they are made available with the _next_ version of R (e.g.
>> if one of their dependencies is about to introduce some breaking changes).
>> That could cause all sorts of trouble in the first builds on the next
>> Bioconductor release, which is meant to be a place storing stable working
>> code.
>>
>> Overall, you will do yourself and your users a favor developing with the
>> _next_ version of R, as this is a forward-looking strategy, as explained
>> above. In contrast, the short-term benefit of developing with the _current_
>> version of R is largely outweighed by the risk of wasting time looking at
>> code that is about to be deprecated.
>>
>> A short-term workaround can be to create a git branch (e.g. "3.4"), where
>> the R version

Re: [Bioc-devel] R version check in BiocChech

[Kevin RUE]

Dear Alexey,

The reason is somewhat implicitly given at
https://www.bioconductor.org/developers/how-to/useDevel/ :
"Package authors should develop against the version of *R* that will be
available to users when the *Bioconductor* devel branch becomes the
*Bioconductor* release branch."

In other words, developing against the _next_ version of R ensures that all
packages in development are tested in the environment where they will be
released to the general community. In particular, that environment includes
the latest devel version of all Bioconductor packages, that will become
their next release version.
If developers were allowed to develop and test their package in the
_current_ version of R, there is no guarantee that those packages would
still work when they are made available with the _next_ version of R (e.g.
if one of their dependencies is about to introduce some breaking changes).
That could cause all sorts of trouble in the first builds on the next
Bioconductor release, which is meant to be a place storing stable working
code.

Overall, you will do yourself and your users a favor developing with the
_next_ version of R, as this is a forward-looking strategy, as explained
above. In contrast, the short-term benefit of developing with the _current_
version of R is largely outweighed by the risk of wasting time looking at
code that is about to be deprecated.

A short-term workaround can be to create a git branch (e.g. "3.4"), where
the R version requirement is downgraded. Then, you can always keep
developing against R-devel on your master branch and back-port the more
recent commit to the "3.4" branch by typing "git rebase master 3.4" in your
shell.
A recent example of this situation can be found in the discussion here as a
branch to the original repository https://github.com/csoneson/iSEE/pull/124
and here as a fork
https://github.com/mdshw5/iSEE/commit/6fb98192a635a6222491b66fb0474dc38f922495

I hope this helps.

Best wishes,
Kevin


On Mon, Feb 19, 2018 at 8:02 AM, Alexey Sergushichev 
wrote:

> Dear Bioconducotr community,
>
> I wonder, what is the reason behind requirement for dependency R >= 3.5
> (currently) for new packages?
>
> As a developer I really want an installation of my package to be as easy as
> possible and want my package to be easily installed from github. So
> currently, when I develop a package I put a R >= 3.4 in my DESCRIPTION and
> test it using Travis against bioc-release. Then, before submission
> to Bioconductor, I have to change R >= 3.4 dependency to R >= 3.5, so that
> the package passes BiocCheck. However, most users don't have R-devel
> installed, so they have R 3.4 in the best case, and for these users I
> create another repository branch with R >= 3.4 dependency.
>
> Overall, it is quite bothersome and it doesn't really make sense to me to
> to restrict potential users in this way. Am I the only one who have issues
> with this? Am I missing something? Or may be this check could be removed?
>
> Best,
> Alexey Sergushichev
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] assay dimnames in SingleCellExperiment / SummarizedExperiment

[Kevin RUE]

Hi Aaron,

Yes - sorry, I meant the names of dimnames. Dimnames are indeed checked,
but my code was meant to demonstrate that names of dimnames aren't.
Obviously, it's not the end of the world, but just something I noticed
while I was investigating the glitch.

My second point is not that much about calling dim or dimnames, but rather
about the side-effects of having names(dimnames(x)) not NULL, such as the
case of `reshape2::melt`.
I think it'd be one worry less for downstream methods to 'know' the
colnames of a melted assay(x, 1) instead of having "Var1, Var2, value" if
names(dimnames) is NULL, and "something else" if not NULL.

Beyond aesthetics, it's really just semantics, but I do think small stuff
like that, if handled at a higher class level, can encourage downstream
developers to work off a more consistent mental and computational model (my
take from Michael Lawrence's BOF at Bioc2017). In other words, it has a
small cost to implement in the parent class, instead of if-else statements
in each child class.

It could be something as simple as :

   - c("Feature", "Sample") at the `SummarizedExperiment` level
   - overriden by c("Feature", "Cell") in `SingleCellExperiment`
   - overriden by developer's choice in other dependent packages.


All the best,
Kevin


On Sat, Sep 16, 2017 at 6:43 AM, Aaron Lun <a...@wehi.edu.au> wrote:

> I'll leave the first point to the SummarizedExperiment maintainers, though
> I  note that your code seems to be about the names of the dimnames rather
> than the dimnames themselves. (I'm under the impression that consistency in
> the actual dimnames is enforced somehow by the SE constructor.)
>
>
> As for the second point; I suppose we *could* set the second name for the
> dimnames as "Cells" in SingleCellExperiment, though the choice for the
> first name is more ambiguous. This request has come up before, and I've
> never been entirely convinced by its necessity. It seems mostly aesthetic
> to me, and honestly, if a user doesn't already know that rows are genes and
> columns are cells, I can't see them flailing away at the keyboard until
> they call dim() to tell them what the dimensions correspond to.
>
>
> But I guess other people like aesthetics, so if you want, you can put in a
> PR to override dim() and dimnames() for SingleCellExperiment to put some
> names on the returned vectors or lists. If I had to choose, I would go with
> "Features" and "Cells" for the rows and columns, respectively. (We already
> use a RSE so we're already implicitly assuming genomic features.)
>
>
> -Aaron
> --
> *From:* Kevin RUE <kevinru...@gmail.com>
> *Sent:* Thursday, 14 September 2017 10:57:39 PM
> *To:* bioc-devel
> *Cc:* da...@ebi.ac.uk; risso.dav...@gmail.com; Aaron Lun; Maintainer
> *Subject:* assay dimnames in SingleCellExperiment / SummarizedExperiment
>
> Dear all,
>
> I cc-ed to this email individual package maintainer to directly 'notify'
> them of this thread and have their respective opinions, but I thought the
> common use of SummarizedExperiment was worth involving the community as
> well.
>
> Background: I was updating one of my workflow from SCESet to the
> SingleCellExperiment class recently introduced on the development branch.
>
> 1)
> One thing leading to another, I ended up noticing that there is no
> validity check on dimnames of the various assays in SummarizedExperiment.
> In other words, the different assays can have different `dimnames` (or some
> assays can have NULL dimnames). Using the example code from
> SummarizedExperiment:
>
> nrows <- 200; ncols <- 6
> counts3 <- counts2 <- counts <-
>   matrix(runif(nrows * ncols, 1, 1e4), nrows)
>
> rnames <- paste0("F_", sprintf("%03.f", seq_len(nrows)))
> cnames <- LETTERS[1:6]
>
> dimnames(counts) <- list(rnames, cnames)
> dimnames(counts2) <- list(Tags = rnames, Samples = cnames)
> dimnames(counts3) <- list(Features = rnames, Cells = cnames)
>
> colData <- DataFrame(row.names=cnames)
>
> rse <- SummarizedExperiment(assays=SimpleList(c1=counts, c2=counts2,
> c3=counts3), colData=colData)
>
> assayNames(rse)
> names(dimnames(assay(rse, "c1"))) # NULL
> names(dimnames(assay(rse, "c2"))) # [1] "Tags""Samples"
> names(dimnames(assay(rse, "c3"))) # [1] "Features" "Cells"
>
> Although not critical, it'd probably be best practice to have a validity
> check on identical dimnames across all assay, so that one does not have to
> worry later about `melt` calls returning different column names whether
> each assay has proper dimnames or not.
>
>
&

[Bioc-devel] assay dimnames in SingleCellExperiment / SummarizedExperiment

[Kevin RUE]

Dear all,

I cc-ed to this email individual package maintainer to directly 'notify'
them of this thread and have their respective opinions, but I thought the
common use of SummarizedExperiment was worth involving the community as
well.

Background: I was updating one of my workflow from SCESet to the
SingleCellExperiment class recently introduced on the development branch.

1)
One thing leading to another, I ended up noticing that there is no validity
check on dimnames of the various assays in SummarizedExperiment. In other
words, the different assays can have different `dimnames` (or some assays
can have NULL dimnames). Using the example code from SummarizedExperiment:

nrows <- 200; ncols <- 6
counts3 <- counts2 <- counts <-
  matrix(runif(nrows * ncols, 1, 1e4), nrows)

rnames <- paste0("F_", sprintf("%03.f", seq_len(nrows)))
cnames <- LETTERS[1:6]

dimnames(counts) <- list(rnames, cnames)
dimnames(counts2) <- list(Tags = rnames, Samples = cnames)
dimnames(counts3) <- list(Features = rnames, Cells = cnames)

colData <- DataFrame(row.names=cnames)

rse <- SummarizedExperiment(assays=SimpleList(c1=counts, c2=counts2,
c3=counts3), colData=colData)

assayNames(rse)
names(dimnames(assay(rse, "c1"))) # NULL
names(dimnames(assay(rse, "c2"))) # [1] "Tags""Samples"
names(dimnames(assay(rse, "c3"))) # [1] "Features" "Cells"

Although not critical, it'd probably be best practice to have a validity
check on identical dimnames across all assay, so that one does not have to
worry later about `melt` calls returning different column names whether
each assay has proper dimnames or not.


2)
The initial glitch that prompted this email related to the `reshape2::melt`
method that extracts dimnames, if available, in the
`scater::plotHighestExprs` function. Anyway, Davis has already prepared a
fix to deal with the scenario whereby the assay does have dimnames (e.g.
counts in the edgeR::DGEList class that I generally use to import counts).
Somehow that wasn't an issue with the SCESet that I was using previously
(probably a side-effect of ExpressionSet).

The point is, the glitch prompted me to think whether a potential
standardisation of names(dimnames) could be beneficial, perhaps more
specifically in the new `SingleCellExperiment` class (as
SummarizedExperiment has a much more general purpose). Considering the
fairly specific purpose of the former, I was wondering whether it would be
worth:

   - enforcing names(dimnames(x)) to "Features" and "Cells", (bearing in
   mind that features could still be genes, transcripts, ...)
   - or maybe dropping dimnames altogether, storing them only once
   elsewhere (although a slot for that seems overkill)

There may be other possibilities that I haven't thought of yet, but I
thought I'd get the ball rolling.
Having well-defined dimnames sounds good practice, with the added benefit
of generating aesthetically pleasing column names in melted data-frame as a
by-product.
However, I can't tell whether the handling of dimnames is something that
needs to be handle by individual downstream package developers, or whether
standards should be set in parent classes.


Thanks for your time!

Best,
Kevin

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Search on www.bioconductor.org fails

[Kevin RUE]

Hi,

I got the same issue yesterday if that can help track down the origin; it
wasn't just today.
I thought it was a transient glitch and didn't report it immediately. I
hadn't checked today yet.

Best
Kevin


On Mon, Aug 21, 2017 at 3:58 PM, Laurent Gatto  wrote:

>
> Dear Bioconductor admins,
>
> When using the search box on www.bioconductor.org, I systematically get
> the following error
>
>   A timeout or invalid search term resulted in an error.
>
> Best wishes,
>
> Laurent
>
> --
> Laurent Gatto | @lgatt0
> http://cpu.sysbiol.cam.ac.uk/
> http://lgatto.github.io/
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] error with transfering SVN repo to git

[Kevin RUE]

Hi Samuel,

Please see the recent email below from Nitesh (core team) yesterday on this
mailing list.

Best wishes,
Kevin


Hi Maintainers,
> The beta phase for the GIT transition has now come to an end. All access
> to the git.bioconductor.org server has been suspended till August 16th
> 6pm EST.
> Please see the important dates, and times for the transition below.
> Best,
> Nitesh

> On Aug 7, 2017, at 4:43 PM, Turaga, Nitesh 
> wrote:
> >
> > Hello Maintainers,
> >
> >
> > The details and timeline of the transition from SVN to GIT have been
> finalized.
> >
> >
> > 1.  Important Dates, Days of transition - August 15th and August 16th.
> >
> > August 15th - 9am EST
> >
> >   - Git BETA server commits stop, BETA phase ends. All commits to
> the BETA repository are discarded.
> >   - Data experiment package SVN commits are stopped.
> >
> > August 16th - 9am EST
> >
> >   - Software package SVN commits are stopped,
> >   - About 6 hours after, the GIT server comes to life.
> >   - No SVN commits here after
> >
> > August 16th - 6pm EST onwards.
> >
> >   - Only commits to git.bioconductor.org possible.
> >   - See scenarios on how to commit to the new git server.
> >
> >   (https://github.com/Bioconductor/bioc_git_
> transition/tree/master/doc)
> >
> > 2. For access to git.bioconductor.org, please submit your SSH keys to
> >
> >   https://goo.gl/forms/eg36vcBkIUjfZfLe2
> >
> > This is important, without which you will not be able to maintain your
> package.
> >
> > 3. Workflow packages will remain on SVN for the moment. We will inform
> you when the transition of the workflow packages happen.
> >
> >
> >
> > Best,
> >
> >
> > Nitesh Turaga
> > Bioconductor Core Team


On Tue, Aug 15, 2017 at 5:44 AM, Samuel E Zimmerman <
sezim...@einstein.yu.edu> wrote:

> Hi,
>
> I am following the first scenario to change over from SVN to github. When
> I do the following commands
>
>
> git remote add upstream g...@git.bioconductor.org:packages/pathVar.git
> git fetch upstream
>
> I get the error
>
> Permission denied (publickey).
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.
>
> Alternatively, if I re-clone the empty repository and then do the command
>
> git remote add upstream https://git.bioconductor.org/packages/pathVar.git
> git fetch upstream
>
> I get the error
>
> fatal: remote error: FATAL: R any packages/pathVar nobody DENIED by
> fallthru
> (or you mis-spelled the reponame)
>
> Do you know why this is happening?
>
> Thank you very much.
>
> Best,
> Sam Zimmerman
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Bioconductor Contribution 'GKnowMTest' (issue #436)

[Kevin RUE]

Dear Samsiddhi,

I am not a core team member, but as developer/maintainer of two Bioc
packages, I can assure you that the core team has not forgotten about your
package submission and will review it as soon as humanly possible.
They have quite a few packages in the review process at the moment, and
it's easy to forget that they also have to deal with
maintenance/development of several core packages.

In addition, I can assure you that their review is entirely worth the wait,
it makes good packages even better (I can see you're using common S4
methods and classes, I am sure they'll appreciate that and provide
excellent constructive feedback). Please be patient.

Best wishes,
Kevin

On Mon, Aug 14, 2017 at 7:59 AM, Samsiddhi Bhattacharjee <
sb.stat...@gmail.com> wrote:

> Hello
>
> I have submitted a R package "GKnowMTest" with issue #436. Please update me
> on the status of reviewing my package.
>
> Thank You
>
>
> Samsiddhi Bhattacharjee
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] git transition for projects with prior git history

[Kevin RUE]

Thanks Nitesh,

I managed to push some changes to my other package "GOexpress" during the
beta a few days ago, so I'm looking forward to the transition next week.
For that package, I didn't hesitate much to clone into a new repository and
start fresh there.

I think I'll do the same for "TVTB", I can always keep the old one for
reference.

Thanks for the reply.
Kevin


On Thu, Aug 10, 2017 at 5:34 PM, Turaga, Nitesh <
nitesh.tur...@roswellpark.org> wrote:

> Hi Kevin,
>
> If your Github and SVN repos separated so much, then I’d just wait for the
> transition and then go from there.
>
> Once the git server is alive, you can make a new GitHub repo at that point.
>
> Nitesh
>
>
> > On Aug 10, 2017, at 10:18 AM, Kevin RUE <kevinru...@gmail.com> wrote:
> >
> > Hi all,
> >
> > I think I'm facing a similar scenario ("prior history"), although I have
> messed up my original GitHub repo (https://github.com/kevinrue/
> TVTB/commits/master) beyond my ability to synchronise it back to a
> working state.
> >
> > Basically, a few months ago, a bad mix of `git svn rebase` and `git
> merge master` replayed a whole lot of commit, likely the entire local
> history of commits, a couple of times (my Github  master branch now shows
> 1,043 commits, against 333 in the Bioconductor-mirror/TVTB:master. I can
> safely say that I haven't been _that_ productive.
> >
> > After a few attempts to reset/merge/rebase/cry, I gave up the idea of
> reconciliation between my GitHub and the Bioc SVN; I abandoned my own
> GitHub repo and interacted with the SVN directly.
> >
> > Now my GitHub repo is behind the current state of my package in
> git.bioconductor.org (version 1.1.10 vs. 1.3.1), with different commit
> histories, that I can't even start to unravel.
> >
> > At that point, I dream of a way to simply update my own GitHub master to
> the current state of the git.bioconductor.org:packages/TVTB master
> branch, and use that commit as the root of all future development
> (branches). Is that something realistic/worth the effort ?
> >
> > I do have a feeling that the cleanest option would be to abandon my
> GitHub repo, clone from git.bioconductor.org, and make a new GitHub repo
> from that point... but I thought I'd ask one last time before giving up on
> the original repo.
> >
> > Many thanks in advance.
> > Kevin
> >
> >
> >
> >
> > On Fri, Jul 28, 2017 at 7:09 PM, McDavid, Andrew <Andrew_Mcdavid@urmc.
> rochester.edu> wrote:
> > Hi Nitesh,
> >
> > Schematically, my git repo started with commit D, while bioconductor's
> started with A.  It's possible this was because I did something wrong
> managing the bioconductor repo, but since I can't rewrite history, there's
> not anything I can do about that now.  Their "founding" commits are
> distinct.
> >
> >
> >  BioconductorA---B---C
> >/ /
> >  MasterD---E---F---G---I
> >
> > Since then, I have I have been cherry-picking changes from master onto
> bioconductor per my understanding of recommended practice.
> > If I try to merge bioconductor onto master, or vice versa, I get the
> unrelated histories warning.  Vlad's suggestion works, but results in
> replaying ~700 commits onto the bioconductor repo...not so nice maybe.
> >
> > The https://github.com/Bioconductor-mirror/MAST.git repo is to make SVN
> commits from the git tree.
> >
> >
> > > On Jul 28, 2017, at 11:33 AM, Turaga, Nitesh
> <nitesh.tur...@roswellpark.org> wrote:
> > >
> > > I would be careful before using the --allow-unrelated-histories flag.
> Please investigate where there is a difference.
> > >
> > > Also, i don't understand why you are using the
> bioconductor-git-mirror? Your non-zero commit history should be related to
> bioconductor git server.
> > >
> > > Best
> > >
> > > Nitesh
> > >
> > > Get Outlook for Android
> > >
> > >
> > >
> > > From: Vladimir Kiselev
> > > Sent: Thursday, July 27, 5:11 PM
> > > Subject: Re: [Bioc-devel] git transition for projects with prior git
> history
> > > To: McDavid, Andrew, bioc-devel@r-project.org
> > >
> > >
> > > Hi Andrew, I solved it by just adding '--allow-unrelated-histories' to
> force the merge: https://stackoverflow.com/questions/37937984/git-
> refusing-to-merge-unrelated-histories Cheers, Vlad On Thu, Jul 27, 2017
> at 9:53 PM McDavid, Andrew < andrew_mcda...@urmc.rochester.edu> wrote: >
> Is

Re: [Bioc-devel] git transition for projects with prior git history

[Kevin RUE]

Hi all,

I think I'm facing a similar scenario ("prior history"), although I have
messed up my original GitHub repo (https://github.com/kevinrue/
TVTB/commits/master) beyond my ability to synchronise it back to a working
state.

Basically, a few months ago, a bad mix of `git svn rebase` and `git merge
master` replayed a whole lot of commit, likely the entire local history of
commits, a couple of times (my Github  master branch now shows 1,043
commits, against 333 in the Bioconductor-mirror/TVTB:master. I can safely
say that I haven't been _that_ productive.

After a few attempts to reset/merge/rebase/cry, I gave up the idea of
reconciliation between my GitHub and the Bioc SVN; I abandoned my own
GitHub repo and interacted with the SVN directly.

Now my GitHub repo is behind the current state of my package in
git.bioconductor.org (version 1.1.10 vs. 1.3.1), with different commit
histories, that I can't even start to unravel.

At that point, I dream of a way to simply update my own GitHub master to
the current state of the git.bioconductor.org:packages/TVTB master branch,
and use that commit as the root of all future development (branches). Is
that something realistic/worth the effort ?

I do have a feeling that the cleanest option would be to abandon my GitHub
repo, clone from git.bioconductor.org, and make a new GitHub repo from that
point... but I thought I'd ask one last time before giving up on the
original repo.

Many thanks in advance.
Kevin




On Fri, Jul 28, 2017 at 7:09 PM, McDavid, Andrew <
andrew_mcda...@urmc.rochester.edu> wrote:

> Hi Nitesh,
>
> Schematically, my git repo started with commit D, while bioconductor's
> started with A.  It's possible this was because I did something wrong
> managing the bioconductor repo, but since I can't rewrite history, there's
> not anything I can do about that now.  Their "founding" commits are
> distinct.
>
>
>  BioconductorA---B---C
>/ /
>  MasterD---E---F---G---I
>
> Since then, I have I have been cherry-picking changes from master onto
> bioconductor per my understanding of recommended practice.
> If I try to merge bioconductor onto master, or vice versa, I get the
> unrelated histories warning.  Vlad's suggestion works, but results in
> replaying ~700 commits onto the bioconductor repo...not so nice maybe.
>
> The https://github.com/Bioconductor-mirror/MAST.git repo is to make SVN
> commits from the git tree.
>
>
> > On Jul 28, 2017, at 11:33 AM, Turaga, Nitesh
>  wrote:
> >
> > I would be careful before using the --allow-unrelated-histories flag.
> Please investigate where there is a difference.
> >
> > Also, i don't understand why you are using the bioconductor-git-mirror?
> Your non-zero commit history should be related to bioconductor git server.
> >
> > Best
> >
> > Nitesh
> >
> > Get Outlook for Android
> >
> >
> >
> > From: Vladimir Kiselev
> > Sent: Thursday, July 27, 5:11 PM
> > Subject: Re: [Bioc-devel] git transition for projects with prior git
> history
> > To: McDavid, Andrew, bioc-devel@r-project.org
> >
> >
> > Hi Andrew, I solved it by just adding '--allow-unrelated-histories' to
> force the merge: https://stackoverflow.com/questions/37937984/git-
> refusing-to-merge-unrelated-histories Cheers, Vlad On Thu, Jul 27, 2017
> at 9:53 PM McDavid, Andrew < andrew_mcda...@urmc.rochester.edu> wrote: >
> Is there a recommended recipe to utilize the git.bioconductor.org< >
> http://git.bioconductor.org> remote with an existing git repo that has >
> non-zero history? I tried adding the git.bioconductor.org< >
> http://git.bioconductor.org> as a remote, making a branch, and then >
> checking out a branch on that remote, but it gave my computer sad. Do I >
> need to clone a new repo instead? > > Example: > $ git remote -vv > bioc
> https://github.com/Bioconductor-mirror/MAST.git (fetch) > bioc
> https://github.com/Bioconductor-mirror/MAST.git (push) > biocgit
> g...@git.bioconductor.org:packages/MAST > (fetch) > biocgit
> g...@git.bioconductor.org:packages/MAST > (push) > origin 
> g...@github.com:RGLab/MAST.git
> (fetch) > origin git
>  @github.com:RGLab/MAST.git (push > > $ git fetch biocgit > $ git
> checkout -b bgMaster --track biocgit/master > ... > > ... > $ git merge
> master bgMaster > fatal: refusing to merge unrelated histories > >
> [[alternative HTML version deleted]] > > 
> ___
> > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/
> listinfo/bioc-devel > -- http://genat.uk [[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
> 

Re: [Bioc-devel] strange error in Jenkins build for singleCellWorkflow

[Kevin RUE]

Hi all,

I had this same issue a few months ago (in the weeks leading up to the
release of R-3.4.0), when building an Rmarkdown website on my own laptop.
It seemed the session variables were cleaned up between markdown documents,
but that packages remained loaded and accumulated to the point that I hit
the '100 DLLs limit' (
http://r.789695.n4.nabble.com/Is-it-possible-to-increase-MAX-NUM-DLLS-in-future-R-releases-td4720352.html)
causing the same error message as Aaron.

At the time, I was using R-devel which was to become 3.4.0. After a couple
of days, updating to the latest nightly build of R-devel solved the error
(except if I inadvertently touched anything else in the process).

It may not be much of a clear bug fix, but I hope my experience can
somewhat help hint toward the source of the issue on Jenkins.

Best wishes,
Kevin

Fun fact:
at the time, that issue made me discover this amazing package:
https://github.com/romainfrancois/nothing (which didn't solve the issue!)
Enjoy ;)


On Tue, Jun 20, 2017 at 6:23 PM, Obenchain, Valerie <
valerie.obench...@roswellpark.org> wrote:

> Thanks for the report Aaron. I'll take a look.
>
> Valerie
>
> On 06/20/2017 07:10 AM, Aaron Lun wrote:
> > Hi all,
> >
> >
> > I'm getting a curious error in the Jenkins log when I try to build the
> singleCellWorkflow:
> >
> >
> > http://docbuilder.bioconductor.org:8080/job/simpleSingleCell/48/label=
> master/console
> >
> >
> > The key part is at the bottom:
> >
> >
> > Error: package or namespace load failed for 'GenomicFeatures' in
> dyn.load(file, DLLpath = DLLpath, ...):
> >  unable to load shared object '/var/lib/jenkins/R/x86_64-pc-
> linux-gnu-library/3.4/Rsamtools/libs/Rsamtools.so':
> >   `maximal number of DLLs reached...
> >
> >
> > The workflow had previously been running fine on the build system; I'm
> not quite sure what's going on here, given that it's not even failing at
> the point where I made the latest changes.
> >
> > Cheers,
> >
> > Aaron
> >
> >   [[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.
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] condition tests on vectors with length greater than 1

[Kevin RUE]

Hi Martin,

My apologies to Tomas Kalibera. I read too fast and missed the part where
you gave him credit for the report.

As I wrote in my previous email, I have started a significant clean-up of
the GOexpress package to improve both the coding standards and the user
experience. I haven't reached the overlap_GO function yet (that uses the
VennDiagram package); however, this is not a core function (I used it for
diagnostic mostly during package development), and I will most likely
drop it altogether before the next release.

Have a great weekend.

Kind regards,
Kevin


On Fri, Mar 31, 2017 at 5:00 PM, Martin Morgan <
martin.mor...@roswellpark.org> wrote:

> On 03/31/2017 08:21 AM, Kevin RUE wrote:
>
>> Hi Martin,
>>
>> Thanks a lot for systematically identifying the issue.
>>
>> Looking at the issue for GOexpress now, I realise that the issue is not
>> in GOexpress itself, but actually within the VennDiagram package that
>> GOexpress imports. You actually captured that in your report:
>>
>> "GOexpress","_VennDiagram_","GOexpress.Rcheck/GOexpress-Ex.R
>> out","VennDiagram::adjust.venn","VennDiagram/R/adjust.venn.R#42 "
>>
>> In your report, GOexpress is the only Bioconductor in this situation.
>> I can (and will) attempt to contact the maintainer of VennDiagram, but
>> it just makes me wonder if you have another suggestion to deal with this
>> kind of issue (/i.e./, imported packages not conforming to BioC
>> guidelines). Is this going to raise Warnings or Errors in BiocCheck ? If
>> so, should we ignore such packages altogether, as long as those packages
>> raise check issues?
>>
>
> Actually, the report was generated by an R-core member, Tomas Kalibera and
> the more extensive version includes all CRAN and Bioc packages. It reflects
> a general effort to address these and then make them errors, rather than
> warnings -- R CMD check would then fail.
>
> Package dependencies are interesting. They are obviously hugely important
> to reduce redundant code, and to fix bugs once in a single place. But they
> also carry with them an additional maintenance cost. If VennDiagram is
> central to your package, especially if it implements complicated
> functionality, then definitely the balance is in favor of depending on it,
> and working with the maintainer to address problems that you discover.
>
> The Bioc requirements are really about your package, especially enforcing
> adequate documentation.
>
> Martin
>
>
>> As a side note, I have actually already been going through GOexpress to
>> prepare a new major version of GOexpress (2.x.x) that will introduce S4
>> where relevant, and break down large functions into more sensibly-sized
>> steps. However, most likely that won't be ready for the next BioC release.
>>
>> Best,
>> Kevin
>>
>>
>> On Wed, Mar 29, 2017 at 10:44 PM, Martin Morgan
>> <martin.mor...@roswellpark.org <mailto:martin.mor...@roswellpark.org>>
>>
>> wrote:
>>
>> On 03/29/2017 05:37 PM, Martin Morgan wrote:
>>
>> Bioc developers,
>>
>> R emits a warning when a condition test has length > 1
>>
>> $ R --vanilla
>>
>> if (letters == "a") TRUE
>>
>> [1] TRUE
>> Warning message:
>> In if (letters == "a") TRUE :
>>   the condition has length > 1 and only the first element will
>> be used
>>
>> These are almost always programming errors.
>>
>> R-3-4-branch and R-devel can be configured to report such errors,
>> as
>> described on the help page for, e.g., `?"if"`
>>
>> $ _R_CHECK_LENGTH_1_CONDITION_=TRUE R --vanilla
>>
>> if (letters=="a") TRUE
>>
>> Error in if (letters == "a") TRUE : the condition has length > 1
>>
>> The attached file (thanks to Tomas Kalibera) summarizes
>> Bioconductor
>> code that triggers this type of error.
>>
>>
>> Second try on the attachment
>>
>> r = read.csv("long-conditional-bioc.txt")
>>
>>
>>
>> If you maintain one of these packages (appearing in either
>> column),
>> please address the error. And of course as a developer, please
>> avoid
>> making the error in the future!
>>
>> r = read.csv("long-conditional-bioc.csv")
>> r[, c("FailedPackage", "Srcref"

Re: [Bioc-devel] condition tests on vectors with length greater than 1

[Kevin RUE]

Hi Martin,

Thanks a lot for systematically identifying the issue.

Looking at the issue for GOexpress now, I realise that the issue is not in
GOexpress itself, but actually within the VennDiagram package that
GOexpress imports. You actually captured that in your report:

"GOexpress","*VennDiagram*","GOexpress.Rcheck/GOexpress-Ex.Rout","VennDiagram::adjust.venn","VennDiagram/R/adjust.venn.R#42
"

In your report, GOexpress is the only Bioconductor in this situation.
I can (and will) attempt to contact the maintainer of VennDiagram, but it
just makes me wonder if you have another suggestion to deal with this kind
of issue (*i.e.*, imported packages not conforming to BioC guidelines). Is
this going to raise Warnings or Errors in BiocCheck ? If so, should we
ignore such packages altogether, as long as those packages raise check
issues?

As a side note, I have actually already been going through GOexpress to
prepare a new major version of GOexpress (2.x.x) that will introduce S4
where relevant, and break down large functions into more sensibly-sized
steps. However, most likely that won't be ready for the next BioC release.

Best,
Kevin


On Wed, Mar 29, 2017 at 10:44 PM, Martin Morgan <
martin.mor...@roswellpark.org> wrote:

> On 03/29/2017 05:37 PM, Martin Morgan wrote:
>
>> Bioc developers,
>>
>> R emits a warning when a condition test has length > 1
>>
>> $ R --vanilla
>>
>>> if (letters == "a") TRUE
>>>
>> [1] TRUE
>> Warning message:
>> In if (letters == "a") TRUE :
>>   the condition has length > 1 and only the first element will be used
>>
>> These are almost always programming errors.
>>
>> R-3-4-branch and R-devel can be configured to report such errors, as
>> described on the help page for, e.g., `?"if"`
>>
>> $ _R_CHECK_LENGTH_1_CONDITION_=TRUE R --vanilla
>>
>>> if (letters=="a") TRUE
>>>
>> Error in if (letters == "a") TRUE : the condition has length > 1
>>
>> The attached file (thanks to Tomas Kalibera) summarizes Bioconductor
>> code that triggers this type of error.
>>
>
> Second try on the attachment
>
> r = read.csv("long-conditional-bioc.txt")
>
>
>
>> If you maintain one of these packages (appearing in either column),
>> please address the error. And of course as a developer, please avoid
>> making the error in the future!
>>
>> r = read.csv("long-conditional-bioc.csv")
>>> r[, c("FailedPackage", "Srcref")]
>>>
>>FailedPackage  Srcref
>> 1 biovizBase   biovizBase/R/crunch-method.R#295
>> 2  branchpointer   branchpointer/R/makeRegions.R#41
>> 3   CardinalCardinal/R/spatial.R#57
>> 4  debrowser   debrowser/R/heatmap.R#38
>> 5DMRcateDMRcate/R/DMR.plot.R#13
>> 6  exomePeak  exomePeak/R/RMT.R#119
>> 7  fabia   fabia/R/fabia.R#1504
>> 8   GenomeInfoDb GenomicFeatures/R/TxDb-class.R#377
>> 9 Glimma   Glimma/R/hexcol.R#32
>> 10 GOexpress VennDiagram/R/adjust.venn.R#42
>> 11  GUIDEseq GUIDEseq/R/offTargetAnalysisOfPeakRegions.R#95
>> 12  hapFabia  hapFabia/R/methods-IBDsegmentList-class.R#110
>> 13 MassArray   MassArray/R/convControl.R#26
>> 14methylPipemethylPipe/R/Allfunctions.R#635
>> 15NOISeq   NOISeq/R/biodetection.plot.R#157
>> 16  pathview  pathview/R/geneannot.map.R#31
>> 17  phyloseq  phyloseq/R/multtest-wrapper.R#101
>> 18 rHVDM  rHVDM/R/measurementerrorHVDM.R#23
>> 19  SEPA  SEPA/R/truetimevisualize.R#28
>> 20  SPLINTER SPLINTER/R/main_splinter.R#817
>>
>> As an example the GenomeInfoDb package (row 8) has this complete record
>>
>> FailedPackage "GenomeInfoDb"
>> IfPackage "GenomicFeatures"
>> File  "GenomeInfoDb.Rcheck/GenomeInfoDb-Ex.Rout"
>> Function  "S4 Method seqlevels<-:GenomeInfoDb defined in namespace
>>GenomicFeatures with signature TxDb has this body."
>> Srcref"GenomicFeatures/R/TxDb-class.R#377 "
>>
>> The problem was from
>>
>>   GenomicFeatures/R/TxDb-class.R#377
>>
>> which has
>>
>> mode <- GenomeInfoDb:::getSeqlevelsReplacementMode(value,
>> x_seqlevels0)
>> if (mode == -2L) {
>>
>> I looked at
>>
>> GenomeInfoDb:::getSeqlevelsReplacementMode
>>>
>> function (new_seqlevels, old_seqlevels)
>> {
>> ...
>>
>> and saw that its code returns a vector with length > 1 intentionally
>> under some specific circumstances. Also, all other uses of the return
>> value of this function (in the GenomeInfoDb and GenomicFeatures package)
>> test for identity of the return value via `identical()`, which is always
>> a scalar. This suggests the fix
>>
>> GenomicFeatures$ svn diff R/TxDb-class.R
>> Index: R/TxDb-class.R
>> ===
>> --- 

Re: [Bioc-devel] A handful of check to follow up on R CMD BiocCheck

[Kevin RUE]

Hi Martin,

Thanks for spending the time and effort to refactor and integrate my code
into BiocCheck. I didn't intend to give you so much to think about !

For the record, I used the "checkFunctionLengths" method (now starting at
line 829 of checks.R) as a template to offer code somewhat homogenous with
what I could see in place already. I believe that function should also be
refactored using your new "Context" and "handleContext" helpers, right?

Side note:
Far from trying to compete with the BiocCheck Bioconductor package, I
couldn't help but update my "follow-up" "BiocCheckTools" Python code
<https://github.com/kevinrue/BiocCheckTools/blob/master/README.md> in the
meantime (sorry for unoriginal name, I'll take suggestions!) taking
Kasper's advice on board:

   - Single master file which runs everything and gives a report.
   - *Bonus*: each module can be run separately (line_chars; tab_width).
   - All line numbers are reported
   - Content of the line is not displayed
   - I didn't mark up TABs, but I indicate how many spaces they are made of
   (when not a multiple of 4)

All the best,
Kevin


On Wed, Nov 9, 2016 at 11:31 PM, Martin Morgan <
martin.mor...@roswellpark.org> wrote:

> On 11/03/2016 08:14 AM, Kevin RUE wrote:
>
>> Apologies for the additional spam, for two reasons:
>>
>>   * The diff files that I've previously sent had the base and modified
>> versions swapped. This new one fixes that.
>>   * This new diff file (always relative to the code I cloned from
>> Bioconductor-mirror) also fixes a bug whereby the updated code would
>> fail on packages that do not break any of the three guidelines.
>>
>
> Hi Kevin -- thanks for these, I incorporated a version in 1.11.1.
>
> The report is for the first 6 lines of offenders; the code for finding all
> offenders is mentioned in the vignette
>
>   BiocCheck:::checkFormatting("path/to/YourPackage", nlines=Inf)
>
> Marcel Ramos mentions the lintr (CRAN) and goodpractice (github only,
> https://github.com/MangoTheCat/goodpractice) packages as useful resources
> for these types of questions; also formatR (CRAN).
>
> For the record, it was fun to work through your code. The basic pattern
> was to read lines and flag those that violated a (usually simple) test, add
> these to a data frame, then if after parsing all files the data frame had
> any rows report these to the user.
>
> I standardized the columns of the data frame across checks to facilitate
> re-use, and imposed the standard by using a constructor -- non-exported
> Context(). I took a little bit of pain to make the constructor work (return
> a data frame with the correct columns but no rows) when there are no lines
> of code flagged to be added to the context, so that I could use it without
> have to insert a bunch of conditional `if (...)` in my code that make it
> both harder to understand and harder to test. Also, the constructor is
> vectorized, whereas your implementation was iterative.
>
> For reporting to the user, I wrote a small helper handleContext() that I
> could re-use across the different types of checks (and likely elsewhere in
> the package) and also maintain the separation of what is reported to the
> user (e.g., in handleContext()) from how it is reported to the user --
> .msg, .verbatim, etc in the utils.R file. Probably the reporting could have
> been refactored further.
>
> I feel guilty about not writing unit tests; the package does include
> tests, including a handy package-generator function to make packages that
> are invalid in various ways. It seems like a better way to go would be to
> further refactor the body of the checkFormatting() function so that one
> could for instance invoke a function checkLineLengths(pkg, file, lines) and
> get back a data.frame created by Context(); it would then be easy to test
> these for various 'lines' without having to figure out how to make test
> packages. But this seemed of course like too much additional work for this
> feature (I'll probably regret not expending the effort at a future date).
>
> I also found myself using the horrible 'copy-and-append' paradigm
>
>ctxt = Context()
>for (fl in files) {
>...
>ctxt = rbind(ctxt, Context(...)
> }
>
> which makes a copy of (the increasingly large) ctxt each time through the
> loop and therefore scales quadratically (when each file has some problems)
> with the number of files. I'm counting on the number of files to be small
> (e.g., less than 1, when the copy-and-append pattern starts to be
> expensive even for trivial operations; mzR has ~8750 files, though many of
> these are not checked for formatting) so that this pattern does not become
&g

[Bioc-devel] Problem with git-mirror

[Kevin RUE]

Dear all,


Apologies for the confusing email below, but I'm not sure anymore which
information can save the day. I'll provide all the information necessary to
fix the situation!

I think I've turned my GitHub/svn/GitHub-mirror repositories into a huge
plate of spaghetti after encountering successively pretty much all the
issues listed out at http://bioconductor.org/developers/how-to/git-mirrors/

After two successful commits and pushes on the devel and release branch of
my package, the situation started with the error message "Unable to
determine upstream SVN information from HEAD history." when running "git
svn dcommit", as described at
http://eikke.com/importing-a-git-tree-into-a-subversion-repository/

Following the instructions on that page, I somehow managed to push my
latest code onto the Bioconductor SVN (TVTB verson 1.1.3) before all hell
broke lose.

I must have done something wrong with either a rebase or a merge step
because it also seems that it reapplied pretty much every commit since the
creation of my own GitHub repository (with predates acceptance to
Bioconductor).
The result is that, in contrast to the SVN trunk (version 1.1.3;
https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/TVTB/DESCRIPTION)
the Bioconductor-mirror of my package shows version 0.1.7 of my package,
with largely pre-dates its addition to Bioconductor (
https://github.com/Bioconductor-mirror/TVTB/blob/master/DESCRIPTION).

After failing to fix the situation, I tried starting fresh (losing the
commit history prior addition to Bioconductor) by renaming my original
GitHub repository to "TVTB-original" (
https://github.com/kevinrue/TVTB-original) and creating a fresh fork from
the Bioconductor-mirror, so that I would fall back into the "*Scenario 2:
Set Up Your Own GitHub Repository*" described at
http://bioconductor.org/developers/how-to/git-mirrors/

But now, following to the letter the process to push to SVN, it fails at
the "git svn dcommit --add-author-from" step with errors and CONFLICT
messages:

$git svn dcommit --add-author-from
Committing to
https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/TVTB ...
Mappveyor.yml
ERROR from SVN:
Item is out of date: Item '/trunk/madman/Rpacks/TVTB/appveyor.yml' is out
of date
W: 533e40cfd8c74fa1d525cf6b4a7fc1e016f07e09 and refs/remotes/git-svn-devel
differ, using rebase:
:04 04 e1ff243efb925d24ba3823445035f91714c8d718
36e542cde3260307a1378870ff42c3975cd99a4e Minst
First, rewinding head to replay your work on top of it...
Applying: Applied all changes more recent than the Bioconductor-mirror.
Using index info to reconstruct a base tree...
M.Rbuildignore
M.gitignore

...

.git/rebase-apply/patch:4788: trailing whitespace.
| Platforms |  OS  | R CMD check | Coverage |
.git/rebase-apply/patch:4807: trailing whitespace.
The value of this information is truly revealed when
.git/rebase-apply/patch:20559: trailing whitespace.
+ affecting the genomic ranges to import from the VCF file
.git/rebase-apply/patch:20574: trailing whitespace.
To reduce the burden of repetition during programming, and to
.git/rebase-apply/patch:20696: trailing whitespace.
(both extending the virtual class `VCF`) of the
warning: squelched 32 whitespace errors
warning: 37 lines add whitespace errors.
Falling back to patching base and 3-way merge...
Auto-merging man/TVTBParam-class.Rd
CONFLICT (add/add): Merge conflict in man/TVTBParam-class.Rd
Auto-merging man/Genotypes-class.Rd
CONFLICT (add/add): Merge conflict in man/Genotypes-class.Rd
CONFLICT (rename/delete): inst/misc/subset_moderate_samples.R deleted in
Applied all changes more recent than the Bioconductor-mirror. and renamed
in 6be1d3b971a54854350105f00f09b794d108ae6d. Version
6be1d3b971a54854350105f00f09b794d108ae6d of
inst/misc/subset_moderate_samples.R left in tree.
Auto-merging appveyor.yml
CONFLICT (add/add): Merge conflict in appveyor.yml
Auto-merging DESCRIPTION
CONFLICT (content): Merge conflict in DESCRIPTION
error: Failed to merge in the changes.
Patch failed at 0001 Applied all changes more recent than the
Bioconductor-mirror.
The copy of the patch that failed is found in: .git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase
--abort".

rebase refs/remotes/git-svn-devel: command returned error: 128


I'm really lost how to restore a sane state and re-synchronise my code on
all of (my GitHub), (Bioconductor SVN trunk), (Bioconductor-mirror).

Thanks in advance for advice!
Kevin

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] A handful of check to follow up on R CMD BiocCheck

[Kevin RUE]

Apologies for the additional spam, for two reasons:

   - The diff files that I've previously sent had the base and modified
   versions swapped. This new one fixes that.
   - This new diff file (always relative to the code I cloned from
   Bioconductor-mirror) also fixes a bug whereby the updated code would fail
   on packages that do not break any of the three guidelines.

Best,
Kevin

On Thu, Nov 3, 2016 at 11:49 AM, Kevin RUE <kevinru...@gmail.com> wrote:

> Hi all,
>
> Please find attached the diff relative to the code that I cloned from
> Bioconductor-mirror yesterday (please ignore the previous diff file).
>
> Basically three new features:
>
>- As per previous email: display up to the first 6 lines that are over
>80 characters long
>- *New*: display up to the first 6 lines that are not indented by a
>multiple of 4 spaces
>- *New*: display up to the first 6 lines that use TAB instead of 4
>spaces for indentation
>
> I also attach the output of the updated code
> <https://github.com/kevinrue/BiocCheck>, to illustrate the changes.
>
> Notes:
>
>- For demonstration purpose, I indented a handful of lines from the
>checks.R file itself with TAB characters. I assume that's OK, as some lines
>were already longer than 80 characters and not indented by a multiple of 4
>    spaces.
>
> All the best,
> Kevin
>
> On Wed, Nov 2, 2016 at 10:00 PM, Kevin RUE <kevinru...@gmail.com> wrote:
>
>> Me again :)
>>
>> Please find attached the first patch to print the first 6 lines over 80
>> characters long. (I'll get to the tabulation offenders next).
>>
>> Note that all the offending lines are stored in the "df.length"
>> data.frame. How about an option like "fullReport=c(FALSE, TRUE)" that print
>> *all* the offending lines?
>> The data.frame also stores the content of the lines for the record, but
>> does not print them. I think Kasper is right: filename and line should be
>> enough to track down the line.
>>
>> All the best,
>> Kevin
>>
>>
>>
>> On Wed, Nov 2, 2016 at 8:08 PM, Kevin RUE <kevinru...@gmail.com> wrote:
>>
>>> Thanks for the feedback!
>>>
>>> I also tend to prefer *all* the lines being reported (or to be honest,
>>> that was really true when I had lots of them; a problem that I largely
>>> mitigated by fixing all of them once and subsequently paying more attention
>>> while developing).
>>>
>>> Printing the content of the offending line somewhat helps me spot the
>>> line faster (more so for tab issues). But I must admit that showing the
>>> whole line is somewhat "overkill". I just started thinking of a compromise
>>> being to only show the first N characters of the line, with N being 80
>>> minus the number of characters necessary to print the filename and line
>>> number.
>>>
>>> Thanks Martin for pointing out the lines in BiocCheck. (Now I feel bad
>>> for not having checked sooner.. hehe!)
>>> I think the idea of BiocCheck showing the first 6 offenders in BiocCheck
>>> quite nice, as I rarely have more since I use using the RStudio "Tools >
>>> Global Options > Code > Display > Show Margin > Margin column: 80" feature.
>>>
>>> I'll give a go at both approaches (developing BiocCheck and my own
>>> scripts)
>>>
>>> Cheers,
>>> Kevin
>>>
>>>
>>> On Wed, Nov 2, 2016 at 7:41 PM, Kasper Daniel Hansen <
>>> kasperdanielhan...@gmail.com> wrote:
>>>
>>>> I would prefer all line numbers reported, but on the other hand I am
>>>> indifferent wrt. the content of the line, unless (say) TABs are marked up
>>>> somehow.
>>>>
>>>> Kasper
>>>>
>>>> On Wed, Nov 2, 2016 at 3:17 PM, Martin Morgan <
>>>> martin.mor...@roswellpark.org> wrote:
>>>>
>>>>> On 11/02/2016 02:49 PM, Kevin RUE wrote:
>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> Just thought I'd share a handful of scripts that I wrote to follow up
>>>>>> on
>>>>>> certain NOTE messages thrown by R CMD BiocCheck.
>>>>>>
>>>>>> https://github.com/kevinrue/BiocCheckTools
>>>>>>
>>>>>> They're very simple, but I occasionally find them quite convenient.
>>>>>> Apologies if something similar already exists somewhere :)
>>>>>>
>>>>>
>&

Re: [Bioc-devel] A handful of check to follow up on R CMD BiocCheck

[Kevin RUE]

Hi all,

Please find attached the diff relative to the code that I cloned from
Bioconductor-mirror yesterday (please ignore the previous diff file).

Basically three new features:

   - As per previous email: display up to the first 6 lines that are over
   80 characters long
   - *New*: display up to the first 6 lines that are not indented by a
   multiple of 4 spaces
   - *New*: display up to the first 6 lines that use TAB instead of 4
   spaces for indentation

I also attach the output of the updated code
<https://github.com/kevinrue/BiocCheck>, to illustrate the changes.

Notes:

   - For demonstration purpose, I indented a handful of lines from the
   checks.R file itself with TAB characters. I assume that's OK, as some lines
   were already longer than 80 characters and not indented by a multiple of 4
   spaces.

All the best,
Kevin

On Wed, Nov 2, 2016 at 10:00 PM, Kevin RUE <kevinru...@gmail.com> wrote:

> Me again :)
>
> Please find attached the first patch to print the first 6 lines over 80
> characters long. (I'll get to the tabulation offenders next).
>
> Note that all the offending lines are stored in the "df.length"
> data.frame. How about an option like "fullReport=c(FALSE, TRUE)" that print
> *all* the offending lines?
> The data.frame also stores the content of the lines for the record, but
> does not print them. I think Kasper is right: filename and line should be
> enough to track down the line.
>
> All the best,
> Kevin
>
>
>
> On Wed, Nov 2, 2016 at 8:08 PM, Kevin RUE <kevinru...@gmail.com> wrote:
>
>> Thanks for the feedback!
>>
>> I also tend to prefer *all* the lines being reported (or to be honest,
>> that was really true when I had lots of them; a problem that I largely
>> mitigated by fixing all of them once and subsequently paying more attention
>> while developing).
>>
>> Printing the content of the offending line somewhat helps me spot the
>> line faster (more so for tab issues). But I must admit that showing the
>> whole line is somewhat "overkill". I just started thinking of a compromise
>> being to only show the first N characters of the line, with N being 80
>> minus the number of characters necessary to print the filename and line
>> number.
>>
>> Thanks Martin for pointing out the lines in BiocCheck. (Now I feel bad
>> for not having checked sooner.. hehe!)
>> I think the idea of BiocCheck showing the first 6 offenders in BiocCheck
>> quite nice, as I rarely have more since I use using the RStudio "Tools >
>> Global Options > Code > Display > Show Margin > Margin column: 80" feature.
>>
>> I'll give a go at both approaches (developing BiocCheck and my own
>> scripts)
>>
>> Cheers,
>> Kevin
>>
>>
>> On Wed, Nov 2, 2016 at 7:41 PM, Kasper Daniel Hansen <
>> kasperdanielhan...@gmail.com> wrote:
>>
>>> I would prefer all line numbers reported, but on the other hand I am
>>> indifferent wrt. the content of the line, unless (say) TABs are marked up
>>> somehow.
>>>
>>> Kasper
>>>
>>> On Wed, Nov 2, 2016 at 3:17 PM, Martin Morgan <
>>> martin.mor...@roswellpark.org> wrote:
>>>
>>>> On 11/02/2016 02:49 PM, Kevin RUE wrote:
>>>>
>>>>> Dear all,
>>>>>
>>>>> Just thought I'd share a handful of scripts that I wrote to follow up
>>>>> on
>>>>> certain NOTE messages thrown by R CMD BiocCheck.
>>>>>
>>>>> https://github.com/kevinrue/BiocCheckTools
>>>>>
>>>>> They're very simple, but I occasionally find them quite convenient.
>>>>> Apologies if something similar already exists somewhere :)
>>>>>
>>>>
>>>> Maybe consider creating a diff against the source code that, e.g.,
>>>> reported the first 6 offenders? The relevant lines are near
>>>>
>>>> https://github.com/Bioconductor-mirror/BiocCheck/blob/master
>>>> /R/checks.R#L1081
>>>>
>>>> Martin
>>>>
>>>>
>>>>> All the best,
>>>>> Kevin
>>>>>
>>>>> [[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...{{dropped:2}}
>>>>
>

Re: [Bioc-devel] A handful of check to follow up on R CMD BiocCheck

[Kevin RUE]

Me again :)

Please find attached the first patch to print the first 6 lines over 80
characters long. (I'll get to the tabulation offenders next).

Note that all the offending lines are stored in the "df.length" data.frame.
How about an option like "fullReport=c(FALSE, TRUE)" that print *all* the
offending lines?
The data.frame also stores the content of the lines for the record, but
does not print them. I think Kasper is right: filename and line should be
enough to track down the line.

All the best,
Kevin



On Wed, Nov 2, 2016 at 8:08 PM, Kevin RUE <kevinru...@gmail.com> wrote:

> Thanks for the feedback!
>
> I also tend to prefer *all* the lines being reported (or to be honest,
> that was really true when I had lots of them; a problem that I largely
> mitigated by fixing all of them once and subsequently paying more attention
> while developing).
>
> Printing the content of the offending line somewhat helps me spot the line
> faster (more so for tab issues). But I must admit that showing the whole
> line is somewhat "overkill". I just started thinking of a compromise being
> to only show the first N characters of the line, with N being 80 minus the
> number of characters necessary to print the filename and line number.
>
> Thanks Martin for pointing out the lines in BiocCheck. (Now I feel bad for
> not having checked sooner.. hehe!)
> I think the idea of BiocCheck showing the first 6 offenders in BiocCheck
> quite nice, as I rarely have more since I use using the RStudio "Tools >
> Global Options > Code > Display > Show Margin > Margin column: 80" feature.
>
> I'll give a go at both approaches (developing BiocCheck and my own scripts)
>
> Cheers,
> Kevin
>
>
> On Wed, Nov 2, 2016 at 7:41 PM, Kasper Daniel Hansen <
> kasperdanielhan...@gmail.com> wrote:
>
>> I would prefer all line numbers reported, but on the other hand I am
>> indifferent wrt. the content of the line, unless (say) TABs are marked up
>> somehow.
>>
>> Kasper
>>
>> On Wed, Nov 2, 2016 at 3:17 PM, Martin Morgan <
>> martin.mor...@roswellpark.org> wrote:
>>
>>> On 11/02/2016 02:49 PM, Kevin RUE wrote:
>>>
>>>> Dear all,
>>>>
>>>> Just thought I'd share a handful of scripts that I wrote to follow up on
>>>> certain NOTE messages thrown by R CMD BiocCheck.
>>>>
>>>> https://github.com/kevinrue/BiocCheckTools
>>>>
>>>> They're very simple, but I occasionally find them quite convenient.
>>>> Apologies if something similar already exists somewhere :)
>>>>
>>>
>>> Maybe consider creating a diff against the source code that, e.g.,
>>> reported the first 6 offenders? The relevant lines are near
>>>
>>> https://github.com/Bioconductor-mirror/BiocCheck/blob/master
>>> /R/checks.R#L1081
>>>
>>> Martin
>>>
>>>
>>>> All the best,
>>>> Kevin
>>>>
>>>> [[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...{{dropped:2}}
>>>
>>>
>>> ___
>>> Bioc-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>
>>
>>
>
diff --git a/R/checks.R b/R/checks.R
index f0b5844..9b1f273 100644
--- a/R/checks.R
+++ b/R/checks.R
@@ -1057,14 +1057,12 @@ checkFormatting <- function(pkgdir)
 tablines <- 0L
 badindentlines <- 0L
 ok <- TRUE
-
-df.length <- data.frame(stringsAsFactors=FALSE)
-df.i <- 1
+
 for (file in files)
 {
-pkgname <- getPkgNameFromPkgDir(pkgdir)
 if (file.exists(file) && file.info(file)$size == 0)
 {
+pkgname <- getPkgNameFromPkgDir(pkgdir)
 handleNote(sprintf("Add content to the empty file %s.",
 mungeName(file, pkgname)))
 }
@@ -1074,23 +1072,14 @@ checkFormatting <- function(pkgdir)
 lines <- readLines(file, warn=FALSE)
 totallines <- totallines + length(lines)
 n <- nchar(lines, allowNA=TRUE)
-n <- n[!is.na(n)]; lines <- lines[!is.na(n)]
+n <- n[!is.na(n)]
 
 names(n) <- seq_along(1:length(n))
-long <- which(n > 80)
-
+long <- n[n > 8

Re: [Bioc-devel] A handful of check to follow up on R CMD BiocCheck

[Kevin RUE]

Thanks for the feedback!

I also tend to prefer *all* the lines being reported (or to be honest, that
was really true when I had lots of them; a problem that I largely mitigated
by fixing all of them once and subsequently paying more attention while
developing).

Printing the content of the offending line somewhat helps me spot the line
faster (more so for tab issues). But I must admit that showing the whole
line is somewhat "overkill". I just started thinking of a compromise being
to only show the first N characters of the line, with N being 80 minus the
number of characters necessary to print the filename and line number.

Thanks Martin for pointing out the lines in BiocCheck. (Now I feel bad for
not having checked sooner.. hehe!)
I think the idea of BiocCheck showing the first 6 offenders in BiocCheck
quite nice, as I rarely have more since I use using the RStudio "Tools >
Global Options > Code > Display > Show Margin > Margin column: 80" feature.

I'll give a go at both approaches (developing BiocCheck and my own scripts)

Cheers,
Kevin


On Wed, Nov 2, 2016 at 7:41 PM, Kasper Daniel Hansen <
kasperdanielhan...@gmail.com> wrote:

> I would prefer all line numbers reported, but on the other hand I am
> indifferent wrt. the content of the line, unless (say) TABs are marked up
> somehow.
>
> Kasper
>
> On Wed, Nov 2, 2016 at 3:17 PM, Martin Morgan <
> martin.mor...@roswellpark.org> wrote:
>
>> On 11/02/2016 02:49 PM, Kevin RUE wrote:
>>
>>> Dear all,
>>>
>>> Just thought I'd share a handful of scripts that I wrote to follow up on
>>> certain NOTE messages thrown by R CMD BiocCheck.
>>>
>>> https://github.com/kevinrue/BiocCheckTools
>>>
>>> They're very simple, but I occasionally find them quite convenient.
>>> Apologies if something similar already exists somewhere :)
>>>
>>
>> Maybe consider creating a diff against the source code that, e.g.,
>> reported the first 6 offenders? The relevant lines are near
>>
>> https://github.com/Bioconductor-mirror/BiocCheck/blob/master
>> /R/checks.R#L1081
>>
>> Martin
>>
>>
>>> All the best,
>>> Kevin
>>>
>>> [[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...{{dropped:2}}
>>
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
>

[[alternative HTML version deleted]]

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

[Bioc-devel] A handful of check to follow up on R CMD BiocCheck

[Kevin RUE]

Dear all,

Just thought I'd share a handful of scripts that I wrote to follow up on
certain NOTE messages thrown by R CMD BiocCheck.

https://github.com/kevinrue/BiocCheckTools

They're very simple, but I occasionally find them quite convenient.
Apologies if something similar already exists somewhere :)

All the best,
Kevin

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Question about a package submission

[Kevin RUE]

Seems to be a MS Windows thing indeed.

I have installed R-devel from scratch on a Window machine, then a fresh
installation of BioC (biocLite()), then installed my package, and I get the
error:
> c(GRanges(), GRanges())
Error in c(GRanges(), GRanges()) :
  could not find symbol "recursive" in environment of the generic function

I have also run the following, but then I got the above error message again:
biocLite(c("rtracklayer", "S4Vectors", "XVector", "IRanges",
   "Biostrings", "GenomicRanges", "GenomicAlignments"))


I'll keep digging... :)

Kevin




On Fri, Oct 28, 2016 at 1:48 PM, Kevin RUE <kevinru...@gmail.com> wrote:

> (What puzzles me most is that it builds fine on Travis CI
> <https://travis-ci.org/kevinrue/TVTB>, just not on AppVeyor
> <https://ci.appveyor.com/project/kevinrue/tvtb>).
>
> MS Windows issue?
>
> Best,
> Kevin
>
>
> On Fri, Oct 28, 2016 at 12:30 PM, Kevin RUE <kevinru...@gmail.com> wrote:
>
>> Thanks for sharing your solution Ioannis.
>> Unfortunately, it did not solve my situation on AppVeyor:
>> https://ci.appveyor.com/project/kevinrue/tvtb/build/1.0.29
>>
>> I'll keep trying a few more things.
>>
>> Best
>> Kevin
>>
>> On Fri, Oct 28, 2016 at 12:13 PM, Ioannis Vardaxis <
>> ioannis.varda...@math.ntnu.no> wrote:
>>
>>> For me, running biocLite(c("rtracklayer", "S4Vectors", "XVector",
>>> "IRanges",
>>>"Biostrings", "GenomicRanges", "GenomicAlignments"))
>>> Worked and solved the error.
>>>
>>> Ioannis
>>> --
>>> Ioannis Vardaxis
>>> Stipendiat IMF
>>> NTNU
>>>
>>> From: Kevin RUE <kevinru...@gmail.com>
>>> Date: Friday 28 October 2016 at 12:38
>>> To: Martin Morgan <martin.mor...@roswellpark.org>
>>> Cc: Vincent Carey <st...@channing.harvard.edu>, Ioannis Vardaxis <
>>> ioannis.varda...@math.ntnu.no>, "bioc-devel@r-project.org" <
>>> bioc-devel@r-project.org>
>>> Subject: Re: [Bioc-devel] Question about a package submission
>>>
>>> Dear Martin,
>>>
>>> Sorry for slightly diverting the thread solely based on the error
>>> message:
>>>
>>>> Error in .Primitive("c")(, >>> class "Rle">) :
>>>>   could not find symbol "recursive" in environment of the generic
>>>> function
>>>>
>>>
>>> I can somewhat picture the issue from your explanation.
>>>
>>>> I think that the generic was redefined in base R, but you have packages
>>>> that were installed before the generic was redefined. The methods in the
>>>> installed packages think that they are associated with the generic at the
>>>> time of installation, rather than at runtime.
>>>>
>>>> Unfortunately I think this means manually re-installing even up-to-date
>>>> packages that define S4 "c" methods; likely this is a complicated stack of
>>>> dependencies including rtracklayer, S4Vectors, XVector, IRanges,
>>>> Biostrings, GenomicRanges, GenomicAlignments, ...
>>>>
>>>
>>> However, I cannot figure out how to avoid this issue on AppVeyor (
>>> https://ci.appveyor.com/project/kevinrue/tvtb/build/job/srkobac85uksgcht
>>> ).
>>> I have tried quite about 20 different combinations of settings in my
>>> YAML file (https://github.com/kevinrue/TVTB/commits/master) without
>>> success.
>>> I am not not sure how I may "manually reinstall" said packages, or
>>> somehow make sure the generic is define before all the relevant packages
>>> are installed.
>>>
>>> I'll admit that setting up a second Continuous Integration system is not
>>> the most pressing issue in my life, but I'm so close to succeeding that it
>>> is fairly frustrating to leave it at that :)
>>>
>>> Kind regards,
>>> Kevin
>>>
>>>
>>> On Thu, Oct 27, 2016 at 1:28 PM, Martin Morgan <
>>> martin.mor...@roswellpark.org> wrote:
>>>
>>>> On 10/27/2016 08:22 AM, Kevin RUE wrote:
>>>>
>>>>> Hi Ioannis, Vincent,
>>>>>
>>>>> I'm in the middle of debugging a similar situation myself, which may
>>>>> provide a reproducible example at a package level.
>>>>>
>>>>> I am in the pro

Re: [Bioc-devel] Question about a package submission

[Kevin RUE]

(What puzzles me most is that it builds fine on Travis CI
<https://travis-ci.org/kevinrue/TVTB>, just not on AppVeyor
<https://ci.appveyor.com/project/kevinrue/tvtb>).

MS Windows issue?

Best,
Kevin


On Fri, Oct 28, 2016 at 12:30 PM, Kevin RUE <kevinru...@gmail.com> wrote:

> Thanks for sharing your solution Ioannis.
> Unfortunately, it did not solve my situation on AppVeyor:
> https://ci.appveyor.com/project/kevinrue/tvtb/build/1.0.29
>
> I'll keep trying a few more things.
>
> Best
> Kevin
>
> On Fri, Oct 28, 2016 at 12:13 PM, Ioannis Vardaxis <
> ioannis.varda...@math.ntnu.no> wrote:
>
>> For me, running biocLite(c("rtracklayer", "S4Vectors", "XVector",
>> "IRanges",
>>"Biostrings", "GenomicRanges", "GenomicAlignments"))
>> Worked and solved the error.
>>
>> Ioannis
>> --
>> Ioannis Vardaxis
>> Stipendiat IMF
>> NTNU
>>
>> From: Kevin RUE <kevinru...@gmail.com>
>> Date: Friday 28 October 2016 at 12:38
>> To: Martin Morgan <martin.mor...@roswellpark.org>
>> Cc: Vincent Carey <st...@channing.harvard.edu>, Ioannis Vardaxis <
>> ioannis.varda...@math.ntnu.no>, "bioc-devel@r-project.org" <
>> bioc-devel@r-project.org>
>> Subject: Re: [Bioc-devel] Question about a package submission
>>
>> Dear Martin,
>>
>> Sorry for slightly diverting the thread solely based on the error message:
>>
>>> Error in .Primitive("c")(, >> "Rle">) :
>>>   could not find symbol "recursive" in environment of the generic
>>> function
>>>
>>
>> I can somewhat picture the issue from your explanation.
>>
>>> I think that the generic was redefined in base R, but you have packages
>>> that were installed before the generic was redefined. The methods in the
>>> installed packages think that they are associated with the generic at the
>>> time of installation, rather than at runtime.
>>>
>>> Unfortunately I think this means manually re-installing even up-to-date
>>> packages that define S4 "c" methods; likely this is a complicated stack of
>>> dependencies including rtracklayer, S4Vectors, XVector, IRanges,
>>> Biostrings, GenomicRanges, GenomicAlignments, ...
>>>
>>
>> However, I cannot figure out how to avoid this issue on AppVeyor (
>> https://ci.appveyor.com/project/kevinrue/tvtb/build/job/srkobac85uksgcht
>> ).
>> I have tried quite about 20 different combinations of settings in my YAML
>> file (https://github.com/kevinrue/TVTB/commits/master) without success.
>> I am not not sure how I may "manually reinstall" said packages, or
>> somehow make sure the generic is define before all the relevant packages
>> are installed.
>>
>> I'll admit that setting up a second Continuous Integration system is not
>> the most pressing issue in my life, but I'm so close to succeeding that it
>> is fairly frustrating to leave it at that :)
>>
>> Kind regards,
>> Kevin
>>
>>
>> On Thu, Oct 27, 2016 at 1:28 PM, Martin Morgan <
>> martin.mor...@roswellpark.org> wrote:
>>
>>> On 10/27/2016 08:22 AM, Kevin RUE wrote:
>>>
>>>> Hi Ioannis, Vincent,
>>>>
>>>> I'm in the middle of debugging a similar situation myself, which may
>>>> provide a reproducible example at a package level.
>>>>
>>>> I am in the process of setting up AppVeyor CI for my package, and my R
>>>> CMD
>>>> check fails because of the same error.
>>>> https://ci.appveyor.com/project/kevinrue/tvtb/build/1.0.11
>>>>
>>>> To debug the issue, I am also currently updating my local installation
>>>> to
>>>> the latest devel packages (until biocValid() returns TRUE).
>>>> Once that is done, I may be able to provide a more practical minimal
>>>> working example for the issue (i.e. the code in one of my man pages).
>>>>
>>>
>>> I think that the generic was redefined in base R, but you have packages
>>> that were installed before the generic was redefined. The methods in the
>>> installed packages think that they are associated with the generic at the
>>> time of installation, rather than at runtime.
>>>
>>> Unfortunately I think this means manually re-installing even up-to-date
>>> packages that define S4 "c" methods; likely this is a complicated stack of
>>> depend

Re: [Bioc-devel] Question about a package submission

[Kevin RUE]

Thanks for sharing your solution Ioannis.
Unfortunately, it did not solve my situation on AppVeyor:
https://ci.appveyor.com/project/kevinrue/tvtb/build/1.0.29

I'll keep trying a few more things.

Best
Kevin

On Fri, Oct 28, 2016 at 12:13 PM, Ioannis Vardaxis <
ioannis.varda...@math.ntnu.no> wrote:

> For me, running biocLite(c("rtracklayer", "S4Vectors", "XVector",
> "IRanges",
>"Biostrings", "GenomicRanges", "GenomicAlignments"))
> Worked and solved the error.
>
> Ioannis
> --
> Ioannis Vardaxis
> Stipendiat IMF
> NTNU
>
> From: Kevin RUE <kevinru...@gmail.com>
> Date: Friday 28 October 2016 at 12:38
> To: Martin Morgan <martin.mor...@roswellpark.org>
> Cc: Vincent Carey <st...@channing.harvard.edu>, Ioannis Vardaxis <
> ioannis.varda...@math.ntnu.no>, "bioc-devel@r-project.org" <
> bioc-devel@r-project.org>
> Subject: Re: [Bioc-devel] Question about a package submission
>
> Dear Martin,
>
> Sorry for slightly diverting the thread solely based on the error message:
>
>> Error in .Primitive("c")(, > "Rle">) :
>>   could not find symbol "recursive" in environment of the generic function
>>
>
> I can somewhat picture the issue from your explanation.
>
>> I think that the generic was redefined in base R, but you have packages
>> that were installed before the generic was redefined. The methods in the
>> installed packages think that they are associated with the generic at the
>> time of installation, rather than at runtime.
>>
>> Unfortunately I think this means manually re-installing even up-to-date
>> packages that define S4 "c" methods; likely this is a complicated stack of
>> dependencies including rtracklayer, S4Vectors, XVector, IRanges,
>> Biostrings, GenomicRanges, GenomicAlignments, ...
>>
>
> However, I cannot figure out how to avoid this issue on AppVeyor (
> https://ci.appveyor.com/project/kevinrue/tvtb/build/job/srkobac85uksgcht).
> I have tried quite about 20 different combinations of settings in my YAML
> file (https://github.com/kevinrue/TVTB/commits/master) without success.
> I am not not sure how I may "manually reinstall" said packages, or somehow
> make sure the generic is define before all the relevant packages are
> installed.
>
> I'll admit that setting up a second Continuous Integration system is not
> the most pressing issue in my life, but I'm so close to succeeding that it
> is fairly frustrating to leave it at that :)
>
> Kind regards,
> Kevin
>
>
> On Thu, Oct 27, 2016 at 1:28 PM, Martin Morgan <
> martin.mor...@roswellpark.org> wrote:
>
>> On 10/27/2016 08:22 AM, Kevin RUE wrote:
>>
>>> Hi Ioannis, Vincent,
>>>
>>> I'm in the middle of debugging a similar situation myself, which may
>>> provide a reproducible example at a package level.
>>>
>>> I am in the process of setting up AppVeyor CI for my package, and my R
>>> CMD
>>> check fails because of the same error.
>>> https://ci.appveyor.com/project/kevinrue/tvtb/build/1.0.11
>>>
>>> To debug the issue, I am also currently updating my local installation to
>>> the latest devel packages (until biocValid() returns TRUE).
>>> Once that is done, I may be able to provide a more practical minimal
>>> working example for the issue (i.e. the code in one of my man pages).
>>>
>>
>> I think that the generic was redefined in base R, but you have packages
>> that were installed before the generic was redefined. The methods in the
>> installed packages think that they are associated with the generic at the
>> time of installation, rather than at runtime.
>>
>> Unfortunately I think this means manually re-installing even up-to-date
>> packages that define S4 "c" methods; likely this is a complicated stack of
>> dependencies including rtracklayer, S4Vectors, XVector, IRanges,
>> Biostrings, GenomicRanges, GenomicAlignments, ...
>>
>> Marin
>>
>>
>>
>>> Best,
>>> Kevin
>>>
>>>
>>>
>>> On Thu, Oct 27, 2016 at 12:23 PM, Vincent Carey <
>>> st...@channing.harvard.edu>
>>> wrote:
>>>
>>> Please send a reproducible example with value of sessionInfo() at time of
>>>> error.
>>>>
>>>> On Thu, Oct 27, 2016 at 7:06 AM, Ioannis Vardaxis <
>>>> ioannis.varda...@math.ntnu.no> wrote:
>>>>
>>>> Hi,
>>>>>
>>>>> I am usi

Re: [Bioc-devel] Question about a package submission

[Kevin RUE]

Dear Martin,

Sorry for slightly diverting the thread solely based on the error message:

> Error in .Primitive("c")(,  "Rle">) :
>   could not find symbol "recursive" in environment of the generic function
>

I can somewhat picture the issue from your explanation.

> I think that the generic was redefined in base R, but you have packages
> that were installed before the generic was redefined. The methods in the
> installed packages think that they are associated with the generic at the
> time of installation, rather than at runtime.
>
> Unfortunately I think this means manually re-installing even up-to-date
> packages that define S4 "c" methods; likely this is a complicated stack of
> dependencies including rtracklayer, S4Vectors, XVector, IRanges,
> Biostrings, GenomicRanges, GenomicAlignments, ...
>

However, I cannot figure out how to avoid this issue on AppVeyor (
https://ci.appveyor.com/project/kevinrue/tvtb/build/job/srkobac85uksgcht).
I have tried quite about 20 different combinations of settings in my YAML
file (https://github.com/kevinrue/TVTB/commits/master) without success.
I am not not sure how I may "manually reinstall" said packages, or somehow
make sure the generic is define before all the relevant packages are
installed.

I'll admit that setting up a second Continuous Integration system is not
the most pressing issue in my life, but I'm so close to succeeding that it
is fairly frustrating to leave it at that :)

Kind regards,
Kevin


On Thu, Oct 27, 2016 at 1:28 PM, Martin Morgan <
martin.mor...@roswellpark.org> wrote:

> On 10/27/2016 08:22 AM, Kevin RUE wrote:
>
>> Hi Ioannis, Vincent,
>>
>> I'm in the middle of debugging a similar situation myself, which may
>> provide a reproducible example at a package level.
>>
>> I am in the process of setting up AppVeyor CI for my package, and my R CMD
>> check fails because of the same error.
>> https://ci.appveyor.com/project/kevinrue/tvtb/build/1.0.11
>>
>> To debug the issue, I am also currently updating my local installation to
>> the latest devel packages (until biocValid() returns TRUE).
>> Once that is done, I may be able to provide a more practical minimal
>> working example for the issue (i.e. the code in one of my man pages).
>>
>
> I think that the generic was redefined in base R, but you have packages
> that were installed before the generic was redefined. The methods in the
> installed packages think that they are associated with the generic at the
> time of installation, rather than at runtime.
>
> Unfortunately I think this means manually re-installing even up-to-date
> packages that define S4 "c" methods; likely this is a complicated stack of
> dependencies including rtracklayer, S4Vectors, XVector, IRanges,
> Biostrings, GenomicRanges, GenomicAlignments, ...
>
> Marin
>
>
>
>> Best,
>> Kevin
>>
>>
>>
>> On Thu, Oct 27, 2016 at 12:23 PM, Vincent Carey <
>> st...@channing.harvard.edu>
>> wrote:
>>
>> Please send a reproducible example with value of sessionInfo() at time of
>>> error.
>>>
>>> On Thu, Oct 27, 2016 at 7:06 AM, Ioannis Vardaxis <
>>> ioannis.varda...@math.ntnu.no> wrote:
>>>
>>> Hi,
>>>>
>>>> I am using the R-devel version for writing an R package. I tried to use
>>>> the c(Granges,Granges) command to merge two Granges objects and I get
>>>> the
>>>> following error:
>>>>
>>>> Error in .Primitive("c")(, >>> "Rle">) :
>>>>   could not find symbol "recursive" in environment of the generic
>>>>
>>> function
>>>
>>>>
>>>> I also get the same error when I use InteractionSet::GInteractions(
>>>>
>>> Granges,
>>>
>>>> Granges).
>>>>
>>>> I downloaded IRanges, GenomicRanges and InteractionSet packages from the
>>>> source.
>>>>
>>>> How can I solve this error?
>>>>
>>>> Best,
>>>> Ioannis
>>>> --
>>>> Ioannis Vardaxis
>>>> Stipendiat IMF
>>>> NTNU
>>>>
>>>> [[alternative HTML version deleted]]
>>>>
>>>> ___
>>>> Bioc-devel@r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>>
>>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __

Re: [Bioc-devel] lumi package is not available

[Kevin RUE]

Dear T.Wang.

First of all, as a general rule, please include the sessionInfo() output
and command that caused the error to facilitate useful replies. Here I will
assume that you are using the devel branch of BioC on the latest R/BioC
setup available.

As far as I know, your problem is still a consequence of the recent
release, affecting all packages dependencies which have not passed a single
R CMD check on the new devel branch (the issue has been reported on this
mailing list for a few packages already; e.g. Biobase, now resolved). the
situation should resolve after all relevant packages pass at least one
build cycle without error:

   - For the lumi package, you can see the R CMD check failing in all
   platforms build report: http://bioconductor.org/checkResults/devel/bioc-
   LATEST/lumi/
   - Note that this is also the case for the release branch
   http://bioconductor.org/checkResults/3.4/bioc-LATEST/lumi/
   - As a result, the package was not released yet on the devel branch of
   the repository, and the landing page of the lumi package is not available
   yet either (click the lumi link in the build report above, which will take
   you to http://bioconductor.org/packages/3.5/bioc/html/lumi.html).
   - Another artifact of this situation is that the landing page of the
   release branch still claims to be the devel branch
   http://bioconductor.org/packages/3.4/bioc/html/lumi.html

Solution (as far as I know):

   - Simply wait that the package (and its dependencies) passes R CMD check
   on all platforms, which will then trigger its release on the BioC
   repository.
   - In other circumstances, I would have suggested to install the lumi
   package from the release branch in the meantime, but given the build errors
   there as well, you might have to download older sources of the package, and
   install them using "install.packages(..., repos = NULL)" rather than
   "biocLite(...)"

Last but not least, I will also point out that a quick check of the
Bioconductor Git Mirror suggests that the latest BioC release where the
lumi package code was updated is release-3.1 (
https://github.com/Bioconductor-mirror/lumi/tree/release-3.1). Maybe some
code updates are overdue now for package to build succesfully.

Kind regads,
Kevin








On Fri, Oct 28, 2016 at 9:20 AM, 王棣台  wrote:

> Hi, all
>
> I am the author of package "anamiR".
> I got a Warning message "Warning: dependency ''lumi" is not available"
> when I installed anamiR.
> Also, I tried other packages which depend on "lumi" package, and all got
> the same warning message.
> Is there any way I can solve this problem?
>
> Best regards,
> T.Wang
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Question about a package submission

[Kevin RUE]

Hi Ioannis, Vincent,

I'm in the middle of debugging a similar situation myself, which may
provide a reproducible example at a package level.

I am in the process of setting up AppVeyor CI for my package, and my R CMD
check fails because of the same error.
https://ci.appveyor.com/project/kevinrue/tvtb/build/1.0.11

To debug the issue, I am also currently updating my local installation to
the latest devel packages (until biocValid() returns TRUE).
Once that is done, I may be able to provide a more practical minimal
working example for the issue (i.e. the code in one of my man pages).

Best,
Kevin



On Thu, Oct 27, 2016 at 12:23 PM, Vincent Carey 
wrote:

> Please send a reproducible example with value of sessionInfo() at time of
> error.
>
> On Thu, Oct 27, 2016 at 7:06 AM, Ioannis Vardaxis <
> ioannis.varda...@math.ntnu.no> wrote:
>
> > Hi,
> >
> > I am using the R-devel version for writing an R package. I tried to use
> > the c(Granges,Granges) command to merge two Granges objects and I get the
> > following error:
> >
> > Error in .Primitive("c")(,  > "Rle">) :
> >   could not find symbol "recursive" in environment of the generic
> function
> >
> > I also get the same error when I use InteractionSet::GInteractions(
> Granges,
> > Granges).
> >
> > I downloaded IRanges, GenomicRanges and InteractionSet packages from the
> > source.
> >
> > How can I solve this error?
> >
> > Best,
> > Ioannis
> > --
> > Ioannis Vardaxis
> > Stipendiat IMF
> > NTNU
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Fwd: BiocInstaller::useDevel() Error: 'devel' version requires a more recent R

[Kevin RUE]

Hi again,

I applied your YAML config in my latest commit
<https://github.com/kevinrue/TVTB/blob/master/.travis.yml>
But in my (ongoing) Travis build
<https://travis-ci.org/kevinrue/TVTB/builds/169301723>, I can already see
that it has installed the wrong R version (3.1.1, not devel), see line 370
<https://travis-ci.org/kevinrue/TVTB/builds/169301723#L370>

$ curl -Lo /tmp/R-3.3.1.xz https://s3.amazonaws.com/rstudio-travis/R-3.3.1.xz

As opposed to the configuration I posted earlier that states:
r: devel

which did install R-devel (line 370
<https://travis-ci.org/kevinrue/TVTB/builds/169258984#L370> of the previous
build):

$curl -Lo /tmp/R-devel.xz https://s3.amazonaws.com/rstudio-travis/R-devel.xz

I honestly don't know how YAML instructions work on Travis, but maybe some
action must be taken before "bioc-devel" becomes synonym to "R-devel" ?

Thanks for your help.
Kevin


On Thu, Oct 20, 2016 at 4:49 PM, Lukas Weber <lukmwe...@gmail.com> wrote:

> Hi Kevin,
>
> I have been using the following setup in my .travis.yml file. Travis CI
> should automatically use the correct version of R for the Bioconductor
> version specified in the "r: bioc-devel" line (you can replace this with
> "r: bioc-release" to use the release version). There is some more
> information here: https://docs.travis-ci.com/user/languages/r/ (see the
> Bioconductor section).
>
> language: r
> r: bioc-devel
> sudo: false
> cache: packages
> r_github_packages:
>   - jimhester/covr
> after_success:
>   - Rscript -e 'covr::codecov()'
>
> The additional "covr" lines are for checking unit test code coverage with
> codecov.
>
> Lukas
>
>
> On Thu, Oct 20, 2016 at 4:51 PM, Kevin RUE <kevinru...@gmail.com> wrote:
>
>> Actually, nevermind, I think I solved the issue of R-devel with the
>> following YAML instructions:
>>
>> language: r
>> r: devel
>>
>> before_install:
>> - Rscript -e 'source(file = "http://bioconductor.org/biocLite.R
>> ");tryCatch(useDevel(devel = TRUE), error = function(err){message(err)})'
>> - if [[ "$TRAVIS_OS_NAME" == "linux" ]]; then tlmgr install bera
>> nowidow parnotes marginfix; fi
>>
>> Now the build <https://travis-ci.org/kevinrue/TVTB/builds/169246652> only
>>
>> fails because S4Vectors is not available on the new devel branch, but I'm
>> sure that's going to resolve itself within the next couple of builds/days.
>>
>> All the best,
>> Kevin
>>
>>
>> Just for the record, prior to the recent BioC release, I had the following
>> (working) configuration. I have never been sure how elegant that was (I
>> may
>> have combined some redundant bioc instructions):
>>
>> language: r
>> use_bioc: true
>> bioc_required: true
>> r: bioc-release
>> before_install:
>> - Rscript -e 'source(file = "http://bioconductor.org/biocLite.R
>> ");tryCatch(useDevel(devel = TRUE), error = function(err){message(err)})'
>> - if [[ "$TRAVIS_OS_NAME" == "linux" ]]; then tlmgr install bera
>> nowidow parnotes marginfix; fi
>>
>>
>>
>> On Thu, Oct 20, 2016 at 1:31 PM, Martin Morgan <
>> martin.mor...@roswellpark.org> wrote:
>>
>> > Sorry, can you try one more time? Thanks, Martin
>> >
>> >
>> > On 10/20/2016 06:06 AM, Rodriguez Martinez, Andrea wrote:
>> >
>> >> Thanks for your reply.
>> >>
>> >>
>> >> I have successfully removed BiocInstaller by hand, restart R, and then,
>> >> installed with:
>> >>
>> >>
>> >> source("https://bioconductor.org/biocLite.R;)
>> >>>
>> >> Warning in install.packages :
>> >>   URL
>> >> 'https://bioconductor.org/packages/3.4/bioc/bin/macosx/maver
>> >> icks/contrib/3.4/PACKAGES.gz':
>> >> status was '404 Not Found'
>> >> Warning in install.packages :
>> >>   URL
>> >> 'https://bioconductor.org/packages/3.4/bioc/bin/macosx/maver
>> >> icks/contrib/3.4/PACKAGES':
>> >> status was '404 Not Found'
>> >> Warning in install.packages :
>> >>   unable to access index for repository
>> >> https://bioconductor.org/packages/3.4/bioc/bin/macosx/maveri
>> >> cks/contrib/3.4:
>> >>   cannot download all files
>> >> installing the source package ‘BiocInstaller’
>> >>
>> >> trying URL
>> >> 'https://bioconductor.org/packages/3.4/bioc/src/contrib/Bioc
>

Re: [Bioc-devel] Fwd: BiocInstaller::useDevel() Error: 'devel' version requires a more recent R

[Kevin RUE]

Thanks Lukas,

I remember trying "r: bioc-devel" and having issues with it a while ago,
but maybe I had an overall incorrect combination of YAML instructions, so
I'll try again with your config and see if that works better. Things moving
a lot during the release process, YAML files may just invalidate overnight,
but only temporarily.

At the moment, I'm still just having the issue of S4Vectors not being
available on the devel branch of BioC (apart from that, it seems my YAML
now uses the correct version of R (devel); now, I just wonder if r:
bioc-devel would get S4Vectors from the release branch if it's not
available from the devel branch). As I wrote previously, I'm sure this is
some minor issue that will disappear shortly (For S4Vectors. the R CMD
check only fails for a unit test, which might prevent the package from
being released on the devel branch, but that's another problem.)

I'll play with my YAML file and find out how to make Travis happy again,
before taking any risk pushing to Bioc, be it devel or release.

In any case, thanks for your advice !
Kevin


On Thu, Oct 20, 2016 at 4:49 PM, Lukas Weber <lukmwe...@gmail.com> wrote:

> Hi Kevin,
>
> I have been using the following setup in my .travis.yml file. Travis CI
> should automatically use the correct version of R for the Bioconductor
> version specified in the "r: bioc-devel" line (you can replace this with
> "r: bioc-release" to use the release version). There is some more
> information here: https://docs.travis-ci.com/user/languages/r/ (see the
> Bioconductor section).
>
> language: r
> r: bioc-devel
> sudo: false
> cache: packages
> r_github_packages:
>   - jimhester/covr
> after_success:
>   - Rscript -e 'covr::codecov()'
>
> The additional "covr" lines are for checking unit test code coverage with
> codecov.
>
> Lukas
>
>
> On Thu, Oct 20, 2016 at 4:51 PM, Kevin RUE <kevinru...@gmail.com> wrote:
>
>> Actually, nevermind, I think I solved the issue of R-devel with the
>> following YAML instructions:
>>
>> language: r
>> r: devel
>>
>> before_install:
>> - Rscript -e 'source(file = "http://bioconductor.org/biocLite.R
>> ");tryCatch(useDevel(devel = TRUE), error = function(err){message(err)})'
>> - if [[ "$TRAVIS_OS_NAME" == "linux" ]]; then tlmgr install bera
>> nowidow parnotes marginfix; fi
>>
>> Now the build <https://travis-ci.org/kevinrue/TVTB/builds/169246652> only
>>
>> fails because S4Vectors is not available on the new devel branch, but I'm
>> sure that's going to resolve itself within the next couple of builds/days.
>>
>> All the best,
>> Kevin
>>
>>
>> Just for the record, prior to the recent BioC release, I had the following
>> (working) configuration. I have never been sure how elegant that was (I
>> may
>> have combined some redundant bioc instructions):
>>
>> language: r
>> use_bioc: true
>> bioc_required: true
>> r: bioc-release
>> before_install:
>> - Rscript -e 'source(file = "http://bioconductor.org/biocLite.R
>> ");tryCatch(useDevel(devel = TRUE), error = function(err){message(err)})'
>> - if [[ "$TRAVIS_OS_NAME" == "linux" ]]; then tlmgr install bera
>> nowidow parnotes marginfix; fi
>>
>>
>>
>> On Thu, Oct 20, 2016 at 1:31 PM, Martin Morgan <
>> martin.mor...@roswellpark.org> wrote:
>>
>> > Sorry, can you try one more time? Thanks, Martin
>> >
>> >
>> > On 10/20/2016 06:06 AM, Rodriguez Martinez, Andrea wrote:
>> >
>> >> Thanks for your reply.
>> >>
>> >>
>> >> I have successfully removed BiocInstaller by hand, restart R, and then,
>> >> installed with:
>> >>
>> >>
>> >> source("https://bioconductor.org/biocLite.R;)
>> >>>
>> >> Warning in install.packages :
>> >>   URL
>> >> 'https://bioconductor.org/packages/3.4/bioc/bin/macosx/maver
>> >> icks/contrib/3.4/PACKAGES.gz':
>> >> status was '404 Not Found'
>> >> Warning in install.packages :
>> >>   URL
>> >> 'https://bioconductor.org/packages/3.4/bioc/bin/macosx/maver
>> >> icks/contrib/3.4/PACKAGES':
>> >> status was '404 Not Found'
>> >> Warning in install.packages :
>> >>   unable to access index for repository
>> >> https://bioconductor.org/packages/3.4/bioc/bin/macosx/maveri
>> >> cks/contrib/3.4:
>> >>   cannot download all files
>> >> installing the source pa

Re: [Bioc-devel] Fwd: BiocInstaller::useDevel() Error: 'devel' version requires a more recent R

[Kevin RUE]

Actually, nevermind, I think I solved the issue of R-devel with the
following YAML instructions:

language: r
r: devel

before_install:
- Rscript -e 'source(file = "http://bioconductor.org/biocLite.R
");tryCatch(useDevel(devel = TRUE), error = function(err){message(err)})'
- if [[ "$TRAVIS_OS_NAME" == "linux" ]]; then tlmgr install bera
nowidow parnotes marginfix; fi

Now the build  only
fails because S4Vectors is not available on the new devel branch, but I'm
sure that's going to resolve itself within the next couple of builds/days.

All the best,
Kevin


Just for the record, prior to the recent BioC release, I had the following
(working) configuration. I have never been sure how elegant that was (I may
have combined some redundant bioc instructions):

language: r
use_bioc: true
bioc_required: true
r: bioc-release
before_install:
- Rscript -e 'source(file = "http://bioconductor.org/biocLite.R
");tryCatch(useDevel(devel = TRUE), error = function(err){message(err)})'
- if [[ "$TRAVIS_OS_NAME" == "linux" ]]; then tlmgr install bera
nowidow parnotes marginfix; fi



On Thu, Oct 20, 2016 at 1:31 PM, Martin Morgan <
martin.mor...@roswellpark.org> wrote:

> Sorry, can you try one more time? Thanks, Martin
>
>
> On 10/20/2016 06:06 AM, Rodriguez Martinez, Andrea wrote:
>
>> Thanks for your reply.
>>
>>
>> I have successfully removed BiocInstaller by hand, restart R, and then,
>> installed with:
>>
>>
>> source("https://bioconductor.org/biocLite.R;)
>>>
>> Warning in install.packages :
>>   URL
>> 'https://bioconductor.org/packages/3.4/bioc/bin/macosx/maver
>> icks/contrib/3.4/PACKAGES.gz':
>> status was '404 Not Found'
>> Warning in install.packages :
>>   URL
>> 'https://bioconductor.org/packages/3.4/bioc/bin/macosx/maver
>> icks/contrib/3.4/PACKAGES':
>> status was '404 Not Found'
>> Warning in install.packages :
>>   unable to access index for repository
>> https://bioconductor.org/packages/3.4/bioc/bin/macosx/maveri
>> cks/contrib/3.4:
>>   cannot download all files
>> installing the source package ‘BiocInstaller’
>>
>> trying URL
>> 'https://bioconductor.org/packages/3.4/bioc/src/contrib/Bioc
>> Installer_1.24.0.tar.gz'
>> Content type 'application/x-gzip' length 17756 bytes (17 KB)
>> ==
>> downloaded 17 KB
>>
>> * installing *source* package ‘BiocInstaller’ ...
>> ** R
>> ** inst
>> ** preparing package for lazy loading
>> ** help
>> *** installing help indices
>> ** building package indices
>> ** testing if installed package can be loaded
>> Bioconductor version 3.4 (BiocInstaller 1.24.0), ?biocLite for help
>> Warning: Bioconductor version 3.4 is too old for R version 3.4.0; see
>>   https://bioconductor.org/install/#troubleshoot-biocinstaller
>> * DONE (BiocInstaller)
>>
>> The downloaded source packages are in
>> ‘/private/var/folders/z8/8jwlrtqx3270h05ncg1xwzs8gn/T/
>> RtmpRmVsc5/downloaded_packages’
>> Bioconductor version 3.4 (BiocInstaller 1.24.0), ?biocLite for help
>>
>> BiocInstaller::useDevel()
>>>
>> Error: 'devel' version requires a more recent R
>>
>
>
>>
>> Thanks very much,
>>
>> Andrea
>>
>>
>>
>> 
>> *From:* Bioc-devel  on behalf of
>> Martin Morgan 
>> *Sent:* 20 October 2016 10:28:34
>> *To:* Michael Lawrence; bioc-devel@r-project.org
>> *Subject:* Re: [Bioc-devel] Fwd: BiocInstaller::useDevel() Error:
>>
>> 'devel' version requires a more recent R
>>
>> On 10/20/2016 12:00 AM, Michael Lawrence wrote:
>>
>>> -- Forwarded message --
>>> From: Rodriguez Martinez, Andrea >> mperial.ac.uk>
>>> Date: Wed, Oct 19, 2016 at 3:33 PM
>>> Subject: Re: [Bioc-devel] BiocInstaller::useDevel() Error: 'devel'
>>> version requires a more recent R
>>> To: Michael Lawrence 
>>>
>>>
>>> Sorry again,
>>>
>>> I have just installed the R-devel version and now I get the following
>>> error: "Bioconductor does not yet support R version 3.4.0"
>>>
>>
>> Thank you, you installed BiocInstaller in R-devel (R-3.4) before
>> Bioconductor officially supported R-3.4, and need to manually remove and
>> re-install BiocInstaller.
>>
>> I have updated the online configure, so in a new session, try to load
>> the BiocInstaller package and you should now see
>>
>> Bioconductor version 3.4 is too old for R version 3.4.0; see
>>https://bioconductor.org/install/#troubleshoot-biocinstaller
>>
>> The instructions are to remove BiocInstaller by hand
>>
>>remove.packages("BiocInstaller")
>>remove.packages("BiocInstaller") # fails, if not then investigate
>>
>> and install again
>>
>>source("https://bioconductor.org/biocLite.R;)
>>
>> Martin
>>
>>
>>> Thanks,
>>>
>>> Andrea
>>>
>>> 
>>> From: Rodriguez Martinez, Andrea
>>> Sent: 19 October 2016 23:13:06

Re: [Bioc-devel] Fwd: BiocInstaller::useDevel() Error: 'devel' version requires a more recent R

[Kevin RUE]

By the way, the reason why I am asking is that BiocCheck raised the
following warning, after I upgraded my system to R-3.4 and Bioc-devel:

WARNING: Update R version dependency from 3.3 to 3.4

Now that I updated the R version dependency, everything is fine on my
updated machine, but the Travis build fails because it doesn't have 3.4
installed.
But I suppose that the BioC devel-build servers have R-3.4 installed, right?

All the best, and sorry for the additional email,
Kevin


On Thu, Oct 20, 2016 at 3:07 PM, Kevin RUE <kevinru...@gmail.com> wrote:

> Hi all,
>
> First of all, thanks for the question and answers, it helped me a lot on
> my local machine.
>
> While we're on the topic, does anyone know when R-devel (R-3.4) will be
> available on Travis CI ? Because it is running R-3.3.1, and therefore
> produces the same error message when I instruct Travis to install packages
> from the devel branch.
>
> I suppose this is something that I need to post on the Travis GitHub isse
> tracker, right, considering the following message?
>
> R for Travis-CI is not officially supported, but is community maintained.
> Please file any issues at https://github.com/travis-ci/travis-ci/issues
> and mention @craigcitro, @hadley and @jimhester in the issue
> Best,
> Kevin
>
> On Thu, Oct 20, 2016 at 11:06 AM, Rodriguez Martinez, Andrea <
> andrea.rodriguez-martine...@imperial.ac.uk> wrote:
>
>> Thanks for your reply.
>>
>>
>> I have successfully removed BiocInstaller by hand, restart R, and then,
>> installed with:
>>
>>
>> > source("https://bioconductor.org/biocLite.R;)
>> Warning in install.packages :
>>   URL 'https://bioconductor.org/packages/3.4/bioc/bin/macosx/maver
>> icks/contrib/3.4/PACKAGES.gz': status was '404 Not Found'
>> Warning in install.packages :
>>   URL 'https://bioconductor.org/packages/3.4/bioc/bin/macosx/maver
>> icks/contrib/3.4/PACKAGES': status was '404 Not Found'
>> Warning in install.packages :
>>   unable to access index for repository https://bioconductor.org/packa
>> ges/3.4/bioc/bin/macosx/mavericks/contrib/3.4:
>>   cannot download all files
>> installing the source package ‘BiocInstaller’
>>
>> trying URL 'https://bioconductor.org/packages/3.4/bioc/src/contrib/Bioc
>> Installer_1.24.0.tar.gz'
>> Content type 'application/x-gzip' length 17756 bytes (17 KB)
>> ==
>> downloaded 17 KB
>>
>> * installing *source* package ‘BiocInstaller’ ...
>> ** R
>> ** inst
>> ** preparing package for lazy loading
>> ** help
>> *** installing help indices
>> ** building package indices
>> ** testing if installed package can be loaded
>> Bioconductor version 3.4 (BiocInstaller 1.24.0), ?biocLite for help
>> Warning: Bioconductor version 3.4 is too old for R version 3.4.0; see
>>   https://bioconductor.org/install/#troubleshoot-biocinstaller
>> * DONE (BiocInstaller)
>>
>> The downloaded source packages are in
>> ‘/private/var/folders/z8/8jwlrtqx3270h05ncg1xwzs8gn/T/
>> RtmpRmVsc5/downloaded_packages’
>> Bioconductor version 3.4 (BiocInstaller 1.24.0), ?biocLite for help
>>
>> > BiocInstaller::useDevel()
>> Error: 'devel' version requires a more recent R
>>
>>
>> Thanks very much,
>>
>> Andrea
>>
>>
>>
>> 
>> From: Bioc-devel <bioc-devel-boun...@r-project.org> on behalf of Martin
>> Morgan <martin.mor...@roswellpark.org>
>> Sent: 20 October 2016 10:28:34
>> To: Michael Lawrence; bioc-devel@r-project.org
>> Subject: Re: [Bioc-devel] Fwd: BiocInstaller::useDevel() Error: 'devel'
>> version requires a more recent R
>>
>> On 10/20/2016 12:00 AM, Michael Lawrence wrote:
>> > -- Forwarded message --
>> > From: Rodriguez Martinez, Andrea <andrea.rodriguez-martinez13@i
>> mperial.ac.uk>
>> > Date: Wed, Oct 19, 2016 at 3:33 PM
>> > Subject: Re: [Bioc-devel] BiocInstaller::useDevel() Error: 'devel'
>> > version requires a more recent R
>> > To: Michael Lawrence <lawrence.mich...@gene.com>
>> >
>> >
>> > Sorry again,
>> >
>> > I have just installed the R-devel version and now I get the following
>> > error: "Bioconductor does not yet support R version 3.4.0"
>>
>> Thank you, you installed BiocInstaller in R-devel (R-3.4) before
>> Bioconductor officially supported R-3.4, and need to manually remove and
>> re-install BiocInstaller.
>>
>> I have updated the online configure, so i

Re: [Bioc-devel] Fwd: BiocInstaller::useDevel() Error: 'devel' version requires a more recent R

[Kevin RUE]

Hi all,

First of all, thanks for the question and answers, it helped me a lot on my
local machine.

While we're on the topic, does anyone know when R-devel (R-3.4) will be
available on Travis CI ? Because it is running R-3.3.1, and therefore
produces the same error message when I instruct Travis to install packages
from the devel branch.

I suppose this is something that I need to post on the Travis GitHub isse
tracker, right, considering the following message?

R for Travis-CI is not officially supported, but is community maintained.
Please file any issues at https://github.com/travis-ci/travis-ci/issues
and mention @craigcitro, @hadley and @jimhester in the issue
Best,
Kevin

On Thu, Oct 20, 2016 at 11:06 AM, Rodriguez Martinez, Andrea <
andrea.rodriguez-martine...@imperial.ac.uk> wrote:

> Thanks for your reply.
>
>
> I have successfully removed BiocInstaller by hand, restart R, and then,
> installed with:
>
>
> > source("https://bioconductor.org/biocLite.R;)
> Warning in install.packages :
>   URL 'https://bioconductor.org/packages/3.4/bioc/bin/macosx/
> mavericks/contrib/3.4/PACKAGES.gz': status was '404 Not Found'
> Warning in install.packages :
>   URL 'https://bioconductor.org/packages/3.4/bioc/bin/macosx/
> mavericks/contrib/3.4/PACKAGES': status was '404 Not Found'
> Warning in install.packages :
>   unable to access index for repository https://bioconductor.org/
> packages/3.4/bioc/bin/macosx/mavericks/contrib/3.4:
>   cannot download all files
> installing the source package ‘BiocInstaller’
>
> trying URL 'https://bioconductor.org/packages/3.4/bioc/src/contrib/
> BiocInstaller_1.24.0.tar.gz'
> Content type 'application/x-gzip' length 17756 bytes (17 KB)
> ==
> downloaded 17 KB
>
> * installing *source* package ‘BiocInstaller’ ...
> ** R
> ** inst
> ** preparing package for lazy loading
> ** help
> *** installing help indices
> ** building package indices
> ** testing if installed package can be loaded
> Bioconductor version 3.4 (BiocInstaller 1.24.0), ?biocLite for help
> Warning: Bioconductor version 3.4 is too old for R version 3.4.0; see
>   https://bioconductor.org/install/#troubleshoot-biocinstaller
> * DONE (BiocInstaller)
>
> The downloaded source packages are in
> ‘/private/var/folders/z8/8jwlrtqx3270h05ncg1xwzs8gn
> /T/RtmpRmVsc5/downloaded_packages’
> Bioconductor version 3.4 (BiocInstaller 1.24.0), ?biocLite for help
>
> > BiocInstaller::useDevel()
> Error: 'devel' version requires a more recent R
>
>
> Thanks very much,
>
> Andrea
>
>
>
> 
> From: Bioc-devel  on behalf of Martin
> Morgan 
> Sent: 20 October 2016 10:28:34
> To: Michael Lawrence; bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Fwd: BiocInstaller::useDevel() Error: 'devel'
> version requires a more recent R
>
> On 10/20/2016 12:00 AM, Michael Lawrence wrote:
> > -- Forwarded message --
> > From: Rodriguez Martinez, Andrea  imperial.ac.uk>
> > Date: Wed, Oct 19, 2016 at 3:33 PM
> > Subject: Re: [Bioc-devel] BiocInstaller::useDevel() Error: 'devel'
> > version requires a more recent R
> > To: Michael Lawrence 
> >
> >
> > Sorry again,
> >
> > I have just installed the R-devel version and now I get the following
> > error: "Bioconductor does not yet support R version 3.4.0"
>
> Thank you, you installed BiocInstaller in R-devel (R-3.4) before
> Bioconductor officially supported R-3.4, and need to manually remove and
> re-install BiocInstaller.
>
> I have updated the online configure, so in a new session, try to load
> the BiocInstaller package and you should now see
>
> Bioconductor version 3.4 is too old for R version 3.4.0; see
>https://bioconductor.org/install/#troubleshoot-biocinstaller
>
> The instructions are to remove BiocInstaller by hand
>
>remove.packages("BiocInstaller")
>remove.packages("BiocInstaller") # fails, if not then investigate
>
> and install again
>
>source("https://bioconductor.org/biocLite.R;)
>
> Martin
>
> >
> > Thanks,
> >
> > Andrea
> >
> > 
> > From: Rodriguez Martinez, Andrea
> > Sent: 19 October 2016 23:13:06
> > To: Michael Lawrence
> > Subject: Re: [Bioc-devel] BiocInstaller::useDevel() Error: 'devel'
> > version requires a more recent R
> >
> >
> > Thanks!
> >
> > 
> > From: Michael Lawrence 
> > Sent: 19 October 2016 23:02:17
> > To: Rodriguez Martinez, Andrea
> > Cc: bioc-devel@r-project.org
> > Subject: Re: [Bioc-devel] BiocInstaller::useDevel() Error: 'devel'
> > version requires a more recent R
> >
> > Bioconductor 3.5 requires R-devel.
> >
> > On Wed, Oct 19, 2016 at 2:57 PM, Rodriguez Martinez, Andrea
> >  wrote:
> >> Hi,
> >>
> >>
> >> I was just trying to use the devel branch, but I get this error message
> 

Re: [Bioc-devel] Package "not supported" on some platforms, and dependent packages

[Kevin RUE]

Agh, I could have looked better in the Git mirror code ;)

Anyway, thanks a lot for the tip!

No worries about removing the file if the parent package gets supported.
However, I've never tried to run the VEP script on Windows, which I expect
is pre-requisite for the package building successfully there. Might not be
that easy. Anyway, future will tell, and I'll keep an eye out for it!

Cheers
Kevin


On Tue, Oct 18, 2016 at 11:44 PM, Dan Tenenbaum <dtene...@fredhutch.org>
wrote:

>
>
> - Original Message -----
> > From: "Kevin RUE" <kevinru...@gmail.com>
> > To: "bioc-devel" <bioc-devel@r-project.org>
> > Sent: Tuesday, October 18, 2016 3:28:23 PM
> > Subject: [Bioc-devel] Package "not supported" on some platforms,
> and dependent packages
>
> > Hi all,
> >
> > Heartless logic works as follows:
> >
> >   - ensemblVEP is "not supported" on Windows (build report
> >   <http://bioconductor.org/checkResults/devel/bioc-LATEST/ensemblVEP/>).
> >   Completely understandable.
> >   - My package depends on ensemblVEP.
> >   - The build system reports an error on Windows for my package
> > because "dependency
> >   'ensemblVEP' is not available for package 'TVTB'" (build report
> >   <http://bioconductor.org/checkResults/devel/bioc-
> LATEST/TVTB/tokay2-buildsrc.html>
> >   )
> >   - As a result, the landing page for my package reports "build error" (
> >   page <https://www.bioconductor.org/packages/release/bioc/html/
> TVTB.html>)
> >
> > I was hoping to benefit of the same treatment as the ensemblVEP package,
> > that is, skipping the nightly build on the Windows machine, to get the
> nice
> > green light "build OK" on the landing page.
> >
> > I suppose this is something to control in the build system, right? Or do
> I
> > have to put any kind of keyword in one of my package files?
> > Thanks!
> >
>
> The build system is heartless. ;)
> ensemblVEP is marked as unsupported on Windows by virtue of a .BBSoptions
> file in the top level (at the same level as DESCRIPTION) containing one
> line:
>
> UnsupportedPlatforms: win
>
> If you add that to your package it will stop building (and failing) on
> windows.
>
> If ensemblVEP is ever again supported on windows (I don't know if this is
> planned) you'll need to remove that file.
>
> Dan
>
>
> > All the best,
> > Kevin
> >
> >   [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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

[Bioc-devel] Package "not supported" on some platforms, and dependent packages

[Kevin RUE]

Hi all,

Heartless logic works as follows:

   - ensemblVEP is "not supported" on Windows (build report
   ).
   Completely understandable.
   - My package depends on ensemblVEP.
   - The build system reports an error on Windows for my package
because "dependency
   'ensemblVEP' is not available for package 'TVTB'" (build report
   

   )
   - As a result, the landing page for my package reports "build error" (
   page )

I was hoping to benefit of the same treatment as the ensemblVEP package,
that is, skipping the nightly build on the Windows machine, to get the nice
green light "build OK" on the landing page.

I suppose this is something to control in the build system, right? Or do I
have to put any kind of keyword in one of my package files?
Thanks!

All the best,
Kevin

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] GitHub and svn

[Kevin RUE]

Dear Mani,

That's actually where I think the git-svn bridge becomes useful.
If you take the time once to synchronise the devel branch of your package
from the Bioconductor-mirror to one of the branch on your GitHub repository
(for me the master branch), you could then:
1) commit changes to your own repository first (does not affect the BioC
code)
2) follow the BioC git-svn instructions that you mentioned to selectively
push the changes to either or both the devel and release branche(s) of
Bioconductor.

I personally don't think that the current system is "unnecessarily
complicated". That handful of commands is probably as simple as a system
can be, to handle version control selectively applied to multiple branches
(devel, 3.3, 3.2, master, ...) of multiple repositories (BioC, GitHub, ...)
using multiple version control software (git, svn).

The learning curve for version control can be quite steep beyond the basic
commands, but one has to bear in mind that RStudio is not a version control
software in itself. The GUI only provides buttons for the most common
version controls commands (pull/push/update). For more advanced commands,
you will have to open a shell anyway (the little wheel icon).
I must admit that I was a bit scared/frustrated at first with the system,
but after a few attempts to get it right, this little process to control
the branches to synchronise can almost become enjoyable when proudly
releasing new code :)

All the best,
Kevin


On Sat, Oct 15, 2016 at 10:21 PM, S Manimaran 
wrote:

> Thanks, Gabe and Kasper, for the info.
>
>
>
> Following up on Gabe's reply: That means, I need to setup two projects in
> R-Studio with one for the release pointing to the release repository in SVN
> and another for the development version pointing to the development
> repository in SVN, right? Now, suppose I make a bug fix and commit to the
> release repository and I want the same fix in the development repository as
> well, how exactly do I go about this: Do I just manually copy those files
> with the changes to the other development version project and commit it
> there as well? (Personally, I also like to keep the original GitHub
> repository in sync with the latest in BioConductor development, which would
> mean I need to maintain three projects in R-Studio, right?) Or is there any
> other way about this?
>
>
>
> Thanks,
>
> Mani
>
>
>
>
> From: Gabe Becker [mailto:becker.g...@gene.com]
> Sent: Saturday, October 15, 2016 4:35 PM
> To: Kasper Daniel Hansen
> Cc: S Manimaran; bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] GitHub and svn
>
>
> Mani,
>
> Related to what Kasper said, one thing you can do is commit directly to
> the canonical repo for your package (which again is not on github once the
> package is accepted) from rstudio. It supports svn.
>
> ~G
>
> On Oct 15, 2016 11:38 AM, "Kasper Daniel Hansen" <
> kasperdanielhan...@gmail.com> wrote:
> Not at the moment.  We are in the (long) process of changing this, but
> there is no ETA for it.
>
> The complications we currently have, as soon as a package is accepted in
> Bioconductor, is that the "true" repository then becomes Bioconductor SVN
> and your Github repository is just a way for you to develop.  This is not
> the case during package submission.
>
> Best,
> Kasper
>
>
> On Sat, Oct 15, 2016 at 12:19 PM, S Manimaran  mailto:manimaran_1...@hotmail.com>>
> wrote:
>
> > Hi,
> >
> > I never understood the github mirror setup and the instructions below
> look
> > unnecessarily complicated to me. I see that the current package
> submission
> > process with the automatic hook added to github is the most easiest of
> all
> > with every commit to github automatically triggering a build at
> > Bioconductor. Now, my question is: Can't this same procedure be carried
> > over once the Bioconductor 3.4 is released as well i.e commits to github
> > automatically resulting in triggering a build at Bioconductor? The main
> use
> > case that I am looking for is an easy way to commit directly from inside
> > R-Studio. With R-Studio setup for GitHub project, it directly commits to
> > GitHub, but now for having to commit to BioConductor, if the automatic
> > trigger works well as is the case with the new package submission
> process,
> > all is well and good. But if I have to do as what the page in git-mirror
> > says, then it looks like that I have to get out of R-Studio to do some
> > overly complicated process to achieve the s!
> >  ame. It will be really helpful if I can continue to use the automatic
> > trigger to automatically build after Bioconductor 3.4 release as well.
> >
> >
> > http://bioconductor.org/developers/how-to/git-mirror/
> >
> > Scenario 2: Set Up Your Own GitHub Repository
> > If you do not already have a public git repository for package REPO the
> > simplest thing to do is navigate to https://github.com/
> > Bioconductor-mirror/REPO 

Re: [Bioc-devel] Accepting an answer on the support website

[Kevin Rue-Albrecht]

"Original Post(er)" I assume?



On 20 October 2015 at 16:15, James W. MacDonald <jmac...@uw.edu> wrote:

> The OP needs to accept your answer.
>
> On Tue, Oct 20, 2015 at 10:14 AM, Kevin Rue-Albrecht <
> kevin@ucdconnect.ie> wrote:
>
>> Dear all,
>>
>> Being on the developer side of things, I have resolved two items related
>> to
>> my package on the support website, and I would like to know how my answer
>> could be marked as "accepted", so that it shows in the corresponding badge
>> on my package web page.
>>
>> Kind regards
>> Kevin
>>
>> --
>> Kévin RUE-ALBRECHT
>> Wellcome Trust Computational Infection Biology PhD Programme
>> University College Dublin
>> Ireland
>> http://fr.linkedin.com/pub/k%C3%A9vin-rue/28/a45/149/en
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
>
>
> --
> James W. MacDonald, M.S.
> Biostatistician
> University of Washington
> Environmental and Occupational Health Sciences
> 4225 Roosevelt Way NE, # 100
> Seattle WA 98105-6099
>



-- 
Kévin RUE-ALBRECHT
Wellcome Trust Computational Infection Biology PhD Programme
University College Dublin
Ireland
http://fr.linkedin.com/pub/k%C3%A9vin-rue/28/a45/149/en

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] RSS package feeds not updated

[Kevin Rue-Albrecht]

Hi Stephanie,

I am using rss2email (
http://www.allthingsrss.com/rss2email/getting-started-with-rss2email/), a
script that I installed to track my package feed, and that is run by my
Windows task scheduler every day, to send me the RSS news in an email (not
as an RSS feed per se)

Now, just like you I get the good and the bad news following the nightly
build. But since I get them as emails, I just set up a filter to mark good
emails as read and I move them directly in a separate email folder (you
could also delete them).
This way, only the bad news show up as unread messages which catch my
attention.

Took a bit of time to set up, but then it ran seamlessly ever since.
No extra work for Dan, and developers who might want to log the successful
builds can do so.

Hope that helps.
Kevin


On 3 December 2014 at 00:19, Stephanie M. Gogarten 
sdmor...@u.washington.edu wrote:



 On 12/2/14 8:17 AM, Dan Tenenbaum wrote:



 - Original Message -

 From: Julian Gehring julian.gehr...@embl.de
 To: bioc-devel@r-project.org
 Cc: Felix Klein fkl...@embl.de
 Sent: Tuesday, December 2, 2014 2:19:01 AM
 Subject: [Bioc-devel] RSS package feeds not updated

 Hi,

 some/many of the package build RSS feeds [1] don't receive updates.
   For
 example,

http://bioconductor.org/rss/build/packages/DESeq2.rss (from
2014-11-04)

http://bioconductor.org/rss/build/packages/BiocInstaller.rss (from
2014-10-15)

 report package builds as broken, although the current builds are
 fine.

 In contrast,

http://bioconductor.org/rss/build/packages/GenomicRanges.rss

 was recently updated (2014-12-01) and also contains the build report
 of
 both the devel and release branch (the broken ones listed above
 don't).

 Most of the packages that I checked manually seem to be
 outdated/broken
 - I guess there is a issue with the underlying feed system.


 Thanks for the report. I've had a look. I've changed the system so it
 doesn't try to be smart about not updating feeds for packages that do not
 have issues.
 This means all package feeds will be updated daily, whether there is an
 issue or not. Not sure if this will be annoying to feed users; we can
 revisit it if it's an issue.


 I have to say, I liked the old system better.  I have a feed for each of
 my packages in the bottom of my email program, so I could see at a glance
 if there was a problem with one of the packages (new message in the feed).
 Failure messages are a lot more noticeable if they're not buried among lots
 of nothing to see here messages.

 Stephanie



 Thanks,
 Dan



  Best
 Julian


 [1] http://bioconductor.org/developers/rss-feeds/

 ___
 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


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




-- 
Kévin RUE-ALBRECHT
Wellcome Trust Computational Infection Biology PhD Programme
University College Dublin
Ireland
http://fr.linkedin.com/pub/k%C3%A9vin-rue/28/a45/149/en

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Change of schema of ENSEMBL biomart

[Kevin Rue-Albrecht]

Well spotted Tiphaine !

I just checked and this has affected my package (GOexpress) as well, as it
fetches the external_gene_id to annotate gene features.
This prevent the key analysis step from completing on my analysis of *Bos
taurus* gene expression as well.

Consequently, I will bug-fix the release version immediately.

For the record, I make a few different calls to biomaRt for gene ontology
annotations, and I didn't get any error message there. But as you say,
there may be other Easter eggs in the various datasets.

Thanks very much !
Kevin







On 17 October 2014 14:48, Martin, Tiphaine tiphaine.mar...@kcl.ac.uk
wrote:

 Hi Everybody,


 Yesterday, I observed that ENSEMBL changed a little their schema of  the
 dataset hsapiens_gene_ensembl.

 In my case, some of my functions were impacted by the change from
 external_gene_id to

 external_gene_name.


 Maybe there are other change in this dataset or other datasets.


 Regards,

 Tiphaine

 [[alternative HTML version deleted]]

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




-- 
Kévin RUE-ALBRECHT
Wellcome Trust Computational Infection Biology PhD Programme
University College Dublin
Ireland
http://fr.linkedin.com/pub/k%C3%A9vin-rue/28/a45/149/en

[[alternative HTML version deleted]]

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

[Bioc-devel] 'BiocInstaller' package not in repository error during nightly build

[Kevin Rue-Albrecht]

Hi Bioconductors,

I got the *BUILD* ERROR report below on all platforms last night.

Given the fact that I didn't update my package since the last (successful)
build, and the error ''BiocInstaller' package not in repository'',  I have
a feeling this is due to a problem on the build platforms ?
In which case, I wonder how many other packages may be affected the same
way. Most of the packages seem fine though.

I can see that the BiocInstaller package got *CHECK* ERROR on all platforms
in the most recent report. Could that be the origin of the problem?
In my vignette, I give the typical installation code biocLite(GOexpress)
which likely caused the build error when trying to load the BiocInstaller
library.

Thanks in advance for advising me

Kind regards,
Kevin


##
##
###
### Running command:
###
###   /home/biocbuild/bbs-3.1-bioc/R/bin/R CMD build --keep-empty-dirs
--no-resave-data GOexpress
###
##
##


* checking for file ‘GOexpress/DESCRIPTION’ ... OK
* preparing ‘GOexpress’:
* checking DESCRIPTION meta-information ... OK
* installing the package to build vignettes
* creating vignettes ... ERROR
Bioconductor version 3.1 (BiocInstaller 1.17.0), ?biocLite for help

Error: processing vignette 'GOexpress-UsersGuide.Rnw' failed with diagnostics:
 chunk 2
Error : ''BiocInstaller' package not in repository' while trying
  http://bioconductor.org/packages/3.1/bioc
Execution halted


-- 
Kévin RUE-ALBRECHT
Wellcome Trust Computational Infection Biology PhD Programme
University College Dublin
Ireland
http://fr.linkedin.com/pub/k%C3%A9vin-rue/28/a45/149/en

[[alternative HTML version deleted]]

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

[Bioc-devel] no more commits allowed before release ?

[Kevin Rue-Albrecht]

Dear all,

I fixed a bug affecting one particular situation in my package (GOexpress)
yesterday, and pushed the changes to GitHub. However, the webhook did not
trigger to update the page, due to the feature freeze if I understand the
schedule correctly (http://www.bioconductor.org/developers/release-schedule/
).

I suppose I need to wait the release is out to push these changes again to
update the SVN ? Or is it still possible to include those changes in the
release? From the schedule, it still sounds possible Package maintainers
should limit changes to show-stopper bugs and documentation improvements.

Sincerely,
Kevin

-- 
Kévin RUE-ALBRECHT
Wellcome Trust Computational Infection Biology PhD Programme
University College Dublin
Ireland
http://fr.linkedin.com/pub/k%C3%A9vin-rue/28/a45/149/en

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] no more commits allowed before release ?

[Kevin Rue-Albrecht]

Alright, I'll do one more final round of manual testing, just in case.

At the moment, I can see the reports for
2014-10-08 16:20:09 -0700 (Wed, 08 Oct 2014) , so I'll just wait to see the
next one, which should include my recent changes. I was confusing myself
between the time difference, the time when the build server runs, and the
time when the corresponding report becomes available.

I'll take the time to introduce unit tests when things cool down after the
release. I was using man page examples as a sort of unit tests, but for
some lengthy functions (~1 min), I didn't cover multiple scenarios to
respect a reasonable CMD check time. But this bug fix probably proved me
wrong.

Thanks for your time
Kevin



On 10 October 2014 16:15, Dan Tenenbaum dtene...@fhcrc.org wrote:



 - Original Message -
  From: Kevin Rue-Albrecht kevin@ucdconnect.ie
  To: Dan Tenenbaum dtene...@fhcrc.org
  Cc: bioc-devel@r-project.org
  Sent: Friday, October 10, 2014 8:03:25 AM
  Subject: Re: [Bioc-devel] no more commits allowed before release ?
 
 
  Hi Dan,
 
 
  Ok good, you have just given me the most recent commit that I did
  today, so the ones I was most concerned about (from yesterday)
  should be there too, that's good for me. The changes should show up
  in the next build report.

 I do see a commit with the commit message Bug fix

  Maybe the build system just started the checks just before I pushed
  those changes yesterday morning (10am, Irish time.. so around 2am
  Seattle time, I believe), which could have left them out of the
  build report.
 

 Changes need to be committed by 4:20 PM Seattle time in order to show up
 in the following day's build report.


 
 
  I always run CMD check locally before submitting. That wasn't the
  problem, it was just a scenario that I hadn't tested in a while. I
  am considering throwing some unit tests in the package soon, but I
  won't have time before the release.. I'll have to spend some time to
  do it correctly as it'd be my first time writing unit tests for an R
  package (did it in other languages before).
 
 
  * Are the unit tests run by the BiocCheck ? In which case, I
  would need to add another testing dataset corresponding to the
  scenario that I fixed yesterday.


 Yes, unit tests are run by BiocCheck, our howto page shows you how to make
 this happen:
 http://www.bioconductor.org/developers/how-to/unitTesting-guidelines/

 Dan

 
 
  Cheers
  Kevin
 
 
 
 
 
 
 
 
 
 
  On 10 October 2014 15:40, Dan Tenenbaum  dtene...@fhcrc.org  wrote:
 
 
 
 
  - Original Message -
   From: Kevin Rue-Albrecht  kevin@ucdconnect.ie 
   To: bioc-devel@r-project.org
   Sent: Friday, October 10, 2014 7:31:36 AM
   Subject: [Bioc-devel] no more commits allowed before release ?
  
   Dear all,
  
   I fixed a bug affecting one particular situation in my package
   (GOexpress)
   yesterday, and pushed the changes to GitHub. However, the webhook
   did
   not
   trigger to update the page, due to the feature freeze if I
   understand
   the
   schedule correctly
   ( http://www.bioconductor.org/developers/release-schedule/
   ).
  
 
  I see a commit at 2014-10-10 13:13:54 +0100 (your time) / 2014-10-10
  05:11:29 -0700 (Seattle time).
 
  Is that the one? The commit message is  Little addition of details
  to the description of DAM and NCN participation in the project.
 
  We do not disable commits to trunk. We have disabled commits to the
  current release branch (Bioconductor 2.14) because 2.14 builds have
  stopped.
 
   I suppose I need to wait the release is out to push these changes
   again to
   update the SVN ? Or is it still possible to include those changes
   in
   the
   release? From the schedule, it still sounds possible Package
   maintainers
   should limit changes to show-stopper bugs and documentation
   improvements.
  
 
  It is possible, but there are very few build cycles left till the
  release, so please build and check your package locally before
  committing changes and then keep an eye on the build report to make
  sure that the package built ok.
 
  Dan
 
 
   Sincerely,
   Kevin
  
   --
   Kévin RUE-ALBRECHT
   Wellcome Trust Computational Infection Biology PhD Programme
   University College Dublin
   Ireland
   http://fr.linkedin.com/pub/k%C3%A9vin-rue/28/a45/149/en
  
   [[alternative HTML version deleted]]
  
   ___
   Bioc-devel@r-project.org mailing list
   https://stat.ethz.ch/mailman/listinfo/bioc-devel
  
 
 
 
 
  --
 
  Kévin RUE-ALBRECHT
  Wellcome Trust Computational Infection Biology PhD Programme
  University College Dublin
  Ireland
  http://fr.linkedin.com/pub/k%C3%A9vin-rue/28/a45/149/en
 




-- 
Kévin RUE-ALBRECHT
Wellcome Trust Computational Infection Biology PhD Programme
University College Dublin
Ireland
http://fr.linkedin.com/pub/k%C3%A9vin-rue/28/a45/149/en

[[alternative HTML version deleted

Re: [Bioc-devel] no more commits allowed before release ?

[Kevin Rue-Albrecht]

Thanks Robert, that is a great idea indeed. I like doing checks before
submitting a new release to the tracker. Avoids bad surprises.

Just to be clear, in this case, I wasn't expecting to see any change in the
build report (I had OKs everywhere, even when the bug existed). The bug
only occurred when using my package with microarray data, which I forgot to
test since I did relevant changes in my code. The only data I provide at
the moment with the package for testing is RNA-Seq, which I use in the
examples and the vignette. I occasionally test the package with an in-house
microarray dataset.

From this experience, I believe it is best if I include a subset of my
microarray dataset as well. But at this stage I think it's better to wait
until the release is out. The package is now is a good working state, and
I'd rather not take risks just before the big day :)

Cheers
Kevin

On 10 October 2014 16:38, Robert M. Flight rfligh...@gmail.com wrote:

 If you want to be really sure that the changes fixed the problem without
 pushing to Bioconductor master (and seeing a build report), you can set up
 a Travis CI on a bugfix branch and see what happens there. The r-travis
 wiki has some good documentation
 https://github.com/craigcitro/r-travis/wiki, and my own package uses it,
 as well as others.
 https://github.com/rmflight/categoryCompare/blob/master/.travis.yml

 -Robert

 Robert M Flight, PhD
 Bioinformatics PostDoctoral Scholar
  Resource Center for Stable Isotope Resolved Metabolomics
 Markey Cancer Center
 University of Kentucky
  Lexington, KY

 Twitter: @rmflight https://twitter.com/rmflight
 Web: rmflight.github.io
 EM rfligh...@gmail.com
 PH 502-509-1827

 The most exciting phrase to hear in science, the one that heralds new
 discoveries, is not Eureka! (I found it!) but That's funny ... - Isaac
 Asimov




 On Fri, Oct 10, 2014 at 11:15 AM, Dan Tenenbaum dtene...@fhcrc.org
 wrote:



 - Original Message -
  From: Kevin Rue-Albrecht kevin@ucdconnect.ie
  To: Dan Tenenbaum dtene...@fhcrc.org
  Cc: bioc-devel@r-project.org
  Sent: Friday, October 10, 2014 8:03:25 AM
  Subject: Re: [Bioc-devel] no more commits allowed before release ?
 
 
  Hi Dan,
 
 
  Ok good, you have just given me the most recent commit that I did
  today, so the ones I was most concerned about (from yesterday)
  should be there too, that's good for me. The changes should show up
  in the next build report.

 I do see a commit with the commit message Bug fix

  Maybe the build system just started the checks just before I pushed
  those changes yesterday morning (10am, Irish time.. so around 2am
  Seattle time, I believe), which could have left them out of the
  build report.
 

 Changes need to be committed by 4:20 PM Seattle time in order to show up
 in the following day's build report.


 
 
  I always run CMD check locally before submitting. That wasn't the
  problem, it was just a scenario that I hadn't tested in a while. I
  am considering throwing some unit tests in the package soon, but I
  won't have time before the release.. I'll have to spend some time to
  do it correctly as it'd be my first time writing unit tests for an R
  package (did it in other languages before).
 
 
  * Are the unit tests run by the BiocCheck ? In which case, I
  would need to add another testing dataset corresponding to the
  scenario that I fixed yesterday.


 Yes, unit tests are run by BiocCheck, our howto page shows you how to
 make this happen:
 http://www.bioconductor.org/developers/how-to/unitTesting-guidelines/

 Dan

 
 
  Cheers
  Kevin
 
 
 
 
 
 
 
 
 
 
  On 10 October 2014 15:40, Dan Tenenbaum  dtene...@fhcrc.org  wrote:
 
 
 
 
  - Original Message -
   From: Kevin Rue-Albrecht  kevin@ucdconnect.ie 
   To: bioc-devel@r-project.org
   Sent: Friday, October 10, 2014 7:31:36 AM
   Subject: [Bioc-devel] no more commits allowed before release ?
  
   Dear all,
  
   I fixed a bug affecting one particular situation in my package
   (GOexpress)
   yesterday, and pushed the changes to GitHub. However, the webhook
   did
   not
   trigger to update the page, due to the feature freeze if I
   understand
   the
   schedule correctly
   ( http://www.bioconductor.org/developers/release-schedule/
   ).
  
 
  I see a commit at 2014-10-10 13:13:54 +0100 (your time) / 2014-10-10
  05:11:29 -0700 (Seattle time).
 
  Is that the one? The commit message is  Little addition of details
  to the description of DAM and NCN participation in the project.
 
  We do not disable commits to trunk. We have disabled commits to the
  current release branch (Bioconductor 2.14) because 2.14 builds have
  stopped.
 
   I suppose I need to wait the release is out to push these changes
   again to
   update the SVN ? Or is it still possible to include those changes
   in
   the
   release? From the schedule, it still sounds possible Package
   maintainers
   should limit changes to show-stopper bugs and documentation
   improvements

[Bioc-devel] GOexpress: new package to visualise microarray and RNAseq data using gene ontology annotations

[Kevin Rue-Albrecht]

Dear all,

I would like to introduce a recent addition to Bioconductor.
I hope those of you working with transcriptomics data will find it useful
for their own work.

*GOexpress *is a package taking an *ExpressionSet *object minimally
including *assayData *and *phenoData* corresponding to either microarray or
RNA-Sequencing data, and enables rapid plotting of the expression profile
of any given gene in the different experimental groups. The package also
initially fetches gene ontology annotations from the *Ensembl BioMart* to
display the expression level of genes associated with each ontology in a
heatmap. Consequently, all species and microarray present in the *Ensembl
BioMart* should be supported by *GOexpress* (only a few were tested during
the development of the package).

We included two scoring methods (random-forest and ANOVA) to rank genes and
gene ontologies best clustering predefined groups of samples (e.g.
treatment groups). Note that we do not intend to compete with packages such
as GOstats and topGO for hypothesis testing, but rather to complement such
packages with means of accompanying their result statistics with plots
showing group-wise and sample-wise expression levels.

I have a few more ideas of my own to extend the package when time allows,
but I do also welcome feedback and suggestions from testers that could
benefit the community.

Link: http://bioconductor.org/packages/devel/bioc/html/GOexpress.html

Yours sincerely,
Kevin

-- 
Kévin RUE-ALBRECHT
Wellcome Trust Computational Infection Biology PhD Programme
University College Dublin
Ireland
http://fr.linkedin.com/pub/k%C3%A9vin-rue/28/a45/149/en

[[alternative HTML version deleted]]

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

[Bioc-devel] GenomicRanges::findOverlaps() ignoring chromosome information?

[Kevin Rue-Albrecht]

Dear maintainer, Dear all,

*Situation*
I have used the findOverlaps(function) to annotate differentially
methylated regions (DRMs) obtained using the bsseq Bioconductor package in
the *Bos taurus* genome. (No, you won't steal my experimental design :-P ).
I used the genome UMD3.1.75 as a reference for my analysis.

*Problem*
The genes found to overlap the DMRs genomic ranges are often on a different
chromosone than the DMR, although the start and end coordinate of DMRs and
gene do overlap in all cases.
This leads me to believe that the chromosome information is ignored in
findOverlaps(). Is this the case, or am I using the function incorrectly?
Note that it does happen that a true hit is returned, i.e. the
overlapping gene is present on the same chromosome, with start and end
overlapping the coordinates of the DMR.


*Attached for your use/testing:*

   - dmrs variable
   - script used to annotate dmrs with information about overlapping gene
  - Note that I have tried to set select to arbitrary, first and last
  with always the same issue. I would prefer to get a single hit at this
  stage rather than filter afterwards, but the latter remain a possible
  option if necessary.


Any help / solution / feedback welcome !

Best regards,
Kevin

-- 
Kévin RUE-ALBRECHT
Wellcome Trust Computational Infection Biology PhD Programme
University College Dublin
Ireland
http://fr.linkedin.com/pub/k%C3%A9vin-rue/28/a45/149/en
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] GenomicRanges::findOverlaps() ignoring chromosome information?

[Kevin Rue-Albrecht]

Hi again,

Update on my issue, although I haven't found the source of the error yet..
I have correct overlaps in one scenario, but not in another.  This suggests
that the findOverlaps() command works as expected on my data, but in the
second scenario I don't see where the error is yet, let me explain:

   - When I use my function OverlapDmrs.Gene with argument only.hits=TRUE,
   all the hits make perfect sense
  - Full command: dmrs_gene = OverlapDmrs.Gene(dmrs=dmrs,
  gene_track=ensGene.asFeatures, only.hits=TRUE, prefix.chr=TRUE)
   - When I use my function OverlapDmrs.Gene with argument only.hits=FALSE,
   the correct DMRs are annotated with the right start and stop position, but
   with an incorrect chromosome value (strangest thing is that chromosone 30
   should not exist in *Bos taurus*, while some hits state this value in
   the chromosome column)
  - Full command: dmrs_gene.all = OverlapDmrs.Gene(dmrs=dmrs,
  gene_track=ensGene.asFeatures, only.hits=FALSE, prefix.chr=T)


...
Now that I wrote that out loud, I just got an idea where to look for the
source of the problem. Apologies for the spam, but if I find the solution,
I'll definitely bring a conclusion to this thread.

Kevin






On 19 September 2014 10:12, Kevin Rue-Albrecht kevin@ucdconnect.ie
wrote:

 Dear maintainer, Dear all,

 *Situation*
 I have used the findOverlaps(function) to annotate differentially
 methylated regions (DRMs) obtained using the bsseq Bioconductor package in
 the *Bos taurus* genome. (No, you won't steal my experimental design :-P
 ).
 I used the genome UMD3.1.75 as a reference for my analysis.

 *Problem*
 The genes found to overlap the DMRs genomic ranges are often on a
 different chromosone than the DMR, although the start and end coordinate of
 DMRs and gene do overlap in all cases.
 This leads me to believe that the chromosome information is ignored in
 findOverlaps(). Is this the case, or am I using the function incorrectly?
 Note that it does happen that a true hit is returned, i.e. the
 overlapping gene is present on the same chromosome, with start and end
 overlapping the coordinates of the DMR.


 *Attached for your use/testing:*

- dmrs variable
- script used to annotate dmrs with information about overlapping gene
   - Note that I have tried to set select to arbitrary, first and last
   with always the same issue. I would prefer to get a single hit at this
   stage rather than filter afterwards, but the latter remain a possible
   option if necessary.


 Any help / solution / feedback welcome !

 Best regards,
 Kevin

 --
 Kévin RUE-ALBRECHT
 Wellcome Trust Computational Infection Biology PhD Programme
 University College Dublin
 Ireland
 http://fr.linkedin.com/pub/k%C3%A9vin-rue/28/a45/149/en




-- 
Kévin RUE-ALBRECHT
Wellcome Trust Computational Infection Biology PhD Programme
University College Dublin
Ireland
http://fr.linkedin.com/pub/k%C3%A9vin-rue/28/a45/149/en

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Question about inserting bibliographic references in a package vignette

[Kevin Rue-Albrecht]

Hi,

Thank you for your replying.

Thanks Kasper, I had looked at other vignettes, but in the packages I
looked at so far I only found the PDF end-result. (e.g. edgeR), or the
sources. On the other hand, Biobase, for instance, gives its sources, but
does not have a references section. Anyway, your minfi provides me with
both, thank you!
I see you used natbib. I might try that one, or maybe bibtex, whichever
feels easier to me. I suppose if I manage to make it compile on my server,
it is likely to work on the Bioconductor build servers too, as it did so
far for the rest of my package.

Thanks Vincent as well, you were right as I initially want to make it work
in my R studio environment (I only submit a new version to Bioconductor
after I checked that it compiles properly on my server where I use RStudio
server), but in the end, what really matters is that it builds on the
Bioconductor servers if I want it to be accepted there. From your answers,
it seems to me that my issue resides more in the LaTeX side than the R
Studio one.
I will try to put the references in a .bib file as you suggested, and take
example on Kasper's source vignette to cite them in my vignette using an
appropriate package. LaTeX manuals, here I come!

Thanks a lot (any further advice welcome though)
Kévin




On 7 August 2014 19:56, Vincent Carey st...@channing.harvard.edu wrote:

 It seemed to me that this question concerned how to do this in Rstudio
 specifically,
 if you are using it as the sole development environment, so I do not
 really have an example
 but I think uploading the relevant .bib file to the vignettes directory
 would be appropriate
 and it may well be that the builder will automatically run bibtex.


 On Thu, Aug 7, 2014 at 1:36 PM, Kasper Daniel Hansen 
 kasperdanielhan...@gmail.com wrote:

 I would recommend looking at existing vignettes, for example minfi, but
 there are tons of them.


 On Thu, Aug 7, 2014 at 12:38 PM, Kevin Rue-Albrecht 
 kevin@ucdconnect.ie
  wrote:

  Dear all,
 
  My name is Kevin Rue-Albrecht and I am working to improve a package
  currently in review by Bioconductor. I am blocked while trying to add
 the
  final touch to the package.
 
  I was wondering about the recommended way of inserting bibliographic
  references in the body of the package vignette using R Studio to build
  the source package.
 
  I am developing the package using R Studio on a standard Linux Ubuntu
 12.04
  distribution. The package contains a Sweave vignette (.Rnw file) which
  succesfully compiles on the Bioconductor package tracker with bits of R
  code and bits of LaTeX.
 
  So far, I have only found this page which confuses me for different
 reasons
  (
 
 
 http://texblog.org/2013/08/20/rknitr-automatic-bibliography-generation-with-biblatex-in-rstudio/
  ):
 
 - It refers to the knitr type of vignette, not the Sweave that I have
 used so far
 - At some point the person writes tell RStudio where to find the
 .tex,
 .bib and .bst files
- In the minimal example, he seems to include the .bib file into
 the
source of the vignette file. I probably should not do that with
 many
references.
 
  I haven't found the information in the Writing R Extensions page, the
  Bioconductor pacakge guidelines or the archives of this mailing list.
 
 
 - Can anyone point me to a place where my question might be already
 answered that I haven't found yet?
 - Or can anyone tell me how to store the references (probably in a
 separate file), and how to refer to them in the .Rnw vignette file so
  that
 it compiles properly on the Bioconductor servers?
 
 
  Many thanks in advance !
 
  Best regards,
  Kevin
 
 
  --
  Kévin RUE-ALBRECHT
  Wellcome Trust Computational Infection Biology PhD Programme
  University College Dublin
  Ireland
  http://fr.linkedin.com/pub/k%C3%A9vin-rue/28/a45/149/en
 
  [[alternative HTML version deleted]]
 
 
  ___
  Bioc-devel@r-project.org mailing list
  https://stat.ethz.ch/mailman/listinfo/bioc-devel
 
 

 [[alternative HTML version deleted]]


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





-- 
Kévin RUE-ALBRECHT
Wellcome Trust Computational Infection Biology PhD Programme
University College Dublin
Ireland
http://fr.linkedin.com/pub/k%C3%A9vin-rue/28/a45/149/en

[[alternative HTML version deleted]]

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

[Bioc-devel] Question about inserting bibliographic references in a package vignette

[Kevin Rue-Albrecht]

Dear all,

My name is Kevin Rue-Albrecht and I am working to improve a package
currently in review by Bioconductor. I am blocked while trying to add the
final touch to the package.

I was wondering about the recommended way of inserting bibliographic
references in the body of the package vignette using R Studio to build
the source package.

I am developing the package using R Studio on a standard Linux Ubuntu 12.04
distribution. The package contains a Sweave vignette (.Rnw file) which
succesfully compiles on the Bioconductor package tracker with bits of R
code and bits of LaTeX.

So far, I have only found this page which confuses me for different reasons
(
http://texblog.org/2013/08/20/rknitr-automatic-bibliography-generation-with-biblatex-in-rstudio/
):

   - It refers to the knitr type of vignette, not the Sweave that I have
   used so far
   - At some point the person writes tell RStudio where to find the .tex,
   .bib and .bst files
  - In the minimal example, he seems to include the .bib file into the
  source of the vignette file. I probably should not do that with many
  references.

I haven't found the information in the Writing R Extensions page, the
Bioconductor pacakge guidelines or the archives of this mailing list.


   - Can anyone point me to a place where my question might be already
   answered that I haven't found yet?
   - Or can anyone tell me how to store the references (probably in a
   separate file), and how to refer to them in the .Rnw vignette file so that
   it compiles properly on the Bioconductor servers?


Many thanks in advance !

Best regards,
Kevin


-- 
Kévin RUE-ALBRECHT
Wellcome Trust Computational Infection Biology PhD Programme
University College Dublin
Ireland
http://fr.linkedin.com/pub/k%C3%A9vin-rue/28/a45/149/en

[[alternative HTML version deleted]]

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