Re: [Bioc-devel] Windows specific error during CHECK

[Felix Ernst]

Thanks Herve!

-Ursprüngliche Nachricht-
Von: Hervé Pagès  
Gesendet: Dienstag, 26. Oktober 2021 21:53
An: Felix Ernst ; bioc-devel@r-project.org
Betreff: Re: [Bioc-devel] Windows specific error during CHECK

Hi Felix,

On 26/10/2021 12:10, Felix Ernst wrote:
> Hi Bioc-Team,
> 
> I have got a problem with an error on Windows, which I am not able to debug.
> 
> http://bioconductor.org/checkResults/devel/bioc-LATEST/mia/riesling1-c
> hecksrc.html
> 
> The testthat.out.fail output doesn't indicate any problems and the 
> testthat.out on other systems looks the same.
> 
> Can someone provide any hint on what might be going on? Thanks in advance!

Hmm.. even more puzzling is that if I go on riesling1, start R (in 64-bit 
mode), and run the tests manually, I don't see any problem:

 > test_check("mia")

 
|==|
100%



Time difference of 6.58 secs



Initializing error rates to maximum possible estimate.

selfConsist step 1 .

selfConsist step 2

selfConsist step 3

selfConsist step 4

Convergence after  4  rounds.

Initializing error rates to maximum possible estimate.

selfConsist step 1 .

selfConsist step 2

selfConsist step 3

selfConsist step 4

Convergence after  4  rounds.

initial  value 0.383462

iter   5 value 0.161655

iter  10 value 0.113278

final  value 0.003270

converged

initial  value 0.00

final  value 0.00

converged

initial  value 0.00

final  value 0.00

converged

initial  value 0.00

final  value 0.00

converged

[ FAIL 0 | WARN 2 | SKIP 0 | PASS 630 ]


So this only seems to happen in the context of 'R CMD check'. I wonder 
if the fact that we run 'R CMD check' with the --force-multiarch option 
(so the examples and tests are run for the 2 Windows archs) could be 
somehow related to the issue.

Anyways, I won't be able to do more testing today because the builds on 
riesling1 are going to start in a few minutes. I'll try to get back to 
this tomorrow.

Cheers,
H.


> 
> Best regards,
> Felix
> 
>   [[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

[Bioc-devel] Windows specific error during CHECK

[Felix Ernst]

Hi Bioc-Team,

I have got a problem with an error on Windows, which I am not able to debug.

http://bioconductor.org/checkResults/devel/bioc-LATEST/mia/riesling1-checksrc.html

The testthat.out.fail output doesn't indicate any problems and the testthat.out 
on other systems looks the same.

Can someone provide any hint on what might be going on? Thanks in advance!

Best regards,
Felix

[[alternative HTML version deleted]]

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

[Bioc-devel] Testthat problem - version info

[Felix Ernst]

Hi all,

I have been notified about some issues and it is quite clear that they are from 
testthat

https://master.bioconductor.org/checkResults/3.14/bioc-LATEST/RNAmodR/nebbiolo2-checksrc.html

Can somebody let me know which testthat version was used for the last check 
run? I want to raise the issue on their end. Thanks!

Best regards,
Felix

[[alternative HTML version deleted]]

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

[Rd] R CMD INSTALL warning for S4 replacement functions on R 4.1.0-alpha

[Felix Ernst]

Hi all,

Since R 4.1, R CMD INSTALL throws warning during building the man pages, when 
installing from source.

We noticed this first on Windows for man pages involving S4 replacement 
function:

  *   
http://bioconductor.org/checkResults/devel/bioc-LATEST/Modstrings/riesling1-checksrc.html
  *   
http://bioconductor.org/checkResults/devel/bioc-LATEST/GenomicAlignments/riesling1-checksrc.html

However, it's also showing up on linux with a slight twist (file not found 
instead of invalid argument) for other functions:

  *   https://cran.r-project.org/web/checks/check_results_Matrix.html (right at 
the end)

>From the messages and the involved offending filenames, we hypothesize that 
>this is triggered by invalid filenames specific to the OS.
Please note, that the warning is not issued during R CMD CHECK for a given 
package.

Can anyone comment on this? Is more information needed? If it is a bug, I am 
happy to post on the bug tracker.

Thanks for any advice.

Best regards,
Felix

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] BSgenome changes

[Felix Ernst]

Hi Leonard, Hi Herve,

I followed your conversation, since I have noticed the same problem. Thanks, 
Herve, for the explanation of the recent changes on hg19.

The GRCh37.P13 report states in its last line:

MT  assembled-molecule  MT  Mitochondrion   J01415.2=   
NC_012920.1 non-nuclear 16569   chrM

Since the last name is called "UCSC-style-name", wouldn't that mean that chrM 
has to be renamed to MT and not chrMT?

Thanks again for the explanation.

Cheers,
Felix

-Ursprüngliche Nachricht-
Von: Bioc-devel  Im Auftrag von Hervé Pagès
Gesendet: Freitag, 14. August 2020 01:08
An: Leonard Goldstein ; bioc-devel@r-project.org
Cc: charlotte.sone...@fmi.ch
Betreff: Re: [Bioc-devel] BSgenome changes

