Re: [R-pkg-devel] Solaris Support

[Tim Taylor]

No direct experience, so others may know more, but I'd have thought in the 
system requirements of DESCRIPTION. See for instance what duckdb does 
https://github.com/duckdb/duckdb/blob/master/tools/rpkg/DESCRIPTION


From: R-package-devel  on behalf of Reed 
A. Cartwright 
Sent: 23 August 2021 20:31
To: R Package Devel
Subject: [R-pkg-devel] Solaris Support

What is the proper way to indicate that a package submitted to CRAN
requires the gcc compiler on Solaris? I haven't been able to find any
information about how to indicate that in a way that the CRAN builders will
pick up on it.

--
Reed A. Cartwright, PhD
Associate Professor of Genomics, Evolution, and Bioinformatics
School of Life Sciences and The Biodesign Institute
Arizona State University
==
Address: The Biodesign Institute, PO Box 875301, Tempe, AZ 85287-5301 USA
Packages: The Biodesign Institute, 1001 S. McAllister Ave, Tempe, AZ
85287-5301 USA
Office: Biodesign B-220C, 1-480-965-9949
Website: http://cartwrig.ht/

[[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] Please install cmake on macOS builders

[Tim Taylor]

On 12/05/2023 08:47, Iñaki Ucar wrote:

El vie., 12 may. 2023 5:58, Simon Urbanek 
escribió:


I think it would be quite useful to have some community repository of code
snippets dealing with such situations. R-exts gives advice and pieces of
code which are useful, but they are not complete solutions and situations
like Dirk's example are not that uncommon. (E.g., I recall some of the
spatial packages copy/pasting code from each other for quote some time -
which works, but is error prone if changes need to be made).


This seems like a nice project for https://github.com/r-devel :)

Iñaki


I've also flagged in the #core-documentation channel of the R 
Contributors Slack (https://contributor.r-project.org/slack). It may (or 
may not) be something that they would like to look at during the 
upcoming R Project Sprint. I know Jeroen previously provided some 
guidance for rust (https://github.com/r-rust/faq) after a similar call 
from Simon last year. Centralising some of this community provided 
guidance under https://github.com/r-devel seems like it could be useful, 
especially when there is an offer of review from R-Core.


Tim




If one has to rely on a 3rd party library and one wants to fall back to
source compilation when it is not available, it is a quite complex task,
because one has to match the library's build system to R's and the package
build rules as well. There are many ways where this can go wrong - Dirk
mentioned some of them - and ideally not every package developer in that
situation should be going through the pain of learning all the details the
hard way.

Of course there are other packages as an example, but for someone not
familiar with the details it's hard to see which ones do it right, and
which ones don't - we don't always catch all the bad cases on CRAN.

I don't have a specific proposal, but if there was a GitHub repo or wiki
or something to try to distill the useful bits from existing packages, I'd
be happy to review it and give advice based on my experience from that
macOS binary maintenance if that's useful.

Cheers,
Simon



On May 12, 2023, at 8:36 AM, Dirk Eddelbuettel  wrote:


Hi Reed,

On 11 May 2023 at 11:15, Reed A. Cartwright wrote:
| I'm curious why you chose to call cmake from make instead of from

configure.

| I've always seen cmake as part of the configure step of package

building.

Great question! Couple of small answers: i) This started as a 'proof of
concept' that aimed to be small so getting by without requiring

`configure`

seemed worth a try, ii) I had seen another src/Makevars invoking

compilation

of a static library in a similar (albeit non-cmake) way and iii) as we

now

know about section 1.2.6 (or soon 1.2.9) 'Using cmake' has it that way

too.

Otherwise I quite like having `configure` and I frequently use it -- made
from 'genuine' configire.in via `autoconf`, or as scripts in shell or

other

languages.

Cheers, Dirk

PS My repaired package is now on CRAN. I managed to bungle the static

library

build (by not telling `cmake` to use position independent code), bungled
macOS but not telling myself where `cmake` could live, and in fixing that
bungled Windows by forgetting to add `src/Makevars.win` fallback. Yay me.

--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
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


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

Re: [R-pkg-devel] Warning 'as.data.frame.POSIXct()' is deprecated

[Tim Taylor]

This *may* be an issue in lapply.  Let's see what others day. Reprex below

