> Hugh Parsonage writes:
Thanks, will fix.
Best
-k
> In r75110 at line 1846 in src/library/tools/R/check.R the following
> line was changed
> - if(length(grep("^Found the defunct/removed function", out8)))
> + if(any(startsWith(out8, "Found the defunct/removed function")))
> However, if
That helps. I think I start to understand what you are after.
See below...
On 08/13/2018 06:07 PM, Michael Love wrote:
dear Hervé,
Thanks for the quick reply about directions to take this.
I'm sorry for not providing sufficient detail about the goal of block
bootstrapping in my initial post.
In r75110 at line 1846 in src/library/tools/R/check.R the following
line was changed
- if(length(grep("^Found the defunct/removed function", out8)))
+ if(any(startsWith(out8, "Found the defunct/removed function")))
However, if `out8` is NULL at this point (which is plausible), the
original
dear Hervé,
Thanks for the quick reply about directions to take this.
I'm sorry for not providing sufficient detail about the goal of block
bootstrapping in my initial post. Let me try again. For a moment, let
me ignore multiple chromosomes/seqs and just focus on a single set of
IRanges.
The
To record the value of the function as well as the arguments, you can use
the following
instrumentObjectiveFunction <- function(FUN) {
newFUN <- local({
INFO <- list()
function(...) {
value <- FUN(...)
INFO[[length(INFO)+1]] <<- list(args=list(...),
Since you're already using bang-bang ;)
library(rlang)
dots1 <- function(...) as.list(substitute(list(...)))[-1L]
dots2 <- function(...) as.list(substitute(...()))
dots3 <- function(...) match.call(expand.dots = FALSE)[["..."]]
dots4 <- function(...) exprs(...)
bench::mark(
dots1(1+2, "a",
Hi Michael,
On 08/13/2018 01:39 PM, Michael Love wrote:
dear Bioc-devels,
From a conversation on Twitter [1], I've been wondering if there has
been any work to implement block bootstrap for GRanges.
I guess that's my main question, and then the rest is details and
ideas in case it hasn't
Despite my years with R, I didn't know about trace(). Thanks.
However, my decades in the minimization and root finding game make me like
having
a trace that gives some info on the operation, the argument and the current
function value.
I've usually found glitches are a result of things like >=
I tend to avoid the the trace/verbose arguments for the various root
finders and optimizers and instead use the trace function or otherwise
modify the function handed to the operator. You can print or plot the
arguments or save them. E.g.,
> trace(ff, print=FALSE, quote(cat("x=", deparse(x),
vapply has a mandatory FUN.VALUE argument which specifies the type and size
of FUN's return value. This helps when you want to cover the 0-length case
without 'if' statements. You can change your apply calls to vapply calls,
but they will be a bit more complicated. E.g., change
dear Bioc-devels,
>From a conversation on Twitter [1], I've been wondering if there has
been any work to implement block bootstrap for GRanges.
I guess that's my main question, and then the rest is details and
ideas in case it hasn't already been done.
The block bootstrap helps to create
Just to close the loop on this - the conversation went off-line and was
resolved. When the omabrowser server OS was changed from Ubuntu to CentOS the
problems on the Windows builders went away.
Valerie
On 07/23/2018 08:14 AM, Obenchain, Valerie wrote:
Hi Klara,
Unfortunately I still don't
Today I saw an error from CRAN that I did not see in Win-builder or on
my system with Ubuntu Linux. This is from the CRAN Debian test system:
* checking for unstated dependencies in vignettes ... OK
* checking package vignettes in ‘inst/doc’ ... OK
* checking re-building of vignette outputs ...
I'm looking for where in the source recycling and vector
multiplication+addition are defined. I see some stuff in
~/src/main/arithmetic.c.
Is there anywhere else I should be looking as well?
Cheers
--
isomorphi...@sdf.org
SDF Public Access UNIX System - http://sdf.org
Can you advise me about this warning in package check:
Package has a VignetteBuilder field but no prebuilt vignette index.
In my vignette folder, I do have an "index.html" file, the index in
the installed package is fine. But I still get this package build
warning:
I asked same question on
Thank you for your patience. The Single Package Builder should now be updated
and functioning properly.
Cheers,
Lori Shepherd
Bioconductor Core Team
Roswell Park Cancer Institute
Department of Biostatistics & Bioinformatics
Elm & Carlton Streets
Buffalo, New York 14263
Note that your attachment was lost, so we don't know what your package code
looks like. It's helpful to host your package sources somewhere publicly
accessible (e.g. GitHub) to make it easier for others to access sources
quickly from a web browser.
My best guess is that your 'init.c' is missing
> On 12 Aug 2018, at 00:18, peter dalgaard wrote:
>
> Have you tried asking CRAN for help? I mean, if you don't fix an obvious
> error, with a well-known cause, like the log thing, they'll get fed up and
> throw you off. However, fixing and then discovering an issue elsewhere is
> different,
Dear Karol,
thank you for the report. I can reproduce that the function from you
example takes very long to compile and I can see where most time is
spent. The compiler is itself written in R and requires a lot of
resources for large functions (foo() has over 16,000 lines of code,
nearly 1
On 13.08.2018 16:51, Duncan Murdoch wrote:
On 13/08/2018 9:08 AM, Eggleston, Barry wrote:
Hello,
I am working through my first submission and making good progress with
the CRAN review system, but now I need to understand the best practice
for dealing with helper functions. I am building
On 13/08/2018 9:08 AM, Eggleston, Barry wrote:
Hello,
I am working through my first submission and making good progress with the CRAN
review system, but now I need to understand the best practice for dealing with
helper functions. I am building a package that only exports 12 functions for
There are several other things to do. You might find the toy package
fooRegister I use for teaching helpful.
https://github.com/cjgeyer/foo/tree/master/package/fooRegister
--
Charles Geyer
Professor, School of Statistics
Resident Fellow, Minnesota Center for Philosophy of Science
University of
Thanks everybody. And just to clarify, it is no why that CRAN knew the
functions in question were helper functions. From their perspective, I just
had a lot of .Rd files with ‘#none’ under @examples. Since these files under
question are not directly accessible to the user, I will try the
#'
Do you have to export them? If not, I think you can just leave out the
@export from the roxygen2 comments.
Here is what I did for my package:
https://github.com/boxuancui/DataExplorer/blob/master/R/helper.r
Best,
Boxuan (Bo)
On Mon, Aug 13, 2018 at 2:08 PM Eggleston, Barry wrote:
>
> >
You can add
#' @noRd
to those functions and roxygen2 will not generate .Rd files for those
entries.
On Mon, Aug 13, 2018 at 2:08 PM Eggleston, Barry wrote:
> Hello,
>
> I am working through my first submission and making good progress with the
> CRAN review system, but now I need to
Hi Barry,
could you specify wh osked you to provide examples? R CHECK doesn't give me
any warnings. If it was asked by the people of CRAN itself, you can explain
that these are internal functions and the help pages are only there for
reference to advanced users. But I'm not sure if they'll accept
Hello,
I am working through my first submission and making good progress with the CRAN
review system, but now I need to understand the best practice for dealing with
helper functions. I am building a package that only exports 12 functions for
direct user access, but it has many helper
We will be updating the Single Package Builder for new package submissions this
morning. While the updates are occurring there will be a temporary downtime
for submitting new packages and receiving the automatically generated build
reports for existing submissions. We will announce when it is
I think it depends on the journal and your order of priority. Essentially they
are separate tasks but it is always nice when submitting to a journal to link
to the accepted package on Bioconductor rather than a github repository. Keep
in mind the review process for a package to be accepted to
Thanks all, this was very helpful. Peter's finding - dots2() below -
is indeed interesting - I'd be curious to learn what goes on there.
The different alternatives perform approximately the same;
dots1 <- function(...) as.list(substitute(list(...)))[-1L]
dots2 <- function(...)
To whom it may concern,
We are a bioinformatics team from the American University of Beirut, we
are currently working on our package to submit to bioconductor.
We have a question which we hope you can help us with.
We plan on writing a paper regarding our package, is it recommended to
wait to
31 matches
Mail list logo
