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: [Rd] Question regarding .make_numeric_version with non-character input
On 4/25/24 07:04, Kurt Hornik wrote: ... > Sure, I'll look into adding something. (Too late for 4.4.0, of course.) > > Best > -k Great. Thanks! H. -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-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
Re: [Rd] Question regarding .make_numeric_version with non-character input
On 4/24/24 23:07, Kurt Hornik wrote:
>>>>>> Hervé Pagès writes:
>> Hi Kurt,
>> Is it intended that numeric_version() returns an error by default on
>> non-character input in R 4.4.0?
> Dear Herve, yes, that's the intention.
>
>> It seems that I can turn this into a warning by setting
>> _R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_=false but I don't
>> seem to be able to find any of this mentioned in the NEWS file.
> That's what I added for smoothing the transition: it will be removed
> from the trunk shortly.
Thanks for clarifying. Could this be documented in the NEWS file? This
is a breaking change (it breaks a couple of Bioconductor packages) and
people are not going to set this environment variable if they are not
aware of it.
Thanks again,
H.
>
> Best
> -k
>
>> Thanks,
>> H.
>> On 4/1/24 05:28, Kurt Hornik wrote:
>> Andrea Gilardi via R-devel writes:
>
>> Thanks: should be fixed now in the trunk.
>
>> Best
>> -k
>> Thank you very much Dirk for your kind words and for confirming the
>> bug.
>> Next week I will open a new issue on Bugzilla adding the related
>> patch.
>
>> Kind regards
>
>> Andrea
>
>> On 29/03/2024 20:14, Dirk Eddelbuettel wrote:
>
>> On 29 March 2024 at 17:56, Andrea Gilardi via R-devel wrote:
>> | Dear all,
>> |
>> | I have a question regarding the R-devel version of
>> .make_numeric_version() function. As far as I can understand, the current
>> code
>> (https://github.com/wch/r-source/blob/66b91578dfc85140968f07dd4e72d8cb8a54f4c6/src/library/base/R/version.R#L50-L56)
>> runs the following steps in case of non-character input:
>> |
>> | 1. It creates a message named msg using gettextf.
>> | 2. Such object is then passed to stop(msg) or warning(msg)
>> according to the following condition
>> |
>> |
>> tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") !=
>> "false")
>> |
>> | However, I don't understand the previous code since the
>> output of Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") !=
>> "false" is just a boolean value and tolower() will just return "true" or
>> "false". Maybe the intended code is
>> tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) !=
>> "false" ? Or am I missing something?
>
>> Yes, agreed -- good catch. In full, the code is (removing
>> leading
>> whitespace, and putting it back onto single lines)
>
>> msg <- gettextf("invalid non-character version specification
>> 'x' (type: %s)", typeof(x))
>>
>> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") !=
>> "false"))
>> stop(msg, domain = NA)
>> else
>> warning(msg, domain = NA, immediate. = TRUE)
>
>> where msg is constant (but reflecting language settings via
>> standard i18n)
>> and as you not the parentheses appear wrong. What was intended
>> is likely
>
>> msg <- gettextf("invalid non-character version specification
>> 'x' (type: %s)", typeof(x))
>>
>> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_"))
>> != "false")
>> stop(msg, domain = NA)
>> else
>> warning(msg, domain = NA, immediate. = TRUE)
>
>> If you use bugzilla before and have a handle, maybe file a bug
>> report with
>> this as patch athttps://bugs.r-project.org/
>
>> Dirk
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>> --
>> 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]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question regarding .make_numeric_version with non-character input
Hi Kurt,
Is it intended that numeric_version() returns an error by default on
non-character input in R 4.4.0? It seems that I can turn this into a
warning by setting
_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_=false but I don't seem
to be able to find any of this mentioned in the NEWS file.
Thanks,
H.
On 4/1/24 05:28, Kurt Hornik wrote:
>>>>>> Andrea Gilardi via R-devel writes:
> Thanks: should be fixed now in the trunk.
>
> Best
> -k
>
>> Thank you very much Dirk for your kind words and for confirming the bug.
>> Next week I will open a new issue on Bugzilla adding the related patch.
>> Kind regards
>> Andrea
>> On 29/03/2024 20:14, Dirk Eddelbuettel wrote:
>>> On 29 March 2024 at 17:56, Andrea Gilardi via R-devel wrote:
>>> | Dear all,
>>> |
>>> | I have a question regarding the R-devel version of
>>> .make_numeric_version() function. As far as I can understand, the current
>>> code
>>> (https://github.com/wch/r-source/blob/66b91578dfc85140968f07dd4e72d8cb8a54f4c6/src/library/base/R/version.R#L50-L56)
>>> runs the following steps in case of non-character input:
>>> |
>>> | 1. It creates a message named msg using gettextf.
>>> | 2. Such object is then passed to stop(msg) or warning(msg) according to
>>> the following condition
>>> |
>>> | tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") !=
>>> "false")
>>> |
>>> | However, I don't understand the previous code since the output of
>>> Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != "false"
>>> is just a boolean value and tolower() will just return "true" or "false".
>>> Maybe the intended code is
>>> tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) !=
>>> "false" ? Or am I missing something?
>>>
>>> Yes, agreed -- good catch. In full, the code is (removing leading
>>> whitespace, and putting it back onto single lines)
>>>
>>> msg <- gettextf("invalid non-character version specification 'x' (type:
>>> %s)", typeof(x))
>>> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")
>>> != "false"))
>>> stop(msg, domain = NA)
>>> else
>>> warning(msg, domain = NA, immediate. = TRUE)
>>>
>>> where msg is constant (but reflecting language settings via standard i18n)
>>> and as you not the parentheses appear wrong. What was intended is likely
>>>
>>> msg <- gettextf("invalid non-character version specification 'x' (type:
>>> %s)", typeof(x))
>>> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_"))
>>> != "false")
>>> stop(msg, domain = NA)
>>> else
>>> warning(msg, domain = NA, immediate. = TRUE)
>>>
>>> If you use bugzilla before and have a handle, maybe file a bug report with
>>> this as patch athttps://bugs.r-project.org/
>>>
>>> Dirk
>>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Hervé Pagès
Bioconductor Core Team
hpages.on.git...@gmail.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-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: [Rd] Spurious warning in as.data.frame.factor()
Thanks Martin. We'll update the BioC builders to the latest R devel soon.
Cheers,
H.
On 3/15/24 10:26, Martin Maechler wrote:
>>>>>> Martin Maechler
>>>>>> on Fri, 15 Mar 2024 11:24:22 +0100 writes:
>>>>>> Ivan Krylov
>>>>>> on Thu, 14 Mar 2024 14:17:38 +0300 writes:
> >> On Thu, 14 Mar 2024 10:41:54 +0100
> >> Martin Maechler wrote:
>
> >>> Anybody trying S7 examples and see if they work w/o producing
> >>> wrong warnings?
>
> >> It looks like this is not applicable to S7. If I overwrite
> >> as.data.frame with a newly created S7 generic, it fails to dispatch on
> >> existing S3 classes:
>
> >> new_generic('as.data.frame', 'x')(factor(1))
> >> # Error: Can't find method for `as.data.frame(S3)`.
>
> >> But there is no need to overwrite the generic, because S7 classes
> >> should work with existing S3 generics:
>
> >> foo <- new_class('foo', parent = class_double)
> >> method(as.data.frame, foo) <- function(x) structure(
> >> # this is probably not generally correct
> >> list(x),
> >> names = deparse1(substitute(x)),
> >> row.names = seq_len(length(x)),
> >> class = 'data.frame'
> >> )
> >> str(as.data.frame(foo(pi)))
> >> # 'data.frame': 1 obs. of 1 variable:
> >> # $ x: num 3.14
>
> >> So I think that is nothing to break because S7 methods for
> >> as.data.frame will rely on S3 for dispatch.
>
> > Yes, as it should be. Thank you for checking..
>
>
> >>> > The patch passes make check-devel, but I'm not sure how to safely
> >>> > put setGeneric('as.data.frame'); as.data.frame(factor(1:10)) in a
> >>> > regression test.
> >>>
> >>> {What's the danger/problem? we do have "similar" tests in both
> >>> src/library/methods/tests/*.R
> >>> tests/reg-S4.R
> >>>
> >>> -- maybe we can discuss bi-laterally (or here, as you prefer)
> >>> }
>
> >> This might be educational for other people wanting to add a regression
> >> test to their patch. I see that tests/reg-tests-1e.R is already
> running
> >> under options(warn = 2), so if I add the following near line 750
> >> ("Deprecation of *direct* calls to as.data.frame.")...
>
> >> # Should not warn for a call from a derivedDefaultMethod to the raw
> >> # S3 method -- implementation detail of S4 dispatch
> >> setGeneric('as.data.frame')
> >> as.data.frame(factor(1))
>
> >> ...then as.data.frame will remain an S4 generic. Should the test then
> >> rm(as.data.frame) and keep going? (Or even keep the S4 generic?) Is
> >> there any hidden state I may be breaking for the rest of the test this
> >> way?
> >> The test does pass like this, so this may be worrying about nothing.
>
> > Indeed, this could be educational; I think just adding
>
> > removeGeneric('as.data.frame')
>
> > is appropriate here as it is self-explaining and should not leave
> > much traces.
>
> > I'm about to test this in reg-tests-1e.R and with make check-all
> > and commit later today,
> > thanking you, Ivan!
>
> This has been committed to R-devel svn rev 86139 now.
>
> So these spurious warnings in situations where as.data.frame()
> is an S4 generic --- notably for the many Bioconductor package
> depending on {BiocGenerics} --- should disappear within 24
> hours or less.
>
> Martin
--
Hervé Pagès
Bioconductor Core Team
hpages.on.git...@gmail.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Spurious warning in as.data.frame.factor()
Hi,
The acrobatics that as.data.frame.factor() is going thru in order to
recognize a direct call don't play nice if as.data.frame() is an S4
generic:
df <- as.data.frame(factor(11:12))
suppressPackageStartupMessages(library(BiocGenerics))
isGeneric("as.data.frame")
# [1] TRUE
df <- as.data.frame(factor(11:12))
# Warning message:
# In as.data.frame.factor(factor(11:12)) :
# Direct call of 'as.data.frame.factor()' is deprecated. Use
'as.data.frame.vector()' or 'as.data.frame()' instead
This spurious warning showed up on the recent Bioconductor daily build
reports after we've updated the build machines to the latest R devel.
It's causing some confusion and breaks at least one unit test.
Thanks,
H.
> sessionInfo()
R Under development (unstable) (2024-03-06 r86056)
Platform: x86_64-pc-linux-gnu
Running under: Ubuntu 22.04.4 LTS
Matrix products: default
BLAS: /home/biocbuild/bbs-3.19-bioc/R/lib/libRblas.so
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.10.0
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_GB 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/New_York
tzcode source: system (glibc)
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] BiocGenerics_0.49.1
loaded via a namespace (and not attached):
[1] compiler_4.4.0
--
Hervé Pagès
Bioconductor Core Team
hpages.on.git...@gmail.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-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: [Rd] NOTE: multiple local function definitions for ?fun? with different formal arguments
Thanks. Workarounds are interesting but... what's the point of the NOTE
in the first place?
H.
On 2/4/24 09:07, Duncan Murdoch wrote:
> On 04/02/2024 10:55 a.m., Izmirlian, Grant (NIH/NCI) [E] via R-devel
> wrote:
>> Well you can see that yeast is exactly weekday you have. The way out
>> is to just not name the result
>
> I think something happened to your explanation...
>
>>
>> toto <- function(mode)
>> {
>> ifelse(mode == 1,
>> function(a,b) a*b,
>> function(u, v, w) (u + v) / w)
>> }
>
> It's a bad idea to use ifelse() when you really want if() ... else ...
> . In this case it works, but it doesn't always. So the workaround
> should be
>
>
> toto <- function(mode)
> {
> if(mode == 1)
> function(a,b) a*b
> else
> function(u, v, w) (u + v) / w
> }
>
>
>>
>>
>>
>> From: Grant Izmirlian
>> Date: Sun, Feb 4, 2024, 10:44 AM
>> To: "Izmirlian, Grant (NIH/NCI) [E]"
>> Subject: Fwd: [EXTERNAL] R-devel Digest, Vol 252, Issue 2
>>
>> Hi,
>>
>> I just ran into this 'R CMD check' NOTE for the first time:
>>
>> * checking R code for possible problems ... NOTE
>> toto: multiple local function definitions for �fun� with different
>> formal arguments
>>
>> The "offending" code is something like this (simplified from the real
>> code):
>>
>> toto <- function(mode)
>> {
>> if (mode == 1)
>> fun <- function(a, b) a*b
>> else
>> fun <- function(u, v, w) (u + v) / w
>> fun
>> }
>>
>> Is that NOTE really intended? Hard to see why this code would be
>> considered "wrong".
>>
>> I know it's just a NOTE but still...
>
> I agree it's a false positive, but the issue is that you have a
> function object in your function which can't be called
> unconditionally. The workaround doesn't create such an object.
>
> Recognizing that your function never tries to call fun requires global
> inspection of toto(), and most of the checks are based on local
> inspection.
>
> Duncan Murdoch
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Hervé Pagès
Bioconductor Core Team
hpages.on.git...@gmail.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
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
[Rd] NOTE: multiple local function definitions for ‘fun’ with different formal arguments
Hi,
I just ran into this 'R CMD check' NOTE for the first time:
* checking R code for possible problems ... NOTE
toto: multiple local function definitions for ‘fun’ with different
formal arguments
The "offending" code is something like this (simplified from the real code):
toto <- function(mode)
{
if (mode == 1)
fun <- function(a, b) a*b
else
fun <- function(u, v, w) (u + v) / w
fun
}
Is that NOTE really intended? Hard to see why this code would be
considered "wrong".
I know it's just a NOTE but still...
Thanks,
H.
--
Hervé Pagès
Bioconductor Core Team
hpages.on.git...@gmail.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-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: [Rd] Should subsetting named vector return named vector including named unmatched elements?
Never been a big fan of this behavior either but maybe the intention was
to make it easier to distinguish between 2 types of NAs in the result:
those that were present in the original vector vs those that are
introduced by an unmatched subscript. Like in this example:
x <- setNames(c(101:108, NA), letters[1:9])
x
# a b c d e f g h i
# 101 102 103 104 105 106 107 108 NA
x[c("g", "k", "a", "i")]
# g a i
# 107 NA 101 NA
The first NA is the result of an unmatched subscript, while the second
one comes from 'x'.
This is of limited interest though. In most real world applications I've
worked on, we actually need to "fix" the names of the result.
Best,
H.
On 1/18/24 11:51, Jiří Moravec wrote:
> Subsetting vector (including lists) returns the same number of
> elements as the subsetting vector, including unmatched elements which
> are reported as `NA` or `NULL` (in case of lists).
>
> Consider:
>
> ```
> menu = list(
> "bacon" = "foo",
> "eggs" = "bar",
> "beans" = "baz"
> )
>
> select = c("bacon", "eggs", "spam")
>
> menu[select]
> # $bacon
> # [1] "foo"
> #
> # $eggs
> # [1] "bar"
> #
> # $
> # NULL
>
> ```
>
> Wouldn't it be more logical to return named vector/list including
> names of unmatched elements when subsetting using names? After all,
> the unmatched elements are already returned. I.e., the output would
> look like this:
>
> ```
>
> menu[select]
> # $bacon
> # [1] "foo"
> #
> # $eggs
> # [1] "bar"
> #
> # $spam
> # NULL
>
> ```
>
> The simple fix `menu[select] |> setNames(select)` solves, but it feels
> to me like something that could be a default behaviour.
>
> On slightly unrelated note, when I was asking if there is a better
> solution, the `menu[select]` seems to allocate more memory than
> `menu_env = list2env(menu); mget(select, envir = menu, ifnotfound =
> list(NULL)`. Or the sapply solution. Is this a benchmarking artifact?
>
> https://stackoverflow.com/q/77828678/4868692
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Hervé Pagès
Bioconductor Core Team
hpages.on.git...@gmail.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-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: [Rd] 'R CMD INSTALL' keeps going on despite serious errors, and returns exit code 0
I see. We'll update soon. Thanks Martin.
On 11/4/23 06:52, Martin Maechler wrote:
>>>>>> Hervé Pagès
>>>>>> on Fri, 3 Nov 2023 15:10:40 -0700 writes:
> > Hi list,
>
> > Here is an example:
>
> > hpages@XPS15:~$ R CMD INSTALL CoreGx * installing
>
>
> > hpages@XPS15:~$ R CMD INSTALL CoreGx
> > * installing to library ‘/home/hpages/R/R-4.4.r85388/site-library’
> ^^^
>
> Yes, this was bad behavior was the case for a short time (too
> long, my fault !!) in R-devel.
>
> But that, svn rev 85388 , was *long* ago (close to 2 weeks):
> Current R-devel is 85471
> (The bug was "only" in 382--388, fixed in 389 -- you were really unlucky!)
>
> Still, I'm sorry that you were accidentally affected, too.
> Martin
>
>
> > * installing *source* package ‘CoreGx’ ...
> > ** using staged installation
> > ** R
> > ** data
> > *** moving datasets to lazyload DB
> > ** inst
> > ** byte-compile and prepare package for lazy loading
> > Error : in method for ‘updateObject’ with signature
> > ‘object="CoreSet"’: arguments (‘verbose’) after ‘...’ in the generic
> > must appear in the method, in the same place at the end of the
> argument list
> > Error: unable to load R code in package ‘CoreGx’
> > ** help
> > *** installing help indices
> > ** building package indices
> > ** installing vignettes
> > ** testing if installed package can be loaded from temporary
> location
> > Error : in method for ‘updateObject’ with signature
> > ‘object="CoreSet"’: arguments (‘verbose’) after ‘...’ in the generic
> > must appear in the method, in the same place at the end of the
> argument list
> > Error: package or namespace load failed for ‘CoreGx’:
> > unable to load R code in package ‘CoreGx’
> > Error: loading failed
> > ** testing if installed package can be loaded from final location
> > Error : in method for ‘updateObject’ with signature
> > ‘object="CoreSet"’: arguments (‘verbose’) after ‘...’ in the generic
> > must appear in the method, in the same place at the end of the
> argument list
> > Error: package or namespace load failed for ‘CoreGx’:
> > unable to load R code in package ‘CoreGx’
> > Error: loading failed
> > Error : in method for ‘updateObject’ with signature
> > ‘object="CoreSet"’: arguments (‘verbose’) after ‘...’ in the generic
> > must appear in the method, in the same place at the end of the
> argument list
> > Error: unable to load R code in package ‘CoreGx’
> > ** testing if installed package keeps a record of temporary
> > installation path
> > * DONE (CoreGx)
>
> > Many serious errors were ignored. Plus the command returned exit code
> 0:
>
> > hpages@XPS15:~$ echo $?
> > 0
>
> > This is with R 4.4, that BioC 3.19 will be based on and that we only
> > started to use recently for our daily builds.
>
> > Strangely, we only see this on Linux. On Windows and Mac, we get the
> > usual hard error, as expected. See:
>
> > -
>
> >https://bioconductor.org/checkResults/3.19/bioc-LATEST/CoreGx/nebbiolo1-install.html
>
> > -
>
> >https://bioconductor.org/checkResults/3.19/bioc-LATEST/CoreGx/palomino3-install.html
>
> > -
>
> >https://bioconductor.org/checkResults/3.19/bioc-LATEST/CoreGx/merida1-install.html
>
> > To reproduce:
>
> > library(remotes)
> > install_git("https://git.bioconductor.org/packages/CoreGx;)
>
> > Thanks,
>
> > H.
>
> >> sessionInfo()
> > R Under development (unstable) (2023-10-22 r85388)
> > Platform: x86_64-pc-linux-gnu
> > Running under: Ubuntu 23.10
>
> > Matrix products: default
> > BLAS: /home/hpages/R/R-4.4.r85388/lib/libRblas.so
> > LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.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
Re: [Rd] 'R CMD INSTALL' keeps going on despite serious errors, and returns exit code 0
Forgot to mention that the package actually got installed, but is
unloadable (not surprisingly):
> "CoreGx" %in% rownames(installed.packages())
[1] TRUE
> suppressWarnings(suppressMessages(library(CoreGx)))
Error : in method for ‘updateObject’ with signature
‘object="CoreSet"’: arguments (‘verbose’) after ‘...’ in the generic
must appear in the method, in the same place at the end of the argument list
Error: package or namespace load failed for ‘CoreGx’:
unable to load R code in package ‘CoreGx’
Best,
H.
On 11/3/23 15:10, Hervé Pagès wrote:
>
> Hi list,
>
> Here is an example:
>
> hpages@XPS15:~$ R CMD INSTALL CoreGx
> * installing to library ‘/home/hpages/R/R-4.4.r85388/site-library’
> * installing *source* package ‘CoreGx’ ...
> ** using staged installation
> ** R
> ** data
> *** moving datasets to lazyload DB
> ** inst
> ** byte-compile and prepare package for lazy loading
> Error : in method for ‘updateObject’ with signature
> ‘object="CoreSet"’: arguments (‘verbose’) after ‘...’ in the generic
> must appear in the method, in the same place at the end of the
> argument list
> Error: unable to load R code in package ‘CoreGx’
> ** help
> *** installing help indices
> ** building package indices
> ** installing vignettes
> ** testing if installed package can be loaded from temporary location
> Error : in method for ‘updateObject’ with signature
> ‘object="CoreSet"’: arguments (‘verbose’) after ‘...’ in the generic
> must appear in the method, in the same place at the end of the
> argument list
> Error: package or namespace load failed for ‘CoreGx’:
> unable to load R code in package ‘CoreGx’
> Error: loading failed
> ** testing if installed package can be loaded from final location
> Error : in method for ‘updateObject’ with signature
> ‘object="CoreSet"’: arguments (‘verbose’) after ‘...’ in the generic
> must appear in the method, in the same place at the end of the
> argument list
> Error: package or namespace load failed for ‘CoreGx’:
> unable to load R code in package ‘CoreGx’
> Error: loading failed
> Error : in method for ‘updateObject’ with signature
> ‘object="CoreSet"’: arguments (‘verbose’) after ‘...’ in the generic
> must appear in the method, in the same place at the end of the
> argument list
> Error: unable to load R code in package ‘CoreGx’
> ** testing if installed package keeps a record of temporary
> installation path
> * DONE (CoreGx)
>
> Many serious errors were ignored. Plus the command returned exit code 0:
>
> hpages@XPS15:~$ echo $?
> 0
>
> This is with R 4.4, that BioC 3.19 will be based on and that we only
> started to use recently for our daily builds.
>
> Strangely, we only see this on Linux. On Windows and Mac, we get the
> usual hard error, as expected. See:
>
> -
> https://bioconductor.org/checkResults/3.19/bioc-LATEST/CoreGx/nebbiolo1-install.html
>
> -
> https://bioconductor.org/checkResults/3.19/bioc-LATEST/CoreGx/palomino3-install.html
>
> -
> https://bioconductor.org/checkResults/3.19/bioc-LATEST/CoreGx/merida1-install.html
>
> To reproduce:
>
> library(remotes)
> install_git("https://git.bioconductor.org/packages/CoreGx;)
>
> Thanks,
>
> H.
>
> > sessionInfo()
> R Under development (unstable) (2023-10-22 r85388)
> Platform: x86_64-pc-linux-gnu
> Running under: Ubuntu 23.10
>
> Matrix products: default
> BLAS: /home/hpages/R/R-4.4.r85388/lib/libRblas.so
> LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.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
>
> other attached packages:
> [1] remotes_2.4.2.1
>
> loaded via a namespace (and not attached):
> [1] processx_3.8.2 compiler_4.4.0 R6_2.5.1 rprojroot_2.0.3
> [5] cli_3.6.1 prettyunits_1.2.0 tools_4.4.0 crayon_1.5.2
> [9] desc_1.4.2 callr_3.7.3 pkgbuild_1.4.2 ps_1.7.5
>
> --
> 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]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] 'R CMD INSTALL' keeps going on despite serious errors, and returns exit code 0
Hi list,
Here is an example:
hpages@XPS15:~$ R CMD INSTALL CoreGx
* installing to library ‘/home/hpages/R/R-4.4.r85388/site-library’
* installing *source* package ‘CoreGx’ ...
** using staged installation
** R
** data
*** moving datasets to lazyload DB
** inst
** byte-compile and prepare package for lazy loading
Error : in method for ‘updateObject’ with signature
‘object="CoreSet"’: arguments (‘verbose’) after ‘...’ in the generic
must appear in the method, in the same place at the end of the argument list
Error: unable to load R code in package ‘CoreGx’
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded from temporary location
Error : in method for ‘updateObject’ with signature
‘object="CoreSet"’: arguments (‘verbose’) after ‘...’ in the generic
must appear in the method, in the same place at the end of the argument list
Error: package or namespace load failed for ‘CoreGx’:
unable to load R code in package ‘CoreGx’
Error: loading failed
** testing if installed package can be loaded from final location
Error : in method for ‘updateObject’ with signature
‘object="CoreSet"’: arguments (‘verbose’) after ‘...’ in the generic
must appear in the method, in the same place at the end of the argument list
Error: package or namespace load failed for ‘CoreGx’:
unable to load R code in package ‘CoreGx’
Error: loading failed
Error : in method for ‘updateObject’ with signature
‘object="CoreSet"’: arguments (‘verbose’) after ‘...’ in the generic
must appear in the method, in the same place at the end of the argument list
Error: unable to load R code in package ‘CoreGx’
** testing if installed package keeps a record of temporary
installation path
* DONE (CoreGx)
Many serious errors were ignored. Plus the command returned exit code 0:
hpages@XPS15:~$ echo $?
0
This is with R 4.4, that BioC 3.19 will be based on and that we only
started to use recently for our daily builds.
Strangely, we only see this on Linux. On Windows and Mac, we get the
usual hard error, as expected. See:
-
https://bioconductor.org/checkResults/3.19/bioc-LATEST/CoreGx/nebbiolo1-install.html
-
https://bioconductor.org/checkResults/3.19/bioc-LATEST/CoreGx/palomino3-install.html
-
https://bioconductor.org/checkResults/3.19/bioc-LATEST/CoreGx/merida1-install.html
To reproduce:
library(remotes)
install_git("https://git.bioconductor.org/packages/CoreGx;)
Thanks,
H.
> sessionInfo()
R Under development (unstable) (2023-10-22 r85388)
Platform: x86_64-pc-linux-gnu
Running under: Ubuntu 23.10
Matrix products: default
BLAS: /home/hpages/R/R-4.4.r85388/lib/libRblas.so
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.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
other attached packages:
[1] remotes_2.4.2.1
loaded via a namespace (and not attached):
[1] processx_3.8.2 compiler_4.4.0 R6_2.5.1 rprojroot_2.0.3
[5] cli_3.6.1 prettyunits_1.2.0 tools_4.4.0 crayon_1.5.2
[9] desc_1.4.2 callr_3.7.3 pkgbuild_1.4.2 ps_1.7.5
--
Hervé Pagès
Bioconductor Core Team
hpages.on.git...@gmail.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-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: [Rd] dim<-() changed in R-devel; no longer removing "dimnames" when doing dim(x) <- dim(x)
Hi Martin, Henrik,
I actually like this change.
Makes a lot of sense IMO that dim(x) <- dim(x) be a no-op, or, more
generally, that foo(x) <- foo(x) be a no-op for any setter/getter combo.
FWIW S4Arrays::set_dim() does that too. It also preserves the dimnames
if the right value is only adding or dropping outermost (ineffective)
dimensions:
> x <- array(1:6, dim=c(2,3,1), dimnames=list(c("A", "B"),
c("x","y", "z"), "T"))
> S4Arrays:::set_dim(x, 2:3)
x y z
A 1 3 5
B 2 4 6
Note that this is consistent with drop().
Best,
H.
On 10/30/23 03:53, Martin Maechler wrote:
>>>>>> Henrik Bengtsson
>>>>>> on Sun, 29 Oct 2023 10:42:19 -0700 writes:
> > Hello,
>
> > the fix of PR18612
> > (https://bugs.r-project.org/show_bug.cgi?id=18612) in
> > r85380
> >
> (https://github.com/wch/r-source/commit/2653cc6203fce4c48874111c75bbccac3ac4e803)
> > caused a change in `dim<-()`. Specifically, in the past,
> > any `dim<-()` assignment would _always_ remove "dimnames"
> > and "names" attributes per help("dim"):
>
>
> > The replacement method changes the "dim" attribute
> > (provided the new value is compatible) and removes any
> > "dimnames" and "names" attributes.
>
> > In the new version, assigning the same "dim" as before
> > will no longer remove "dimnames". I'm reporting here to
> > check whether this change was intended, or if it was an
> > unintended side effect of the bug fix.
>
> > For example, in R Under development (unstable) (2023-10-21
> > r85379), we would get:
>
> >> x <- array(1:2, dim=c(1,2), dimnames=list("A",
> >> c("a","b"))) str(dimnames(x))
> > List of 2 $ : chr "A" $ : chr [1:2] "a" "b"
>
> >> dim(x) <- dim(x) ## Removes "dimnames" no matter what
> >> str(dimnames(x))
> > NULL
>
>
> > whereas in R Under development (unstable) (2023-10-21
> > r85380) and beyond, we now get:
>
> >> x <- array(1:2, dim=c(1,2), dimnames=list("A",
> >> c("a","b"))) str(dimnames(x))
> > List of 2 $ : chr "A" $ : chr [1:2] "a" "b"
>
> >> dim(x) <- dim(x) ## No longer removes "dimnames"
> >> str(dimnames(x))
> > List of 2 $ : chr "A" $ : chr [1:2] "a" "b"
>
> >> dim(x) <- rev(dim(x)) ## Still removes "dimnames"
> >> str(dimnames(x))
> > NULL
>
> > /Henrik
>
> Thank you, Henrik.
>
> This is "funny" (in an unusal sense):
> indeed, the change was *in*advertent, by me (svn rev 85380).
>
> I had experimentally {i.e., only in my own private version of R-devel!}
> modified the behavior of `dim<-` somewhat
> such it does *not* unnecessarily drop dimnames,
> e.g., in your `dim(x) <- dim(x)` case above,
> one could really argue that it's a "true loss" if x loses
> dimnames "unnecessarily" ...
>
> OTOH, I knew in the mean time that `dim<-` has always been
> documented to drop dimnames in all cases, and even more
> importantly, I got a strong recommendation to *not* go further
> with this idea -- not only for back compatibility reasons, but
> also for internal logical consistency.
>
> Most probably, we will just revert this inadvertent change,
> but before that ... since it has been out in the wild anyway,
> we could quickly consider if it *did* break code.
>
> I assume it did, or you would not have noticed ?
>
> Martin
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Hervé Pagès
Bioconductor Core Team
hpages.on.git...@gmail.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-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: [Rd] as(, "dgTMatrix")' is deprecated.
Hi Martin,
On 10/3/23 10:17, Martin Maechler wrote:
>>>>>> Duncan Murdoch
>>>>>> on Tue, 3 Oct 2023 12:59:10 -0400 writes:
> > On 03/10/2023 12:50 p.m., Koenker, Roger W wrote:
> >> I’ve been getting this warning for a while now (about
> >> five years if memory serves) and I’m finally tired of it,
> >> but also too tired to track it down in Matrix. As far as
> >> I can grep I have no reference to either deprecated
> >> object, only the apparently innocuous Matrix::Matrix(A,
> >> sparse = TRUE). Can someone advise, Martin perhaps? I
> >> thought it might come from Rmosek, but mosek folks don’t
> >> think so.
> >>https://groups.google.com/g/mosek/c/yEwXmMfHBbg/m/l_mkeM4vAAAJ
>
> > A quick scan of that discussion didn't turn up anything
> > relevant, e.g. a script to produce the warning. Could you
> > be more specific, or just post the script here?
>
> > In general, a good way to locate the source of a warning
> > is to set options(warn=2) to turn it into an error, and
> > then trigger it. The traceback from the error will
> > include a bunch of junk from the code that catches the
> > warning, but it will also include the context where it was
> > triggered.
>
> > Duncan Murdoch
>
> Indeed.
>
> But Roger is right that it in the end, (almost surely) it is
> from our {Matrix} package.
>
> Indeed for several years now, we have tried to make the setup
> leaner (and hence faster) by not explicitly define coercion
> from to because the size of
> is here about 200, and we don't want to have to provide
> 200^2 = 40'000 coercion methods.
40,000 coercion methods sounds indeed crazy. But have you considered
having 200 coercions from ANY to ?
For example the coercion from ANY to dgTMatrix would do as(as(as(from,
"dMatrix"), "generalMatrix"), "TsparseMatrix").
Maybe the ANY->xyzMatrix methods could even be generated programmatically?
Best,
H.
>
> Rather, Matrix package users should use to high level abstract Matrix
> classes such as "sparseMatrix" or "CsparseMatrix" or
> "TsparseMatrix" or "dMatrix", "symmetricMatrix".
>
> In the case of as(, "dgTMatrix") , if you
> replace "dgTMatrix" by "TsparseMatrix"
> the result will be the same but also work in the future when the
> deprecation may have been turned into a defunctation ...
>
> Martin
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Hervé Pagès
Bioconductor Core Team
hpages.on.git...@gmail.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-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: [Rd] Recent changes to as.complex(NA_real_)
On 9/25/23 07:05, Martin Maechler wrote: >>>>>> Hervé Pagès >>>>>> on Sat, 23 Sep 2023 16:52:21 -0700 writes: > > Hi Martin, > > On 9/23/23 06:43, Martin Maechler wrote: > >>>>>>> Hervé Pagès > >>>>>>> on Fri, 22 Sep 2023 16:55:05 -0700 writes: > >> > The problem is that you have things that are > >> > **semantically** different but look exactly the same: > >> > >> > They look the same: > >> > >> >> x > >> > [1] NA > >> >> y > >> > [1] NA > >> >> z > >> > [1] NA > >> > >> >> is.na(x) > >> > [1] TRUE > >> >> is.na(y) > >> > [1] TRUE > >> >> is.na(z) > >> > [1] TRUE > >> > >> >> str(x) > >> > cplx NA > >> >> str(y) > >> > num NA > >> >> str(z) > >> > cplx NA > >> > >> > but they are semantically different e.g. > >> > >> >> Re(x) > >> > [1] NA > >> >> Re(y) > >> > [1] -0.5 # surprise! > >> > >> >> Im(x) # surprise! > >> > [1] 2 > >> >> Im(z) > >> > [1] NA > >> > >> > so any expression involving Re() or Im() will produce > >> > different results on input that look the same on the > >> > surface. > >> > >> > You can address this either by normalizing the internal > >> > representation of complex NA to always be complex(r=NaN, > >> > i=NA_real_), like for NA_complex_, or by allowing the > >> > infinite variations that are currently allowed and at the > >> > same time making sure that both Re() and Im() always > >> > return NA_real_ on a complex NA. > >> > >> > My point is that the behavior of complex NA should be > >> > predictable. Right now it's not. Once it's predictable > >> > (with Re() and Im() both returning NA_real_ regardless of > >> > internal representation), then it no longer matters what > >> > kind of complex NA is returned by as.complex(NA_real_), > >> > because they are no onger distinguishable. > >> > >> > H. > >> > >> > On 9/22/23 13:43, Duncan Murdoch wrote: > >> >> Since the result of is.na(x) is the same on each of > >> >> those, I don't see a problem. As long as that is > >> >> consistent, I don't see a problem. You shouldn't be using > >> >> any other test for NA-ness. You should never be > >> >> expecting identical() to treat different types as the > >> >> same (e.g. identical(NA, NA_real_) is FALSE, as it > >> >> should be). If you are using a different test, that's > >> >> user error. > >> >> > >> >> Duncan Murdoch > >> >> > >> >> On 22/09/2023 2:41 p.m., Hervé Pagès wrote: > >> >>> We could also question the value of having an infinite > >> >>> number of NA representations in the complex space. For > >> >>> example all these complex values are displayed the same > >> >>> way (as NA), are considered NAs by is.na(), but are not > >> >>> identical or semantically equivalent (from an Re() or > >> >>> Im() point of view): > >> >>> > >> >>> NA_real_ + 0i > >> >>> > >> >>> complex(r=NA_real_, i=Inf) > >> >>> > >> >>> complex(r=2, i=NA_real_) > >> >>> > >> >>> complex(r=NaN, i=NA_real_) > >> >>> > >> >>> In other words, using a single representation for > >> >>> complex NA (i.e. complex(r=NA_real_, i=NA_real_)) would > >> >>> avoid a lot of unnecessary complications and surprises. > >> >>> > >> >>> Once you do that, whether as.complex(NA_real_) should &
Re: [Rd] Recent changes to as.complex(NA_real_)
Hi Martin, On 9/23/23 06:43, Martin Maechler wrote: >>>>>> Hervé Pagès >>>>>> on Fri, 22 Sep 2023 16:55:05 -0700 writes: > > The problem is that you have things that are > > **semantically** different but look exactly the same: > > > They look the same: > > >> x > > [1] NA > >> y > > [1] NA > >> z > > [1] NA > > >> is.na(x) > > [1] TRUE > >> is.na(y) > > [1] TRUE > >> is.na(z) > > [1] TRUE > > >> str(x) > > cplx NA > >> str(y) > > num NA > >> str(z) > > cplx NA > > > but they are semantically different e.g. > > >> Re(x) > > [1] NA > >> Re(y) > > [1] -0.5 # surprise! > > >> Im(x) # surprise! > > [1] 2 > >> Im(z) > > [1] NA > > > so any expression involving Re() or Im() will produce > > different results on input that look the same on the > > surface. > > > You can address this either by normalizing the internal > > representation of complex NA to always be complex(r=NaN, > > i=NA_real_), like for NA_complex_, or by allowing the > > infinite variations that are currently allowed and at the > > same time making sure that both Re() and Im() always > > return NA_real_ on a complex NA. > > > My point is that the behavior of complex NA should be > > predictable. Right now it's not. Once it's predictable > > (with Re() and Im() both returning NA_real_ regardless of > > internal representation), then it no longer matters what > > kind of complex NA is returned by as.complex(NA_real_), > > because they are no onger distinguishable. > > > H. > > > On 9/22/23 13:43, Duncan Murdoch wrote: > >> Since the result of is.na(x) is the same on each of > >> those, I don't see a problem. As long as that is > >> consistent, I don't see a problem. You shouldn't be using > >> any other test for NA-ness. You should never be > >> expecting identical() to treat different types as the > >> same (e.g. identical(NA, NA_real_) is FALSE, as it > >> should be). If you are using a different test, that's > >> user error. > >> > >> Duncan Murdoch > >> > >> On 22/09/2023 2:41 p.m., Hervé Pagès wrote: > >>> We could also question the value of having an infinite > >>> number of NA representations in the complex space. For > >>> example all these complex values are displayed the same > >>> way (as NA), are considered NAs by is.na(), but are not > >>> identical or semantically equivalent (from an Re() or > >>> Im() point of view): > >>> > >>> NA_real_ + 0i > >>> > >>> complex(r=NA_real_, i=Inf) > >>> > >>> complex(r=2, i=NA_real_) > >>> > >>> complex(r=NaN, i=NA_real_) > >>> > >>> In other words, using a single representation for > >>> complex NA (i.e. complex(r=NA_real_, i=NA_real_)) would > >>> avoid a lot of unnecessary complications and surprises. > >>> > >>> Once you do that, whether as.complex(NA_real_) should > >>> return complex(r=NA_real_, i=0) or complex(r=NA_real_, > >>> i=NA_real_) becomes a moot point. > >>> > >>> Best, > >>> > >>> H. > > Thank you, Hervé. > Your proposition is yet another one, > to declare that all complex NA's should be treated as identical > (almost/fully?) everywhere. > > This would be a possibility, but I think a drastic one. > > I think there are too many cases, where I want to keep the > information of the real part independent of the values of the > imaginary part (e.g. think of the Riemann hypothesis), and > typically vice versa. Use NaN for that, not NA. > > With your proposal, for a (potentially large) vector of complex numbers, > after >Re(z) <- 1/2 > > I could no longer rely on Re(z) == 1/2, > because it would be wrong for those z where (the imaginary part/ the number) > was NA/NaN. My proposal is to do this only if the Re and/or Im parts are NAs, not if they are NaN
Re: [Rd] Recent changes to as.complex(NA_real_)
On 9/22/23 16:55, Hervé Pagès wrote: > The problem is that you have things that are **semantically** > different but look exactly the same: > > They look the same: > > > x > [1] NA > > y > [1] NA > > z > [1] NA > > > is.na(x) > [1] TRUE > > is.na(y) > [1] TRUE > > is.na(z) > [1] TRUE > > > str(x) > cplx NA > > str(y) > num NA > oops, that was supposed to be: > str(y) cplx NA but somehow I managed to copy/paste the wrong thing, sorry. H. -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Recent changes to as.complex(NA_real_)
The problem is that you have things that are **semantically** different
but look exactly the same:
They look the same:
> x
[1] NA
> y
[1] NA
> z
[1] NA
> is.na(x)
[1] TRUE
> is.na(y)
[1] TRUE
> is.na(z)
[1] TRUE
> str(x)
cplx NA
> str(y)
num NA
> str(z)
cplx NA
but they are semantically different e.g.
> Re(x)
[1] NA
> Re(y)
[1] -0.5 # surprise!
> Im(x) # surprise!
[1] 2
> Im(z)
[1] NA
so any expression involving Re() or Im() will produce different results
on input that look the same on the surface.
You can address this either by normalizing the internal representation
of complex NA to always be complex(r=NaN, i=NA_real_), like for
NA_complex_, or by allowing the infinite variations that are currently
allowed and at the same time making sure that both Re() and Im() always
return NA_real_ on a complex NA.
My point is that the behavior of complex NA should be predictable. Right
now it's not. Once it's predictable (with Re() and Im() both returning
NA_real_ regardless of internal representation), then it no longer
matters what kind of complex NA is returned by as.complex(NA_real_),
because they are no onger distinguishable.
H.
On 9/22/23 13:43, Duncan Murdoch wrote:
> Since the result of is.na(x) is the same on each of those, I don't see
> a problem. As long as that is consistent, I don't see a problem. You
> shouldn't be using any other test for NA-ness. You should never be
> expecting identical() to treat different types as the same (e.g.
> identical(NA, NA_real_) is FALSE, as it should be). If you are using
> a different test, that's user error.
>
> Duncan Murdoch
>
> On 22/09/2023 2:41 p.m., Hervé Pagès wrote:
>> We could also question the value of having an infinite number of NA
>> representations in the complex space. For example all these complex
>> values are displayed the same way (as NA), are considered NAs by
>> is.na(), but are not identical or semantically equivalent (from an Re()
>> or Im() point of view):
>>
>> NA_real_ + 0i
>>
>> complex(r=NA_real_, i=Inf)
>>
>> complex(r=2, i=NA_real_)
>>
>> complex(r=NaN, i=NA_real_)
>>
>> In other words, using a single representation for complex NA (i.e.
>> complex(r=NA_real_, i=NA_real_)) would avoid a lot of unnecessary
>> complications and surprises.
>>
>> Once you do that, whether as.complex(NA_real_) should return
>> complex(r=NA_real_, i=0) or complex(r=NA_real_, i=NA_real_) becomes a
>> moot point.
>>
>> Best,
>>
>> H.
>>
>> On 9/22/23 03:38, Martin Maechler wrote:
>>>>>>>> Mikael Jagan
>>>>>>>> on Thu, 21 Sep 2023 00:47:39 -0400 writes:
>>> > Revisiting this thread from April:
>>>
>>> >https://stat.ethz.ch/pipermail/r-devel/2023-April/082545.html
>>>
>>> > where the decision (not yet backported) was made for
>>> > as.complex(NA_real_) to give NA_complex_ instead of
>>> > complex(r=NA_real_, i=0), to be consistent with
>>> > help("as.complex") and as.complex(NA) and
>>> as.complex(NA_integer_).
>>>
>>> > Was any consideration given to the alternative?
>>> > That is, to changing as.complex(NA) and
>>> as.complex(NA_integer_) to
>>> > give complex(r=NA_real_, i=0), consistent with
>>> > as.complex(NA_real_), then amending help("as.complex")
>>> > accordingly?
>>>
>>> Hmm, as, from R-core, mostly I was involved, I admit to say "no",
>>> to my knowledge the (above) alternative wasn't considered.
>>>
>>> > The principle that
>>> > Im(as.complex()) should be zero
>>> > is quite fundamental, in my view, hence the "new" behaviour
>>> > seems to really violate the principle of least surprise ...
>>>
>>> of course "least surprise" is somewhat subjective. Still,
>>> I clearly agree that the above would be one desirable property.
>>>
>>> I think that any solution will lead to *some* surprise for some
>>> cases, I think primarily because there are *many* different
>>> values z for which is.na(z) is true, and in any case
>>> NA_complex_ is only of the many.
>>>
>>> I also agree with Mikael that we should reconsider the issue
>>> that was raised by Davis Vaughan here ("on R-devel") last April.
>>>
>>> > Another (but maybe weaker) argument is that
>>> > double->comp
Re: [Rd] Recent changes to as.complex(NA_real_)
ook at it only *secondary* to your first
> proposal.
>
> > Whatever decision is made about as.complex(NA_real_),
> > maybe these points should be weighed before it becomes part of
> > R-release ...
>
> > Mikael
>
> Indeed.
>
> Can we please get other opinions / ideas here?
>
> Thank you in advance for your thoughts!
> Martin
>
> ---
>
> PS:
>
> Our *print()*ing of complex NA's ("NA" here meaning NA or NaN)
> is also unsatisfactory, e.g. in the case where all entries of a
> vector are NA in the sense of is.na(.), but their
> Re() and Im() are not all NA:
>
>showC <- function(z) noquote(sprintf("(R = %g, I = %g)", Re(z), Im(z)))
>z <- complex(, c(11, NA, NA), c(NA, 99, NA))
>z
>showC(z)
>
> gives
>
>> z
>[1] NA NA NA
>> showC(z)
>[1] (R = 11, I = NA) (R = NA, I = 99) (R = NA, I = NA)
>
> but that (printing of complex) *is* another issue,
> in which we have the re-opened bugzilla PR#16752
> ==>https://bugs.r-project.org/show_bug.cgi?id=16752
>
> on which we also worked during the R Sprint in Warwick three
> weeks ago, and where I want to commit changes in any case {but
> think we should change even a bit more than we got to during the
> Sprint}.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Hervé Pagès
Bioconductor Core Team
hpages.on.git...@gmail.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] FYI: daily R source tarballs from ETH: *.xz instead of *.bz2)
On 9/11/23 22:39, Prof Brian Ripley wrote: > On 09/09/2023 01:56, Hervé Pagès wrote: >> Hi Martin, >> >> Sounds good. Are there any plans to support the xz compression for >> package source tarballs? > > What makes you think it is not supported? I guess because I've never seen source tarballs distributed as .xz files but it's good to know that 'R CMD build' and 'R CMD INSTALL' support that. So let me reformulate my question: do CRAN have any plans to switch from .tar.gz to .xz for the distribution of source tarballs? Is this something that tools like write_PACKAGES(), available.packages(), and install.packages() would be able to handle? Would they be able to handle a mix of .tar.gz and .xz packages? (Which would be important for a smooth transition from .tar.gz to .xz across CRAN/Bioconductor.) I'm just trying to get a sense if the effort to reduce bandwidth will go beyond the distribution of R source snapshots. Thanks, H. -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] FYI: daily R source tarballs from ETH: *.xz instead of *.bz2)
Hi Martin, Sounds good. Are there any plans to support the xz compression for package source tarballs? Thanks, H. On 9/8/23 06:44, Martin Maechler wrote: > A quick notice for anyone who uses cron-like scripts to get > R source tarballs from the ETH R/daily/ s: > > I've finally switched to replace *.bz2 by *.xz which does save > quite a bit of bandwidth. > > Currently, you can see the 2 day old *.bz2 (and their sizes) and > compare with the new *.xz one (sorted newest first): > >https://stat.ethz.ch/R/daily/?C=M;O=D > > > Best, > Martin > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] codetools wrongly complains about lazy evaluation in S4 methods
Oh but I see now that you've already tried this in your R/AllGenerics.R,
sorry for missing that, but that you worry about the following message
being disruptive on CRAN:
The following object is masked from 'package:base':
qr.X
Why would that be? As long as you only define methods for objects that
**you** control everything is fine. In other words you're not allowed to
define a method for "qr" objects because that method would override
base::qr.X(). But the generic itself and the method that you define for
your objects don't override anything so should not disrupt anything.
H.
On 6/15/23 13:51, Hervé Pagès wrote:
>
> I'd argue that at the root of the problem is that your qr.X() generic
> dispatches on all its arguments, including the 'ncol' argument which I
> think the dispatch mechanism needs to evaluate **before** dispatch can
> actually happen.
>
> So yes lazy evaluation is a real feature but it does not play well for
> arguments of a generic that are involved in the dispatch.
>
> If you explicitly defined your generic with:
>
> setGeneric("qr.X", signature="qr")
>
> you should be fine.
>
> More generally speaking, it's a good idea to restrict the signature of
> a generic to the arguments "that make sense". For unary operations
> this is usually the 1st argument, for binary operations the first two
> arguments etc... Additional arguments that control the operation like
> modiflers, toggles, flags, rng seed, and other parameters, usually
> have not place in the signature of the generic.
>
> H.
>
> On 6/14/23 20:57, Mikael Jagan wrote:
>> Thanks all - yes, I think that Simon's diagnosis ("user error") is
>> correct:
>> in this situation one should define a reasonable generic function
>> explicitly,
>> with a call to setGeneric, and not rely on the call inside of
>> setMethod ...
>>
>> But it is still not clear what the way forward should be (for package
>> Matrix,
>> where we would like to export a method for 'qr.X'). If we do
>> nothing, then
>> there is the note, already mentioned:
>>
>> * checking R code for possible problems ... NOTE
>> qr.X: no visible binding for global variable ‘R’
>> Undefined global functions or variables:
>> R
>>
>> If we add the following to our R/AllGenerics.R :
>>
>> setGeneric("qr.X",
>> function(qr, complete = FALSE, ncol, ...)
>> standardGeneric("qr.X"),
>> useAsDefault = function(qr, complete = FALSE, ncol,
>> ...) {
>> if(missing(ncol))
>> base::qr.X(qr, complete = complete)
>> else base::qr.X(qr, complete = complete, ncol = ncol)
>> },
>> signature = "qr")
>>
>> then we get a startup message, which would be quite disruptive on CRAN :
>>
>> The following object is masked from 'package:base':
>>
>> qr.X
>>
>> and if we further add setGenericImplicit("qr.X", restore = (TRUE|FALSE))
>> to our R/zzz.R, then for either value of 'restore' we encounter :
>>
>> ** testing if installed package can be loaded from temporary
>> location
>> Error: package or namespace load failed for 'Matrix':
>> Function found when exporting methods from the namespace
>> 'Matrix' which is not S4 generic: 'qr.X'
>>
>> Are there possibilities that I have missed?
>>
>> It seems to me that the best option might be to define an implicit
>> generic
>> 'qr.X' in methods via '.initImplicitGenerics' in
>> methods/R/makeBasicFunsList.R,
>> where I see that an implicit generic 'qr.R' is already defined ... ?
>>
>> The patch pasted below "solves everything", though we'd still have to
>> think
>> about how to work for versions of R without the patch ...
>>
>> Mikael
>>
>> Index: src/library/methods/R/makeBasicFunsList.R
>> ===
>> --- src/library/methods/R/makeBasicFunsList.R (revision 84541)
>> +++ src/library/methods/R/makeBasicFunsList.R (working copy)
>> @@ -263,6 +263,17 @@
>> signature = "qr", where = where)
>> setGenericImplicit("qr.R", where, FALSE)
>>
>> + setGeneric("qr.X",
>> + function(qr, complete = FALSE, ncol, ...)
>> + standardGeneric("qr.X"),
>> + useAsDefault = function(qr, c
Re: [Rd] codetools wrongly complains about lazy evaluation in S4 methods
ic itself (not >> necessarily a good idea) the default would be ncol = if (complete) >> nrow(qr.R(qr, TRUE)) else min(dim(qr.R(qr, TRUE))) to not rely on the >> internals of the implementation. >> >> Cheers, >> Simon >> >> >>> On 14/06/2023, at 6:03 AM, Kasper Daniel Hansen >>> wrote: >>> >>> On Sat, Jun 3, 2023 at 11:51 AM Mikael Jagan >>> wrote: >>> >>>> The formals of the newly generic 'qr.X' are inherited from the >>>> non-generic >>>> function in the base namespace. Notably, the inherited default >>>> value of >>>> formal argument 'ncol' relies on lazy evaluation: >>>> >>>>> formals(qr.X)[["ncol"]] >>>> if (complete) nrow(R) else min(dim(R)) >>>> >>>> where 'R' must be defined in the body of any method that might >>>> evaluate >>>> 'ncol'. >>>> >>> >>> Perhaps I am misunderstanding something, but I think Mikael's >>> expectations >>> about the scoping rules of R are wrong. The enclosing environment >>> of ncol >>> is where it was _defined_ not where it is _called_ (apologies if I am >>> messing up the computer science terminology here). >>> >>> This suggests to me that codetools is right. But a more extended >>> example >>> would be useful. Perhaps there is something special with setOldClass() >>> which I am no aware of. >>> >>> Also, Bioconductor has 100s of packages with S4 where codetools >>> works well. >>> >>> Kasper >>> >>> [[alternative HTML version deleted]] >>> >>> __ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >> > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-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
[Rd] 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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-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