Sys.setenv("_R_CHECK_AS_DATA_FRAME_EXPLICIT_METHOD_" = TRUE)
dat <- Sys.Date()
as.data.frame(dat)
#>  dat
#> 1 2023-07-06
lapply(dat, as.data.frame)
#> Warning: Direct call of 'as.data.frame.Date()' is deprecated.  Use
#> 'as.data.frame.vector()' or 'as.data.frame()' instead
#> [[1]]
#>   X[[i]]
#> 1 2023-07-06

Tim

On 06/07/2023 08:54, Vincent van Hees wrote:

Dear all,

I see the following warning in my package test results:

```
Warning
Direct call of 'as.data.frame.POSIXct()' is deprecated.  Use
'as.data.frame.vector()' or 'as.data.frame()' instead
```

The warning is not always there and I struggle to make it reproducible. I
have encountered it in both Ubuntu 22.04 and in Windows 11, in both R 4.3.0
and 4.3.1, in both RStudio and in an GitHub Actions environment (example
).
The warning gives the impression that I am doing something that R no longer
supports. However, I am not using the command as.data.frame.POSIXct()
anywhere directly in my code.

When I dive into the code where the warnings occur I see patterns like:

```
now = Sys.time()
df = data.frame (time = seq(now, now + 10, by =1),  B  = 1:11)
```

(this is a simplification of for example:
https://github.com/wadpac/GGIR/blob/master/tests/testthat/test_read.myacc.csv.R
)

Does this mean I am discouraged from putting a vector with POSIXct values
in a data.frame?
If yes, what would be the recommended work around?

I have been trying to find documentation or online discussions about this
warning but no luck so far. I see R NEWS
 mentions
updates to POSIXct related objects several times in the past year but those
seem to be different issues.

Best,

Vincent

