Re: [R-pkg-devel] problem with locale-dependent order()
Alex,
'with_collate' is one of the functions included in the withr package (
https://cran.rstudio.com/web/packages/withr/).
So you could simply write
sort_c <- function(x) withr::with_collate("C", sort(x))
The usage semantics and implementation are essentially identical to what
Hadley described.
Jim
On Sun, Sep 20, 2015 at 1:22 PM, Hadley Wickham wrote:
> Hi Alex,
>
> As far as I know, that's the best solution. In roxygen, I've wrapped
> it up with a couple of helpers:
>
> set_collate <- function(locale) {
> cur <- Sys.getlocale(category = "LC_COLLATE")
> Sys.setlocale(category = "LC_COLLATE", locale = locale)
> cur
> }
>
> with_collate <- function(locale, code) {
> old <- set_collate(locale)
> on.exit(set_collate(old))
>
> force(code)
> }
>
> sort_c <- function(x) with_collate("C", sort(x))
>
> Hadley
>
> On Fri, Sep 18, 2015 at 4:25 PM, Alex Deckmyn
> wrote:
> > Hi,
> >
> > For an update of the maps package, I have run into a bug caused by the
> locale-depent behaviour of order().
> > In a certain function, the polygon names of the world map are lexically
> sorted with order() prior to being sent to a C routine. That routine
> expects them to be sorted according to ASCII rules, but that is not the
> result I get. The main culprit is the colon used to identify sub-regions.
> For instance, in my locale (en_GB_UTF-8), I get
> >
> > "uk:northen ireland" < "ukrain" < "uk:scotland"
> >
> > which is not the order expected by C. I guess some language settings
> would also cause other unexpected results.
> >
> > Apart from the pain of fixing uk/ukrain ambiguities, is there a safe way
> to fix this order() in a package? An obvious solution seems to be
> >
> > lcc <- Sys.getlocale("LC_COLLATE")
> > Sys.setlocale("LC_COLLATE","C")
> > ord.nam <- order(nam)
> > Sys.setlocale("LC_COLLATE",lcc)
> >
> > This seems to work fine on my linux PC, but I am not sure about other
> platforms (Windows, OS-X...), though the "C" locale should be standard. Is
> this safe? Or is there a better way to get the right ordering?
> >
> > Alex
> >
> > ---
> > Dr. Alex Deckmyn e-mail: alex.deck...@meteo.be
> > Royal Meteorological Institute http://www.meteo.be
> > Ringlaan 3, 1180 Ukkel, Belgium tel. (32)(2)3730646
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>
>
> --
> http://had.co.nz/
>
> __
> 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] [Learning] the secret of Win[dows C-backed packages]
It has been a few months since I was doing this for the 4.9.3 windows toolchain, but the best way I found IIRC of getting everything working was to install msys2 and use that as the build environment, but put the proper Rtools toolchain first in the PATH. On Mon, Aug 15, 2016 at 9:13 AM, Hadley Wickham wrote: > One other option is to include the src for libmagic inside your > package, and use that as a fallback if it's not installed on the > system. That gives linux users what they want (linking to the system > package), and windows users what they want (it just works). It only > works for simple libraries, but it looks like libmagic might qualify. > > I could have sworn I did that in a package, but I can't remember which one > :( > > Hadley > > On Sat, Aug 13, 2016 at 11:34 AM, Bob Rudis wrote: > > Hey folks, > > > > I usually stare in awe at the C-backed packages that rely on eternal > > libraries which are super-easy to get working on macOS & *nix _but_ that > > also work perfectly on Windows. I fire up Windows (*maybe*) once a month > to > > test some of my packages but I'm curious as to what I need to do to > setup a > > more extended toolchain to create libraries such as are found in > > https://github.com/rwinlib. > > > > Jeroen (I think others, too) seem to effortlessly package those up and I > > fully grok his "anticonf" setup and the 32-bit & 64-bit Windows library > > setup. I just can't seem to actually do the building. > > > > Why I'm asking what I'm asking (below) is that I'm working on something > for > > the $DAYJOB now - https://github.com/hrbrmstr/wand - that requires > libmagic > > and I kinda, unfortunately, actually need it to also work on Windows (it > > usually doesn't matter, but this time some folks who use Windows systems > at > > work need to use this forthcoming package). > > > > Rather than b[eu]g Jeroen or others for library building/packaging, I'd > be > > very, keenly interested in learning what else besides Rtools I need to > > install to be able to make similar binary bundles to include during > > installation (and to have my compiled pkgs work on Windows). > > > > My disdain for Windows and my frustration with the super-limited > toolchain > > components installed with Rtools is probably contributing to my inability > > to solve this on my own (no bash.exe...rly?). I used to use cygwin back > in > > the day but there are so many cautions in the main R docs abt compatible > > versions that I'd rather not spend hours or days figuring out something > > that others already have. > > > > One example here is that I actually managed to get one of the libmagic > > support packages (the regex library) built and installed on Windows (in > the > > toolchain /usr/local) but can't get libmagic's `configure` script to > > find/use it. > > > > I'm more than willing to write up any copious pointers folks provide > into a > > detailed, attributed blog post or R Journal article since this is > seriously > > the only bit holding me back from working on and releasing a ton of other > > compilation-required packages to CRAN. I also know I'm not the only one > who > > gets stalled when trying to get similar things (especially those with > full > > Boost dependencies) to work on Windows. > > > > thx, > > > > -Bob > > > > [[alternative HTML version deleted]] > > > > __ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > > > -- > http://hadley.nz > > __ > 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] Depending on currently unreleased package
You can use the `Remotes: ` feature in your DESCRIPTION file
(https://github.com/hadley/devtools/blob/master/vignettes/dependencies.Rmd)
implemented in devtools to automatically install development versions
of packages during development, including on Travis CI. However they
will need to be removed before submitting to CRAN, in which case a
conditional include like Duncan described is what you will need to do
until dbplyr is released on CRAN.
On Tue, May 9, 2017 at 7:54 PM, William Brannon wrote:
> Thanks! That took care of it. I had been tripped up by how the R support in
> travis-ci throws errors if suggested packages aren't available.
>
> On May 6, 2017 4:18 PM, "Duncan Murdoch" wrote:
>
>> On 06/05/2017 4:02 PM, William Brannon wrote:
>>
>>> Hi r-devel,
>>>
>>> I have a package called sqlscore (
>>> https://cran.r-project.org/package=sqlscore) which depends on dplyr
>>> functions for SQL generation. The new version of dplyr splits these
>>> functions into a different package (dbplyr) and provides a recommended way
>>> to wrap around access to the function in the appropriate package. So when
>>> it's released in a few days, users with the new dplyr will see errors when
>>> trying to use sqlscore. So far, so good, though - updating my R code as
>>> such isn't hard.
>>>
>>> But dbplyr won't be released before the new dplyr is, and I can't figure
>>> out how to list it in Imports, Depends or even Suggests to release an
>>> update ahead of the new dplyr release. Doing so causes ERRORs in R CMD
>>> check about an unavailable dependency, and not doing so causes problems
>>> with "::" references to a package not mentioned in DESCRIPTION.
>>>
>>> I'd rather not wait until dbplyr is released to submit a new package, for
>>> obvious reasons. But releasing an update which depends on it before that
>>> might also cause breakage.
>>>
>>> Any suggestions for the right upgrade path?
>>>
>>>
>> You can list dbplyr in Suggests, and put in conditionals to test for it.
>> If you don't want to wait for its release you'll need to have code that
>> works without it as well, so something like this
>>
>> if (requireNamespace("dbplyr"))
>> foo <- dbplyr::foo
>> else if (packageVersion("dplyr") < "x.y.z")
>> foo <- dplyr::foo
>> else
>> stop("You need to install the dbplyr package, because dplyr::foo has
>> moved there.")
>>
>> will allow you to use foo() anywhere (as long as its interface is the same
>> in both packages, of course).
>>
>> Duncan Murdoch
>>
>
> [[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] Writing to files without altering working directory in R package
For what it's worth, the recommendation to use `tempfile()` is very
confusing to R users.
Often users (particularly new users) jump directly to examples when
reading documentation and when you have these more complicated
examples they do not realize they can just use a simple string
literal.
See https://github.com/tidyverse/readr/issues/635 for an issue where
multiple users explicitly request examples which do _not_ use
`tempfile()`.
On Fri, May 3, 2019 at 7:59 PM Duncan Murdoch wrote:
>
> On 03/05/2019 6:33 p.m., Jarrett Phillips wrote:
> > Hello,
> >
> > My R package has a function with an argument to specify whether numerical
> > results should be outputted to a CSV file.
> >
> > CRAN policy stipulates verbatim that
> >
> > Packages should not write in the user’s home filespace (including
> > clipboards), nor anywhere else on the file system apart from the R
> > session’s temporary directory (or during installation in the location
> > pointed to by TMPDIR: and such usage should be cleaned up). Installing into
> > the system’s R installation (e.g., scripts to its bin directory) is not
> > allowed.
> >
> > I know I should use tempdir() within my package function, but I've not seen
> > any examples on how this is best done within existing R packages.
> >
> > Within my package documentation examples for my function, I have the lines:
> >
> > \dontshow{.oldwd <- setwd(tempdir())}
> >
> > ... some R code ...
> >
> > \dontshow{setwd(.oldwd)}
> >
> > but I have been informed that this is not the accepted way.
> >
> > Any ideas from the community on how do do this properly?
>
> Use the tempfile() function to generate a filename in the temporary
> directory. You might want to use the "pattern" or "fileext" arguments,
> but don't change the "tmpdir" argument.
>
> Then write to that file.
>
> For example,
>
> filename <- tempfile(fileext = ".csv")
> write.csv(df, filename)
>
> It's a good idea to clean up afterwards using
>
> unlink(filename)
>
> __
> 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] CRAN student assistants
I agree that `message()` is in an ideally preferred, precisely because
of the reasons Martin stated, it is easily controlled by the user.
Unfortunately, in the real world, the windows R gui console and
RStudio (which copied behavior) color messages, and anything on stderr
in fact, in red, which confuses most users who are trained to treat
messages in red as errors.
This also makes using colored output (where available) more
challenging when using `message()`. You either have to accept the
text as red, or unconditionally change the text color to black or
similar, which can then be unreadable if the user is using a dark
color theme.
Jenny is an experienced package developer. She knew this tradeoff and
the use of `cat()` in gargle was deliberate choice in an imperfect
world. She did not make this decision out of ignorance of a better
way.
However there is no way for Jenny or any other package developers to
have a dialog during a CRAN submission, the communication is only in
one direction, if she resubmits explaining her rationale for the
choice she may not even have the same reviewer the next time.
Bioconductor seems to have a much better review process for
submissions, with real dialog between the reviewer and package author,
perhaps CRAN can learn from that process and improve the submission
experience in the future.
Jim
On Wed, May 15, 2019 at 7:41 AM Martin Morgan wrote:
>
> message() / warning() / stop() write to stderr whereas print() / cat() write
> (by default) to stdout. Even without being able to suppress messages, it is
> well-established practice (the story is that this is the reason why 'stderr'
> was introduced into unix,
> https://www.jstorimer.com/blogs/workingwithcode/7766119-when-to-use-stderr-instead-of-stdout
> ) to separate diagnostic messages from program output. I agree that gargle
> (in particular, and packages in general, given the theme of this mailing
> list) would be a better package if it used message() where it now uses cat().
>
> Martin
>
> On 5/15/19, 5:04 AM, "R-package-devel on behalf of Joris Meys"
>
> wrote:
>
> 2) Where cat() is used in gargle, message() is a better option for the
> following reason:
>
> > myfun <- function(){cat("Yes");message("No")}
> > suppressMessages(myfun())
> Yes
>
>
> __
> 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] CRAN student assistants
Sorry first sentence should read
I agree that `message()` is ideally preferred, precisely because
of the reasons Martin stated, it is easily controlled by the user.
On Wed, May 15, 2019 at 9:41 AM Jim Hester wrote:
>
> I agree that `message()` is in an ideally preferred, precisely because
> of the reasons Martin stated, it is easily controlled by the user.
>
> Unfortunately, in the real world, the windows R gui console and
> RStudio (which copied behavior) color messages, and anything on stderr
> in fact, in red, which confuses most users who are trained to treat
> messages in red as errors.
>
> This also makes using colored output (where available) more
> challenging when using `message()`. You either have to accept the
> text as red, or unconditionally change the text color to black or
> similar, which can then be unreadable if the user is using a dark
> color theme.
>
> Jenny is an experienced package developer. She knew this tradeoff and
> the use of `cat()` in gargle was deliberate choice in an imperfect
> world. She did not make this decision out of ignorance of a better
> way.
>
> However there is no way for Jenny or any other package developers to
> have a dialog during a CRAN submission, the communication is only in
> one direction, if she resubmits explaining her rationale for the
> choice she may not even have the same reviewer the next time.
>
> Bioconductor seems to have a much better review process for
> submissions, with real dialog between the reviewer and package author,
> perhaps CRAN can learn from that process and improve the submission
> experience in the future.
>
> Jim
>
> On Wed, May 15, 2019 at 7:41 AM Martin Morgan wrote:
> >
> > message() / warning() / stop() write to stderr whereas print() / cat()
> > write (by default) to stdout. Even without being able to suppress messages,
> > it is well-established practice (the story is that this is the reason why
> > 'stderr' was introduced into unix,
> > https://www.jstorimer.com/blogs/workingwithcode/7766119-when-to-use-stderr-instead-of-stdout
> > ) to separate diagnostic messages from program output. I agree that gargle
> > (in particular, and packages in general, given the theme of this mailing
> > list) would be a better package if it used message() where it now uses
> > cat().
> >
> > Martin
> >
> > On 5/15/19, 5:04 AM, "R-package-devel on behalf of Joris Meys"
> >
> > wrote:
> >
> > 2) Where cat() is used in gargle, message() is a better option for the
> > following reason:
> >
> > > myfun <- function(){cat("Yes");message("No")}
> > > suppressMessages(myfun())
> > Yes
> >
> >
> > __
> > 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] CRAN policies with regards to runnable examples
CRAN reviewers have somewhat recently been requesting that new
submissions have runnable examples. This is in general a good
recommendation, but the reviewers seem to apply this policy
unconditionally, and there are certain classes of packages where this
is either extremely cumbersome or impossible to do.
Two in particular are packages which wrap web APIs and packages
containing shiny applications. Even the most robust APIs will
inevitably have network failures, causing spurious failures on CRAN's
machines, and often the APIs require credentials to access, which
won't be available on the build machines. Shiny applications block the
R process and require user interaction in a browser to function, they
cannot really be run non-interactively.
In these cases it seems appropriate to put examples in a `\dontrun{}`
or `\donttest{}` block, and this is what is suggested by writing R
extensions. However CRAN reviewers have refused to accept packages
taking this approach.
If these workarounds are not acceptable what _does_ CRAN want package
authors to do in these cases?
Jim
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R_MAKEVARS_USER fail to pass down to sub-makes?
I think the issue is likely that you seem to be using a relative path to
the R_MAKEVARS_USER file, it needs to be an absolute path as the
installation is run in a temporary directory not from the directory you
call `R CMD INSTALL` from.
I observed similar behavior to what you describe when I had the
MAKEVARS_USER file as a relative path, but using an absolute path produced
the expected result.
On Mon, Jun 1, 2020 at 8:04 AM Jan Gorecki wrote:
> Hi package devel support,
>
> I am trying to use R_MAKEVARS_USER to customize build, rather than
> .R/Makevars. It is properly displayed from config CFLAGS but during
> package install it doesn't seem to work.
>
> In R-admin in "6.3.3 Customizing package compilation" there is:
>
> > Note that these mechanisms do not work with packages which fail to pass
> settings down to sub-makes, perhaps reading etc/Makeconf in makefiles in
> subdirectories.
>
> It seems that it applies to me. How should I debug that? to make this
> env var respected? Note that my pkg has src/Makevars to handle openmp
> switch nicely
> Thank you
>
> system("R_MAKEVARS_USER=library/gcc/O3/Makevars R CMD config CFLAGS")
> -O3
>
> system("R_MAKEVARS_USER=library/gcc/O3/Makevars R CMD INSTALL
> --library=library/gcc/O3 mypkg_1.0.0.tar.gz")
> * installing *source* package 'mypkg' ...
> ** using staged installation
> ** libs
> gcc -std=gnu99 -I"/usr/share/R/include" -DNDEBUG-fopenmp -fpic -g
> -O2 -fdebug-prefix-map=/build/r-base-V28x5H/r-base-3.6.3=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -g -c assign.c -o assign.o
>
> __
> 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] CRAN pre-test Windows machine seems to be in a bad state
In particular the magrittr package seems to be broken on the pre-test machine. I submitted a new version of the pkgload package on Friday, again on Tuesday and today (Wednesday). All passed fine on the Debian machine, but failed during installation on the Windows builder. The failure is due to a soft load time dependency on testthat, which itself has a hard dependency on magrittr. Because the magrittr installation is broken my package (pkgload) fails to install. e.g. * installing *source* package 'pkgload' ... ** using staged installation ** R ** inst ** byte-compile and prepare package for lazy loading ** help *** installing help indices ** building package indices ** testing if installed package can be loaded from temporary location *** arch - i386 Error: package or namespace load failed for 'pkgload': .onLoad failed in loadNamespace() for 'pkgload', details: call: loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), versionCheck = vI[[j]]) error: there is no package called 'magrittr' Error: loading failed Execution halted *** arch - x64 Error: package or namespace load failed for 'pkgload': .onLoad failed in loadNamespace() for 'pkgload', details: call: loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), versionCheck = vI[[j]]) error: there is no package called 'magrittr' Error: loading failed Execution halted ERROR: loading failed for 'i386', 'x64' * removing 'd:/RCompile/CRANincoming/R-devel/lib/pkgload' I am pretty confident there is nothing wrong in the pkgload package that is causing this. The checks pass fine on a local windows machine. Hopefully this will be cleared up by the CRAN maintainers soon. Jim [[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] R package check stuck on “checking use of S3 registration …”
I have recently been having this same issue and traced it to a hang when loading the tcltk package. The 'checking use of S3 registration' part of the check loads all the base and recommended packages and for some reason the tcltk package was hanging during loading on my machine (macOS 11.2.1). I would try to load tcltk and see if this is the case for you, if so removing and reinstalling XQuartz may fix the issue. On Thu, Feb 11, 2021 at 11:20 AM Evan Biederstedt < evan.biederst...@gmail.com> wrote: > Hi there > > Creating an R package here which I plan to upload to CRAN. Upon checking > the tarball created with `R CMD BUILD`, I try to use `R CMD CHECK` as > follows: > > ``` > R CMD CHECK my_package.tar.gz --as-cran > ``` > > This normally works smoothly. However, in this case, it is stuck on > `checking use of S3 registration` and has been there for several hours. > I've never experienced this before; here's the partial output I see: > > > ``` > ... > * checking package subdirectories ... OK > * checking R files for non-ASCII characters ... OK > * checking R files for syntax errors ... OK > * checking whether the package can be loaded ... OK > * checking whether the package can be loaded with stated dependencies ... > OK > * checking whether the package can be unloaded cleanly ... OK > * checking whether the namespace can be loaded with stated dependencies > ... OK > * checking whether the namespace can be unloaded cleanly ... OK > * checking use of S3 registration ... > ``` > > (1) What does `checking use of S3 registration` really mean? > > (2) More importantly, why could it be stuck here? How could I fix this > issue? > > Any insight or help greatly appreciated. Thanks! > > [[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
