Re: [Rd] Breaking Change in Rcomplex Layout?

On 4/4/23 04:27, Michael Milton wrote: > Hi Tomas, > > Thanks for this explanation. As you can probably tell I'm not much of > a C person, so I didn't realise this change would be invisible to C > users. I suppose R's stability contract only applies to C, and > therefore changes that break oth

Re: [Rd] Breaking Change in Rcomplex Layout?

On Tue, 4 Apr 2023 09:31:33 +0200 Tomas Kalibera wrote: > it also matters how Rust can handle anonymous nested structures, or > what is the right mapping of the involved C types to Rust It's worth mentioning that Rust's RFC 2102 [1] defines unnamed structs and unions for the purpose of C interop

Re: [Rd] Breaking Change in Rcomplex Layout?

I don't think an auto-generated name (along the lines of u or u2) for the anonymous structs would be helpful here. You can see that bindgen is already generating a placeholder name ("__bindgen_anon_1"). A meaningful name might be nice instead, but I get the impression that isn't an option here sinc

Re: [Rd] Breaking Change in Rcomplex Layout?

On 4/4/23 11:27, Michael Milton wrote: > I don't think an auto-generated name (along the lines of u or u2) for > the anonymous structs would be helpful here. You can see that bindgen > is already generating a placeholder name ("__bindgen_anon_1"). A > meaningful name might be nice instead, but

[Rd] path to rtools not updated in R 4.2.3 - line 1: gcc: command not found

Dear listers, I have update to rtools43 and, using R 4.2.3 I have been surprised not to be able to compile packages needing compilation when updating. Looks like the path given in gcc  -I"C:/PROGRA~1/R/R-42~1.3/include" -DNDEBUG -DNTIMER -I./SuiteSparse_config -DUSE_FC_LEN_T -I"C:/rtools42/x8

Re: [Rd] path to rtools not updated in R 4.2.3 - line 1: gcc: command not found

On 4/5/23 07:48, Patrick Giraudoux wrote: Dear listers, I have update to rtools43 and, using R 4.2.3 I have been surprised not to be able to compile packages needing compilation when updating. Looks like the path given in gcc  -I"C:/PROGRA~1/R/R-42~1.3/include" -DNDEBUG -DNTIMER -I./SuiteSpa

Re: [Rd] removeSource() vs. function literals

Thanks for the comments and sorry I didn't reply sooner! On Thu, 30 Mar 2023 12:38:24 -0400 Duncan Murdoch wrote: > You'd need to recurse through all expressions in the object. Some of > those expressions might be environments, so your changes could leak > out of the function you're working on.