Re: [R-pkg-devel] Call internal R functions in C

2021-04-25 Thread Cai Li
Thanks Duncan! I was advised not to export those functions in the namespace and keep them as internals. In terms of this, could you advise what specific changes should I make to the C code so that I can evaluate them in a suitable environment? I tried something like

Re: [R-pkg-devel] Call internal R functions in C

2021-04-25 Thread Duncan Murdoch
On 25/04/2021 7:23 p.m., Cai Li wrote: Hello All, I'm developing a package with C code. My question may be naive: I have several internal R functions that need to be called by C, but I cannot get it to work or find a solution. It can work if I export those internal functions in namespace, but

[R-pkg-devel] Call internal R functions in C

2021-04-25 Thread Cai Li
Hello All, I'm developing a package with C code. My question may be naive: I have several internal R functions that need to be called by C, but I cannot get it to work or find a solution. It can work if I export those internal functions in namespace, but it fails if I just want to keep them as

Re: [R-pkg-devel] winUCRT failures

2021-04-25 Thread Hadley Wickham
Who is responsible for the winUCRT checks? Perhaps that person could provide us with a list of root causes behind the testthat failures, and we could look into resolving them. Hadley On Sun, Apr 25, 2021 at 7:50 AM Duncan Murdoch wrote: > > The current CRAN release of rgl fails on winUCRT

Re: [R-pkg-devel] winUCRT failures

2021-04-25 Thread Hadley Wickham
> One additional thought: > > If the testing package (i.e. testthat in this case) had been available > but other suggested packages were not, it would be worth running tests > with just testthat present: that might be why you called the decision > defensible. I'd agree with that. > > However,

Re: [R-pkg-devel] winUCRT failures

2021-04-25 Thread Duncan Murdoch
On 25/04/2021 12:56 p.m., Duncan Murdoch wrote: On 25/04/2021 12:46 p.m., Dirk Eddelbuettel wrote: ... It has long been true that the main test runners (RUnit, testthat, now also tinytest) are automagically included, which is a defensible (if undocumented) special rule. It's a bad rule.

Re: [R-pkg-devel] winUCRT failures

2021-04-25 Thread Duncan Murdoch
On 25/04/2021 12:46 p.m., Dirk Eddelbuettel wrote: On 25 April 2021 at 12:27, Duncan Murdoch wrote: | On 25/04/2021 11:35 a.m., Dirk Eddelbuettel wrote: | > I last wrote about that four years ago under the title "Suggests != Depends" | >

Re: [R-pkg-devel] winUCRT failures

2021-04-25 Thread Dirk Eddelbuettel
On 25 April 2021 at 11:46, Dirk Eddelbuettel wrote: | So yes, it is technically easy, and we could pool the resources. But nobody | is driving it so (as has been the case for years) nothing changes. Ever. Sorry, "nothing changes" is too harsh. We have in the last year or two gotten a new test

Re: [R-pkg-devel] winUCRT failures

2021-04-25 Thread Dirk Eddelbuettel
On 25 April 2021 at 12:27, Duncan Murdoch wrote: | On 25/04/2021 11:35 a.m., Dirk Eddelbuettel wrote: | > I last wrote about that four years ago under the title "Suggests != Depends" | > http://dirk.eddelbuettel.com/blog/2017/03/22#suggests_is_not_depends | > | > Of course, nothing changed. | >

Re: [R-pkg-devel] winUCRT failures

2021-04-25 Thread Duncan Murdoch
On 25/04/2021 11:35 a.m., Dirk Eddelbuettel wrote: On 25 April 2021 at 11:14, Duncan Murdoch wrote: | What I haven't tried to do is check any of them if *none* of the | suggested packages is available. Packages should still build and check | without ERRORs in this case, though I'd expect NOTEs

Re: [R-pkg-devel] Cannot reproduce errors of archived CRAN package

2021-04-25 Thread Will L
On reflection, I strongly suspect the errors come from the way I was using file modification time stamps to manage a user-side configuration file. {targets} was using a time stamp to decide whether it needs to read the file, but the precision of time stamps varies from system to system. I

Re: [R-pkg-devel] winUCRT failures

2021-04-25 Thread Dirk Eddelbuettel
On 25 April 2021 at 11:14, Duncan Murdoch wrote: | What I haven't tried to do is check any of them if *none* of the | suggested packages is available. Packages should still build and check | without ERRORs in this case, though I'd expect NOTEs and/or WARNINGs. | | This is an old issue: what

Re: [R-pkg-devel] winUCRT failures

2021-04-25 Thread Duncan Murdoch
On 25/04/2021 8:49 a.m., Duncan Murdoch wrote: The current CRAN release of rgl fails on winUCRT because of missing dependencies: 'htmlwidgets', 'htmltools', 'knitr', 'jsonlite', 'shiny', 'magrittr', 'crosstalk', 'manipulateWidget'. Tracing `htmlwidgets` shows it also fails because of missing

[R-pkg-devel] Cannot reproduce errors of archived CRAN package

2021-04-25 Thread Will L
All, I was just informed that the {targets} package was archived. Version 0.4-1 is still failing on macOS so it and tarchetypes have been > archived. > A recheck on my own Intel Mac today gives the same check ERRORs as > reported on the CRAN results page. > Do not submit again without

[R-pkg-devel] winUCRT failures

2021-04-25 Thread Duncan Murdoch
The current CRAN release of rgl fails on winUCRT because of missing dependencies: 'htmlwidgets', 'htmltools', 'knitr', 'jsonlite', 'shiny', 'magrittr', 'crosstalk', 'manipulateWidget'. Tracing `htmlwidgets` shows it also fails because of missing dependencies: 'htmltools', 'jsonlite', 'yaml'