Re: [Bioc-devel] pkgdown::build_site_github_pages fails with "Quarto articles require Bootstrap 5"

[Oleksii Nikolaienko]

Thanks again for suggestions. Issue was on my side and I fixed it by adding
_pkgdown.yml with usethis::use_pkgdown()

Best,
Oleksii

On Thu, 10 Oct 2024 at 15:52, Oleksii Nikolaienko <
oleksii.nikolaie...@gmail.com> wrote:

> Thanks for the quick reply.
> I do not have a ./pkgdown/ folder, everything is automagically managed by
> .github/workflows/check-bioc.yml
> <https://github.com/BBCG/epialleleR/blob/devel/.github/workflows/check-bioc.yml>
> Is there a way to check Bootstrap version in docker image? Can this be the
> reason?
>
> Best,
> Oleksii
>
> On Thu, 10 Oct 2024 at 15:43, Louis Le Nézet 
> wrote:
>
>> Hi,
>>
>> Did you add in your /mypackage/pkgdown/_pkgdown.yml:
>>
>> ```yml
>> template:
>>   bootstrap: 5
>> ```
>>
>> Best,
>> Louis
>>
>> -Message d'origine-
>> De : Bioc-devel  De la part de Oleksii
>> Nikolaienko
>> Envoyé : jeudi 10 octobre 2024 15:37
>> À : bioc-devel@r-project.org
>> Objet : [Bioc-devel] pkgdown::build_site_github_pages fails with "Quarto
>> articles require Bootstrap 5"
>>
>> I apologise if the reason for this error will be outside the scope of this
>> list, but I'd appreciate it if someone can help me to identify it.
>> From today (more likely yesterday) check-bioc Github action that uses
>> "bioconductor/bioconductor_docker:devel" container fails during
>> pkgdown::build_site_github_pages(). Error is "Quarto articles require
>> Bootstrap 5".
>> Technically, this is a consequence of a recent change in pkgdown:
>> https://github.com/r-lib/pkgdown/pull/2797/files. What I don't
>> understand is
>> if it's an issue of bioc docker image, or pkgdown, or
>> biocthis::use_bioc_github_action(). Does anyone know?
>>
>> Best,
>> Oleksii
>>
>> [[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] pkgdown::build_site_github_pages fails with "Quarto articles require Bootstrap 5"

[Oleksii Nikolaienko]

Thanks for the quick reply.
I do not have a ./pkgdown/ folder, everything is automagically managed by
.github/workflows/check-bioc.yml
<https://github.com/BBCG/epialleleR/blob/devel/.github/workflows/check-bioc.yml>
Is there a way to check Bootstrap version in docker image? Can this be the
reason?

Best,
Oleksii

On Thu, 10 Oct 2024 at 15:43, Louis Le Nézet  wrote:

> Hi,
>
> Did you add in your /mypackage/pkgdown/_pkgdown.yml:
>
> ```yml
> template:
>   bootstrap: 5
> ```
>
> Best,
> Louis
>
> -Message d'origine-
> De : Bioc-devel  De la part de Oleksii
> Nikolaienko
> Envoyé : jeudi 10 octobre 2024 15:37
> À : bioc-devel@r-project.org
> Objet : [Bioc-devel] pkgdown::build_site_github_pages fails with "Quarto
> articles require Bootstrap 5"
>
> I apologise if the reason for this error will be outside the scope of this
> list, but I'd appreciate it if someone can help me to identify it.
> From today (more likely yesterday) check-bioc Github action that uses
> "bioconductor/bioconductor_docker:devel" container fails during
> pkgdown::build_site_github_pages(). Error is "Quarto articles require
> Bootstrap 5".
> Technically, this is a consequence of a recent change in pkgdown:
> https://github.com/r-lib/pkgdown/pull/2797/files. What I don't understand
> is
> if it's an issue of bioc docker image, or pkgdown, or
> biocthis::use_bioc_github_action(). Does anyone know?
>
> Best,
> Oleksii
>
> [[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] pkgdown::build_site_github_pages fails with "Quarto articles require Bootstrap 5"

[Oleksii Nikolaienko]

I apologise if the reason for this error will be outside the scope of this
list, but I'd appreciate it if someone can help me to identify it.
>From today (more likely yesterday) check-bioc Github action that uses
"bioconductor/bioconductor_docker:devel" container fails during
pkgdown::build_site_github_pages(). Error is "Quarto articles require
Bootstrap 5".
Technically, this is a consequence of a recent change in pkgdown:
https://github.com/r-lib/pkgdown/pull/2797/files. What I don't understand
is if it's an issue of bioc docker image, or pkgdown, or
biocthis::use_bioc_github_action(). Does anyone know?

Best,
Oleksii

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] potential cache-related error

[Oleksii Nikolaienko]

Thanks!

On Thu, 1 Aug 2024 at 13:44, Kern, Lori 
wrote:

> It has been refreshed.
>
> I'm looking into a fall back when the download gets corrupted so this will
> be done automatically in the future.
>
>
> Lori Shepherd - Kern
>
> Bioconductor Core Team
>
> Roswell Park Comprehensive Cancer Center
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
> ----------
> *From:* Bioc-devel  on behalf of
> Oleksii Nikolaienko 
> *Sent:* Thursday, August 1, 2024 7:11 AM
> *To:* bioc-devel@r-project.org 
> *Subject:* [Bioc-devel] potential cache-related error
>
> Dear Bioc team,
> build/check of my package results in errors on nebbiolo1
> <
> https://secure-web.cisco.com/11swBT9Q1uWTxpX6HT1SqR-igfoatdk8Q1Y8THIZOFvOadk1OLMamAdQqu8MnPHhFVfQoLCU-dpvYOS0PYbG-iLTHEw8e4o29QjJhFtQToZ9xHqOe479ghwZprBn8HNeeaHXOqA3bdXzc75VqeUAcEmBLhisOvgd6er17ZpxiUz7cZ1wipUHey5rvxbWxjEV6pBVUlxnSdEjZcUFbFQ08J1KWXOf8nSZKXUZU58sH9oRkW5jOsdPm3K6dsG6x6Gw_RmTOuT3yFbVjnHke8aaAEIGuTVPBu9DCKGGLAdsHxVtoEfBL1IUa2pFTLYkc8IMD/https%3A%2F%2Fbioconductor.org%2FcheckResults%2F3.19%2Fbioc-LATEST%2Framr%2Fnebbiolo1-buildsrc.html
> >
> and palomino7
> <
> https://secure-web.cisco.com/1hB-dR2aF4oiDB1JLPPiY8yaRgb-LWVw88TKhLKDAOEaOQ3gVo2vxJcKvzl1wPEL-dofHGYZi5M4eTXCwxpch-cNAoxouSgJYLAZvAht2cDd4B8UhPGFCYJy-kRl1GNYCTgJhofu1Sr64rSxIShBFQBe2B5WKz-etwDOAmWFTZKt6ag5QgH1nBxshpp56v-e8WM8mRDu3Eqx5M8dypn8Rad27WiU-1jm4HNbtBbUWsxY8zZ4sCAvK2ySMh2WlzJ1r9W26H84LRcmg_ZCrdXBmkPdCloyAWpmwKF4YvyBHRdGZC0vnZzJHOhw5LvQzR1pz/https%3A%2F%2Fbioconductor.org%2FcheckResults%2F3.19%2Fbioc-LATEST%2Framr%2Fpalomino7-buildsrc.html
> >
> possibly due a corrupted file in cache. If my understanding is correct,
> could you please refresh that file on both hosts?
>
> Best regards,
> Oleksii
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
>
> https://secure-web.cisco.com/1rOlS6G36sqkRTKwU79Sma2Llo4NTAqWLIgdEHYgr0jHynQQeEb-I-Ug_5a4nDz64TaaaCNqobI0vTzOrV7DTaGKa1WAkczOqqAv2JumO7fiT3hyQcHz5meYgCIHWQ_f2R8BQ-iyyZhIu8KzFBr91Ui0uwf6J2ieCYQI0P5nfTZyne7w5I-SQA_rulOvKZowkeSuOSkdr7y9aQM-63k7doVjPSCetV567UztghpyQqWhfnDfUOKQeLjgep5FMNq36du_2E2Pl2Q6JKzmcdaK9YdFWTtJWQcBH1ZvRLwBhcS-cUgaQIoRVSiP-_g1cuL4J/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-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

[Bioc-devel] potential cache-related error

[Oleksii Nikolaienko]

Dear Bioc team,
build/check of my package results in errors on nebbiolo1

and palomino7

possibly due a corrupted file in cache. If my understanding is correct,
could you please refresh that file on both hosts?

Best regards,
Oleksii

[[alternative HTML version deleted]]

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

[Bioc-devel] No cairo device on merida1

[Oleksii Nikolaienko]

Dear Bioc team,
my package is failing

on
merida1 with the message "svg: Cairo-based devices are not available for
this platform". I didn't find relevant issues at
https://github.com/Bioconductor/BBS, therefore asking here - is there
something missing at merida1 or I shouldn't include SVG in my vignettes?

Best,
Oleksii

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Omada package failing due to removed dependency

[Oleksii Nikolaienko]

https://nonstationarity.sciencesconf.org/resource/page/id/7
That is, perhaps, not surprising...

Package seems to be too good to be abandoned. I wonder if anyone from their
lab <https://modalx.parisnanterre.fr/membres> could take over maintenance,
if you still bother to ask...

Best,
Oleksii

On Thu, 6 Jul 2023 at 06:23, Sokratis Kariotis 
wrote:

> Hey,
>
> I haven't received any responses from the maintainer of ClusterCrit so I
> guess I will have to re-write the code used. How can I properly go about
> this and credit the authors as well? Thanks!
>
> Cheers,
> Sokratis
>
> On Thu, Jun 29, 2023 at 7:38 PM Kern, Lori 
> wrote:
>
>> We do not allow archived packages to be used.  All dependencies must be
>> on CRAN or Bioconductor. So yes if you can get them to reinstate the
>> package on CRAN that would be ideal.  If not you will have to remove the
>> package from the dependency list and either re-write the code used (giving
>> original clusterCrit authors credit) or remove the functionality used from
>> that package.
>>
>> Lori Shepherd - Kern
>>
>> Bioconductor Core Team
>>
>> Roswell Park Comprehensive Cancer Center
>>
>> Department of Biostatistics & Bioinformatics
>>
>> Elm & Carlton Streets
>>
>> Buffalo, New York 14263
>> --
>> *From:* Bioc-devel  on behalf of
>> Oleksii Nikolaienko 
>> *Sent:* Thursday, June 29, 2023 5:36 AM
>> *To:* Sokratis Kariotis 
>> *Cc:* bioc-devel@r-project.org 
>> *Subject:* Re: [Bioc-devel] Omada package failing due to removed
>> dependency
>>
>> Hi,
>> in this case maybe it's worth reaching out to the maintainer of
>> clusterCrit. It was removed from CRAN because of (seems-to-be) minor
>> warnings, which can be addressed by the clusterCrit developer in no
>> time...
>>
>> Best,
>> Oleksii
>>
>> On Thu, 29 Jun 2023 at 08:44, Sokratis Kariotis <
>> sokratiskario...@gmail.com>
>> wrote:
>>
>> > Dear Bioconductor team,
>> >
>> > I received an email that my package "Omada" is failing in release and
>> > devel. I had a look and the problem seems to be: *ERROR: dependency
>> > ‘clusterCrit’ is not available for package ‘omada’*. So the package
>> > clusterCrit was removed. Is there a way I can use a archived version of
>> it
>> > (or something similar) so I don't have to rewrite code based on new
>> > packages to avoid potentially inconsistencies? Please advise, thank you!
>> >
>> > Cheers,
>> > Dr. Sokratis Kariotis (PhD)
>> > Agency for Science, Technology and Research (A*STAR)
>> > Singapore Immunology Network (SIgN)
>> > Twitter: @s_kariotis <
>> https://secure-web.cisco.com/1EqWv8V2N5hRbw3HmoPEY8RdpEeWxqDoUa71DV8jQUiygXZiRjRxTOSFFWWDUSN7nw3Aviue7E_1xQuvbY4J8O3un4nvR0wtrlQUjMbs1vFGt5o9bI_InwlMvRWb2dhIe9ic0_2ugbdCwXwW_RGN1G4LJxUxm_yO9EkGSnc10bfG2fjit4oALm7Y8gMqnFusMJfqR3j-IKbu0Hem-jPRYXIeAurGmn1l7FvPYk9Pi6MHnOl1RN-5x19R655qOhP8vtsh9q-qwvckAbwuklQvq6lo0zKstGTdB6JkFCIIHswJrur4WrdjGMtwrYkWwOAQs/https%3A%2F%2Ftwitter.com%2Fs_kariotis
>> >
>> > LinkedIn:
>> http://secure-web.cisco.com/1hrH0VDgCpCKm6BWl_eP9v57iZE2j6Y9RUetJ4RMrKylsFeYV7AWyeBfOewj6SpLxhrD-_JnI4sPdaUJB9Mwxuj-B5ot2FZIu4AU87ty04CdxW8zw9DShqtsaZPm68os9ySeI12kEcN_iujEcY11StQo1_qKeBsQchHO3Vc_qvfAbA2T29jSt4KX0OnG4UZENEfns3cigBqNgiYMOOiCGmz01_nIY5M3cgVbsTmSNA-pov7ZD6si4bOXF6pt-manBCeK0NB13icO5MMlpc8HNxSqkARD7n-R71Sa3ZsGQOIYPgA0uuuIRAR9DbV_F5kSj/http%3A%2F%2Fwww.linkedin.com%2Fin%2Fsokratiskariotis
>> >
>> > [[alternative HTML version deleted]]
>> >
>> > ___
>> > Bioc-devel@r-project.org mailing list
>> >
>> https://secure-web.cisco.com/1CoMZlPPSNe-MfqZkOpNFvpMkwbnIVkEbPIxbET9FKoHMGCVzTeeTdPJGpD4PHivCSzZwalSMt8BeA1_Ab8Pa5gS2jCkg9_onfbYE3UAgbywg5GD1CrAN86qgN8FH4tjTwPBq95yDFIvYCamr14TUrSDkZKUvFhtAw7FR6bpJ_Ub9z2fU6f-G3Xw_FHRqcg6aM9xrpq4GmnfMOKO_Jlf10TJsdvhdReM9Phw2lV_EMy55ZjFYD5bteCpN4_qqRQb4_J6IbFYjlRQEi1A0DiwxC67Gzaf0QPTRszxXRxqPy4oancisQKzNmQJod-2cz9Oa/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel
>> >
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>>
>> https://secure-web.cisco.com/1CoMZlPPSNe-MfqZkOpNFvpMkwbnIVkEbPIxbET9FKoHMGCVzTeeTdPJGpD4PHivCSzZwalSMt8BeA1_Ab8Pa5gS2jCkg9_onfbYE3UAgbywg5GD1CrAN86qgN8FH4tjTwPBq95yDFIvYCamr14TUrSDkZKUvFhtAw7FR6bpJ_Ub9z2fU6f-G3Xw_FHRqcg6aM9xrpq4GmnfMOKO_Jlf10TJsdvhdReM9Phw2lV_EMy55ZjFYD5bteCpN4_qqRQb4_J6IbFYjlRQEi

Re: [Bioc-devel] Omada package failing due to removed dependency

[Oleksii Nikolaienko]

Hi,
in this case maybe it's worth reaching out to the maintainer of
clusterCrit. It was removed from CRAN because of (seems-to-be) minor
warnings, which can be addressed by the clusterCrit developer in no time...

Best,
Oleksii

On Thu, 29 Jun 2023 at 08:44, Sokratis Kariotis 
wrote:

> Dear Bioconductor team,
>
> I received an email that my package "Omada" is failing in release and
> devel. I had a look and the problem seems to be: *ERROR: dependency
> ‘clusterCrit’ is not available for package ‘omada’*. So the package
> clusterCrit was removed. Is there a way I can use a archived version of it
> (or something similar) so I don't have to rewrite code based on new
> packages to avoid potentially inconsistencies? Please advise, thank you!
>
> Cheers,
> Dr. Sokratis Kariotis (PhD)
> Agency for Science, Technology and Research (A*STAR)
> Singapore Immunology Network (SIgN)
> Twitter: @s_kariotis 
> LinkedIn: http://www.linkedin.com/in/sokratiskariotis
>
> [[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] RforProteomics: vignette error - cannot find the file(s)

[Oleksii Nikolaienko]

Hi,
I wonder if it's because the entire "vignettes/figures" is not pushed to
Bioc git (it's included in your .gitignore). And the previous chunk does
not re-create the figure.

Best,
Oleksii


On Fri, 28 Apr 2023 at 15:24, Laurent Gatto 
wrote:

> I am puzzled by this error:
>
> The vignette fails because it can't find a figure
>
> * checking re-building of vignette outputs ... ERROR
> Error(s) in re-building vignettes:
> --- re-building ‘RProtVis.Rmd’ using rmarkdown
> Quitting from lines 607-608 (RProtVis.Rmd)
> Error: processing vignette 'RProtVis.Rmd' failed with diagnostics:
> Cannot find the file(s): "figures/msanim1.gif"
> --- failed re-building ‘RProtVis.Rmd’
>
> Even though that figure does exists [1].
>
> I am unable to reproduce locally and on Github [2]
>
> Source: [3]
>
> Any idea?
>
> Laurent
>
> [1] https://github.com/lgatto/RforProteomics/tree/master/vignettes/figures
> [2] If fails at the moment, but for a different reason - a dependency is
> not (yet?) available
> [3]
> https://master.bioconductor.org/checkResults/3.17/data-experiment-LATEST/RforProteomics/nebbiolo1-checksrc.html
>
> ___
> 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: philr problems reported in the Multiple platform build/check report for BioC 3.17

[Oleksii Nikolaienko]

Hi,
looks like the latest commit to the relevant code

in package mia has changed the arguments of
makePhyloseqFromTreeSummarizedExperiment (makePhyloseqFromTreeSE). I wonder
if that's the reason.
Is the error gone if you call it differently? -
pseq <- makePhyloseqFromTreeSummarizedExperiment(tse, assay.type="
counts.shifted")

Best,
Oleksii


On Fri, 7 Apr 2023 at 15:23, Justin Silverman  wrote:

> Hello helpful list.
>
> I have repeatedly got the following email over the past few weeks. At
> first I thought it was a false positive as the error in question was fixed
> a while back. But I keep receiving this email. I have asked a few
> colleagues to try to test out the package and run R CMD CHECK and they find
> that the package passes no without problems (particularly no one can
> recreate this bug in the vignette) on mac, windows, and linux.
>
> I am sorry to ask this but could someone please help me figure out what is
> going on? I am almost certain that the master branch of my github repo
> (jsilve24/philr) is synced with the BioC 3.17 branch as they are both at
> version 1.25.2.
>
> Thank you so much for your help and sorry for the trouble.
>
> Justin
>
> bbs-nore...@bioconductor.org writes:
>
> > [This is an automatically generated email. Please don't reply.]
> >
> > Hi philr maintainer,
> >
> > According to the Multiple platform build/check report for BioC 3.17,
> > the philr package has the following problem(s):
> >
> >   o ERROR for 'R CMD build' on nebbiolo1. See the details here:
> >   <
> https://master.bioconductor.org/checkResults/3.17/bioc-LATEST/philr/nebbiolo1-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:
> >
> >   
> >
> > (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:
> >
> > 
> >
> > Thanks for contributing to the Bioconductor project!
> ___
> 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] Missing dependency errors on nebbiolo1 (Bioc 3.17)

[Oleksii Nikolaienko]

Hi,
maybe because BiocStyle is not listed as a dependency or suggested package
in DESCRIPTION?
More info here: https://github.com/Bioconductor/BBS/issues/248

Best,
Oleksii

On Tue, 4 Apr 2023 at 11:22, Rainer Johannes 
wrote:

> Dear all,
>
> I'm continuing to see some strange dependency problems for packages on the
> linux build system for Bioconductor 3.17. First time I've seen them where
> on the build report for snapshot 2023-03-31, and they are still there for
> snapshot date 2023-04-02 (build report from 2023-04-03). What I've seen so
> far is that most are related to `BiocStyle` missing.
>
> Some examples are:
> - ROC (missing BiocStyle)
> - SCATE (missing BiocStyle)
> - SC3 (missing BiocStyle)
> - scTHI (missing BiocStyle)
>
> Since they are only present on the linux build system - maybe that's
> something related to the setup on that particular server? Or the R version
> used there does not properly get all dependencies of packages?
>
> cheers, jo
>
> ---
> Johannes Rainer, PhD
>
> Eurac Research
> Institute for Biomedicine
> Via A.-Volta 21, I-39100 Bolzano, Italy
>
> email: johannes.rai...@eurac.edu
> github: jorainer
> mastodon: jorai...@fosstodon.org
>
>
> [[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] Warnings in "checking compiled code" of R CMD check

[Oleksii Nikolaienko]

Hi all,
it seems that the devel version of R CMD check has raised the level of
messages in "checking compiled code" from NOTE to WARNING. My package
contains

entry points for abort, exit, stdout, stderr and sprintf, while I use only
snprintf and don't terminate or write out anything in a non recommended
way. I can see similar warnings in checks of Rsamtools and rtracklayer as
well.
Is there anything one needs to do about this? Would it become a problem in
the future?

Best,
Oleksii

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Bioconductor install instructions for M1-based Mac

[Oleksii Nikolaienko]

I don't know if this has been mentioned, but the following pages are of an
immense help:
https://mac.r-project.org/
https://mac.r-project.org/openmp/
It is possible and quite easy to get a native M1 build of R with OpenMP
support and no issues with Bioc packages.

Best,
Oleksii

On Sun, 20 Feb 2022 at 04:19, Vincent Carey 
wrote:

> Thanks Gordon, I agree that some documentation should be added.  While
> we are not in a position to provide
> binaries for M1 at this time, anyone who has prepared their
> M1-oriented version of R to install packages from source
> can install Bioconductor packages.  I will respond on the support
> site, and we will work on enhancing the
> documentation for users.
>
> On Sat, Feb 19, 2022 at 7:00 PM Gordon Smyth  wrote:
> >
> > Given all the questions on the Bioc Support forum, it would be timely to
> have guidance on the Bioconductor install page:
> >
> >   https://www.bioconductor.org/install/
> >
> > for users with an M1-based Mac. As far as I know, there isn't any
> documentation alerting a beginner user that Bioconductor doesn't support
> the native M1 compilation of R.
> >
> > Thanks
> > Gordon
> >
> > --
> > Professor Gordon K Smyth
> > Joint Head, Bioinformatics Division
> >
> > [WEHI Logo]
> >
> >
> > Walter and Eliza Hall Institute of Medical Research
> > 1G Royal Parade Parkville Victoria 3052 Australia
> >
> > www.wehi.edu.au
> >
> > Twitter  |  Facebook<
> https://www.facebook.com/WEHIresearch/>  |  Instagram<
> https://www.instagram.com/wehi_research>  |  Youtube<
> https://www.youtube.com/user/WEHImovies>  |  LinkedIn<
> https://www.linkedin.com/company/wehi_research>
> >
> >
> > WEHI acknowledges the Wurundjeri people of the Kulin Nation as the
> traditional owners of the land where our campuses are located and the
> continuing connection to country and community.
> >
> > Private and confidential
> > The content of this e-mail and any attachments may be private and
> confidential, intended only for use of the individual or entity named. If
> you are not the intended recipient of this message you must not read,
> forward, print, copy, disclose, use or store in any way the information
> this e-mail or any attachment contains. If you are not the intended
> recipient, please notify the sender immediately and delete or destroy all
> copies of this e-mail and any attachment.
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> --
> The information in this e-mail is intended only for th...{{dropped:10}}

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

[Bioc-devel] BiocCheck fails during Github action workflow

[Oleksii Nikolaienko]

Hi,
this question probably relates to Bioc docker images, thus asking here
first.
I am using biocthis GitHub action

and
I recently noticed that it started to fail with a BiocCheck message:
"ERROR: dependencies ‘GenomicRanges’, ‘BiocGenerics’, ‘GenomeInfoDb’,
‘SummarizedExperiment’, ‘VariantAnnotation’, ‘data.table’, ‘Rcpp’, ‘BH’,
‘Rhtslib’, ‘zlibbioc’ are not available for package ‘epialleleR’".
Does it relate to some changes in docker images, or BiocCheck::BiocCheck
configuration, or it's wrong invocation (in a pretty standard action
workflow)?

Best regards,
Oleksii

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] printing GRanges fails

[Oleksii Nikolaienko]

Ok, thanks very much Herve. I didn't know about these changes.

Best,
Oleksii

On Sun, 21 Nov 2021 at 20:17, Hervé Pagès 
wrote:

> Hi Oleksii,
>
> This was caused by the serialized object in ramr/data/ramr.rda being
> out-of-sync with the latest changes in S4Vectors (DataFrame became a
> virtual class in S4Vectors 0.33.3). See
>
>
>
> https://bioconductor.org/help/course-materials/2019/BiocDevelForum/02-DataFrame.pdf
>
> for the motivation behind this change.
>
> Many packages contain serialized S4 objects with this problem. Most of
> them got fixed in devel already. Yours was fixed today (ramr 1.3.1,
> commit 6f30c30) so the error should clear on tomorrow's build report.
>
> Make sure to resync your GitHub repo with the ramr repo at
> git.bioconductor.org by following the instructions described here:
>
>https://bioconductor.org/developers/how-to/git/
>
> Cheers,
> H.
>
>
> On 21/11/2021 07:28, Oleksii Nikolaienko wrote:
> > Hi,
> > devel branch of my package (ramr) cannot be built due to an error which I
> > don't understand. Package has sample data of class GRanges, but when I
> try
> > to print it I get the following:
> >> library(ramr)
> >> data(ramr)
> >> class(ramr.data)
> > [1] "GRanges"
> > attr(,"package")
> > [1] "GenomicRanges"
> >> ramr.data
> > GRanges object with 3000 ranges and 100 metadata columns:
> > Error: C stack usage  7954616 is too close to the limit
> >
> > This object seems to be ok in the release branch. Could anyone advise me
> on
> > further steps, please?
> >
> > Best regards,
> > Oleksii Nikolaienko
> >
> >   [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
> --
> Hervé Pagès
>
> Bioconductor Core Team
> hpages.on.git...@gmail.com
>

[[alternative HTML version deleted]]

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

[Bioc-devel] printing GRanges fails

[Oleksii Nikolaienko]

Hi,
devel branch of my package (ramr) cannot be built due to an error which I
don't understand. Package has sample data of class GRanges, but when I try
to print it I get the following:
> library(ramr)
> data(ramr)
> class(ramr.data)
[1] "GRanges"
attr(,"package")
[1] "GenomicRanges"
> ramr.data
GRanges object with 3000 ranges and 100 metadata columns:
Error: C stack usage  7954616 is too close to the limit

This object seems to be ok in the release branch. Could anyone advise me on
further steps, please?

Best regards,
Oleksii Nikolaienko

[[alternative HTML version deleted]]

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

[Bioc-devel] Build report page is not updated, DOI leads nowhere

[Oleksii Nikolaienko]

Dear Bioc team,
I recently pushed changes to the release branch and was waiting for
http://bioconductor.org/checkResults/release/bioc-LATEST/ramr/ page to
reflect them. Strangely, this page does not, while
http://bioconductor.org/packages/3.13/bioc/html/ramr.html shows a new,
updated version of the package available.
And also, I know that some issues with package DOIs were reported
previously, but didn't understand if they are fixed on an individual basis
or if a general solution will be available. Mine doesn't point to the
package - https://doi.org/doi:10.18129/B9.bioc.ramr, I wonder if this can
be fixed.

Best regards,
Oleksii Nikolaienko

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] SplicingFactory: problem with release bugfix build

[Oleksii Nikolaienko]

Hi Endre,
I guess it's because it hasn't been built yet. I'm also waiting for the
build, but it looks like it happens once in three days, is that correct?

Best,
Oleksii

On Fri, 25 Jun 2021 at 22:56, Endre Sebestyen 
wrote:

> Hi all,
>
> I fixed some bugs in our package SplicingFactory, both for devel and
> release branches. I also pushed to github and bioconductor master and
> release.
>
> However, the devel build seems to be ok:
> https://bioconductor.org/checkResults/devel/bioc-LATEST/SplicingFactory/
>
> but the release is still at the previous version:
> https://bioconductor.org/checkResults/release/bioc-LATEST/SplicingFactory/
>
> tamas_por/SplicingFactory - [RELEASE_3_13] »  git remote -v
> origin g...@github.com:SU-CompBio/SplicingFactory.git (fetch)
> origin g...@github.com:SU-CompBio/SplicingFactory.git (push)
> upstream g...@git.bioconductor.org:packages/SplicingFactory.git (fetch)
> upstream g...@git.bioconductor.org:packages/SplicingFactory.git (push)
> tamas_por/SplicingFactory - [RELEASE_3_13] » git push upstream RELEASE_3_13
> Everything up-to-date
> tamas_por/SplicingFactory - [RELEASE_3_13] » git push origin RELEASE_3_13
> Everything up-to-date
> tamas_por/SplicingFactory - [RELEASE_3_13] » grep Version DESCRIPTION
> Version: 1.0.3
> tamas_por/SplicingFactory - [RELEASE_3_13] » git checkout master
> Switched to branch 'master'
> Your branch is up to date with 'origin/master'.
> tamas_por/SplicingFactory - [master] » git push upstream master
> Everything up-to-date
> tamas_por/SplicingFactory - [master] » git push origin master
> Everything up-to-date
> tamas_por/SplicingFactory - [master] » grep Version DESCRIPTION
> Version: 1.1.3
>
> I don’t see what am I doing wrong. Any suggestions?
>
> Thanks,
>
> Endre
>
> ___
> 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] C++ parallel computing

[Oleksii Nikolaienko]

Thank you for the information. I guess I'll try to stick to the R-level
parallelization whenever possible.

Best,
Oleksii

On Wed, 26 May 2021 at 13:47, Martin Morgan  wrote:

> The best way to process large files is in chunks using BamFile(…,
> yieldSize = …) and by using ScanBamParam() to select just the components of
> the bam files of interest. The number of cores is basically irrelevant for
> input -- you'll be using just one, so choose yieldSize to use modest
> amounts of memory for primary data, e.g, 4 GB per file, and process each
> file separately.
>
> Figure the iteration-by-chunk solution for one file; the simplest example
> is in ?Rsamtools::BamFile
>
>
>  ## Use 'yieldSize' to iterate through a file in chunks.
>  bf <- open(BamFile(fl, yieldSize=1000))
>  while (nrec <- length(scanBam(bf)[[1]][[1]]))
>  cat("records:", nrec, "\n")
>  close(bf)
>
> but you'd likely want the convenience of
> GenomicAlignments::readGAlignments() / readGAlignmentPairs().
>
> Once this is working, write this as a proper function, specifying all
> packages required for the function to complete, e.g.,
>
> fun = function(fl, yieldSize) {
> library(Rsamtools)
> nrec <- 0L
> bf <- open(BamFile(fl, yieldSize=yieldSize))
> repeat {
> len <- length(scanBam(bf)[[1]][[1]])
> if (len == 0L)
> break
> nrec = nrec + len
> }
> close(bf)
> nrec
> }
>
> try to minimize the size of the inputs (here just the file name) and the
> outputs (nrec, a single integer), perhaps using the file system to
> temporarily store large results. Use BiocParallel::bplapply to apply this
> to all files
>
> bplapply(fls, fun, yieldSize = 100)
>
> I would actually recommend BiocParallel::SnowParam() (separate processes)
> because (a) this enforces the discipline that the function does not rely
> implicitly on the state of the parent process and (b) ensures operation
> across all OS, and easier transition to, e.g., an HPC cluster. The fixed
> cost of starting separate processes for each file are outweighed by the
> time spent processing the file in the process.
>
> GenomicFiles::reduceByYield() or reduceByFile() might be relevant.
>
> I am not totally current (others on this list probably know more) but I
> don't think openMP is supported on MacOS (
> https://mac.r-project.org/openmp/) so would be a poor choice at the C
> level if cross-platform utility were important. If it were me, and again I
> do not have enough recent experience, I might aim for Intel Threaded
> Building Blocks, using RcppParallel for inspiration.
>
> Martin
>
> From: Oleksii Nikolaienko 
> Date: Tuesday, May 25, 2021 at 6:28 PM
> To: Martin Morgan 
> Cc: "bioc-devel@r-project.org" 
> Subject: Re: [Bioc-devel] C++ parallel computing
>
> Hi Martin,
> thanks for your answer. The goal is to speed up my package (epialleleR),
> where most of the functions are already written in C++, but the code is
> single-threaded. Tasks include: apply analog of
> GenomicAlignments::sequenceLayer to SEQ, QUAL and XM strings, calculate
> per-read methylation beta values, create methylation cytosine reports with
> prefiltering of sequence reads. Probably all of them I could parallelize
> at the level of R, but even in this case I'd maybe like to use OpenMP SIMD
> directives.
> And yes, the plan is to use Rhtslib. Current backend for reading BAM
> is Rsamtools, however I believe I could speed things up significantly by
> avoiding unnecessary type conversions and cutting other corners. It doesn't
> hurt much when the BAM file is smaller than 1GB, but for 20-40GB file
> loading takes more than an hour (24 cores, 378GB RAM workstation).
>
> Best,
> Oleksii
>
>
> On Tue, 25 May 2021 at 19:39, Martin Morgan  mtmorgan.b...@gmail.com> wrote:
> If the BAM files are each processed independently, and each processing
> task takes a while, then it is probably 'good enough' to use R-level
> parallel evaluation using BiocParallel (currently the recommendation for
> Bioconductor packages) or other evaluation framework. Also, presumably you
> will use Rhtslib, which provides C-level access to the hts library. This
> will requiring writing C / C++ code to interface between R and the hts
> library, and will of course be a significant underataking.
>
> It might be worth outlining in a bit more detail what your task is and how
> (not too much detail!) you've tried to implement this in Rsamtools.
>
> Martin Morgan
>
> On 5/24/21, 10:01 AM, "Bioc-devel on behalf of Oleksii Nikolaienko"
> <mailto:bioc-devel-boun..

Re: [Bioc-devel] %outside% on GRanges

[Oleksii Nikolaienko]

Thanks very much for the explanation, Jim.

Best,
Oleksii

On Wed, 26 May 2021 at 16:28, James W. MacDonald  wrote:

> Hi Oleksii,
>
> That function is just a simplification of the negation of overlapsAny:
>
> > getAnywhere("%outside%")
> A single object matching '%outside%' was found
> It was found in the following places
>   package:IRanges
>   namespace:IRanges
> with value
>
> function (query, subject)
> !overlapsAny(query, subject)
> 
> 
>
> And overlapsAny has dispatch on Granges objects via inheritance from the
> Vector class.
>
> > showMethods("overlapsAny")
> Function: overlapsAny (package IRanges)
> query="GRanges", subject="GRanges"
> (inherited from: query="Vector", subject="Vector")
> query="integer", subject="Vector"
> query="IntegerRangesList", subject="IntegerRangesList"
> query="Vector", subject="missing"
> query="Vector", subject="Vector"
>
> So far as I can tell there is no code in GenomicRanges to make this happen
> - it just dispatches via inheritance - so there is no direct help page in
> GenomicRanges.
>
> Best,
>
> Jim
>
>
>
>
> -Original Message-
> From: Bioc-devel  On Behalf Of Oleksii
> Nikolaienko
> Sent: Wednesday, May 26, 2021 9:15 AM
> To: bioc-devel@r-project.org
> Subject: [Bioc-devel] %outside% on GRanges
>
> Dear Bioc team,
> %outside% operator from IRanges works as one would expect even if GRanges
> objects are supplied as operands:
>
>
> > a <- as("chr1:100-200", "GRanges")
> > b <- as("chr2:150-250", "GRanges")
> > IRanges::`%outside%`(a, b)
> [1] TRUE
>
> > IRanges::`%outside%`(ranges(a), ranges(b))
> [1] FALSE
>
> It is correct and intuitive, but %outside% does not seem to be defined or
> included in help pages of the GenomicRanges library. Can I rely on such
> behaviour of %outside% in the future?
>
> Best,
> Oleksii Nikolaienko
>
> [[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] %outside% on GRanges

[Oleksii Nikolaienko]

Dear Bioc team,
%outside% operator from IRanges works as one would expect even if GRanges
objects are supplied as operands:


> a <- as("chr1:100-200", "GRanges")
> b <- as("chr2:150-250", "GRanges")
> IRanges::`%outside%`(a, b)
[1] TRUE

> IRanges::`%outside%`(ranges(a), ranges(b))
[1] FALSE

It is correct and intuitive, but %outside% does not seem to be defined or
included in help pages of the GenomicRanges library. Can I rely on such
behaviour of %outside% in the future?

Best,
Oleksii Nikolaienko

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] C++ parallel computing

[Oleksii Nikolaienko]

Hi Martin,
thanks for your answer. The goal is to speed up my package (epialleleR),
where most of the functions are already written in C++, but the code is
single-threaded. Tasks include: apply analog of
GenomicAlignments::sequenceLayer to SEQ, QUAL and XM strings, calculate
per-read methylation beta values, create methylation cytosine reports with
prefiltering of sequence reads. Probably all of them I could parallelize
at the level of R, but even in this case I'd maybe like to use OpenMP SIMD
directives.
And yes, the plan is to use Rhtslib. Current backend for reading BAM
is Rsamtools, however I believe I could speed things up significantly by
avoiding unnecessary type conversions and cutting other corners. It doesn't
hurt much when the BAM file is smaller than 1GB, but for 20-40GB file
loading takes more than an hour (24 cores, 378GB RAM workstation).

Best,
Oleksii


On Tue, 25 May 2021 at 19:39, Martin Morgan  wrote:

> If the BAM files are each processed independently, and each processing
> task takes a while, then it is probably 'good enough' to use R-level
> parallel evaluation using BiocParallel (currently the recommendation for
> Bioconductor packages) or other evaluation framework. Also, presumably you
> will use Rhtslib, which provides C-level access to the hts library. This
> will requiring writing C / C++ code to interface between R and the hts
> library, and will of course be a significant underataking.
>
> It might be worth outlining in a bit more detail what your task is and how
> (not too much detail!) you've tried to implement this in Rsamtools.
>
> Martin Morgan
>
> On 5/24/21, 10:01 AM, "Bioc-devel on behalf of Oleksii Nikolaienko" <
> bioc-devel-boun...@r-project.org on behalf of
> oleksii.nikolaie...@gmail.com> wrote:
>
> Dear Bioc team,
> I'd like to ask for your advice on the parallelization within a Bioc
> package. Please point me to a better place if this mailing list is not
> appropriate.
> After a bit of thinking I decided that I'd like to parallelize
> processing
> at the level of C++ code. Would you strongly recommend not to and use
> an R
> approach instead (e.g. "future")?
> If parallel C++ is ok, what would be the best solution for all major
> OSs?
> My initial choice was OpenMP, but then it seems that Apple has
> something
> against it (https://mac.r-project.org/openmp/). My own dev
> environment is
> mostly Big Sur/ARM64, but I wouldn't want to drop its support anyway.
>
> (On the actual task: loading and specific processing of very large BAM
> files, ideally significantly faster than by means of Rsamtools as a
> backend)
>
> Best,
> Oleksii Nikolaienko
>
> [[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] C++ parallel computing

[Oleksii Nikolaienko]

Dear Bioc team,
I'd like to ask for your advice on the parallelization within a Bioc
package. Please point me to a better place if this mailing list is not
appropriate.
After a bit of thinking I decided that I'd like to parallelize processing
at the level of C++ code. Would you strongly recommend not to and use an R
approach instead (e.g. "future")?
If parallel C++ is ok, what would be the best solution for all major OSs?
My initial choice was OpenMP, but then it seems that Apple has something
against it (https://mac.r-project.org/openmp/). My own dev environment is
mostly Big Sur/ARM64, but I wouldn't want to drop its support anyway.

(On the actual task: loading and specific processing of very large BAM
files, ideally significantly faster than by means of Rsamtools as a backend)

Best,
Oleksii Nikolaienko

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] non-subsettable GRanges object

[Oleksii Nikolaienko]

Thanks very much, Hervé, I indeed never noticed the wrong number of
elements in my objects.

Best regards,
Oleksii

On Tue, 6 Apr 2021 at 02:10, Hervé Pagès  wrote:

> This is fixed in S4Vectors 0.29.13:
>
> https://github.com/Bioconductor/S4Vectors/commit/6d79932910af9618465d5f932df5864d0a270e11
>
> This new version of S4Vectors should propagate to the build machines and
> become available via BiocManager::install() in the next 48h or so.
>
> Cheers,
> H.
>
> On 4/5/21 3:40 PM, Hervé Pagès wrote:
> > Hi Oleksii,
> >
> > It looks like we have a long-standing bug in the rbind() method for
> > DataFrame objects that is somehow surfacing now. Here is a simple
> example:
> >
> >library(IRanges)
> >DF1 <- DataFrame(A=I(list(11:12, 21:23)))
> >DF2 <- DataFrame(A=IntegerList(31:34, 41:45, 51:56))
> >DF3 <- rbind(DF1, DF2)
> >DF3
> ># DataFrame with 3 rows and 1 column
> >#A
> >#   
> ># 1  11,12
> ># 2   21,22,23
> ># 3 31,32,33,...,41,42,43,...,51,52,53,...
> >
> > This result is wrong. We observe this in release and devel.
> >
> > If you look at the mcols of the GRanges object returned by getAMR() in
> > your code below, you'll see that it's actually an invalid DataFrame
> > object (its first column has 23 elements but 22 are expected). This is a
> > consequence of the above bug. Even though the bug has existed for a long
> > time, somehow it was not affecting your code. However this changed
> > recently because of some minor refactoring of the rbind() method for
> > DataFrame objects that I made a few days ago in S4Vectors.
> >
> > I'm working on a fix and will let you know when it's ready.
> >
> > Cheers,
> > H.
> >
> >
> > On 4/5/21 1:12 PM, Oleksii Nikolaienko wrote:
> >> Dear Bioc team,
> >> my package has started to fail during the build check (
> >> http://bioconductor.org/checkResults/devel/bioc-LATEST/ramr/). I tried
> to
> >> figure out why and it appears that I somehow make GRanges object
> >> non-subsettable. Could anyone from "GenomicRanges" developers look at my
> >> issue and advise me on a solution, please?
> >>
> >> To reproduce:
> >>
> >> library(ramr)
> >> data(ramr)
> >> amrs <- getAMR(ramr.data, ramr.samples, ramr.method="beta", min.cpgs=5,
> >> merge.window=1000, qval.cutoff=1e-3, cores=2)
> >> # this works:
> >> class(amrs)
> >> amrs
> >> # error:
> >> amrs[2]
> >> # suddenly works again:
> >> GRangesList(amrs)[[1]][2]
> >>
> >>
> >> Best regards,
> >> Oleksii
> >>
> >> [[alternative HTML version deleted]]
> >>
> >> ___
> >> Bioc-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >>
> >
>
> --
> Hervé Pagès
>
> Bioconductor Core Team
> hpages.on.git...@gmail.com
>

[[alternative HTML version deleted]]

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

[Bioc-devel] non-subsettable GRanges object

[Oleksii Nikolaienko]

Dear Bioc team,
my package has started to fail during the build check (
http://bioconductor.org/checkResults/devel/bioc-LATEST/ramr/). I tried to
figure out why and it appears that I somehow make GRanges object
non-subsettable. Could anyone from "GenomicRanges" developers look at my
issue and advise me on a solution, please?

To reproduce:

library(ramr)
data(ramr)
amrs <- getAMR(ramr.data, ramr.samples, ramr.method="beta", min.cpgs=5,
merge.window=1000, qval.cutoff=1e-3, cores=2)
# this works:
class(amrs)
amrs
# error:
amrs[2]
# suddenly works again:
GRangesList(amrs)[[1]][2]


Best regards,
Oleksii

[[alternative HTML version deleted]]

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