Hi Leonard,

On 8/12/20 15:22, Leonard Goldstein via Bioc-devel wrote:
> Dear Bioc team,
> 
> I'm following up on this recent GitHub issue 
>  _SGSeq_issues_5=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=n5bIFHTIgC1B4EdjWUDLIlVcRJdXScYvfbojaqTJZVg=Tfk-tDM99P63dnsvMydG2phv5WQPVbJzPk0hzi-_1SE=
>  >. Please see the issue for more details and code examples.
> 
> It looks like changes in Bioc devel result in two copies of the 
> mitochondrial chromosome for BSgenome.Hsapiens.UCSC.hg19 -- one named 
> chrM like in previous package versions (length 16571) and one named 
> chrMT (length 16569).
> 
> When using seqlevelsStyle() to change chromosome names from UCSC to 
> NCBI format, this results in new behavior -- in the past chrM was 
> simply renamed MT, now the different sequence chrMT is used. Is this intended?

Absolutely intended.

There is a long story behind the unfortunate fate of the mitochondrial 
chromosome in hg19. I'll try to keep it short.

When the UCSC folks released the hg19 browser more than 10 years ago, they 
based it on assembly GRCh37:

   https://www.ncbi.nlm.nih.gov/assembly/GCF_01405.13

See sequence report for GRCh37:

 
https://ftp.ncbi.nlm.nih.gov/genomes/all/GCF/000/001/405/GCF_01405.13_GRCh37/GCF_01405.13_GRCh37_assembly_report.txt

For some mysterious reason GRCh37 didn't include the mitochondrial chromosome 
so the UCSC folks decided to use mitochondrial sequence
NC_001807 and called it chrM.

However, UCSC has recently decided to base hg19 on GRCh37.p13 instead of 
GRCh37. A rather surprising move after many years of hg19 being based on the 
latter.

   https://www.ncbi.nlm.nih.gov/assembly/GCF_01405.25/

See sequence report for GRCh37.p13:

 
https://ftp.ncbi.nlm.nih.gov/genomes/all/GCF/000/001/405/GCF_01405.25_GRCh37.p13/GCF_01405.25_GRCh37.p13_assembly_report.txt

Note that GRCh37.p13 does include the mitochondrial chromosome. It's called MT 
in the official sequence report above and chrMT in hg19.

At the same time the UCSC folks decided to keep chrM so now hg19 contains 2 
mitochondrial sequences: chrM and chrMT. Previously it has only one: chrM.

So what you see in BioC devel in BSgenome.Hsapiens.UCSC.hg19 and with
seqlevelsStyle(genome) is only reflecting this. In particular
seqlevelsStyle(genome) <- "NCBI" now does the following:

   - Rename chrMT -> MT.

   - chrM does NOT get renamed. There is no point in renaming this sequence 
because it has no equivalent in GRCh37.p13.

Hope this helps,

H.

> 
> Leonard
> 
>   [[alternative HTML version deleted]]
> 
> ___
> Bioc-devel@r-project.org mailing list
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mail
> man_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeA
> vimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=n5bIFHTIgC1B4EdjWUDLIlVcRJdXScYv
> fbojaqTJZVg=IczvesjTwEkPQVlFX5wKSJLUHyjNHE0sk71a-kMAVEI=
> 

--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

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

[Bioc-devel] AnnotationHubData -> rBiopaxParser -> nem dependency issue

[Felix Ernst]

Hi,

I have a bit of a strange error on my Travis-CI build reports and strange in 
the sense, that they are not picked up by the Bioc build report. 
https://travis-ci.com/github/FelixErnst/RNAmodR

The package "rBiopaxParser" is reported as not available during the dependency 
install step.

I investigated, what let to the dependency via the BiocPkgTools package:

> depdf <- BiocPkgTools::buildPkgDependencyDataFrame(version = "3.12")
> library(dplyr)
> depdf %>% filter(dependency == "rBiopaxParser")
# A tibble: 4 x 3
  Package   dependencyedgetype

1 AnnotationHubData rBiopaxParser Imports
2 pwOmics   rBiopaxParser Imports
3 AnnotationHub rBiopaxParser Suggests
4 NetPathMiner  rBiopaxParser Suggests

It turns out that the RNAmodR requires RNAmodR.Data, which itself is data 
package wrapping AnnotationHub resources using the AnnotationHub and 
AnnotationHubData packages. At this point rBiopaxParser Is on the hook via 
AnnotationHubData, because "Depends", "Imports" and "LinkingTo" fields are used 
to resolve the dependencies.

When checking the rBiopaxParser build report for devel and I found consistent 
failures 
(http://bioconductor.org/checkResults/devel/bioc-LATEST/rBiopaxParser/malbec1-checksrc.html),
 because the package nem is deprecated. Nem is only suggested by rBiopaxParser, 
but this gets an error on Bioc build report. So my guess is that rBiopaxParser 
was never build without error for 3.12 and even the source package is not 
available for 3.12. I also confirmed the behavior by running 
'BiocManager::install("RNAmodR.Data")' on the bioconductor_docker:devel image.

So my questions is, why doesn't the Bioc build report fail, because 
AnnotationHubData is importing rBiopaxParser, but that shouldn't be available, 
should it? Should I worry about this? What would be the best course of action 
here?

Thanks for any help and advice.

Best regards,
Felix

PS: It seems to my the nem packages was deprecated because of conditions of 
length > 1. This was enforced in Bioc 3.11 wasn't it? Its probably a bit of a 
shame then, but probably the dev didn't respond.

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] GenomicFeatures and/or TxDb.Hsapiens.UCSC.hg19.knownGene issue: missing tibble

