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
.
--------------------------
Dan Zigmond
d...@shmonk.com
On Thu, Sep 3, 2020 at 2:59 PM Gábor Csárdi <csardi.ga...@gmail.com> wrote:
> On Thu, Sep 3, 2020 at 10:25 PM Dan Zigmond <d...@shmonk.com> 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 the primary point of installing it.
>
> Well, if you want to put a cache in a package, then the way I showed
> you works well.
>
> Possibly more importantly, maybe I misunderstood something, but
> stringi::stri_unescape_unicode() is not doing anything or your
> character vectors, because they do not contain escaped characters:
>
> fixed <- stringi::stri_unescape_unicode(pali_alphabet)
> identical(pali_alphabet, fixed)
> #> TRUE
>
> Gabor
>
> > Is there any other solution?
> >
> > Dan
> >
> > .
> > --------------------------
> > Dan Zigmond
> > d...@shmonk.com
> >
> >
> >
> > On Thu, Sep 3, 2020 at 1:40 PM Gábor Csárdi <csardi.ga...@gmail.com>
> wrote:
> >>
> >> 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 <d...@shmonk.com> 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 code like to create and save the
> data in
> >> > global variables in one file:
> >> >
> >> > pali_vowels <-
> >> > c("a", "\u0101", "i", "\u012b", "u", "\u016b", "e", "o")
> >> > pali_consonants <-
> >> > c("k", "kh", "g", "gh", "\u1e45",
> >> > "c", "ch", "j", "jh", "\u00f1",
> >> > "\u1e6d", "\u1e6dh", "\u1e0d", "\u1e0dh", "\u1e47",
> >> > "t", "th", "d", "dh", "n",
> >> > "p", "ph", "b", "bh", "m",
> >> > "y", "r", "l", "v", "s", "h", "\u1e37", "\u1e43")
> >> > pali_alphabet <-c(pali_vowels, pali_consonants)
> >> > use_data(pali_alphabet, overwrite = TRUE)
> >> >
> >> > and then I try to export a function like this in another file:
> >> >
> >> > pali_string_fix <- function() {
> >> > pali_alphabet <<-
> >> > stringi::stri_unescape_unicode(pali_alphabet)
> >> > # Several more of these...
> >> > }
> >> >
> >> > The idea is that users can run pali_string_fix() once when they load
> the
> >> > package and then they won't need to deal with all the Unicode escape
> >> > sequences after that.
> >> >
> >> > However, this is getting rejected by the CRAN checks with the message:
> >> >
> >> > * checking R code for possible problems ... [4s] NOTE
> >> > pali_string_fix: no visible binding for '<<-' assignment to
> >> > 'pali_alphabet'
> >> >
> >> > I'm guessing this is because the data and the function are defined in
> >> > different files, so even though those globals are defined by my
> package,
> >> > that isn't obvious when the check is run on this code.
> >> >
> >> > Does anyone have advice for how to fix this?
> >> >
> >> > Dan
> >> >
> >> > .
> >> > -------------------------
> >> > Dan Zigmond
> >> > d...@shmonk.com
> >> >
> >> > [[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
