> Is there a reason that this slightly more explicit
> version [assign(envir=.GlobalEnv)] wouldn't work?
https://cran.r-project.org/web/packages/policies.html
- Packages should not modify the global environment (user’s workspace).
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Thu, Sep 3, 2020
That was where I started, but for some reason that triggered a WARNING
about these non-ASCII characters, which seemed worse. :-)
Dan
.
--
Dan Zigmond
d...@shmonk.com
On Thu, Sep 3, 2020 at 3:26 PM Ben Bolker wrote:
>OK, trying again.
>
>Would it work to s
You can include Unicode strings in a package, either as data, or just
as character vectors. Or character vectors returned by functions. Many
packages do that. E.g. cli:::symbol_utf8$tick is Unicode (not
exported, but it could be).
The only restriction is that the source file must be ASCII, i.e. yo
I chose a bad example. :-) Trust me that I have a bunch of strings with
escaped Unicode.
It seems the consensus is that I should not try to do what I'm trying to
do. I think instead I'll just document how users can fix the escaping if
they want to, since it's not very hard anyway.
Dan
.
---
I get that, but these variables are created by the package. It's a data
package so the whole point is to provide access to the data. I'm just
trying to provide an option to make the data more readable since I can't
include Unicode strings directly in the package. In other words, these
variables (eg
On Thu, Sep 3, 2020 at 10:25 PM Dan Zigmond wrote:
>
> Thanks, Gabor. I want these to be easily available to package users though –
> that's why they are in the package. So I would rather not "hide" them in a
> local environment. This is fundamentally a data package, so access to this
> data is
OK, trying again.
Would it work to save the unescaped versions in a .RData file as in
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Data-in-packages
? Presumably the problems with non-ASCII variables arise when they show
up in a text-format (e.g. .R) file, not when they are
Given that both trigger a NOTE, is there a reason to favor the assign
solution over just using <<-?
Dan
.
--
Dan Zigmond
d...@shmonk.com
On Thu, Sep 3, 2020 at 2:46 PM Joshua Ulrich
wrote:
> On Thu, Sep 3, 2020 at 4:36 PM Ben Bolker wrote:
> >
> > Is there a r
On 03/09/2020 4:31 p.m., Dan Zigmond wrote:
Hi, all. I am developing a package that includes some global variables.
Because these are non-ASCII, I have escaped them. But then because these
are difficult to read, I want to provide an easy way for users to unescape
all of them up front. Thus I have
On Thu, Sep 3, 2020 at 4:36 PM Ben Bolker wrote:
>
> Is there a reason that this slightly more explicit version wouldn't work?
>
> pali_string_fix <- function() {
> assign("pali_alphabet", stringi::stri_unescape_unicode(pali_alphabet),
> .GlobalEnv)
> }
>
Using assign will also
Is there a reason that this slightly more explicit version wouldn't work?
pali_string_fix <- function() {
assign("pali_alphabet", stringi::stri_unescape_unicode(pali_alphabet),
.GlobalEnv)
}
On 9/3/20 5:25 PM, Dan Zigmond wrote:
Thanks, Gabor. I want these to be easily availabl
Thanks, Gabor. I want these to be easily available to package users though
– that's why they are in the package. So I would rather not "hide" them in
a local environment. This is fundamentally a data package, so access to
this data is the primary point of installing it.
Is there any other solution
Store the cached data in an environment within the package:
pali_data <- new.env(parent = emptyenv())
pali_string_fix <- function() {
pali_data$alphabet <-
stringi::stri_unescape_unicode(pali_alphabet)
...
}
Gabor
On Thu, Sep 3, 2020 at 9:33 PM Dan Zigmond wrote:
>
> Hi, all. I am devel
Hi, all. I am developing a package that includes some global variables.
Because these are non-ASCII, I have escaped them. But then because these
are difficult to read, I want to provide an easy way for users to unescape
all of them up front. Thus I have code like to create and save the data in
glob
Thank you for the helpful replies! I got it now, I overlooked the return on
the ifelse() before.
Thanks a lot again!
- Anirban
On Thu, Sep 3, 2020, 11:18 AM Anirban wrote:
> Hi, I've one note in my package which I can't seem to resolve while
> submitting to CRAN:
>
> New submission
>
> Flavo
Hi Anirban,
I don't think the issue is coming from the return statement at the end of your
function. I think it's triggered by your "ifelse" statement, where you have
"return" as the expression to be run if the condition isn't met.
A more idiomatic way of achieving what you're trying to do woul
`return()` is a function in R, so `return` does nothing. You probably
want `return()`.
Here:
https://github.com/Anirban166/testComplexity/blob/c991c31e5250bcaf804c3ad781fbc126c6a17e57/R/asymptoticMemoryUsage.R#L22
https://github.com/Anirban166/testComplexity/blob/master/R/asymptoticTimings.R#L22
Hi, I've one note in my package which I can't seem to resolve while
submitting to CRAN:
New submission
Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
Check: R code for possible problems, Result: NOTE
Possibly missing '()' after 'return' in the following functions:
'a
Thanks both for your quick answers,
I've implemented a solution to avoid the keyring issue by handling
properly the error, and catch it properly in test-all.R (as a better
control to deactivate CI integration tests if Zenodo token is invalid -
which is the case on CRAN).
https://github.com/e
19 matches
Mail list logo
