Re: [Rd] Help with resolving non-API call warnings in Rust-based packages (ymd and fcl)
Brilliant! On Mon, Apr 14, 2025 at 22:49 谭显英 wrote: > 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 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" 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 most of these issues by upgrading to "extendr 0.8.0". >> When testing with R-win-devel, the packages pass all checks. However, >> upon submission to CRAN, I'm facing a confusing situation: the packages >> pass checks on Windows but fail on Debian with the following warning: >> >> >> * checking compiled code ... WARNING >> File 'ymd/libs/ymd.so': >> Found '_exit', possibly from '_exit' (C) >> Object: 'rust/target/release/libymd.a' >> Found 'abort', possibly from 'abort' (C) >> Object: 'rust/target/release/libymd.a' >> Found 'exit', possibly from 'exit' (C) >> Object: 'rust/target/release/libymd.a' >> >> >> I'm not sure if this is still an issue with extendr or if it's a false >> warning. I'm particularly puzzled by the discrepancy between Windows and >> Debian check results. >> >> >> Is there an easy way to check against the Debian win-devel server before >> resubmitting to ensure these issues are fixed? >> >> >> For reference, here's the relevant excerpt from CRAN's automated email: >> >> >> package ymd_0.1.5.tar.gz does not pass the incoming checks automatically, >> please see the following pre-tests (additional issue checks): >> Windows: >> https://win-builder.r-project.org/incoming_pretest/ymd_0.1.5_20250414_114928/Windows/00check.log >> Status: OK >> Debian: >> https://win-builder.r-project.org/incoming_pretest/ymd_0.1.5_20250414_114928/Debian/00check.log >> Status: 1 WARNING >> >> >> Any insights or suggestions would be greatly appreciated. >> >> >> Best regards, >> Xianying Tan (shrektan) >> [[alternative HTML version deleted]] >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
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 namespacing specials is a bad idea. But I'm afraid that the mistake with specials happens much more often than I'd like. I find examples in the reverse dependencies for survival of 3 different errors, all of which give code that runs without an error message, but with the wrong result. Since I have a strong interest in correct results from medical research, I've tried to think about ways to protest the user from themselves. The errors are a. using survival::strata(group) in a formula. This is not recognized as a special. b. the package had zed <- strata(group), then used +zed in multiple formulas. c. formula was preprocessed (I don't remember the detail exactly here, and I expect this is rare) In all three cases the final fit was the same as if they used factor(group). I expect that (a) and (b) are quite prevalent in user code, the second due to all the tutorials that like to create a new variable zed <- Surv(time, status) and then use 'zed' in the formulas, people will do the same with strata. (I don't like this approach in general; you've saved a tiny bit of typing to create fits that are less clearly documented.) When reading one of my colleagues grants, before submission, I often try to actively try to put on a "pretend I don't know this topic deeply" persona, so as to note passages where other readers might go wrong, e.g., completely misunderstand a sentence. I'm trying to think about specials with a bit of that bias as well, when might a naive but well meaning user go wrong? Is there something fairly simple I could do in the package coding to avert it? I'm thinking that the only solution to (b) above will be to have strata return a classed object and key on the class rather depend on specials. It will be a lot of busywork to implement though. I have no particular votes for against the proposed change: I have a general opinion that those who insist on using non-syntactic names have fallen into a pit that they dug themselves, and little sympathy for their plight. Terry T On 4/15/25 03:17, peter dalgaard wrote: > 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 issue, then having to undo that for the > actual use. > > It all came about by someone (I have forgotten the details) having a > corporate coding standard mandating namespaces on all function calls and > falling over things like strata() in the survival package. Then package > author(s) chose to comply rather than explain... > > -pd [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
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 issue, then
having to undo that for the actual use.
It all came about by someone (I have forgotten the details) having a corporate
coding standard mandating namespaces on all function calls and falling over
things like strata() in the survival package. Then package author(s) chose to
comply rather than explain...
-pd
> On 14 Apr 2025, at 23.49, Ben Bolker wrote:
>
> 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 functionality here.
>
> Mikael showed how I could use the *new* functionality instead:
>
> https://github.com/bbolker/reformulas/issues/4
>
> but honestly if I were going to change things in `reformulas` it would be in
> the direction of streamlining and refactoring, not changing the basic
> approach.
>
> cheers
> Ben Bolker
>
>
> On 2025-04-14 5:43 p.m., Mikael Jagan wrote:
>> [CC: maintainers of R packages survival, mgcv, lme4, RItools]
>> Dear R-devel subscribers,
>> If you have never used stats:::terms.formula or its 'specials' argument,
>> then feel free to stop reading or otherwise review help("terms.formula")
>> and help("terms.object").
>> Folks may have noticed a recent change in R-devel:
>> $ svn log -v -r 88066
>>
>> r88066 | maechler | 2025-03-28 17:04:27 -0400 (Fri, 28 Mar 2025) | 1 line
>> Changed paths:
>>M /trunk/doc/NEWS.Rd
>>M /trunk/src/library/stats/src/model.c
>>M /trunk/tests/reg-tests-1e.R
>> terms(, specials = "") now works
>>
>> intended to resolve Bug 18568
>> https://bugs.r-project.org/show_bug.cgi?id=18568
>> which pointed out the following undesirable behaviour in R-release:
>> > attr(terms(~x1 + s (x2, f) + s (x3, g), specials = "s"), "specials")
>> $s
>> [1] 2 3
>> > attr(terms(~x1 + `|`(x2, f) + `|`(x3, g), specials = "|"), "specials")
>> $`|`
>> NULL
>> namely that non-syntactic names like "|" were not supported. Unfortunately,
>> the patch (r88066) broke one package on CRAN, RItools, which relied on the
>> following
>> > attr(terms(~x1 + mgcv::s (x2, f), specials = "mgcv::s"), "specials")
>> $`mgcv::s`
>> [1] 2
>> > attr(terms(~x1 + `mgcv::s`(x2, f), specials = "mgcv::s"), "specials")
>> $`mgcv::s`
>> NULL
>> whereas in R-devel we see
>> > attr(terms(~x1 + mgcv::s (x2, f), specials = "mgcv::s"), "specials")
>> $`mgcv::s`
>> NULL
>> > attr(terms(~x1 + `mgcv::s`(x2, f), specials = "mgcv::s"), "specials")
>> $`mgcv::s`
>> [1] 2
>> A strict interpretation of 'specials' as a list of *name*s of functions would
>> suggest that the old behaviour was "wrong" (and accidental, predating package
>> namespaces altogether) and that the new behaviour is "right". After all,
>> `mgcv::s` (with backticks) is a name (of type "symbol", class "name") whereas
>> mgcv::s (without backticks) is a call (of type "language", class "call").
>> Martin and I are requesting comments from the community, especially R-core
>> members and package authors who use 'specials', on the following:
>> 1. Should the previous (long standing but undocumented, likely rarely
>> used)
>>behaviour be preserved going forward?
>> 2. If we pursue a more *robust* implementation of namespace resolution by
>>stats:::terms.formula, not relying on details of how non- syntactic
>> names
>>are deparsed, then what should that look like?
>> (I say "likely rarely used" because stats:::terms.formula is called
>> primarily by
>> package *authors* to parse formulas of package *users*. Only a subset of
>> those
>> packages will set 'specials', only a subset of *those* packages will set
>> specials="::", and only one such package is known to be broken
>> due
>> to r88066.)
>> Relevant to (2) is an earlier thread
>> https://stat.ethz.ch/pipermail/r-devel/2025-March/083906.html
>> in which I proposed that we make use of an optional 'package' attribute of
>> 'specials', so that
>> specials = structure(c("s", "s"), package = c("", "mgcv"))
>> would match calls s(...) and mgcv::s(...) separately. This attribute would
>> be
>> preserved by the 'specials' component of the 'terms' object, e.g.,
>> > attr(terms(~x1 + s(x2, f) + mgcv::s(x3, g),
>> +specials = structure(c("s", "s"), package = c("", "mgcv"))),
>> + "specia
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 related to your issue. Best, Kasper On Mon, Apr 14, 2025 at 9:42 AM Ivan Krylov via R-devel < r-devel@r-project.org> wrote: > 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 somewhere above in the log? I think it's not being > correctly linked with libicu, but since shared libraries are allowed to > have undefined imports in them, this is only found out later, when > linking the R.bin executable. > > > It seems that the libcurl package in conda provides the curl-config > > command line program, which R is using to get this flag: > > -I/home/local/USHERBROOKE/hoct2726/miniconda3/include > > With libcurl installed from conda, what do the following commands print? > > curl-config --built-shared > curl-config --static-libs > curl-config --libs > > > To fix the build, I did "conda remove libcurl" and then "make clean" > > and then "configure" and "make" worked. > > It should also be possible to override the path to curl-config using > the CURL_CONFIG environment variable. > > -- > Best regards, > Ivan > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Best, Kasper [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
