Hi Nitesh,
I have checked my mail and I have 3 different SVN ids, one for each package
I have submitted:
- r.carlos: MEAL
- c.ruiz-arenas: MultiDataSet
- c.ruiz: scoreInvHap
When I submitted MultiDataSet, I asked Bioc to consolidate my svn user.
From then, I used c.ruiz-arenas for MEAL and Multi
Hi Carlos
Your ID is standardized across all your packages now to “c.ruiz”. Your key is
the one your submitted most recently
ssh-rsa
B3NzaC1yc2EDAQABAAABAQDEMdup9kYuv4KO5MO1lctLXl4Griu571wbbDZU+ueZHhtuEm2WBqWTC0Zp6V+rszWORQkDGcM2ym+pVMNapSbFFbCJPDG1kxXpJI+2
…..
Please use that key to
Bioc-git server* (git.bioconductor.org).
Ignore the typo.
> On Sep 14, 2017, at 2:20 PM, ni41435_ca wrote:
>
> Hi Carlos
>
> Your ID is standardized across all your packages now to “c.ruiz”. Your key is
> the one your submitted most recently
>
> ssh-rsa
> B3NzaC1yc2EDAQABAAABAQDEM
Hi Carlos,
Do you by any chance have 2 separate SVN id’s?
1. c.ruiz
2. c.ruiz-arenas
Best,
Nitesh
> On Sep 14, 2017, at 12:17 PM, Carlos Ruiz wrote:
>
> Hi,
> Today I definitely was able to fetch from the Bioc git. However, I cannot
> push. Here, the commands and the error:
>
>
> C:\Use
Hi Carlos,
Give me a till tomorrow to solve this.
Good news is r.carlos isn’t used anywhere yet. I think this is mostly on our
end, and not on your end.
Best,
Nitesh
> On Sep 14, 2017, at 1:30 PM, Carlos Ruiz wrote:
>
> Hi Nitesh,
>
> I have checked my mail and I have 3 different SVN ids
Thank you for the quick fix and reply Andrzej. best, Mike
On Thu, Sep 14, 2017 at 6:30 PM, Andrzej Oleś wrote:
> Hi Mike,
>
> thanks for reporting this. Strange, not sure what the problem was because
> now I was able to rebuild the workflow without actually reinstalling or
> reconfiguring anythin
On 09/14/2017 02:23 PM, Laurent Gatto wrote:
On 14 September 2017 15:15, Hervé Pagès wrote:
Hi,
Note that right now the name of the Ontology getter matches the
name of the corresponding field in all our annotations:
> library(org.Hs.eg.db)
> org.Hs.egGO[["92610"]][["GO:0005622"]]
Hi Mike,
thanks for reporting this. Strange, not sure what the problem was because
now I was able to rebuild the workflow without actually reinstalling or
reconfiguring anything on the builder. Maybe this was a transient issue
related to the fact that I updated the LaTeX distro on the builder some
On 14 September 2017 15:15, Hervé Pagès wrote:
> Hi,
>
> Note that right now the name of the Ontology getter matches the
> name of the corresponding field in all our annotations:
>
>> library(org.Hs.eg.db)
>
>> org.Hs.egGO[["92610"]][["GO:0005622"]]
>$GOID
>[1] "GO:0005622"
>
>
Dear Herve,
Your solution worked out, no 'R CMD check' warning.
--
Tomasz
On Thu, 14 Sep 2017 18:09:44 +0200,
wrote:
Hi Tomasz,
The name of the BSgenome object defined in a BSgenome data package
is the name of the package itself. Hsapiens is just an convenient
"alias" for the long name. S
You are welcome.
Begin forwarded message:
From: "Oghabian, Ali"
mailto:ali.oghab...@helsinki.fi>>
Subject: Re: Getting w+r access for my package (IntEREst); svn/git transfer
problem (Problem remains unsloved)
Date: September 14, 2017 at 12:19:37 PM EDT
To: "Turaga, Nitesh"
mailto:nitesh.tur...
hi,
I pushed a change to rnaseqGene workflow and only winbuilder1 had a problem:
* checking PDF version of manual ...Warning: running command
'"C:/Progra~1/R/R-3.4.0/bin/x64/Rcmd.exe" Rd2pdf --batch --no-preview
--build-dir="C:/Windows/TEMP/RtmpE9T1fB/Rd2pdff6059a733c8" --no-clean
-o rnaseqGene
Hi,
Note that right now the name of the Ontology getter matches the
name of the corresponding field in all our annotations:
> library(org.Hs.eg.db)
> org.Hs.egGO[["92610"]][["GO:0005622"]]
$GOID
[1] "GO:0005622"
$Evidence
[1] "IEA"
$Ontology
[1] "CC"
> library(GO.db)
> G
Hi Tomasz,
The name of the BSgenome object defined in a BSgenome data package
is the name of the package itself. Hsapiens is just an convenient
"alias" for the long name. So you could do:
importFrom(BSgenome.Hsapiens.UCSC.hg19, BSgenome.Hsapiens.UCSC.hg19)
importFrom(BSgenome.Hsapiens.UCSC.hg38,
I think the point is that CMD check will issue a warning for the symbol
collision implied by the import statements. I don't know that there is a
way to do this. I think the namespace should be made to avoid conflicts
and if a given name can have distinct values you will have to use code to
sort t
Hi,
That is an invalid key. Please regenerate your key with the instructions
provided in the http://bioconductor.org/developers/how-to/git/faq/ (FAQ
section).
Resubmit to the google-form.
Best,
Nitesh
> On Sep 14, 2017, at 8:12 AM, Vojtech Kulvait wrote:
>
> Hi,
> I would like to ask yo
Hello Tomaszu,
On 9/14/17 2:14 PM, Tomasz Stokowy wrote:
Could you suggest how to avoid this warning? I would like to use both hg19 and
hg38 references in my package.
super easy:
library(BSgenome.Hsapiens.UCSC.hg19)
suppressMessages(library(BSgenome.Hsapiens.UCSC.hg38))
_
The Cell Line Ontology includes tokens like
CSMaß1H cell
which trigger warnings if included in .rda files in data folder.
They can be masked using iconv but it seems unfortunate to do this.
The offending .rda files can be kept elsewhere and loaded
by function. Is that the appropriate practice
Dear bioc-devel,
I would like to import Hsapiens objects from both
BSgenome.Hsapiens.UCSC.hg19
and
BSgenome.Hsapiens.UCSC.hg38
this is currently handled in the namespace of my package by
import(BSgenome.Hsapiens.UCSC.hg19)
import(BSgenome.Hsapiens.UCSC.hg38)
I get warning (because I assign two
Dear all,
I cc-ed to this email individual package maintainer to directly 'notify'
them of this thread and have their respective opinions, but I thought the
common use of SummarizedExperiment was worth involving the community as
well.
Background: I was updating one of my workflow from SCESet to t
20 matches
Mail list logo
