date:20200903

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

2020-09-03 Thread William Dunlap

> 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  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
> > d...@shmonk.com
> >
> >
> >
> > On Thu, Sep 3, 2020 at 1:40 PM Gábor Csárdi  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  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
> >
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

2020-09-03 Thread Dan Zigmond

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 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
> > d...@shmonk.com
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
>
> __
> 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

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

2020-09-03 Thread Gábor Csárdi

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. you
need to create these vectors with `\u` escapes. For example the tick
in cli is created like this:
https://github.com/r-lib/cli/blob/e3ca34656f5bb82df63bfc1c741e75acc79b13d9/R/symbol.R#L27

When you print it (e.g. with something like
`cat(cli:::symbol_utf8$tick)`) the proper Unicode character is
printed, as long as the platform supports it. E.g. on macOS:

❯ cli:::symbol_utf8$tick
[1] "✔"

Gabor

On Thu, Sep 3, 2020 at 11:26 PM Dan Zigmond  wrote:
>
> 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
> d...@shmonk.com
>
>
>
> On Thu, Sep 3, 2020 at 2:56 PM William Dunlap  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  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
> > > > d...@shmonk.com
> > > >
> > > >
> > > >
> > > > On Thu, Sep 3, 2020 at 1:40 PM Gábor Csárdi 
> > 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  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.
> > > >>>
> > > >>>

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

2020-09-03 Thread Dan Zigmond

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  wrote:

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

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

2020-09-03 Thread Dan Zigmond

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
d...@shmonk.com



On Thu, Sep 3, 2020 at 2:56 PM William Dunlap  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  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
> > > d...@shmonk.com
> > >
> > >
> > >
> > > On Thu, Sep 3, 2020 at 1:40 PM Gábor Csárdi 
> 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  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
> > >
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

2020-09-03 Thread Gábor Csárdi

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

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

2020-09-03 Thread Ben Bolker


  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
d...@shmonk.com

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

2020-09-03 Thread Dan Zigmond

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 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
> > > d...@shmonk.com
> > >
> > >
> > >
> > > On Thu, Sep 3, 2020 at 1:40 PM Gábor Csárdi 
> 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  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
> > >
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>
>
> --
> Joshua Ulrich  |  about.me/joshuaulrich
> FOSS Trading  |  www.fosstrading.com
>
> __
> 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

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

2020-09-03 Thread Duncan Murdoch


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


You shouldn't be doing that.  Write a function that returns those 
results, and tell the user that if they store them in a global variable 
named "string_fixes" (or whatever), then your function will use their 
values instead of your own built in ones.  You should never write to the 
global environment, but you can read from it.


Duncan Murdoch


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



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

2020-09-03 Thread Joshua Ulrich

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 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
> > d...@shmonk.com
> >
> >
> >
> > On Thu, Sep 3, 2020 at 1:40 PM Gábor Csárdi  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  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
> >
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



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

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

2020-09-03 Thread Ben Bolker


 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
d...@shmonk.com



On Thu, Sep 3, 2020 at 1:40 PM Gábor Csárdi  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  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



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

2020-09-03 Thread Dan Zigmond

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
d...@shmonk.com



On Thu, Sep 3, 2020 at 1:40 PM Gábor Csárdi  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  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

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

2020-09-03 Thread Gábor Csárdi

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

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

2020-09-03 Thread Dan Zigmond

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

Re: [R-pkg-devel] Help with a note

2020-09-03 Thread Anirban

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
>
> 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:
> 'asymptoticMemoryUsage' 'asymptoticTimings'
>
>
> There are opening and closing brackets with the return statement to the
> functions already. The source code can be found here:
> asymptoticTimings:
> https://github.com/Anirban166/testComplexity/blob/master/R/asymptoticTimings.R
> asymptoticMemoryUsage:
> https://github.com/Anirban166/testComplexity/blob/master/R/asymptoticMemoryUsage.R
>
>
> The note seems trivial but I can't seem to get rid of it. Any help would
> be appreciated.
>
> Thanks,
> Anirban
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Help with a note

