[R-pkg-devel] 'stringi' package on Windows
I've run into another issue re-submitting my package to CRAN: Flavor: r-devel-windows-ix86+x86_64 Check: package dependencies, Result: ERROR Package required but not available: 'stringi' Everything seems to run fine on the other platformd and I used the stringi package in the previous iteration of the package without issue, but it seems perhaps there is some issue with stringi under Windows right now? 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-pkg-devel] warning: binary constants are a C++14 feature or GCC extension
Hi, all. In re-submitting a package to CRAN, I'm getting the following
warnings in the Debian pre-test:
Found the following significant warnings:
sort.cpp:12:28: warning: binary constants are a C++14 feature or GCC extension
sort.cpp:12:43: warning: binary constants are a C++14 feature or GCC extension
I added some C++ code to speed up the package and the warnings refer to
this line of C++:
while ((s[p + length] & 0b1100) == 0b1000) {
The line has to do with parsing UTF-8 strings by figuring out how many
bytes are used in each character. Is the 0b... notation not allowed in
CRAN? I could substitute decimal constants, but that will be a bit more
obtuse. The other platforms seems to allow this; only the Debian check
failed.
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] visible binding for '<<-' assignment
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
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
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:
Re: [R-pkg-devel] visible binding for '<<-' assignment
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
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-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
d...@shmonk.com
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
