Hi Onur,
AFAICT ChIPseeker is currently available on all platforms in BioC devel:
https://bioconductor.org/packages/3.13/ChIPseeker
Same for all the other Bioconductor packages that the CRAN check results
for cinaR say are not available:
- CRAN check results:
Thanks Dario.
Could we please use my gmail address for this (this address), which is the
one I used for registering my Bioconductor account.
(Sorry for possible duplicate email - I previously tried replying from my
other address, which is not registered to the Bioc-devel list so email
possibly
Hi all,
I have a CRAN package called cinaR which depends on ChIPseeker. Yet, I
recently learned that ChIPseeker is actually failing on r-devel checks of
CRAN, which possibly fails my package as well. You can find the detailed
info here:
https://support.bioconductor.org/p/9135778/
Can anyone
Thanks Dario.
Could we please use my gmail address for this (cc’d), which is the address I
used for registering my Bioconductor account.
Best regards,
Lukas
Lukas M. Weber, Ph.D.
Postdoctoral Fellow
Department of Biostatistics
Johns Hopkins Bloomberg School of Public Health
On 3/23/21 1:31 PM, Murphy, Alan E wrote:
Hi Hervé,
My apologies but I don't think I follow your approach. I have put your
code below into a utils.R script in ewceData:
.my_internal_global_variables <- new.env(parent=emptyenv())
.get_eh <- function() get("eh",
Hi Herv�,
My apologies but I don't think I follow your approach. I have put your code
below into a utils.R script in ewceData:
.my_internal_global_variables <- new.env(parent=emptyenv())
.get_eh <- function() get("eh", envir=.my_internal_global_variables)
.set_eh <- function(value)
Hi Guys,
we'd like to add Helena Crowell and Lukas Weber (CC) as maintainers of
the SpatialExperiment repo so that they can push on the upstream.
Thanks,
Dario
___
Bioc-devel@r-project.org mailing list
Doesn't really matter where you put them but
.my_internal_global_variables, .get_eh(), .set_eh(), and toto() don't
need to be defined inside the .onLoad() hook, and it's actually
cleaner/easier to not define them there. You can define there anywhere
in your ewceData/R/* files.
Here is a
Hey Herv�,
Thanks for this it is very helpful and I'm very sorry but I have one more
question, where to put option 3? I thought making an onload r script for it:
.onLoad <- function(libname, pkgname) {
.my_internal_global_variables <- new.env(parent=emptyenv())
.get_eh <- function()
3 ways to do this, one that doesn't work, and two that work ;-)
1. Simple way that doesn't work:
## Just a place holder. Will be initialized at run-time the first
## time it's needed.
.some_internal_global_variable <- NULL
toto <- function()
{
if (is.null(.some_global_variable))
Hey Herv�,
I get the idea now thanks for clarifying. Where do I place the call to
ExperimentHub in the package?:
eh <- ExperimentHub() # the only call to ExperimentHub() in
# the entire R session
The package contains calls to the datasets in internal functions,
On 3/23/21 6:33 AM, Mike Smith wrote:
...
Finally I'll point out there's a testthat::skip_on_bioc() function that
will allow you to skip a test on the Bioc builder, but still run that test
locally/on GitHub etc.
What?!
> testthat::skip_on_bioc
function ()
{
if
On 3/23/21 4:11 AM, Murphy, Alan E wrote:
Hi,
Thank you very much Martin and Hervé for your suggestions. I have reverted my zzz.R on load
function to that advised by ExperimentHub and had used the ID look up (system.time(tt_alzh
<- eh[["EH5373"]])) on internal functions and unit tests.
Hi Alan,
I wonder if there are instances in your tests where you can use pseudo data
or mock the behaviour of certain functions. For me the aim of unit testing
is to confirm the behaviour of functions under controlled conditions, but
it doesn't necessarily have to be done using 'real' data.
For
OK that makes sense - apologies, it stated in the issue that "Your package
will be included in the next nigthly 'devel' build" and I misinterpreted.
Thanks for clarifying!
Cheers
On Tue, 23 Mar 2021 at 11:40, Kern, Lori
wrote:
> Your package was identified as a workflow package based you the
Hi,
Thank you very much Martin and Hervé for your suggestions. I have reverted my
zzz.R on load function to that advised by ExperimentHub and had used the ID
look up (system.time(tt_alzh <- eh[["EH5373"]])) on internal functions and unit
tests. However, the check is still taking ~18 minutes so
Your package was identified as a workflow package based you the biocViews you
selected. The workflow packages did not build last Friday and next run is
today. You should check the following page for your workflow package build
results:
Dear all,
I am the maintainer of the package ExpHunterSuite. This was accepted
thursday, and on Friday (19/03) the issue raised on the
Bioconductor/contributions github page was closed (ExpHunterSuite #1835,
https://github.com/Bioconductor/Contributions/issues/1835 ).
The last message on the
Hi Sarah,
Just to reiterate Marcel's point, if these are new features or tweaks to
your package, then they shouldn't be committed to the release branch at
all. The Bioconductor ethos is that the release version of a package
should remain stable for a 6 month window (the release cycle), and
19 matches
Mail list logo
