Re: [R-pkg-devel] Help on Windows CRAN Check
> John Lawson
> on Thu, 5 Mar 2020 20:34:00 -0700 writes:
> I see this error on windows CRAN Check
> --- failure: the condition has length > 1 ---
> --- srcref ---
> :
> --- package (from environment) ---
> daewr
> --- call from context ---
> ihstep(y, x, m, c)
> --- call from argument ---
> if (t1 == "I" & t2 == "(") {
> iquad = TRUE
> }
> t1 and t2 are both characters of length 1, therefore I assume they are
> scalars. The check on my own computer or R forge gives no errors. When
> I change if(t1 == "I" & t2 =="(") {iquad=TRUE} to
> if(t1 == "I" && t2 =="(") {iquad=TRUE}
> I get the following error when I try the check on my own computer
> --- FAILURE REPORT --
> --- failure: length > 1 in coercion to logical ---
> --- srcref ---
> :
> --- package (from environment) ---
> daewr
> --- call from context ---
> ihstep(y, x, m, c)
> --- call from argument ---
> t1 == "I" && t2 == "("
> --- R stacktrace ---
> where 1: ihstep(y, x, m, c)
> where 2: eval(expr, pf)
> where 3: eval(expr, pf)
> where 4: withVisible(eval(expr, pf))
> where 5: evalVis(expr)
> where 6: capture.output(res <- ihstep(y, x, m, c))
> where 7: withCallingHandlers(expr, warning = function(w)
> invokeRestart("muffleWarning"))
> I am not sure what this means. Using one &, I am able to check and
> build the package on my computer or R forge but not on CRAN. When
> using two && I can't check and build on my own computer. Any advice on
> what to do would be greatly appreciated.
Well, to me it seems clear that your claim
"t1 and t2 are both characters of length 1, therefore .."
must be wrong sometimes and that's why you these problems:
In both cases, the respective error is triggered *if and only if*
at least one of t1 or t2 is *not* of length 1.
Martin
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Building Windoze packages using rhub.
Recently I complained about the fact that it was taking forever for
packages to come back to me from the winbuilder facility that Uwe Ligges
so kindly provides.
Ben Bolker suggested that I use "rhub" instead. I responded that I'd
*heard* of rhub but had no real idea what it was nor how to use it. Roy
Mendelssohn chimed in with "Download the 'rhub' package. Then
submission to 'rhub' is one easy command."
Well, "Hah!" I say to that!!! :-) Easy perhaps if you are not a Bear of
Very Little Brain, as I am. However it seems to be do-able, even for a
Bear of Very Little Brain, and I managed (I think!!!) to get it to work.
Since I found the procedure a bit opaque, I thought I would set out step
by step instructions, that perhaps others might find useful.
(1) Install rhub. E.g. in R issue the command
install.packages("rhub",lib=)
(2) Load rhub: library(rhub)
(3) Validate your email address: validate_email()
You get prompted for an email address, and then asked for a verification
code. That code gets emailed to you; copy and paste it in and you're
good to go.
(4) Then (and this is one of the things that foxed me) you invoke the
*check()* function from the rhub package. (For the love of Pete, I
don't want to check the package, I want to *build*
it!!! But never mind.) The simplest thing to do is to make sure your
working directory is that in which the source package lives. Then issue
the command
xxx <- check("blah_1.1-1.tar.gz",platform="windows-x86_64-release")
where of course "blah_1.1-1.tar.gz" is the name of the tarball holding
your source package.
Wait a while --- the function keeps you pretty well informed of what
it's doing.
Finally it completes, and you see that xxx is an object of class
"rhub_check" "R6" that prints as:
── blah 1.1-1: OK
Build ID: blah_1.1-1.tar.gz-3b30749f06644fd4833d02da6ec895fb
Platform: Windows Server 2008 R2 SP1, R-release, 32/64 bit
Submitted: 3h 56m 39.3s ago
Build time: 11m 54.2s
0 errors ✔ | 0 warnings ✔ | 0 notes ✔
(5) Now what? Here's where I really got foxed. I want a Windoze
binary. Where the is it?
Then I noticed that I'd got an email. It was headed "blah 1.1-1 OK" and
contained essentially the same material as did xxx. But it also had:
See the full build log: HTML, text, artifacts.
This did not look at all promising; I did not want the deleted> build log, nor any "artefacts", but I clicked on "artefacts"
out of curiosity. And *this*, mirabile dictu, took me to a page from
which I could download blah_1.1-1.zip, and this was indeed the required
Windoze binary.
Ta-da!!! Victory. I hope that those who are as mentally handicapped as
I am find the foregoing useful.
cheers,
Rolf Turner
--
Honorary Research Fellow
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[Bioc-devel] [rOpenSci] Community Call: Maintaining an R Package
Hi BioC-devel, Since 2018 I've been interacting with rOpenSci's organizers. For those that don't know, rOpenSci https://ropensci.org/ is a non-profit that aims to > make scientific data retrieval reproducible. Over the past seven years we > have developed an ecosystem of open source tools, we run annual > unconferences, and review community developed software. (taken from their https://ropensci.org/about/ page) That is, they are in some ways similar to Bioconductor and that's why they want to build a bridge between the two communities. Stefanie Butland, their community manager, invited me to be a part of a community call (webinar) on the topic of Maintaining an R Package in order to bring in a little bit of the Bioconductor perspective. They have a pretty nice system where they take questions before hand through a GitHub issue page, so please feel free to chime in. I think that besides the Bioconductor side, I bring in a bit of the CDSB perspective (the work we do to help others in Mexico and Latin America). In any case, feel free to tune in to the webinar (details below) as well as share the information with anyone who might be interested. https://support.bioconductor.org/p/128869/ Best, Leo ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] CDSB Workshop 2020: Building workflows with RStudio and Bioconductor for single cell RNA-seq analysis
Hi, I should clarify that this workshop will be held in Cuernavaca, Morelos, Mexico during August 3rd to the 7th, 2020. Best, Leo On Thu, Mar 5, 2020 at 10:05 PM Leonardo Collado Torres wrote: > > Hi BioC-devel! > > We just made the announcement of our CDSB 2020 workshop at > https://support.bioconductor.org/p/128868/ + Twitter & Facebook (both > in English and Spanish). Joselyn and Rob will be among our > instructors. Thank you Bioconductor Foundation for the support! > > Please help us spreading the word around. Also, if you have any > contacts that you think might be interested in sponsoring the > workshop, please let us know. At > https://comunidadbioinfo.github.io/niveles-de-patrocinio/ we answer > the question why should you support us? Thanks! > > Best, > Leo > > Leonardo Collado Torres, Ph. D., Staff Scientist II > Lieber Institute for Brain Development > 855 N Wolfe St, Suite 300 > Baltimore, MD 21205 > Website: http://lcolladotor.github.io ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[R-pkg-devel] Help on Windows CRAN Check
I see this error on windows CRAN Check
--- failure: the condition has length > 1 ---
--- srcref ---
:
--- package (from environment) ---
daewr
--- call from context ---
ihstep(y, x, m, c)
--- call from argument ---
if (t1 == "I" & t2 == "(") {
iquad = TRUE
}
t1 and t2 are both characters of length 1, therefore I assume they are
scalars. The check on my own computer or R forge gives no errors. When
I change if(t1 == "I" & t2 =="(") {iquad=TRUE} to
if(t1 == "I" && t2 =="(") {iquad=TRUE}
I get the following error when I try the check on my own computer
--- FAILURE REPORT --
--- failure: length > 1 in coercion to logical ---
--- srcref ---
:
--- package (from environment) ---
daewr
--- call from context ---
ihstep(y, x, m, c)
--- call from argument ---
t1 == "I" && t2 == "("
--- R stacktrace ---
where 1: ihstep(y, x, m, c)
where 2: eval(expr, pf)
where 3: eval(expr, pf)
where 4: withVisible(eval(expr, pf))
where 5: evalVis(expr)
where 6: capture.output(res <- ihstep(y, x, m, c))
where 7: withCallingHandlers(expr, warning = function(w)
invokeRestart("muffleWarning"))
I am not sure what this means. Using one &, I am able to check and
build the package on my computer or R forge but not on CRAN. When
using two && I can't check and build on my own computer. Any advice on
what to do would be greatly appreciated.
John Lawson
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[Bioc-devel] CDSB Workshop 2020: Building workflows with RStudio and Bioconductor for single cell RNA-seq analysis
Hi BioC-devel! We just made the announcement of our CDSB 2020 workshop at https://support.bioconductor.org/p/128868/ + Twitter & Facebook (both in English and Spanish). Joselyn and Rob will be among our instructors. Thank you Bioconductor Foundation for the support! Please help us spreading the word around. Also, if you have any contacts that you think might be interested in sponsoring the workshop, please let us know. At https://comunidadbioinfo.github.io/niveles-de-patrocinio/ we answer the question why should you support us? Thanks! Best, Leo Leonardo Collado Torres, Ph. D., Staff Scientist II Lieber Institute for Brain Development 855 N Wolfe St, Suite 300 Baltimore, MD 21205 Website: http://lcolladotor.github.io ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [R-pkg-devel] Winbuilder queues jammed again?
Download the 'rhub' package. Then submission to 'rhub' is one easy command. HTH, -Roy > On Mar 5, 2020, at 3:33 PM, Rolf Turner wrote: > > > On 6/03/20 11:14 am, Ben Bolker wrote: > > > >> It's probably been suggested already in this thread, but perhaps >> rhub would work for you as an alternative? > > > > Quite possibly, but I have no real idea what "rhub" is. I've seen it > referred to many times but the references always assume that you know all > about it already. > > I'll try to investigate. Thanks for the suggestion. > > cheers, > > Rolf > > > -- > Honorary Research Fellow > Department of Statistics > University of Auckland > Phone: +64-9-373-7599 ext. 88276 > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel ** "The contents of this message do not reflect any position of the U.S. Government or NOAA." ** Roy Mendelssohn Supervisory Operations Research Analyst NOAA/NMFS Environmental Research Division Southwest Fisheries Science Center ***Note new street address*** 110 McAllister Way Santa Cruz, CA 95060 Phone: (831)-420-3666 Fax: (831) 420-3980 e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/ "Old age and treachery will overcome youth and skill." "From those who have been given much, much will be expected" "the arc of the moral universe is long, but it bends toward justice" -MLK Jr. __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Winbuilder queues jammed again?
On 6/03/20 11:14 am, Ben Bolker wrote: It's probably been suggested already in this thread, but perhaps rhub would work for you as an alternative? Quite possibly, but I have no real idea what "rhub" is. I've seen it referred to many times but the references always assume that you know all about it already. I'll try to investigate. Thanks for the suggestion. cheers, Rolf -- Honorary Research Fellow Department of Statistics University of Auckland Phone: +64-9-373-7599 ext. 88276 __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Winbuilder queues jammed again?
You can also just paste the ftp link into your browser. On Thursday, March 5, 2020, 6:31:03 PM EST, Rolf Turner wrote: On 6/03/20 11:41 am, Henrik Bengtsson wrote: > 1. I'd guess it helps Uwe a bit you clarify exactly which queue you > think is stuck - otherwise he has to check them all. They're independent. Yeah. Sorry. It's the R-release queue. > 2. You can look at the different win-builder queues yourself via ftp, > see https://stat.ethz.ch/pipermail/r-package-devel/2020q1/005098.html That could be useful information, but when I tried just now I could not get curl to work: > curl -s ftp://win-builder.r-project.org/R-release/ > curl: /usr/local/lib/libcurl.so.4: no version information available (required > by curl) > curl: relocation error: curl: symbol curl_mime_headers version CURL_OPENSSL_4 > not defined in file libcurl.so.4 with link time reference I then tried sudo apt update sudo apt upgrade sudo apt install curl according to some instructions that I found on the web. It told me " > curl is already the newest version (7.58.0-2ubuntu3.8). > 0 to upgrade, 0 to newly install, 0 to remove and 0 not to upgrade. I then did curl --version and got > curl: /usr/local/lib/libcurl.so.4: no version information available (required > by curl) > curl: relocation error: curl: symbol curl_mime_headers version CURL_OPENSSL_4 > not defined in file libcurl.so.4 with link time reference I've Googled about a bit and found various references, but nothing that I could understand or use. I don't understand what's going on/wrong. Nor do I understand why the Computer Gods hate me! :-) cheers, Rolf -- Honorary Research Fellow Department of Statistics University of Auckland Phone: +64-9-373-7599 ext. 88276 __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Winbuilder queues jammed again?
On 6/03/20 11:41 am, Henrik Bengtsson wrote: 1. I'd guess it helps Uwe a bit you clarify exactly which queue you think is stuck - otherwise he has to check them all. They're independent. Yeah. Sorry. It's the R-release queue. 2. You can look at the different win-builder queues yourself via ftp, see https://stat.ethz.ch/pipermail/r-package-devel/2020q1/005098.html That could be useful information, but when I tried just now I could not get curl to work: curl -s ftp://win-builder.r-project.org/R-release/ curl: /usr/local/lib/libcurl.so.4: no version information available (required by curl) curl: relocation error: curl: symbol curl_mime_headers version CURL_OPENSSL_4 not defined in file libcurl.so.4 with link time reference I then tried sudo apt update sudo apt upgrade sudo apt install curl according to some instructions that I found on the web. It told me " curl is already the newest version (7.58.0-2ubuntu3.8). 0 to upgrade, 0 to newly install, 0 to remove and 0 not to upgrade. I then did curl --version and got curl: /usr/local/lib/libcurl.so.4: no version information available (required by curl) curl: relocation error: curl: symbol curl_mime_headers version CURL_OPENSSL_4 not defined in file libcurl.so.4 with link time reference I've Googled about a bit and found various references, but nothing that I could understand or use. I don't understand what's going on/wrong. Nor do I understand why the Computer Gods hate me! :-) cheers, Rolf -- Honorary Research Fellow Department of Statistics University of Auckland Phone: +64-9-373-7599 ext. 88276 __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Winbuilder queues jammed again?
1. I'd guess it helps Uwe a bit you clarify exactly which queue you think is stuck - otherwise he has to check them all. They're independent. 2. You can look at the different win-builder queues yourself via ftp, see https://stat.ethz.ch/pipermail/r-package-devel/2020q1/005098.html /Henrik On Thu, Mar 5, 2020, 14:14 Ben Bolker wrote: > Maybe there's something queriable similar to the CRAN queue? (In an > ideal world this could even be incorporated into F Michonneau's > foghorn package ...) > >It's probably been suggested already in this thread, but perhaps > rhub would work for you as an alternative? > > On Thu, Mar 5, 2020 at 4:35 PM Rolf Turner > wrote: > > > > > > Sorry to be a pest, but I submitted a package to winbuilder more than 24 > > hours ago, and nothing has come back to me. For a while (a few days > > ago) I was getting about a 20 minute turnaround. > > > > One gets dependant on facilities such as winbuilder and gets frustrated > > when they don't perform quite as expected. > > > > I know this sounds demanding (in respect of a free service that is > > provided entirely due to Uwe's good graces), but, said he plaintively, > > is there any way that some sort of indication of the expected wait time > > could be made available? Or an indication of the length of the queue, > > or something like that? > > > > Even an indication that one's submission is still in the queue and > > hasn't disappeared into a black hole in cyberspace, would be reassuring. > > > > Apropos of the latter --- I say that I submitted a package, but in my > > state of advanced senility I can't be sure. Maybe I just *intended* to, > > but then forgot, or messed up the submission procedure, or buggered > > something else up. There seems to be no way to check that I really did > > make a submission. Such a facility would be, uh, nice. Said he, > > plaintively. > > > > cheers, > > > > Rolf Turner > > > > -- > > Honorary Research Fellow > > Department of Statistics > > University of Auckland > > Phone: +64-9-373-7599 ext. 88276 > > > > __ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] findInterval Documentation Suggestion
Trying the attachment as .txt instead of Rd.
On Thursday, March 5, 2020, 5:20:25 PM EST, brodie gaslam via R-devel
wrote:
% File src/library/base/man/findInterval.Rd
% Part of the R package, https://www.R-project.org
% Copyright 1995-2020 R Core Team
% Distributed under GPL 2 or later
\name{findInterval}
\alias{findInterval}
\title{Find Interval Numbers or Indices}
\usage{
findInterval(x, vec, rightmost.closed = FALSE, all.inside = FALSE,
left.open = FALSE)
}
\arguments{
\item{x}{numeric.}
\item{vec}{numeric, sorted (weakly) increasingly, of length \code{N},
say.}
\item{rightmost.closed}{logical; if true, the rightmost bounded
interval, \code{vec[N-1] .. vec[N]} is treated as \emph{closed},
see below.}
\item{all.inside}{logical; if true, the returned indices are coerced
into \code{1,\dots,N-1}, i.e., \code{0} is mapped to \code{1}
and \code{N} to \code{N-1}.}
\item{left.open}{logical; if true all the intervals are open at left
and closed at right; in the description \sQuote{less than or equal to}
becomes \sQuote{strictly less than}, and
\code{rightmost.closed} means \sQuote{leftmost is closed}. This may
be useful, e.g., in survival analysis computations.}
}
\description{
Given a vector of non-decreasing values \code{vec}, for each value in
\code{x} return the highest position in \code{vec} that corresponds
to a value less than or equal to that \code{x} value, or zero if none
are. Equivalently, if the values in \code{vec} are taken to be the
closed left-bounds of contiguous half-open intervals, return which of
those intervals each value of \code{x} lies in.
}
\details{
Under the default parameter values the bounds in \code{vec} define
intervals that are closed on the left and open on the right:
\preformatted{
Bound: -Inf vec[1] vec[2] ... vec[N-1] vec[N] +Inf
Interval: 0 )[ 1 )[ ... )[ N-1 )[ N
}
Intervals \eqn{0} and \eqn{N} are half-bounded, and interval \eqn{0}
is implicitly defined. Interval \eqn{0} does not exist if \code{vec}
includes \eqn{-\infty}, and interval \eqn{N} does not exist if
\code{vec} includes \eqn{+\infty}.
\code{left.open=TRUE} reverses which side of the intervals is open,
\code{rightmost.closed=TRUE} closes interval \eqn{N-1} on both sides
(or interval \eqn{1} if \code{left.open=TRUE}), and \code{all.inside=TRUE}
drops bounds \eqn{1} and \eqn{N}, which merges interval \eqn{0} into
\eqn{1} and interval \eqn{N} into \eqn{N-1}.
The internal algorithm uses interval search
ensuring \eqn{O(n \log N)}{O(n * log(N))} complexity where
\code{n <- length(x)} (and \code{N <- length(vec)}). For (almost)
sorted \code{x}, it will be even faster, basically \eqn{O(n)}.
}
\value{
vector of length \code{length(x)} with values in \code{0:N} (and
\code{NA}) where \code{N <- length(vec)}, or values coerced to
\code{1:(N-1)} if and only if \code{all.inside = TRUE} (equivalently coercing
all
x values \emph{inside} the intervals). Note that \code{\link{NA}}s are
propagated from \code{x}, and \code{\link{Inf}} values are allowed in
both \code{x} and \code{vec}.
}
\author{Martin Maechler}
\seealso{\code{\link{approx}(*, method = "constant")} which is a
generalization of \code{findInterval()}, \code{\link{ecdf}} for
computing the empirical distribution function which is (up to a factor
of \eqn{n}) also basically the same as \code{findInterval(.)}.
}
\examples{
v <- c(5, 10, 15) # create bins [5,10), [10,15), and [15,+Inf)
x <- c(2, 5, 8, 10, 12, 15, 17)
intervals <- rbind(
'match(x, v)'=match(x, v), # `x` values that are on bounds
x,
default= findInterval(x, v),
rightmost.cl= findInterval(x, v, rightmost.closed=TRUE),
left.open=findInterval(x, v, left.open=TRUE),
all.in= findInterval(x, v, all.inside=TRUE)
)
v
intervals
N <- 100
X <- sort(round(stats::rt(N, df = 2), 2))
tt <- c(-100, seq(-2, 2, length.out = 201), +100)
it <- findInterval(tt, X)
tt[it < 1 | it >= N] # only first and last are outside range(X)
## 'left.open = TRUE' means "mirroring" :
N <- length(v)
stopifnot(identical(
findInterval( x, v, left.open=TRUE) ,
N - findInterval(-x, -v[N:1])))
}
\keyword{arith}
\keyword{utilities}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] findInterval Documentation Suggestion
I've found over time that R documentation that comes off as terse at first blush is usually revealed to be precise, concise, and complete on close reading. I'm sure this is also true of `?findInterval`, but for whatever reason my brain simply refuses to extract meaning from it. Part of the problem may be that we interact with the function via a compressed form of the bounds of the intervals (only specify left bounds for 2nd interval onwards), but the semantics are described mostly in terms of the intervals themselves. This requires indirections to map the parameters to the concepts. An alternative is to first describe what the function does directly in terms of its inputs, and subsequent relate that to the intervals. If I understand correctly (in default mode) the function can be described as: Given a vector of non-decreasing values 'vec', for each value in 'x' return the highest position in 'vec' that corresponds to a value less than or equal to that 'x' value, or zero if none are. Equivalently, if the values in 'vec' are taken to be the closed left-bounds of contiguous half-open intervals, return which of those intervals each value of 'x' lies in. Compared to the original: Given a vector of non-decreasing breakpoints in ‘vec’, find the interval containing each element of ‘x’; i.e., if ‘i <- findInterval(x,v)’, for each index ‘j’ in ‘x’ v[i[j]] <= x[j] < v[i[j] + 1] where v[0] := - Inf, v[N+1] := + Inf, and ‘N <- length(v)’. At the two boundaries, the returned index may differ by 1, depending on the optional arguments ‘rightmost.closed’ and ‘all.inside’. Obviously you would be right to question whether someone who claims not to understand the documentation should venture to re-write it. Nonetheless I attach a proposed alternate version in the hopes that someone who clearly understand the original might use or adapt parts of it to make `?findInterval` more accessible to those comprehension-challenged like me. Best, Brodie __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] Winbuilder queues jammed again?
Maybe there's something queriable similar to the CRAN queue? (In an ideal world this could even be incorporated into F Michonneau's foghorn package ...) It's probably been suggested already in this thread, but perhaps rhub would work for you as an alternative? On Thu, Mar 5, 2020 at 4:35 PM Rolf Turner wrote: > > > Sorry to be a pest, but I submitted a package to winbuilder more than 24 > hours ago, and nothing has come back to me. For a while (a few days > ago) I was getting about a 20 minute turnaround. > > One gets dependant on facilities such as winbuilder and gets frustrated > when they don't perform quite as expected. > > I know this sounds demanding (in respect of a free service that is > provided entirely due to Uwe's good graces), but, said he plaintively, > is there any way that some sort of indication of the expected wait time > could be made available? Or an indication of the length of the queue, > or something like that? > > Even an indication that one's submission is still in the queue and > hasn't disappeared into a black hole in cyberspace, would be reassuring. > > Apropos of the latter --- I say that I submitted a package, but in my > state of advanced senility I can't be sure. Maybe I just *intended* to, > but then forgot, or messed up the submission procedure, or buggered > something else up. There seems to be no way to check that I really did > make a submission. Such a facility would be, uh, nice. Said he, > plaintively. > > cheers, > > Rolf Turner > > -- > Honorary Research Fellow > Department of Statistics > University of Auckland > Phone: +64-9-373-7599 ext. 88276 > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Bioc-devel] MRD measurements in Leukemic patients using NGS data in r
a few thoughts:
1) look into Shearwater (
https://bioconductor.org/packages/release/bioc/html/deepSNV.html), then
2) talk to Todd Druley @ WashU, Elli Pappaemanuil @ MSKCC, Ruud & Bob @
Erasmus, the usual suspects
3) plan to validate w/ddPCR (at the absolute very least) and be aware that
most MRD in leukemia is done by a combination of BCR/TCR + breakpoint PCR
(lymphoid/fusion-driven) or DFN flow (myeloid + normal cyto)
not saying that ML-based methods might not help, but if you've got a
30x-100x genome (or even 1000x FM1) and are trying to compete with existing
standard approaches that can detect molecules at 1e-6, it'll be rough. An
alternative approach (that has been used repeatedly) is to throw caution to
the wind, generate primers for numerous subject-specific somatic variants,
and use the ensemble to try and model MRD (speaking of ML). On the one
hand, that could give the clinic a "customer for life"; on the other hand,
it's not conducive to large-scale automation & deployment. As far as I
know, it never got much traction, in leukemia or anywhere else. (Consider
that flow cytometry is capable of detecting 1-in-10K to 1-in-a-million
cells in most clinical flow labs.)
Best of luck! (and if you're not already working with UMI-tagged reads,
please talk to the people in #2 above; the reason most people won't go
below 5% VAF is that you get thwacked by error rates at that level, and the
reason most NGS-based MRD is based on UMIs is that existing PCR-based
methods have 6 logs sensitivity.)
--t
On Thu, Mar 5, 2020 at 4:08 PM Mulder, R wrote:
> Hi,
>
>
> I was wondering if anyone could help me with a script and support for the
> above mentioned goal.
>
> For this I have several BAM files for which I want to determine de
> nucleotide count per region of interest. The latter could be several
> hotspot mutation sites. I would like to get an overall overview of all the
> BAM files. Next I want to use these counts to determine for any new BAM
> file if the count for a particular genomic position is higher than the
> allowable range, hence could indicate if a mutation is present. For this I
> would like to use the modified Thompson Tau test. I think machine learning
> could be used for this. So, why do I want to do all this? Well, normal NGS
> pipelines only deal with variants at a frequency of 5%. Mutatios below this
> frequency are often missed. To know if a mutation is present below this
> level, you showed dive into the alignment and most often manually
> investigate the base calls. I know that this races some questions regarding
> call qualities, but then again our conventional assays have actually
> confirmed some of these low mutations. In addition, NGS can
> be used to determine the presence of low frequent mutation which is of
> great importance for determining the measurable residual disease after
> treatment.
>
>
> I am new to r and bioconductor so I would be very thankful if someone
> could help me in my mission to setting up a script for this purpose.
>
>
> Thanks,
>
>
> Rene Mulder
>
> Laboratory Medicine
>
> University Medical Center Groningen
>
> The Netherlands
>
>
> De inhoud van dit bericht is vertrouwelijk en alleen bes...{{dropped:15}}
>
> ___
> 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
[Bioc-devel] MRD measurements in Leukemic patients using NGS data in r
Hi,
I was wondering if anyone could help me with a script and support for the above
mentioned goal.
For this I have several BAM files for which I want to determine de nucleotide
count per region of interest. The latter could be several hotspot mutation
sites. I would like to get an overall overview of all the BAM files. Next I
want to use these counts to determine for any new BAM file if the count for a
particular genomic position is higher than the allowable range, hence could
indicate if a mutation is present. For this I would like to use the modified
Thompson Tau test. I think machine learning could be used for this. So, why do
I want to do all this? Well, normal NGS pipelines only deal with variants at a
frequency of 5%. Mutatios below this frequency are often missed. To know if a
mutation is present below this level, you showed dive into the alignment and
most often manually investigate the base calls. I know that this races some
questions regarding call qualities, but then again our conventional assays have
actually confirmed some of these low mutations. In addition, NGS can
be used to determine the presence of low frequent mutation which is of great
importance for determining the measurable residual disease after treatment.
I am new to r and bioconductor so I would be very thankful if someone could
help me in my mission to setting up a script for this purpose.
Thanks,
Rene Mulder
Laboratory Medicine
University Medical Center Groningen
The Netherlands
De inhoud van dit bericht is vertrouwelijk en alleen bes...{{dropped:15}}
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Rd] survival bug? - solved
I _think_ the relevant section of the C standard is 6.5.6 Additive Operators
Par 8, excerpted here:
> If both the pointer operand and the result point to elements
> of the same array object, or one past the last element of the
> array object, the evaluation shall not produce an overflow;
> otherwise, **the behavior is undefined**.
This is from the [C11 draft][1], though I imagine has been part of the standard
for a while. So by doing id[-1], in this case the pointer operand is id, and
the result is one element _before_ the array object, thus undefined behavior
which is bad news.
I'm not an expert in these matters though.
[1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
On Thursday, March 5, 2020, 11:39:38 AM EST, Therneau, Terry M., Ph.D. via
R-devel wrote:
I ended up finding the issue by a focused code review.
Once in the past, I had a version that would fail under one architecture but
not another,
in that case some help from Brian Ripley pointed me to the offending line of C
code.
That line read, but did not write, at an invalid memory location. Starting
with the
question of "what C routines have I added or modified most recently" along with
where the
fault appeared to occur in my test suite, I started reading C code and found
one.
Revised code passes tests on the winbuilder site.
For the curious, I had a line asking "is this patient id different than the
last patient
id" in the C routine underneath survcheck(); I'm making sure that patients
don't go
backwards in time. Essentially
for (i=0; i< n; i) {
if (id[i] != id[i-1] ) { ...}
It is still a surprise to me that just LOOKING at this out of range element
would cause a
failure, [i-1] never appears on the left hand side of any expressions in the
... chunk
above. Nevertheless, it was an error. Que sera sera
A strong thanks to those who gave solid suggestions for bringing up a local
copy of Windows.
Terry T
>>> My latest submission of survival3.1-10 to CRAN fails a check, but only on
>>> windows, which
>>> I don't use.
>>> How do I track this down?
>>> The test in question works fine on my Linux box.
>>>
>>> Terry
>>>
>>>
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
[[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
Re: [Rd] survival bug? - solved
I ended up finding the issue by a focused code review.
Once in the past, I had a version that would fail under one architecture but
not another,
in that case some help from Brian Ripley pointed me to the offending line of C
code.
That line read, but did not write, at an invalid memory location. Starting
with the
question of "what C routines have I added or modified most recently" along with
where the
fault appeared to occur in my test suite, I started reading C code and found
one.
Revised code passes tests on the winbuilder site.
For the curious, I had a line asking "is this patient id different than the
last patient
id" in the C routine underneath survcheck(); I'm making sure that patients
don't go
backwards in time. Essentially
for (i=0; i< n; i) {
if (id[i] != id[i-1] ) { ...}
It is still a surprise to me that just LOOKING at this out of range element
would cause a
failure, [i-1] never appears on the left hand side of any expressions in the
... chunk
above. Nevertheless, it was an error. Que sera sera
A strong thanks to those who gave solid suggestions for bringing up a local
copy of Windows.
Terry T
>>> My latest submission of survival3.1-10 to CRAN fails a check, but only on
>>> windows, which
>>> I don't use.
>>> How do I track this down?
>>> The test in question works fine on my Linux box.
>>>
>>> Terry
>>>
>>>
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] [FORGED] Re: Help on Windows CRAN Check
This is something that, by the way, I've always thought R got backwards. If
you want an operation to handle "one thing" against "one other thing"
(scalars), a single & or | seems like the obvious symbol for it. Whereas an
operation on "multiple things" (vectors) would be well-represented by a
multiple-character symbol like && or ||.
But as long as I remember that it's backwards, I can keep them sorted out.
:-)
- Jeff
On Thu, Mar 5, 2020 at 6:14 AM Uwe Ligges
wrote:
>
>
> On 05.03.2020 09:45, Rolf Turner wrote:
> >
> > On 5/03/20 9:04 pm, Tomas Kalibera wrote:
> >
> >> On 3/5/20 4:26 AM, John Lawson wrote:
> >>> I see this error on the CRAN Check report
> >
> >
> >
> >>> Fatal error: the condition has length > 1
> >>
> >> The problem is that the condition t1 == "I" & t2 == "(" of the if
> >> statement in the code is not a scalar. Even though this has been allowed
> >> in R historically, the first element has been used, it is almost always
> >> a sign of coding error, so it is going to become a runtime error.
> >>
> >> So what one should do is fix the code to only use scalar conditions -
> >> ensure t1, t2 are scalar, replace & by &&.
> >
> > Perhaps I'm being even thicker than usual (imagine that!)
>
> Oh dear, but this time it is true...:
>
>
> > but I don't
> > grok that last recommendation: "replace & by &&". It's usually
> > harmless but indicates a lack of understanding. The "&&" operator
> > evaluates the second condition only if the first condition is TRUE. It
>
> Right, and as the conditions are scalar, we never have to evaluate the
> 2nd if the first is FALSE unless you do it for side effects.
>
> So for logical operators on scalar logical vectors, one should prefer &&
> and || for efficeincy reasons.
>
> Best,
> Uwe
>
>
>
>
> > is useful (only) in setting where the second condition is meaningful
> > only when the first condition is TRUE.
> >
> > Things like:
> >
> > if(!is.null(x) && x > 0)
> >
> > If "x" were null then the second condition would cause an error to be
> > thrown if you used "&" rather than "&&".
> >
> > In all (???) situations where "&&" works, then "&" works as well.
> > However it's a Good Idea to use the language as intended.
> >
> > It I'm missing some point here, please enlighten me.
> >
> >
> >
> > cheers,
> >
> > Rolf
> >
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[Rd] rounding change
This is a small heads up for package maintainers. Under the more recent R-devel, R CMD check turned up some changes in the *.out files. The simple demonstration is to type "round(51/80, 3)", which gives .638 under the old and .637 under the new. (One of my coxph test cases has a concordance of exactly 51/80). In this particular case 51/80 is exactly .6375, but that value does not have an exact representation in base 2. The line below would argue that the new version is correct, at least with respect to the internal representation. > print(51/80, digits = 20) [1] 0.63745559 This is not a bug or problem, it just means that whichever version I put into my survival/tests/book6.Rout.save file, one of R-devel or R-current will flag an issue. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] [FORGED] Re: Help on Windows CRAN Check
On 05.03.2020 09:45, Rolf Turner wrote:
On 5/03/20 9:04 pm, Tomas Kalibera wrote:
On 3/5/20 4:26 AM, John Lawson wrote:
I see this error on the CRAN Check report
Fatal error: the condition has length > 1
The problem is that the condition t1 == "I" & t2 == "(" of the if
statement in the code is not a scalar. Even though this has been allowed
in R historically, the first element has been used, it is almost always
a sign of coding error, so it is going to become a runtime error.
So what one should do is fix the code to only use scalar conditions -
ensure t1, t2 are scalar, replace & by &&.
Perhaps I'm being even thicker than usual (imagine that!)
Oh dear, but this time it is true...:
but I don't
grok that last recommendation: "replace & by &&". It's usually
harmless but indicates a lack of understanding. The "&&" operator
evaluates the second condition only if the first condition is TRUE. It
Right, and as the conditions are scalar, we never have to evaluate the
2nd if the first is FALSE unless you do it for side effects.
So for logical operators on scalar logical vectors, one should prefer &&
and || for efficeincy reasons.
Best,
Uwe
is useful (only) in setting where the second condition is meaningful
only when the first condition is TRUE.
Things like:
if(!is.null(x) && x > 0)
If "x" were null then the second condition would cause an error to be
thrown if you used "&" rather than "&&".
In all (???) situations where "&&" works, then "&" works as well.
However it's a Good Idea to use the language as intended.
It I'm missing some point here, please enlighten me.
cheers,
Rolf
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [FORGED] Re: Help on Windows CRAN Check
On 3/5/20 9:45 AM, Rolf Turner wrote:
On 5/03/20 9:04 pm, Tomas Kalibera wrote:
On 3/5/20 4:26 AM, John Lawson wrote:
I see this error on the CRAN Check report
Fatal error: the condition has length > 1
The problem is that the condition t1 == "I" & t2 == "(" of the if
statement in the code is not a scalar. Even though this has been allowed
in R historically, the first element has been used, it is almost always
a sign of coding error, so it is going to become a runtime error.
So what one should do is fix the code to only use scalar conditions -
ensure t1, t2 are scalar, replace & by &&.
Perhaps I'm being even thicker than usual (imagine that!) but I don't
grok that last recommendation: "replace & by &&". It's usually
harmless but indicates a lack of understanding. The "&&" operator
evaluates the second condition only if the first condition is TRUE.
It is useful (only) in setting where the second condition is
meaningful only when the first condition is TRUE.
Things like:
if(!is.null(x) && x > 0)
If "x" were null then the second condition would cause an error to be
thrown if you used "&" rather than "&&".
In all (???) situations where "&&" works, then "&" works as well.
However it's a Good Idea to use the language as intended.
&& has short-circuit evaluation but also is intended for scalars. This
is reflected by that non-scalar arguments lead to a runtime error with
_R_CHECK_LENGTH_1_LOGIC2_=TRUE.
I use && in the code to indicate that I expect a scalar, and I want the
short-circuit evaluation for scalars as I am used to if from other
programming languages. I only use & when want element-wise operation on
vectors, when & is for computation (e.g. of indices).
Best
Tomas
It I'm missing some point here, please enlighten me.
cheers,
Rolf
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [FORGED] Re: Help on Windows CRAN Check
It's not about god imposing style:). Consider this variant of your example:
>flag <- !is.null(x) && x > 0
With the strict checking this will throw error when you run it (good). If you
replace && with & and x is a vector, flag will silently become a vector and the
error be masked or delayed and pop up far away.
Georgi Boshnakov
-Original Message-
From: R-package-devel On Behalf Of Rolf
Turner
Sent: 05 March 2020 08:46
To: Tomas Kalibera
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] [FORGED] Re: Help on Windows CRAN Check
On 5/03/20 9:04 pm, Tomas Kalibera wrote:
> On 3/5/20 4:26 AM, John Lawson wrote:
>> I see this error on the CRAN Check report
>> Fatal error: the condition has length > 1
>
> The problem is that the condition t1 == "I" & t2 == "(" of the if
> statement in the code is not a scalar. Even though this has been
> allowed in R historically, the first element has been used, it is
> almost always a sign of coding error, so it is going to become a runtime
> error.
>
> So what one should do is fix the code to only use scalar conditions -
> ensure t1, t2 are scalar, replace & by &&.
Perhaps I'm being even thicker than usual (imagine that!) but I don't grok that
last recommendation: "replace & by &&". It's usually harmless but indicates a
lack of understanding. The "&&" operator evaluates the second condition only
if the first condition is TRUE. It is useful (only) in setting where the
second condition is meaningful only when the first condition is TRUE.
Things like:
if(!is.null(x) && x > 0)
If "x" were null then the second condition would cause an error to be thrown
if you used "&" rather than "&&".
In all (???) situations where "&&" works, then "&" works as well.
However it's a Good Idea to use the language as intended.
It I'm missing some point here, please enlighten me.
cheers,
Rolf
--
Honorary Research Fellow
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [FORGED] Re: Help on Windows CRAN Check
On 5/03/20 9:04 pm, Tomas Kalibera wrote:
On 3/5/20 4:26 AM, John Lawson wrote:
I see this error on the CRAN Check report
Fatal error: the condition has length > 1
The problem is that the condition t1 == "I" & t2 == "(" of the if
statement in the code is not a scalar. Even though this has been allowed
in R historically, the first element has been used, it is almost always
a sign of coding error, so it is going to become a runtime error.
So what one should do is fix the code to only use scalar conditions -
ensure t1, t2 are scalar, replace & by &&.
Perhaps I'm being even thicker than usual (imagine that!) but I don't
grok that last recommendation: "replace & by &&". It's usually
harmless but indicates a lack of understanding. The "&&" operator
evaluates the second condition only if the first condition is TRUE. It
is useful (only) in setting where the second condition is meaningful
only when the first condition is TRUE.
Things like:
if(!is.null(x) && x > 0)
If "x" were null then the second condition would cause an error to be
thrown if you used "&" rather than "&&".
In all (???) situations where "&&" works, then "&" works as well.
However it's a Good Idea to use the language as intended.
It I'm missing some point here, please enlighten me.
cheers,
Rolf
--
Honorary Research Fellow
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Help on Windows CRAN Check
On 3/5/20 4:26 AM, John Lawson wrote:
> I see this error on the CRAN Check report
>
>> ### ** Examples
>>
>> #Definitive Screening Design
>> library(daewr)
>> set.seed(1234)
>> x <- DefScreen(m=5,c=0)
>> colnames(x) <- paste("x",1:5,sep="")
>> x$y <- 3*x$x1 + 2*x$x2 + 2*x$x4*x$x5 + x$x3^2 + 2*x$x1^2 + rnorm(nrow(x),0,1)
>> (z <- HierAFS(x$y,x[,-6],m=5,c=0,step=4,nm1=FALSE ))
> --- FAILURE REPORT --
> --- failure: the condition has length > 1 ---
> --- srcref ---
> :
> --- package (from environment) ---
> daewr
> --- call from context ---
> ihstep(y, x, m, c)
> --- call from argument ---
> if (t1 == "I" & t2 == "(") {
> iquad = TRUE
> }
> --- R stacktrace ---
> where 1: ihstep(y, x, m, c)
> where 2: eval(expr, pf)
> where 3: eval(expr, pf)
> where 4: withVisible(eval(expr, pf))
> where 5: evalVis(expr)
> where 6: capture.output(res <- ihstep(y, x, m, c))
> where 7: withCallingHandlers(expr, warning = function(w)
> invokeRestart("muffleWarning"))
> where 8: suppressWarnings(invisible(capture.output(res <- ihstep(y, x,
> m, c
> where 9: HierAFS(x$y, x[, -6], m = 5, c = 0, step = 4, nm1 = FALSE)
>
> --- value of length: 3 type: logical ---
> [1] FALSE FALSE FALSE
> --- function from context ---
> function (y, des, m, c)
> {
> lin <- colnames(des)
> values <- c("A", "B", "C", "D", "E", "F", "G", "H", "I",
> "J", "K", "L", "M", "N", "O", "P", "Q", "R", "S", "T",
> "U", "V", "W", "X", "Y", "Z")
> repl <- c("I(A^2)", "I(B^2)", "I(C^2)", "I(D^2)", "I(E^2)",
> "I(F^2)", "I(G^2)", "I(H^2)", "I(I^2)", "I(J^2)", "I(K^2)",
> "I(L^2)", "I(M^2)", "I(N^2)", "I(O^2)", "I(P^2)", "I(Q^2)",
> "I(R^2)", "I(S^2)", "I(T^2)", "I(U^2)", "I(V^2)", "I(W^2)",
> "I(X^2)", "I(Y^2)", "I(Z^2)")
> repl.tab <- cbind(values, repl)
> if (m == 0) {
> quad <- character()
> }
> else {
> indx <- rep(0, m)
> for (i in 1:m) {
> indx[i] <- match(lin[i], repl.tab[, 1], nomatch = 0)
> }
> quad <- rep("A", m)
> for (i in 1:m) {
> quad[i] <- lin[i]
> }
> quad[indx != 0] <- repl.tab[indx, 2]
> quad <- paste(quad, collapse = "+")
> }
> dat <- data.frame(y = y, des)
> lm1 <- lm(y ~ (.)^2, data = dat)
> mm <- model.matrix(lm1)
> fact <- colnames(mm)
> fact <- fact[-1]
> fact <- paste(fact, collapse = "+")
> mod <- paste(c(fact, quad), collapse = "+")
> lm2 <- lm(reformulate(termlabels = mod, response = "y"),
> data = dat)
> mm <- model.matrix(lm2)
> mm <- mm[, 2:ncol(mm)]
> trm <- firstm(y, mm)
> d1 <- data.frame(y = y, mm[, trm])
> t1 <- substr(trm, 1, 1)
> t2 <- substr(trm, 2, 2)
> t3 <- substr(trm, 3, 3)
> iquad = FALSE
> if (t1 == "I" & t2 == "(") {
> iquad = TRUE
> }
> hmt <- trm
> if (t2 == "") {
> nms <- names(d1)
> nms[2] <- hmt
> names(d1) <- nms
> }
> m1 <- lm(y ~ (.), data = d1)
> result <- summary(m1)
> print(result)
> return(trm)
> }
>
>
> --- function search by body ---
> Function ihstep in namespace daewr has this body.
> --- END OF FAILURE REPORT --
> Fatal error: the condition has length > 1
The problem is that the condition t1 == "I" & t2 == "(" of the if
statement in the code is not a scalar. Even though this has been allowed
in R historically, the first element has been used, it is almost always
a sign of coding error, so it is going to become a runtime error.
So what one should do is fix the code to only use scalar conditions -
ensure t1, t2 are scalar, replace & by &&.
You can enable these checks on your end using an environment variable
(more details are in R Internals, _R_CHECK_LENGTH_1_CONDITION_ and
related is _R_CHECK_LENGTH_1_LOGIC2_).|||
|
Best
Tomas
>
>
> However on my own computer or on Rforge
>
> I see this:
>
> * checking examples ... OK
> * DONE
>
> Status: OK
>
> -- R CMD check results daewr 1.1-9
>
> Duration: 1m 1.8s
>
> 0 errors v | 0 warnings v | 0 notes v
>
> R CMD check succeeded
>
>
> I am not sure what the error is or how to correct it. Any help would
> be greatly appreciated,
>
> John Lawson
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