[Felix Ernst]

Hi,

Thanks for the discussion and the insight into possible solutions.

I currently have the same problem with settings up an RNAmodR GitHub Action. 
This fails because the RNAmodR requires RNAmodR.Data, which suggests 
GenomicRanges, which then leads to GenomeInfoDb and GenomeInfoDbData. What 
struck me was the fact, that GenomeInfoDbData is installed as a source package 
after RNAmodR.Data, which is basically the same situation as Leonardo describes 
for the TxDb packages.
So why is the package GenomeInfoDbData, which does not have any dependencies at 
all (except R) is not installed first? I tried to fix it by adding 
GenomeInfoDbData to the depends of RNAmodR. This solved the problem on macOS, 
but not on windows the tibble problem remains 
(https://github.com/FelixErnst/RNAmodR/runs/623569724). This makes sense, 
because tibble is currently available as binary for macOS, but not windows. 
Adding tibble will probably solve this as well, but that cannot be a permanent 
solution, can it?

I also have a question regarding the inner working of BiocManager::install: I 
used the following command to install dependencies: 
BiocManager::install(remotes::dev_package_deps(dependencies = TRUE, repos = 
c(BiocManager::repositories(),getOption('repos')))$package). Is the order in 
which the packages are given important?

To state a hypothesis: In both cases, GenomeInfoDbData and tibble, source 
packages are affected, which are required, by a binary package, which is then 
again required by a source package. Maybe this bridge by a binary package is 
not picked up, when trying to sort for the install order of the source packages.

Does this sound reasonable or is it there something I haven't thought about? 
Thanks for any advice.

Best regards,
Felix

-Ursprüngliche Nachricht-
Von: Bioc-devel  Im Auftrag von Leonardo 
Collado Torres
Gesendet: Montag, 27. April 2020 18:07
An: Charlotte Soneson 
Cc: Bioc-devel 
Betreff: Re: [Bioc-devel] GenomicFeatures and/or 
TxDb.Hsapiens.UCSC.hg19.knownGene issue: missing tibble

Hi,

I also ran more tests, which makes me think that the issue was with the list of 
dependencies we were asking `remotes` to install.


First, regarding the second to last email from Charlotte, the step-wise 
installation I did mostly using remotes was not ideal. I found a complicated 
scenario in another package that I contribute to where 
BSgenome.Hsapiens.UCSC.hg19 had to be downloaded twice (it failed the first 
time). That was `brainflowprobes` on Windows at
https://github.com/LieberInstitute/brainflowprobes/runs/621460015?check_suite_focus=true#step:12:1142
and 
https://github.com/LieberInstitute/brainflowprobes/runs/621460015?check_suite_focus=true#step:12:1410.
Downloading such a big package (or any package) twice is really wasteful. So we 
can discard that path.


Secondly, I also found about remotes::local_package_deps() like Charlotte just 
mentioned prompted by Martin's question. As suggested by Martin, I'm now trying 
using BiocManager::install() only since it knows how to resolve Bioc's 
dependency tree. Thus my current GHA workflow uses BiocManager::install() with 
the "minimal" deps (the immediate dependencies). I still use 
remotes::dev_package_deps() to find which packages need to be updated in order 
to enable the caching functionality later on. I did this installation twice, 
just as a backup. Then I do a third BiocManager::install() call with any 
outdated packages across the full dependencies. That's what
https://github.com/leekgroup/derfinderPlot/blob/673608493488ae488ccb66e77e6deae5dabe69e0/.github/workflows/check-bioc.yml#L367-L393
does and here's the relevant code:


message(paste('', Sys.time(), 'installing BiocManager '))
remotes::install_cran("BiocManager")

## Pass #1 at installing dependencies
message(paste('', Sys.time(), 'pass number 1 at installing
dependencies: local dependencies ')) local_deps <- 
remotes::local_package_deps(dependencies = TRUE) deps <- 
remotes::dev_package_deps(dependencies = TRUE, repos =
BiocManager::repositories())
BiocManager::install(local_deps[local_deps %in% deps$package[deps$diff != 0]])

## Pass #2 at installing dependencies
message(paste('', Sys.time(), 'pass number 2 at installing
dependencies: local dependencies again ')) deps <- 
remotes::dev_package_deps(dependencies = TRUE, repos =
BiocManager::repositories())
BiocManager::install(local_deps[local_deps %in% deps$package[deps$diff != 0]])

## Pass #3 at installing dependencies
message(paste('', Sys.time(), 'pass number 3 at installing
dependencies: any remaining dependencies ')) deps <- 
remotes::dev_package_deps(dependencies = TRUE, repos =
BiocManager::repositories())
BiocManager::install(deps$package[deps$diff != 0])


For all 3 OS (Bioconductor devel docker, macOS, Windows) this works for 
`derfinderPlot`:
https://github.com/leekgroup/derfinderPlot/actions/runs/89153451.
Actually, in all 3, "pass #2" did nothing. Only in the docker one did 

Re: [Bioc-devel] R Dependency Warning

[Felix Ernst]

Hi Sunny,

I would venture a guess and suggest that is about the too fined grained version 
you defined in the DESCRIPTION file.

I would suggest, that you try to define an R version, which follows the format 
x.y and not x.y.z. So for you that would be R (>= 4.0).

Hope that works,

Felix

-Ursprüngliche Nachricht-
Von: Bioc-devel  Im Auftrag von Sunny Jones
Gesendet: Freitag, 3. April 2020 20:14
An: bioc-devel@r-project.org
Betreff: [Bioc-devel] R Dependency Warning

Hello,

I'm in the process of submitting two packages to Bioconductor, MOMA and its 
associated data package moma.gbmexample. I keep getting this warning about the 
R dependency:

* Checking R Version dependency...
* WARNING: Unless package includes compressed data, remove R
  version dependency

Both packages do have compressed data and I have tried both making the 
dependency 4.0.0 and 3.6 but have gotten the error both times. Which is the 
correct R version to list as the dependency on the upcoming release version? Or 
is this a warning that should be ignored given that I do have compressed data?

Thank you
Sunny Jones

[[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

Re: [Bioc-devel] Biostrings: unicode character ("compact ellipsis") in print()/show() output (2nd attempt, rephrased)

[Felix Ernst]

Hi,

If you can replicate the latex/knitr/sweave issue locally, try installing 
Biostrings from my GitHub fork used in the PR. This should solve the issue, if 
it is about the ellipsis character causing problems on windows only.

If it doesn't, it probably has more to do with the way unicode characters are 
handeled in latex. I had a lot of problems, when trying to develop the 
Modstrings package vignette and I couldn't get it to work with a pdf output. 
The number of special characters I had to deal with were from many different 
alphabets and resisted my attempts (without any detailed knowledge about latex 
to pdf conversion) to get to the bottom of it.

Maybe someone else has more experience regarding unicode characters in latex 
and can take a look at this (if it persists).

Felix

-Ursprüngliche Nachricht-
Von: Bioc-devel  Im Auftrag von Vincent Carey
Gesendet: Samstag, 7. März 2020 20:50
An: Shepherd, Lori 
Cc: bioc-devel@r-project.org; Ulrich Bodenhofer ; 
Kurt Hornik 
Betreff: Re: [Bioc-devel] Biostrings: unicode character ("compact ellipsis") in 
print()/show() output (2nd attempt, rephrased)

you are not wrong ... thanks for pointing this out

https://github.com/Bioconductor/Biostrings/pull/33



On Sat, Mar 7, 2020 at 2:33 PM Shepherd, Lori 
wrote:

> I could be wrong but I think there is an open issue and PR already 
> submitted that might be related.
>
> Get Outlook for Android 
>
> --
> *From:* Bioc-devel  on behalf of 
> Vincent Carey 
> *Sent:* Saturday, March 7, 2020 12:58:57 PM
> *To:* Ulrich Bodenhofer 
> *Cc:* bioc-devel@r-project.org ; Kurt Hornik 
> < kurt.hor...@wu.ac.at>
> *Subject:* Re: [Bioc-devel] Biostrings: unicode character ("compact
> ellipsis") in print()/show() output (2nd attempt, rephrased)
>
> I have a feeling that the best way to get action here will be to file 
> an issue and perhaps a PR at 
> https://github.com/Bioconductor/Biostrings
>
> On Sat, Mar 7, 2020 at 7:12 AM Ulrich Bodenhofer 
>  >
> wrote:
>
> > Dear colleagues,
> >
> > As noted in my previous message, I have encountered problems with 
> > the new way of displaying sequences/sequence sets that now use a 
> > UTF-8 ellipsis character (internally defined as R object 
> > 'compact_ellipsis' in the package) when the output is included in a 
> > LaTeX document (which happens when printing biological sequences via 
> > the 'Biostrings' package inside LaTeX-based Sweave or knitr 
> > documents). My question again: Is there any special measure that I can take 
> > to counteract this issue?
> > (e.g. like loading \usepackage[xxx]{inputenc} in the vignette, 
> > setting an option, or manually refining 'compact_ellipsis') Is there 
> > a way that the users can revert to the old-style dots for such cases?
> >
> > As a sidenote: this causes the building of my package 'apcluster' to 
> > break on a non-UTF-8 locale (
> >
> https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-cl
> ang/apcluster-00check.html
> ),
> >
> > but leads to warnings also in a UTF-8 locale.
> >
> > Any help is gratefully appreciated, thanks so much in advance!
> >
> > Best regards,
> > Ulrich
> >
> > ___
> > 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 the 
> ...{{dropped:18}}
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> This email message may contain legally privileged and/or confidential 
> information. If you are not the intended recipient(s), or the employee 
> or agent responsible for the delivery of this message to the intended 
> recipient(s), you are hereby notified that any disclosure, copying, 
> distribution, or use of this email message is prohibited. If you have 
> received this message in error, please notify the sender immediately 
> by e-mail and delete this email message from your computer. Thank you.

--
The information in this e-mail is intended only for the person to whom it is 
addressed. If you believe this e-mail was sent to you in error and the e-mail 
contains patient information, please contact the Partners Compliance HelpLine 
at http://www.partners.org/complianceline
 . If the e-mail was sent to you in 
error but does not contain patient information, please contact the sender and 
properly dispose of the e-mail.

[[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

Re: [Bioc-devel] warning: file link '%>%' in package 'magrittr' does not exist and so has been treated as a topic

[Felix Ernst]

Hi,

I am certainly not a roxygen expert, but if \code{\link{\%>\%}} is to implicit 
for anyone's taste, \code{\link[magrittr:pipe]{\%>\%}} should also work in this 
case. 

The case above is used for a package external link. For an internal explicit 
link use \code{\link[=something]{or other}}.

Felix

-Ursprüngliche Nachricht-
Von: Bioc-devel  Im Auftrag von Martin Morgan
Gesendet: Donnerstag, 13. Februar 2020 04:46
An: stefano ; bioc-devel@r-project.org
Betreff: Re: [Bioc-devel] warning: file link '%>%' in package 'magrittr' does 
not exist and so has been treated as a topic

This warning

* checking whether package 'ttBulk' can be installed ... WARNING Found the 
following significant warnings:
  Rd warning: 
C:/Users/pkgbuild/AppData/Local/Temp/Rtmp6Js8e8/R.INSTALL1ddcdee5581/ttBulk/man/reexports.Rd:19:
 file link '%>%' in package 'magrittr' does not exist and so has been treated 
as a topic See 
'C:/Users/pkgbuild/packagebuilder/workers/jobs/1330/8048f88/ttBulk.Rcheck/00install.out'
 for details.

is actually about the documentation for '%>%'. In your previous 'man' page you 
had

  \code{\link[magrittr]{\%>\%}}

which from reading 'Writing R Extensions' RShowDoc("R-exts") section 2.5 
'Cross-references' indicates that you're trying to link to an html page named 
'%>%.html' in the magrittr package, but actually the man page is 'pipe.html' 
(e.g., by using help.start() and browsing manually to the help page). While 
it's possible to link to that help page, you should instead just 
\code{\link{\%>\%}} and R (possibly with the user choosing the package) will 
generate the correct link.

Your package is too deep into the roxygen foo for me to know what you need to 
do to generate the appropriate link (or even where the link is generated...); 
maybe there's a roxygen expert on the mailing list who can help (or you can 
perhaps post here where you generate the reexports.Rd page from).

Also, your github repository seems VERY LARGE (I lost patience trying to clone 
it, although my current link is quite slow); this 
http://bioconductor.org/developers/how-to/git/remove-large-data/ might provide 
some hints for removing large commits.

Hope that helps,

Martin


On 2/12/20, 9:51 PM, "Bioc-devel on behalf of stefano" 
 wrote:

Hello Community,

The CHECK Windows server gives me a warning when I try to reexport an
existing operator magrittr::`%>%`

```
#' @importFrom magrittr %>%

#' @export

magrittr::`%>%`
```

okay2 Windows Server 2012 R2 Standard/x64
  OK
  WARNINGS
  OK
  OK

malbec2 Linux (Ubuntu 18.04.3 LTS)/x86_64
  OK
  OK
  skipped
  OK


Here is the log

http://bioconductor.org/spb_reports/ttBulk_buildreport_20200212081044.html#tokay2_check_anchor

I looked online but I could not find a definitive answer. An advice will be
highly appreciated.

Thanks!

Best wishes.

*Stefano *



Stefano Mangiola | Postdoctoral fellow

Papenfuss Laboratory

The Walter Eliza Hall Institute of Medical Research

+61 (0)466452544

[[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
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] New bioconductor_docker image officially released

[Felix Ernst]

Hi Nitesh,

Thanks for the new image.

I have a question regarding the behavior of encountering logicals with a length 
higher than 1 and its coercion to logical(1) for an if statement.

I encountered a bit of a problem, when a unit test returned an error running R 
CMD check using the Bioconductor docker image:

'length(x) = 2 > 1' in coercion to 'logical(1)'

However in a normal session this didn't raise an error. After adding 

_R_CHECK_LENGTH_1_CONDITION_=true
_R_CHECK_LENGTH_1_LOGIC2_=true

to /usr/local/lib/R/etc/Renviron.site the behavior matched the output from R 
CMD check.

Is this behavior intended or would you consider adding this setting to the 
docker image?

Best regards
Felix

-Ursprüngliche Nachricht-
Von: Bioc-devel  Im Auftrag von Turaga, Nitesh
Gesendet: Dienstag, 21. Januar 2020 18:41
An: bioc-devel@r-project.org
Betreff: [Bioc-devel] New bioconductor_docker image officially released

Hello developers,

The new "bioconductor/bioconductor_docker" image is officially released.

The link to access it on Dockerhub is:  
https://hub.docker.com/repository/docker/bioconductor/bioconductor_docker.

The source code in on GitHub at: 
https://github.com/bioconductor/bioconductor_docker.

Please note there are currently two versions,

1. bioconductor/bioconductor_docker:devel

2. bioconductor/bioconductor_docker:RELEASE_3_10 or 
bioconductor/bioconductor_docker:latest

The previous set of images have been deprecated. The previous images have also 
been updated with a `LABEL` in the Dockerfile which refers to them as 
"Deprecated". You can see this information on your image if you do a  `docker 
pull ; docker inspect `. Please note, we will support 
these images through this release cycle.

We highly recommend that you shift to the new images, and use those containers. 
They come with all the system dependencies to install almost all of the 
Bioconductor packages, an RStudio interface, and with customizations which are 
specific to Bioconductor.

Docker images are now considered similar to Bioconductor packages. There will 
be official contributions from the community following our list of best 
practices.
 If you need more information on the docker images please refer to 
http://bioconductor.org/help/docker/.

As always, if you have any questions, please feel free to reply to this email.

Best regards,

Nitesh





This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

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

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

[Bioc-devel] error regarding splitAsList from IRanges packages

[Felix Ernst]

Hi

I have a build error for RNAmodR package, which was just added to the Bioc git 
repo and was build for the first time for 3.10.

https://bioconductor.org/checkResults/3.10/bioc-LATEST

> No methods found in package �IRanges� for request: �splitAsList� when loading 
> �ensembldb�
> Error: object 'splitAsList' is not exported by 'namespace:IRanges'

I never encountered this particular error during the review process so I am bit 
out of my depth.

If I read this error correctly, it was triggered trying to load the ensembldb 
package (which is an indirect dependency). However, ensembldb did build 
correctly and splitAsList is as far as I know also exported from IRanges. 
IRanges also build correctly.

Thanks for any advice or a pointer, how I can debug this?

Best regards,
Felix

[[alternative HTML version deleted]]

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

[Bioc-devel] BiocManager for BioC 3.9/R 3.6

[Felix Ernst]

Hi,

I just installed R 3.6, but everything I try to get a BiocManager Version, 
which works with R 3.6 were so far not successful.

I installed BiocManager from CRAN �

> install.packages("BiocManager")

� and from GitHub �

> devtools::install_github("Bioconductor/BiocManager")

� but both times I get the following error:

> BiocManager::install("Biostrings")
Fehler: Bioconductor version '3.8' requires R version '3.5'; see 
https://bioconductor.org/install

CRAN has Version 1.30.4 and GitHub has version 1.30.5.

Did I miss something?

Thanks for any help or advice.

Best regards
Felix


> sessionInfo()
R version 3.6.0 (2019-04-26)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 17763)

Matrix products: default

locale:
[1] LC_COLLATE=German_Germany.1252  LC_CTYPE=German_Germany.1252
LC_MONETARY=German_Germany.1252
[4] LC_NUMERIC=CLC_TIME=German_Germany.1252

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

loaded via a namespace (and not attached):
[1] BiocManager_1.30.4 compiler_3.6.0 tools_3.6.0

[[alternative HTML version deleted]]

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

[Bioc-devel] Single Package Builder

[Felix Ernst]

Hi,

 

I just wanted to ask, whether the SPB is under maintenance.

 

After a push, the bot reports the start of a build, but the build is not
started or at least the result is not reported back to the issue on GitHub.

 

I hope I didn�t miss something or is the info from the 29th of January still
valid?

 

Best regards,

Felix

 

---



Felix Ernst, PhD

Universit� Libre de Bruxelles

RNA MOLECULAR BIOLOGY

BIOPARK Charleroi Brussels-South CAMPUS

Rue Profs Jeener & Brachet, 12

B-6041 Charleroi - Gosselies

BELGIUM

+32(2)650 9774 (office phone)

 <mailto:felix.er...@ulb.ac.be> felix.er...@ulb.ac.be

 

 


[[alternative HTML version deleted]]

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

[Rd] compairing doubles

[Felix Ernst]

Dear all,

I a bit unsure, whether this qualifies as a bug, but it is definitly a strange 
behaviour. That why I wanted to discuss it.

With the following function, I want to test for evenly space numbers, starting 
from anywhere.

.is_continous_evenly_spaced <- function(n){
  if(length(n) < 2) return(FALSE)
  n <- n[order(n)]
  n <- n - min(n)
  step <- n[2] - n[1]
  test <- seq(from = min(n), to = max(n), by = step)
  if(length(n) == length(test) &&
 all(n == test)){
return(TRUE)
  }
  return(FALSE)
}

> .is_continous_evenly_spaced(c(1,2,3,4))
[1] TRUE
> .is_continous_evenly_spaced(c(1,3,4,5))
[1] FALSE
> .is_continous_evenly_spaced(c(1,1.1,1.2,1.3))
[1] FALSE

I expect the result for 1 and 2, but not for 3. Upon Investigation it turns 
out, that n == test is TRUE for every pair, but not for the pair of 0.2.

The types reported are always double, however n[2] == 0.1 reports FALSE as well.

The whole problem is solved by switching from all(n == test) to 
all(as.character(n) == as.character(test)). However that is weird, isn�t it?

Does this work as intended? Thanks for any help, advise and suggestions in 
advance.

Best regards,
Felix


[[alternative HTML version deleted]]

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

Re: [Bioc-devel] EXTERNAL: troubles with fetching Bioconductor github

[Felix Ernst]

Hi all,

I had a problem accessing git@bioconductor yesterday as well from a Windows
1803 PC. With the same PC it worked in March, but not now.

The last bit about the version is important since the OpenSSH form Microsoft
is apparently in 1803 the default. I don't know, how the setup was
previously. 

How I diagnosed the problem:
- ssh-add -l does not show previously added keys (powershell or git bash
terminal in rstudio)
- re-adding keys works and is persistent after a restart without a .bashrc
script or anything ()
- ssh -T works
- git fetch does not

The last two information means, that there are to key stores at play.

There are two solutions, which worked for me:
- copy and rename the key file to ~/.ssh/id_rsa (git finds it then and ask
for passphrase. The config file in ~/.ssh/ was ignored)
- change core.sshCommand option in .gitconfig to
"C:/Windows/System32/OpenSSH/ssh.exe" (git uses the stored keys added with
ssh-add)

I don't know, where I found all the bits of information, but it was
basically a lot of googling. I am also not sure, whether this a specific
problem to my machine or a general Windows 1803 issue. I am also not sure,
what the underlying cause for the behaviour is. It is more a fix for the
symptom, not a cure.

Hope this helps some people.

Best regards,
Felix

---
Felix Ernst, PhD
Université Libre de Bruxelles
RNA MOLECULAR BIOLOGY
BIOPARK Charleroi Brussels-South CAMPUS
Rue Profs Jeener & Brachet, 12
B-6041 Charleroi - Gosselies
BELGIUM
+32(2)650 9774 (office phone)
felix.er...@ulb.ac.be



-Original Message-
From: Bioc-devel  On Behalf Of Turaga,
Nitesh
Sent: Freitag, 3. August 2018 12:21
To: Piotr 
Cc: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] EXTERNAL: troubles with fetching Bioconductor
github

No, I'm not aware of any such issues.

Maybe someone else in the community can chip in with some information about
this.

Best,

Nitesh

Get Outlook for Android<https://aka.ms/ghei36>


From: Piotr 
Sent: Friday, August 3, 2018 5:22:23 AM
To: Turaga, Nitesh
Cc: bioc-devel@r-project.org
Subject: Re: EXTERNAL: [Bioc-devel] troubles with fetching Bioconductor
github

Dear Nitesh,
now works ok, although I did not change anything.
maybe there is a time when I should not connect with Bioconductor git?


Piotr

On Thu, Aug 2, 2018 at 11:35 PM Turaga, Nitesh
mailto:nitesh.tur...@roswellpark.org>> wrote:
Please copy the result of this,

git remote -v

and send it to us so we have more information.

http://bioconductor.org/developers/how-to/git/faq/ , check #14

Best,

Nitesh

> On Aug 2, 2018, at 5:14 PM, Piotr
mailto:piotr.dittw...@gmail.com>> wrote:
>
> Dear All,
>
> I try to follow instruction here:
> https://bioconductor.org/developers/how-to/git/sync-existing-repositor
> ies/
>
> however, I find the following
> git fetch --all
> Fetching origin
> Fetching upstream
> sign_and_send_pubkey: signing failed: agent refused operation 
> Permission denied (publickey).
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights and the repository 
> exists.
> error: Could not fetch upstream
>
> I have correct ssh keys and I am almost sure about 1 hr ago it worked.
> What might have happened?
>
> I created new ssh key but it is still not working
>
> Kind regards,
> Piotr
>
>   [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org<mailto:Bioc-devel@r-project.org> mailing list 
> https://stat.ethz.ch/mailman/listinfo/bioc-devel



This email message may contain legally privileged and/or confidential
information.  If you are not the intended recipient(s), or the employee or
agent responsible for the delivery of this message to the intended
recipient(s), you are hereby notified that any disclosure, copying,
distribution, or use of this email message is prohibited.  If you have
received this message in error, please notify the sender immediately by
e-mail and delete this email message from your computer. Thank you.


This email message may contain legally privileged and/or confidential
information.  If you are not the intended recipient(s), or the employee or
agent responsible for the delivery of this message to the intended
recipient(s), you are hereby notified that any disclosure, copying,
distribution, or use of this email message is prohibited.  If you have
received this message in error, please notify the sender immediately by
e-mail and delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

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

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

[Bioc-devel] DOI information

[Felix Ernst]

Dear BioC-Team,

 

Just as little bug report. I don't want to make a big deal about it:

I just imported the citation information for my package tRNAscanImport into
Citavi using the doi number and the last name was not imported correctly. Is
this due to the middle name(s)? On the package page everything is correct.
The test import using the doi for GenomicRanges worked, but nobody with a
middle name is present. Also I don't know how the information is actually
retrieved providing the doi number to Citavi.

 

I  just wanted to let you know. Any suggestions, how I can follow up/debug
it this on my end?

 

Kind regards,

Felix


[[alternative HTML version deleted]]

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

[Bioc-devel] AAString - Amino acid code enforced?

[Felix Ernst]

Dear all,

probably this is for Hervé Pagès:

I tried the following code, which should according to ?AAString not work, since 
ÜÖÄ are not part of any AA code.

> AAString("ÜÄÖ")
  3-letter "AAString" instance
seq: ÜÄÖ
> sessionInfo()
R version 3.4.4 (2018-03-15)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows >= 8 x64 (build 9200)

Matrix products: default

locale:
[1] LC_COLLATE=German_Germany.1252  LC_CTYPE=German_Germany.1252
LC_MONETARY=German_Germany.1252 LC_NUMERIC=C   
[5] LC_TIME=German_Germany.1252

attached base packages:
[1] stats4parallel  stats graphics  grDevices utils datasets  
methods   base 

other attached packages:
[1] Biostrings_2.46.0   XVector_0.18.0  IRanges_2.12.0  
S4Vectors_0.16.0BiocGenerics_0.24.0

loaded via a namespace (and not attached):
[1] zlibbioc_1.24.0 compiler_3.4.4  tools_3.4.4 yaml_2.1.18


I don’t have access right now to the devel version of Biostrings, bit I checked 
out the current Code in the github repo and its recent changes. I am pretty 
sure, that this behavior is also in the current devel branch. Can someone 
confirm this?

My current interest is in using the XString classes and methods for an 
additional biological string representation. The initial question was, how can 
I restrict this to a certain character set, if the characters are not saved 
byte encoded? The latter option is not available to me, since characters like 
‚«‘ or ‚=‘ result in a two byte code using the charToRaw function. This trips 
up the build of the internal lookup table, which are passed down to the C 
backend.

Therefore I looked into, how this is done for an AAString differing from a 
BString. I discovered, that it currently doesn‘t. I also looked into the 
current 2.47.12 repo, which as far as I can tell does not use the 
AMINO_ACID_CODE constant in the creation of an AAString object.

So my questions are:
- What is the best practice for extending a class from XString with a 
restricted character set, which is not byte encoded?
- Is there a way to use byte encoding for chars with two ore more bytes?

 Thanks in advance for any help and suggestions.

Best regards,
Felix

PS: regarding the second question: One could change 
„as.integer(charToRaw(paste(letters, collapse="")))“ to 
„lapply(lapply(letters,charToRaw),as.integer)“ in .letterAsByteVal, but in any 
case it will not be atomic anymore, which I think is required to be excepted by 
the C backend. I didn’t test it.






[[alternative HTML version deleted]]

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

[Bioc-devel] SummarizedExperiment: duplication of metadata, when modifying colData

[Felix Ernst]

Hi all,

 

I got a bit of weird behaviour with SummarizedExperiments in Bioc 3.6 and
3.7. I suppose it is a bug, but I might be wrong, since the accession to the
SummarizedExperiment object is not really straight forward. Any suggestions?

library(GenomicRanges)

library(SummarizedExperiment)

 

nrows <- 200; ncols <- 6

counts <- matrix(runif(nrows * ncols, 1, 1e4), nrows)

colnames(counts) <- LETTERS[1:6]

rownames(counts) <- 1:nrows

counts2 <- counts-floor(counts)

rowRanges <- GRanges(rep(c("chr1", "chr2"), c(50, 150)),

 IRanges(floor(runif(200, 1e5, 1e6)), width=100),

 strand=sample(c("+", "-"), 200, TRUE),

 feature_id=sprintf("ID%03d", 1:200)) 

colData <- DataFrame(Treatment=rep(c("ChIP", "Input"), 3),

 row.names=LETTERS[1:6])

 

se <- SummarizedExperiment(assays=list(counts=counts),

   rowRanges=rowRanges,

   colData=colData)

colData(se)$xyz <- rep("",ncol(se))

metadata(se) <- list("meep" = "meep")

 

str(metadata(se))

colData(se[, 1])$xyz <- "abc"

str(metadata(se))

The first metadata() returns a list, length of 1, with the correct data. The
second call returns a list of two, with a duplicated entries and every
further colData modification (and replacing data) duplicates the entries in
the metadata further.

> str(metadata(se))

List of 1

$ meep: chr "meep"

> colData(se[, 1])$xyz <- "abc"

> str(metadata(se))

List of 2

$ meep: chr "meep"

$ meep: chr "meep"
> colData(se[, 2])$xyz <- "abc"

> str(metadata(se))

List of 4

$ meep: chr "meep"

$ meep: chr "meep"

$ meep: chr "meep"

$ meep: chr "meep"

> colData(se[, 2])$xyz <- "abc"

> str(metadata(se))

List of 8

$ meep: chr "meep"

$ meep: chr "meep"

$ meep: chr "meep"

$ meep: chr "meep"

$ meep: chr "meep"

$ meep: chr "meep"

$ meep: chr "meep"

$ meep: chr "meep"

Thanks for any advice and suggestions.

Felix



---



Felix Ernst, PhD

Universit� Libre de Bruxelles

RNA MOLECULAR BIOLOGY

BIOPARK Charleroi Brussels-South CAMPUS

Rue Profs Jeener & Brachet, 12

B-6041 Charleroi - Gosselies

BELGIUM

+32(2)650 9774 (office phone)

 <mailto:felix.er...@ulb.ac.be> felix.er...@ulb.ac.be

 






[[alternative HTML version deleted]]

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