2020-09-03 Thread Max Turgeon

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 would be to use 
"stopifnot".

Best,


Max Turgeon
Assistant Professor
Department of Statistics
Department of Computer Science
University of Manitoba
maxturgeon.ca



From: R-package-devel  on behalf of 
Anirban 
Sent: Thursday, September 3, 2020 12:48 AM
To: r-package-devel@r-project.org 
Subject: [R-pkg-devel] Help with a note


Caution: This message was sent from outside the University of Manitoba.


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:
'asymptoticMemoryUsage' 'asymptoticTimings'


There are opening and closing brackets with the return statement to the
functions already. The source code can be found here:
asymptoticTimings:
https://github.com/Anirban166/testComplexity/blob/master/R/asymptoticTimings.R
asymptoticMemoryUsage:
https://github.com/Anirban166/testComplexity/blob/master/R/asymptoticMemoryUsage.R


The note seems trivial but I can't seem to get rid of it. Any help would be
appreciated.

Thanks,
Anirban

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

Re: [R-pkg-devel] Help with a note

2020-09-03 Thread Gábor Csárdi

`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

Gabor

On Thu, Sep 3, 2020 at 6:42 PM Anirban  wrote:
>
> 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:
> 'asymptoticMemoryUsage' 'asymptoticTimings'
>
>
> There are opening and closing brackets with the return statement to the
> functions already. The source code can be found here:
> asymptoticTimings:
> https://github.com/Anirban166/testComplexity/blob/master/R/asymptoticTimings.R
> asymptoticMemoryUsage:
> https://github.com/Anirban166/testComplexity/blob/master/R/asymptoticMemoryUsage.R
>
>
> The note seems trivial but I can't seem to get rid of it. Any help would be
> appreciated.
>
> Thanks,
> Anirban
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Help with a note

2020-09-03 Thread Anirban

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:
'asymptoticMemoryUsage' 'asymptoticTimings'


There are opening and closing brackets with the return statement to the
functions already. The source code can be found here:
asymptoticTimings:
https://github.com/Anirban166/testComplexity/blob/master/R/asymptoticTimings.R
asymptoticMemoryUsage:
https://github.com/Anirban166/testComplexity/blob/master/R/asymptoticMemoryUsage.R


The note seems trivial but I can't seem to get rid of it. Any help would be
appreciated.

Thanks,
Anirban

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Advice for solving ERRORs in Fedora reported on CRAN / zen4R package

2020-09-03 Thread Emmanuel Blondel (GMAIL)


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/eblondel/zen4R/commit/ff3c34a20b486e547bbc684a696cfe15eb8c37bd 



zen4R has been resubmitted and Fedora CRAN builds are fine now.

Emmanuel

Le 03/09/2020 à 00:39, Gábor Csárdi a écrit :

On Wed, Sep 2, 2020 at 11:11 PM Dirk Eddelbuettel  wrote:


On 2 September 2020 at 23:59, Emmanuel Blondel (GMAIL) wrote:

[...]

| Your advice in order to solve that would be much appreciated,

Life, as they say, "is too short" so you could just comment-out the test.

Indeed, it is probably best not to run this test on CRAN's machines.

It probably fails because CRAN's keyring package is built without the
OS's keyring library, at least on Fedora.

But really, ideally you would not access the OS keyring in test cases,
except when running on a CI, or on the developers' machines.

Gabor

[...]


__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [R-pkg-devel] Help with a note

Re: [R-pkg-devel] Help with a note

Re: [R-pkg-devel] Help with a note

[R-pkg-devel] Help with a note

Re: [R-pkg-devel] Advice for solving ERRORs in Fedora reported on CRAN / zen4R package

19 matches

Site Navigation

Mail list logo

Footer information