> 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
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.
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
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
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
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
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
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
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
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
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
14 matches
Mail list logo