[[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] Warning 'as.data.frame.POSIXct()' is deprecated

[Tim Taylor]

Apologies - I've not had enough caffeine just yet. The reprex below 
highlights the issue but I think the code which implemented the change 
*may* need tweaking not lapply.


Tim

On 06/07/2023 09:26, Tim Taylor wrote:
This *may* be an issue in lapply.  Let's see what others day. Reprex 
below


Sys.setenv("_R_CHECK_AS_DATA_FRAME_EXPLICIT_METHOD_" = TRUE)
dat <- Sys.Date()
as.data.frame(dat)
#>  dat
#> 1 2023-07-06
lapply(dat, as.data.frame)
#> Warning: Direct call of 'as.data.frame.Date()' is deprecated.  Use
#> 'as.data.frame.vector()' or 'as.data.frame()' instead
#> [[1]]
#>   X[[i]]
#> 1 2023-07-06

Tim

On 06/07/2023 08:54, Vincent van Hees wrote:

Dear all,

I see the following warning in my package test results:

```
Warning
Direct call of 'as.data.frame.POSIXct()' is deprecated.  Use
'as.data.frame.vector()' or 'as.data.frame()' instead
```

The warning is not always there and I struggle to make it 
reproducible. I
have encountered it in both Ubuntu 22.04 and in Windows 11, in both R 
4.3.0

and 4.3.1, in both RStudio and in an GitHub Actions environment (example
<https://github.com/wadpac/GGIR/actions/runs/5463862340/jobs/9945096566>). 

The warning gives the impression that I am doing something that R no 
longer

supports. However, I am not using the command as.data.frame.POSIXct()
anywhere directly in my code.

When I dive into the code where the warnings occur I see patterns like:

```
now = Sys.time()
df = data.frame (time = seq(now, now + 10, by =1),  B  = 1:11)
```

(this is a simplification of for example:
https://github.com/wadpac/GGIR/blob/master/tests/testthat/test_read.myacc.csv.R 


)

Does this mean I am discouraged from putting a vector with POSIXct 
values

in a data.frame?
If yes, what would be the recommended work around?

I have been trying to find documentation or online discussions about 
this

warning but no luck so far. I see R NEWS
<https://cran.r-project.org/doc/manuals/r-release/NEWS.html> mentions
updates to POSIXct related objects several times in the past year but 
those

seem to be different issues.

Best,

Vincent

[[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] Warning 'as.data.frame.POSIXct()' is deprecated

[Tim Taylor]

Ah yes ... and reading the as.data.frame help we see (emphasis mine):

"... Direct calls to as.data.frame.() are still possible (*base 
package!*), for 12 atomic base classes, but will deprecated ..."


So it does seem that a lot of these warnings are triggered by base R and 
updating this code may be a work in progress.



A little tangential (but related) to this though is still the fact that 
we can trigger the warning with:


lapply(Sys.Date(), as.data.frame)

so I wonder if the code in base/R/zzz.R 
(https://github.com/wch/r-source/blob/9f1940663f902174034a01197e55fd17c767213a/src/library/base/R/zzz.R#L664-L686) 
does need tweaking?


At this stage this is probably more a question for R-devel though.

Tim


On 06/07/2023 14:42, Enrico Schumann wrote:

On Thu, 06 Jul 2023, Vincent van Hees writes:


Thanks, in that case the REPLEX for the issue may need to be:


remember = Sys.getenv("_R_CHECK_AS_DATA_FRAME_EXPLICIT_METHOD_")
Sys.setenv("_R_CHECK_AS_DATA_FRAME_EXPLICIT_METHOD_" = TRUE)
data.frame(time = Sys.time())

  time
1 2023-07-06 14:29:37

data.frame(time = as.POSIXlt(Sys.time()))

  time
1 2023-07-06 14:29:37
Warning message:
Direct call of 'as.data.frame.POSIXct()' is deprecated.  Use
'as.data.frame.vector()' or 'as.data.frame()' instead

Sys.setenv("_R_CHECK_AS_DATA_FRAME_EXPLICIT_METHOD_" = remember)


I think it happens because

 data.frame()

calls 'as.data.frame.POSIXlt' (per its S3-class), which
in turn directly calls 'as.data.frame.POSIXct':

 ## as.data.frame.POSIXlt
 function (x, row.names = NULL, optional = FALSE, ...)
 {
 value <- as.data.frame.POSIXct(as.POSIXct(x), row.names,
 optional, ...)
 if (!optional)
 names(value) <- deparse1(substitute(x))
     value
 }
 

Kind regards
 Enrico


Vincent

On Thu, 6 Jul 2023 at 10:41, Tim Taylor 
wrote:


Apologies - I've not had enough caffeine just yet. The reprex below
highlights the issue but I think the code which implemented the change
*may* need tweaking not lapply.

Tim

On 06/07/2023 09:26, Tim Taylor wrote:

This *may* be an issue in lapply.  Let's see what others day. Reprex
below

Sys.setenv("_R_CHECK_AS_DATA_FRAME_EXPLICIT_METHOD_" = TRUE)
dat <- Sys.Date()
as.data.frame(dat)
#>  dat
#> 1 2023-07-06
lapply(dat, as.data.frame)
#> Warning: Direct call of 'as.data.frame.Date()' is deprecated.  Use
#> 'as.data.frame.vector()' or 'as.data.frame()' instead
#> [[1]]
#>   X[[i]]
#> 1 2023-07-06

Tim

On 06/07/2023 08:54, Vincent van Hees wrote:

Dear all,

I see the following warning in my package test results:

```
Warning
Direct call of 'as.data.frame.POSIXct()' is deprecated.  Use
'as.data.frame.vector()' or 'as.data.frame()' instead
```

The warning is not always there and I struggle to make it
reproducible. I
have encountered it in both Ubuntu 22.04 and in Windows 11, in both R
4.3.0
and 4.3.1, in both RStudio and in an GitHub Actions environment (example
<https://github.com/wadpac/GGIR/actions/runs/5463862340/jobs/9945096566>).
The warning gives the impression that I am doing something that R no
longer
supports. However, I am not using the command as.data.frame.POSIXct()
anywhere directly in my code.

When I dive into the code where the warnings occur I see patterns like:

```
now = Sys.time()
df = data.frame (time = seq(now, now + 10, by =1),  B  = 1:11)
```

(this is a simplification of for example:


https://github.com/wadpac/GGIR/blob/master/tests/testthat/test_read.myacc.csv.R

)

Does this mean I am discouraged from putting a vector with POSIXct
values
in a data.frame?
If yes, what would be the recommended work around?

I have been trying to find documentation or online discussions about
this
warning but no luck so far. I see R NEWS
<https://cran.r-project.org/doc/manuals/r-release/NEWS.html> mentions
updates to POSIXct related objects several times in the past year but
those
seem to be different issues.

Best,

Vincent

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


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

Re: [R-pkg-devel] Re-building vignettes had CPU time 9.2 times elapsed time

[Tim Taylor]

I’m definitely sympathetic to both sides but have come around to the view of 
Greg, Dirk et al. It seems sensible to have a default that benefits the 
majority of “normal” users and require explicit action in shared environments 
not vice-versa.

That is not to say that data.table could not do better with it’s heuristics 
(e.g. respecting CGroups settings as raised by Henrik in 
https://github.com/Rdatatable/data.table/issues/5620) but the current defaults 
(50%) seem reasonable for, dare I say, most users.

Tim

> On 26 Aug 2023, at 03:20, Greg Hunt  wrote:
> 
> The question should be, in how many cases is the current behaviour a
> problem?  In a shared environment, sure, you have to be more careful.  I'd
> say don't let the teenagers in there. The CRAN build server does need to do
> something to protect itself and I don't greatly mind the 2 thread limit, I
> implemented it by hand in my examples and didn't think about it
> afterwards.  On most 8, 16 or 32 way environments, dedicated or
> semi-dedicated to a particular workload, the defaults make some level of
> sense and they are probably most of the use cases.  Protecting high
> processor count environments from people who don't know what they are doing
> would seem to be a mismatch between the people and the environment, not so
> much a matter of software.
> 
>> On Sat, 26 Aug 2023 at 11:49, Jeff Newmiller 
>> wrote:
>> 
>> You have a really bizarre way of twisting what others are saying, Dirk. I
>> have seen no-one here saying 'limit R to 2 threads' except for you, as a
>> way to paint opposing views to be absurd.
>> 
>> What _is_ being said is that users need to be in control_, but _the
>> default needs to do least harm_ until those users take responsibility for
>> that control. Do not turn the throttle up until the user is prepared for
>> the consequences. Trying to subvert that responsibility into packages by
>> default is going to make more trouble than giving the people using those
>> packages simple examples of how to take that control.
>> 
>> A similar problem happens when users discover .Rprofile and insert all
>> those pesky library statements into it, making their scripts
>> irreproducible. If data.table made a warp10() function that activated this
>> current default performance setting then the user would be clearly at fault
>> for using it in an inappropriate environment like a shared HPC or the CRAN
>> servers. Don't put a brick on the accelerator of a teenager's car before
>> they even figure out where the brakes are.
>> 
>>> On August 25, 2023 6:17:04 PM PDT, Dirk Eddelbuettel 
>>> wrote:
>>> 
 On 26 August 2023 at 12:05, Simon Urbanek wrote:
>>> | In reality it's more people running R on their laptops vs the rest of
>> the world.
>>> 
>>> My point was that we also have 'single user on really Yuge workstation'.
>>> 
>>> Plus we all know that those users are often not sysadmins, and do not have
>>> our levels of accumulated systems knowledge.
>>> 
>>> So we should give _more_ power by default, not less.
>>> 
>>> | [...] they will always be saying blatantly false things like "R is not
>> for large data"
>>> 
>>> By limiting R (and/or packages) to two threads we will only get more of
>>> these.  Our collective call.
>>> 
>>> This whole thread is pretty sad, actually.
>>> 
>>> Dirk
>>> 
>> 
>> --
>> Sent from my phone. Please excuse my brevity.
>> 
>> __
>> 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

[[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] What to do when a package is archived from CRAN

[Tim Taylor]

Could you have been caught out with the precompiled binary that serde started 
distributing in a few of it’s versions 
(https://github.com/serde-rs/serde/issues/2538)? That could have been a reason 
if you pinned a version with it present but only CRAN could confirm if that was 
the reason.

Tim

> On 26 Aug 2023, at 22:22, Ivan Krylov  wrote:
> 
> On Sat, 26 Aug 2023 11:46:44 +0900
> SHIMA Tatsuya  wrote:
> 
>> I noticed that my submitted package `prqlr` 0.5.0 was archived from
>> CRAN on 2023-08-19.
>> 
>> 
>> I submitted prqlr 0.5.0 on 2023-08-13. I believe I have since only 
>> received word from CRAN that it passed the automated release process. 
> 
> Sarah gave a good guess (although there are CRAN packages containing
> C++ and Rust code with NOTEs about size of their libs, 18.2Mb is still
> a lot), though I do find it strange that you didn't receive anything
> from CRAN prior to having your package archived. I don't think I ever
> had problems with e-mails being delivered from CRAN to GMail, but we
> can't rule that out.
> 
> You've obviously made an effort to follow the Rust policy, and I don't
> see any obvious problems with this part of the package, although I
> haven't tried it myself to verify the installation working offline from
> bundled source code.
> 
> You've also made an effort to list all the authors of the code
> comprising your package in inst/AUTHORS, which is the right thing to do
> to avoid making the list of authors in DESCRIPTION long enough to be
> unreadable.
> 
> You licensed the package as MIT. Are your dependencies compatible with
> MIT? All direct dependencies of your Rust code seem to be licensed
> under either MIT or Apache-2.0, which seems to be compatible. You named
> the copyright holder of your package as "prqlr authors", which may be a
> problem. (I think I saw it somewhere that for MIT license, CRAN prefers
> the copyright holder to be some kind of legal entity: either the legal
> name of a person, or a company, or something like that.)
> 
> Could the Rust code or any of the dependencies accidentally write under
> the user's home directory or take over the terminal or something like
> that?
> 
> We might need a response from CRAN after all.
> 
> -- 
> Best regards,
> Ivan
> 
> __
> 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] How to create a macos-arm64 virtual machine/cloud environment to debug R package?

[Tim Taylor]

This is just a punt from a quick glance at your tests. Try using the following 
on your local build to ensure it's not a time zone issue

`TZ=NZ R CMD check --as-cran`

`Apologies if this is just noise but whenever I've had issues with datetimes 
and mac tests this is the first thing I check.`

`Tim`




On Wed, 6 Dec 2023, at 9:28 AM, Vincent van Hees wrote:
> Hello,
> 
> What is the recommended way to create a virtual machine or cloud based R
> environment for debugging R package issues specific to OS macos-arm64?
> 
> Details:
> CRAN results show macos-arm64 specific problems for my package:
> https://cran.r-project.org/web/checks/check_results_GGIR.html. I am able to
> reproduce them with https://mac.r-project.org/macbuilder/submit.html. I
> suspect something goes wrong with the timestamp creation or handling as
> that has caused issues with this OS for me in the past. All this relates to
> this
> 
> test for this
> 
> function, that in the process calls this
>  short
> function. I have been trying some edits locally and re-submitting them to
> macbuilder a couple of times to no avail. To debug this efficiently it
> would be good to have access to an R environment for this OS. I do not have
> a physical macos myself.
> 
> Vincent
> 
> [[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] Matrix 1.7-0 to be released in March with ABI-breaking SuiteSparse update

[Tim Taylor]

Hi Mikael

Revisiting this. Have the plans changed for 1.7-0 release?

Tim

On Mon, 12 Feb 2024, at 6:36 PM, Mikael Jagan wrote:
> Dear users and binary repository maintainers,
> 
> We are preparing Matrix version 1.7-0 for CRAN submission on March 11, ahead
> of the spring release of R version 4.4.0.  The only significant change from
> Matrix 1.6-5 is an update of the internal SuiteSparse libraries
> (5.10.1 -> 7.6.0).  Unfortunately, the old and new SuiteSparse versions are 
> binary incompatible, hence so too will be the old and new Matrix versions.
> 
> A corollary is that users and binary repository maintainers switching between
> Matrix < 1.7-0 and Matrix >= 1.7-0 must rebuild _from sources_ packages that
> link Matrix:
> 
> > tools::package_dependencies("Matrix", which = "LinkingTo", reverse = 
> > TRUE)[[1L]]
>   [1] "ahMLE"   "bayesWatch"  "cplm"
>   [4] "GeneralizedWendland" "geostatsp"   "irlba"
>   [7] "lme4""mcmcsae" "OpenMx"
> [10] "PRIMME"  "PUlasso" "robustlmm"
> [13] "spGARCH" "TMB" "bcSeq"
> 
> For users, that means doing, e.g.,
> 
>  install.packages("lme4", type = "source")
> 
> but an alternative for Windows and macOS users without the required tools is
> 
>  oo <- options(repos = "https://cran.r-project.org/";)
>  install.packages("Matrix")
>  install.packages("lme4")
>  options(oo)
> 
> where we trust CRAN to provide binaries compatible with the latest Matrix
> version (because we notify CRAN upon submission about required rebuilds).
> Once other repositories react with rebuilds, they can be used instead of
> CRAN.
> 
> Our reverse dependency checks (and history, intuition, ...) show that most
> problems (caught segfaults in this case) can be traced to a binary 
> incompatible
> lme4 and not to one of the other packages linking Matrix.  Still, we recommend
> rebuilds for all 15 packages.
> 
> Maintainers of packages that link Matrix can implement an .onLoad test for
> possible binary incompatibility by comparing the value of
> 
>  if (utils::packageVersion("Matrix") >= "1.6.2")
>  Matrix::Matrix.Version()[["abi"]]
>  else numeric_version("0")
> 
> at install time and at load time, warning the user if the values differ.
> But please do look at the above and not at packageVersion("Matrix") directly,
> as the ABI version is incremented less often than the package version.
> 
> Mikael {on behalf of citation("Matrix")$author}
> 
> __
> 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] Matrix 1.7-0 to be released in March with ABI-breaking SuiteSparse update

[Tim Taylor]

On Wed, 10 Apr 2024, at 11:52 AM, Martin Maechler wrote:
>>>>>> Tim Taylor 
>>>>>> on Wed, 10 Apr 2024 10:37:00 +0100 writes:
>
> > Hi Mikael Revisiting this. Have the plans changed for
> > 1.7-0 release?
>
> > Tim
>
> Yes.  Matrix 1.7-0 *has* been on CRAN now for while
> (i.e. 'March' has remained as announced), *but*
> -- because of the ABI change and the problem it can cause for
>*some* users --
>
> we have made it  'Depends: R (>= 4.4.0)'
> i.e., you *see* the new Matrix only once you use R 4.4.0
> which has been available as "alpha" already and is now in
> "beta" already, e.g.,
>
>   R version 4.4.0 beta (2024-04-10 r86393) -- "Puppy Cup"
>
>
> Best regards,
> Martin
>
> --
> Martin Maechler
> ETH Zurich  and  R Core Team

Thank you Martin.

Indeed, I should have dug further.

Rdevel> packageVersion("Matrix")
[1] '1.7.0'

Cheers

Tim

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

Re: [R-pkg-devel] Check errors for RMarkdown vignettes with error chunks

[Tim Taylor]

Does this issue over in knitr shed some additional light ...

https://github.com/yihui/knitr/issues/2338

Tim

On 07/06/2024 14:50, Ivan Krylov via R-package-devel wrote:

В Fri, 7 Jun 2024 09:10:03 +0200
"C.H."  пишет:


RMarkdown vignettes are sometimes used to demonstrate errors and one
can write vignettes with `error` chunks.

```{r, error = TRUE}
stop()
```
But now CRAN also reports the same ERRORS for mac and linux `oldrel`
(4.3.3).

https://cran.r-project.org/web/checks/check_results_rio.html

It sounds like R Markdown, when tangling a vignette into an *.R file,
should provide additional wrapping for chunks with the error = TRUE
option set. Would a try({ chunk content }) suffice?

R CMD check relies on the tangled script not to crash, and there is
currently no such wrapping in the generated output:
https://github.com/cran/rio/blob/master/inst/doc/remap.R



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

Re: [R-pkg-devel] Delays in CRAN Windows Binaries?

[Tim Taylor]

I've made an example at https://github.com/tjtnew/newbies that uses
GitHub actions to monitor how many hours a package has been in the
"newbies" queue.  It updates hourly and saves to a csv in the repo.
It's not something I have time to develop more but if someone wants to
pick it up and take it further please do. Disclaimer - hacked together
quite quickly so code could well be a little iffy.
Best
Tim


On Wed, 21 Oct 2020 at 20:47, Henrik Bengtsson
 wrote:
>
> Related to this:
>
> It would be neat to have a dashboard that reports on the current
> latency is on the different CRAN "queues" are, e.g. how long is the
> average waiting time when submitting a new package ("newbies") until
> you get a manual reply or it's on CRAN, submitting an update with all
> OK before it hits CRAN, waiting time for building Windows or macOS
> binaries, etc.  Some, but not all, of this information can already be
> guestimated from the info on ftp://cran.r-project.org/incoming/, on
> easier on https://lockedata.github.io/cransays/articles/dashboard.html.
> I think this could be a great contributor project - it doesn't have to
> be hosted by CRAN.
>
> /Henrik
>
> On Wed, Oct 21, 2020 at 11:08 AM Marc Schwartz  wrote:
> >
> > Hi All,
> >
> > Just thought that I would check to see if there are any known issues/delays 
> > for CRAN in creating R release and devel binaries for Windows for updated 
> > packages.
> >
> > It has been four days since I submitted an update and the other binaries 
> > were created within a couple of days. The two Windows binaries are the only 
> > outstanding updates pending.
> >
> > Thanks!
> >
> > Marc Schwartz
> >
> > __
> > 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

[R-pkg-devel] Test errors occurring on win-builder only

[Tim Taylor]

Morning all

What's the best way to narrow down test errors that are occurring on
win-builder only?  I've tried checking the package on local installs
of r-devel (both 32 bit and 64bit), and on the Windows installs on
rhub and through GitHub actions.  On all of these systems the checks
pass without issue.

Is there anyway to match the configuration of the CRAN / win-builder machine?

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

Re: [R-pkg-devel] Test errors occurring on win-builder only

[Tim Taylor]

Hi Uwe,

here's the response from win-builder:
*
Your package reportfactory_0.0.7.tar.gz has been built (if working)
and checked for Windows.
Please check the log files and (if working) the binary package at:
https://win-builder.r-project.org/21kwCPDaCbxn
The files will be removed after roughly 72 hours.
Installation time in seconds: 6
Check time in seconds: 110
Status: 2 ERRORs, 1 NOTE
R Under development (unstable) (2020-12-09 r79601)
**

Cheers

On Thu, 10 Dec 2020 at 10:02, Uwe Ligges
 wrote:
>
> WHich package? Where are the logs?
>
> Best,
> Uwe Ligges
>
>
> On 10.12.2020 10:39, Tim Taylor wrote:
> > Morning all
> >
> > What's the best way to narrow down test errors that are occurring on
> > win-builder only?  I've tried checking the package on local installs
> > of r-devel (both 32 bit and 64bit), and on the Windows installs on
> > rhub and through GitHub actions.  On all of these systems the checks
> > pass without issue.
> >
> > Is there anyway to match the configuration of the CRAN / win-builder 
> > machine?
> >
> > __
> > 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] Use of long double in configuration

[Tim Taylor]

Is it correct to say that R's conditional use of long double is around ensuring 
things work on platforms which have 'long double' identical to 'double' types, 
as opposed to there being an odd compiler targeted that does not even have any 
concept of 'long double' type?

As background this was motivated by a query raised in the matrixStats package:
https://github.com/HenrikBengtsson/matrixStats/issues/278

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

Re: [R-pkg-devel] Use of long double in configuration

[Tim Taylor]

Cheers for the quick response.

To clarify my question: Is it correct to say that as long as packages do not 
assume the greater precision provided by 'double' there is no reason they 
cannot use 'long double' to get *possible* advantages (e.g. in summations). 
AFAICT 'long double' is (and has always been) part of the C standard so it's 
use as a type should be unproblematic (this is the query relevant to 
matrixStats).

Apologies if this does not make much sense.

Tim



On Wed, 30 Apr 2025, at 9:33 AM, Uwe Ligges wrote:
> On 30.04.2025 10:25, Tim Taylor wrote:
>> Is it correct to say that R's conditional use of long double is around 
>> ensuring things work on platforms which have 'long double' identical to 
>> 'double' types, as opposed to there being an odd compiler targeted that does 
>> not even have any concept of 'long double' type?
>
> a double is 64 bit and stored that way on all platforms, the concept of 
> long doubles is CPU specific. x86 chips have 80bit in the floating point 
> units for calculations before rounding (and normalizing) to a regular 
> double.
>
> Some chips, e.g. those ARM chips used in current M[123]Macs (hence very 
> relevant topic), do not support long doubles. And compilers offer to 
> compile without support for long doubles which e.g. CRAN uses to check 
> in an additional (issues) check.
>
> Best,
> Uwe Ligges
>
>> 
>> As background this was motivated by a query raised in the matrixStats 
>> package:
>> https://github.com/HenrikBengtsson/matrixStats/issues/278
>> 
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>
> Attachments:
> * smime.p7s

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

Re: [R-pkg-devel] Use of long double in configuration

[Tim Taylor]

Thank you all!

Everything is clear.

Tim

On Wed, 30 Apr 2025, at 10:07 AM, Tomas Kalibera wrote:
> On 4/30/25 10:43, Tim Taylor wrote:
>> Cheers for the quick response.
>>
>> To clarify my question: Is it correct to say that as long as packages do not 
>> assume the greater precision provided by 'double' there is no reason they 
>> cannot use 'long double' to get *possible* advantages (e.g. in summations). 
>> AFAICT 'long double' is (and has always been) part of the C standard so it's 
>> use as a type should be unproblematic (this is the query relevant to 
>> matrixStats).
>
> Probably already clear from previous answers, but yes, packages can use 
> long double type.
>
> Whenever using a long double type, one needs to be careful about making 
> sure the algorithms work, and the tests pass (so have reasonable 
> tolerances), even when the long double type happens to be just the same 
> as double. This is the case on aarch64, and macOS/aarch64 is one of the 
> platforms where packages have to work, anyway, so this shouldn't be too 
> limiting anymore - but really one needs to test on such platform.
>
> R itself has an option to disable use of long double to make such 
> testing in R itself possible also on other platforms. In principle one 
> could do something similar in a package, have some ifdefs to disable 
> long doubles, but this is not required. And I probably wouldn't do that, 
> I'd just test on aarch64 regularly.
>
> See Writing R Extensions for more details.
>
> Best
> Tomas
>
>> Apologies if this does not make much sense.
>>
>> Tim
>>
>>
>>
>> On Wed, 30 Apr 2025, at 9:33 AM, Uwe Ligges wrote:
>>> On 30.04.2025 10:25, Tim Taylor wrote:
>>>> Is it correct to say that R's conditional use of long double is around 
>>>> ensuring things work on platforms which have 'long double' identical to 
>>>> 'double' types, as opposed to there being an odd compiler targeted that 
>>>> does not even have any concept of 'long double' type?
>>> a double is 64 bit and stored that way on all platforms, the concept of
>>> long doubles is CPU specific. x86 chips have 80bit in the floating point
>>> units for calculations before rounding (and normalizing) to a regular
>>> double.
>>>
>>> Some chips, e.g. those ARM chips used in current M[123]Macs (hence very
>>> relevant topic), do not support long doubles. And compilers offer to
>>> compile without support for long doubles which e.g. CRAN uses to check
>>> in an additional (issues) check.
>>>
>>> Best,
>>> Uwe Ligges
>>>
>>>> As background this was motivated by a query raised in the matrixStats 
>>>> package:
>>>> https://github.com/HenrikBengtsson/matrixStats/issues/278
>>>>
>>>> __
>>>> R-package-devel@r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>
>>> Attachments:
>>> * smime.p7s
>> __
>> 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] Advice for addressing CRAN rejection

[Tim Taylor]

On Wed, 14 May 2025, at 4:18 PM, smallepsilon wrote:

> No need to apologize. I hope the following example helps clarify what I 
> mean. Suppose that modify_matrix(mat, other_args) is a function that, 
> among other things, applies eigen() to mat. For good reasons, 
> other_args has no default value. It is sometimes convenient, though, to 
> supply the user with default values. Therefore, there is another 
> function, convenient_modify_matrix():
>

I'd just use all.equal but I *think* you could just check the call is 
constructed correctly, e.g.

convenient_modify_matrix <- function(mat) modify_matrix(mat, other_args = 
default)

identical(
  body(convenient_modify_matrix),
  call("modify_matrix", quote(mat), other_args = quote(default))
)

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

Re: [R-pkg-devel] Advice for addressing CRAN rejection

[Tim Taylor]

> On 14 May 2025, at 02:21, Dirk Eddelbuettel  wrote:
> 
…
> There is a higher-level README linked from CRAN package pages but I can't
> find it now :-/

https://cran.r-project.org/web/checks/check_issue_kinds.html I believe 

Tim
[[alternative HTML version deleted]]

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