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
> > >>>
>> > 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
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
robbing upstream authors of their download-numbers.
I do
> not think
> >>> such policy is honourable.
> >>> >
> >>> > While C/C++ do not have official package
repositories,
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
> >>
>>>> > >>> > it does seem very strange that we cannot get a
>>>> reasonable
>>>> > >>> dialogue going.
>>>> > >>> >
>>>>
> 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
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
> &
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.
> >>> >
>
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
&
<http://crates.io
<http://crates.io>>>, we are
> >>> robbing upstream authors of their download-numbers.
I do
> not think
> >>> such policy is honourable.
> >>> >
> &
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
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
ired my end of the community for suggestions
> to compile a larger proposal, but then I was afraid that this
would be perceived as a big, bulky demand.
>
> Rust is not C/C++/Java, and the support for Rust cannot look like
the support for these languages.
>
&g
Mossa,
> On Mar 2, 2025, at 11:45 PM, Mossa Merhi Reimert wrote:
>
> There has been very little engagement with the issue I referred to. If it was
> decided that this “check” ought to be part of the default checks for R, then
> that could have been written to us. Either on the bugs.r-project.
demand.
>
> Rust is not C/C++/Java, and the support for Rust cannot look like
the support for these languages.
>
>
>
> From: Simon Urbanek
> Date: Sunday, 2 March 2025 at 00.39
> To: Mossa Merhi Reimert <mailto:mo...@sund.ku.dk
gt; to compile a larger proposal, but then I was afraid that this
would be perceived as a big, bulky demand.
>
> Rust is not C/C++/Java, and the support for Rust cannot look like
the support for these languages.
>
>
>
> From: Simon Urbanek
andom demands” comment, as this is not a
> demand, nor is it random.
> > I have inquired my end of the community for suggestions
> > to compile a larger proposal, but then I was afraid that this would be
> perceived as a big, bulky demand.
> >
> > Rust is not C/C++
h, before embarking on a larger discussion.
> > I do not appreciate the “random demands” comment, as this is not a
> demand, nor is it random.
> > I have inquired my end of the community for suggestions
> > to compile a larger proposal, but then I was afraid that this would be
> p
fraid that this would be
perceived as a big, bulky demand.
Rust is not C/C++/Java, and the support for Rust cannot look like the support
for these languages.
From: Simon Urbanek
Date: Sunday, 2 March 2025 at 00.39
To: Mossa Merhi Reimert
Cc: r-devel@r-project.org
Subject: Re: [Rd] R CMD c
Urbanek
Date: Sunday, 2 March 2025 at 00.39
To: Mossa Merhi Reimert
Cc: r-devel@r-project.org
Subject: Re: [Rd] R CMD check and CRAN's Rust policy
[Du får ikke ofte mails fra simon.urba...@r-project.org. Få mere at vide om,
hvorfor dette er vigtigt, på https://a
Mossa,
the issue you cite is lacking any pertinent information and it's not even clear
why it should be an issue. The check is perfectly justified, it just reports
whether a package using rust declares this correctly and where it downloads 3rd
party content - something that is important to R us
Hello everyone!
I'm Mossa, I'm one of the maintainers of extendr, an automated generation of
bindings project for
Rust code, for use in R-packages.
I'm writing to you, as R 4.4.3 was just released, and there have not been
follow-up on an issue important to us. Link to the issue as discussed on r
Thank you, Tomas, for the clarification!
On Sun, Oct 13, 2024 at 14:59 Tomas Kalibera
wrote:
> On 10/13/24 19:30, Josiah Parry wrote:
> > Hi all,
> >
> > I'm new to contributing to r-devel. The trunk of r-devel right now
> includes
> > a `check_rust()` function for adherence to CRAN's evolving r
On 10/13/24 19:30, Josiah Parry wrote:
Hi all,
I'm new to contributing to r-devel. The trunk of r-devel right now includes
a `check_rust()` function for adherence to CRAN's evolving rust policy (see
commit
https://github.com/r-devel/r-svn/commit/6114d4126434c056b476cbc5db2657536c153d9a
).
As it
Hi all,
I'm new to contributing to r-devel. The trunk of r-devel right now includes
a `check_rust()` function for adherence to CRAN's evolving rust policy (see
commit
https://github.com/r-devel/r-svn/commit/6114d4126434c056b476cbc5db2657536c153d9a
).
As it stands R 4.4.2 will codify CRAN policy o
26 matches
Mail list logo
