I'm having a problem please excuse the noise.
cheers,
Rolf Turner
--
Honorary Research Fellow
Department of Statistics
University of Auckland
Stats. Dep't. (secretaries) phone:
+64-9-373-7599 ext. 89622
Home phone: +64-9-480-4619
__
R
On 5 March 2021 at 21:07, Ben Bolker wrote:
|Thanks! Now I see this is in Writing R Extensions, should have
| looked more carefully ...
There is also a very good (and frequently linked-to) post by Kevin on SO
which lists the different ways in the C API of R, and the Rcpp wrapper which
aims
Thanks! Now I see this is in Writing R Extensions, should have
looked more carefully ...
On 3/5/21 9:00 PM, Andrew Simmons wrote:
Hello,
You probably want one of the following
ISNA TRUE for R's NA only
ISNAN TRUE for R's and IEEE's NaN
R_IsNaN TRUE for IEEE'S NaN only
On F
I would like to test for NaN inside C++ code that lives inside a CRAN
package.
Following the StackOverflow question linked below, I was using
#define isNAN(a) (a!=a)
which I *think* used to work, but at some point along the way it stopped
working due to compiler/flag changes. I'm thinking of
On Sun, Jan 31, 2021 at 6:52 PM Duncan Murdoch wrote:
>
> On 31/01/2021 12:35 p.m., Duncan Murdoch wrote:
> > On 31/01/2021 10:57 a.m., Gábor Csárdi wrote:
> >> Do you actually experience any problems, if you don't treat this case
> >> specially?
> >
> > Yes, what was happening was that remotes::
On 31/01/2021 12:35 p.m., Duncan Murdoch wrote:
On 31/01/2021 10:57 a.m., Gábor Csárdi wrote:
Do you actually experience any problems, if you don't treat this case specially?
Yes, what was happening was that remotes::install_deps skipped
installing rgl from CRAN because the local copy had a la
On 31/01/2021 10:57 a.m., Gábor Csárdi wrote:
Do you actually experience any problems, if you don't treat this case specially?
Yes, what was happening was that remotes::install_deps skipped
installing rgl from CRAN because the local copy had a later version
number. Sorry, I deleted most of t
Do you actually experience any problems, if you don't treat this case specially?
AFAIR, in most cases this is not a problem in practice. remotes might
install the CRAN version of rgl as the dependency of alphashape3d, but
`R CMD check` will install and use the local copy of the rgl package
for the
On Sun, Jan 31, 2021 at 4:32 AM Duncan Murdoch wrote:
>
> I am trying out a modified version of the tidyverse actions, and it does
> seem to be going well. Just one question:
>
> rgl has a soft dependency on alphashape3d, and alphashape3d has a hard
> dependency on rgl. This means that I need to
I am trying out a modified version of the tidyverse actions, and it does
seem to be going well. Just one question:
rgl has a soft dependency on alphashape3d, and alphashape3d has a hard
dependency on rgl. This means that I need to install in the order
rgl hard dependencies
rgl
rgl sof
On Thu, Jan 28, 2021 at 6:27 PM Henrik Bengtsson
wrote:
>
> Hi,
>
> you're probably already aware of it, but 'rgl' depends on 'magrittr'
> which depends on 'rlang', and the latter requires R (>= 3.3.0).
For the reference, we support R-release, R-devel, and the last four
versions of R:
https://www
Thanks, I'll try Singularity out. (I tried it, but got some weird game
playing when I tried to do my first build. Strange.)
By the way, I've been thinking of downgrading the magrittr dependency to
Suggests. The only reason it is currently Imports is so that rgl can
re-export the pipe operat
Hi,
you're probably already aware of it, but 'rgl' depends on 'magrittr'
which depends on 'rlang', and the latter requires R (>= 3.3.0).
BTW, I find Singularity (https://github.com/hpcng/singularity/) more
convenient to work with than Docker, e.g. you run as host $USER also
"inside" the containe
On 28 January 2021 at 16:50, Duncan Murdoch wrote:
| Thanks Dirk, Neal and Nathan. I ended up going with Dirk's suggestion.
|
| So far I haven't got it to work in 3.2.0; I probably won't put much
| effort into supporting that old version. But it's fine in 3.4.0 and
| 3.5.0, and I'm trying 3.
Thanks Dirk, Neal and Nathan. I ended up going with Dirk's suggestion.
So far I haven't got it to work in 3.2.0; I probably won't put much
effort into supporting that old version. But it's fine in 3.4.0 and
3.5.0, and I'm trying 3.3.0 now. Rocker rocks!
P.S. rgl now installs in the basic r
e-devel on behalf of
Duncan Murdoch
Sent: Friday, January 29, 2021 1:35:40 AM
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] Testing on old R versions
I just received a bug report about the rgl package: it claims to depend
on R >= 3.2.0, but actually uses the hcl.colors() fun
The Rocker Project provides both rocker/r-ver (with package snapshotting) as
well as the (much smaller, just R) rocker/r-base images which are then passed
on to the Docker team to become the official r-base image.
These go back to 3.1.3 with (almost if not all) interim releases, see
https://
I've used the https://hub.docker.com/r/rstudio/r-base images for this, and
they appear to go back to R 3.1. Likewise
https://hub.docker.com/r/rocker/r-ver. The latter uses MRAN to install
packages from a CRAN snapshot corresponding to the release, so that should
also help with dependencies.
Neal
I just received a bug report about the rgl package: it claims to depend
on R >= 3.2.0, but actually uses the hcl.colors() function that was
introduced in R 3.6.0, so fails to install. (This dependence was
introduced while I had the dependence stated as R >= 4.0.0 for a while,
until I tried to
Thanks for the suggestion. But it may not be quite expressive enough; I
think I will instead use
> ifelse(getRversion() < "3.6.0",
> ! canCoerce(wv, "double"), # fails in older versions
> canCoerce(wv, "double")) # works in newer versions
That way, when I update the p
Hi Kevin,
I think using
> canCoerce(wv, "double") || getRversion() < "3.6.0"
could solve the issue of an inconsistent test result and is descriptive.
Best regards,
Sebastian
Am 06.12.18 um 16:59 schrieb Kevin Coombes:
> Hi,
>
> A package I recently submitted to CRAN includes an S4
Hi,
A package I recently submitted to CRAN includes an S4 class that defines a
method to coerce from that class to a numeric vector, basically through
> setAs("myClass", "numeric", function(from) from@psi)
Being perhaps overly compulsive about trying to test everything while
documenting behavi
On 02/12/2017 2:19 PM, Bill Denney wrote:
On Dec 2, 2017, at 09:43, Duncan Murdoch wrote:
I don't think there's anything better than Bill's solution, though I imagine it is
possible to ask for translation of the message. For example, sqrt(-1) currently gives a
warning with English message
> On Dec 2, 2017, at 09:43, Duncan Murdoch wrote:
>
> I don't think there's anything better than Bill's solution, though I imagine
> it is possible to ask for translation of the message. For example, sqrt(-1)
> currently gives a warning with English message "NaNs produced".
Another idea just
On 02/12/2017 9:23 AM, Dirk Eddelbuettel wrote:
On 2 December 2017 at 08:38, Bill Denney wrote:
| Hi,
|
| I got a message last night that some of the tests in the PKNCA package do not follow
best practices. ("Do not test the exact format of R messages (from R itself or from
other packages): T
For the translation part, you can test the received error message against
the translated message. You can get the translated version from the
original one using gettext("").
This should be agile to user's language settings but, of course, not to
changes that the developer does to the the error mes
On 2 December 2017 at 08:38, Bill Denney wrote:
| Hi,
|
| I got a message last night that some of the tests in the PKNCA package do not
follow best practices. ("Do not test the exact format of R messages (from R
itself or from other packages): They change, and they can be translated.")
Speci
Hi,
I got a message last night that some of the tests in the PKNCA package do not
follow best practices. ("Do not test the exact format of R messages (from R
itself or from other packages): They change, and they can be translated.")
Specifically, I test to ensure that an error is generated wh
28 matches
Mail list logo
