[Rd] Why does format.default skip dispatch for list items?

This is the documented behavior since r35262 (2005), from ?format > If x is a list, the result is a character vector obtained by applying > format.default(x, ...) to each element of the list One consequence is that we can't add "nice" printing methods for list-of-object columns in data.frames:

Re: [Rd] Is it possible to gracefully interrupt a child R process on MS Windows?

On Sun, 11 May 2025 10:58:18 -0700 Henrik Bengtsson wrote: > Is it possible to gracefully interrupt a child R process on MS > Windows, e.g. a PSOCK cluster node? Not in the general case (I think, based on the code paths leading to Rf_onintr() on Windows), but PSOCK cluster nodes are instances of

[Rd] Is it possible to gracefully interrupt a child R process on MS Windows?

In help("pskill", package = "tools") is says: Only SIGINT and SIGTERM will be defined on Windows, and pskill will always use the Windows system call TerminateProcess. As far as I understand it, TerminateProcess [1] terminates the process "quite abruptly". Specifically, it is not possible for th

Re: [Rd] array-bound error with GCC 13/14

> On 9 May 2025, at 19:29, Kevin Ushey wrote: > > Hopefully a member of the CRAN team will tell me I'm wrong, but I > think whether or not there is a compiler bug is ultimately irrelevant > -- packages on CRAN must compile cleanly even with potentially-buggy > development versions of compilers.

Re: [Rd] array-bound error with GCC 13/14

Hopefully a member of the CRAN team will tell me I'm wrong, but I think whether or not there is a compiler bug is ultimately irrelevant -- packages on CRAN must compile cleanly even with potentially-buggy development versions of compilers. So, whether or not there is a bug in gcc is moot -- you'll

Re: [Rd] array-bound error with GCC 13/14

