[R-pkg-devel] visible binding for '<<-' assignment

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
djz at shmonk.com

        [[alternative HTML version deleted]]

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 <djz at 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
djz at shmonk.com

        [[alternative HTML version deleted]]

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?

      Dan

.
--------------------------
Dan Zigmond
djz at shmonk.com



On Thu, Sep 3, 2020 at 1:40 PM G?bor Cs?rdi <csardi.gabor at 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 <djz at 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
djz at shmonk.com

         [[alternative HTML version deleted]]

	[[alternative HTML version deleted]]

  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 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?

      Dan

.
--------------------------
Dan Zigmond
djz at shmonk.com



On Thu, Sep 3, 2020 at 1:40 PM G?bor Cs?rdi <csardi.gabor at 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 <djz at 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
djz at shmonk.com

         [[alternative HTML version deleted]]

      [[alternative HTML version deleted]]

Is there a reason that this slightly more explicit
version [assign(envir=.GlobalEnv)] wouldn't work?

  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 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?

      Dan

.
--------------------------
Dan Zigmond
djz at shmonk.com



On Thu, Sep 3, 2020 at 1:40 PM G?bor Cs?rdi <csardi.gabor at 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 <djz at 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
djz at shmonk.com

         [[alternative HTML version deleted]]

      [[alternative HTML version deleted]]

On Thu, Sep 3, 2020 at 4:36 PM Ben Bolker <bbolker at gmail.com> 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 cause R CMD check to throw a NOTE that you will
need to explain upon pkg submission to CRAN.

On 9/3/20 5: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 the primary point of installing it.

Is there any other solution?

      Dan

.
--------------------------
Dan Zigmond
djz at shmonk.com



On Thu, Sep 3, 2020 at 1:40 PM G?bor Cs?rdi <csardi.gabor at 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 <djz at 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
djz at shmonk.com

         [[alternative HTML version deleted]]

      [[alternative HTML version deleted]]

--
Joshua Ulrich  |  about.me/joshuaulrich
FOSS Trading  |  www.fosstrading.com

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
djz at shmonk.com

	[[alternative HTML version deleted]]

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 at 2:36 PM Ben Bolker <bbolker at gmail.com> 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)
}


On 9/3/20 5: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 the primary point of installing it.

Is there any other solution?

      Dan

.
--------------------------
Dan Zigmond
djz at shmonk.com



On Thu, Sep 3, 2020 at 1:40 PM G?bor Cs?rdi <csardi.gabor at 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 <djz at 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
djz at shmonk.com

         [[alternative HTML version deleted]]

      [[alternative HTML version deleted]]

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?

     Dan

.
--------------------------
Dan Zigmond
djz at shmonk.com



On Thu, Sep 3, 2020 at 1:40 PM G?bor Cs?rdi <csardi.gabor at 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 <djz at 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
djz at shmonk.com

        [[alternative HTML version deleted]]

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
djz at shmonk.com

	[[alternative HTML version deleted]]

On Thu, Sep 3, 2020 at 10:25 PM Dan Zigmond <djz at 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
djz at shmonk.com



On Thu, Sep 3, 2020 at 1:40 PM G?bor Cs?rdi <csardi.gabor at 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 <djz at 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
djz at shmonk.com

        [[alternative HTML version deleted]]

   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 read from a
binary-format file?

   Then, if you use LazyData: yes in the DESCRIPTION file (this may be
the default?), these should automatically be accessible to users when
the package is loaded?


On 9/3/20 4:31 PM, 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 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
djz at shmonk.com

      [[alternative HTML version deleted]]

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, pali_alphabet) will already exist when the user attaches the
package ? but is there a way I can tweak them after the package has been
loaded?

     Dan

.
--------------------------
Dan Zigmond
djz at shmonk.com



On Thu, Sep 3, 2020 at 2:56 PM William Dunlap <wdunlap at tibco.com> wrote:

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 at 2:36 PM Ben Bolker <bbolker at gmail.com> 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)
}


On 9/3/20 5: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 the primary point of installing it.

Is there any other solution?

      Dan

.
--------------------------
Dan Zigmond
djz at shmonk.com



On Thu, Sep 3, 2020 at 1:40 PM G?bor Cs?rdi <csardi.gabor at 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 <djz at 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
djz at shmonk.com

         [[alternative HTML version deleted]]

      [[alternative HTML version deleted]]

        [[alternative HTML version deleted]]