Re: [Bioc-devel] Question relating to extending a class and inclusion of data
I replied the wrong email sorry. Please ignore. On 5/23/24 11:40, Hervé Pagès wrote: > > Ok I downloaded the SecureLink Connection Manager (file > connection-manager.run) on my Linux laptop (got a big warning from > Chrome that this kind of file is dangerous, I found this pretty ironic). > > Then I started it with > > bash connection-manager.run > > (you have to kind of figure out these things by yourself) > > That displays a small popup window that says: > > securelink.partners.org > > Connected to the server > > And now what? > > The page at https://securelink.partners.org/ also says that I'm > connected to kraken.dfci.harvard.edu but how do I actually access that > machine? > > Thanks for your help. > > H. > > On 5/22/24 16:29, Hervé Pagès wrote: >> >> On 5/22/24 02:16, Vincent Carey wrote: >> >>> ... >>> >>> > Q4: Do you think a separate ExperimentData package satisfying >>> the specifications laid out in Background 2 is warranted? This >>> could be included in a future version with >>> SummarizedExperiment/MetaboExperiment support. >>> It depends on the size of the data. For a software package, we >>> limit the >>> size of the source tarball to 5G. So if you're going to exceed that >>> limit then the datasets need to go in an experiment data package. >>> >>> >>> Not 5G. Compressed tarball size may not exceed 5MB. See >>> https://contributions.bioconductor.org/general.html, sec 3.2.5. >> >> oops! Yes of course. Thanks for the catch! >> >> -- >> Hervé Pagès >> >> Bioconductor Core Team >> hpages.on.git...@gmail.com > -- > Hervé Pagès > > Bioconductor Core Team > hpages.on.git...@gmail.com -- 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
Re: [Bioc-devel] Question relating to extending a class and inclusion of data
Ok I downloaded the SecureLink Connection Manager (file connection-manager.run) on my Linux laptop (got a big warning from Chrome that this kind of file is dangerous, I found this pretty ironic). Then I started it with bash connection-manager.run (you have to kind of figure out these things by yourself) That displays a small popup window that says: securelink.partners.org Connected to the server And now what? The page at https://securelink.partners.org/ also says that I'm connected to kraken.dfci.harvard.edu but how do I actually access that machine? Thanks for your help. H. On 5/22/24 16:29, Hervé Pagès wrote: > > On 5/22/24 02:16, Vincent Carey wrote: > >> ... >> >> > Q4: Do you think a separate ExperimentData package satisfying >> the specifications laid out in Background 2 is warranted? This >> could be included in a future version with >> SummarizedExperiment/MetaboExperiment support. >> It depends on the size of the data. For a software package, we >> limit the >> size of the source tarball to 5G. So if you're going to exceed that >> limit then the datasets need to go in an experiment data package. >> >> >> Not 5G. Compressed tarball size may not exceed 5MB. See >> https://contributions.bioconductor.org/general.html, sec 3.2.5. > > oops! Yes of course. Thanks for the catch! > > -- > Hervé Pagès > > Bioconductor Core Team > hpages.on.git...@gmail.com -- 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
Re: [Bioc-devel] Question relating to extending a class and inclusion of data
On 5/22/24 02:16, Vincent Carey wrote: > ... > > > Q4: Do you think a separate ExperimentData package satisfying > the specifications laid out in Background 2 is warranted? This > could be included in a future version with > SummarizedExperiment/MetaboExperiment support. > It depends on the size of the data. For a software package, we > limit the > size of the source tarball to 5G. So if you're going to exceed that > limit then the datasets need to go in an experiment data package. > > > Not 5G. Compressed tarball size may not exceed 5MB. See > https://contributions.bioconductor.org/general.html, sec 3.2.5. oops! Yes of course. Thanks for the catch! -- 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
Re: [Bioc-devel] Question relating to extending a class and inclusion of data
. Sample data > needs to include study group, time point, subject ID and several batches. > Blank samples would be good as well. Packages I have checked for data with > the above specifications include FaahKO, MetaMSdata, msdata, msqc1, mtbls2, > pmp, PtH2O2lipids, and ropls. As of now, the example data is not realistic in > that it is scrambled and I have not yet been informed of the origin and > modification of the data. > > Q3: If I get access to information about the origin and modification of the > now used data, can I further modify it to satisfy the needs of the package > for an initial Bioconductor release? Or does it need to be realistic? > Consider this the explicit pre-approval inquiry for including data in the > notame package. I'm not sure I fully understand the question (or its connection with Excel) but yes you can include unrealistic data in the package. As long as it allows you to properly illustrate the basic usage of your functions in the man pages and/or vignette(s). It can also be useful to have small (and unrealistic) data for the unit tests. The important thing here is that the data must be small. > Q4: Do you think a separate ExperimentData package satisfying the > specifications laid out in Background 2 is warranted? This could be included > in a future version with SummarizedExperiment/MetaboExperiment support. It depends on the size of the data. For a software package, we limit the size of the source tarball to 5G. So if you're going to exceed that limit then the datasets need to go in an experiment data package. > > Q5: The instructions state that the data needs to be documented > (https://contributions.bioconductor.org/docs.html#doc-inst-script). Is the > availability of the original data strictly necessary? I notice many packages > don't include documentation on how the data was procured. The availability of the original data is not strictly necessary but the data still needs to be documented i.e. what's its nature, where it's coming from, how it was imported/transformed, etc... Best, H. > > Thanks, > Vilhelm Suksi > Turku Data Science Group > vks...@utu.fi > > ___ > 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
Re: [Bioc-devel] Build errors related to the new pwalign package
I forgot to mention that the BLOSUM and PAM substitution matrices have also moved from Biostrings to the new pwalign package. 37 software packages were affected by this move (see list below). All of them have been fixed. If you maintain one of them, please resync your GitHub repo with the repo at git.bioconductor.org. Let me know if you have any questions. Cheers, H. List of software packages that were affected by the Biostrings/pwalign split (in alphabetical order): amplican ChIPpeakAnno ClustIRR CNEr crisprShiny DECIPHER DominoEffect enhancerHomologSearch girafe GUIDEseq hiReadsProcessor HTSeqGenie idpr IMMAN iPAC IsoformSwitchAnalyzeR LinTInd MethTargetedNGS methylscaper motifbreakR msa MSA2dist openPrimeR QSutils QuartPAC R453Plus1Toolbox Rcpi RSVSim sangeranalyseR sangerseqR scanMiR ShortRead SPLINTER StructuralVariantAnnotation svaNUMT TFBSTools XNAString On 4/24/24 09:52, Hervé Pagès wrote: > > Hi developers, > > pairwiseAlignement() and stringDist() have recently moved from > Biostrings to the new pwalign package. This is causing a number of > failures today on the 3.19 report. Since yesterday I've been actively > repairing packages affected by this by pushing fixes to > git.bioconductor.org. Most packages are now fixed but this won't > reflect before tomorrow's report. > > Later in the day I'll send emails to the maintainers of packages that > I have touched and ask them to resync their GitHub repos with > git.bioconductor.org. > > Sorry for the inconvenience. > > Let me know if you have any questions. > > Best, > > H. > > -- > Hervé Pagès > > Bioconductor Core Team > hpages.on.git...@gmail.com -- 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
Re: [Bioc-devel] Biostrings: substitution matrices disappeared?
Good. I also just pushed 2 additional small tweaks (commits 0e98500 and 84c8ed5) right after you pushed yours. Hopefully I didn't step on your toes. H. On 4/25/24 01:04, Ulrich Bodenhofer wrote: > > Great, thanks, Hervé! I also made two more fixes and pushed them. > > Cheers, Ulrich > > *From:*Hervé Pagès > *Sent:* Thursday, April 25, 2024 9:52 AM > *To:* ulr...@bodenhofer.com > *Cc:* bioc-devel@r-project.org; 'Martin Grigorov' > > *Subject:* Re: [Bioc-devel] Biostrings: substitution matrices disappeared? > > I'm done. Please resync you GitHub repo. > > Best, > > H. > > On 4/25/24 00:14, Ulrich Bodenhofer wrote: > > Great, thanks, Hervé, so I’ll simply wait for the update. If there > is anything I should do, just let me know. > > Thanks and best regards, > > Ulrich > > *From:*Hervé Pagès > <mailto:hpages.on.git...@gmail.com> > *Sent:* Thursday, April 25, 2024 9:06 AM > *To:* ulr...@bodenhofer.com; 'Martin Grigorov' > <mailto:martin.grigo...@gmail.com> > *Cc:* bioc-devel@r-project.org > *Subject:* Re: [Bioc-devel] Biostrings: substitution matrices > disappeared? > > Hi Ulrich, > > Yes the substitution matrices are now in pwalign. I'm taking care > of msa. Sorry for that. > > Best, > > H. > > On 4/24/24 23:25, Ulrich Bodenhofer wrote: > > Ah, thank you very much, sorry for having overlooked this! Yes, that > seems the source of the problem. Hervé, should I wait for your update or > rather change the package myself? The latter won’t be a problem for me. I > suppose it is just about adding ‘pwalign’ as an additional dependency, right? > > > > Thanks and best regards, > > Ulrich > > > > > > From: Martin Grigorov > <mailto:martin.grigo...@gmail.com> > > Sent: Thursday, April 25, 2024 7:52 AM > > To:ulr...@bodenhofer.com > > Cc:bioc-devel@r-project.org > > Subject: Re: [Bioc-devel] Biostrings: substitution matrices > disappeared? > > > > Hi, > > > > Yesterday there was another email about Biostrings > -https://stat.ethz.ch/pipermail/bioc-devel/2024-April/020395.html > > I thought it might be related to your problem. > > > > Regards, > > Martin > > > > On Thu, Apr 25, 2024 at 8:23 AM Ulrich > Bodenhofer<mailto:ulrich.bodenho...@gmail.com> > <mailto:ulrich.bodenho...@gmail.com> wrote: > > Dear colleagues, dear BioC core team, > > > > One of my packages in the devel branch, the ‘msa’ package seems > broken since > > yesterday. The vignette does not run anymore (therefore, the package > does > > not build), and the reason is that the BLOSUM62 substitution matrix > cannot > > be loaded form the ‘Biostrings’ package anymore. I checked the > ‘Biostrings’ > > package. In Version 2.70.3 in the release branch, the substitution > matrices > > were still in the ‘data/’ directory. In the current devel version > 2.71.6, > > they have disappeared. I found no hint to that in the NEWS file. So, > I want > > to kindly ask the maintainers of the ‘Biostrings’ package to give me > some > > advice how to fix that on my side or, in case that this is an error > in the > > current devel version of the ‘Biostrings’ package, to have a look > into this. > > > > Thanks a lot in advance, best regards, > > Ulrich > > > > ___ > > mailto:Bioc-devel@r-project.org <mailto: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 > > -- > Hervé Pagès > Bioconductor Core Team > hpages.on.git...@gmail.com -- 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
Re: [Bioc-devel] Biostrings: substitution matrices disappeared?
I'm done. Please resync you GitHub repo. Best, H. On 4/25/24 00:14, Ulrich Bodenhofer wrote: > > Great, thanks, Hervé, so I’ll simply wait for the update. If there is > anything I should do, just let me know. > > Thanks and best regards, > > Ulrich > > *From:*Hervé Pagès > *Sent:* Thursday, April 25, 2024 9:06 AM > *To:* ulr...@bodenhofer.com; 'Martin Grigorov' > *Cc:* bioc-devel@r-project.org > *Subject:* Re: [Bioc-devel] Biostrings: substitution matrices disappeared? > > Hi Ulrich, > > Yes the substitution matrices are now in pwalign. I'm taking care of > msa. Sorry for that. > > Best, > > H. > > On 4/24/24 23:25, Ulrich Bodenhofer wrote: > > Ah, thank you very much, sorry for having overlooked this! Yes, that > seems the source of the problem. Hervé, should I wait for your update or > rather change the package myself? The latter won’t be a problem for me. I > suppose it is just about adding ‘pwalign’ as an additional dependency, right? > > Thanks and best regards, > > Ulrich > > From: Martin Grigorov > <mailto:martin.grigo...@gmail.com> > > Sent: Thursday, April 25, 2024 7:52 AM > > To:ulr...@bodenhofer.com > > Cc:bioc-devel@r-project.org > > Subject: Re: [Bioc-devel] Biostrings: substitution matrices disappeared? > > Hi, > > Yesterday there was another email about Biostrings > -https://stat.ethz.ch/pipermail/bioc-devel/2024-April/020395.html > > I thought it might be related to your problem. > > Regards, > > Martin > > On Thu, Apr 25, 2024 at 8:23 AM Ulrich > Bodenhofer<mailto:ulrich.bodenho...@gmail.com> > <mailto:ulrich.bodenho...@gmail.com> wrote: > > Dear colleagues, dear BioC core team, > > One of my packages in the devel branch, the ‘msa’ package seems broken > since > > yesterday. The vignette does not run anymore (therefore, the package does > > not build), and the reason is that the BLOSUM62 substitution matrix cannot > > be loaded form the ‘Biostrings’ package anymore. I checked the > ‘Biostrings’ > > package. In Version 2.70.3 in the release branch, the substitution > matrices > > were still in the ‘data/’ directory. In the current devel version 2.71.6, > > they have disappeared. I found no hint to that in the NEWS file. So, I > want > > to kindly ask the maintainers of the ‘Biostrings’ package to give me some > > advice how to fix that on my side or, in case that this is an error in the > > current devel version of the ‘Biostrings’ package, to have a look into > this. > > Thanks a lot in advance, best regards, > > Ulrich > > ___ > > mailto:Bioc-devel@r-project.org <mailto: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 -- 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
Re: [Bioc-devel] Biostrings: substitution matrices disappeared?
Hi Ulrich, Yes the substitution matrices are now in pwalign. I'm taking care of msa. Sorry for that. Best, H. On 4/24/24 23:25, Ulrich Bodenhofer wrote: > Ah, thank you very much, sorry for having overlooked this! Yes, that seems > the source of the problem. Hervé, should I wait for your update or rather > change the package myself? The latter won’t be a problem for me. I suppose it > is just about adding ‘pwalign’ as an additional dependency, right? > > Thanks and best regards, > Ulrich > > > From: Martin Grigorov > Sent: Thursday, April 25, 2024 7:52 AM > To:ulr...@bodenhofer.com > Cc:bioc-devel@r-project.org > Subject: Re: [Bioc-devel] Biostrings: substitution matrices disappeared? > > Hi, > > Yesterday there was another email about Biostrings > -https://stat.ethz.ch/pipermail/bioc-devel/2024-April/020395.html > I thought it might be related to your problem. > > Regards, > Martin > > On Thu, Apr 25, 2024 at 8:23 AM Ulrich > Bodenhofer<mailto:ulrich.bodenho...@gmail.com> wrote: > Dear colleagues, dear BioC core team, > > One of my packages in the devel branch, the ‘msa’ package seems broken since > yesterday. The vignette does not run anymore (therefore, the package does > not build), and the reason is that the BLOSUM62 substitution matrix cannot > be loaded form the ‘Biostrings’ package anymore. I checked the ‘Biostrings’ > package. In Version 2.70.3 in the release branch, the substitution matrices > were still in the ‘data/’ directory. In the current devel version 2.71.6, > they have disappeared. I found no hint to that in the NEWS file. So, I want > to kindly ask the maintainers of the ‘Biostrings’ package to give me some > advice how to fix that on my side or, in case that this is an error in the > current devel version of the ‘Biostrings’ package, to have a look into this. > > Thanks a lot in advance, best regards, > Ulrich > > _______ > mailto: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] Build errors related to the new pwalign package
Hi developers, pairwiseAlignement() and stringDist() have recently moved from Biostrings to the new pwalign package. This is causing a number of failures today on the 3.19 report. Since yesterday I've been actively repairing packages affected by this by pushing fixes to git.bioconductor.org. Most packages are now fixed but this won't reflect before tomorrow's report. Later in the day I'll send emails to the maintainers of packages that I have touched and ask them to resync their GitHub repos with git.bioconductor.org. Sorry for the inconvenience. Let me know if you have any questions. Best, H. -- 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
Re: [Bioc-devel] nebbiolo1 - build report
As for the error you will see when today's report gets published it's caused by the recent move of the pairwiseAlignment stuff from Biostrings to the new pwalign package. I fixed it in MSA2dist 1.7.6 so it will go away in tomorrow's report. Please resync your GitHub repo with git.bioconductor.org when you get a chance. H. On 4/24/24 09:18, Hervé Pagès wrote: > > Hi Kristian, > > I believe that this is because the new report didn't get published yet > so the links in the email you received still points to yesterday's > report. We're investigating. > > Best, > > H. > > On 4/24/24 09:10, Kristian Ullrich wrote: >> Hi, >> >> I just got an email from bbs: >> >> Hi MSA2dist maintainer, >> >> According to the Multiple platform build/check report for BioC 3.19, >> the MSA2dist package has the following problem(s): >> >> o ERROR for 'R CMD INSTALL' on nebbiolo1. See the details here: >> >> https://bioconductor.org/checkResults/3.19/bioc-LATEST/MSA2dist/nebbiolo1-install.html >> >> <https://bioconductor.org/checkResults/3.19/bioc-LATEST/MSA2dist/nebbiolo1-install.html> >> >> o ERROR for 'R CMD build' on nebbiolo1. See the details here: >> >> https://bioconductor.org/checkResults/3.19/bioc-LATEST/MSA2dist/nebbiolo1-buildsrc.html >> >> <https://bioconductor.org/checkResults/3.19/bioc-LATEST/MSA2dist/nebbiolo1-buildsrc.html> >> >> However, if I check the the page, there are no ERROR listed: >> >> Report page was generated: >> >> This page was generated on 2024-04-23 11:37:19 -0400 (Tue, 23 Apr 2024). >> >> Should I just wait or where I can find the mentioned ERROR? >> >> Best regards >> >> Kristian >> > -- > Hervé Pagès > > Bioconductor Core Team > hpages.on.git...@gmail.com -- 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
Re: [Bioc-devel] nebbiolo1 - build report
Hi Kristian, I believe that this is because the new report didn't get published yet so the links in the email you received still points to yesterday's report. We're investigating. Best, H. On 4/24/24 09:10, Kristian Ullrich wrote: > Hi, > > I just got an email from bbs: > > Hi MSA2dist maintainer, > > According to the Multiple platform build/check report for BioC 3.19, > the MSA2dist package has the following problem(s): > > o ERROR for 'R CMD INSTALL' on nebbiolo1. See the details here: > > https://bioconductor.org/checkResults/3.19/bioc-LATEST/MSA2dist/nebbiolo1-install.html > > <https://bioconductor.org/checkResults/3.19/bioc-LATEST/MSA2dist/nebbiolo1-install.html> > > o ERROR for 'R CMD build' on nebbiolo1. See the details here: > > https://bioconductor.org/checkResults/3.19/bioc-LATEST/MSA2dist/nebbiolo1-buildsrc.html > > <https://bioconductor.org/checkResults/3.19/bioc-LATEST/MSA2dist/nebbiolo1-buildsrc.html> > > However, if I check the the page, there are no ERROR listed: > > Report page was generated: > > This page was generated on 2024-04-23 11:37:19 -0400 (Tue, 23 Apr 2024). > > Should I just wait or where I can find the mentioned ERROR? > > Best regards > > Kristian > -- 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
Re: [Bioc-devel] R version dependency
If you're submitting a new package, you might be asked to set this to R (>= 4.4). At least it used to be that way but I'm not sure this is still enforced. Otherwise you don't need to do anything. Best, H. On 4/22/24 10:56, Richard Heery wrote: > Hi all, > > I'm wondering what we should now list as the R version in the Depends > section of the description file: the current version 4.3.3 or the > development version 4.4? > > Cheers, > > Richard > > [[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
Re: [Bioc-devel] unix package in suggest leads to check error
Hi Alex, On 4/19/24 09:53, Alexey Sergushichev wrote: > Hi, > > Our package "phantasus" requires the "unix" package to properly work on > *nix systems, I just tried to run 'R CMD check' on phantasus on my Linux laptop where I don't have the unix package installed, and everything went fine. In particular all the examples and unit tests passed with no problem. So I'm not sure what you mean when you say that the unix package is required for phantasus "to properly work". So unless I'm missing something, I see no reason to list unix in the Suggests field of your package. Best, H. > but works well without it on Windows and Mac OS (actually we > depend on the opencpu package, which requires it). I've tried to put this > package into suggest field, but now the package failed Bioc checks on > Windows and Mac ( > https://bioconductor.org/checkResults/devel/bioc-LATEST/phantasus/palomino3-checksrc.html) > with the following message: > > ``` > * checking package dependencies ... ERROR > Package suggested but not available: 'unix' > > The suggested packages are required for a complete check. > Checking can be attempted without them by setting the environment > variable _R_CHECK_FORCE_SUGGESTS_ to a false value. > ``` > > Is there any way to keep this package in suggestions and not to fail the > checks? Or are there any other recommendations for this case? > > Best, > Alexey > > [[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
Re: [Bioc-devel] Is package name "ADAPT" available?
Also BiocManager::available() will show you all the packages in the
CRAN/Bioconductor ecosystem that contain the specified string:
> library(BiocManager)
> available("ADAPT")
[1] "adapt4pv" "adaptalint" "adaptDiag"
[4] "AdaptGauss" "adaptiveGPCA" "AdaptiveSparsity"
[7] "adaptivetau" "adaptIVPT" "adaptMCMC"
[10] "adaptMT" "adaptr" "ADAPTS"
[13] "adaptsmoFMRI" "adaptTest" "BrokenAdaptiveRidge"
[16] "eufmdis.adapt" "fairadapt" "fruclimadapt"
[19] "GLMMadaptive" "iAdapt" "kernstadapt"
[22] "pcadapt" "survRM2adapt"
Best,
H.
On 4/9/24 07:38, Mukai Wang wrote:
> Thank you Olly!
>
> -Mukai
>
> On Tue, Apr 9, 2024 at 10:31 AM Oliver Crook
> wrote:
>
>> Hi Mukai,
>>
>> If you run biocCheck on your package it will tell you if the name is
>> already taken.
>>
>> Best wishes,
>> Olly
>>
>> ---
>> Dr. Oliver Crook (he/him)
>> Florence Nightingale Bicentennial Fellow, Department of Statistics
>> Todd-Bird Junior Research Fellow, New College
>> University of Oxford
>> --
>> *From:* Bioc-devel on behalf of Mukai
>> Wang
>> *Sent:* Tuesday, April 9, 2024 3:12 PM
>> *To:*bioc-devel@r-project.org
>> *Subject:* [Bioc-devel] Is package name "ADAPT" available?
>>
>> Dear bioconductor community,
>>
>> I am writing to ask if the package name ADAPT is available for use. I don't
>> see any package with this name on bioconductor but there is a package
>> called "adapt" archived many years ago on CRAN, so I am not sure. Any
>> suggestion is appreciated!
>>
>> Best,
>> Mukai
>>
>> --
>> Mukai Wang
>> Biostatistics Department, School of Public Health, University of Michigan
>>
>> [[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
Re: [Bioc-devel] Fw: MungeSumstats Bioconductor
The longtests builds only run the tests in the longtests/ folder. Best, H. On 2/21/24 09:56, alan murphy wrote: > Hey Herve, > > Thanks for this, I'm going to implement that now. One thing I > wondered, is it only the tests in the longtest/ folder that run on > these weekly builds or both those and the tests in test/? I'm > wondering should I duplicate the tests in both folders that I want to > run in both? > > Cheers, > Alan. > -------- > *From:* Hervé Pagès > *Sent:* Tuesday 6 February 2024 18:58 > *To:* alan murphy ; Bioc-devel@r-project.org > > *Subject:* Re: [Bioc-devel] Fw: MungeSumstats Bioconductor > > Hi Alan, > > The specs of the Linux servers have not changed. > > However we've recently observed some of these random kills by the > Linux kernel for a couple of other packages, and we started an > application to get funding to increase the amount of RAM on these > machines. > > These random kills are a desperate attempt by the Linux kernel to keep > the machine alive when it's under extremely high load and running out > of resources. Unfortunately this is not something that anybody will be > able to easily reproduce as it only happens under special > circumstances e.g. during the daily builds when dozens of packages are > being checked simultaneously. > > Regardless of whether we'll manage to increase the memory on the Linux > servers, it seems to me that the most memory-hungry unit tests in > MungeSumstats would be a better fit for the long tests. These tests > are run once a week instead of daily, and use less workers (4 instead > of 28). This means that each package has access to more resources. > > See https://contributions.bioconductor.org/long-tests.html > <https://contributions.bioconductor.org/long-tests.html> for how to > set up the long tests in your package. > > Let me know if you have questions or need help with this. > > Best, > > H. > > On 2/2/24 09:14, alan murphy wrote: >> Hi, >> >> I'm the maintainer of the MungeSumstats package which is currently failing >> on the devel nebbiolo1 Linux platform because of RAM requirements of the >> unit tests. These tests use large reference datasets (like >> BSgenome.Hsapiens.1000genomes.hs37d5::BSgenome.Hsapiens.1000genomes.hs37d5) >> which cause the issue, e.g. from the output of the devel linux >> test<https://bioconductor.org/checkResults/3.19/bioc-LATEST/MungeSumstats/nebbiolo1-checksrc.html> >> >> <https://bioconductor.org/checkResults/3.19/bioc-LATEST/MungeSumstats/nebbiolo1-checksrc.html>: >> >> ``` >> >> Validating RSIDs of 92 SNPs using BSgenome::snpsById... >> Killed >> >> ``` >> which is from this >> function:https://github.com/neurogenomics/MungeSumstats/blob/cccf77b2249f52be59fe1749f13a386ffaaae528/R/load_ref_genome_data.R#L49 >> >> <https://github.com/neurogenomics/MungeSumstats/blob/cccf77b2249f52be59fe1749f13a386ffaaae528/R/load_ref_genome_data.R#L49> >> >> I would like to keep these units tests as they are very important for me to >> know if things have gone wrong. I can't scale down the RAM usage, it is only >> using a few rows of data as it, the issue is that the reference sets are >> massive rather than the actual set being tested. I currently don't have a >> lot of these tests set to run on windows/mac platforms so I rely on the >> Linux machines to run this. I am not sure what has changed but a few >> releases back, the same tested were not causing this issue and would >> complete on linux - has the machine spec changed? Is there any chance RAM >> could be increased for these tests or is there a way to specify not to run >> the specific unit tests on the Bioconductor server so I can at least keep >> these for my github actions workflows? See below for the automated message I >> got about these errors. >> >> Any other suggestions on ways around this would be greatly appreciated! >> >> Thanks, >> Alan. >> >> From: CoreTeam Bioconductor >> <mailto:bioconductorcoret...@gmail.com> >> Sent: Friday 2 February 2024 16:43 >> To:alanmurp...@hotmail.com <mailto:alanmurp...@hotmail.com> >> <mailto:alanmurp...@hotmail.com> >> Subject: MungeSumstats Bioconductor >> >> Hello Package Maintainer, >> >> We would like to bring to your attention that your package is failing in >> devel on the linux platform. This is very problematic. Please investigate >> the issues and fix the package
Re: [Bioc-devel] Fw: MungeSumstats Bioconductor
Hi Alan, The specs of the Linux servers have not changed. However we've recently observed some of these random kills by the Linux kernel for a couple of other packages, and we started an application to get funding to increase the amount of RAM on these machines. These random kills are a desperate attempt by the Linux kernel to keep the machine alive when it's under extremely high load and running out of resources. Unfortunately this is not something that anybody will be able to easily reproduce as it only happens under special circumstances e.g. during the daily builds when dozens of packages are being checked simultaneously. Regardless of whether we'll manage to increase the memory on the Linux servers, it seems to me that the most memory-hungry unit tests in MungeSumstats would be a better fit for the long tests. These tests are run once a week instead of daily, and use less workers (4 instead of 28). This means that each package has access to more resources. See https://contributions.bioconductor.org/long-tests.html for how to set up the long tests in your package. Let me know if you have questions or need help with this. Best, H. On 2/2/24 09:14, alan murphy wrote: > Hi, > > I'm the maintainer of the MungeSumstats package which is currently failing on > the devel nebbiolo1 Linux platform because of RAM requirements of the unit > tests. These tests use large reference datasets (like > BSgenome.Hsapiens.1000genomes.hs37d5::BSgenome.Hsapiens.1000genomes.hs37d5) > which cause the issue, e.g. from the output of the devel linux > test<https://bioconductor.org/checkResults/3.19/bioc-LATEST/MungeSumstats/nebbiolo1-checksrc.html>: > > ``` > > Validating RSIDs of 92 SNPs using BSgenome::snpsById... > Killed > > ``` > which is from this > function:https://github.com/neurogenomics/MungeSumstats/blob/cccf77b2249f52be59fe1749f13a386ffaaae528/R/load_ref_genome_data.R#L49 > > I would like to keep these units tests as they are very important for me to > know if things have gone wrong. I can't scale down the RAM usage, it is only > using a few rows of data as it, the issue is that the reference sets are > massive rather than the actual set being tested. I currently don't have a lot > of these tests set to run on windows/mac platforms so I rely on the Linux > machines to run this. I am not sure what has changed but a few releases back, > the same tested were not causing this issue and would complete on linux - has > the machine spec changed? Is there any chance RAM could be increased for > these tests or is there a way to specify not to run the specific unit tests > on the Bioconductor server so I can at least keep these for my github actions > workflows? See below for the automated message I got about these errors. > > Any other suggestions on ways around this would be greatly appreciated! > > Thanks, > Alan. > > From: CoreTeam Bioconductor > Sent: Friday 2 February 2024 16:43 > To:alanmurp...@hotmail.com > Subject: MungeSumstats Bioconductor > > Hello Package Maintainer, > > We would like to bring to your attention that your package is failing in > devel on the linux platform. This is very problematic. Please investigate the > issues and fix the package to avoid deprecation. > > https://bioconductor.org/checkResults/devel/bioc-LATEST/ > <https://bioconductor.org/checkResults/3.17/workflows-LATEST/TCGAWorkflow> > > If you have further questions or concerns please reach out on > thebioc-de...@r-project.org<mailto:bioc-devel@r-project.org> > > We appreciate your quick attention to this matter > > Cheers, > On behalf of the Bioconductor Core Team > > [[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
Re: [Bioc-devel] Incorrect warning about failing package built
;> >> >> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fbioconductor.org%2FcheckResults%2Fdevel%2Fbioc-LATEST%2FReactomeGSA%2F__%3B!!PxiZbSOawA!M-1zUaRSf4H_CKYUyhpGNOS9X3o9oI8ig_h2rck5yvFPc1mC4nbUNsLfyxRJNMbhmsAGjnS4E9GoK_LE2uqmKM0fkPMpu89nUSA0rnxJ23U%24=05%7C02%7Cjennifer.wokaty%40sph.cuny.edu%7C0e7c021440214cf1ba5708dc2362f85a%7C6f60f0b35f064e099715989dba8cc7d8%7C0%7C0%7C638424155200973059%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=EZnvSQ0zSzlNuW5DocjOsROuDVk6e7GH0Hg%2ByRnhdwQ%3D=0 >> >> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fbioconductor.org%2FcheckResults%2Fdevel%2Fbioc-LATEST%2FReactomeGSA%2F__%3B!!PxiZbSOawA!M-1zUaRSf4H_CKYUyhpGNOS9X3o9oI8ig_h2rck5yvFPc1mC4nbUNsLfyxRJNMbhmsAGjnS4E9GoK_LE2uqmKM0fkPMpu89nUSA0rnxJ23U%24=05%7C02%7Cjennifer.wokaty%40sph.cuny.edu%7C0e7c021440214cf1ba5708dc2362f85a%7C6f60f0b35f064e099715989dba8cc7d8%7C0%7C0%7C638424155200973059%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=EZnvSQ0zSzlNuW5DocjOsROuDVk6e7GH0Hg%2ByRnhdwQ%3D=0><https://urldefense.com/v3/__https://bioconductor.org/checkResults/devel/bioc-LATEST/ReactomeGSA/__;!!PxiZbSOawA!M-1zUaRSf4H_CKYUyhpGNOS9X3o9oI8ig_h2rck5yvFPc1mC4nbUNsLfyxRJNMbhmsAGjnS4E9GoK_LE2uqmKM0fkPMpu89nUSA0rnxJ23U$ >> >> <https://urldefense.com/v3/__https://bioconductor.org/checkResults/devel/bioc-LATEST/ReactomeGSA/__;!!PxiZbSOawA!M-1zUaRSf4H_CKYUyhpGNOS9X3o9oI8ig_h2rck5yvFPc1mC4nbUNsLfyxRJNMbhmsAGjnS4E9GoK_LE2uqmKM0fkPMpu89nUSA0rnxJ23U$>> >> >> >> >> On release we have no errors or warnings at all, on devel, >> everything is >> fine in two instances while the others seem to have issues that >> we will >> look into. >> >> Is there anything I can do to fix that? >> >> Kind regards, >> Johannes >> >> ___ >> Bioc-devel@r-project.org <mailto:Bioc-devel@r-project.org> mailing list >> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel__%3B!!PxiZbSOawA!M-1zUaRSf4H_CKYUyhpGNOS9X3o9oI8ig_h2rck5yvFPc1mC4nbUNsLfyxRJNMbhmsAGjnS4E9GoK_LE2uqmKM0fkPMpu89nUSA0ArxoE98%24=05%7C02%7Cjennifer.wokaty%40sph.cuny.edu%7C0e7c021440214cf1ba5708dc2362f85a%7C6f60f0b35f064e099715989dba8cc7d8%7C0%7C0%7C638424155200977608%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=0x4xNPvAHnkGyUcEz4PVIOM8eCVTEWNpNUOkskspUEQ%3D=0 >> >> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel__%3B!!PxiZbSOawA!M-1zUaRSf4H_CKYUyhpGNOS9X3o9oI8ig_h2rck5yvFPc1mC4nbUNsLfyxRJNMbhmsAGjnS4E9GoK_LE2uqmKM0fkPMpu89nUSA0ArxoE98%24=05%7C02%7Cjennifer.wokaty%40sph.cuny.edu%7C0e7c021440214cf1ba5708dc2362f85a%7C6f60f0b35f064e099715989dba8cc7d8%7C0%7C0%7C638424155200977608%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=0x4xNPvAHnkGyUcEz4PVIOM8eCVTEWNpNUOkskspUEQ%3D=0><https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/bioc-devel__;!!PxiZbSOawA!M-1zUaRSf4H_CKYUyhpGNOS9X3o9oI8ig_h2rck5yvFPc1mC4nbUNsLfyxRJNMbhmsAGjnS4E9GoK_LE2uqmKM0fkPMpu89nUSA0ArxoE98$ >> >> <https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/bioc-devel__;!!PxiZbSOawA!M-1zUaRSf4H_CKYUyhpGNOS9X3o9oI8ig_h2rck5yvFPc1mC4nbUNsLfyxRJNMbhmsAGjnS4E9GoK_LE2uqmKM0fkPMpu89nUSA0ArxoE98$>> >> >> >> >> [[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 >> <https://stat.ethz.ch/mailman/listinfo/bioc-devel> >> > ___ > 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
Re: [Bioc-devel] Error in Nebbiolo1
nebbiolo1 uses a special setup to detect undeclared deps i.e. it will fail to find a package if you didn't list it in the Suggests field of your package. In this case you seem to be using BiocStyle for your vignette so you need to add it to your Suggests field. Best, H. On 1/5/24 11:49, erhanozer19 via Bioc-devel wrote: > I apologize for the typo in the mail > > 2024-01-05 22:43, erhanozer19 via Bioc-devel yazmış: >> Dead Biconductor Community, >> >> According to the new build report, check process in Nebbiolo1 of my >> package SVMDO resulted in error: there is no package called BiocStyle. >> Yet, in other systems the check process was successful. >> >> Is this related with Nebbiolo1? >> >> ___ >> Bioc-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel > > > -- > Bu e-posta mesajı ve içeriği gizli veya özel bilgiler içerebilir. > Mesajın içeriğinde bulunan tüm fikir ve görüşler sadece göndericiye > ait olup, Marmara Üniversitesi’nin resmi görüşünü yansıtmaz. Kurumumuz > bu e-posta içeriğindeki bilgilerin kullanılması nedeniyle hiç kimseye > karşı sorumlu tutulamaz. Mesajın belirlenen alıcılardan biri > değilseniz, mesaj içeriğini ya da eklerini kullanmayınız, > kopyalamayınız, yaymayınız, başka kişilere yönlendirmeyiniz ve mesajı > gönderen kişiyi derhal e-posta yoluyla haberdar ederek bu mesajı ve > eklerini herhangi bir kopyasını muhafaza etmeksizin siliniz. Kurumumuz > size, mesajın ve bilgilerinin değişikliğe uğramaması, bütünlüğünün ve > gizliliğin korunması konusunda garanti vermemekte olup, e-posta > içeriğine yetkisiz olarak yapılan müdahale, virüs içermesi ve/veya > bilgisayar sisteminize verebileceği herhangi bir zarardan da sorumlu > değildir.This e-mail message and its content may cont > ain confidential or proprietary information. All ideas and opinions > contained in the message are solely those of the sender and do not > reflect the official opinion of Marmara University. Our institution > cannot be held responsible to anyone for the use of the information > contained in this e-mail. If you are not one of the designated > recipients of the message, do not use, copy, disseminate, forward the > message content or attachments, and immediately notify the sender of > the message via e-mail and delete this message and its attachments > without retaining any copies. Our institution does not guarantee you > that the message and its information will not be changed, its > integrity and confidentiality will be protected, and is not > responsible for any unauthorized intervention to the e-mail content, > viruses and/or any damage it may cause to your computer system. > > ___ > 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
Re: [Bioc-devel] Wrong skipping of tests when builidng on Bioconductor and R CMD check timeout
Hi Jacopo,
testthat::skip_on_bioc() relies on the IS_BIOC_BUILD_MACHINE environment
variable to know whether it's on a BioC build machine or not.
This environment variable is defined during the daily build via the
Renviron.bioc file. Note that a link to this file is provided on the
individual build reports e.g. here
https://bioconductor.org/checkResults/3.19/bioc-LATEST/Biobase/
("Renviron settings" link).
Maybe this environment variable is not defined on the Single Package
Builder (SPB)? The SPB is the build system used during the package
submission process. It runs on the same machines as the daily builds but
my understanding is that it uses a slightly different set of variables.
Maybe Lori can shed some light?
As for the timeout on merida1 (Intel Mac), have you considered using
BiocFileCache to cache the data that you download in your examples? You
might still get a timeout the next time 'R CMD check' will run on our
build machines, but it should go significantly faster after that.
Best,
H.
On 12/12/23 07:22, Jacopo Ronchi wrote:
> Dear Developers,
>
> I am currently in the process of submitting my package on Bioconductor and
> I am facing some issues during the R CMD check on the Bioconductor Build
> System. Since I was not able to find any answers to my doubts, I decided to
> ask for your help before doing anything wrong.
>
> The build report for my package is available here:
> http://bioconductor.org/spb_reports/MIRit_buildreport_20231211095232.html
>
> In particular, my package includes some functions where it accesses remote
> resources. Therefore, I included some "skip_on_bioc()" chunks at the
> beginning of these tests since I don't want my package to fail during the
> build process because of occasional down times. However, when I look at the
> build report, I notice that the relevant tests are not skipped.
> Furthermore, other tests that should be run are instead skipped on CRAN. I
> am referring to these lines:
>
> Skipped tests (2)
> On CRAN (2): 'test-topological-integration.R:23:5', 'test-utils.R:20:5'
>
> Lastly, I have an error during R CMD check on macOS, and I really don't
> know how to reduce the running time on this operating system. Currently, I
> have reshaped the testing suite to reduce the time spent on unit tests.
> However, on macOS, i guess that most of the time consumed is due to
> examples. Nevertheless, the most time consuming functions retrieve
> gene-sets from external resources and I can't reduce the download size of
> KEGG pathways, for example. What should I do?
>
> Sorry again for bothering you,
> Best regards,
> Jacopo
>
> [[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
Re: [Bioc-devel] Missing CHM13v2.0 TxDB and OrgDb objects
FWIW I've documented the process of making a TxDb object for
T2T-CHM13v2.0 there:
https://github.com/Bioconductor/GenomicFeatures/issues/65
Please comment there for any follow-up.
Note that we're considering wrapping this is an TxDb package that we'll
make available to the community. It's a work-in-progress.
Thanks!
H.
On 12/12/23 07:29, James W. MacDonald wrote:
> Hi Christian,
>
> This conversation is off-topic, both for this listserv (it’s meant to help
> people developing Bioconductor packages) and for the support site (which is
> meant to help people with (again), Bioconductor packages. I’ll answer your
> questions one more time, but if you have other questions, please move to
> biostars.org, or just ask the ArchR people directly, since it’s their package.
>
> I believe you are misinterpreting what an OrgDb is intended to provide. There
> is no positional data in an OrgDb, and what the CHM13 project has done is
> completely positional (what data are provided in the ‘Gene Annotation’
> section of the CHM13 Github are all GFF files, which are meant to provide
> positional information of genes on a genome).
>
> The OrgDb package provides functional and within-annotation mappings. You can
> map an NCBI Gene ID to Ensembl, or to the HGNC gene symbol, or a GO term,
> etc. For example, I can map Gene symbol P53 to NCBI Gene ID 7157, or its
> UniProt symbol K7PPA8. If the new genome build says P53 has moved to a new
> genomic position, that has no affect on what UniProt thinks the ID for that
> gene’s protein should be, or what ID NCBI uses, or what GO terms are appended
> to that gene. Functionally it’s the same gene. We just might think it is
> located in a different place in the genome.
>
> The difference between CHM13 and GRCh38 is not materially different from the
> difference between GRCh37 and GRCh38 (they represent the current knowledge of
> the genome at a point in time), and while we supply TxDb packages for GRCh38
> and GRCh37 (and variants based on NCBI’s mappings as well as Ensembl’s
> mappings), we have never supplied more than one human OrgDb package, because
> the positional and functional information are orthogonal.
>
> It seems pretty simple to make what you need though.
>
>> library(GenomicAlignments)
>> tx <-
>> makeTxDbFromGFF(https://ftp.ncbi.nlm.nih.gov/genomes/all/GCF/009/914/755/GCF_009914755.1_T2T-CHM13v2.0/GCF_009914755.1_T2T-CHM13v2.0_genomic.gff.gz)
> Import genomic features from the file as a GRanges object ... trying URL
> 'https://ftp.ncbi.nlm.nih.gov/genomes/all/GCF/009/914/755/GCF_009914755.1_T2T-CHM13v2.0/GCF_009914755.1_T2T-CHM13v2.0_genomic.gff.gz'
> Content type 'application/x-gzip' length 79009538 bytes (75.3 MB)
> downloaded 75.3 MB
>
> OK
> Prepare the 'metadata' data frame ... OK
> Make the TxDb object ... OK
> Warning messages:
> 1: In .extract_transcripts_from_GRanges(tx_IDX, gr, mcols0$type, mcols0$ID, :
>some transcripts have no
>"transcript_id" attribute ==>
>their name ("tx_name" column in
>the TxDb object) was set to NA
> 2: In .extract_transcripts_from_GRanges(tx_IDX, gr, mcols0$type, mcols0$ID, :
>the transcript names ("tx_name"
>column in the TxDb object)
>imported from the
>"transcript_id" attribute are
>not unique
> 3: In .find_exon_cds(exons, cds) : The following transcripts have
>exons that contain more than one
>CDS (only the first CDS was kept
>for each exon):
>rna-NM_001134939.1,
>rna-NM_001172437.2,
>rna-NM_001184961.1,
>rna-NM_001301020.1,
>rna-NM_001301302.1,
>rna-NM_001301371.1,
>rna-NM_002537.3,
>rna-NM_004152.3,
>rna-NM_015068.3, rna-NM_016178.2
>> tx
> TxDb object:
> # Db type: TxDb
> # Supporting package: GenomicFeatures
> # Data
> source:https://ftp.ncbi.nlm.nih.gov/genomes/all/GCF/009/914/755/GCF_009914755.1_T2T-CHM13v2.0/GCF_009914755.1_T2T-CHM13v2.0_genomic.gff.gz
> # Organism: NA
> # Taxonomy ID: NA
> # miRBase build ID: NA
> # Genome: NA
> # Nb of transcripts: 188205
> # Db created by: GenomicFeatures package from Bioconductor
> # Creation time: 2023-12-12 10:17:34 -0500 (Tue, 12 Dec 2023)
> # GenomicFeatures version at creation time: 1.54.1
> # RSQLite version at creation time: 2.3.1
> # DBSCHEMAVERSION: 1.2
>
> genomeAnnotation <-
> createGenomeAnnotation(BSgenome.Hsapiens.NCBI.T2T.CHM13v2.0)
> geneAnnotation <- createGeneAnnotation(TxDb = tx, OrgDb = org.Hs.eg.db)
>
>
> Best,
>
> Jim
>
> From: Christian Arnold
> Sent: Tuesday, December 12, 2023 9:35 AM
> To: Vincent Carey; James W.
> MacDonald
> Cc:bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Missing CHM13v2.0 TxDB and OrgDb objects
>
> Dear Vincent and others, thanks for the reply! Irrespective of whether a
> different OrgDb is required, the name itself suggested that there "should be"
> also corresponding OrgDb and TxDb packages. I can build one on my own, I see,
> is there anyone
> ZjQcmQRYFpfptBannerStart
> This Message Is From an Untrusted Sender
>
Re: [Bioc-devel] How to declare optional system requirement for package
Hi Alex, On 11/28/23 22:47, Alex Wong via Bioc-devel wrote: > Hi there, > > I am the author of SpliceWiz. My package contains several wrapper functions > that run the STAR aligner on systems where it is installed. If STAR is not > found, these functions do nothing other than return a helpful message that > says STAR is not available. The vast majority of the functions in the > package does not depend on STAR, thus STAR is a highly optional requirement > for my package. > > What is the best way to convey this in the DESCRIPTION file? Is it > acceptable to add the following line? > >> SystemRequirements: STAR (optional) That works but it's hard to know what functionality is lost by not having STAR on the machine. Would it make sense to put all the STAR-related stuff in their own package and have SpliceWiz suggest that package? STAR would now be a hard requirement for the package that contains the STAR-related stuff. This kind of separation might help with maintenance and quality control. It might also help making things less confusing for the end user. Best, H. > Kind Regards, > > Alex > -- 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
Re: [Bioc-devel] package name
Yes, deprecating the current package and submitting a revised proposal with a new name is the way to go. Thanks, H. On 11/24/23 14:17, mauro castro wrote: > Hello Bioconductor Team, > > We have a package that has been part of Bioconductor for a while, and we > are considering the possibility of renaming it. > > We understand that this is not a straightforward process, and we are aware > of Bioconductor's encouragement not to rename packages. > > However, we are currently working on publishing a paper about this package. > Following editorial recommendations, we have been asked to address several > reviewer demands, one of which involves renaming the package to better > align its primary objectives with the paper's narrative, title, and > abstract. > > If necessary, we are open to deprecating the current package and submitting > a revised proposal with a new name. > > I would greatly appreciate your assistance in navigating this process. > > Best, > > Mauro > > --- > > Prof. Mauro Castro, MD, PhD > Bioinformatics & Systems Biology Lab > Polytechnic Center > Federal University of Paraná - UFPR > Rua Alcides Vieira Arcoverde, 1225 > Curitiba - PR 81520-260 - Brazil > > E-mail:mauro.cas...@ufpr.br > Phone: +55-41-33614906 > https://orcid.org/-0003-4942-8131 > > [[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
Re: [Bioc-devel] Workflow package build all OK but no vignette and red Package propagation status LED
Hi Jim, On 11/17/23 06:22, James Perkins wrote: > Thanks I didn't know about the mouseover hint! It appears that this > package (miRBaseConverter) is failing the check on linux: > > https://bioconductor.org/checkResults/3.18/bioc-LATEST/miRBaseConverter/ > > Leading to the red light ExpHunterSuite on the linux build only: > > https://bioconductor.org/checkResults/3.18/workflows-LATEST/ExpHunterSuite/ > > > However, what I'm not sure about - is this unavailable dependency the > reason why the landing page for ExpHunterSuite does not show the > vignette or source code? > > https://bioconductor.org/packages/3.18/workflows/html/ExpHunterSuite.html > Yes. The vignettes displayed on the package landing pages are generated from what's found in the _published_ source tarball. Since no source tarball for ExpHunterSuite ever made it to the BioC 3.18 repositories, the landing page that we produce is missing a few things (it's a degraded version of the standard landing page). Note that miRBaseConverter has been failing on Linux for more than 6 months, for not declaring BiocStyle in its Suggests field, and despite numerous reminders (emails sent by core team members in addition to the weekly automatic BBS notifications). Maybe you want to try and ping the miRBaseConverter maintainer by opening an issue at https://github.com/taoshengxu/miRBaseConverter ? Maybe you'll have more luck. Otherwise, we will soon deprecate miRBaseConverter in BioC 3.19. Unfortunately this means that you'll need to modify the ExpHunterSuite workflow to no longer rely on it. Best, H. > Or could it be another factor? > > Jim > > On 2023-11-13 12:08, Martin Grigorov wrote: >> Hi, >> >> If you hover over the red LED you will see the following hint: NO, >> package depends on 'miRBaseConverter' which is not available" >> >> Regards, >> Martin >> >> On Mon, Nov 13, 2023 at 11:31 AM James Perkins >> wrote: >> >>> Hi, >>> >>> I am the maintainer of the Workflow package ExpHunterSuite. >>> >>> In the build report for the release branch, 3.18, my build and >>> install >>> status are green-OK. >>> >>> However, I have a red LED for Package Propagation. How can I tell >>> what's >>> gone wrong, and how could I fix it? >>> >>> >> https://bioconductor.org/checkResults/3.18/workflows-LATEST/ExpHunterSuite/ >> >>> >>> I've had a look through the documentation and the nearest I've found >>> >>> was: "propagation is still determined by the results of the nightly >>> builds." - but I cannot find/workout the relevant section in the >>> output >>> of the nightly build report that is related to propagation status. >>> >>> The landing page of the package is not showing the documentation >>> (vignette etc.), or letting me download the package source. >>> >>> >> https://bioconductor.org/packages/3.18/workflows/html/ExpHunterSuite.html >> >>> >>> I suspect this is related, because the devel version of the package >>> IS >>> showing blue propagation status, and IS showing the >>> documentation/package source etc. >>> >>> >> https://bioconductor.org/packages/3.19/workflows/html/ExpHunterSuite.html >> >>> >>> Cheers! >>> >>> Jim >>> >>> ___ >>> 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 -- 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
Re: [Bioc-devel] Build issue on nebbiolo2 for DEWSeq
Hi Sudeep, I don't see magrittr in any of the Depends, Imports, or Suggests field of DEWSeq. Remember that any function or symbol you use from another package requires that you declare that package in one of these fields. In this case, since you only use %>% in the vignette, then you only need to put magrittr in the Suggests field. You don't need to import it. However, as suggested by Kristian, why not just use R basic pipe "|>" instead? Best, H. On 11/14/23 23:23, Biohentze wrote: > Dear all, > > We are facing build issue on nebbiolo2 on our vignette for the package > DEWSeq. The issue is that we use magittr pipe (%>%) in the vignette and the > issue occurs only on the linux machine. > Checks, builds and installation completes successfully on windows and mac. > Here is the complete build > report:https://master.bioconductor.org/checkResults/3.18/bioc-LATEST/DEWSeq/nebbiolo2-checksrc.html > > Could you please look into it ? > > Thank you in advance, > Sudeep. > > [[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
Re: [Bioc-devel] Package problems due to results() function from other package?
Fixed in BiocGenerics 0.48.1: https://github.com/Bioconductor/BiocGenerics/commit/5fd6dfe93786292484dc53023ec681391f4559e0 With this version of BiocGenerics, SNPhood passes CHECK on my laptop (Ubuntu Linux). We'll see how it goes on Thursday's report. (The fix was too late for today's builds -- they already started -- so it won't reflect on tomorrow's report.) Sorry again for the trouble. Cheers, H. PS: Making results() an S4 generic defined in BiocGenerics would still be a good idea though, because a SNPhood user could still decide to _explicitly_ load DESeq2 with library(DESeq2) after they've loaded SNPhood, which would also break results(). I'll leave this to the authors/maintainers of SNPhood and/or DESeq2 to open an issue on the BiocGenerics repo to request this if they are interested. On 10/31/23 13:49, Hervé Pagès wrote: > > Hmm.. so I was curious and did a little bit more investigation about this. > > The other package that also defines a results() function is DESeq2, > and it gets attached to the search path after calling > analyzeSNPhood(). You can actually observe this phenomena with the > following code: > > library(SNPhood) > library(SNPhoodData) > search() # DESeq2 is NOT attached > example(analyzeSNPhood) > search() # DESeq2 is attached > > What's intriguing is that this only happens in BioC 3.18. In BioC > 3.17, running the analyzeSNPhood example does NOT alter the search > path. After spending some time tracking this down, it turns out that > the reason for this change of behaviour is a small tweak I made > recently to the updateObject() generic in BiocGenerics. An unfortunate > one that I will correct now. > > @Christian: A fix is on its way so you have nothing to do. > > Sorry for the trouble. > > H. > > On 10/31/23 09:44, Hervé Pagès wrote: >> >> On 10/31/23 07:22, Wolfgang Huber wrote: >> >>> Dear Christian >>> >>> If your vignette attaches another package that exports a “results” >>> function, after it attached SNPhood which defines its own results function, >>> then the R interpreter has no other choice than doing what it does. >>> >>> Other people adding additional functionality to their packages is probably >>> not something one can really complain about, so I see three options >>> - you use SNPhood::results in your vignette >>> - you don’t attach the other package, and rather just use what you need >>> from it using “::” >>> - you convince Hervé to add ‘results' to BiocGenerics and everyone who >>> exports such a function converts it to a method for that generic. >> >> My pleasure, and that's the cleanest solution. But it will only help >> if the package that defines the "other" results() function is a >> Bioconductor package and not a CRAN package. Has this package been >> identified? >> >> A 4th option is to make sure that the other package gets loaded >> _before_ SNPhood e.g. by putting an explicit library(> package>) before library(SNPhood) in your vignette, even though >> that's kind of hacky. >> >> Best, >> >> H. >> >>> Thank you and kind regards >>> Wolfgang >>> >>> -- >>> Wolfgang Huber >>> EMBL >>> https://www.huber.embl.de/ >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>> Il giorno 2023-10-28, alle ore 16:15, Christian Arnold >>>> ha scritto: >>>> >>>> For my package SNPhood that did not receive any code changes or updates >>>> in quite a while, I suddenly see errors with Bioc 3.18: >>>> https://master.bioconductor.org/checkResults/3.18/bioc-LATEST/SNPhood/nebbiolo2-buildsrc.html >>>> >>>> Error: processing vignette 'workflow.Rmd' failed with diagnostics: >>>> unused argument (type = "allelicBias") >>>> >>>> This comes from this line I think: >>>> >>>> names(results(SNPhood.o, type = "allelicBias")) >>>> >>>> For literally years, this didnt cause any problems, and the results >>>> function is actually (re)defined in the SNPhood package: >>>> >>>> results <- function(SNPhood.o, type, elements = NULL) >>>> >>>> I am not sure now what causes this. Should I use the syntax >>>> SNPhood::results to make it clear, or I am wrongly assuming that the >>>> wrong result function is taken that causes the error? >>>> >>>> Any pointers? >>>> >>>> >>>> Best >>>> >>>> Christian >>>> >>>> >>>> [[alternative HTML version deleted]] >>>> >>>> ___ >>>> Bioc-devel@r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >>> ___ >>> Bioc-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> -- >> Hervé Pagès >> >> Bioconductor Core Team >> hpages.on.git...@gmail.com > -- > Hervé Pagès > > Bioconductor Core Team > hpages.on.git...@gmail.com -- 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
Re: [Bioc-devel] Package problems due to results() function from other package?
Thanks Ali! Only problem is that I have too much control on too many infrastructure components so it's too easy for me to mess up other people's stuff :-( On 10/31/23 14:00, Ali Sajid Imami wrote: > Herve, I see the work you do and stand in awe. I can only wish I could > some day be in a similar place. For now, I am content with submitting > packages for 3.19. :) > >> On Oct 31, 2023, at 4:49 PM, Hervé Pagès >> wrote: >> >> Hmm.. so I was curious and did a little bit more investigation about >> this. >> >> The other package that also defines a results() function is DESeq2, and >> it gets attached to the search path after calling analyzeSNPhood(). You >> can actually observe this phenomena with the following code: >> >> library(SNPhood) >> library(SNPhoodData) >> search() # DESeq2 is NOT attached >> example(analyzeSNPhood) >> search() # DESeq2 is attached >> >> What's intriguing is that this only happens in BioC 3.18. In BioC 3.17, >> running the analyzeSNPhood example does NOT alter the search path. After >> spending some time tracking this down, it turns out that the reason for >> this change of behaviour is a small tweak I made recently to the >> updateObject() generic in BiocGenerics. An unfortunate one that I will >> correct now. >> >> @Christian: A fix is on its way so you have nothing to do. >> >> Sorry for the trouble. >> >> H. >> >> On 10/31/23 09:44, Hervé Pagès wrote: >>> >>> On 10/31/23 07:22, Wolfgang Huber wrote: >>> >>>> Dear Christian >>>> >>>> If your vignette attaches another package that exports a “results” >>>> function, after it attached SNPhood which defines its own results >>>> function, then the R interpreter has no other choice than doing >>>> what it does. >>>> >>>> Other people adding additional functionality to their packages is >>>> probably not something one can really complain about, so I see >>>> three options >>>> - you use SNPhood::results in your vignette >>>> - you don’t attach the other package, and rather just use what you >>>> need from it using “::” >>>> - you convince Hervé to add ‘results' to BiocGenerics and everyone >>>> who exports such a function converts it to a method for that generic. >>> >>> My pleasure, and that's the cleanest solution. But it will only help >>> if the package that defines the "other" results() function is a >>> Bioconductor package and not a CRAN package. Has this package been >>> identified? >>> >>> A 4th option is to make sure that the other package gets loaded >>> _before_ SNPhood e.g. by putting an explicit library(>> package>) before library(SNPhood) in your vignette, even though that's >>> kind of hacky. >>> >>> Best, >>> >>> H. >>> >>>> Thank you and kind regards >>>> Wolfgang >>>> >>>> -- >>>> Wolfgang Huber >>>> EMBL >>>> https://www.huber.embl.de/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> Il giorno 2023-10-28, alle ore 16:15, Christian >>>>> Arnold ha scritto: >>>>> >>>>> For my package SNPhood that did not receive any code changes or >>>>> updates >>>>> in quite a while, I suddenly see errors with Bioc 3.18: >>>>> https://master.bioconductor.org/checkResults/3.18/bioc-LATEST/SNPhood/nebbiolo2-buildsrc.html >>>>> >>>>> Error: processing vignette 'workflow.Rmd' failed with diagnostics: >>>>> unused argument (type = "allelicBias") >>>>> >>>>> This comes from this line I think: >>>>> >>>>> names(results(SNPhood.o, type = "allelicBias")) >>>>> >>>>> For literally years, this didnt cause any problems, and the results >>>>> function is actually (re)defined in the SNPhood package: >>>>> >>>>> results <- function(SNPhood.o, type, elements = NULL) >>>>> >>>>> I am not sure now what causes this. Should I use the syntax >>>>> SNPhood::results to make it clear, or I am wrongly assuming that the >>>>> wrong result function is taken that causes the error? >>>>> >>>>> Any pointers? >>>>> >>>>> >>>>> Best >>>>> >>>>> Christian >>>>> >>>>> >>>>> [[alternative HTML version deleted]] >>>>> >>>>> ___ >>>>> Bioc-devel@r-project.org mailing list >>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >>>> ___ >>>> Bioc-devel@r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >>> -- >>> Hervé Pagès >>> >>> Bioconductor Core Team >>> hpages.on.git...@gmail.com >> >> -- >> Hervé Pagès >> >> Bioconductor Core Team >> hpages.on.git...@gmail.com >> >> [[alternative HTML version deleted]] >> >> ___ >> Bioc-devel@r-project.orgmailing 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
Re: [Bioc-devel] Package problems due to results() function from other package?
Hmm.. so I was curious and did a little bit more investigation about this. The other package that also defines a results() function is DESeq2, and it gets attached to the search path after calling analyzeSNPhood(). You can actually observe this phenomena with the following code: library(SNPhood) library(SNPhoodData) search() # DESeq2 is NOT attached example(analyzeSNPhood) search() # DESeq2 is attached What's intriguing is that this only happens in BioC 3.18. In BioC 3.17, running the analyzeSNPhood example does NOT alter the search path. After spending some time tracking this down, it turns out that the reason for this change of behaviour is a small tweak I made recently to the updateObject() generic in BiocGenerics. An unfortunate one that I will correct now. @Christian: A fix is on its way so you have nothing to do. Sorry for the trouble. H. On 10/31/23 09:44, Hervé Pagès wrote: > > On 10/31/23 07:22, Wolfgang Huber wrote: > >> Dear Christian >> >> If your vignette attaches another package that exports a “results” function, >> after it attached SNPhood which defines its own results function, then the R >> interpreter has no other choice than doing what it does. >> >> Other people adding additional functionality to their packages is probably >> not something one can really complain about, so I see three options >> - you use SNPhood::results in your vignette >> - you don’t attach the other package, and rather just use what you need from >> it using “::” >> - you convince Hervé to add ‘results' to BiocGenerics and everyone who >> exports such a function converts it to a method for that generic. > > My pleasure, and that's the cleanest solution. But it will only help > if the package that defines the "other" results() function is a > Bioconductor package and not a CRAN package. Has this package been > identified? > > A 4th option is to make sure that the other package gets loaded > _before_ SNPhood e.g. by putting an explicit library( package>) before library(SNPhood) in your vignette, even though that's > kind of hacky. > > Best, > > H. > >> Thank you and kind regards >> Wolfgang >> >> -- >> Wolfgang Huber >> EMBL >> https://www.huber.embl.de/ >> >> >> >> >> >> >> >> >> >>> Il giorno 2023-10-28, alle ore 16:15, Christian Arnold >>> ha scritto: >>> >>> For my package SNPhood that did not receive any code changes or updates >>> in quite a while, I suddenly see errors with Bioc 3.18: >>> https://master.bioconductor.org/checkResults/3.18/bioc-LATEST/SNPhood/nebbiolo2-buildsrc.html >>> >>> Error: processing vignette 'workflow.Rmd' failed with diagnostics: >>> unused argument (type = "allelicBias") >>> >>> This comes from this line I think: >>> >>> names(results(SNPhood.o, type = "allelicBias")) >>> >>> For literally years, this didnt cause any problems, and the results >>> function is actually (re)defined in the SNPhood package: >>> >>> results <- function(SNPhood.o, type, elements = NULL) >>> >>> I am not sure now what causes this. Should I use the syntax >>> SNPhood::results to make it clear, or I am wrongly assuming that the >>> wrong result function is taken that causes the error? >>> >>> Any pointers? >>> >>> >>> Best >>> >>> Christian >>> >>> >>> [[alternative HTML version deleted]] >>> >>> ___ >>> Bioc-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> ___ >> Bioc-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel > -- > Hervé Pagès > > Bioconductor Core Team > hpages.on.git...@gmail.com -- 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
Re: [Bioc-devel] Package problems due to results() function from other package?
On 10/31/23 07:22, Wolfgang Huber wrote: > Dear Christian > > If your vignette attaches another package that exports a “results” function, > after it attached SNPhood which defines its own results function, then the R > interpreter has no other choice than doing what it does. > > Other people adding additional functionality to their packages is probably > not something one can really complain about, so I see three options > - you use SNPhood::results in your vignette > - you don’t attach the other package, and rather just use what you need from > it using “::” > - you convince Hervé to add ‘results' to BiocGenerics and everyone who > exports such a function converts it to a method for that generic. My pleasure, and that's the cleanest solution. But it will only help if the package that defines the "other" results() function is a Bioconductor package and not a CRAN package. Has this package been identified? A 4th option is to make sure that the other package gets loaded _before_ SNPhood e.g. by putting an explicit library() before library(SNPhood) in your vignette, even though that's kind of hacky. Best, H. > > Thank you and kind regards > Wolfgang > > -- > Wolfgang Huber > EMBL > https://www.huber.embl.de/ > > > > > > > > > >> Il giorno 2023-10-28, alle ore 16:15, Christian Arnold ha >> scritto: >> >> For my package SNPhood that did not receive any code changes or updates >> in quite a while, I suddenly see errors with Bioc 3.18: >> https://master.bioconductor.org/checkResults/3.18/bioc-LATEST/SNPhood/nebbiolo2-buildsrc.html >> >> Error: processing vignette 'workflow.Rmd' failed with diagnostics: >> unused argument (type = "allelicBias") >> >> This comes from this line I think: >> >> names(results(SNPhood.o, type = "allelicBias")) >> >> For literally years, this didnt cause any problems, and the results >> function is actually (re)defined in the SNPhood package: >> >> results <- function(SNPhood.o, type, elements = NULL) >> >> I am not sure now what causes this. Should I use the syntax >> SNPhood::results to make it clear, or I am wrongly assuming that the >> wrong result function is taken that causes the error? >> >> Any pointers? >> >> >> Best >> >> Christian >> >> >> [[alternative HTML version deleted]] >> >> ___ >> Bioc-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel > ___ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel -- 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
Re: [Bioc-devel] groHMM package error
Package is all green today on the 3.18 report: https://bioconductor.org/checkResults/3.18/bioc-LATEST/groHMM/ Cheers, H. On 10/25/23 16:11, Hervé Pagès wrote: > > Addressed in S4Vectors 0.40.1. Today's builds have started already so > the fix won't be reflected on tomorrow's report (Thursday), only on > Friday. > > Sorry again for the inconvenience. > > Best, > > H. > > On 10/25/23 15:34, Hervé Pagès wrote: >> >> Hi Tulip, >> >> I think this is caused by a late change in S4Vectors: >> https://github.com/Bioconductor/S4Vectors/commit/15349ef40f141b16df6daf3e38f3782ef54eb60c >> >> This was an attempt at implementing the following feature request: >> https://github.com/Bioconductor/DelayedArray/issues/108 >> >> Sorry that this change broken your subsetting operation kgChr7[de==1, ]. >> >> Honestly, it's hard (if not impossible) to anticipate that some code >> somewhere would use a Nx1 TestResults object (this is what 'de==1' >> is!) as a subscript to subset a Vector derivative like your GRanges >> object kgChr7. It was just luck that this was working so far. >> Anyways, I think we can make this work again. A patch is coming. >> >> Best, >> >> H. >> >> On 10/25/23 14:03, Tulip Nandu wrote: >>> Hi Lori, >>> >>> Thank you for your prompt response. I haven't changed anything in the >>> development package (on git on anywhere else) then why the error message >>> has suddenly come up. As per the package what exactly they want me to >>> change so it passes the R CMD Check goes on without errors. >>> >>> Regards, >>> >>> Tulip. >>> >>> >>> From: Kern, Lori >>> Sent: Wednesday, October 25, 2023 6:06 AM >>> To: Tulip Nandu;bioc-devel@r-project.org >>> >>> Cc: Martin Grigorov >>> Subject: Re: groHMM package error >>> >>> You should make sure you are using the latest version of R and have updated >>> Bioconductor/CRAN packages by running BiocManager::valid and/or >>> BiocManager:install . I can reproduce this locally. >>> >>> Running your vignette it has to do with this line: >>> >>>> upGenes <- kgChr7[de==1,] >>> Error: invalid subscript >>> >>> >>> >>> >>> >>> Lori Shepherd - Kern >>> >>> Bioconductor Core Team >>> >>> Roswell Park Comprehensive Cancer Center >>> >>> Department of Biostatistics & Bioinformatics >>> >>> Elm & Carlton Streets >>> >>> Buffalo, New York 14263 >>> >>> >>> From: Tulip Nandu >>> Sent: Tuesday, October 24, 2023 3:33 PM >>> To:bioc-devel@r-project.org >>> Cc: Kern, Lori; Martin >>> Grigorov >>> Subject: Re: groHMM package error >>> >>> Hi, >>> >>> >>> Can someone explain as why has this error suddenly come up. I haven't >>> changed anything from my end. >>> >>> Also, please if someone can help me tackle the error it would be great. >>> >>> >>> Thanks. >>> >>> Regards, >>> >>> Tulip. >>> >>> >>> From: Kern, Lori >>> Sent: Wednesday, October 18, 2023 3:45 PM >>> To: Tulip Nandu >>> Subject: Re: groHMM package error >>> >>> As Martin also responded, The ERROR should not be neglected but you should >>> push to the "devel" branch instead of "RELEASE_3_18". >>> >>> >>> >>> >>> >>> Lori Shepherd - Kern >>> >>> Bioconductor Core Team >>> >>> Roswell Park Comprehensive Cancer Center >>> >>> Department of Biostatistics & Bioinformatics >>> >>> Elm & Carlton Streets >>> >>> Buffalo, New York 14263 >>> >>> >>> From: Tulip Nandu >>> Sent: Wednesday, October 18, 2023 4:37 PM >>> To: Kern, Lori;bioc-devel@r-project.org >>> ;martin.grigo...@gmail.com >>> >>> Subject: Re: groHMM package error >>> >>> Is this error to be neglected then? >>> >>> Package: groHMM >>> Version: 1.35.0 >>> Command: /home/biocbuild/bbs-3.18-bioc/R/bin/R CMD build --keep-empty-dirs >>&g
Re: [Bioc-devel] RCAS build error on Nebbiolo2 - Missing BiocManager
Hi Bora,
BiocManager is installed on the machine but 'R CMD check' does not "see"
it because you don't have it listed in Suggests. This 'R CMD check'
behavior is controlled by the _R_CHECK_SUGGESTS_ONLY_ behavior and is
only enabled on our Linux builders for now.
However, please note that the code in your examples, vignettes or unit
tests should NOT install packages. I don't know what package exactly
checkSeqDb('hg19') is trying to install but that is what should be
listed in Suggests instead of BiocManager. That way it won't be
reinstalled over and over again by 'R CMD check'.
Best,
H.
On 10/27/23 05:56, bora.u...@mdc-berlin.de wrote:
> Hi Bioc-Devel Team,
>
> My package RCAS has been getting build errors on Nebbiolo2. It fails to run
> the tests/examples/vignettes all due to a missing dependency, which can’t be
> installed because BiocManager is not available.
>
> Here is the build report:
> https://bioconductor.org/checkResults/release/bioc-LATEST/RCAS/nebbiolo2-checksrc.html
>
> The relevant error is :
>
> Error in get_data_annotation_contrib_url(type) :
>Install 'BiocManager' from CRAN to get 'BioCann' contrib.url
>
> Error: processing vignette 'RCAS.vignette.Rmd' failed with diagnostics:
> Install 'BiocManager' from CRAN to get 'BioCann' contrib.url
>
> The other machines all build it properly.
>
> Best,
> Bora
>
> ---
> Dr. Bora Uyar
> Bioinformatics Scientist
> Bioinformatics and Omics Data Science Platform
> Max Delbrueck Center (MDC) for Molecular Medicine
> The Berlin Institute for Medical Systems Biology
> Hannoversche Str. 28, 10115 Berlin
>
>
>
> [[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
Re: [Bioc-devel] flowDensity 1.35.0 in 3.18 still imports archived rgeos
Thanks Roger for the reminder. FWIW an issue has been opened on GitHub for flowDensity (see https://github.com/mehrnoushmalek/flowDensity/issues/10), and it looks like Mehrnoush was able to make an rgeos-free version of the package. Hopefully he can push it to the Bioconductor git server at git.bioconductor.org soon. Cheers, H. On 10/26/23 05:22, Roger Bivand wrote: > As far as I can tell, only flowDensity has not updated to the archiving of > R-spatial infrastructure packages, specifically rgeos, 2023-10-16 and > notified here, (seehttps://r-spatial.github.io/evolution/) and directly to > package maintainers in good time (June 2023). Please ensure that rgeos, > rgdal, and maptools are removed from Bioconductor check servers for >= 3.18 > as soon as possible. > > Unfortunately, flowDensity has strong reverse dependencies, leading to > further problems upgrading to 3.18 on platforms without the archived packages > on the library path. > > The maintainer email bounces, but mehrmalek at gmail.com may be an > alternative. > > Roger > > -- > Roger Bivand > Emeritus Professor > Norwegian School of Economics > Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway > roger.biv...@nhh.no > ___ > 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
Re: [Bioc-devel] groHMM package error
Addressed in S4Vectors 0.40.1. Today's builds have started already so the fix won't be reflected on tomorrow's report (Thursday), only on Friday. Sorry again for the inconvenience. Best, H. On 10/25/23 15:34, Hervé Pagès wrote: > > Hi Tulip, > > I think this is caused by a late change in S4Vectors: > https://github.com/Bioconductor/S4Vectors/commit/15349ef40f141b16df6daf3e38f3782ef54eb60c > > This was an attempt at implementing the following feature request: > https://github.com/Bioconductor/DelayedArray/issues/108 > > Sorry that this change broken your subsetting operation kgChr7[de==1, ]. > > Honestly, it's hard (if not impossible) to anticipate that some code > somewhere would use a Nx1 TestResults object (this is what 'de==1' > is!) as a subscript to subset a Vector derivative like your GRanges > object kgChr7. It was just luck that this was working so far. Anyways, > I think we can make this work again. A patch is coming. > > Best, > > H. > > On 10/25/23 14:03, Tulip Nandu wrote: >> Hi Lori, >> >> Thank you for your prompt response. I haven't changed anything in the >> development package (on git on anywhere else) then why the error message has >> suddenly come up. As per the package what exactly they want me to change so >> it passes the R CMD Check goes on without errors. >> >> Regards, >> >> Tulip. >> >> >> From: Kern, Lori >> Sent: Wednesday, October 25, 2023 6:06 AM >> To: Tulip Nandu;bioc-devel@r-project.org >> >> Cc: Martin Grigorov >> Subject: Re: groHMM package error >> >> You should make sure you are using the latest version of R and have updated >> Bioconductor/CRAN packages by running BiocManager::valid and/or >> BiocManager:install . I can reproduce this locally. >> >> Running your vignette it has to do with this line: >> >>> upGenes <- kgChr7[de==1,] >> Error: invalid subscript >> >> >> >> >> >> Lori Shepherd - Kern >> >> Bioconductor Core Team >> >> Roswell Park Comprehensive Cancer Center >> >> Department of Biostatistics & Bioinformatics >> >> Elm & Carlton Streets >> >> Buffalo, New York 14263 >> >> >> From: Tulip Nandu >> Sent: Tuesday, October 24, 2023 3:33 PM >> To:bioc-devel@r-project.org >> Cc: Kern, Lori; Martin >> Grigorov >> Subject: Re: groHMM package error >> >> Hi, >> >> >> Can someone explain as why has this error suddenly come up. I haven't >> changed anything from my end. >> >> Also, please if someone can help me tackle the error it would be great. >> >> >> Thanks. >> >> Regards, >> >> Tulip. >> >> >> From: Kern, Lori >> Sent: Wednesday, October 18, 2023 3:45 PM >> To: Tulip Nandu >> Subject: Re: groHMM package error >> >> As Martin also responded, The ERROR should not be neglected but you should >> push to the "devel" branch instead of "RELEASE_3_18". >> >> >> >> >> >> Lori Shepherd - Kern >> >> Bioconductor Core Team >> >> Roswell Park Comprehensive Cancer Center >> >> Department of Biostatistics & Bioinformatics >> >> Elm & Carlton Streets >> >> Buffalo, New York 14263 >> >> >> From: Tulip Nandu >> Sent: Wednesday, October 18, 2023 4:37 PM >> To: Kern, Lori;bioc-devel@r-project.org >> ;martin.grigo...@gmail.com >> >> Subject: Re: groHMM package error >> >> Is this error to be neglected then? >> >> Package: groHMM >> Version: 1.35.0 >> Command: /home/biocbuild/bbs-3.18-bioc/R/bin/R CMD build --keep-empty-dirs >> --no-resave-data groHMM >> StartedAt: 2023-10-17 17:05:26 -0400 (Tue, 17 Oct 2023) >> EndedAt: 2023-10-17 17:07:18 -0400 (Tue, 17 Oct 2023) >> EllapsedTime: 112.0 seconds >> RetCode: 1 >> Status: ERROR >> PackageFile: None >> PackageFileSize: NA >> >> >> According to the Multiple platform build/check report for BioC 3.18, >> the groHMM package has the following problem(s): >> >> o ERROR for 'R CMD build' on nebbiolo2. See the details here: >> >> https://secure-web.cisco.com/1Gxx-FnOWCG92V7Tzo6WKfoWn5bSB3-JFD94GIphjmXdi4H2pB97FW0r5HHTt-hdeQj7zZhcmI6dFaU86awXiiWtmSvKjj9swVSo0aGgPMnXH3Z4vVOjbh4zpLrt5PzPE2mXDfaE3BRb3jfaDqsJCAvn19Xv6OnoDfdbzoSo0goZWmkpXfnPaq1s8LMbJi-bz
Re: [Bioc-devel] atena build error on kunpeng2 Linux openEuler 22.03 LTS-SP1 / aarch64
That was actually about the gDNAx package (based on the URL you provided
in your original post), which will hopefully turn green on kunpeng2
today: https://bioconductor.org/checkResults/3.18/bioc-LATEST/gDNAx
Best,
H.
On 10/23/23 23:29, Robert Castelo wrote:
>
> Hervé, Martin,
>
> Thank you so much, atena builds and checks cleanly now on kunpeng2 too!!
>
> https://bioconductor.org/checkResults/3.18/bioc-LATEST/atena
>
> cheers,
>
> robert.
>
> On 10/23/23 20:46, Hervé Pagès wrote:
>>
>> On 10/23/23 11:45, Martin Grigorov wrote:
>>
>>> Hi,
>>>
>>> > quickBamFlagSummary(eh[["EH8081"]])
>>> see ?gDNAinRNAseqData and browseVignettes('gDNAinRNAseqData') for
>>> documentation
>>> loading from cache
>>> [E::hts_hopen] Failed to open file
>>> /home/biocbuild/.cache/R/ExperimentHub/1d1f2d2a8e1eab_8133
>>> [E::hts_open_format] Failed to open file
>>> "/home/biocbuild/.cache/R/ExperimentHub/1d1f2d2a8e1eab_8133" : Exec
>>> format error
>>> Error in value[[3L]](cond) :
>>> failed to open BamFile: failed to open SAM/BAM file
>>> file: '/home/biocbuild/.cache/R/ExperimentHub/1d1f2d2a8e1eab_8133'
>>> > eh[["EH8081", force=TRUE]]
>>> see ?gDNAinRNAseqData and browseVignettes('gDNAinRNAseqData') for
>>> documentation
>>> downloading 2 resources
>>> retrieving 2 resources
>>> |==|
>>> 100%
>>>
>>> |==|
>>> 100%
>>>
>>> loading from cache
>>> class: BamFile
>>> path: /home/biocbuild/.cache/R/ExperimentHub/1d1f2d2a8e1eab_8133
>>> index: /home/biocbuild/.cache/R/ExperimentHub/1d1f2d19075fb4_8134
>>> isOpen: FALSE
>>> yieldSize: NA
>>> obeyQname: FALSE
>>> asMates: FALSE
>>> qnamePrefixEnd: NA
>>> qnameSuffixStart: NA
>>> > quickBamFlagSummary(eh[["EH8081"]])
>>> see ?gDNAinRNAseqData and browseVignettes('gDNAinRNAseqData') for
>>> documentation
>>> loading from cache
>>> [E::idx_find_and_load] Could not retrieve index file for
>>> '/home/biocbuild/.cache/R/ExperimentHub/1d1f2d19075fb4_8134'
>>> group | nb of | nb of | mean / max
>>> of | records | unique | records per
>>> records | in group | QNAMEs | unique QNAME
>>> All records A | 215602 | 10 | 2.16 / 20
>>> o template has single segment S | 0 | 0 | NA / NA
>>> o template has multiple segments. M | 215602 | 10 | 2.16 / 20
>>> - first segment.. F | 107801 | 10 | 1.08 / 10
>>> - last segment... L | 107801 | 10 | 1.08 / 10
>>> - other segment.. O | 0 | 0 | NA / NA
>>>
>>> Note that (S, M) is a partitioning of A, and (F, L, O) is a
>>> partitioning of M.
>>> Indentation reflects this.
>>>
>>> Details for group M:
>>> o record is mapped.. M1 | 215602 | 10 | 2.16 / 20
>>> - primary alignment. M2 | 20 | 10 | 2 / 2
>>> - secondary alignment... M3 | 15602 | 4085 | 3.82 / 18
>>> o record is unmapped M4 | 0 | 0 | NA / NA
>>>
>>> Details for group F:
>>> o record is mapped.. F1 | 107801 | 10 | 1.08 / 10
>>> - primary alignment. F2 | 10 | 10 | 1 / 1
>>> - secondary alignment... F3 | 7801 | 4085 | 1.91 / 9
>>> o record is unmapped F4 | 0 | 0 | NA / NA
>>>
>>> Details for group L:
>>> o record is mapped.. L1 | 107801 | 10 | 1.08 / 10
>>> - primary alignment. L2 | 10 | 10 | 1 / 1
>>> - secondary alignment... L3 | 7801 | 4085 | 1.91 / 9
>>> o record is unmapped L4 | 0 | 0 | NA / NA
>>>
>>>
>>> Looks good ?
>>
>>
>> Looks good. Thanks Martin!
>>
>> H.
>>
>>
>>>
>>> Regards,
>>> Martin
>>>
>>>
>>> On Mon, Oct 23, 2023 at 7:26 PM Hervé Pagès
>>> wrote:
>>>
>>> Hi Robert,
>>>
>>> There's the possibility that some of these BAM files got
>>
Re: [Bioc-devel] atena build error on kunpeng2 Linux openEuler 22.03 LTS-SP1 / aarch64
On 10/23/23 11:45, Martin Grigorov wrote:
> Hi,
>
> > quickBamFlagSummary(eh[["EH8081"]])
> see ?gDNAinRNAseqData and browseVignettes('gDNAinRNAseqData') for
> documentation
> loading from cache
> [E::hts_hopen] Failed to open file
> /home/biocbuild/.cache/R/ExperimentHub/1d1f2d2a8e1eab_8133
> [E::hts_open_format] Failed to open file
> "/home/biocbuild/.cache/R/ExperimentHub/1d1f2d2a8e1eab_8133" : Exec
> format error
> Error in value[[3L]](cond) :
> failed to open BamFile: failed to open SAM/BAM file
> file: '/home/biocbuild/.cache/R/ExperimentHub/1d1f2d2a8e1eab_8133'
> > eh[["EH8081", force=TRUE]]
> see ?gDNAinRNAseqData and browseVignettes('gDNAinRNAseqData') for
> documentation
> downloading 2 resources
> retrieving 2 resources
> |==|
> 100%
>
> |==|
> 100%
>
> loading from cache
> class: BamFile
> path: /home/biocbuild/.cache/R/ExperimentHub/1d1f2d2a8e1eab_8133
> index: /home/biocbuild/.cache/R/ExperimentHub/1d1f2d19075fb4_8134
> isOpen: FALSE
> yieldSize: NA
> obeyQname: FALSE
> asMates: FALSE
> qnamePrefixEnd: NA
> qnameSuffixStart: NA
> > quickBamFlagSummary(eh[["EH8081"]])
> see ?gDNAinRNAseqData and browseVignettes('gDNAinRNAseqData') for
> documentation
> loading from cache
> [E::idx_find_and_load] Could not retrieve index file for
> '/home/biocbuild/.cache/R/ExperimentHub/1d1f2d19075fb4_8134'
> group | nb of | nb of | mean / max
> of | records | unique | records per
> records | in group | QNAMEs | unique QNAME
> All records A | 215602 | 10 | 2.16 / 20
> o template has single segment S | 0 | 0 | NA / NA
> o template has multiple segments. M | 215602 | 10 | 2.16 / 20
> - first segment.. F | 107801 | 10 | 1.08 / 10
> - last segment... L | 107801 | 10 | 1.08 / 10
> - other segment.. O | 0 | 0 | NA / NA
>
> Note that (S, M) is a partitioning of A, and (F, L, O) is a
> partitioning of M.
> Indentation reflects this.
>
> Details for group M:
> o record is mapped.. M1 | 215602 | 10 | 2.16 / 20
> - primary alignment. M2 | 20 | 10 | 2 / 2
> - secondary alignment... M3 | 15602 | 4085 | 3.82 / 18
> o record is unmapped M4 | 0 | 0 | NA / NA
>
> Details for group F:
> o record is mapped.. F1 | 107801 | 10 | 1.08 / 10
> - primary alignment. F2 | 10 | 10 | 1 / 1
> - secondary alignment... F3 | 7801 | 4085 | 1.91 / 9
> o record is unmapped F4 | 0 | 0 | NA / NA
>
> Details for group L:
> o record is mapped.. L1 | 107801 | 10 | 1.08 / 10
> - primary alignment. L2 | 10 | 10 | 1 / 1
> - secondary alignment... L3 | 7801 | 4085 | 1.91 / 9
> o record is unmapped L4 | 0 | 0 | NA / NA
>
>
> Looks good ?
Looks good. Thanks Martin!
H.
>
> Regards,
> Martin
>
>
> On Mon, Oct 23, 2023 at 7:26 PM Hervé Pagès
> wrote:
>
> Hi Robert,
>
> There's the possibility that some of these BAM files got corrupted
> when
> downloaded to kunpeng2 local cache.
>
> @Martin Gregorov: Would you be able to try to run the following on
> kunpeng2?
>
> library(Rsamtools)
> library(ExperimentHub)
> eh <- ExperimentHub()
> quickBamFlagSummary(eh[["EH8081"]])
>
> If you get an error that the file cannot be opened, then maybe try to
> re-download it with:
>
> eh[["EH8081", force=TRUE]]
>
> Then try quickBamFlagSummary(eh[["EH8081"]]) again and hopefully
> it will
> work.
>
> Thanks,
>
> H.
>
> On 10/23/23 08:03, Robert Castelo wrote:
> > hi,
> >
> > our package atena fails to build **only** in kunpeng2 Linux
> openEuler
> > 22.03 LTS-SP1 / aarch64:
> >
> >
>
> https://bioconductor.org/checkResults/3.18/bioc-LATEST/gDNAx/kunpeng2-buildsrc.html
>
> >
> >
> > concretely, the vignette fails to find a BAM file downloaded via
> > ExperimentHub. This does not happen in any of the other platforms.
> > Should we
Re: [Bioc-devel] Build error on nebbiolo2
Hi Gregory, Looks like GDAL is missing on nebbolo2. We're looking into this. Thanks for letting us know, H. On 10/23/23 10:25, Gregory B. Gloor wrote: > Hello, > > I received an error today on this machine for ALDEx2 > > I last committed 12 days ago and until today it was building cleanly on > everything. I am not sure what I can do to fix the error since I don't know > what dependency is calling that library file > > Any help appreciated > > Greg > > ## > ## > ### > ### Running command: > ### > ### /home/biocbuild/bbs-3.18-bioc/R/bin/R CMD build --keep-empty-dirs > --no-resave-data ALDEx2 > ### > ## > ## > > > * checking for file ‘ALDEx2/DESCRIPTION’ ... OK > * preparing ‘ALDEx2’: > * checking DESCRIPTION meta-information ... OK > * installing the package to build vignettes > * creating vignettes ... ERROR > --- re-building ‘ALDEx2_vignette.Rmd’ using rmarkdown > --- finished re-building ‘ALDEx2_vignette.Rmd’ > > --- re-building ‘scaleSim_vignette.Rmd’ using rmarkdown > > Quitting from lines 331-419 [graph] (scaleSim_vignette.Rmd) > Error: processing vignette 'scaleSim_vignette.Rmd' failed with diagnostics: > unable to load shared object > '/home/biocbuild/bbs-3.18-bioc/R/site-library/sf/libs/sf.so': > libgdal.so.30: cannot open shared object file: No such file or directory > --- failed re-building ‘scaleSim_vignette.Rmd’ > > SUMMARY: processing the following file failed: > ‘scaleSim_vignette.Rmd’ > > Error: Vignette re-building failed. > Execution halted > ___ > 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
Re: [Bioc-devel] atena build error on kunpeng2 Linux openEuler 22.03 LTS-SP1 / aarch64
Hi Robert, There's the possibility that some of these BAM files got corrupted when downloaded to kunpeng2 local cache. @Martin Gregorov: Would you be able to try to run the following on kunpeng2? library(Rsamtools) library(ExperimentHub) eh <- ExperimentHub() quickBamFlagSummary(eh[["EH8081"]]) If you get an error that the file cannot be opened, then maybe try to re-download it with: eh[["EH8081", force=TRUE]] Then try quickBamFlagSummary(eh[["EH8081"]]) again and hopefully it will work. Thanks, H. On 10/23/23 08:03, Robert Castelo wrote: > hi, > > our package atena fails to build **only** in kunpeng2 Linux openEuler > 22.03 LTS-SP1 / aarch64: > > https://bioconductor.org/checkResults/3.18/bioc-LATEST/gDNAx/kunpeng2-buildsrc.html > > > > concretely, the vignette fails to find a BAM file downloaded via > ExperimentHub. This does not happen in any of the other platforms. > Should we do anything about this? > > Thanks! > > robert. > -- 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
Re: [Bioc-devel] Errors on package post 3.18 deadline
Hi Burak, On 10/20/23 21:12, Burak Ogan Mancarci wrote: > Hi, > > I am a developer working on the bioconductor package gemma.R > <https://bioconductor.org/packages/3.16/data/experiment/html/gemma.R.html>. > This is a API package that interacts with our servers and we had an > unfortunate case of updating our databases when the tests were running. I > was wondering having the error today would effect the 3.18 release. Today's error won't affect the 3.18 release. Hopefully the package goes back to green on the next report. Best, H. PS: The link you provided to your package doesn't work. > > Cheers, > Ogan > > [[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
Re: [Bioc-devel] Failed to obtain 'hguid' cookie
Hi Tiphaine, This is a known issue with the rtracklayer package. The issue itself is caused by a change that was made earlier this week on the UCSC servers. The rtracklayer issue is being discussed here https://github.com/lawremi/rtracklayer/issues/95. I'm waiting for my PR to be merged, hopefully soon. Best, H. On 10/20/23 09:11, Martin, Tiphaine via Bioc-devel wrote: > Hi, > > I have my package that failed to build its vignette because of failing to > obtain 'hguid' cookie. > > Could you please tell me how I can solve this? > > thanks, > Tiphaine > > > Tiphaine Martin > Assistant Professor > Department of Oncological Sciences > The Tisch Cancer Institute at Mount Sinai > Icahn School of Medicine at Mount Sinai > Hess Center for Science and Medicine > 1470 Madison Ave, 6th Floor > New York, NY 10029 > tel: 1- 212-824-9253 > Email:tiphaine.mar...@mssm.edu<mailto:tiphaine.mar...@mssm.edu> > > > [[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
Re: [Bioc-devel] Build error for CaDrA package on kunpeng2 Linux machine
Hi Reina, Note that CaDrA results on Mac ARM64 are also affected: https://bioconductor.org/checkResults/devel/bioc-mac-arm64-LATEST/CaDrA/ See Martin Grigorov's blog post here https://blog.bioconductor.org/posts/2023-06-09-debug-linux-arm64-on-docker/ for how to debug Linux ARM64 related issues on a x86_64 host. Note that different architectures use slightly different floating point arithmetic with slightly different precision. This can affect the results of your numerical calculations. The degree to which they are affected will vary greatly depending on what calculations you perform and how you perform them. So it's important to implement things in a way that tries to minimize the impact of these variations as much as possible. Best, H. On 10/18/23 10:46, Chau, Reina wrote: > Hi Bioconductor Core Team, > > I’m the maintainer of CaDrA package, and recently, I notice that my package > built successfully for all platforms except on Kunpeng2 Linux machine > (seehttps://bioconductor.org/checkResults/devel/bioc-LATEST/CaDrA/ > andhttps://bioconductor.org/checkResults/devel/bioc-LATEST/CaDrA/kunpeng2-checksrc.html) > > I did try to figure out what is causing the different results using this > particular platform compare with others but with no resolves. > > Hope you can give me some guidance or feedback of why the build is failing > for this particular case. > > Thanks so much! > > Best, > > Reina C. > > [[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
Re: [Bioc-devel] arm64 on Mac build fails due to problem with MPO.db
On 10/12/23 12:25, Zuguang Gu wrote:
> The devel version of DOSE depends on MPO.db.
>
> I also found MoonlightR depends on DOSE only on its two functions:
> gseDO() and simplot().
>
> An analysis by the pkgndep package shows if you can reduce the
> dependency on both clusterProfiler and DOSE, a total of 46 upstream
> dependencies will be reduced (30 by clusterProfiler uniquely and 16 by
> both). You can use `pkgndep::dependency_database()` to query the
> dependencies, but the database was only updated to some version last year.
>
> MPO.db initializes an instance of AnnotationHub in its .onLoad(). I
> don't know whether that is the source of the error.
>
> .onLoad <- function(libname, pkgname) {
> ns <- asNamespace(pkgname)
> makeCachedActiveBinding("MPO.db", make_MPO.db, env=ns)
> namespaceExport(ns, "MPO.db")
> ah <- suppressMessages(AnnotationHub())
> dbfile <- ah[["AH111553", verbose=FALSE]]
> dbconn <- AnnotationDbi::dbFileConnect(dbfile)
> assign("dbconn", dbconn, envir=datacache)
> ann_objs <- createAnnObjs.MPO_DB("MPO", "MPO", dbconn, datacache)
> mergeToNamespaceAndExport(ann_objs, "MPO.db")
>
> }
I don't know either but we strongly recommend against .onLoad hooks
trying to access the internet. Once a package is installed, one should
be able to load it offline.
H.
>
>
> On Thu, 12 Oct 2023 at 20:37, Robert Castelo
> wrote:
>
> Hi,
>
> one of the kind of tools that Hervé is referring to is the package
> BiocPkgTools:
>
> https://bioconductor.org/packages/BiocPkgTools
>
> section "7 Dependency burden" in the vignette illustrates how to
> identify dependencies that you might want to get rid of.
>
> cheers,
>
> robert.
>
> On 12/10/23 18:24, Hervé Pagès wrote:
> > On 10/12/23 00:45, Matteo Tiberti wrote:
> >
> >> Hi Hervé,
> >>
> >> Thank you for your comment and for looking into our package – it
> >> would definitely make sense to try and not depend on
> clusterProfiler
> >> if it is that heavy of a dependency (and we don’t use it so
> much as
> >> you mention), more in general working in the direction of removing
> >> little-used or heavy dependencies would speed things up all around
> >> and reduce the chance of having failures because of
> changes/failures
> >> of dep. packages. We will try and reassess the package imports in
> >> this direction.
> >>
> >> It would be great if we could obtain e.g. a dependency graph –
> or at
> >> least know how many (unique) dependencies each of our deps has,
> e.g.
> >> I saw that miniCRAN can do something similar
> >>
> > I think there are a number of tools already that you can use to do
> > this kind of analysis e.g. basic low-level tools like
> > tools::package_dependencies() but also more high-level ones with
> > advanced functionalities like pkgndep (CRAN package) etc...
> >
> > H.
> >>
> >> Best,
> >>
> >>
> >> Matteo Tiberti
> >>
> >> *Danish Cancer Institute*
> >> Strandboulevarden 49
> >> DK-2100 Copenhagen
> >> *Telephone*: +45 35 25 73 07
> >> /– a part of the Danish Cancer Society/
> >>
> >>
>
> <https://www.cancer.dk/?utm_source=email_medium=medarbejderemail_campaign=medarbejderemail_content=cancerdk
>
> <https://www.cancer.dk/?utm_source=email_medium=medarbejderemail_campaign=medarbejderemail_content=cancerdk>>
>
> >>
> >>
> >> www.cancer.dk <http://www.cancer.dk>
> <https://www.cancer.dk/international/> | Our privacy
> >> policy <https://www.cancer.dk/om-os/privatlivspolitik/>
> >>
> >> *From: *Hervé Pagès
> >> *Date: *Wednesday, 11 October 2023 at 19.30
> >> *To: *Matteo Tiberti , bioc-devel@r-project.org
> >>
> >> *Subject: *Re: [Bioc-devel] arm64 on Mac build fails due to
> problem
> >> with MPO.db
> >>
> >> Hi Matteo,
> >>
> >> Thanks for letting us know.
> >>
> >> FWIW the dependency on MPO.db is via clusterProfiler and DOSE.
> >>
> >> Not directly addressing the issue but note that clusterProfiler
> is a
> >> h
Re: [Bioc-devel] arm64 on Mac build fails due to problem with MPO.db
On 10/12/23 00:45, Matteo Tiberti wrote: Hi Hervé, Thank you for your comment and for looking into our package – it would definitely make sense to try and not depend on clusterProfiler if it is that heavy of a dependency (and we don’t use it so much as you mention), more in general working in the direction of removing little-used or heavy dependencies would speed things up all around and reduce the chance of having failures because of changes/failures of dep. packages. We will try and reassess the package imports in this direction. It would be great if we could obtain e.g. a dependency graph – or at least know how many (unique) dependencies each of our deps has, e.g. I saw that miniCRAN can do something similar I think there are a number of tools already that you can use to do this kind of analysis e.g. basic low-level tools like tools::package_dependencies() but also more high-level ones with advanced functionalities like pkgndep (CRAN package) etc... H. Best, Matteo Tiberti *Danish Cancer Institute* Strandboulevarden 49 DK-2100 Copenhagen *Telephone*: +45 35 25 73 07 /– a part of the Danish Cancer Society/ <https://www.cancer.dk/?utm_source=email_medium=medarbejderemail_campaign=medarbejderemail_content=cancerdk> www.cancer.dk <https://www.cancer.dk/international/> | Our privacy policy <https://www.cancer.dk/om-os/privatlivspolitik/> *From: *Hervé Pagès *Date: *Wednesday, 11 October 2023 at 19.30 *To: *Matteo Tiberti , bioc-devel@r-project.org *Subject: *Re: [Bioc-devel] arm64 on Mac build fails due to problem with MPO.db Hi Matteo, Thanks for letting us know. FWIW the dependency on MPO.db is via clusterProfiler and DOSE. Not directly addressing the issue but note that clusterProfiler is a heavy-weight dependency that triggers the loading of 120+ packages. All together, loading Moonlight2R with library(Moonlight2R) triggers the loading of 170+ packages which takes about 20 seconds. Have you considered trying to make Moonlight2R dependencies lighter? For example it seems that the only thing that the package uses from clusterProfiler is clusterProfiler::bitr(), which is a simple convenience wrapper around AnnotationDbi::select() used inside your GSEA() function. I wonder if some of these deps could perhaps be moved from Imports to Suggests, with the hope to make library(Moonlight2R) lighter and faster. Best, H. On 10/11/23 02:18, Matteo Tiberti via Bioc-devel wrote: Dear all, We are seeing a couple of build fails of our MoonlightR and Moonlight2R packages in the devel (3.18) MacOS arm64 builder that seem to be related to the MPO.db package. This is the error message we get: * installing to library ‘/Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/library’ * installing *source* package ‘Moonlight2R’ ... ** using staged installation ** R ** data ** inst ** byte-compile and prepare package for lazy loading Warning: Couldn't set cache size: file is not a database Use `cache_size` = NULL to turn off this warning. Warning: Couldn't set synchronous mode: file is not a database Use `synchronous` = NULL to turn off this warning. Error: .onLoad failed in loadNamespace() for 'MPO.db', details: call: NULL error: file is not a database Execution halted ERROR: lazy loading failed for package ‘Moonlight2R’ * removing ‘/Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/library/Moonlight2R’ We don’t have MPO.db as an explicit requirement for our packages, and it checks all green on its own build report. We poked around 3.18 MacOS arm64 build reports and saw several other packages with similar failures (e.g. miRspongeR<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/miRspongeR/> <https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/miRspongeR/> miRSM<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/miRSM/> <https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/miRSM/> MicrobiomeProfiler<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/MicrobiomeProfiler/> <https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/MicrobiomeProfiler/> EasyCellType<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/EasyCellType/> <https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/EasyCellType/> MetaPhOR<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/MetaPhOR/> <https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/MetaPhOR/> meshes<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/meshes/> <https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/meshes/> CBNplot<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/CBNplot/&
Re: [Bioc-devel] arm64 on Mac build fails due to problem with MPO.db
Hi Matteo, Thanks for letting us know. FWIW the dependency on MPO.db is via clusterProfiler and DOSE. Not directly addressing the issue but note that clusterProfiler is a heavy-weight dependency that triggers the loading of 120+ packages. All together, loading Moonlight2R with library(Moonlight2R) triggers the loading of 170+ packages which takes about 20 seconds. Have you considered trying to make Moonlight2R dependencies lighter? For example it seems that the only thing that the package uses from clusterProfiler is clusterProfiler::bitr(), which is a simple convenience wrapper around AnnotationDbi::select() used inside your GSEA() function. I wonder if some of these deps could perhaps be moved from Imports to Suggests, with the hope to make library(Moonlight2R) lighter and faster. Best, H. On 10/11/23 02:18, Matteo Tiberti via Bioc-devel wrote: > Dear all, > > We are seeing a couple of build fails of our MoonlightR and > Moonlight2R packages in the devel (3.18) MacOS arm64 builder that seem > to be related to the MPO.db package. This is the error message we get: > > * installing to library > ‘/Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/library’ > * installing *source* package ‘Moonlight2R’ ... > ** using staged installation > ** R > ** data > ** inst > ** byte-compile and prepare package for lazy loading > Warning: Couldn't set cache size: file is not a database > Use `cache_size` = NULL to turn off this warning. > Warning: Couldn't set synchronous mode: file is not a database > Use `synchronous` = NULL to turn off this warning. > Error: .onLoad failed in loadNamespace() for 'MPO.db', details: > call: NULL > error: file is not a database > Execution halted > ERROR: lazy loading failed for package ‘Moonlight2R’ > * removing > ‘/Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/library/Moonlight2R’ > > We don’t have MPO.db as an explicit requirement for our packages, and > it checks all green on its own build report. We poked around 3.18 > MacOS arm64 build reports and saw several other packages with similar > failures (e.g. > miRspongeR<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/miRspongeR/> > > miRSM<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/miRSM/> > > MicrobiomeProfiler<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/MicrobiomeProfiler/> > > EasyCellType<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/EasyCellType/> > > MetaPhOR<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/MetaPhOR/> > > meshes<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/meshes/> > > CBNplot<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/CBNplot/> > > …) so we were wondering if there’s a more general problem with the > builder/set up or if there is a general solution to this. Suggestions > are welcome > > Thank you, > > Matteo Tiberti > > Danish Cancer Institute > Strandboulevarden 49 > DK-2100 Copenhagen > Telephone: +45 35 25 73 07 > – a part of the Danish Cancer Society > > [cid:image001.png@01D9FB90.6FE2D7A0]<https://www.cancer.dk/?utm_source=email_medium=medarbejderemail_campaign=medarbejderemail_content=cancerdk> > > > > www.cancer.dk<https://www.cancer.dk/international/> | Our privacy > policy<https://www.cancer.dk/om-os/privatlivspolitik/> > > ___ > 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
Re: [Bioc-devel] [Rd] is.atomic(NULL) will become FALSE
Thanks Martin for the heads-up. H. On 9/26/23 09:06, Martin Maechler wrote: > I've sent a longish post to the R-devel mailing list with this > topic here: > https://stat.ethz.ch/pipermail/r-devel/2023-September/082892.html > > In the mean time, the plan is to effectuate the change in > R-devel (the in-development version of R) on Sep.28, ~ 9:30 CEST ( =UTC+2) > > AFAIK, this will only affect bioconductor packages *after* the > upcoming release of BioC ... when they will all begin to run / > be tested "against R-devel". > > But if you use CI / R-bug / rocker / ... tests for your packages > using the development version of R, this may affect some of > your bioconductor packages already sooner. > > Best regards, > Martin > > -- > Martin Maechler > ETH Zurich and R Core team > > ___ > 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
Re: [Bioc-devel] Missing Java on Windows Development Machine palomino4
0%7C638313325236054652%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=9Xc2pcLzslWjCmKJXLGhhmwenj7ZWahbrKjlrg09sZ4%3D=0 > > > > Dear package maintainer, > > your package "rRDP" is currently failing on the Bioconductor devel branch > (error for R CMD build on Windows; build report from 2023-09-24). Please have > a look into this and fix the issue. From the error message it seems that java > is missing on that build machine. Eventually get in contact with the > Bioconductor core team for help. > > Please use the Bioconductor developer mailing list if you need any help (also > from Bioconductor core) or have any questions. > > Thank you, > Johannes Rainer > > 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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel__%3B!!PxiZbSOawA!KyRp-e3er_j2IaXihvGE890iBaVn3BQgG6xwKWyaQaInWDt2geeRyBxAPIe-6vxBrEKEimI0B8zwZbQgov0yMe7Il0KFHVtn%24=05%7C01%7Cjennifer.wokaty%40sph.cuny.edu%7C76b7f746d2f5458f9cbe08dbbe965b15%7C6f60f0b35f064e099715989dba8cc7d8%7C0%7C0%7C638313325236054652%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=nb01Mwqu7SY%2FDc7Bbc1PAKyTKtGoe%2FjV7oovbvfNaNg%3D=0<https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/bioc-devel__;!!PxiZbSOawA!KyRp-e3er_j2IaXihvGE890iBaVn3BQgG6xwKWyaQaInWDt2geeRyBxAPIe-6vxBrEKEimI0B8zwZbQgov0yMe7Il0KFHVtn$> > > [[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
Re: [Bioc-devel] Empty DataFrame Causes SummarizedExperiment Constructor Error
On 5/17/23 23:59, Robert Castelo wrote:
not sure whether this is relevant, but I observed that while an empty
base R 'data.frame()' constructor gives zero-length character vectors
for row and column names, the empty 'DataFrame()' constructor gives
also a zero-length character vector for column names, but NULL for row
names, shouldn't this be consistent with base R 'data.frame()'?
dimnames(data.frame())
[[1]]
character(0)
[[2]]
character(0)
dimnames(DataFrame())
[[1]]
NULL
[[2]]
character(0)
This is a feature. Handling of the rownames of a DataFrame deviates from
data.frame as documented in ?DataFrame.
H.
robert.
On 5/17/23 20:45, Hervé Pagès wrote:
Not sure why the colData default is DataFrame(). Seems like this has
been the default since the birth of the SummarizedExperiment class
back in 2010 (FWIW the class was born in the GenomicRanges package).
Anyways, it should probably be NULL, like for rowData. Can you please
open an issue on GitHub for this? Thanks
H.
On 5/12/23 07:00, Dario Strbenac via Bioc-devel wrote:
Good day,
The default value of colData is DataFrame(). Not specifying an
informative colData is fine.
countsMini <- matrix(rpois(100, 100), ncol = 10)
colnames(countsMini) <- paste("Cell", 1:10)
rownames(countsMini) <- paste("Gene", 1:10)
SummarizedExperiment(assays = list(counts = countsMini)) # Creates
the object successfully.
But, explicitly specifying an empty DataFrame triggers an error. I
don't understand why it is not equivalent to the constructor's default.
SummarizedExperiment(assays = list(counts = countsMini), colData =
DataFrame())
Error in `rownames<-`(`*tmp*`, value =
.get_colnames_from_first_assay(assays)) :
invalid rownames length
What is the subtle difference? It also seems like there could be a
clearer error message emitted if this is caught in the right place.
--
Dario Strbenac
University of Sydney
Camperdown NSW 2050
Australia
___
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
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] issue with .local() hack used in S4 methods
On 5/19/23 14:37, Martin Maechler wrote:
Could you file a bug at R's bugzilla?
{I know we have too many open bugs there, notably related to S4,
but still you'd do a service to the R community.}
Done: https://bugs.r-project.org/show_bug.cgi?id=18538
Cheers,
H.
--
Hervé Pagès
Bioconductor Core Team
hpages.on.git...@gmail.com
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] issue with .local() hack used in S4 methods
oops, wrong list sorry. I meant to send this to the R-devel list. Done now.
@Martin FWIW I worked around this by keeping the ellipsis in the arg
list of the method:
> setMethod("foo", "raw", function(x, y=-5, ..., z=22) y)
> selectMethod("foo", "raw")
Method Definition:
function (x, ..., z = 22)
{
.local <- function (x, y = -5, ..., z = 22)
y
.local(x, ..., z = z)
}
Signatures:
x
target "raw"
defined "raw"
> foo(raw(1))
[1] -5
Best,
H.
On 5/19/23 14:37, Martin Maechler wrote:
Hervé Pagès
on Fri, 19 May 2023 11:43:50 -0700 writes:
> Hi,
> Just ran across this:
> foo <- function(x, ..., z=22) z
> setMethod("foo", "character", function(x, y=-5, z=22) y)
> # Creating a generic function from function ‘foo’ in the global
> environment
> Then:
> foo("a")
> # [1] 22
> Should return -5, not 22.
> That's because the call to .local() used internally by the foo() method
> does not name the arguments placed after the ellipsis:
>> selectMethod("foo", "character")
> Method Definition:
> function (x, ..., z = 22)
> {
> .local <- function (x, y = 5, z = 22)
> y
> .local(x, ..., z) <--- should be .local(x, ..., z=z)
> }
> Thanks,
> H.
>> sessionInfo()
> R version 4.3.0 (2023-04-21)
[...]
I can confirm this *bug* (also in R 4.2.z, R 4.1.z, R 3.6.3).
One might be tempted to say this falls into the
"Doctor, it hurts when I do this --- then, don't do that!"
category.
Maybe a simple way to fix the would be to forbid the '...'
in S4 generics and methods apart from at the end,
or then make sure that after the ... in the .local() call, all
argument must be named {{as you suggest above}}.
Could you file a bug at R's bugzilla?
{I know we have too many open bugs there, notably related to S4,
but still you'd do a service to the R community.}
Best,
Martin
> --
> Hervé Pagès
> Bioconductor Core Team
> hpages.on.git...@gmail.com
> ___
> 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
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] issue with .local() hack used in S4 methods
Hi,
Just ran across this:
foo <- function(x, ..., z=22) z
setMethod("foo", "character", function(x, y=-5, z=22) y)
# Creating a generic function from function ‘foo’ in the global
environment
Then:
foo("a")
# [1] 22
Should return -5, not 22.
That's because the call to .local() used internally by the foo() method
does not name the arguments placed after the ellipsis:
> selectMethod("foo", "character")
Method Definition:
function (x, ..., z = 22)
{
.local <- function (x, y = 5, z = 22)
y
.local(x, ..., z) <--- should be .local(x, ..., z=z)
}
Thanks,
H.
> sessionInfo()
R version 4.3.0 (2023-04-21)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 23.04
Matrix products: default
BLAS: /home/hpages/R/R-4.3.0/lib/libRblas.so
LAPACK: /home/hpages/R/R-4.3.0/lib/libRlapack.so; LAPACK version 3.11.0
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
time zone: America/Los_Angeles
tzcode source: system (glibc)
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_4.3.0 codetools_0.2-19
--
Hervé Pagès
Bioconductor Core Team
hpages.on.git...@gmail.com
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Empty DataFrame Causes SummarizedExperiment Constructor Error
Not sure why the colData default is DataFrame(). Seems like this has
been the default since the birth of the SummarizedExperiment class back
in 2010 (FWIW the class was born in the GenomicRanges package). Anyways,
it should probably be NULL, like for rowData. Can you please open an
issue on GitHub for this? Thanks
H.
On 5/12/23 07:00, Dario Strbenac via Bioc-devel wrote:
Good day,
The default value of colData is DataFrame(). Not specifying an informative
colData is fine.
countsMini <- matrix(rpois(100, 100), ncol = 10)
colnames(countsMini) <- paste("Cell", 1:10)
rownames(countsMini) <- paste("Gene", 1:10)
SummarizedExperiment(assays = list(counts = countsMini)) # Creates the object
successfully.
But, explicitly specifying an empty DataFrame triggers an error. I don't
understand why it is not equivalent to the constructor's default.
SummarizedExperiment(assays = list(counts = countsMini), colData = DataFrame())
Error in `rownames<-`(`*tmp*`, value = .get_colnames_from_first_assay(assays)) :
invalid rownames length
What is the subtle difference? It also seems like there could be a clearer
error message emitted if this is caught in the right place.
--
Dario Strbenac
University of Sydney
Camperdown NSW 2050
Australia
___
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
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] S4 Methods Documentation Convention Triggers Warnings
Thanks Deepayan. H. On 30/03/2023 02:32, Deepayan Sarkar wrote: R-devel and R-4-3-branch both now have the option of suppressing these warnings by setting _R_CHECK_RD_ALLOW_EMPTY_ITEM_IN_DESCRIBE_=true But please note this is only intended to be a stop-gap measure, and will likely be removed at some point. Best, -Deepayan On Mon, Jan 30, 2023 at 12:02 PM Hervé Pagès wrote: On 28/01/2023 19:42, Deepayan Sarkar wrote: ... I'm open to suppressing the warning for \describe items (the warning is more important for \arguments). Let me know. Hi Deepayan, suppressing the warning for \describe would kind of make sense. Thanks for the offer. Best, H. -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] rowSums, colSums, rowMeans, colMeans generics moved from BiocGenerics to MatrixGenerics
Hi developers, A couple of days ago I moved the rowSums, colSums, rowMeans, colMeans generics from *BiocGenerics* to *MatrixGenerics*, and this seems to break a lot of packages on today's build report for devel, sorry for that. I didn't have time to look closely at the damage caused by this change yet, but will do it in a few days and repair as much as possible. The fix is very simple. Packages that explicitly import these generrics from BiocGenerics now need to import them from *MatrixGenerics* (they are in *MatrixGenerics* >= 1.11.1). However, a lot of packages also fail because they depend directly or indirectly on a package that tries to import these generics from the old place. In this case, there's not much to do, these packages will auto-repair when the packages they depend on get fixed. Sorry for the inconvenience and let me know if you have any questions. Cheers, H. [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] surfaltr build on Bioc 3.17 error advice
Hi Pooja, Looks like std::auto_ptr is no longer valid in C++17: https://stackoverflow.com/questions/69116001/how-do-i-re-enable-c17-removed-features-in-clang Weird thing is that the compiler is invoked with -std=gnu++17 on all platforms but compilation of msa only fails on Mac. It looks like using -D_LIBCPP_ENABLE_CXX17_REMOVED_FEATURES instead of -D_HAS_AUTO_PTR_ETC=1 in msa/src/ClustalW/msaMakefile solves the "no template named 'auto_ptr'" problem, but then compilation fails later with: fileInput/FileParser.cpp:56:5: error: ISO C++17 does not allow 'register' storage class specifier [-Wregister] register int i; ^ which is easy enough to fix by just removing the few occurrences of the 'register' keyword in ClustalW source code. With these small adjustments I manage to have the embedded ClustalW to compile on merida1. I don't know about the embedded ClustalOmega and Muscle though, they might need some similar adjustments too. Best, H. On 24/03/2023 08:26, Pooja Gangras wrote: > Hi Hervé, > > I reached out to Ulrich who is the maintainer for msa package. He > found your suggestions very helpful and used the option 2 you > suggested to fix the error. Looks like the changes he made have fixed > everything on windows and Linux platforms but the macOS platform is > still showing an error message. > > http://bioconductor.org/checkResults/devel/bioc-LATEST/msa/merida1-buildsrc.html > > Any ideas on how to fix this? > > Thank you so much for all your help!! > > Pooja > > On Tue, Mar 21, 2023, 4:50 PM Hervé Pagès > wrote: > > On 21/03/2023 12:48, Pooja Gangras wrote: > >> Hi Herve, >> >> Thank you for the quick response. >> >> So what surprises me is that msa was compiling and building just >> fine on the devel branch until now. > As I said, the switch from C++14 to C++17 happened not too long > ago in the devel version of R. And since we recently updated R on > the BioC 3.17 builders to the most recent R devel, that switch is > now reflected on the 3.17 builds. >> And hence so was surfaltr, without any errors. There was a >> warning in surfaltr which one can see on the 3.16 release, I had >> fixed it in the devel branch. For some reason I was not able to >> push changes to the existing 3.16 release branch. > That's a separate issue but if you provide more details about how > you tried to do this and what happened, maybe someone on this list > will be able to help. >> >> I will go ahead and contact the maintainer for msa but hoping >> that it will fix itself before release because it was just fine >> until yesterday. > > Unfortunately it won't fix itself. > > H. > >> >> Thanks, >> Pooja >> >> On Tue, Mar 21, 2023, 2:43 PM Hervé Pagès >> wrote: >> >> Hi Pooja, >> >> Generally speaking there are 3 things you can do when a dep >> breaks your >> package: >> >> 1. Consider getting rid of that dep. >> >> 2. Contact the author/maintainers of the dep to let them know >> about the >> problem. If you can suggest a fix (e.g. by sending a PR on >> GitHub), >> that's even better, as I'm sure it will help get the issue >> resolved more >> quickly. >> >> 3. Do nothing and hope that the dep will get fixed in time >> for the 3.17 >> release (scheduled for end of April, see our release schedule >> here >> https://bioconductor.org/developers/release-schedule/ for the >> details). >> But that's risky ;-) >> >> In the case of msa's compilation error, it seems to be due to >> the R >> developers switching to the C++17 compiler by default for C++ >> package >> code in recent version of R devel (4.3 series). This is >> documented in >> the R devel NEWS file here: >> https://cran.r-project.org/doc/manuals/r-devel/NEWS.html >> >> Note that BioC 3.16 is based on R 4.2 which uses the C++14 >> compiler by >> default for C++ package code. Therefore, in BioC 3.16, msa >> compiles fine >> on all platforms: >> https://bioconductor.org/checkResults/3.16/bioc-LATEST/msa/ >> >> So one option for the msa folks is to stick to the C++14 >> compiler by >> adding C++14 to they 'SystemRequirements' field. Although I >> d
Re: [Bioc-devel] download stats not accessible
Download stats are finally back and updated: https://bioconductor.org/packages/stats/ Sorry that it took a little bit longer than anticipated. Cheers, H. On 21/03/2023 09:39, Luo Weijun wrote: > Thanks for the clarification. I have a analytics plot, which receives > the download stats from these pages and has not been updated for > months. I thought this is the cause, but could be something else. > Anyway, thanks for working on the problem. > Weijun > > > > On Monday, March 20, 2023, 01:06:26 PM EDT, Sarvesh Nikumbh > wrote: > > > While I too wondered why the OP mentions unavailability "for months", > now re-reading the OP's email, may be they meant "for months" > granularity which is (now temporarily un)available! :D > > Cheers, > Sarvesh > > On Mon, 20 Mar 2023 at 16:50, Hervé Pagès > wrote: > > Not for months, only since last week. They should be back in the next > 12-18 hours. Thanks for reporting this. > > Cheers, > > H. > > On 19/03/2023 11:00, Luo Weijun wrote: > > Dear BioC team, > > I noticed that download stats for BioC packages are not > accessible for months: > > https://bioconductor.org/packages/stats/bioc/pathview/ > > https://bioconductor.org/packages/stats/bioc/BiocGenerics/ > > > > can you check on this? thanks. > > Weijun Luo > > -- > Hervé Pagès > > Bioconductor Core Team > hpages.on.git...@gmail.com > > ___ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > > > > -- > > thanks! > > -Sarvesh > > > Q: Why is this email five sentences or less? > A: http://five.sentenc.es > > -- 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
Re: [Bioc-devel] surfaltr build on Bioc 3.17 error advice
On 21/03/2023 12:48, Pooja Gangras wrote: > Hi Herve, > > Thank you for the quick response. > > So what surprises me is that msa was compiling and building just fine > on the devel branch until now. As I said, the switch from C++14 to C++17 happened not too long ago in the devel version of R. And since we recently updated R on the BioC 3.17 builders to the most recent R devel, that switch is now reflected on the 3.17 builds. > And hence so was surfaltr, without any errors. There was a warning in > surfaltr which one can see on the 3.16 release, I had fixed it in the > devel branch. For some reason I was not able to push changes to the > existing 3.16 release branch. That's a separate issue but if you provide more details about how you tried to do this and what happened, maybe someone on this list will be able to help. > > I will go ahead and contact the maintainer for msa but hoping that it > will fix itself before release because it was just fine until yesterday. Unfortunately it won't fix itself. H. > > Thanks, > Pooja > > On Tue, Mar 21, 2023, 2:43 PM Hervé Pagès > wrote: > > Hi Pooja, > > Generally speaking there are 3 things you can do when a dep breaks > your > package: > > 1. Consider getting rid of that dep. > > 2. Contact the author/maintainers of the dep to let them know > about the > problem. If you can suggest a fix (e.g. by sending a PR on GitHub), > that's even better, as I'm sure it will help get the issue > resolved more > quickly. > > 3. Do nothing and hope that the dep will get fixed in time for the > 3.17 > release (scheduled for end of April, see our release schedule here > https://bioconductor.org/developers/release-schedule/ for the > details). > But that's risky ;-) > > In the case of msa's compilation error, it seems to be due to the R > developers switching to the C++17 compiler by default for C++ package > code in recent version of R devel (4.3 series). This is documented in > the R devel NEWS file here: > https://cran.r-project.org/doc/manuals/r-devel/NEWS.html > > Note that BioC 3.16 is based on R 4.2 which uses the C++14 > compiler by > default for C++ package code. Therefore, in BioC 3.16, msa > compiles fine > on all platforms: > https://bioconductor.org/checkResults/3.16/bioc-LATEST/msa/ > > So one option for the msa folks is to stick to the C++14 compiler by > adding C++14 to they 'SystemRequirements' field. Although I don't > know > how that would play with Rcpp which gets compiled with the C++17 > compiler, and which they depend on. So maybe that's a little bit > risky? > Maybe something to check with the Rcpp experts. > > Best, > > H. > > On 21/03/2023 09:18, Pooja Gangras wrote: > > Hi, > > > > I got an email yesterday alerting me of the error in the build > in the new > > BioC release. Upon looking into the error further I found out > that the > > error is occurring because a dependency 'msa' package is not > being built in > > the new release likely due to some issues with the C++ compiler > (just > > guessing here). > > > > Can you please advice on next steps? Is there anything I need to > do here? > > > > Thanks for your help, > > Pooja > > > > [[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 > -- 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
Re: [Bioc-devel] surfaltr build on Bioc 3.17 error advice
Hi Pooja, Generally speaking there are 3 things you can do when a dep breaks your package: 1. Consider getting rid of that dep. 2. Contact the author/maintainers of the dep to let them know about the problem. If you can suggest a fix (e.g. by sending a PR on GitHub), that's even better, as I'm sure it will help get the issue resolved more quickly. 3. Do nothing and hope that the dep will get fixed in time for the 3.17 release (scheduled for end of April, see our release schedule here https://bioconductor.org/developers/release-schedule/ for the details). But that's risky ;-) In the case of msa's compilation error, it seems to be due to the R developers switching to the C++17 compiler by default for C++ package code in recent version of R devel (4.3 series). This is documented in the R devel NEWS file here: https://cran.r-project.org/doc/manuals/r-devel/NEWS.html Note that BioC 3.16 is based on R 4.2 which uses the C++14 compiler by default for C++ package code. Therefore, in BioC 3.16, msa compiles fine on all platforms: https://bioconductor.org/checkResults/3.16/bioc-LATEST/msa/ So one option for the msa folks is to stick to the C++14 compiler by adding C++14 to they 'SystemRequirements' field. Although I don't know how that would play with Rcpp which gets compiled with the C++17 compiler, and which they depend on. So maybe that's a little bit risky? Maybe something to check with the Rcpp experts. Best, H. On 21/03/2023 09:18, Pooja Gangras wrote: Hi, I got an email yesterday alerting me of the error in the build in the new BioC release. Upon looking into the error further I found out that the error is occurring because a dependency 'msa' package is not being built in the new release likely due to some issues with the C++ compiler (just guessing here). Can you please advice on next steps? Is there anything I need to do here? Thanks for your help, Pooja [[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 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] download stats not accessible
Not for months, only since last week. They should be back in the next 12-18 hours. Thanks for reporting this. Cheers, H. On 19/03/2023 11:00, Luo Weijun wrote: Dear BioC team, I noticed that download stats for BioC packages are not accessible for months: https://bioconductor.org/packages/stats/bioc/pathview/ https://bioconductor.org/packages/stats/bioc/BiocGenerics/ can you check on this? thanks. Weijun Luo -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Openssl is not available in netConnectHttps for importing remote BigWig files
selection = reduce(range), as = "RleList")
1:
rtracklayer::import("https://urldefense.proofpoint.com/v2/url?u=http-3A__sciserver.org_public-2Ddata_recount2_data_SRP002001_bw_mean-5FSRP002001.bw=DwIFaQ=mRWFL96tuqj9V0Jjj4h40ddo0XsmttALwKjAEOCyUjY=FKSqKXkUOES-D4VQb2jSn9QK7Vz5lE18rLcyn73CPhA=BRxpnUxOEpNwBnvNz7_tvWT-eQ3eQOVrI6k5vXKWROddWJMxFsDhKTp5JOelaIM_=F0oFWXFFxsylMqc00YZ05rFgLzkkocPevscWyQc=
",
selection = reduce(range), as = "RleList")
packageVersion("rtracklayer")
[1] �1.58.0�
I'm not sure what else I can do to help. As noted at
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_lawremi_rtracklayer_issues_83-23issuecomment-2D1437585161=DwIFaQ=mRWFL96tuqj9V0Jjj4h40ddo0XsmttALwKjAEOCyUjY=FKSqKXkUOES-D4VQb2jSn9QK7Vz5lE18rLcyn73CPhA=BRxpnUxOEpNwBnvNz7_tvWT-eQ3eQOVrI6k5vXKWROddWJMxFsDhKTp5JOelaIM_=fZTgbHR5Wn0VJkseyYfOtokJM5Xe__FMapkwjbUze04=
,
recount / rtracklayer versions from BioC 3.11 do work with the same
links.
Thanks in advance.
Best,
Leo
Leonardo Collado Torres, Ph. D.
Investigator
LIEBER INSTITUTE for BRAIN DEVELOPMENT
855 N. Wolfe St., Suite 300
Baltimore, MD 21205
lcolladotor.github.io
lcollado...@gmail.com
___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIFaQ=mRWFL96tuqj9V0Jjj4h40ddo0XsmttALwKjAEOCyUjY=FKSqKXkUOES-D4VQb2jSn9QK7Vz5lE18rLcyn73CPhA=BRxpnUxOEpNwBnvNz7_tvWT-eQ3eQOVrI6k5vXKWROddWJMxFsDhKTp5JOelaIM_=zjoOkX2-XpaR-_jfe7tHgtDLKlyMDnfppaDy0EInzP4=
[[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
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] name for new BioC package
Hi Matteo. We had DESeq2 after DESeq, Rbowtie2 after Rbowtie, MOFA2 after MOFA, etc.. so I don't see any problem, but thanks for asking! Best, H. On 03/02/2023 00:08, Matteo Tiberti wrote: dear maintainers, I am currently listed as maintainer of Bioconductor package MoonlightR, designed for the prediction of cancer driver genes, which implements the Moonlight workflow. We are currently working on a second version of our workflow, called Moonlight2, and would like to have it released on Bioconductor as well, in form of the Moonlight2R package. The new package uses similar principles as the current one, but will have significant changes and updates, both in terms of new functionality and revision of old functionalities. The Moonlight2R project/paper will also have in part a different corresponding authorship respect to the current one. MoonlightR and Moonlight2R currently reside in two separate GitHub repositories. Ideally we would like to have both packages on BioConductor for the moment, the old one (called MoonlightR) and the new one that we intend to submit before the April cut-off for 3.17 (called Moonlight2R), where the number signifies the version of the protocol rather than the software. However on the package submission list, I see that having package names that "imply a temporal relationship" respect to an existing package is discouraged. Given the circumstances, do you think it would be possible to use the Moonlight2R name for the package (i.e. would it be a reason for rejection or object of revision during submission) or is it fair to keep it as is? Many thanks Matteo Tiberti Danish Cancer Society Research Center Strandboulevarden 49 DK-2100 Copenhagen Telephone: +45 35 25 73 07 [https://i.xink.io/Images/Get/K116/d1.png]<https://www.cancer.dk/?utm_source=email_medium=medarbejderemail_campaign=medarbejderemail_content=cancerdk> www.cancer.dk<https://www.cancer.dk/international/> | Vores privatlivspolitik<https://www.cancer.dk/om-os/privatlivspolitik/> [[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 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] S4 Methods Documentation Convention Triggers Warnings
On 28/01/2023 19:42, Deepayan Sarkar wrote: ... I'm open to suppressing the warning for \describe items (the warning is more important for \arguments). Let me know. Hi Deepayan, suppressing the warning for \describe would kind of make sense. Thanks for the offer. Best, H. -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] S4 Methods Documentation Convention Triggers Warnings
On 27/01/2023 02:00, Dario Strbenac via Bioc-devel wrote:
Good day,
So, is the ultimate solution to manually change everything to the format of
\item{\code{show(x)}:}{
...
} ?
I think I will do this in my own packages. Still need to make those
changes though, just didn't have time to work on a script to automate this.
The warnings persist, so it does not seem as though R will revert to allowing
the currently-popular syntax past its check.
I don't see that anybody complained about this on R-devel, so they don't
really have a reason to revert.
H.
--
Dario Strbenac
University of Sydney
Camperdown NSW 2050
Australia
___
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
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Warnings in "checking compiled code" of R CMD check
Hi Oleksii, I was contacted off-list by the maintainer of the FLAMES package about this. The FLAMES package has the same "checking compiled code" WARNING. I'm just copying my answer below. Best, H. - Yes the warning for the C code in Rhtslib actually propagates to any package that is linked to Rhtslib (via the LinkingTo field). See for example the CHECK result for Rsamtools: https://bioconductor.org/checkResults/3.17/bioc-LATEST/Rsamtools/nebbiolo1-checksrc.html This is because Rsamtools.so and FLAMES.so are statically linked to Rhtslib, so even if the C code in Rsamtools and FLAMES don't use these forbidden symbols, they still end up in Rsamtools.so and FLAMES.so. Nothing can be done on Rsamtools' or FLAMES' side about this, except using dynamic linking. But this is discouraged because it introduces a whole set of other problems. So a proper solution would need to originate in the Rhtslib package itself. However note that these symbols are not known to actually cause problems in practice so the situation is not that bad. All this to say that it's ok to ignore the warning for FLAMES. Thanks for your contribution to Bioconductor. - On 26/01/2023 06:00, Oleksii Nikolaienko wrote: > 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 > <http://bioconductor.org/checkResults/devel/bioc-LATEST/Rsamtools/nebbiolo1-checksrc.html> > 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 -- 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
Re: [Bioc-devel] Support for Linux ARM64
On 05/01/2023 18:52, Vincent Carey wrote: > > > On Thu, Jan 5, 2023 at 7:08 PM Vincent Carey > wrote: > > > > On Thu, Jan 5, 2023 at 1:44 PM Hervé Pagès > wrote: > > Hi Martin, > > Linux runs on many architectures, ARM64 is just one of them. > > Our daily builds have traditionally focused on 3 platforms: > Intel-based > Linux (Ubuntu 22.04), Windows, and Intel-based Mac. Note that we > recently added ARM64-based Mac to our daily builds. > > One big difference between Linux and the other platforms is > that we only > produce binary packages for the latter. More precisely: > > - on the Linux builders: the daily builds only run 'R CMD > INSTALL', 'R > CMD build', and 'R CMD check', on each Bioconductor package, > > - on the Windows and Mac builders: the daily builds run all > the above > plus an additional step that we call the BUILD BIN step that > produces a > binary for each Bioconductor package. > > This means that on Linux, as well as on any other Unix-like OS > that is > not macOS (e.g. FreeBSD, OpenBSD, Solaris, HP-UX, etc...), > users will > install all their packages (Bioconductor and CRAN) **from > source**. This > should work as long as they are on a platform where R is > supported and > have the required compilers (C, C++, and Fortran). > > Note that if officially supporting a given platform means > running the > daily builds on that particular platform, then there's no way > for us to > do that because platform == OS + architecture, and the list of > combinations of Unix-like OS's (Linux, FreeBSD, Solaris, > etc...) + > architectures (Intel, ARM64, Sparc, powerpc) is endless. Even > if we > narrow this list to Intel-based Linux, there are hundreds of > Linux > distributions around that use different kernel, compilers, > package > managers, etc... > > All this to say that, as far as the daily builds are > concerned, we had > to make choices, and those choices are based on the most > commonly used > platforms. Since all Bioconductor packages are tested daily on > Intel-based Linux (Ubuntu 22.04), Windows, Intel-based Mac, and > ARM64-based Mac, we have some reasonable confidence that they > will work > properly on these 4 platforms (still not a 100% guarantee of > course, > there's nothing like that). > > My understanding is that ARM64-based Linux is still a > marginally used > platform so probably not worth for us to allocate resources on > adding it > to our daily builds at the moment. If it ever becomes more > mainstream in > the future, then we will certainly reconsider. That does not > mean that > you can't use Bioconductor on a ARM64-based Linux machine > **now**. I see > no reason a priori why you couldn't install (from source) > Bioconductor > packages on this platform, and use them, as long as: > > > Thanks Hervé for a good overview of the issues. I think there are > a couple > of reasons to keep this dialogue going (and there is now a > community slack channel > for further discussion: #arm-linux at community-bioc.slack.com > <http://community-bioc.slack.com>.) > > The first reason is Martin's offer of resources to accomplish the > support aim. What > exactly that support aim is remains to be made precise. As you > note, a properly > configured system with R can use BiocManager::install to build > from source, but > there are a few additional things that can be done to produce > binaries, and perhaps > some of our software in BBS or some of the binary repo generation > tools could be > useful for Martin's group to make a relevant binary repo. The > package-management > oriented process of Dirk Eddelbuettel's r2u > <https://github.com/eddelbuettel/r2u> also seems potentially > relevant. We also > have tooling to build all the CRAN dependencies that Bioc packages > declare. This > is all in the open and it would be interesting to see how much > work is needed to > get solutions for ARM64 linux. It could lead to some > robustification of the existing > build machinery. I am not offering to do it, but the fact
Re: [Bioc-devel] Support for Linux ARM64
Hi Martin, Linux runs on many architectures, ARM64 is just one of them. Our daily builds have traditionally focused on 3 platforms: Intel-based Linux (Ubuntu 22.04), Windows, and Intel-based Mac. Note that we recently added ARM64-based Mac to our daily builds. One big difference between Linux and the other platforms is that we only produce binary packages for the latter. More precisely: - on the Linux builders: the daily builds only run 'R CMD INSTALL', 'R CMD build', and 'R CMD check', on each Bioconductor package, - on the Windows and Mac builders: the daily builds run all the above plus an additional step that we call the BUILD BIN step that produces a binary for each Bioconductor package. This means that on Linux, as well as on any other Unix-like OS that is not macOS (e.g. FreeBSD, OpenBSD, Solaris, HP-UX, etc...), users will install all their packages (Bioconductor and CRAN) **from source**. This should work as long as they are on a platform where R is supported and have the required compilers (C, C++, and Fortran). Note that if officially supporting a given platform means running the daily builds on that particular platform, then there's no way for us to do that because platform == OS + architecture, and the list of combinations of Unix-like OS's (Linux, FreeBSD, Solaris, etc...) + architectures (Intel, ARM64, Sparc, powerpc) is endless. Even if we narrow this list to Intel-based Linux, there are hundreds of Linux distributions around that use different kernel, compilers, package managers, etc... All this to say that, as far as the daily builds are concerned, we had to make choices, and those choices are based on the most commonly used platforms. Since all Bioconductor packages are tested daily on Intel-based Linux (Ubuntu 22.04), Windows, Intel-based Mac, and ARM64-based Mac, we have some reasonable confidence that they will work properly on these 4 platforms (still not a 100% guarantee of course, there's nothing like that). My understanding is that ARM64-based Linux is still a marginally used platform so probably not worth for us to allocate resources on adding it to our daily builds at the moment. If it ever becomes more mainstream in the future, then we will certainly reconsider. That does not mean that you can't use Bioconductor on a ARM64-based Linux machine **now**. I see no reason a priori why you couldn't install (from source) Bioconductor packages on this platform, and use them, as long as: - R is supported on your ARM64-based Linux machine - you have compilers that are supported by R - you have the external libraries that are required by some CRAN and/or Bioconductor packages. Hope this helps, H. On 05/01/2023 02:01, Martin Grigorov wrote: Dear community, Happy and successful new year! Appologies if this has been discussed before but https://stat.ethz.ch/pipermail/bioc-devel/ does not provide search facilities and my googling didn't help much! I'd like to ask whether Linux ARM64 is officially supported ? I know that Mac ARM64 is supported since 3.16 [1] [2]. I cannot find such test results for Linux ARM64 and the site search [3] also mentions "arm64" only in context of "macOS". In addition the Docker images are also single-platform [4] (linux/amd64). How can we help to add support for Linux ARM64 ? My employer is willing to donate VMs and man power if the community is interested in adding support for Linux ARM64! Regards, Martin 1. https://bioconductor.org/news/bioc_3_16_release/ 2. https://bioconductor.org/checkResults/3.17/bioc-mac-arm64-LATEST/ 3. https://bioconductor.org/help/search/index.html?q=arm64/ 4. https://hub.docker.com/r/bioconductor/bioconductor_docker/tags [[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 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] data extension preference
Agree with Lori. If you have tabulated data, csv is better than rda because it's plain text and can easily be imported by many software, not just R. People can also use an editor or command line tool like grep or head to inspect the file. OTOH rda/rds files are R specific so can only be used within the R ecosystem. Furthermore these are binary formats so not as practical as plain text. If size is an issue, you can always compress the csv file (-> csv.gz). H. On 03/01/2023 08:24, Kern, Lori wrote: Personally: I think it depends on the use case and the type of data being provided as well as the size. Raw data is probably more adaptable for various usage even extending beyond expected use however it can be large; processed data can be saved compressed and greatly reduce package/data size. Again it will largely depend on what you are doing with the data provided. 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 Park, Adam Keebum Sent: Wednesday, December 21, 2022 11:42 PM To: bioc-devel@r-project.org Subject: [Bioc-devel] data extension preference Dear whom it may concern, I want to check if reviewers have a preference in data formats for data included in a package. Is rda strongly recommended over csv? Sincerely, Adam. [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://secure-web.cisco.com/1TPdwAVqVZuSe4StGWM5cZ069tkkEd2TzRyilsxSECEjqUKvno8Zdb1ADlxRO16lYeghEAcxQKUbYlHrN2KDXvokdAcDZyHHQnbzpmvtEdR5-LnOnPQTBydfgzsrqt_wvHLCCkfIR2dca1h0yDT6Tx8KsV-vXAoxjLyP0YTvVpcrOsqRabwJF7P7y5ntz29eeFVAqTNjXA6XilRqlKO8HMidxVRRAWSypOTO7X1oscKhmxUKWQgBLGrn9p8rF7XA9tjsaOAg5-1kEcC4Cbqu0T7qqPX0bGD1spEdDqAv2q2Vz-Cpwm-xniK7e7w7xeI5J/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 -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] How to deal with external software dependencies
Hi Ran, First of all, please note that direct calls to external commands via system() or system2() are not ideal so should only be used when there is no other alternative. For example, if a CRAN or Bioconductor package already provides the functionality that you are after, you should use that instead. Now if your package **absolutely** must rely on external software then you need to make sure that those requirements are listed in the SystemRequirements field of the DESCRIPTION file of the package. These requirements should be "reasonable" requirements, that is, trusted software only, open source, and relatively easy to install. Additionally we ask that the package contains an INSTALL file (in the top-level folder) that provides instructions for installing the external software on the 3 major OS that we support: Linux, Windows, and Mac. This will not only help your users get the external software on their machines, but it will also help us install it on the build machines if it's not already there. May I ask what those external tools are? Thanks, H. On Mon, Dec 19, 2022 at 3:13 PM RAN HU wrote: > Hi all, > > I am developing a new R package that relies on some external software. > There are some system calls written in the R function that requires the > path to those external software tools. > > I am not sure what is the best practice to using external software in R > Bioconductor packages. If the external software paths are required for the > functions to run successfully, will the package fail the BiocCheck? > > Any suggestions would be appreciated and thank you in advance for your > help!!! > > Best, > Ran > > [[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] SpatialExperiment checks fail on Windows platform
Hi Dario,
Note that we observe the same problem on our daily Windows builder, so
this has not much to do with your GitHub actions setup:
https://bioconductor.org/checkResults/3.17/bioc-LATEST/SpatialExperiment/palomino3-buildsrc.html
It looks to me that some recent changes to the package broke the dim()
method for StoredSpatialImage objects. Here is how the method is defined
in BioC devel:
> selectMethod("dim", "StoredSpatialImage")
Object with tracing code, class "MethodDefinitionWithTrace"
Original definition:
Method Definition:
function (x)
{
src <- imgSource(x)
src <- normalizePath(src)
src <- paste0("file://", src)
img <- .get_from_cache(src, NULL)
if (!is.null(img))
return(dim(img))
img <- image_read(src)
tib <- image_info(img)
c(tib$height, tib$width)
}
Signatures:
x
target "StoredSpatialImage"
defined "StoredSpatialImage"
## (to see the tracing code, look at body(object))
I'm not sure I understand the logic for prefixing the already normalized
local path with "file://", but this breaks magick::image_read() on
Windows. Without the "file://" prefix, the dim() method seems to work
fine on all platforms.
Hope this helps,
H.
On 12/12/2022 02:11, Dario Righelli wrote:
Hi everyone,
we are having an issue when running GithubActions on Windows platform
that we are not able to figure out.
The error is about loading an image as a grob during the vignette
construction.
It seems that it loads the image path twice, but this sounds weird
because the same vignette code is working on the other two platforms
(linux and osx).
Does anyone have any ideas about this?
Here it is the reported check error:
Quitting from lines 110-111 (SpatialExperiment.Rmd) Error: processing
vignette 'SpatialExperiment.Rmd' failed with diagnostics: Rscript.exe:
UnableToOpenBlob
`F:\biocbuild\bbs-3.17-bioc\tmpdir\RtmpsN0lzb\Rbuild3f6c3ae24a46\SpatialExperiment\vignettes\file:\F:\biocbuild\bbs-3.17-bioc\tmpdir\RtmpsN0lzb\Rinst3f6c113c6bc2\SpatialExperiment\extdata\10xVisium\section1\outs\spatial\tissue_lowres_image.png':
Invalid argument @ error/blob.c/OpenBlob/2924 --- failed re-building
'SpatialExperiment.Rmd'
Thanks, Dario
[[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
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] error on R CMD check
Hi Zhigang,
We didn't hear back from you. We hope you're seeing those emails.
Note that IFAA should now be removed from CRAN. Please request the
removal as soon as possible.
Also, as mentioned earlier, don't forget to resync the IFAA repo on
GitHub with IFAA's repo on git.bioconductor.org.
Thanks,
H.
On 09/12/2022 14:47, Hervé Pagès wrote:
Hi,
IFAA now passes BUILD and CHECK on all platforms on the BioC 3.17
build report:
https://bioconductor.org/checkResults/3.17/bioc-LATEST/IFAA/
The package is now available in BioC 3.17 via BiocManager::install():
https://bioconductor.org/packages/3.17/IFAA
Except on Windows. But that's because of an issue with an upstream
package on this platform that will hopefully be resolved soon. (Note
that BioC 3.17 users can still install the package from source on
Windows.)
Cheers,
H.
On 07/12/2022 21:54, Hervé Pagès wrote:
Hi,
On 06/12/2022 22:10, Hervé Pagès wrote:
...
Anyways, the version of the Bioconductor package would need to be
bumped to 1.1.1. However you won't be able to push this bump to
git.bioconductor.org because we don't allow this kind of version
bump. So we'll take care of it. We'll let you know when it's done.
This is done. Version 1.1.1 should show up on Friday's build report.
Hopefully without the BiocGenerics:::testPackage("IFAA") error.
Remember to resync the IFAA repo on GitHub with IFAA's repo on
git.bioconductor.org
Best,
H.
Best,
H.
Thanks,
Zhigang
https://sites.google.com/view/zlab
___
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
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] error on R CMD check
Hi,
IFAA now passes BUILD and CHECK on all platforms on the BioC 3.17 build
report:
https://bioconductor.org/checkResults/3.17/bioc-LATEST/IFAA/
The package is now available in BioC 3.17 via BiocManager::install():
https://bioconductor.org/packages/3.17/IFAA
Except on Windows. But that's because of an issue with an upstream
package on this platform that will hopefully be resolved soon. (Note
that BioC 3.17 users can still install the package from source on Windows.)
Cheers,
H.
On 07/12/2022 21:54, Hervé Pagès wrote:
Hi,
On 06/12/2022 22:10, Hervé Pagès wrote:
...
Anyways, the version of the Bioconductor package would need to be
bumped to 1.1.1. However you won't be able to push this bump to
git.bioconductor.org because we don't allow this kind of version
bump. So we'll take care of it. We'll let you know when it's done.
This is done. Version 1.1.1 should show up on Friday's build report.
Hopefully without the BiocGenerics:::testPackage("IFAA") error.
Remember to resync the IFAA repo on GitHub with IFAA's repo on
git.bioconductor.org
Best,
H.
Best,
H.
Thanks,
Zhigang
https://sites.google.com/view/zlab
___
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
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Fwd: Package "SingleCellSignalR" failing on Bioconductor devel
FWIW the compilation error for SIMLR looks like a real error to me, not
a warning-induced one:
tsne.cpp:883:11: error: too few arguments to function ‘void dgemm_(...
It seems to be caused by a change in R-devel. We see it on all platforms
on the daily builds for BioC 3.17 and I also get it on my laptop.
Anybody using a recent R-devel should be able to reproduce it.
Cheers,
H.
On 08/12/2022 05:44, Jacques Colinge wrote:
Dear Vincent,
Thank you very much for this information. The problem should be fixed
now, build and check are successful in R develeopment version. I have
just pushed my fixes onto bioconductor github.
Best regards,
Jacques
On 26.11.2022 12:35, Vincent Carey wrote:
When testing on the devel branch at this time, you must use R-devel (R
4.3). See
https://contributions.bioconductor.org/use-devel.html#use-devel
For SingleCellSignalR, the dependence on SIMLR seems problematic.
SIMLR is in an error state on the devel branch. One
could see that even in the release branch, SIMLR includes some code
that is risky:
* installing to library ‘/home/biocbuild/bbs-3.16-bioc/R/library’
* installing *source* package ‘SIMLR’ ...
** using staged installation
** libs
g++ -std=gnu++14 -I"/home/biocbuild/bbs-3.16-bioc/R/include" -DNDEBUG
-I'/home/biocbuild/bbs-3.16-bioc/R/library/Rcpp/include' -I/usr/local/include -fpic -g
-O2 -Wall -c RcppExports.cpp -o RcppExports.o
g++ -std=gnu++14 -I"/home/biocbuild/bbs-3.16-bioc/R/include" -DNDEBUG
-I'/home/biocbuild/bbs-3.16-bioc/R/library/Rcpp/include' -I/usr/local/include -fpic -g
-O2 -Wall -c Rtsne.cpp -o Rtsne.o
gcc -I"/home/biocbuild/bbs-3.16-bioc/R/include" -DNDEBUG
-I'/home/biocbuild/bbs-3.16-bioc/R/library/Rcpp/include' -I/usr/local/include -fpic -g
-O2 -Wall -c package_init.c -o package_init.o
gcc -I"/home/biocbuild/bbs-3.16-bioc/R/include" -DNDEBUG
-I'/home/biocbuild/bbs-3.16-bioc/R/library/Rcpp/include' -I/usr/local/include -fpic -g
-O2 -Wall -c projsplx_R.c -o projsplx_R.o
g++ -std=gnu++14 -I"/home/biocbuild/bbs-3.16-bioc/R/include" -DNDEBUG
-I'/home/biocbuild/bbs-3.16-bioc/R/library/Rcpp/include' -I/usr/local/include -fpic -g
-O2 -Wall -c sptree.cpp -o sptree.o
g++ -std=gnu++14 -I"/home/biocbuild/bbs-3.16-bioc/R/include" -DNDEBUG
-I'/home/biocbuild/bbs-3.16-bioc/R/library/Rcpp/include' -I/usr/local/include -fpic -g
-O2 -Wall -c tsne.cpp -o tsne.o
tsne.cpp: In member function ‘bool TSNE::load_data(double**, int*, int*, int*,
double*, double*, int*)’:
tsne.cpp:967:48: warning: comparison of integer expressions of different
signedness: ‘size_t’ {aka ‘long unsigned int’} and ‘int’ [-Wsign-compare]
967 | if (fread(*data, sizeof(double), *n * *d, h) != *n * *d) {
| ~^~
but it passed on the release branch. On the devel branch SIMLR fails. The
sources for
SIMLR don't appear to have changed since 2017 (reading git log). So this seems
like a situation
in which a package that has not changed since release fails in devel because
the tolerance of the build system for compiler-flagged warning events has been
reduced.
The developers of SIMLR will need to fix this, or you will have to eliminate
the dependence on
SIMLR from your package. Your favorable results for CMD check arise from a)
not working
in the devel branch and b) having a version of SIMLR that built under
out-of-date warning
tolerance compiler settings. Let us know if there are further questions.
On Sat, Nov 26, 2022 at 6:15 AM Jacques Colinge
wrote:
Dear Johannes,
Dear Bioc Developers,
I am not sure I get the problem. I am currently running R 4.2.1
and if I
do a devtools::check() and a devtools::build() I have no error
(just one
warning), see below both outputs.
Do you need me to install R development version and redo those tests
because with this new versions some errors occur?
Thanks for your answer.
Best regards,
Jacques
--- check() output -
jcolinge@osboxes:~/SingleCellSignalR$ R
R version 4.2.1 (2022-06-23) -- "Funny-Looking Kid"
Copyright (C) 2022 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> library(devtools)
Loading required package: usethis
> devtools::check()
══ Documenting
Re: [Bioc-devel] error on R CMD check
Hi,
On 06/12/2022 22:10, Hervé Pagès wrote:
...
Anyways, the version of the Bioconductor package would need to be
bumped to 1.1.1. However you won't be able to push this bump to
git.bioconductor.org because we don't allow this kind of version bump.
So we'll take care of it. We'll let you know when it's done.
This is done. Version 1.1.1 should show up on Friday's build report.
Hopefully without the BiocGenerics:::testPackage("IFAA") error.
Remember to resync the IFAA repo on GitHub with IFAA's repo on
git.bioconductor.org
Best,
H.
Best,
H.
Thanks,
Zhigang
https://sites.google.com/view/zlab
___
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
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] error on R CMD check
t is happening exactly on the build machines with
BiocGenerics:::testPackage("IFAA") is a slightly more sophisticated
variant of that.
Anyways, the version of the Bioconductor package would need to be bumped
to 1.1.1. However you won't be able to push this bump to
git.bioconductor.org because we don't allow this kind of version bump.
So we'll take care of it. We'll let you know when it's done.
Best,
H.
Thanks,
Zhigang
https://sites.google.com/view/zlab
___
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
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] S4 Methods Documentation Convention Triggers Warnings
Itemizing brings semantics and structure. Plus, the \preformatted
solution doesn't look good either IMO. FWIW I mostly care about what I
see when I open the man page in a terminal with ?. I don't care so
much about the PDF manual, never look at it.
So I'm going to switch from
\item{}{\code{show(x)}:
...
}
to
\item{\code{show(x)}:}{
...
}
as suggested by Henrik.
I actually tried the latter many years ago and compared with the former
and for some reason decided to go for the former. But now I like the
rendering of the latter better. Don't know if it has changed or if my
taste has changed ;-)
Anyways, that's hundreds of \items that I need to fix in a dozen of
packages. Not fun! Also the thing with the exact location of the colon
is very error prone. As Michael said, it would be nice to be able to
achieve this with a simpler/more natural syntax.
H.
On 30/11/2022 10:47, Deepayan Sarkar wrote:
On Wed, Nov 30, 2022 at 9:51 PM Martin Morgan
wrote:
I recently made the change Henrik suggests in the ‘devel’ but not
‘release’ branch of BiocParallel, so the manuals can be compared. Take a
look at the ‘Constructor’ and ‘Accessors: Logging and results’ sections of
the ‘SnowParam-class.Rd’ man page, starting on p. 53 of the PDF.
https://bioconductor.org/packages/release/bioc/manuals/BiocParallel/man/BiocParallel.pdf
https://bioconductor.org/packages/devel/bioc/manuals/BiocParallel/man/BiocParallel.pdf
I think in \item{}{bar} the is not wrapped, so runs off the
margin in the devel ‘Constructor’ section.
This should ideally use \preformatted{}, but R-exts says that "Due to
limitations in LaTeX as of this writing, this macro may not be nested
within other markup macros other than \dQuote and \sQuote, as errors or bad
formatting may result."
Still, in this particular case, and possibly others like it, free-format
text (instead of itemizing) might work better:
\section{Constructor}{
\preformatted{SnowParam(workers = snowWorkers(), type=c("SOCK", "MPI"),
tasks = 0L, stop.on.error = FALSE,
progressbar = FALSE, RNGseed = NULL,
timeout = Inf, exportglobals = TRUE,
exportvariables = TRUE,
log = FALSE, threshold = "INFO", logdir = NA_character_,
resultdir = NA_character_, jobname = "BPJOB",
manager.hostname = NA_character_,
manager.port = NA_integer_,
...)}
Returns an object representing a SNOW cluster. The cluster is not
created until \code{bpstart} is called. Named arguments in \code{...}
are passed to \code{makeCluster}.
}
Even if we retain the status quo, the \item{}{\code{...}{}} version of this
(as in the release branch) is by no means nice-looking.
Best,
-Deepayan
The shorter items in the ‘Accessors: Logging and results’ section look
almost identical, with a little extra (unnecessary) indentation under the
original formatting.
I changed the ‘Accessors: Back-end control’ to an itemized list, since
there was no description associated with each item. This adds bullets.
The commit is at
https://code.bioconductor.org/browse/BiocParallel/commit/4e85b38b92f2adb68fe04ffb0476cbc47c1241a8
(as well as https://github.com/Bioconductor/BiocParallel...)
Martin
From: Bioc-devel on behalf of Martin
Maechler
Date: Wednesday, November 30, 2022 at 6:28 AM
To: Michael Lawrence (MICHAFLA)
Cc: bioc-devel@r-project.org , Kurt Hornik <
kurt.hor...@wu.ac.at>
Subject: Re: [Bioc-devel] S4 Methods Documentation Convention Triggers
Warnings
Michael Lawrence \(MICHAFLA\) via Bioc-devel
on Mon, 28 Nov 2022 12:11:00 -0800 writes:
> It may be worth revisiting why we arrived at this convention in the
first
> place and see whether the Rd system can be enhanced somehow so that
we can
> achieve the same effect with a more natural syntax.
> Michael
Yes, I agree.
It may be that in the distant past, Henrik's suggestion
(a version of which I am using myself a lot in *.Rd -- mostly
*not* related to S4)
did not work correctly, but I know it has worked for years now,
as I use it "all the time".
and not just I.
If I grep in R's *base* package alone,
inside ./R/src/library/base/man/
grep --color -nH --null -e '\\item{\\code{' *.Rd
starts with
agrep.Rd
[[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
--
Hervé Pagès
Bioconductor Core Team
hpages.on.git...@gmail.com
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] palomino4 CHECK error "permission denied" msqrob2
Hi Stijn, Note that today the error is gone. This is a race condition in 'R CMD check' that affects some packages on Windows. What 'R CMD check' is trying to do here is open the msqrob2-Ex.Rout file but that file is still being written to by another process. Windows (unlike Linux or macOS) doesn't like that: it won't let a process open a file if the file is being hold by another process. More precisely here is what is happening here: - One of the checks that 'R CMD check' performs is to run all the examples in a package, and to capture the output produced by the examples in a file (the msqrob2-Ex.Rout in your case). - Once it's done running the examples, 'R CMD check' wants to know if the examples produced errors. It does this by parsing the msqrob2-Ex.Rout file. That's when it tries to open the file in read-only mode. - But sometimes, when 'R CMD check' tries to open msqrob2-Ex.Rout in read-only mode, other processes are still holding on the msqrob2-Ex.Rout file. This typically happens when the examples in the package spawn subprocesses. For example these spawned processes can be the workers spawned by BiocParallel or by other parallel evaluation mechanism (e.g. doParallel/foreach). Note that there can be a very small lag between the moment the main worker and the spawned workers are done. If one of the spawned workers takes a fraction of an extra second to finish writing some output to msqrob2-Ex.Rout, then 'R CMD check' won't be able to open the file. One could argue that this is an issue with 'R CMD check'. Maybe on Windows it should wait a couple of seconds before trying to open msqrob2-Ex.Rout, I don't know. Maybe there's something that could be done in BiocParallel too. I don't know how hard that would be, or if that's even feasible, but maybe there's a way that the main worker could wait and make sure that all the spawn processes are dead before returning. I guess that kind of feature would only make sense for some parallel back-ends. Does some of the examples in msqrob2 use parallelization? If so maybe you can try to add a call to Sys.sleep(2) at the end of those examples and see if that helps. In any case there's nothing that can really be done on our Windows builders to prevent this, sorry. Hope this helps, H. On 28/10/2022 06:29, vandenbulcke stijn wrote: Dear All, On the palomino4 host the check for msqrob2 returns the following error ( http://bioconductor.org/checkResults/devel/bioc-LATEST/msqrob2/palomino4-checksrc.html ) * checking examples ...Warning in file(con, "r") : cannot open file 'msqrob2-Ex.Rout': Permission denied Error in file(con, "r") : cannot open the connection Execution halted I am however not able to reproduce this, and it works on the other hosts. Would anyone know the cause of this issue? Thanks in advance Stijn [[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 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] seqArchR error on build systems
Hi Sarvesh, It looks like reticulate somehow was using the wrong Python instance on nebbiolo2 and lconway, as reported by py_config(). We're now setting RETICULATE_PYTHON on those machines to make sure that reticulate will use the correct Python. This change was made after the builds started today so it won't be reflected on tomorrow's report. But it should be reflected on Thursday's report. We'll do the same on the other build machines soon. Best, H. On 25/10/2022 08:53, Sarvesh Nikumbh wrote: Hi Bioc-team, seqArchR was building fine, without any errors last week, but I am seeing an error again. This time it is due to the Python module 'sklearn' not available and one another error. The sklearn-related error occurs on nebbiolo2 and Iconway, while palomino4 shows a different error. Maybe something changed on the build systems? Because these system requirements were available before*.* Thanks and best, Sarvesh -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] reverting to a previous version
On 19/10/2022 19:48, Jason Ji wrote: > Thanks Hervé, > > I am sorry I am not familiar with the Bioconductor git system. Could > you please advise the code I should use to revert to the last working > version? Thanks! I'm not a git expert so maybe others have a better way to do this. I would just identify the commit you want to revert (the fact that all the recent commit messages are "commit" won't necessarily help), then revert it with: git revert If you need to revert more than 1 commit, revert them in reverse chronological order. This is just standard git stuff. The only part that is specific to Bioconductor is that you need to finish the sequence with an additional commit that bumps the version to 1.35.2. Hope this helps, H. > > > Best, > Jason > > -- > Zhicheng Ji, PhD. > Assistant Professor > Department of Biostatistics and Bioinformatics > Duke University School of Medicine > 2424 Erwin Road, Suite 1102 Hock Plaza Box 2721 > Durham, NC 27710, USA > > > > On Wed, Oct 19, 2022 at 10:29 PM Hervé Pagès > wrote: > > Hi Jason, > > On 19/10/2022 19:10, Jason Ji wrote: > > Dear admin, > > > > I am an author of a Bioconductor package (TSCAN) and recently I > made a > > mistake pushing a problematic version of the software to > Bioconductor. I > > wonder if there is a way to revert back to the previous working > version? > > Yes but only for the master branch (BioC 3.16). The RELEASE_3_15 > branch > got frozen recently and can no longer be touched. > > Also package versions can only go up. Note that the current devel > version of TSCAN (1.35.1) never got published (i.e. it didn't > propagate), so, technically, you won't need to bump the version after > you fix the package. Even though it wouldn't hurt to do so (i.e. > to bump > to 1.35.2). > > Cheers, > > H. > > > > > Thanks! > > > > > > Best, > > Jason > > > > -- > > Zhicheng Ji, PhD. > > Assistant Professor > > Department of Biostatistics and Bioinformatics > > Duke University School of Medicine > > 2424 Erwin Road, Suite 1102 Hock Plaza Box 2721 > > Durham, NC 27710, USA > > > > [[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 > -- 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
Re: [Bioc-devel] reverting to a previous version
Hi Jason, On 19/10/2022 19:10, Jason Ji wrote: Dear admin, I am an author of a Bioconductor package (TSCAN) and recently I made a mistake pushing a problematic version of the software to Bioconductor. I wonder if there is a way to revert back to the previous working version? Yes but only for the master branch (BioC 3.16). The RELEASE_3_15 branch got frozen recently and can no longer be touched. Also package versions can only go up. Note that the current devel version of TSCAN (1.35.1) never got published (i.e. it didn't propagate), so, technically, you won't need to bump the version after you fix the package. Even though it wouldn't hurt to do so (i.e. to bump to 1.35.2). Cheers, H. Thanks! Best, Jason -- Zhicheng Ji, PhD. Assistant Professor Department of Biostatistics and Bioinformatics Duke University School of Medicine 2424 Erwin Road, Suite 1102 Hock Plaza Box 2721 Durham, NC 27710, USA [[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 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Increase version of system dependency?
Hi Sarvesh, All I see is that seqArchR fails on palomino4 because Python module 'packaging' is not available on that machine. The module seems to be available on the other builders though so no problem there. Anyways if your package depends on that module (and it seems that it does, via the inst/python/perform_nmf.py script), then you need to list the module in your SystemRequirements. Then we'll make sure to install the module on all the builders. Thanks, H. On 18/10/2022 09:31, Sarvesh Nikumbh wrote: Hi bioc team, My package seqArchR though does not error in any way, but can spit out numerous warnings (originally from Python/scikit-learn which is a dependency) depending on the version of scikit-learn available. This fills the output to the extent that it is unreadable. The cause for this is the deprecation/future version warning in NMF/scikitlearn <https://scikit-learn.org/stable/modules/generated/sklearn.decomposition.NMF.html> which is forced, so I cannot suppress it. I pushed a fix for this in the devel version -- where, instead of increasing the dependency version, I check the module version using packaging module from setuptools and appropriately make the python function call. But this gives an error on the Windows build machine, and is fine on Linux/macOS. See https://bioconductor.org/checkResults/3.16/bioc-LATEST/seqArchR/palomino4-checksrc.html I expected that setuptools will be available on all machines, because the previous alternative, distutils, is available with vanilla python, but is not recommended. Would you suggest having setuptools in the SystemRequirements or using distutils? Or simply depending on higher version of scikit-learn (the latest 1.2) -- which is the root cause of this issue anyway. Thanks and best, Sarvesh -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Package checks with WARNING
On 12/10/2022 13:42, Lapuente Santana, Oscar wrote: Hi Hervé, Thanks for your suggestion. The package rstatix which I used and it's set as an import, calls the coin package but this one is defined as a suggests in the description file of rstatix package (https://github.com/kassambara/rstatix/blob/master/DESCRIPTION). In particular, I am calling two two functions from this package: rstatix::wilcox_test and rstatix::wilcox_effsize. The later uses several functions from the coin package and one is called the same way which is coin::wilcox_test and then the warning arises. Given this situation, I would feel more comfortable importing the full coin package. What are your thoughts? I see. But still, you're only supposed to import what your code uses _directly_. In this case your code doesn't make any call to coin or doesn't use any symbol defined in coin. The code in rstatix does, but not your code. One concern is that you want to make sure that coin is installed on the user machine, so it needs to be listed as a dependency. One way to achieve this is to move coin to Depends, and to not import anything from it. I just tried this but R CMD check now produces: * checking dependencies in R code ... NOTE Package in Depends field not imported from: ‘coin’ These packages need to be imported from (in the NAMESPACE file) for when this namespace is loaded but not attached. IMO this is actually a legitimate use of Depends, so I'd say it's ok. At least now you get a NOTE instead of a WARNING ;-) A more hacky solution is to keep coin in Imports and to import an arbitrary symbol from it. Could be anything, except 'wilcox_test' of course, to avoid the clash with importFrom(rstatix,wilcox_test). That should produce a clean R CMD check. Hope this helps, H. Cheers, Óscar On 12/10/2022, 20:07, "Hervé Pagès" wrote: Hi Óscar, On 12/10/2022 01:09, Lapuente Santana, Oscar via Bioc-devel wrote: > Dear Bioconductor developers/maintainers, > > My package ‘easier’ checks with WARNING in both the current 3.15 release and the devel version. > I am just checking in to see if that’s okay since this was also the case in the first submission (the warning stems from a dependency of a dependency) Sure but you can get rid of it by importing only what you need from the coin package. Right now you import the full coin namespace, by having import(coin) in your NAMESPACE file, and that introduces a clash with importFrom(rstatix,wilcox_test) that you also have in there. I'm actually not sure what you need coin for (I was not able to find a place in your code where you make any use of it). So maybe you could just drop that dependency entirely? Best, H. > > Thanks in advance, > Cheers, Óscar > > [[alternative HTML version deleted]] > > ___ > Bioc-devel@r-project.org mailing list > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-develdata=05%7C01%7C%7Cb6a12862a3d34c6fc57608daac7c93b1%7Ccc7df24760ce4a0f9d75704cf60efc64%7C1%7C0%7C638011948302682925%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=zX2HiEuNhlfF8IQ1N61wbAyt1Sd2k4hiVISTMJXA3qk%3Dreserved=0 -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Package checks with WARNING
Hi Óscar, On 12/10/2022 01:09, Lapuente Santana, Oscar via Bioc-devel wrote: Dear Bioconductor developers/maintainers, My package ‘easier’ checks with WARNING in both the current 3.15 release and the devel version. I am just checking in to see if that’s okay since this was also the case in the first submission (the warning stems from a dependency of a dependency) Sure but you can get rid of it by importing only what you need from the coin package. Right now you import the full coin namespace, by having import(coin) in your NAMESPACE file, and that introduces a clash with importFrom(rstatix,wilcox_test) that you also have in there. I'm actually not sure what you need coin for (I was not able to find a place in your code where you make any use of it). So maybe you could just drop that dependency entirely? Best, H. Thanks in advance, Cheers, Óscar [[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 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Issue with a package dependent on rJava
o liability for any damage caused by any virus transmitted by this email. www.icar.org.in [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Mac ARM64 binaries available
Hi Ramon,
FWIW here's what I get when I run code chunk fdfmutex2 from the
OncoSimulR.Rmd vignette on kjohnson (Mac arm64):
> set.seed(1)
> s2fd <- oncoSimulIndiv(afe4,
+ muEF = mtfd,
+ model = "McFL",
+ onlyCancer = FALSE,
+ finalTime = 40,
+ mu = 1e-4,
+ initSize = 5000,
+ keepPhylog = TRUE,
+ seed = NULL,
+ errorHitMaxTries = FALSE,
+ errorHitWallTime = FALSE)
Using old version of fitnessEffects. Transforming fitnessEffects
to last version.
Using old version of fitnessEffects. Transforming fitnessEffects
to last version.
Using old version of fitnessEffects. Transforming fitnessEffects
to last version.
Using old version of fitnessEffects. Transforming fitnessEffects
to last version.
ERROR: Algo 2: (1.0 - pe/pm) > 1.0
Unrecoverable exception: Algo 2: 1 - pe/pm > 1. Aborting.
> plot(s2fd, show = "genotypes")
Error in seq.int(0, 1, length.out = n) :
'length.out' must be a non-negative number
So it looks like the real error actually occurs in oncoSimulIndiv().
This function relies heavily on C++ code.
An orthogonal issue is that oncoSimulIndiv() shouldn't catch the error
like it does right now. Problem with this design is that the function
seems to return normally but the returned object is broken. Would be
better if the error was actually a hard one i.e. if the call to
oncoSimulIndiv() actually failed.
Cheers,
H.
On 04/10/2022 03:45, Ramon Diaz-Uriarte wrote:
Dear Vincent,
On Tue, 04-October-2022, at 11:40:11, Vincent Carey
wrote:
We are not running check on ARM platform at this time. If you want to provide
a link
to the
package/error you are having trouble with I will have a look on my machine.
Thanks a lot. This is the link:
https://bioconductor.org/checkResults/3.16/bioc-mac-arm64-LATEST/OncoSimulR/kjohnson-buildsrc.html
To try to figure it out, I split the suspected problematic section of the
vignette where things fail; the newest version of the package (as well as the
former one) passed checks in the other platforms.
Nevertheless, since not passing in this platform will have no consequences, I
would not like to bug you with this. Since there is no rush, I'll use
trial-and-error, preparing new versions as new check results become available.
Best,
R.
If you are
passing
on the other platforms there will be no consequences for remaining in the bioc
ecosystem.
On Tue, Oct 4, 2022 at 5:22 AM Ramon Diaz-Uriarte wrote:
Dear All,
It is unclear to me if the deadline of 28-October-2022 for "packages passing
‘‘R
CMD build’’ and ‘‘R CMD check’’ without errors or warnings"
(https://bioconductor.org/developers/release-schedule/) also applies to this
platform.
Why the question? I am trying to debug an error in this platform of a package
I
maintain but:
a) the snapshot date seems older than the snapshot date in
http://bioconductor.org/checkResults/devel/bioc-LATEST/ (which would
introduce a longer delay in verifying results of code changes)
b) results are not linked from the former page (which, I understand, is the
"canonical" one for checking status).
Thanks,
R.
On Tue, 27-September-2022, at 19:46:01, Jennifer Wokaty
wrote:
> Mac ARM64 binaries are now available. You can view the build report at
> https://bioconductor.org/checkResults/3.16/bioc-mac-arm64-LATEST/.
>
> To make use of these binaries
>
> * Install R-4.2.1-arm64.pkg from CRAN at
https://cran.r-project.org/bin/macosx/
> * Install BiocManager as usual
> * Use BiocManager::install() as usual
>
> Note: BiocManager::install() will automatically pick the new arm64 binaries
so
> you should no longer need Xcode.
>
>
> Jennifer Wokaty
> they/them
> Bioconductor Core Team
> CUNY SPH
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
--
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-31
Facultad de Medicina
Universidad Autónoma de Madrid
Arzobispo Morcillo, 4
28029 Madrid
Spain
Phone: +34-91-497-2412
Email: rdia...@gmail.com
r.d...@uam.es
https://ligarto.org/rdiaz
___
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 t...{{dropped:13}}
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] New maintainer for package - Updating a R package and pushing the commit
Hi Tulip, On 29/09/2022 13:52, Tulip Nandu wrote: Hi Kern, Anusha no longer is associated with the lab. So I will need to have access to the package. If you can create an account on GitCredentials that would be great. If that means Anusha is no longer going to maintain the package, then their role in Authors@R would need to be switched from "cre" to "aut" or "ctb" or whatever is appropriate. As Lori said, the Maintainer and Author fields should get removed, and your name and role moved to the Authors@R field. Thanks, H. I do have a github account. tulipnandu is the username. https://github.com/tulipnandu [https://avatars.githubusercontent.com/u/1099843?v=4?s=400]<https://github.com/tulipnandu> tulipnandu - Overview<https://github.com/tulipnandu> tulipnandu has 10 repositories available. Follow their code on GitHub. github.com Also I would need to push the changes in the src file to master on bioconductor/git. If I can get some help with that, it would be great too. Regards, Tulip. From: Kern, Lori Sent: Thursday, September 29, 2022 6:52 AM To: Tulip Nandu ; bioc-devel@r-project.org ; Anusha Nagari Subject: Re: New maintainer for package - Updating a R package and pushing the commit EXTERNAL MAIL This message was sent securely using Zix�<http://www.zixcorp.com/get-started/> a few points: Normally only one person has maintainer access to a package this currently was Anusha Nagari . Should they also retain maintainer access? Anusha was assigned because that is who is listed with Authors@R. You currently have a mixure of using Authors@R and Maintainer/Author field. Please remove Author/Maintainer fields and only use Authors@R. In a normal procedure the currently listed maintainer would request the switch or additional access. Since I see you listed in the Maintainer field, we can ignore this step for this situation. I will need to create an account on our GitCredentials where you can manage your ssh keys for access. We can link a github account for access. Do you have a personal github account you would like associated with; if so please provide your github username? Cheers, 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 Tulip Nandu Sent: Wednesday, September 28, 2022 5:15 PM To: bioc-devel@r-project.org Subject: [Bioc-devel] New maintainer for package - Updating a R package and pushing the commit Hi, I'm the new maintainer of the groHMM package which is having issues in its build. In that view I would like to update the package but it won't allow me since my email is not on file with the maintainer of bioconductor package. Can you please list the steps to have me listed as a maintainer and update the package on bioconductor/git. Let me know. Regards, Tulip. UT Southwestern Medical Center The future of medicine, today. [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://secure-web.cisco.com/153TPO9q9LgJcIfq7xj6UvgBc8nFbtHT8ZYZQGFIIs9ZSk4A7ilw0CeI7TbK_V6bYIx6ThYomprV1f_aLbd2S7a4YeVDdjcKH03QZSE2kEv9_cNUrEpbkAGk1iajxtenYsDmTonDkJbZIeg-IoB4g0iaPG_jCRjh5agFEcsI__iP6x9liTUj5A10Dg00kng9WU4FVkpjP43oIF598TjRkpatlZZje1T_Uia_oVEIB40G8FCCId7tn4Ma2qwItlJv02H_hbkaC51OFRBiEs01TpHluUuNezGZ0_C3uhIT4KIFVO5xO4VHhGZplznuonJ4r/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. This message was secured by Zix<http://www.zixcorp.com>�. CAUTION: This email originated from outside UTSW. Please be cautious of links or attachments, and validate the sender's email address before replying. [[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 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Package Classifications via BiocViews
On 28/09/2022 16:03, Hervé Pagès wrote: Hi Burak, Based on your description of what the package does, this is really a software package in nature, so is in the wrong repository. We need to fix this. In 4 steps: 1. Please remove the ExperimentData term from the biocViews field as well as any term that belongs to the ExperimentData ontology, that is: DiseaseModel, OrganismData, Homo_sapiens_Data, Mus_musculus_Data, Rattus_norvegicus_Data, TechnologyData, MicroarrayData, SequencingData, and RNASeqData. Yep, most of your terms will go away. After taking a second look I realize that **all** your current terms are from the ExperimentData ontology, instead of being a mix of Software and ExperimentData terms as I thought initially. So they should all be removed. 2. Add the Software term, in first position. You're welcome to add new terms if you want, from the following vocabulary: https://github.com/Bioconductor/biocViews/blob/master/inst/dot/biocViewsVocab.dot. Please make sure to pick terms that belong to the Software ontology (i.e. are offsprings of the Software term). You should definitely add new terms from the Software ontology! Thanks, H. 3. Bump the package version (only the z part in x.y.z), and push your changes to git.bioconductor.org. 4. Let us know when you're done. We'll make the required adjustments on our side. Thanks, H. On 28/09/2022 09:37, Burak Ogan Mancarci wrote: Apologies for the inconvenience. The change isn't essential on our end and can be avoided or delayed if you think the ExperimentData label can be applied to a package responsible for accessing data from a database rather than storing static data. We were only worried about misleading use of biocviews terms. Cheers, Ogan On Wed., Sep. 28, 2022, 14:26 Kern, Lori, wrote: Changing the biocviews is not sufficient. There needs to be work on our end to change the manifest the package belongs to and to clear the build products from the data repositories so it is only found in one location. Are you sure you want to proceed with switching? It is not trivial on our end. 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 Burak Ogan Mancarci *Sent:* Wednesday, September 28, 2022 9:17 AM *To:* bioc-devel@r-project.org *Subject:* [Bioc-devel] Package Classifications via BiocViews Hi, I am a developer working on the bioconductor package gemma.R < https://secure-web.cisco.com/1wIQY41Mq8CRYqLq1luoPm43XSj6Icl27w6udr35y-BxPHgEP6B5pApAAeBdBeWsydixV0CSwBVIVl2C7mJykPI3ESX7qtp-xJOSvJAu4T1yzHr3CWRc7s6LY_WtIcrnzfyw3MI7z0oqv1hzA1x5oRN1kFZ-KF6tttbi86SwIwZhYADSMaK1xXJxmlZ0Oe8CtJ6jKBrSjnn6fnDONMFHadvspGk8Gxc7N15gdoVzcbADiR0q1V7O973S1e0Fu6CFPAayqcCBKIOs4_xfp6nm1HNupK82P0Bawyi3Bc4Fu2vcDQKLcgU-gyiBMkego3WW4/https%3A%2F%2Fbioconductor.org%2Fpackages%2F3.16%2Fdata%2Fexperiment%2Fhtml%2Fgemma.R.html . On publication we have used the ExperimentData biocview to classify the package but we believe this was not the correct decision since the package's function is to access a database much like geoquery. I was wondering if it was safe to change the classification on our end by changing biocviews directly or if it would cause issues with the bioconductor infrastructure? Cheers, Ogan [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://secure-web.cisco.com/1T5fXNWrq0wVkhsBGGZem_PrfqZL4JVbxk93lJB7cvCmSzN0HQXSMpdqsrdB-M-09zasav4vj733ww5BnQASs1jdsouSO0jb4woXH7k0uksmqx3BhiCXJy0Mwx7Lm3Y-CZdMcl-wRht_iwp5HSLm92GQ0X9FlCbqajgbnLRL79fA6nWZAIFiGim4shu4ZdLRn1HpNCM-UApMLDl1YReeF_UVn6EWI1QphpP--G8sq4j0nYkOefHddWPyHlTNwCg-f2aZd94WzVyCs9rzrmaF54N8FmJ-RTYeRHbVsmsWez047xQCe1sEkuv5HUjkC8Wqy/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 -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Package Classifications via BiocViews
Hi Burak, Based on your description of what the package does, this is really a software package in nature, so is in the wrong repository. We need to fix this. In 4 steps: 1. Please remove the ExperimentData term from the biocViews field as well as any term that belongs to the ExperimentData ontology, that is: DiseaseModel, OrganismData, Homo_sapiens_Data, Mus_musculus_Data, Rattus_norvegicus_Data, TechnologyData, MicroarrayData, SequencingData, and RNASeqData. Yep, most of your terms will go away. 2. Add the Software term, in first position. You're welcome to add new terms if you want, from the following vocabulary: https://github.com/Bioconductor/biocViews/blob/master/inst/dot/biocViewsVocab.dot. Please make sure to pick terms that belong to the Software ontology (i.e. are offsprings of the Software term). 3. Bump the package version (only the z part in x.y.z), and push your changes to git.bioconductor.org. 4. Let us know when you're done. We'll make the required adjustments on our side. Thanks, H. On 28/09/2022 09:37, Burak Ogan Mancarci wrote: Apologies for the inconvenience. The change isn't essential on our end and can be avoided or delayed if you think the ExperimentData label can be applied to a package responsible for accessing data from a database rather than storing static data. We were only worried about misleading use of biocviews terms. Cheers, Ogan On Wed., Sep. 28, 2022, 14:26 Kern, Lori, wrote: Changing the biocviews is not sufficient. There needs to be work on our end to change the manifest the package belongs to and to clear the build products from the data repositories so it is only found in one location. Are you sure you want to proceed with switching? It is not trivial on our end. 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 Burak Ogan Mancarci *Sent:* Wednesday, September 28, 2022 9:17 AM *To:* bioc-devel@r-project.org *Subject:* [Bioc-devel] Package Classifications via BiocViews Hi, I am a developer working on the bioconductor package gemma.R < https://secure-web.cisco.com/1wIQY41Mq8CRYqLq1luoPm43XSj6Icl27w6udr35y-BxPHgEP6B5pApAAeBdBeWsydixV0CSwBVIVl2C7mJykPI3ESX7qtp-xJOSvJAu4T1yzHr3CWRc7s6LY_WtIcrnzfyw3MI7z0oqv1hzA1x5oRN1kFZ-KF6tttbi86SwIwZhYADSMaK1xXJxmlZ0Oe8CtJ6jKBrSjnn6fnDONMFHadvspGk8Gxc7N15gdoVzcbADiR0q1V7O973S1e0Fu6CFPAayqcCBKIOs4_xfp6nm1HNupK82P0Bawyi3Bc4Fu2vcDQKLcgU-gyiBMkego3WW4/https%3A%2F%2Fbioconductor.org%2Fpackages%2F3.16%2Fdata%2Fexperiment%2Fhtml%2Fgemma.R.html . On publication we have used the ExperimentData biocview to classify the package but we believe this was not the correct decision since the package's function is to access a database much like geoquery. I was wondering if it was safe to change the classification on our end by changing biocviews directly or if it would cause issues with the bioconductor infrastructure? Cheers, Ogan [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://secure-web.cisco.com/1T5fXNWrq0wVkhsBGGZem_PrfqZL4JVbxk93lJB7cvCmSzN0HQXSMpdqsrdB-M-09zasav4vj733ww5BnQASs1jdsouSO0jb4woXH7k0uksmqx3BhiCXJy0Mwx7Lm3Y-CZdMcl-wRht_iwp5HSLm92GQ0X9FlCbqajgbnLRL79fA6nWZAIFiGim4shu4ZdLRn1HpNCM-UApMLDl1YReeF_UVn6EWI1QphpP--G8sq4j0nYkOefHddWPyHlTNwCg-f2aZd94WzVyCs9rzrmaF54N8FmJ-RTYeRHbVsmsWez047xQCe1sEkuv5HUjkC8Wqy/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 -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] How to fix the error checked in the development version of miRspongeR
On 21/09/2022 07:57, Hervé Pagès wrote: Just a workaround and not a real solution but maybe try to switch the order of the clusterProfiler and SPONGE reports? Oops, I meant "imports", not "reports". But, again, reducing the huge number of dependencies of both miRspongeR and SPONGE should be a priority. Something that you might want to discuss/coordinate with the SPONGE folks. Best, H. -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] How to fix the error checked in the development version of miRspongeR
Let's please keeping this conversation on bioc-devel.
On 20/09/2022 22:36, Zhang Junpeng wrote:
> Thanks for your reply, Hervé.
>
> I have found the cause of this error at
> https://github.com/paul-buerkner/brms/issues/1356 and
> https://github.com/tidyverse/dbplyr/issues/779.
>
> It is Brobdingnag which caused the bug which is a dependency from
> bridgsamplin. But, I have no way to solve this error now. It seems
> that several other packages have also the same error.
Just a workaround and not a real solution but maybe try to switch the
order of the clusterProfiler and SPONGE reports?
Best,
H.
>
> Regards,
> Junpeng
>
> Hervé Pagès 于2022年9月21日周三 10:42写道：
>
> Looks like there's a nasty clash between dbplyr (CRAN) and the devel
> version of clusterProfiler:
>
> > library(clusterProfiler)
> > library(dbplyr)
> Error in completeSubclasses(classDef2, class1, obj, where) :
> trying to get slot "subclasses" from an object of a basic class
> ("NULL") with no slots
> Error: package or namespace load failed for ‘dbplyr’:
> .onLoad failed in loadNamespace() for 'dbplyr', details:
> call: setClass(cl, contains = c(prevClass, "VIRTUAL"), where =
> where)
> error: error in contained classes ("character") for class “ident”;
> class definition removed from ‘dbplyr’
>
> This is on any platform with Bioc-devel and the latest version of
> each
> package:
>
> > packageVersion("clusterProfiler")
> [1] ‘4.5.2’
> > packageVersion("dbplyr")
> [1] ‘2.2.1’
>
> Note that you need to load the two packages in this order to get this
> error. Loading them in the opposite order works fine.
>
> This seems to break miRspongeR thru a series of events that
> involve the
> imports made by the SPONGE package: miRspongeR imports
> clusterProfiler
> and SPONGE, in that order, and SPONGE itself imports dbplyr via
> tidyverse.
>
> This is something you'll have to discuss with the clusterProfiler
> and/or
> dbplyr maintainers.
>
> Finally note that, when miRspongeR is loaded, sessionInfo() reports
> about 200 packages loaded via a namespace! This is obviously a very
> fragile situation. Reducing that number would help make the
> package less
> vulnerable to these sorts of clash. Many of those "loaded via a
> namespace" packages are actually a consequence of SPONGE itself
> importing many many things (it imports the full tidyverse!), so
> there's
> probably some room for improvement on that side too.
>
> Best,
>
> H.
>
>
> On 20/09/2022 13:32, Hervé Pagès wrote:
> > Hi Junpeng,
> >
> > FWIW the EpiCompare package seems to be failing in exactly the
> same way:
> >
> >
>
> https://bioconductor.org/checkResults/3.16/bioc-LATEST/EpiCompare/nebbiolo2-install.html
>
> >
> >
> > Also I can easily reproduce this on my laptop (Ubuntu 22.04):
> >
> > > BiocManager::install("miRspongeR")
> > Bioconductor version 3.16 (BiocManager 1.30.18), R 4.2.0 Patched
> > (2022-05-04
> > r82318)
> > Installing package(s) 'miRspongeR'
> > trying URL
> >
>
> 'https://bioconductor.org/packages/3.16/bioc/src/contrib/miRspongeR_2.1.0.tar.gz'
>
> >
> > Content type 'application/x-gzip' length 661557 bytes (646 KB)
> > ==
> > downloaded 646 KB
> >
> > * installing *source* package ‘miRspongeR’ ...
> > ** using staged installation
> > ** libs
> > /usr/bin/gcc -I"/home/hpages/R/R-4.2.r82318/include" -DNDEBUG
> > `/home/hpages/R/R-4.2.r82318/bin/Rscript -e "Rcpp:::CxxFlags()"`
> > -I/usr/local/include -fpic -O3 -c complex.c -o complex.o
> > /usr/bin/gcc -I"/home/hpages/R/R-4.2.r82318/include" -DNDEBUG
> > `/home/hpages/R/R-4.2.r82318/bin/Rscript -e "Rcpp:::CxxFlags()"`
> > -I/usr/local/include -fpic -O3 -c registerDynamicSymbol.c -o
> > registerDynamicSymbol.o
> > /usr/bin/gcc -shared -L/home/hpages/R/R-4.2.r82318/lib
> > -L/usr/local/lib -o miRspongeR.so complex.o registerDynamicSymbol.o
> > -L/home/hpages/R/R-4.2.r82318/lib -lR
> > installing to
> >
>
> /home/hpages/R/R-4.2.r82318/library/00LOCK-miRspongeR/00new/miRspongeR/libs
> > ** R
> > ** inst
>
Re: [Bioc-devel] How to fix the error checked in the development version of miRspongeR
Looks like there's a nasty clash between dbplyr (CRAN) and the devel
version of clusterProfiler:
> library(clusterProfiler)
> library(dbplyr)
Error in completeSubclasses(classDef2, class1, obj, where) :
trying to get slot "subclasses" from an object of a basic class
("NULL") with no slots
Error: package or namespace load failed for ‘dbplyr’:
.onLoad failed in loadNamespace() for 'dbplyr', details:
call: setClass(cl, contains = c(prevClass, "VIRTUAL"), where = where)
error: error in contained classes ("character") for class “ident”;
class definition removed from ‘dbplyr’
This is on any platform with Bioc-devel and the latest version of each
package:
> packageVersion("clusterProfiler")
[1] ‘4.5.2’
> packageVersion("dbplyr")
[1] ‘2.2.1’
Note that you need to load the two packages in this order to get this
error. Loading them in the opposite order works fine.
This seems to break miRspongeR thru a series of events that involve the
imports made by the SPONGE package: miRspongeR imports clusterProfiler
and SPONGE, in that order, and SPONGE itself imports dbplyr via tidyverse.
This is something you'll have to discuss with the clusterProfiler and/or
dbplyr maintainers.
Finally note that, when miRspongeR is loaded, sessionInfo() reports
about 200 packages loaded via a namespace! This is obviously a very
fragile situation. Reducing that number would help make the package less
vulnerable to these sorts of clash. Many of those "loaded via a
namespace" packages are actually a consequence of SPONGE itself
importing many many things (it imports the full tidyverse!), so there's
probably some room for improvement on that side too.
Best,
H.
On 20/09/2022 13:32, Hervé Pagès wrote:
Hi Junpeng,
FWIW the EpiCompare package seems to be failing in exactly the same way:
https://bioconductor.org/checkResults/3.16/bioc-LATEST/EpiCompare/nebbiolo2-install.html
Also I can easily reproduce this on my laptop (Ubuntu 22.04):
> BiocManager::install("miRspongeR")
Bioconductor version 3.16 (BiocManager 1.30.18), R 4.2.0 Patched
(2022-05-04
r82318)
Installing package(s) 'miRspongeR'
trying URL
'https://bioconductor.org/packages/3.16/bioc/src/contrib/miRspongeR_2.1.0.tar.gz'
Content type 'application/x-gzip' length 661557 bytes (646 KB)
==
downloaded 646 KB
* installing *source* package ‘miRspongeR’ ...
** using staged installation
** libs
/usr/bin/gcc -I"/home/hpages/R/R-4.2.r82318/include" -DNDEBUG
`/home/hpages/R/R-4.2.r82318/bin/Rscript -e "Rcpp:::CxxFlags()"`
-I/usr/local/include -fpic -O3 -c complex.c -o complex.o
/usr/bin/gcc -I"/home/hpages/R/R-4.2.r82318/include" -DNDEBUG
`/home/hpages/R/R-4.2.r82318/bin/Rscript -e "Rcpp:::CxxFlags()"`
-I/usr/local/include -fpic -O3 -c registerDynamicSymbol.c -o
registerDynamicSymbol.o
/usr/bin/gcc -shared -L/home/hpages/R/R-4.2.r82318/lib
-L/usr/local/lib -o miRspongeR.so complex.o registerDynamicSymbol.o
-L/home/hpages/R/R-4.2.r82318/lib -lR
installing to
/home/hpages/R/R-4.2.r82318/library/00LOCK-miRspongeR/00new/miRspongeR/libs
** R
** inst
** byte-compile and prepare package for lazy loading
Error in completeSubclasses(classDef2, class1, obj, where) :
trying to get slot "subclasses" from an object of a basic class
("NULL") with no slots
Error: .onLoad failed in loadNamespace() for 'dbplyr', details:
call: setClass(cl, contains = c(prevClass, "VIRTUAL"), where = where)
error: error in contained classes ("character") for class “ident”;
class definition removed from ‘dbplyr’
Execution halted
ERROR: lazy loading failed for package ‘miRspongeR’
* removing ‘/home/hpages/R/R-4.2.r82318/library/miRspongeR’
The downloaded source packages are in
‘/tmp/RtmpzFvmcs/downloaded_packages’
Updating HTML index of packages in '.Library'
Making 'packages.html' ... done
Let me take a closer look.
H.
On 20/09/2022 03:50, Zhang Junpeng wrote:
Hi Bioconductor community,
When I build/check the miRspongeR R package (development version),
there is
an error as follows. The release version of the miRspongeR R package
is OK.
*Error: .onLoad failed in loadNamespace() for 'dbplyr', details:
call: setClass(cl, contains = c(prevClass, "VIRTUAL"), where = where)
error: error in contained classes ("character") for class “ident”;
class
definition removed from ‘dbplyr’
Execution halted*
How can I fix this error? The details of error here:
https://master.bioconductor.org/checkResults/3.16/bioc-LATEST/miRspongeR/nebbiolo2-buildsrc.html
Thanks in advance
Junpeng
[[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
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] C++ compiler flags on Windows
On 01/08/2022 08:17, Martin Morgan wrote: ... I notice that on the package landing page https://bioconductor.org/packages/3.16/bioc/html/syntenet.html there is no Windows binary, suggesting that it has never built successfully. It could be that the intermittent results you observed was actually due to something else, like the Windows builder not reporting for that day. The single package builder results have expired, so I’m not sure why those builds were successful; the builders and single package builder are not identical. AFAIK the Single Package Builder no longer runs the Windows builds. So any Windows-related issue only gets detected once a contributed package is added to the daily builds. H. -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] download stats problem
Hi Jim, The download stats for data-experiment packages and workflows are temporary unavailable. We're aware of the issue and have been working on it. If all goes well they'll become available again soon: in the next 12 hours for data-experiment, and in the next 24 hours for workflows.. Sorry for the inconvenience. Best, H. On 09/06/2022 03:07, James Perkins wrote: > Looking into this a bit further - this might be a workflow specific > issue, as the same problem occurs for e.g. > > http://bioconductor.org/packages/stats/workflows/chipseqDB/ > > On Thu, 9 Jun 2022 at 11:53, James Perkins wrote: > > Dear BioC team, > > I cannot access download stats for the following package: > > http://bioconductor.org/packages/stats/workflows/ExpHunterSuite/ > > It does not appear to be a systemic issue, I can access e.g. > > http://bioconductor.org/packages/stats/bioc/ReadqPCR/ > > Not sure if this is related to the previous issue, i.e. problems > accessing the > latest CloudFront log files on S3 but I've used this thread anyway. > > Cheers, > > Jim > > On Thu, 11 Mar 2021 at 01:40, Hervé Pagès > wrote: > > Thanks for bringing this to our attention. > > > The script that we use to compute the stats had problems > accessing the > latest CloudFront log files on S3, resulting in package > downloads from > the last few days being ignored. This is now repaired and > hopefully the > stats will get updated tomorrow with the full counts. > > Best, > H. > > > On 3/10/21 3:15 PM, Luo Weijun via Bioc-devel wrote: > > Dear BioC team, > > download stats for BioC packages don’t seem to be updated. > The graphs were generated on 03-09, but the stats are much > lower than expected for 9 days: > > https://bioconductor.org/packages/stats/bioc/SBGNview/ > > https://bioconductor.org/packages/stats/bioc/pathview/ > > https://bioconductor.org/packages/stats/bioc/BiocGenerics/ > > can you check on this? thanks. > > Weijun Luo > > > > _______ > > 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 > > ___ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > > > > -- > James R Perkins PhD > Post-Doctoral Researcher, Rare Diseases Research Network (CIBERER) > Department of Molecular Biology and Biochemistry > <https://goo.gl/maps/UCLQXZLR2W12> > Science Faculty, University of Malaga > 29071 Malaga, Spain > > > > > > -- > James R Perkins PhD > Post-Doctoral Researcher, Rare Diseases Research Network (CIBERER) > Department of Molecular Biology and Biochemistry > <https://goo.gl/maps/UCLQXZLR2W12> > Science Faculty, University of Malaga > 29071 Malaga, Spain > > > -- 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
Re: [Bioc-devel] macOS auto build fails with "graphics API version mismatch"
Hi Matteo,
Let's please keep this conversation on bioc-devel where it started.
On 23/03/2022 08:46, Matteo Tiberti wrote:
>
> Hi Hervé,
>
> Now all builds pass – thanks for your help!
>
> As you mention we have a warning to iron out in the documentation and
> we’ll also sneak in the other fixes to the documentation you are
> kindly suggesting.
>
> Just to be sure, if I want these changes to appear in release 3.15 I
> just need to push them to my Bioconductor master branch and don’t need
> to create a RELEASE_3_15 branch, since that will automatically branch
> off the latest master. Is this correct?
>
Yes
> Also, I don’t need to do anything else for this build to be propagated
> to the users in version 3.14 since that happens automatically when the
> build passes. Is this right?
>
Bumping the version is what triggers propagation. Note that we only
build release (BioC 3.14) every other day, with reports on Mondays,
Wednesdays, and Fridays. FWIW I don't see your latest changes on today's
report, maybe because you pushed them after the builds started yesterday:
https://bioconductor.org/checkResults/3.14/bioc-LATEST/MoonlightR/
This means that they will show up on Friday's report, granted that you
actually pushed them to the RELEASE_3_14 branch. If you also bumped the
version (which you should do if you haven't yet), then the blue LEDs on
the right will turn green indicating propagation of the new version
(normally 1.20.1).
Cheers,
H.
> Best,
>
> Matteo
>
> *From: *Hervé Pagès
> *Date: *Tuesday, 22 March 2022 at 21.23
> *To: *Matteo Tiberti , bioc-devel@r-project.org
>
> *Subject: *Re: [Bioc-devel] macOS auto build fails with "graphics API
> version mismatch"
>
> Hi Matteo,
>
> On 21/03/2022 03:53, Matteo Tiberti wrote:
> > Dear all,
> >
> > I'm looking into the build failure of our MoonlightR package on
> merida1 (macOS). It fails because vignettes fail to compile:
> >
> > Quitting from lines 532-546 (Moonlight.Rmd)
> > Error: processing vignette 'Moonlight.Rmd' failed with diagnostics:
> > Graphics API version mismatch
> > --- failed re-building �Moonlight.Rmd�
> >
> > The error refers to a function call that is supposed to generate an
> image file for the vignette using ggsave.
> >
> > I have installed R-devel on macOS 10.15.7 and I am trying to
> replicate the error, but it seems to build correctly on my system.
> I've done some searching and I suspect that packages that use the
> graphics API need to be recompiled on the build system since the API
> version changed with R 4.2. Do you think this might be the case and,
> if so, should I wait for this to be fixed on merida?
>
> This should have been taken care of now. Let us know if you still see
> this error on tomorrow's report.
>
> >
> > Notice that MoonlightR also doesn't build on Windows now because of
> an unrelated issue with a dependency
>
> Looks like it's gone on today's report :-)
>
> BTW can you please remove MoonlightR/vignettes/Moonlight.html from the
> git repo of your package? The HTML vignette is automatically generated
> by 'R CMD build' and added to the resulting source tarball. As such it
> should not be pre-compiled and included in the package source tree.
>
> FWIW I get the following problem when running 'R CMD Stangle' on the
> markdown vignette:
>
> hpages@spectre:~/MoonlightR/vignettes$ R CMD Stangle Moonlight.Rmd
> Warning: The closing backticks on line 669 (" ```") in Moonlight.Rmd
> do not match the opening backticks "```" on line 667. You are
> recommended to fix either the opening or closing delimiter of the code
> chunk to use exactly the same numbers of backticks and same level of
> indentation (or blockquote).
> Output file: Moonlight.R
>
> Maybe you want to look into this.
>
> Thanks,
>
> H.
>
> >
> > Thank you,
> >
> > Matteo Tiberti
> >
> > Danish Cancer Society
> > Strandboulevarden 49
> > DK-2100 Copenhagen
> > Telephone: +45 35 25 73 07
> >
> >
> >
> [https://i.xink.io/Images/Get/K116/d1.png]<https://www.cancer.dk/?utm_source=email_medium=medarbejderemail_campaign=medarbejderemail_content=cancerdk
>
> <https://i.xink.io/Images/Get/K116/d1.png%5d%3chttps:/www.cancer.dk/?utm_source=email_medium=medarbejderemail_campaign=medarbejderemail_content=cancerdk>>
> >
> > www.cancer.dk<https://www.cancer.dk/international/> | Vores
> privatlivspolitik<https://www.cancer.dk/om-os/privatlivspolitik/>
> >
> >
> > [[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
>
--
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
Re: [Bioc-devel] Vignettes with many output graphics - How to fulfill the Bioc build requirements, best practises?
Yes, moving the heavy vignette to a workflow package is probably a good
idea. See this post from last month for more info about workflow packages:
https://stat.ethz.ch/pipermail/bioc-devel/2022-February/018821.html
Cheers,
H.
On 22/03/2022 13:09, Marcel Ramos wrote:
Hi Christian,
Thanks for reaching out.
From what I gather, perhaps a workflow package submission is more
appropriate for the
details that you would like to submit within the vignette. We recommend
vignettes that have
small and run-able examples (possibly from simulated data) that
demonstrate package functionality.
I haven't taken a look at the 'mysterious' package but perhaps consider
breaking up the functionality
into separate packages, if possible. For example, you could have one
package for each of the facilities
(e.g., stats, viz, utils, etc).
As for producing PDFs from plotting functions, this is generally
discouraged.
Plotting functions should work like plot(1:10) and should output a
single plot (or grouped plots)
to the graphics device. The user should then be free to choose the file
format for any plot produced.
This approach may in turn resolve the issues you describe with plots in
the vignette.
It may require some time re-designing the package(s) but I think your
users would benefit
in the long run.
Best regards,
Marcel
On 3/22/22 4:05 PM, James W. MacDonald wrote:
If the pages from the PDF are essentially static (for your vignette, that is),
why not run it once, get the pngs, save them somewhere, and use eval = FALSE in
the knitr headers for the plot* fuctions. Then you will speed things up, there
won't be all this extra PDF documentation that's +/- not part of the vignette,
and it should run much faster.
-Original Message-
From: Bioc-devel On Behalf Of Christian
Arnold
Sent: Tuesday, March 22, 2022 3:33 PM
To:bioc-devel@r-project.org
Subject: [Bioc-devel] Vignettes with many output graphics - How to fulfill the
Bioc build requirements, best practises?
Hi, I wanted to reach out for some thoughts on the following problem I am
facing with a package I recently submitted to Bioc. In essence, I am struggling
with the 15 minutes time limit for R CMD check as well as the package size
limit of 5 MB. The latter is more important, so let's focus on that:
It is a quite large package with many functions, a full workflow for building
gene-regulatory networks, and we want to include a detailed workflow vignette
where the most important output plots are shown and explained, to make it
user-friendly and easy to apply.
For various plot* functions produce PDFs that have many pages (sometimes dozens
or even hundreds), only some of which should be shown in the vignette (say page
2 and 5 from PDF A, and page 1 and 2 from PDF B, etc). Including selected pages
from a PDF doesnt seem to be possible with BiocStyle (please correct me if I am
wrong), so currently, I am automatically converting each page of each of the
various PDFs as a png image, to include selected pages then in the Vignette via
knitr::include_graphics. This works well, but leads to the repo being too big
(currently 11 MB) when being build - because the original images as well as the
resulting htmls in the inst folder contain the images, making it bigger than 5
MB. I could reduce the resolution of the images much further, but this feels
wrong also. In total, we talk about 40 or so images that I wanted to share
across the different vignettes.
Are there any thoughts on how I can proceed here without spending a lot of time
on re-designing the package logic (which I unfortunately dont have at this
point) and without sacrificing the usability of the package (I could just
remove the Workflow vignette or host it externally I guess)?
Thanks, your input is very appreciated.
Best
Christian
___
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
---
Marcel Ramos
Bioconductor Core Team
Roswell Park Comprehensive Cancer Center
Dept. of Biostatistics & Bioinformatics
Elm St. & Carlton St.
Buffalo, New York 14263
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
--
Hervé Pagès
Bioconductor Core Team
hpages.on.git...@gmail.com
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Supplementing package vignette with workflow vignette
On 16/02/2022 00:35, migdal migdal wrote: Dear bioc-devel, one of the requirements for the Bioconductor package is to pass the R CMD BUILD, including some constraints on the time. To accommodate for some specific cases, Bioconductor implements a concept of long tests which are excluded from the build time limit. I wonder if a corresponding concept exists for the vignettes? I do realize the need for time constraints. However, I think it could be of use to supplement a main vignette with supplementary vignettes that could showcase the package use eg. on a larger dataset. Those could have a less strict constraints policy eg. more time to run, more resources like number of cores, RAM etc. Are there any ways to accomplish this? Yes, by creating (and submitting) a workflow package. This is basically a vignette wrapped in its own dedicated package (the package typically contains no R code). List of existing workflow packages: https://bioconductor.org/packages/devel/BiocViews.html#___Workflow Workflow builds (Tuesdays and Fridays): https://bioconductor.org/checkResults/3.15/workflows-LATEST/ Timeout limit is 2h for these packages. Cheers, H. Best Maciek [[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 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Recreating nebbiolo1's build environment
Today's results for rrvgo:
https://bioconductor.org/checkResults/3.15/bioc-LATEST/rrvgo/
The vignette error is gone. There are still some errors but they are
different (org.Pf.plasmo.db was deprecated in BioC 3.14 and got removed
from BioC 3.15).
H.
On 11/01/2022 09:28, Hervé Pagès wrote:
Hi Sergi,
I can't reproduce this on my laptop either (Ubuntu 21.10) or on
nebbiolo1.
And it looks like the build results for rrvgo will look fine on all
platform today (report not available yet).
I suspect that the error was coming from a package that rrvgo depends
on and that it's been fixed now.
I strongly suspect GOSemSim:
commit 93e084381b6f73209da09b6564db7a30516e9b99 (HEAD -> master,
origin/master, origin/HEAD)
Author: Guangchuang Yu
Date: Mon Jan 10 10:12:55 2022 +0800
fixed #36 for returning NULL when it should be the input object
Cheers,
H.
On 11/01/2022 02:21, sergi sayols puig wrote:
Dear all,
Our package rrvgo has recently started to fail when building for BioC
3.15 (devel branch).
I'm trying to replicate the build environment as in nebbiolo1 in order
to reproduce the issue locally, with little success so far. I'm
following carefully the instructions provided in the build report, but
I must be missing something because I can build the package
successfully.
I tried both compiling R from source (snapshot
R-devel_2022-01-05_r81451.tar.gz) + installing the devel version of
Bioconductor, and also using the docker image of
bioconductor_docker:devel. Here I provide the steps I followed to
build from within the container, using vanilla .libPaths():
* pull docker image
$ docker pull bioconductor/bioconductor_docker:devel
* open shell in the running container:
$ docker exec -it bioconductor/bioconductor_docker:devel /bin/bash
* install package + dependencies (within the container):
# R
R> install.packages("BiocManager")
R> BiocManager::install(version='devel')
R> BiocManager::install(c("rrvgo", "org.Hs.eg.db")) # the second
is required in the vignette
R> q()
* clone the devel branch of the package:
# git clone https://git.bioconductor.org/packages/rrvgo
* get nebbiolo1's .Renviron:
# wget -qO-
http://bioconductor.org/checkResults/devel/bioc-LATEST/Renviron.bioc >
Renviron.bioc
* and build as described in the build report:
# R_ENVIRON_USER=Renviron.bioc R CMD build --keep-empty-dirs
--no-resave-data rrvgo
This will successfully build the tarball of the package, without
complains.
Does anyone have any idea what I could possibly do to troubleshoot
the error?
Thanks a lot in advance!
Best wishes,
Sergi
___
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
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Recreating nebbiolo1's build environment
Hi Sergi,
I can't reproduce this on my laptop either (Ubuntu 21.10) or on nebbiolo1.
And it looks like the build results for rrvgo will look fine on all
platform today (report not available yet).
I suspect that the error was coming from a package that rrvgo depends on
and that it's been fixed now.
I strongly suspect GOSemSim:
commit 93e084381b6f73209da09b6564db7a30516e9b99 (HEAD -> master,
origin/master, origin/HEAD)
Author: Guangchuang Yu
Date: Mon Jan 10 10:12:55 2022 +0800
fixed #36 for returning NULL when it should be the input object
Cheers,
H.
On 11/01/2022 02:21, sergi sayols puig wrote:
Dear all,
Our package rrvgo has recently started to fail when building for BioC
3.15 (devel branch).
I'm trying to replicate the build environment as in nebbiolo1 in order
to reproduce the issue locally, with little success so far. I'm
following carefully the instructions provided in the build report, but
I must be missing something because I can build the package
successfully.
I tried both compiling R from source (snapshot
R-devel_2022-01-05_r81451.tar.gz) + installing the devel version of
Bioconductor, and also using the docker image of
bioconductor_docker:devel. Here I provide the steps I followed to
build from within the container, using vanilla .libPaths():
* pull docker image
$ docker pull bioconductor/bioconductor_docker:devel
* open shell in the running container:
$ docker exec -it bioconductor/bioconductor_docker:devel /bin/bash
* install package + dependencies (within the container):
# R
R> install.packages("BiocManager")
R> BiocManager::install(version='devel')
R> BiocManager::install(c("rrvgo", "org.Hs.eg.db")) # the second
is required in the vignette
R> q()
* clone the devel branch of the package:
# git clone https://git.bioconductor.org/packages/rrvgo
* get nebbiolo1's .Renviron:
# wget -qO-
http://bioconductor.org/checkResults/devel/bioc-LATEST/Renviron.bioc >
Renviron.bioc
* and build as described in the build report:
# R_ENVIRON_USER=Renviron.bioc R CMD build --keep-empty-dirs
--no-resave-data rrvgo
This will successfully build the tarball of the package, without complains.
Does anyone have any idea what I could possibly do to troubleshoot the error?
Thanks a lot in advance!
Best wishes,
Sergi
___
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
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] DataFrameList to Wide Format DataFrame
On 16/12/2021 23:00, Dario Strbenac via Bioc-devel wrote:
Hello,
Ah, yes, the sample names should of course be in the rows - Friday afternoon error. In
the question, I specified "largely the same set of features", implying that the
overlap is not complete. So, the example below will error.
DFL <- DataFrameList(X = DataFrame(a = 1:3, b = 3:1, row.names = LETTERS[1:3]),
Y = DataFrame(b = 4:6, c = 6:4, row.names =
LETTERS[20:22]))
unlist(DFL)
Error in .aggregate_and_align_all_colnames(all_colnames, strict.colnames =
strict.colnames) :
the DFrame objects to combine must have the same column names
unlist() uses rbind() internally to combine the rows and rbind() wants to see
the same columns in all the DataFrame to combines. combineRows() is a more
flexible version of rbind() that was added in BioC 3.13:
do.call(combineRows, unname(as.list(DFL)))
# DataFrame with 6 rows and 3 columns
# a b c
#
# A 1 3 NA
# B 2 2 NA
# C 3 1 NA
# T NA 4 6
# U NA 5 5
# V NA 6 4
If you want to discuss this further, please ask on the support site.
H.
This is long but works:
allFeatures <- unique(unlist(lapply(DFL, colnames)))
DFL <- lapply(DFL, function(DF)
{
missingFeatures <- setdiff(allFeatures, colnames(DF))
DF[missingFeatures] <- NA
DF
})
DFLflattened <- do.call(rbind, DFL)
Is there a one-line function for it?
--
Dario Strbenac
University of Sydney
Camperdown NSW 2050
Australia
___
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
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] DataFrameList to Wide Format DataFrame
A metadata column on a DataFrame runs along its 2nd dimension so is not a good place to put the list names. Have you tried unlist()? library(S4Vectors) DF <- DataFrame(id=letters[1:10], score=runif(10)) f <- sample(LETTERS[1:3], 10, replace=TRUE) DFL <- split(DF, f) DFL # SplitDataFrameList of length 3 # $A # DataFrame with 2 rows and 2 columns # id score # # 1 f 0.894709 # 2 h 0.801125 # # $B # DataFrame with 1 row and 2 columns # id score # # 1 d 0.538166 # # $C # DataFrame with 7 rows and 2 columns # id score # # 1 a 0.0145477 # 2 b 0.2507581 # 3 c 0.4388678 # 4 e 0.5219524 # 5 g 0.6377634 # 6 i 0.1892103 # 7 j 0.1829650 unlist(DFL) # DataFrame with 10 rows and 2 columns # id score # # A f 0.8947085 # A h 0.8011255 # B d 0.5381664 # C a 0.0145477 # C b 0.2507581 # C c 0.4388678 # C e 0.5219524 # C g 0.6377634 # C i 0.1892103 # C j 0.1829650 BTW this is a user question so is more appropriate for the support site. H. On 16/12/2021 22:00, Dario Strbenac via Bioc-devel wrote: Good day, Is there a function in the S4Vectors API which converts a DataFrameList into a DataFrame, automatically putting the list names into one of the metadata columns, analogous to MultiAssayExperiment's wideFormat function? The scenario is mutliple data sets from different organisations measuring the largely the same set of features and patient outcome, but on completely different sets of patients in each organisation. -- Dario Strbenac University of Sydney Camperdown NSW 2050 Australia ___ 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 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] MAGMA executable
Hi Kristian,
The package installation folder should never been written to once the
package has been installed. On many systems this is a read-only folder.
I didn't see any mention of Cygwin in your DESCRIPTION or README.md file.
Also I noticed some inconsistency between the system requirements listed
in DESCRIPTION and those listed in README.md (e.g. libgit2-dev).
At first glance, the process of getting all the external deps in place
seems pretty involved, even on Linux! I would suggest you focus on this
platform for now and try to make things easier for the user. Granted
they have all the required system libraries on their Linux machine (i.e.
libcurl4-openssl-dev, libssl-dev, libxml2-dev, libglu1-mesa-dev on
Ubuntu), anybody should be able to run 'R CMD build' and 'R CMD check'
on the package.
Cheers,
H.
On 13/12/2021 23:12, Kristian Ullrich wrote:
> Hi,
>
> I have a similar issue with my package
> https://gitlab.gwdg.de/mpievolbio-it/crbhits
>
> It relies on three dependencies, however in my situation the licensing
> was not a problem with these dependencies.
>
> They can be compiled on any unix system and so far the user need to
> compile them after the installation.
>
> They will be compiled into the R extdata folder, see e.g. here:
>
> https://gitlab.gwdg.de/mpievolbio-it/crbhits/-/blob/master/R/make_last.R
>
> Anyhow, I did not try yet to put it on Bioc, since the compilation for
> one of the dependencies would need the Cygwin dll to run on a windows
> machine.
>
> Does anyone have run into such a situation yet, since Cygwin and mingw
> come with their own licensing restrictions?
>
> I would need to put and distribute a pre-compiled exe and the dll file
> with my package and even do not know if this would pass the CRAN/Bioc
> checks, which I do not know would be covered by the licensing scheme.
>
> Thank you in anticipation
>
> Best regards
> --
> Kristian Ullrich, Ph.D.
> Max Planck Institute
> For Evolutionary Biology
>
> Scientific IT group
> Department of Evolutionary Biology
> August Thienemann Str. 2
> 24306 Plön
> Germany
> +49 4522 763 313
> ullr...@evolbio.mpg.de
>
> "It is part of it that thoughts run riot" (Mia)
>
> --
> CONFIDENTIALITY NOTICE:
> The contents of this email message and any attachments are intended
> solely for the addressee(s) and may contain confidential and/or
> privileged information and may be legally protected from disclosure.
> If you are not the intended recipient, you are hereby notified
> that any use, dissemination, copying, or storage of this message or
> its attachments is strictly prohibited.
>
> --
> Kristian Ullrich, Ph.D.
> Max Planck Institute
> For Evolutionary Biology
>
> Scientific IT group
> Department of Evolutionary Biology
> August Thienemann Str. 2
> 24306 Plön
> Germany
> +49 4522 763 313
> ullr...@evolbio.mpg.de
>
> "It is part of it that thoughts run riot" (Mia)
>
> --
> CONFIDENTIALITY NOTICE:
> The contents of this email message and any attachments are intended
> solely for the addressee(s) and may contain confidential and/or
> privileged information and may be legally protected from disclosure.
> If you are not the intended recipient, you are hereby notified
> that any use, dissemination, copying, or storage of this message or
> its attachments is strictly prohibited.
>
>> On 13. Dec 2021, at 18:46, Hervé Pagès
>> wrote:
>>
>> Hi Brian,
>>
>> Note that Rsamtools does not relies on any CLI tools. It contains
>> C/C++ code that is _compiled_ and _linked_ against Rhtslib rather
>> than relying on the standalone `samtools` and `tabix` commands.
>>
>> Installing MAGMA at package installation time in the package
>> installation folder of MAGMA.Celltyping means downloading MAGMA each
>> time MAGMA.Celltyping gets installed, including after each update of
>> MAGMA.Celltyping. This would be very unusual and would break the
>> general expectation that a local install with 'R CMD INSTALL
>> MAGMA.Celltyping' should work without the need to access the internet
>> to download additional stuff.
>>
>> Instead I would recommend the following:
>>
>> - Install in a more permanent location like
>> tools::R_user_dir("MAGMA.Celltyping", which="cache")
>>
>> - Do not install at package installation time or at package load
>> time. Instead, delay installation until it's needed, that is, until
>> the user calls a function that actually needs MAGMA. One way to
>> achieve this is by making sure that all your functions that rely on
>> MAGMA check its presence with magma_installed_version
Re: [Bioc-devel] Git recognizes me but denies access
On 12/12/2021 03:49, Philipp A. wrote: I think the easiest fix was to just switch to HTML vignettes, then destiny is no longer dependent on Bioconductor’s LaTeX environment staying stable. Let’s see in the next build if it worked. Just in case someone is watching this thread and wondering what we're doing with the LaTeX environment on the build machines. Short answer: nothing Detailed answer: - The Linux builders run Ubuntu 20.04 LTS which provides Tex Live. See https://github.com/Bioconductor/BBS/blob/master/Ubuntu-files/20.04/apt_vignettes_reference_manuals.txt for the exact list of Deb packages we install on the builders. That's all we install there as far as TeX/LaTeX is concerned. - The Windows builders use MiKTeX. We install MiKTeX once for all when we prepare a new Windows machine for the builds and that's it. We never touch it again. - The Mac builders use MacTeX which we also install once for all at prep time. All these installations are stock installations. We don't "tweak" them or try to define specific variable environments to change the default behavior. They just work out-of-the box like they would on the end-user machines. Just wanted to clarify. Cheers, H. If not, I’d like some support. The 24 hour turnaround of the build bots is too slow for incremental changes. Am Fr., 10. Dez. 2021 um 18:59 Uhr schrieb Vincent Carey < st...@channing.harvard.edu>: How are we doing with this? Can destiny be maintained? Do we need more git assistance? I am told the package is not passing check in 3.14. On Thu, Nov 18, 2021 at 4:24 AM Philipp A. wrote: My addresses are phil.ange...@gmail.com (not philipp) and flying-sh...@web.de. I’ll add a key as soon as I’m able to log in. Am Mo., 15. Nov. 2021 um 15:56 Uhr schrieb Nitesh Turaga < nturaga.b...@gmail.com>: You have to activate the account at https://git.bioconductor.org/BiocCredentials/account_activation. Set a password and add Ssh keys. Once again, the email you are trying to activate is ' philipp.ange...@gmail.com’. The problem seems to be non-matching key pairs. Add new SSH keys. Best, Nitesh Nitesh Turaga Scientist II, Department of Data Science, Bioconductor Core Team Member Dana Farber Cancer Institute On Nov 15, 2021, at 9:54 AM, Nitesh Turaga wrote: Hi Philipp, The email address that is registered to BiocCredentials right now is ' philipp.ange...@gmail.com'. It doesn’t look like an institutional email address. Could you please confirm the email change to flying-sh...@web.de ?? Best, Nitesh Nitesh Turaga Scientist II, Department of Data Science, Bioconductor Core Team Member Dana Farber Cancer Institute On Nov 15, 2021, at 2:36 AM, Carsten Marr < carsten.m...@helmholtz-muenchen.de> wrote: confirmed! best, c Am 13.11.2021 um 15:56 schrieb Philipp A. : I no longer have control of this email address. Please add the one I’m writing from to the account. My supervisor (CC) from when I was at the institution can confirm that I’m the same person. Best, Phil Am Di., 9. Nov. 2021 um 16:24 Uhr schrieb Nitesh Turaga < nturaga.b...@gmail.com>: Dear Phil, Please activate your account at https://git.bioconductor.org/BiocCredentials/account_activation. Add new SSH keys, because it’s possible you are not using the correct key-pairs. Nothing on our end seems out of place. The FAQ section from #13 onwards has other debugging options as well, https://bioconductor.org/developers/how-to/git/faq/. Best, Nitesh Nitesh Turaga Scientist II, Department of Data Science, Bioconductor Core Team Member Dana Farber Cancer Institute On Nov 8, 2021, at 12:23 PM, Philipp A. wrote: Hi, My package (destiny) has been deprecated because Bioconductor’s LaTeX environment keeps changing and breaking my docs. I‘m trying to fix it once again, but I get: $ git push upstream masterFATAL: W any packages/destiny p.angerer DENIED by fallthru *Please note that this isn’t covered in the FAQ*: “p.angerer” indicates that it recognizes me, but still doesn’t allow me to push commits. Best, Phil [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel --- Carsten Marr +49 89 3187 2158 AIH Institute of AI for Health Helmholtz Zentrum München www.helmholtz-muenchen.de/aih/index.html Helmholtz Zentrum München Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH) Ingolstädter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir.in Prof. Dr. Veronika von Messling Geschäftsführung: Prof. Dr. med. Dr. h.c. Matthias Tschöp, Kerstin Günther Registergericht: Amtsgericht München HRB 6466 USt-IdNr: DE 129521671 [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list
Re: [Bioc-devel] MAGMA executable
Hi Brian,
Note that Rsamtools does not relies on any CLI tools. It contains C/C++
code that is _compiled_ and _linked_ against Rhtslib rather than relying
on the standalone `samtools` and `tabix` commands.
Installing MAGMA at package installation time in the package
installation folder of MAGMA.Celltyping means downloading MAGMA each
time MAGMA.Celltyping gets installed, including after each update of
MAGMA.Celltyping. This would be very unusual and would break the general
expectation that a local install with 'R CMD INSTALL MAGMA.Celltyping'
should work without the need to access the internet to download
additional stuff.
Instead I would recommend the following:
- Install in a more permanent location like
tools::R_user_dir("MAGMA.Celltyping", which="cache")
- Do not install at package installation time or at package load time.
Instead, delay installation until it's needed, that is, until the user
calls a function that actually needs MAGMA. One way to achieve this is
by making sure that all your functions that rely on MAGMA check its
presence with magma_installed_version() and call magma_install() if
needed. If MAGMA's license requires that the user accepts an end-user
agreement, then your functions should not try to install MAGMA
automatically. They should just fail with an error asking the user to
call magma_install().
Another approach is to bundle MAGMA's source in MAGMA.Celltyping and
compile it at installation time but that's an entirely different story.
Hope this helps,
H.
On 13/12/2021 08:37, Brian Schilder wrote:
Thank you both for the helpful feedback. I’ll follow up with the developers of
MAGMA for clarification on license.
Regarding installation, I agree Kasper, this is not an ideal solution.
Installing MAGMA at the R package installation time would be ideal, but I’ve
been unable to come up with a way to do this.
I’ve been look to Rsamtools for
some sources of inspiration, since it relies on multiple CLI tools (rsamtools,
tabix). I’m unfamiliar with getting bash scripts to run while installing R packages,
but looking into this now.
Best,
Brian
On 13 Dec 2021, at 13:59, Kasper Daniel Hansen
wrote:
Ignoring the license issues (which may be significant), I strongly dislike this
installation strategy. It (IMO) unreasonable that you potentially write in
system locations on package load. You're looking in
/usr/local/bin
R.home/bin <- this makes not sense, this is the R home location, why should
anything else but R be here?
$HOME
working directory
In my opinion, if you want to do something like this, you need to do it at
installation time and you should install MAGMA in the package location.
On Thu, Dec 9, 2021 at 8:30 AM Vincent Carey mailto:st...@channing.harvard.edu>> wrote:
I didn't find an obvious licensing statement at the magma site. I did see
note that standard copyright applies; the MAGMA binaries and source code
may not be distributed or modified)
the licensing situation would affect my advice on this process, but others
may have other more
specific advice
On Thu, Dec 9, 2021 at 7:37 AM Brian Schilder <
brian_schil...@alumni.brown.edu > wrote:
Hi everyone,
I’m a developer for the R package MAGMA.Celltyping <
https://github.com/neurogenomics/MAGMA_Celltyping/tree/bschilder_dev
> (on
the bschilder_dev branch). It’s currently only distributed via GitHub but
I’m trying to get it on Bioc if possible. The dilemma is, it relies on
MAGMA >, which is only available as a
CLI program.
I have everything passing CRAN/Bioc checks on my local machine, but the
final hurdle is installing MAGMA > on
other machines (e.g. via GitHub Actions checks) such that it can be called
from within R.
Here’s the steps I’ve taken:
Upon .onLoad <
https://github.com/neurogenomics/MAGMA_Celltyping/blob/bschilder_dev/R/zzz.R
>
of MAGMA.Celltyping, magma_installed_version() <
https://github.com/neurogenomics/MAGMA_Celltyping/blob/bschilder_dev/R/magma_installed_version.R
>
will check whether MAGMA is installed. If not, it proceeds to try and
install it via magma_install() <
https://github.com/neurogenomics/MAGMA_Celltyping/blob/bschilder_dev/R/magma_install.R
>
.
magma_install() finds the latest version of MAGMA in their archives <
https://ctg.cncr.nl/software/MAGMA/prog/
[Bioc-devel] Many build report errors due to some regressions introduced in S4Vectors
Hi, While making some changes to S4Vectors, I introduced a couple of regressions that break many packages on today's devel report: https://bioconductor.org/checkResults/3.15/bioc-LATEST/ One is an infinite circular recursion error that looks like this: C stack usage 7977524 is too close to the limit The other one is an out-of-bounds index error that looks like this: [i,] index out of bounds or like this: [i,] index out of bounds (the name inside the angle brackets can actually be any SummarizedExperiment derivative). This seems to break about 120 software packages in devel. It also affects the books: https://bioconductor.org/checkResults/3.15/books-LATEST/ Sorry for that! It's now fixed in S4Vectors 0.33.7 and SummarizedExperiment 1.25.3 so hopefully things will clear out in the next couple of days. Apology for the inconvenience. Let me know if you have any questions about this. Best, H. -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