В Fri, 9 May 2025 11:09:22 +1000 Stephen Wade пишет: > inlined from ‘std::vector literanger::adjust_pvalues(const > std::vector&)’ at ../src/literanger/utility_math.h:99:48: > /usr/include/c++/13/bits/stl_algobase.h:437:30: warning: ‘void* > __builtin_memmove(void*, const void*, long unsigned

[Rd] array-bound error with GCC 13/14

The literanger package is no longer passing on CRAN (https://CRAN.R-project.org/package=literanger) due to array-bound warnings in GCC 13.3 and 14.2 (more details below). This _looks_ to me like one of either a) a compiler bug, b) a false positive, or c) (very unlikely) something in the standard l

[Rd] Recommend/clarify in ?utils::news that h2/h3 markdown hierarchy is preferable to h1/h2

The current wording in ?utils::news reads to me as implying we should use `#` and `##` for the respective version, category headings [1]: > File NEWS.md should contain the news in Markdown..., with the > primary heading level giving the version number... Where available, > secondary headings are t

Re: [Rd] sqrt(.Machine$double.xmax)^2 == Inf, but only on Windows in R

Hello! My three Groschen: On MacOS (Intel CPU) and R 4.4.3 I report: > dput(.Machine$double.xmax, control = 'hex') 0x1.fp+1023 > dput(sqrt(.Machine$double.xmax), control = 'hex') 0x1.fp+511 > dput(sqrt(.Machine$double.xmax)^2, control = 'hex') 0x1.ep+1023 so as

Re: [Rd] sqrt(.Machine$double.xmax)^2 == Inf, but only on Windows in R

On Tue, 29 Apr 2025 12:00:09 +0200 Martin Maechler wrote: > Would you (or anybody else) know if this is new behaviour or it > also happened e.g. in R 4.4.x versions on Windows? R-4.3.1 on Windows 7 in a virtual machine gives: dput(sqrt(.Machine$double.xmax), control = 'hex') # 0x1p+512 sqrt(.M

Re: [Rd] sqrt(.Machine$double.xmax)^2 == Inf, but only on Windows in R

> Pavel Krivitsky via R-devel > on Mon, 28 Apr 2025 05:13:41 + writes: > Hello, Under R 4.5.0 on Windows (x86-64), I get: >> sqrt(.Machine$double.xmax)^2 > [1] Inf >> sqrt(.Machine$double.xmax)*sqrt(.Machine$double.xmax) > [1] Inf > On other hand on other

[Rd] sqrt(.Machine$double.xmax)^2 == Inf, but only on Windows in R

Hello, Under R 4.5.0 on Windows (x86-64), I get: > sqrt(.Machine$double.xmax)^2 [1] Inf > sqrt(.Machine$double.xmax)*sqrt(.Machine$double.xmax) [1] Inf On other hand on other platforms, including Debian Linux (x86-64), I get: d> sqrt(.Machine$double.xmax)^2 [1] 1.797693134862315508561e+308 d> s

[Rd] on.exit() handler being interrupted by time limit

This StackOverflow question: https://stackoverflow.com/q/79594532 and this discussion on Github: https://github.com/r-lib/evaluate/issues/242 are talking about an interesting situation. Under a fairly simple setup shown in both, setTimeLimit() can interrupt the on.exit() handler that was ins

[Rd] Complex numbers and negative zeroes

0 and 0i are parsed as constants with 'positive zero' real and imaginary parts, whereas 0, 0i, and 00i are parsed as *calls*: 0~ ( 0 ) 0i ~ ( 0i) 00i ~ ((0), 0i) Keeping in mind R's usual arithmetic conversions and the IEEE 754 standard which defines e

[Rd] Complex numbers and negative zeroes

Dear r-devel, In R `sign(0)` and `sign(-0)` both return `0` but negative zeroes do exist in the sense that dividing by them gives `-Inf` Complex numbers behave oddly with negative 0s, see below: ``` r 1 / Re(0 + 0i) #> [1] Inf 1 / Im(0 + 0i) #> [1] Inf 1 / Re(0 - 0i) #> [1] Inf 1 / Im(0 - 0i) # n

Re: [Rd] R should add an API routine for safe use of memcpy(), memset() for use with 0-length SEXP

Is it correct to say the desired behavior in the long term is for such an error to occur? If so, could we make it so the --enable-strict-barrier (or other option) behavior educes those errors for developers to opt in to finding them sooner than later? On Wed, Apr 23, 2025 at 3:43 PM Tomas Kaliber

Re: [Rd] R should add an API routine for safe use of memcpy(), memset() for use with 0-length SEXP

On 4/24/25 00:18, Michael Chirico wrote: In that case it seems like just erroring instead of returning invalid pointers is a much friendlier option. Why give developers an unpinned grenade to carry around? That would be too strict at this point. There is too much code around depending on tha

Re: [Rd] R should add an API routine for safe use of memcpy(), memset() for use with 0-length SEXP

In that case it seems like just erroring instead of returning invalid pointers is a much friendlier option. Why give developers an unpinned grenade to carry around? On Wed, Apr 23, 2025 at 1:38 PM Tomas Kalibera wrote: > > On 4/23/25 19:03, Michael Chirico wrote: > > h/t Tim Taylor for pointing o

Re: [Rd] R should add an API routine for safe use of memcpy(), memset() for use with 0-length SEXP

h/t Tim Taylor for pointing out my blindspot :) We have Memcpy() in API already [1], which wraps a 0-aware R_chk_memcpy() [2]. We don't quite have Memset() in API, though; instead we have Memzero() [3] for R_chk_memset(s, 0, n) which is 0-aware memset() [4]. [1] https://github.com/r-devel/r-svn

[Rd] R should add an API routine for safe use of memcpy(), memset() for use with 0-length SEXP

>From R 4.5.0 [1], all builds of R discourage use of INTEGER() [and friends REAL(), ... and *_RO() equivalents] on length-0 SEXP [2]. Before R 4.5.0, this was the behavior under --enable-strict-barrier. That means the following can segfault under strict builds (e.g. -fsanitize=alignment and -O0):

Re: [Rd] R Dev Day @ RSECon25, Fri 12 Sep, Warwick University - travel funding available!

A reminder that the application deadline for this event is coming up - I put the wrong day in the original email below, the deadline is **Wednesday, 23 April (midnight anywhere on earth).** On Wed, Apr 2, 2025, at 1:43 PM, Heather Turner wrote: > Dear All, > > There will be another R Dev Day aft

Re: [Rd] r-base: FTBFS: Add "${boot_path}/zero" for OpenJDK zero build

Dandan, thanks! Dirk reported it as https://bugs.r-project.org/show_bug.cgi?id=18884 and it should be fixed in R-devel r88154 - please confirm if it works for you and if it does, I'll port it to R 4.5.0 Patched. Cheers, Simon > On Apr 17, 2025, at 3:40 PM, zhangdandan wrote: > > Source: r-

Re: [Rd] r-base: FTBFS: Add "${boot_path}/zero" for OpenJDK zero build

On 17 April 2025 at 11:40, zhangdandan wrote: | Source: r-base | Version: 4.5.0-1 | Severity: normal | Tags: FTBFS patch | User: debian-loonga...@lists.debian.org | Usertags: loong64 | | Hi maintainers, | | Compiling the rjava 1.0-11-1 failed for loong64 in the Debian Package | Auto-Building e

[Rd] r-base: FTBFS: Add "${boot_path}/zero" for OpenJDK zero build

Source: r-base Version: 4.5.0-1 Severity: normal Tags: FTBFS patch User: debian-loonga...@lists.debian.org Usertags: loong64 Hi maintainers, Compiling the rjava 1.0-11-1 failed for loong64 in the Debian Package Auto-Building environment. The build error log(build error on 10 architectures)  is

[Rd] Inappropriate modifications to R C source related to bool

src/main/attrib.c r87863 'TRUE' is not replaced with 'true' in functions 'row_names_gets',  'isOneDimensionalArray', 'getAttrib0', 'copyMostAttribNoTs', 'classgets',  'R_data_class2'. But it works fine. src/main/main.c r87863 'FALSE' is not replaced with 'false' in bool wasDisplayed = FALSE;

Re: [Rd] R does not build with conda libcurl

Toby, I know this is not what you're asking for, but when I build R from source within a conda environment I make sure I use the conda compilers. I think what you might be doing is using system compilers with conda libraries that may have been built using a different compiler. Not saying this is

Re: [Rd] [EXTERNAL] Re: Request for comment: namespace resolution in terms(, specials=) [::, etc.]

Peter,    I had an argument with someone at one of the big companies (google?) several years ago over the coding standard you mention, who was claiming that the survival package had a bug due to a wrong result using survival::strata() in a formula.   I argued back. I agree with you that names

Re: [Rd] Help with resolving non-API call warnings in Rust-based packages (ymd and fcl)

25 10:27 > To 谭显英 > Cc r-devel@r-project.org > Subject Re: [Rd] Help with resolving non-API call warnings in Rust-based > packages (ymd and fcl) > Please update your Makevars template using the development version of > rextendr. > > Please see: > https://github.com/extend

Re: [Rd] Request for comment: namespace resolution in terms(, specials=) [::, etc.]

I don't seem to have the original post (not in spamfilter either). But generically, I think namespacing specials in formulas is just a Bad Idea. They are syntactic constructs, specifically _not_ function calls, so people are stumbling over formally protecting them from a non-existing scoping iss

Re: [Rd] Help with resolving non-API call warnings in Rust-based packages (ymd and fcl)

Thanks. I confirmed the issue has been resolved by following the instructions in your link. Regards, Xianying Tan (shrektan) Replied Message | From | Josiah Parry | | Date | 04/15/2025 10:27 | | To | 谭显英 | | Cc | r-devel@r-project.org | | Subject | Re: [Rd] Help with resolving

Re: [Rd] Help with resolving non-API call warnings in Rust-based packages (ymd and fcl)

Please update your Makevars template using the development version of rextendr. Please see: https://github.com/extendr/extendr/releases/tag/extendr-api-v0.8.0 On Mon, Apr 14, 2025 at 18:59 谭显英 wrote: > Dear R-devel list, > > > I maintain two packages that use Rust code through the "extendr" lib

[Rd] Help with resolving non-API call warnings in Rust-based packages (ymd and fcl)

Dear R-devel list, I maintain two packages that use Rust code through the "extendr" library: ymd (https://github.com/shrektan/ymd) and fcl (https://github.com/shrektan/fcl) . These packages are currently at risk of being removed from CRAN due to calls to R's non-API functions. I've addressed

Re: [Rd] Request for comment: namespace resolution in terms(, specials=) [::, etc.]

I don't have any concerns about these changes, don't see any need to preserve the old behaviour. In lme4 and glmmTMB (and now broken out into a separate `reformulas` package, I do this the hard way, walking down the parse trees of formula objects and looking for specials, and not using the

Re: [Rd] R does not build with conda libcurl

On Mon, 14 Apr 2025 14:10:56 +0200 Toby Hocking wrote: > /usr/bin/ld : ../../lib/libR.so : référence indéfinie vers > « u_getVersion_73 » Strange that it's complaining about symbols from libicu when the problem is due to libcurl-related flags. What was the command line used to link libR.so somew

[Rd] R does not build with conda libcurl

Hi all, I'm not sure if this is an issue with conda or R. I expected that I should be able to build R from source, with a conda environment active. However, I observe that with conda 23.9.0, in an environment with libcurl package installed, I get a link error. The configure works fine: (base) hoct

Re: [Rd] table() and as.character() performance for logical values

> Suharto Anggono Suharto Anggono > on Sat, 12 Apr 2025 08:27:26 + (UTC) writes: > For NA case (x == NA_LOGICAL), if R_print.na_width > NB-1 , the "fast path" for 'EncodeLogical' that I propose previously behaves differently from the general case that truncates at (NB-1). Y

Re: [Rd] should the top of doc/NEWS.3 mention doc/NEWS.Rd ?

Also, the files do exist in the build directory after R has been built. I suppose that we could copy them into the sources for the distribution, but generically, it is bad luck for tarballs to include both sources and build results because it confuses the Makefile dependencies (& we have plenty

Re: [Rd] should the top of doc/NEWS.3 mention doc/NEWS.Rd ?

On 2025-04-13 11:07 a.m., Benjamin Tyner wrote: Greetings, As of r80088, at the top of doc/NEWS.3 file it says: LATER NEWS:   • News for R 4.x.y can be found in HTML format at doc/html/NEWS.html,     and in text format in file NEWS in the doc directory. However as far as I can tell, neithe

[Rd] should the top of doc/NEWS.3 mention doc/NEWS.Rd ?

Greetings, As of r80088, at the top of doc/NEWS.3 file it says: LATER NEWS:   • News for R 4.x.y can be found in HTML format at doc/html/NEWS.html,     and in text format in file NEWS in the doc directory. However as far as I can tell, neither NEWS nor NEWS.html exists in the R source. Should

Re: [Rd] table() and as.character() performance for logical values

For NA case (x == NA_LOGICAL), if R_print.na_width > NB-1 , the "fast path" for 'EncodeLogical' that I propose previously behaves differently from the general case that truncates at (NB-1). To be consistent with the general case, if(w == R_print.na_width) can be replaced with if(w == R_print.na_

Re: [Rd] Check for protection

On 4/11/25 17:39, Duncan Murdoch wrote: On a tangent from the main topic of this thread:  sometimes (especially to non-experts) it's not obvious whether a variable is protected or not. I don't think there's any easy way to determine that, but perhaps there should be.  Would it be possible to

Re: [Rd] Check for protection

That might help, but protecting things is a fairly cheap operation, so I don't know if people would bother with the naming convention. It's just as easy to just protect things if you're not sure. One way things can go wrong is when you think you protected something, but then the pointer chang

Re: [Rd] table() and as.character() performance for logical values

On 4/11/25 16:23, Suharto Anggono Suharto Anggono via R-devel wrote: Alternative revision: Added to my changed 'StringFromLogical': #define CACHE 16 if (!(*warn & CACHE)) {TrueCh = FalseCh = NULL; *warn |= CACHE;} No change to 'coerceToString' and 'coerceToSymbol'. -- On Friday

Re: [Rd] Check for protection (was: table() and as.character() performance for logical values)

For a long-term horizon, would it help R developers to use a naming convention? Perhaps, varName_PROT, or the inverse varName_UNPROT? Eventually, teach some linter about that? On Fri, Apr 11, 2025 at 10:40 AM Duncan Murdoch wrote: > On a tangent from the main topic of this thread: sometimes (es

[Rd] Check for protection (was: table() and as.character() performance for logical values)

On a tangent from the main topic of this thread: sometimes (especially to non-experts) it's not obvious whether a variable is protected or not. I don't think there's any easy way to determine that, but perhaps there should be. Would it be possible to add a run-time test you could call in C c

Re: [Rd] table() and as.character() performance for logical values

Alternative revision: Added to my changed 'StringFromLogical': #define CACHE 16 if (!(*warn & CACHE)) {TrueCh = FalseCh = NULL; *warn |= CACHE;} No change to 'coerceToString' and 'coerceToSymbol'. -- On Friday, 11 April 2025 at 08:02:58 pm GMT+7, Suharto Anggono Suharto Anggono wr

Re: [Rd] table() and as.character() performance for logical values

Oh, with the abuse of 'warn' in my previous message, warning would be issued if the input 'v' of 'coerceToString' is a logical vector of length 1. Revision: Added to my changed 'StringFromLogical': if (*warn) {TrueCh = FalseCh = NULL; *warn = 0;} 'coerceToString': insert if (i == 0) warn = 1;

Re: [Rd] table() and as.character() performance for logical values

On second thought, I wonder if the caching in my changed 'StringFromLogical' in my previous message is safe. While 'ans' in the C function 'coerceToString' is protected, its element is also protected. If the object corresponding to 'ans' is then no longer protected, is it possible for the cache

[Rd] R 4.5.0 is released

ting in download.file() has been extended to report the outcome for individual files in simultaneous downloads. • The Rd \link macro now allows markup in the link text when the topic is given by the optional argument, e.g., \link[=gamma]{\eqn{\Gamma(x)}}. • If La_library(

Re: [Rd] Better support ESS by allowing choice of CRAN mirror using the `menu-choice` widget

I know ESS already has a better interface for installing packages, C-c C-e TAB, but it'd be "neat" if when I forget to do this and I call install.packages() without first setting a mirror that either the same interface would be presented rather than Tcl/Tk, or a widget.el-based interface was presen

Re: [Rd] table() and as.character() performance for logical values

Right, thanks! These are non-standard uses of factor(), edge cases I alluded to. We didn't see any problems with the patch in existing tests nor in CRAN/BIOC package checks. Note that 'levels' is documented as an optional vector of the unique values (as character strings) that ‘x’ might

Re: [Rd] table() and as.character() performance for logical values

> Suharto Anggono Suharto Anggono via R-devel > on Thu, 10 Apr 2025 07:53:04 + (UTC) writes: > Chain of calls of C functions in coerce.c for as.character() in R: > do_asatomic > ascommon > coerceVector > coerceToString > StringFromLogical (for each elemen

Re: [Rd] table() and as.character() performance for logical values

Chain of calls of C functions in coerce.c for as.character() in R: do_asatomic ascommon coerceVector coerceToString StringFromLogical (for each element) The definition of 'StringFromLogical' in coerce.c : attribute_hidden SEXP StringFromLogical(int x, int *warn) { int w; formatLogical(&x,

Re: [Rd] Better support ESS by allowing choice of CRAN mirror using the `menu-choice` widget

I see, a profile option is a good idea. I think I will tinker with the ESS package a bit regardless and see what interesting things can be done. On Wed., Apr. 9, 2025, 7:02 p.m. Dirk Eddelbuettel, wrote: > > On 8 April 2025 at 23:15, Bryce Carson wrote: > | I know ESS already has a better inter

Re: [Rd] Better support ESS by allowing choice of CRAN mirror using the `menu-choice` widget

On 8 April 2025 at 23:15, Bryce Carson wrote: | I know ESS already has a better interface for installing packages, C-c C-e | TAB, but it'd be "neat" if when I forget to do this and I call | install.packages() without first setting a mirror that either the same | interface would be presented rathe

Re: [Rd] table() and as.character() performance for logical values

With the change to 'factor', factor(1L, levels = TRUE) doesn't give NA, different from factor(1, levels = TRUE) With the change to 'factor', factor(TRUE, levels = 1L) and factor(TRUE, levels = 1) don't give NA. With the change to 'factor', factor(2L, levels = sqrt(2)^2) gives NA, different from f

[Rd] Better support ESS by allowing choice of CRAN mirror using the `menu-choice` widget

This would allow ESS to be used in a graphical-mode emacs without utilizing the Tcl/Tk widget, and on non-Linux platforms would allow Emacs to provide the choice widget rather than Tcl/Tk, Aqua, or whatever Windows does. [[alternative HTML version deleted]] ___

Re: [Rd] Proposal: Integrating Rust Toolchain into Rtools for Rust-Based R Package Development

Hi Tomas, Thank you very much for the detailed and thoughtful reply. Your explanation really helped me better understand the architecture of Rtools. You're absolutely right that a **ideal** integration of Rust into Rtools would ideally involve extending the MXE-based toolchain, as the same comp

Re: [Rd] WRE Date field & CRAN

Hi Duncan, Thanks for the fast check and reply. Indeed, the documentation is correct. I just think it can be interpreted as saying Date is required to submit to CRAN. Some package maintainers have been using the Date field, probably interpreting this section this way because if you read the main

Re: [Rd] WRE Date field & CRAN

On 2025-04-06 10:55 a.m., Lluís Revilla wrote: Hi, On Writing R Extensions there is a footnote [6] about the "Date" field on the DESCRIPTION file being required by CRAN: "required by CRAN, so checked by R CMD check --as-cran" I think this is no longer up to date, as I've seen packages publishe

[Rd] WRE Date field & CRAN

Hi, On Writing R Extensions there is a footnote [6] about the "Date" field on the DESCRIPTION file being required by CRAN: "required by CRAN, so checked by R CMD check --as-cran" I think this is no longer up to date, as I've seen packages published on CRAN without it. This might be because now t

Re: [Rd] Patch for RJSONIO

> Dirk Eddelbuettel writes: Great, thanks! Will put up a fixed RJSONIO shortly ... Best -k > I can never remember where the canonical sources are for the effectively-CRAN > maintained packages so I am dropping it here -- yesterday's update to RJSONIO > does not build on anything older than

[Rd] request for discussion on lonely doc patch suggestion

Aki Vehtari and I suggested a revision to some of the man pages involving NA/is.nan/is.na about a year ago, but it never seems to have gotten any traction. https://bugs.r-project.org/show_bug.cgi?id=18691 Discussion here: https://fediscience.org/@aveht...@bayes.club/112043521852737720 Th

Re: [Rd] structure(, ...) is sticky: a bug, or should it be an error?

> I'm pretty convinced we should fix it by checking for primitive > functions inside the C code of `attributes<-` : > arguably the bug is really there, rather than in structure(). > > Patches are welcome (via R's Bugzilla or just here). Thank you Martin. I'll make sure I create a brief BugZilla re

Re: [Rd] Suppressed "graphical parameter" warnings reviving themselves magically

I don't know what's going on, but I see a version of it in R 4.4.2 on MacOS in the console, but not in R.app. The difference is I only get one of the warnings, and only on the first attempt: $ R R version 4.4.2 (2024-10-31) -- "Pile of Leaves" Copyright (C) 2024 The R Foundation for Statist

Re: [Rd] request for discussion on lonely doc patch suggestion

Thanks for the suggestion. I did a quick scan of the delta manual, but couldn't spot anything on integration with svn, just git. Have you worked out the necessary config options for svn so that it would work with diffs like Ben's, or for running `svn diff` on some local changes? Currently I

[Rd] Bad URLs in DESCRIPTION files

Hi All, Just want to flag a few packages: MatrixLDA: https://cran.r-project.org/web/packages/MatrixLDA/index.html The URL is technically valid - ajmols...@github.io/ - but returns a 404. Almost certainly a typo. redistmetrics: https://cran.r-project.org/web/packages/redistmetrics/index.html Not

Re: [Rd] R CMD check and CRAN's Rust policy

t; and https://github.com/extendr/hellorustc > > <https://github.com/extendr/hellorustc> > > >>> <https://github.com/extendr/hellorustc > > <https://github.com/extendr/hellorustc>>, which showcases how Rust > > >>>

Re: [Rd] R CMD check and CRAN's Rust policy

>>  > side-stepping `cargo` / crates.io     <http://crates.io> <http://crates.io <http://crates.io>> >     <http://crates.io <http://crates.io> <http://crates.io     <http://crates.io>>>, we are >      >>&g

Re: [Rd] Problems with ::

On 2025-03-19 12:49 p.m., Therneau, Terry M., Ph.D. via R-devel wrote: In response to the tidyverse habit of adding another zillion functions to one's search space, the use of things like survival::coxph is becoming more common. But this practice breaks the use of the specials argument in term

Re: [Rd] structure(, ...) is sticky: a bug, or should it be an error?

On Fri, Mar 21, 2025 at 8:55 AM Martin Maechler wrote: > > > Martin Maechler > > on Fri, 21 Mar 2025 14:49:16 +0100 writes: > > > Henrik Bengtsson > > on Thu, 20 Mar 2025 11:55:05 -0700 writes: > > >>> I'm pretty convinced we should fix it by checking for > >>> prim

Re: [Rd] Bad URLs in DESCRIPTION files

> Colin Gillespie writes: >> I'm surprised this wasn't captured by the url checker on CRAN. > As was I >> Are you suggesting a new check on package descriptions for the urls present? > Yes - but more fixing edge cases than a new check >> In that case I guess it could be part of the standard

Re: [Rd] Bad URLs in DESCRIPTION files

> I'm surprised this wasn't captured by the url checker on CRAN. As was I > Are you suggesting a new check on package descriptions for the urls present? Yes - but more fixing edge cases than a new check > In that case I guess it could be part of the standard R CMD check. Yep. Kurt's message sugg

[Rd] R Dev Day @ RSECon25, Fri 12 Sep, Warwick University - travel funding available!

Dear All, There will be another R Dev Day after RSECon25, on Friday 12 Sep, Warwick University, UK. Travel funding is available - for participants from UK/Europe, this will cover travel plus up to 2 nights accommodation and for participants from the Global South this will cover travel plus up

Re: [Rd] Bad URLs in DESCRIPTION files

Hi Colin, I'm surprised this wasn't captured by the url checker on CRAN. Are you suggesting a new check on package descriptions for the urls present? In that case I guess it could be part of the standard R CMD check. Lluís On Thu, 3 Apr 2025 at 17:17, Colin Gillespie wrote: > Hi All, > > Just

Re: [Rd] Proposal: Integrating Rust Toolchain into Rtools for Rust-Based R Package Development

Congratulations on figuring out how to extend the build of the Rtools installer to add more programs there - it is always good to have a confirmation such things are clear enough from the available documentation and sources. You can see that e.g. QPDF is added this way, but adding a toolchain r

Re: [Rd] Proposal: Integrating Rust Toolchain into Rtools for Rust-Based R Package Development

Hello, Wenjie. If you are specifically interested in Windows, Tomas Kalibera is the keeper of Rtools for Windows and it has its own list at R-sig-windows which may provide more focus. Thank you, Avi Sent from my iPhone > On Apr 3, 2025, at 7:30 AM, Sun Wenjie wrote: > > Dear R-devel com

[Rd] Proposal: Integrating Rust Toolchain into Rtools for Rust-Based R Package Development

Dear R-devel community, I'm exploring (experimentally) the integration of the Rust toolchain into Rtools, to enable smoother development and shipping of Rust-based R packages on Windows. I've written a detailed blog post documenting the process, technical rationale and what’s next: https://medi

[Rd] Enable compression in download.file()

Comparing download times of base R and the curl package: url <- 'https://jeroen.github.io/data/nycflights13.json' tmp <- tempfile() system.time(download.file(url, tmp, quiet = F) system.time(curl::curl_download(url, tmp, quiet = F)) Because this is an uncompressed file, the gzipped downlo

Re: [Rd] structure(, ...) is sticky: a bug, or should it be an error?

Thank you Martin - I've been following your commits to R-devel and R-beta. FWIW, I've just verified that it works as expected - I scanned the base environment for all primitive functions and then verified that attr(x, "abc") <- TRUE gives an error on R-devel; $ R --vanilla R Under development (uns

Re: [Rd] Suggestion: Install packages on non-appendable file systems (e.g. databricks volumes)

В Thu, 27 Mar 2025 13:26:47 +0100 Sergio Oller пишет: > Our current workaround kind of works, but when users expect to be able > to install packages > using renv or other tools that use install.packages to work; our > wrapper is not that convenient. Here's an idea that might help: since R CMD IN

Re: [Rd] R CMD check and CRAN's Rust policy

It is also pretty straightforward to roll your own actions and / or use different, simpler YAML setups. I still use a 'rolled forward and maintained by me now version' of the shell script many of us started with at Travis CI. It works, is portable across multiple CI backend, and is still a shell

Re: [Rd] R CMD check and CRAN's Rust policy

  robbing upstream authors of their download-numbers.     I do >     not think >      >>>      such policy is honourable. >      >>>  > >      >>>  > While C/C++ do not have official package     repositories,

Re: [Rd] R CMD check and CRAN's Rust policy

tp://crates.io>> >     <http://crates.io <http://crates.io> <http://crates.io     <http://crates.io>>>, we are >      >>>      robbing upstream authors of their download-numbers.     I do >     not think >      >>

Re: [Rd] R CMD check and CRAN's Rust policy

>>>> > >>> > it does seem very strange that we cannot get a >>>> reasonable >>>> > >>> dialogue going. >>>> > >>> > >>>>

Re: [Rd] R CMD check and CRAN's Rust policy

> To Tim's comment—the check is a simple grep of the installation log for > "Downloading crates." This could be easily circumvented on CRAN and locally > by suppressing stdout/err. But that would be adversarial and I would like > to adhere to the intent of the check. Josiah - I do sympathise but

Re: [Rd] R CMD check and CRAN's Rust policy

crates.io <http://crates.io>> >     <http://crates.io <http://crates.io> <http://crates.io <http://crates.io>>>, we are >      >>>      robbing upstream authors of their download-numbers. I do >     not think >      &

Re: [Rd] R CMD check and CRAN's Rust policy

s.io> <http://crates.io     <http://crates.io>>>, we are >      >>>      robbing upstream authors of their download-numbers.     I do >     not think >      >>>      such policy is honourable. >      >>>  > >

Re: [Rd] R CMD check and CRAN's Rust policy

n is already conveyed to the user. > >>> > > >>> > Personally, I do wish we could debate this requirement > further. I > >>> do not believe that having R-packages on CRAN vendor rust > >>> dependencies &

Re: [Rd] R CMD check and CRAN's Rust policy

<http://crates.io     <http://crates.io>>>, we are >      >>>      robbing upstream authors of their download-numbers.     I do >     not think >      >>>      such policy is honourable. >      >>>  > >      &

Re: [Rd] R CMD check and CRAN's Rust policy

t;http://crates.io>>, we are >>>      robbing upstream authors of their download-numbers. I do not think >>>      such policy is honourable. >>>  > >>>  > While C/C++ do not have official package repositories, it could

Re: [Rd] R CMD check and CRAN's Rust policy

On Mon, 31 Mar 2025, at 4:50 PM, Josiah Parry wrote: > Following up with this as I address the new R-devel "Compiled code should > not call entry points which might terminate R" WARNING and this issue has > reared its head again. > > Would a path forward be an environment variable similar > to _R_C

Re: [Rd] request for discussion on lonely doc patch suggestion

For Linux users, meld is quite nice for side by side editing, though I've never tried using it for display. Just checking now suggests it isn't obvious how to "print" side by side display. I've made meld easier for my own use by creating an icon in Double Commander (DC allows the user to creat

Re: [Rd] Suggestion: Install packages on non-appendable file systems (e.g. databricks volumes)

Hi Tomas, Thanks for your feedback and the link to your blog post about staged installs. Missatge de Tomas Kalibera del dia dc., 26 de març 2025 a les 21:34: > > > > I am working at a company, and we use R with databricks. We want to install > > some packages on a distributed filesystem that is

Re: [Rd] Suggestion: Install packages on non-appendable file systems (e.g. databricks volumes)

On 3/26/25 17:47, Sergio Oller wrote: Hello, I would like to submit a patch to R. Following 5 Submitting Feature Requests – R Development Guide , I would like to ask for feedback before proceeding with a ¿f

[Rd] Suggestion: Install packages on non-appendable file systems (e.g. databricks volumes)

Hello, I would like to submit a patch to R. Following 5 Submitting Feature Requests – R Development Guide , I would like to ask for feedback before proceeding with a ¿formal? submission on bugzilla. It's my fir

Re: [Rd] Why does NextMethod() pick up duplicate arguments in '...' if given positionally at top level?

Thanks Duncan! I filed [1]. I didn't have a clue how to fix it, so I figured, why not ask an LLM [2]. It got the solution quite wrong (unless I'm just not zen enough to understand its wisdom), but it _did_ focus my attention on the right place. I have a patch going through CI at [3] that fixes the

Re: [Rd] Patch for RJSONIO

Dirk points out via Jeroen Ooms that https://github.com/r-devel/r-svn-packages is a mirror of https://svn.r-project.org/R-packages/trunk/RJSONIO/ which is where the package really lives ... On Tue, Mar 25, 2025 at 8:10 PM Duncan Murdoch wrote: > > I think email to the maintainer is likely

Re: [Rd] Patch for RJSONIO

I think email to the maintainer is likely the only choice. The maintainer is "CRAN Team ". Duncan Murdoch On 2025-03-25 6:58 p.m., Ben Bolker wrote: Maybe https://github.com/duncantl/RJSONIO ? (That page also points to https://omegahat.org/RJSONIO, which is now defunct ...) On 3/25/25 18:5

Re: [Rd] Patch for RJSONIO

Maybe https://github.com/duncantl/RJSONIO ? (That page also points to https://omegahat.org/RJSONIO, which is now defunct ...) On 3/25/25 18:53, Dirk Eddelbuettel wrote: I can never remember where the canonical sources are for the effectively-CRAN maintained packages so I am dropping it here

  1   2   3   4   5   6   7   8   9   10   >