Re: [Rd] vector arithmetic

[Hiroaki Yutani]

I've been wondering this, too! Following the codes in arithmetic.c, I've
finally reached MOD_ITERATE2_CORE macro in src/include/R_ext/Itermacros.h.
Is this the place?

Best

2018年8月14日(火) 2:59 isomorphismes :

> I'm looking for where in the source recycling and vector
> multiplication+addition are defined. I see some stuff in
> ~/src/main/arithmetic.c.
>
> Is there anywhere else I should be looking as well?
>
> Cheers
>
> --
> isomorphi...@sdf.org
> SDF Public Access UNIX System - http://sdf.org
>
> __
> 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] New pipe operator

[Hiroaki Yutani]

>  Error: function '::' not supported in RHS call of a pipe

To me, this error looks much more friendly than magrittr's error.
Some of them got too used to specify functions without (). This
is OK until they use `::`, but when they need to use it, it takes
hours to figure out why

mtcars %>% base::head
#> Error in .::base : unused argument (head)

won't work but

mtcars %>% head

works. I think this is a too harsh lesson for ordinary R users to
learn `::` is a function. I've been wanting for magrittr to drop the
support for a function name without () to avoid this confusion,
so I would very much welcome the new pipe operator's behavior.
Thank you all the developers who implemented this!

Best,
Hiroaki Yutani

2020年12月4日(金) 20:51 Duncan Murdoch :
>
> Just saw this on the R-devel news:
>
>
> R now provides a simple native pipe syntax ‘|>’ as well as a shorthand
> notation for creating functions, e.g. ‘\(x) x + 1’ is parsed as
> ‘function(x) x + 1’. The pipe implementation as a syntax transformation
> was motivated by suggestions from Jim Hester and Lionel Henry. These
> features are experimental and may change prior to release.
>
>
> This is a good addition; by using "|>" instead of "%>%" there should be
> a chance to get operator precedence right.  That said, the ?Syntax help
> topic hasn't been updated, so I'm not sure where it fits in.
>
> There are some choices that take a little getting used to:
>
>  > mtcars |> head
> Error: The pipe operator requires a function call or an anonymous
> function expression as RHS
>
> (I need to say mtcars |> head() instead.)  This sometimes leads to error
> messages that are somewhat confusing:
>
>  > mtcars |> magrittr::debug_pipe |> head
> Error: function '::' not supported in RHS call of a pipe
>
> but
>
> mtcars |> magrittr::debug_pipe() |> head()
>
> works.
>
> Overall, I think this is a great addition, though it's going to be
> disruptive for a while.
>
> Duncan Murdoch
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] New pipe operator

[Hiroaki Yutani]

It is common practice to call |> as pipe (or pipeline operator) among
many languages
including ones that recently introduced it as an experimental feature.
Pipeline is a
common feature for functional programming, not just for "data pipeline."

F#: 
https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/symbol-and-operator-reference/
Elixir: https://hexdocs.pm/elixir/operators.html#general-operators
Typescript:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Pipeline_operator
Ruby: https://bugs.ruby-lang.org/issues/15799

(This blog post about the history of pipe operator might be
interesting: 
https://mamememo.blogspot.com/2019/06/a-brief-history-of-pipeline-operator.html
)

I agree this is a bit confusing for those who are familiar with other
"pipe" concepts,
but there's no other appropriate term to call |>.

2020年12月6日(日) 12:22 Gregory Warnes :
>
> If we’re being mathematically pedantic, the “pipe” operator is actually
> function composition.
>
> That being said, pipes are a simple and well-known idiom. While being less
> than mathematically exact, it seems a reasonable   label for the (very
> useful) behavior.
>
> On Sat, Dec 5, 2020 at 9:43 PM Abby Spurdle  wrote:
>
> > > This is a good addition
> >
> > I can't understand why so many people are calling this a "pipe".
> > Pipes connect processes, via their I/O streams.
> > Arguably, a more general interpretation would include sockets and files.
> >
> > https://en.wikipedia.org/wiki/Pipeline_(Unix)
> > https://en.wikipedia.org/wiki/Named_pipe
> > https://en.wikipedia.org/wiki/Anonymous_pipe
> >
> > As far as I can tell, the magrittr-like operators are functions (not
> > pipes), with nonstandard syntax.
> > This is not consistent with R's original design philosophy, building
> > on C, Lisp and S, along with lots of *important* math and stats.
> >
> > It's possible that some parties are interested in creating a kind of
> > "data pipeline".
> > I'm interested in this myself, and I think we could discuss this more.
> > But I'm not convinced the magrittr-like operators help to achieve this
> > goal.
> > Which, in my opinion, would require one to model programs as directed
> > graphs, along with some degree of asynchronous input.
> >
> > Presumably, these operators will be added to R anyway, and (almost) no
> > one will listen to me.
> >
> > So, I would like to make one suggestion:
> > Is it possible for these operators to *not* be named:
> > The R Pipe
> > The S Pipe
> > Or anything with a similar meaning.
> >
> > Maybe tidy pipe, or something else that links it to its proponents?
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> --
> "Whereas true religion and good morals are the only solid foundations of
> public liberty and happiness . . . it is hereby earnestly recommended to
> the several States to take the most effectual measures for the
> encouragement thereof." Continental Congress, 1778
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

[Rd] issue with print()ing multibyte characters on R 4.0.4

[Hiroaki Yutani]

Hi all,

I saw several people on Japanese locale claim that, on R 4.0.4,
print() doesn't display
Japanese characters correctly. This seems to happen only on Windows
and on macOS (I
usually use Linux and I don't see this problem).

For example, in the result below, "鬼" and "外" are displayed in
"\u" format. What's
curious here is that "は" is displayed as it is, by the way.

> "鬼は外"
[1] "\u9b3cは\u5916"

But, if I use such functions as message() or cat(), the string is
displayed as it is.

> message("鬼は外")
鬼は外

Considering the fact that it seems only Windows and macOS are
affected, I suspect this
is somehow related to this change described in the release note,
(though I have no idea
what change this is):

The internal table for iswprint (used on Windows, macOS and AIX) has been
updated to include many recent Unicode characters.
(https://cran.r-project.org/doc/manuals/r-release/NEWS.html)

Before I'm going to file this issue on Bugzilla, I'd like to confirm
if this is not the intended
change, and, if this is actually intended, I want to discuss how to
improve this behaviour.

Best,
Hiroaki Yutani

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

Re: [Rd] issue with print()ing multibyte characters on R 4.0.4

[Hiroaki Yutani]

Thanks for confirming and investigating.

> but it was no one reported in the run up to 4.0.4.

Yes, it was unfortunate that no one had reported it to the right place
before the release...

2021年2月17日(水) 19:20 Prof Brian Ripley :

>
> On 17/02/2021 04:58, Hiroaki Yutani wrote:
> > Hi all,
> >
> > I saw several people on Japanese locale claim that, on R 4.0.4,
> > print() doesn't display
> > Japanese characters correctly. This seems to happen only on Windows
> > and on macOS (I
> > usually use Linux and I don't see this problem).
> >
> > For example, in the result below, "鬼" and "外" are displayed in
> > "\u" format. What's
> > curious here is that "は" is displayed as it is, by the way.
> >
> >> "鬼は外"
> > [1] "\u9b3cは\u5916"
> >
> > But, if I use such functions as message() or cat(), the string is
> > displayed as it is.
> >
> >> message("鬼は外")
> > 鬼は外
>
> that does not escape non-printable characters, so as expected.
> >
> > Considering the fact that it seems only Windows and macOS are
> > affected, I suspect this
> > is somehow related to this change described in the release note,
> > (though I have no idea
> > what change this is):
> >
> >  The internal table for iswprint (used on Windows, macOS and AIX) has 
> > been
> >  updated to include many recent Unicode characters.
> >  (https://cran.r-project.org/doc/manuals/r-release/NEWS.html)
> >
> > Before I'm going to file this issue on Bugzilla, I'd like to confirm
> > if this is not the intended
> > change, and, if this is actually intended, I want to discuss how to
> > improve this behaviour.
>
> I am sorry: this was not intended but it was no one reported in the run
> up to 4.0.4.  It seems to be working in R-devel so I suggest you check
> that or go back to 4.0.3.
>
> It looks like a line in the iswprint table got deleted in the merge from
> R-devel.  I will try to set up some automated checks to see if I can
> find any other problems, but that will take a few days.
>
> --
> Brian D. Ripley,  rip...@stats.ox.ac.uk
> Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [Rd] issue with print()ing multibyte characters on R 4.0.4

[Hiroaki Yutani]

I filed an issue for this on R's Bugzilla as well, in case this makes
it easier to track (This is my first time to submit a bug report,
please excuse me if I'm failing to follow the appropriate steps to do
this).

https://bugs.r-project.org/bugzilla/show_bug.cgi?id=18059

2021年2月17日(水) 22:47 Hiroaki Yutani :
>
> Thanks for confirming and investigating.
>
> > but it was no one reported in the run up to 4.0.4.
>
> Yes, it was unfortunate that no one had reported it to the right place
> before the release...
>
> 2021年2月17日(水) 19:20 Prof Brian Ripley :
>
> >
> > On 17/02/2021 04:58, Hiroaki Yutani wrote:
> > > Hi all,
> > >
> > > I saw several people on Japanese locale claim that, on R 4.0.4,
> > > print() doesn't display
> > > Japanese characters correctly. This seems to happen only on Windows
> > > and on macOS (I
> > > usually use Linux and I don't see this problem).
> > >
> > > For example, in the result below, "鬼" and "外" are displayed in
> > > "\u" format. What's
> > > curious here is that "は" is displayed as it is, by the way.
> > >
> > >> "鬼は外"
> > > [1] "\u9b3cは\u5916"
> > >
> > > But, if I use such functions as message() or cat(), the string is
> > > displayed as it is.
> > >
> > >> message("鬼は外")
> > > 鬼は外
> >
> > that does not escape non-printable characters, so as expected.
> > >
> > > Considering the fact that it seems only Windows and macOS are
> > > affected, I suspect this
> > > is somehow related to this change described in the release note,
> > > (though I have no idea
> > > what change this is):
> > >
> > >  The internal table for iswprint (used on Windows, macOS and AIX) has 
> > > been
> > >  updated to include many recent Unicode characters.
> > >  (https://cran.r-project.org/doc/manuals/r-release/NEWS.html)
> > >
> > > Before I'm going to file this issue on Bugzilla, I'd like to confirm
> > > if this is not the intended
> > > change, and, if this is actually intended, I want to discuss how to
> > > improve this behaviour.
> >
> > I am sorry: this was not intended but it was no one reported in the run
> > up to 4.0.4.  It seems to be working in R-devel so I suggest you check
> > that or go back to 4.0.3.
> >
> > It looks like a line in the iswprint table got deleted in the merge from
> > R-devel.  I will try to set up some automated checks to see if I can
> > find any other problems, but that will take a few days.
> >
> > --
> > Brian D. Ripley,  rip...@stats.ox.ac.uk
> > Emeritus Professor of Applied Statistics, University of Oxford

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

[Rd] Detect UCRT-built R from within R sessions (and in configure.win)

[Hiroaki Yutani]

Hi,

Are there any proper ways to know whether the session is running on
the R that is built with the UCRT toolchain or not? Checking if the
encoding is UTF-8 might do the trick, but I'm not sure if it's always
reliable.

Also, I'd like to know if there's any mechanism to detect the UCRT in
configure.win. I know there are Makevars.ucrt and Makefile.ucrt, but
one might want to do some feature test that is specific to the UCRT
toolchain.

Best,
Hiroaki Yutani

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

Re: [Rd] Detect UCRT-built R from within R sessions (and in configure.win)

[Hiroaki Yutani]

Thank you for the prompt reply.

> There in not such a mechanism, yet, but can be added, at least for
> diagnostics.

For example, can R.version somehow contain the information?

> We could add support for configure.ucrt, which would take precedence
> over configure.win on the UCRT builds (like Makevars.ucrt takes
> precedence over Makevars.win). Would that work for you?

Yes, configure.ucrt should work for me. There might be someone who prefers
to switch by some envvar rather than creating another file, but I don't
have a strong opinion here.

Best,
Hiroaki Yutani

2021年9月9日(木) 0:48 Tomas Kalibera :

>
> On 9/8/21 2:08 PM, Hiroaki Yutani wrote:
> > Hi,
> >
> > Are there any proper ways to know whether the session is running on
> > the R that is built with the UCRT toolchain or not? Checking if the
> > encoding is UTF-8 might do the trick, but I'm not sure if it's always
> > reliable.
>
> There in not such a mechanism, yet, but can be added, at least for
> diagnostics.
>
> You are right that checking for UTF-8 encoding would not always be
> reliable. For example, the version of Windows may be too old to allow R
> use UTF-8 as native encoding (e.g. Windows server 2016), then R will use
> the native code page as it does today in the MSVCRT builds.
>
> > Also, I'd like to know if there's any mechanism to detect the UCRT in
> > configure.win. I know there are Makevars.ucrt and Makefile.ucrt, but
> > one might want to do some feature test that is specific to the UCRT
> > toolchain.
>
> We could add support for configure.ucrt, which would take precedence
> over configure.win on the UCRT builds (like Makevars.ucrt takes
> precedence over Makevars.win). Would that work for you?
>
> Best
> Tomas
>
> >
> > Best,
> > Hiroaki Yutani
> >
> > __
> > 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] Detect UCRT-built R from within R sessions (and in configure.win)

[Hiroaki Yutani]

Thanks for both, I'll try these features.

2021年9月14日(火) 22:40 Tomas Kalibera :

>
>
> On 9/9/21 5:54 AM, Hiroaki Yutani wrote:
>
> Thank you for the prompt reply.
>
> > There in not such a mechanism, yet, but can be added, at least for
> > diagnostics.
>
> For example, can R.version somehow contain the information?
>
> Yes, now added to the experimental builds. R.version$crt contains "ucrt" (and 
> would contain "msvcrt" if R was built against MSVCRT).
>
>
> > We could add support for configure.ucrt, which would take precedence
> > over configure.win on the UCRT builds (like Makevars.ucrt takes
> > precedence over Makevars.win). Would that work for you?
>
> Yes, configure.ucrt should work for me. There might be someone who prefers to 
> switch by some envvar rather than creating another file, but I don't have a 
> strong opinion here.
>
> The experimental builds now support configure.ucrt and cleanup.ucrt files.
>
> Best
> Tomas
>
>
> Best,
> Hiroaki Yutani
>
> 2021年9月9日(木) 0:48 Tomas Kalibera :
>>
>>
>> On 9/8/21 2:08 PM, Hiroaki Yutani wrote:
>> > Hi,
>> >
>> > Are there any proper ways to know whether the session is running on
>> > the R that is built with the UCRT toolchain or not? Checking if the
>> > encoding is UTF-8 might do the trick, but I'm not sure if it's always
>> > reliable.
>>
>> There in not such a mechanism, yet, but can be added, at least for
>> diagnostics.
>>
>> You are right that checking for UTF-8 encoding would not always be
>> reliable. For example, the version of Windows may be too old to allow R
>> use UTF-8 as native encoding (e.g. Windows server 2016), then R will use
>> the native code page as it does today in the MSVCRT builds.
>>
>> > Also, I'd like to know if there's any mechanism to detect the UCRT in
>> > configure.win. I know there are Makevars.ucrt and Makefile.ucrt, but
>> > one might want to do some feature test that is specific to the UCRT
>> > toolchain.
>>
>> We could add support for configure.ucrt, which would take precedence
>> over configure.win on the UCRT builds (like Makevars.ucrt takes
>> precedence over Makevars.win). Would that work for you?
>>
>> Best
>> Tomas
>>
>> >
>> > Best,
>> > Hiroaki Yutani
>> >
>> > __
>> > R-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] Detect UCRT-built R from within R sessions (and in configure.win)

[Hiroaki Yutani]

I tried to use configure.ucrt, and found it results in the following
NOTE on the released version of R, unfortunately.

* checking top-level files ... NOTE
Non-standard file/directory found at top level:
'configure.ucrt'

Will this be accepted by CRAN if I submit a package that contains
configure.ucrt? Or, is it too early to use it in a CRAN package?

In either case, while I don't have a strong opinion here, I'm starting
to feel that it might be preferable to provide an environmental
variable rather than creating ".ucrt" versions of files. In my
understanding, the plan is to switch all the Windows R to UCRT at some
point in future. But, it's not clear to me how to unify these ".win"
files and ".ucrt" files smoothly.

Best,
Hiroaki Yutani

2021年9月14日(火) 23:44 Hiroaki Yutani :

>
> Thanks for both, I'll try these features.
>
> 2021年9月14日(火) 22:40 Tomas Kalibera :
>
> >
> >
> > On 9/9/21 5:54 AM, Hiroaki Yutani wrote:
> >
> > Thank you for the prompt reply.
> >
> > > There in not such a mechanism, yet, but can be added, at least for
> > > diagnostics.
> >
> > For example, can R.version somehow contain the information?
> >
> > Yes, now added to the experimental builds. R.version$crt contains "ucrt" 
> > (and would contain "msvcrt" if R was built against MSVCRT).
> >
> >
> > > We could add support for configure.ucrt, which would take precedence
> > > over configure.win on the UCRT builds (like Makevars.ucrt takes
> > > precedence over Makevars.win). Would that work for you?
> >
> > Yes, configure.ucrt should work for me. There might be someone who prefers 
> > to switch by some envvar rather than creating another file, but I don't 
> > have a strong opinion here.
> >
> > The experimental builds now support configure.ucrt and cleanup.ucrt files.
> >
> > Best
> > Tomas
> >
> >
> > Best,
> > Hiroaki Yutani
> >
> > 2021年9月9日(木) 0:48 Tomas Kalibera :
> >>
> >>
> >> On 9/8/21 2:08 PM, Hiroaki Yutani wrote:
> >> > Hi,
> >> >
> >> > Are there any proper ways to know whether the session is running on
> >> > the R that is built with the UCRT toolchain or not? Checking if the
> >> > encoding is UTF-8 might do the trick, but I'm not sure if it's always
> >> > reliable.
> >>
> >> There in not such a mechanism, yet, but can be added, at least for
> >> diagnostics.
> >>
> >> You are right that checking for UTF-8 encoding would not always be
> >> reliable. For example, the version of Windows may be too old to allow R
> >> use UTF-8 as native encoding (e.g. Windows server 2016), then R will use
> >> the native code page as it does today in the MSVCRT builds.
> >>
> >> > Also, I'd like to know if there's any mechanism to detect the UCRT in
> >> > configure.win. I know there are Makevars.ucrt and Makefile.ucrt, but
> >> > one might want to do some feature test that is specific to the UCRT
> >> > toolchain.
> >>
> >> We could add support for configure.ucrt, which would take precedence
> >> over configure.win on the UCRT builds (like Makevars.ucrt takes
> >> precedence over Makevars.win). Would that work for you?
> >>
> >> Best
> >> Tomas
> >>
> >> >
> >> > Best,
> >> > Hiroaki Yutani
> >> >
> >> > __
> >> > R-devel@r-project.org mailing list
> >> > https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] Detect UCRT-built R from within R sessions (and in configure.win)

[Hiroaki Yutani]

> Thanks, that's right, so I've ported this part to R-devel and R-patched,

I noticed R-devel no longer complains about this from a while ago, thanks.

> With R.version$crt, you can already get a make (or even environment)
> variable. Writing R Extensions has examples how to invoke R in make
> files to get "R CMD config" values, so here you would invoke "Rscript"
> instead with one of the conditions above.

This slipped my mind, thanks for pointing it out! Yes, this works
perfectly without configure.ucrt. I will stick with this at least for
a while until the next version of R gets released.

> ... The .ucrt
> files are easier to maintain in hot-patches, but that is not an
> advantage for package authors.

I see, I think now I get your point. So, even if all the package
authors would choose to use the Rscript way, the .ucrt files would be
still needed to make room for the (R? or CRAN?) maintainers to
hot-patch the packages that don't work on UCRT nicely. Thanks for all
the efforts to make the UCRT R a reality.

Best,
Hiroaki Yutani

2021年9月24日(金) 2:16 Tomas Kalibera :


>
>
> On 9/20/21 11:03 AM, Hiroaki Yutani wrote:
> > I tried to use configure.ucrt, and found it results in the following
> > NOTE on the released version of R, unfortunately.
> >
> >  * checking top-level files ... NOTE
> >  Non-standard file/directory found at top level:
> >  'configure.ucrt'
> >
> > Will this be accepted by CRAN if I submit a package that contains
> > configure.ucrt? Or, is it too early to use it in a CRAN package?
>
> Thanks, that's right, so I've ported this part to R-devel and R-patched,
> configure.ucrt and cleanup.ucrt will be treated as "standard". There is
> nothing we can do about already released versions, the NOTE will appear.
>
> You can also use configure.win and branch on R.version$crt, e.g.
>
> !is.null(R.version$crt) && R.version$crt == "ucrt"
>
> or
>
> identical(R.version$crt, "ucrt")
>
> > In either case, while I don't have a strong opinion here, I'm starting
> > to feel that it might be preferable to provide an environmental
> > variable rather than creating ".ucrt" versions of files. In my
> > understanding, the plan is to switch all the Windows R to UCRT at some
> > point in future. But, it's not clear to me how to unify these ".win"
> > files and ".ucrt" files smoothly.
>
> With R.version$crt, you can already get a make (or even environment)
> variable. Writing R Extensions has examples how to invoke R in make
> files to get "R CMD config" values, so here you would invoke "Rscript"
> instead with one of the conditions above.
>
> Either is fine. With .ucrt files, you can avoid copy pasting of common
> code using "include" directives. With the variable, you can use make
> conditionals. As you found now, with the variable you have the advantage
> of not getting a NOTE with already released versions of R. The .ucrt
> files are easier to maintain in hot-patches, but that is not an
> advantage for package authors.
>
> Once a package depends on a version of R that will already use UCRT, one
> either would refactor/remove the conditionals, or integrate the ".ucrt"
> files back into the ".win". So, in the long term, there should be no
> conditionals on R.version$crt nor ".ucrt" files.
>
> Best
> Tomas
> > Best,
> > Hiroaki Yutani
> >
> > 2021年9月14日(火) 23:44 Hiroaki Yutani :
> >
> >> Thanks for both, I'll try these features.
> >>
> >> 2021年9月14日(火) 22:40 Tomas Kalibera :
> >>
> >>>
> >>> On 9/9/21 5:54 AM, Hiroaki Yutani wrote:
> >>>
> >>> Thank you for the prompt reply.
> >>>
> >>>> There in not such a mechanism, yet, but can be added, at least for
> >>>> diagnostics.
> >>> For example, can R.version somehow contain the information?
> >>>
> >>> Yes, now added to the experimental builds. R.version$crt contains "ucrt" 
> >>> (and would contain "msvcrt" if R was built against MSVCRT).
> >>>
> >>>
> >>>> We could add support for configure.ucrt, which would take precedence
> >>>> over configure.win on the UCRT builds (like Makevars.ucrt takes
> >>>> precedence over Makevars.win). Would that work for you?
> >>> Yes, configure.ucrt should work for me. There might be someone who 
> >>> prefers to switch by some envvar rather than creating another file, but I 
>

[Rd] R on Windows with UCRT and the system encoding

[Hiroaki Yutani]

Hi,

I'm more than excited about the announcement about the upcoming UTF-8
R on Windows. Let me confirm my understanding. Is R 4.2 supposed to
work on Windows with non-UTF-8 encoding as the system locale? I think
this blog post indicates so (as this describes the older Windows than
the UTF-8 era), but I'm not fully confident if I understand the
details correctly.

https://developer.r-project.org/Blog/public/2021/12/07/upcoming-changes-in-r-4.2-on-windows/index.html

If so, I'm curious what the package authors should do when the locales
are different between OS and R. For example (disclaimer: I don't
intend to blame processx at all. Just for an example), the CRAN check
on the processx package currently fails with this warning on R-devel
Windows.

> 1. UTF-8 in stdout (test-utf8.R:85:3) - Invalid multi-byte character at 
> end of stream ignored
https://cran.r-project.org/web/checks/check_results_processx.html

As far as I know, processx launches an external process and captures
its output, and I suspect the problem is that the output of the
process is encoded in non-UTF-8 while R assumes it's UTF-8. I
experienced similar problems with other packages as well, which
disappear if I switch the locale to the same one as the OS by
Sys.setlocale(). So, I think it would be great if there's some
guidance for the package authors on how to handle these properly.

Any suggestions?

Best,
Yutani

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

Re: [Rd] R on Windows with UCRT and the system encoding

[Hiroaki Yutani]

Hi Tomas,

Thank you very much for the detailed explanation! I think now I have a
bit better understanding on how the things work; at least now I know I
didn't understand the concept of "active code page". I'll follow your
advice when I need to fix the packages that need some tweaks to handle
UTF-8 properly.

Sorry, I'd like to ask one more question related to locale. If I copy
the following text and execute `read.csv("clipboard")`, it returns
"uao" instead of "úáö" (the characters are transliterated).

"col1","col2"
"úáö","úáö"


While this is probably the status quo (the same behavior on R 4.1) on
Latin-1 encoding, things are worse on CJK locales. If I try,

"col1","col2"
"あ","い"

I get the following error:

> read.csv("clipboard")
Error in type.convert.default(data[[i]], as.is = as.is[i], dec = dec,  :
  invalid multibyte string at '<82>'

Is this supposed to work? It seems the characters are encoded as CP932
(my system locale) but marked as UTF-8.

> x <- utils:::readClipboard()
> x
[1] "\"col1\",\"col2\"" "\"\x82\xa0\",\"\x82\xa2\""
> iconv(x, from = "CP932", to = "UTF-8")
[1] "\"col1\",\"col2\"" "\"あ\",\"い\""

I read the source code of readClipboard() in
src/library/utils/src/windows/util.c, but have no idea if there's
anything that needs to be fixed.

Best,
Yutani

2021年12月21日(火) 17:26 Tomas Kalibera :





>
> Hi Yutani,
>
> On 12/21/21 6:34 AM, Hiroaki Yutani wrote:
> > Hi,
> >
> > I'm more than excited about the announcement about the upcoming UTF-8
> > R on Windows. Let me confirm my understanding. Is R 4.2 supposed to
> > work on Windows with non-UTF-8 encoding as the system locale? I think
> > this blog post indicates so (as this describes the older Windows than
> > the UTF-8 era), but I'm not fully confident if I understand the
> > details correctly.
>
> R 4.2 will automatically use UTF-8 as the active code page (system
> locale) and the C library encoding and the R current native encoding on
> systems which allow this (recent Windows 10 and newer, Windows Server
> 2022, etc). There is no way to opt-out from that, and of course no
> reason to, either. It does not matter of what is the system locale set
> in Windows for the whole system - these recent Windows allow individual
> applications to override the system-wide setting to UTF-8, which is what
> R does. Typically the system-wide setting will not be UTF-8, because
> many applications will not work with that.
>
> On older systems, R 4.2 will run in some other system locale and the
> same C library encoding and R current native encoding - the same system
> default as R 4.1 would run on that system. So for some time, encoding
> support for this in R will have to stay, but eventually will be removed.
> But yes, R 4.2 is still supposed to work on such systems.
>
> > https://developer.r-project.org/Blog/public/2021/12/07/upcoming-changes-in-r-4.2-on-windows/index.html
> >
> > If so, I'm curious what the package authors should do when the locales
> > are different between OS and R. For example (disclaimer: I don't
> > intend to blame processx at all. Just for an example), the CRAN check
> > on the processx package currently fails with this warning on R-devel
> > Windows.
> >
> >>  1. UTF-8 in stdout (test-utf8.R:85:3) - Invalid multi-byte character 
> >> at end of stream ignored
> > https://cran.r-project.org/web/checks/check_results_processx.html
> >
> > As far as I know, processx launches an external process and captures
> > its output, and I suspect the problem is that the output of the
> > process is encoded in non-UTF-8 while R assumes it's UTF-8. I
> > experienced similar problems with other packages as well, which
> > disappear if I switch the locale to the same one as the OS by
> > Sys.setlocale(). So, I think it would be great if there's some
> > guidance for the package authors on how to handle these properly.
>
> Incidentally I've debugged this case and sent a detailed analysis to the
> maintainer, so he knows about the problem.
>
> In short, you cannot assume in Windows that different applications use
> the same system encoding. That is not true at least with the invention
> of the fusion manifests which allow an application to switch to UTF-8 as
> system encoding, which R does. So, when using an external application on
> Windows, you need to know and respect a specific

Re: [Rd] R on Windows with UCRT and the system encoding

[Hiroaki Yutani]

Hi Tomas,

Thanks for your prompt reply and spotting the right place. While I'm
not good at C/C++ things, I'll try investigating this and, if
possible, creating some patch to fix the issue. As the UTF-8 R on
Windows is really exciting news to us in CJK locale, I'd like to do my
best to help making the upcoming release a success.

I'll report on Bugzilla with more thetails first. Thanks for your support.

Best,
Yutani

2021年12月22日(水) 0:23 Tomas Kalibera :

>
> Hi Yutani,
>
> On 12/21/21 3:47 PM, Hiroaki Yutani wrote:
> > Hi Tomas,
> >
> > Thank you very much for the detailed explanation! I think now I have a
> > bit better understanding on how the things work; at least now I know I
> > didn't understand the concept of "active code page". I'll follow your
> > advice when I need to fix the packages that need some tweaks to handle
> > UTF-8 properly.
> >
> > Sorry, I'd like to ask one more question related to locale. If I copy
> > the following text and execute `read.csv("clipboard")`, it returns
> > "uao" instead of "úáö" (the characters are transliterated).
> >
> >  "col1","col2"
> >  "úáö","úáö"
> >
> >
> > While this is probably the status quo (the same behavior on R 4.1) on
> > Latin-1 encoding, things are worse on CJK locales. If I try,
> >
> >  "col1","col2"
> >  "あ","い"
> >
> > I get the following error:
> >
> >  > read.csv("clipboard")
> >  Error in type.convert.default(data[[i]], as.is = as.is[i], dec = dec,  
> > :
> >invalid multibyte string at '<82>'
> >
> > Is this supposed to work? It seems the characters are encoded as CP932
> > (my system locale) but marked as UTF-8.
> >
> >  > x <- utils:::readClipboard()
> >  > x
> >  [1] "\"col1\",\"col2\"" "\"\x82\xa0\",\"\x82\xa2\""
> >  > iconv(x, from = "CP932", to = "UTF-8")
> >  [1] "\"col1\",\"col2\"" "\"あ\",\"い\""
> >
> > I read the source code of readClipboard() in
> > src/library/utils/src/windows/util.c, but have no idea if there's
> > anything that needs to be fixed.
>
> Yes, this should work. I can reproduce the problem on my system, the
> clipboard apparently contains the Unicode characters, but R does not get
> them correctly, and from my quick read, it is a bug in R.
>
> My guess is this is in connections.c, where we call
> GetClipboardData(CF_TEXT). Perhaps if we used CF_UNICODETEXT, it would
> work (or alternatively CF_TEXT but also CF_LOCALE to find out what is
> the locale used, but CF_UNICODETEXT seems simpler). See
> https://docs.microsoft.com/en-us/windows/win32/dataxchg/standard-clipboard-formats
>
> As you started looking at the code, would you like to try
> debugging/fixing this?
>
> Best
> Tomas
>
> >
> > Best,
> > Yutani
> >
> > 2021年12月21日(火) 17:26 Tomas Kalibera :
> >
> >
> >
> >
> >
> >> Hi Yutani,
> >>
> >> On 12/21/21 6:34 AM, Hiroaki Yutani wrote:
> >>> Hi,
> >>>
> >>> I'm more than excited about the announcement about the upcoming UTF-8
> >>> R on Windows. Let me confirm my understanding. Is R 4.2 supposed to
> >>> work on Windows with non-UTF-8 encoding as the system locale? I think
> >>> this blog post indicates so (as this describes the older Windows than
> >>> the UTF-8 era), but I'm not fully confident if I understand the
> >>> details correctly.
> >> R 4.2 will automatically use UTF-8 as the active code page (system
> >> locale) and the C library encoding and the R current native encoding on
> >> systems which allow this (recent Windows 10 and newer, Windows Server
> >> 2022, etc). There is no way to opt-out from that, and of course no
> >> reason to, either. It does not matter of what is the system locale set
> >> in Windows for the whole system - these recent Windows allow individual
> >> applications to override the system-wide setting to UTF-8, which is what
> >> R does. Typically the system-wide setting will not be UTF-8, because
> >> many applications will not work with that.
> >>
> >> On older systems, R 4.2 will run in some other system locale and the
> >> same C library encoding and R current native encoding - the s

[Rd] Undocumented change of dirname("C:/") on R-devel on Windows

[Hiroaki Yutani]

Hi,

I found dirname() behaves differently on R-devel on Windows. Since I'm not
sure which behavior is right, let me ask here before filing this to R's
Bigzilla.

On R 4.2.2., we get

> dirname("C:/")
[1] "C:/"

However, on R-devel (r83888), we get

> dirname("C:/")
[1] "."

?dirname says 'dirname returns the part of the path up to but excluding the
last path separator, or "." if there is no path separator,' but I don't see
how the root path is supposed to be treated based on this rule (, whether
it's WIndows or UNIX-alike).

What should we expect as the return value of dirname("C:/")? I feel the
current behavior on R 4.2.2 is right, but I'd like to confirm.

Best,
Yutani

[[alternative HTML version deleted]]

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

Re: [Rd] Undocumented change of dirname("C:/") on R-devel on Windows

[Hiroaki Yutani]

Thanks for the prompt response, I'll confirm it after the new R-devel
binary is available.
Also, thanks for the detailed explanation. I agree with you in general.

> "/" in "C:/" is a path separator or not, and whether it is trailing or not

It seems a Windows' path basically consists of two components; a drive
specification (e.g., C:) and the directory structure within the drive. What
I learned today is that both "C:/" and "C:" are valid path specifications,
but refer to different locations; "C:" is not the root directory of the
drive, but just a relative path [1]. So, I agree with you that the basename
of "C:/" should be "C:/". However, at the same time, I don't feel this is
worth a breaking change, so I think we can preserve the current (R 4.2.2)
behavior.

[1]:
https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats#apply-the-current-directory

Best,
Yutani

2023年2月23日(木) 17:15 Tomas Kalibera :

>
> On 2/23/23 03:27, Hiroaki Yutani wrote:
> > Hi,
> >
> > I found dirname() behaves differently on R-devel on Windows. Since I'm
> not
> > sure which behavior is right, let me ask here before filing this to R's
> > Bigzilla.
> >
> > On R 4.2.2., we get
> >
> >  > dirname("C:/")
> >  [1] "C:/"
> >
> > However, on R-devel (r83888), we get
> >
> >  > dirname("C:/")
> >  [1] "."
> >
> > ?dirname says 'dirname returns the part of the path up to but excluding
> the
> > last path separator, or "." if there is no path separator,' but I don't
> see
> > how the root path is supposed to be treated based on this rule (, whether
> > it's WIndows or UNIX-alike).
> Thanks for spotting the difference, I've reverted to the previous
> behavior, the change was unintentional. If you spot any other suspicious
> changes in behavior in file-system operations, please report.
> > What should we expect as the return value of dirname("C:/")? I feel the
> > current behavior on R 4.2.2 is right, but I'd like to confirm.
>
> I also think the old behavior is better, even though it could be argued
> whether the "/" in "C:/" is a path separator or not, and whether it is
> trailing or not. But the behavior is in line with Unix where dirname of
> "/" is also "/". Msys2 would return "C:".
>
> If  "/" in "C:/" is a path separator but not a trailing path separator,
> then basename("C:/") should probably be "" and not "C:", and this would
> be in line with what R does on Unix. However, to be in line with Unix, I
> think the basename of "C:/" should be "C:/". Yet, Msys2 returns "C:"
> which is what R does now.
>
> So what these functions should do on Windows is definitely tricky. In
> either case the behavior is now again as in R 4.2.2.
>
> Best
> Tomas
>
> >
> > Best,
> > Yutani
> >
> >   [[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] Undocumented change of dirname("C:/") on R-devel on Windows

[Hiroaki Yutani]

I confirmed the revert fixed my failing test. Thanks!

2023年2月23日(木) 20:12 Hiroaki Yutani :

> Thanks for the prompt response, I'll confirm it after the new R-devel
> binary is available.
> Also, thanks for the detailed explanation. I agree with you in general.
>
> > "/" in "C:/" is a path separator or not, and whether it is trailing or
> not
>
> It seems a Windows' path basically consists of two components; a drive
> specification (e.g., C:) and the directory structure within the drive. What
> I learned today is that both "C:/" and "C:" are valid path specifications,
> but refer to different locations; "C:" is not the root directory of the
> drive, but just a relative path [1]. So, I agree with you that the basename
> of "C:/" should be "C:/". However, at the same time, I don't feel this is
> worth a breaking change, so I think we can preserve the current (R 4.2.2)
> behavior.
>
> [1]:
> https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats#apply-the-current-directory
>
> Best,
> Yutani
>
> 2023年2月23日(木) 17:15 Tomas Kalibera :
>
>>
>> On 2/23/23 03:27, Hiroaki Yutani wrote:
>> > Hi,
>> >
>> > I found dirname() behaves differently on R-devel on Windows. Since I'm
>> not
>> > sure which behavior is right, let me ask here before filing this to R's
>> > Bigzilla.
>> >
>> > On R 4.2.2., we get
>> >
>> >  > dirname("C:/")
>> >  [1] "C:/"
>> >
>> > However, on R-devel (r83888), we get
>> >
>> >  > dirname("C:/")
>> >  [1] "."
>> >
>> > ?dirname says 'dirname returns the part of the path up to but excluding
>> the
>> > last path separator, or "." if there is no path separator,' but I don't
>> see
>> > how the root path is supposed to be treated based on this rule (,
>> whether
>> > it's WIndows or UNIX-alike).
>> Thanks for spotting the difference, I've reverted to the previous
>> behavior, the change was unintentional. If you spot any other suspicious
>> changes in behavior in file-system operations, please report.
>> > What should we expect as the return value of dirname("C:/")? I feel the
>> > current behavior on R 4.2.2 is right, but I'd like to confirm.
>>
>> I also think the old behavior is better, even though it could be argued
>> whether the "/" in "C:/" is a path separator or not, and whether it is
>> trailing or not. But the behavior is in line with Unix where dirname of
>> "/" is also "/". Msys2 would return "C:".
>>
>> If  "/" in "C:/" is a path separator but not a trailing path separator,
>> then basename("C:/") should probably be "" and not "C:", and this would
>> be in line with what R does on Unix. However, to be in line with Unix, I
>> think the basename of "C:/" should be "C:/". Yet, Msys2 returns "C:"
>> which is what R does now.
>>
>> So what these functions should do on Windows is definitely tricky. In
>> either case the behavior is now again as in R 4.2.2.
>>
>> Best
>> Tomas
>>
>> >
>> > Best,
>> > Yutani
>> >
>> >   [[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

[Rd] Is ALTREP "non-API"?

[Hiroaki Yutani]

Writing R Extension[1] defines "API" as:

Entry points which are documented in this manual and declared in an
installed header file. These can be used in distributed packages and will
only be changed after deprecation.

But, the document (WRE) doesn't have even a single mention of ALTREP, the
term "ALTREP" itself or any entry points related to ALTREP. Does this mean,
despite the widespread use of it on R packages including CRAN ones, ALTREP
is not the API and accordingly using it in distributed packages is
considered illegal?

Best,
Yutani

[1]: https://cran.r-project.org/doc/manuals/r-release/R-exts.html#The-R-API

[[alternative HTML version deleted]]

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

Re: [Rd] Is ALTREP "non-API"?

[Hiroaki Yutani]

Thanks, Hernando,

Sorry, "API" is a bit confusing term in this context, but what I want to
discuss is the "API" that Writing R Extension defines as quoted in my
previous email. It's probably different from an ordinary sense when we
casually say "R C API".

You might wonder why I care about such a difference. This is because
calling a "non-API" is considered a violation of CRAN repository policy,
which means CRAN will kick out the R package. I know many CRAN packages use
ALTREP, but just being accepted by CRAN at the moment doesn't mean CRAN
will keep accepting it. So, I want to clarify the current status of ALTREP.

Best,
Yutani

2024年4月22日(月) 10:17 :

> Hello, I don't believe it is illegal, as ALTREP "implements an abstraction
> underneath the C API". And is "compatible with all code which uses the
> API".
>
> Please see slide deck by Gabriel Becker,  with L Tierney, M Lawrence and T
> Kalibera.
>
>
> https://bioconductor.org/help/course-materials/2020/BiocDevelForum/16-ALTREP
> .pdf
> <https://bioconductor.org/help/course-materials/2020/BiocDevelForum/16-ALTREP.pdf>
>
> ALTREP framework implements an abstraction underneath traditional R C API
> - Generalizes whats underneath the API
> - Without changing how data are accessed
> - Compatible with all C code which uses the API
> - Compatible with R internals
>
>
> I hope this helps,
> Hernando
>
>
> -Original Message-
> From: R-devel  On Behalf Of Hiroaki Yutani
> Sent: Sunday, April 21, 2024 8:48 PM
> To: r-devel 
> Subject: [Rd] Is ALTREP "non-API"?
>
> Writing R Extension[1] defines "API" as:
>
> Entry points which are documented in this manual and declared in an
> installed header file. These can be used in distributed packages and will
> only be changed after deprecation.
>
> But, the document (WRE) doesn't have even a single mention of ALTREP, the
> term "ALTREP" itself or any entry points related to ALTREP. Does this mean,
> despite the widespread use of it on R packages including CRAN ones, ALTREP
> is not the API and accordingly using it in distributed packages is
> considered illegal?
>
> Best,
> Yutani
>
> [1]:
> https://cran.r-project.org/doc/manuals/r-release/R-exts.html#The-R-API
>
> [[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] Is ALTREP "non-API"?

[Hiroaki Yutani]

Thanks for your convincing comment, but it seems the R core team has a
different opinion...
A few hours ago, src/include/R_ext/Altrep.h got this comment:

/*
   Not part of the API, subject to change at any time.
*/

commit:
https://github.com/r-devel/r-svn/commit/2059bffde642f8426d1f39ab5dd995d19a575d4d

While I'm glad to see their attempt to make it clear, I'm confused. That
commit marks many other files as "not API," but I think it's a bit
inconsistent with what Writing R Extension says.

For example, src/include/R_ext/Parse.h got a comment "So not API," but the
entry point R_ParseVector is explained in Writing R Extension[1]. So, I
believe it's clearly an "API" both in the sense of WRE's dialect and in an
ordinary sense. Which should I believe? WRE? The source code?

It might be just a coincidence, but I'm sorry if my question drove the R
core team to such a too-quick clarification. I just wanted to discuss how
to fix the current inconsistencies.

I think the R core needs a proper definition of "API" first. In my opinion,
it makes little sense to call it "non-API" just to show the possibility of
future breaking changes. Whether you call it API or non-API, clever users
will still accept the breaking changes on it if it's reasonable. For
example, how about "experimental API" or "unstable API"? They sound better
to me.

Best,
Yutani

[1]:
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Parsing-R-code-from-C


2024年4月22日(月) 16:37 Gabriel Becker :

> Hi Yutani,
>
> ALTREP is part of the official R api, as illustrated by the presence of
> src/include/R_ext/Altrep.h. Everything declared in the header files in that
> directory is official API AFAIK (and I believe that is more definitive than
> the manuals).
>
> The documentation of ALTREP has lagged behind its implementation
> unfortunately, which may partially my fault for not submitting doc
> patches for it against the manuals. Sorry for my contribution to that, I'll
> see if I can loop back around to contributing documentation for ALTREP.
>
> Best,
> ~G
>
> On Sun, Apr 21, 2024 at 6:36 PM Hiroaki Yutani 
> wrote:
>
>> Thanks, Hernando,
>>
>> Sorry, "API" is a bit confusing term in this context, but what I want to
>> discuss is the "API" that Writing R Extension defines as quoted in my
>> previous email. It's probably different from an ordinary sense when we
>> casually say "R C API".
>>
>> You might wonder why I care about such a difference. This is because
>> calling a "non-API" is considered a violation of CRAN repository policy,
>> which means CRAN will kick out the R package. I know many CRAN packages
>> use
>> ALTREP, but just being accepted by CRAN at the moment doesn't mean CRAN
>> will keep accepting it. So, I want to clarify the current status of
>> ALTREP.
>>
>> Best,
>> Yutani
>>
>> 2024年4月22日(月) 10:17 :
>>
>> > Hello, I don't believe it is illegal, as ALTREP "implements an
>> abstraction
>> > underneath the C API". And is "compatible with all code which uses the
>> > API".
>> >
>> > Please see slide deck by Gabriel Becker,  with L Tierney, M Lawrence
>> and T
>> > Kalibera.
>> >
>> >
>> >
>> https://bioconductor.org/help/course-materials/2020/BiocDevelForum/16-ALTREP
>> > .pdf
>> > <
>> https://bioconductor.org/help/course-materials/2020/BiocDevelForum/16-ALTREP.pdf
>> >
>> >
>> > ALTREP framework implements an abstraction underneath traditional R C
>> API
>> > - Generalizes whats underneath the API
>> > - Without changing how data are accessed
>> > - Compatible with all C code which uses the API
>> > - Compatible with R internals
>> >
>> >
>> > I hope this helps,
>> > Hernando
>> >
>> >
>> > -Original Message-
>> > From: R-devel  On Behalf Of Hiroaki
>> Yutani
>> > Sent: Sunday, April 21, 2024 8:48 PM
>> > To: r-devel 
>> > Subject: [Rd] Is ALTREP "non-API"?
>> >
>> > Writing R Extension[1] defines "API" as:
>> >
>> > Entry points which are documented in this manual and declared in an
>> > installed header file. These can be used in distributed packages and
>> will
>> > only be changed after deprecation.
>> >
>> > But, the document (WRE) doesn't have even a single mention of ALTREP,
>> the
>> > term "ALTREP" itself or any entry p

Re: [Rd] Is ALTREP "non-API"?

[Hiroaki Yutani]

I just saw the recent commits about the "experimental" entry points. So, my
original question about the current status of ALTREP is now resolved. I'm
glad that ALTREP is confirmed usable on CRAN (with care). Thank you for all
your help!

I think other "non-API"s still need clarification. For example, this one I
picked in my previous email.

> For example, src/include/R_ext/Parse.h got a comment "So not API," but
the entry point R_ParseVector is explained in Writing R Extension[1]. So, I
believe it's clearly an "API" both in the sense of WRE's dialect and in an
ordinary sense. Which should I believe? WRE? The source code?

But, in my understanding, R is now in the process of clearing such
ambiguities. So, I can just wait.

Lastly, I want the R core to consider marking ALTREP as stable, or the
"API". I didn't actively follow the development of ALTREP, but I think the
ALTREP entry points have been there for half a decade without any major
breaking changes. So, in my opinion, it's safe to declare it's stable.

Best,
Yutani


2024年4月23日(火) 7:14 Simon Urbanek :

>
>
> > On Apr 22, 2024, at 7:37 PM, Gabriel Becker 
> wrote:
> >
> > Hi Yutani,
> >
> > ALTREP is part of the official R api, as illustrated by the presence of
> > src/include/R_ext/Altrep.h. Everything declared in the header files in
> that
> > directory is official API AFAIK (and I believe that is more definitive
> than
> > the manuals).
> >
>
> That is not true at all - the presence of header does not constitute
> declaration of something as the R API. There are cases where internal
> functions are in the headers for historical or other reasons since the
> headers are used both for the internal implementation and packages. That's
> why this is in R-exts under "The R API: entry points for C code":
>
> > There are a large number of entry points in the R executable/DLL that
> can be called from C code (and some that can be called from Fortran code).
> Only those documented here are stable enough that they will only be changed
> with considerable notice.
>
> And that's why CRAN does not allow unstable ones = those not documented in
> R-exts as part of the API.
>
> Therefore Hiroaki's question is a very good one. ALTREP is declared as
> experimental and is not part of the API, but the development and stability
> of the API in some sense should get better as more packages are using it.
> Therefore it is currently allowed on CRAN in the hope that it will
> transition to stable at some point, but package authors using it must be
> willing to adapt to changes to the API as necessary.
>
> Cheers,
> Simon
>
>
>
> > The documentation of ALTREP has lagged behind its implementation
> > unfortunately, which may partially my fault for not submitting doc
> > patches for it against the manuals. Sorry for my contribution to that,
> I'll
> > see if I can loop back around to contributing documentation for ALTREP.
> >
> > Best,
> > ~G
> >
> > On Sun, Apr 21, 2024 at 6:36 PM Hiroaki Yutani 
> wrote:
> >
> >> Thanks, Hernando,
> >>
> >> Sorry, "API" is a bit confusing term in this context, but what I want to
> >> discuss is the "API" that Writing R Extension defines as quoted in my
> >> previous email. It's probably different from an ordinary sense when we
> >> casually say "R C API".
> >>
> >> You might wonder why I care about such a difference. This is because
> >> calling a "non-API" is considered a violation of CRAN repository policy,
> >> which means CRAN will kick out the R package. I know many CRAN packages
> use
> >> ALTREP, but just being accepted by CRAN at the moment doesn't mean CRAN
> >> will keep accepting it. So, I want to clarify the current status of
> ALTREP.
> >>
> >> Best,
> >> Yutani
> >>
> >> 2024年4月22日(月) 10:17 :
> >>
> >>> Hello, I don't believe it is illegal, as ALTREP "implements an
> >> abstraction
> >>> underneath the C API". And is "compatible with all code which uses the
> >>> API".
> >>>
> >>> Please see slide deck by Gabriel Becker,  with L Tierney, M Lawrence
> and
> >> T
> >>> Kalibera.
> >>>
> >>>
> >>>
> >>
> https://bioconductor.org/help/course-materials/2020/BiocDevelForum/16-ALTREP
> >>> .pdf
> >>> <
> >>
> https://bioconductor.org/help/course-materials/2020/BiocDevelForum/16-ALTREP.pdf
> &

Re: [Rd] Is ALTREP "non-API"?

[Hiroaki Yutani]

> And in general, I'd urge R Core to make an explicit list of functions that
you consider to be part of the exported API

While I believe R Core is in the process of such clarification, I'd also
vote for this. Now that WRE has "experimental" category, and if we take the
current definition of "documented in the manual" literally, an
"experimental" entry point cannot be documented because the entry point
would promote to an "API" for the obvious reason. It would sound funny that
you cannot write precautionary statements on experimental entry points just
because of the very definition of "experimental". So, I agree R should have
the explicit list.

I'd add that R should also define a process on how to stabilize an
"experimental" or "public" entry point into an "API". For example, Rust
language has such a process [1]. After a feature is introduced as unstable,
a "tracking issue" is filed and the related problems are reported or linked
to it. Users can know what are the remaining problems before getting
stabilized, and, if they have strong will, they can contribute to resolving
such blockers. Similarly, if we can track the unresolved problems of each
non-API, we might be able to help the R core team more smoothly.

Best,
Yutani

[1]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html


2024年4月24日(水) 21:55 Hadley Wickham :

> >
> >
> >
> > >>> That is not true at all - the presence of header does not constitute
> > >> declaration of something as the R API. There are cases where internal
> > >> functions are in the headers for historical or other reasons since the
> > >> headers are used both for the internal implementation and packages.
> > That's
> > >> why this is in R-exts under "The R API: entry points for C code":
> > >>>
> > >>> If I understand your point correctly, does this mean that
> > >> Rf_allocVector() is not part of the "official" R API? It does not
> > appear to
> > >> be documented in the "The R API: entry points for C code" section.
> > >>>
> > >>
> > >> It does, obviously:
> > >>
> https://cran.r-project.org/doc/manuals/R-exts.html#Allocating-storage-1
> > >
> > >
> > > I'm just trying to understand the precise definition of the official
> API
> > > here. So it's any function mentioned in R-exts, regardless of which
> > section
> > > it appears in?
> > >
> > > Does this sentence imply that all functions starting with alloc* are
> part
> > > of the official API?
> > >
> >
> > Again, I can only quote the R-exts (few lines below the previous "The R
> > API" quote):
> >
> >
> > We can classify the entry points as
> > API
> > Entry points which are documented in this manual and declared in an
> > installed header file. These can be used in distributed packages and will
> > only be changed after deprecation.
> >
> >
> > It says "in this manual" - I don't see anywhere restriction on a
> > particular section of the manual, so I really don't see why you would
> think
> > that allocation is not part on the API.
> >
>
> Because you mentioned that section explicitly earlier in the thread. This
> obviously seems clear to you, but it's not at all clear to me and I suspect
> many of the wider community. It's frustrating because we are trying
> our best to do what y'all want us to do, but it feels like we keep getting
> the rug pulled out from under us with very little notice, and then have to
> spend a large amount of time figuring out workarounds. That is at least
> feasible for my team since we have multiple talented folks who are paid
> full-time to work on R, but it's a huge struggle for most people who are
> generally maintaining packages in their spare time.
>
> For the purposes of this discussion could you please "documented in the
> manual" means? For example, this line mentions allocXxx functions: "There
> are quite a few allocXxx functions defined in Rinternals.h—you may want to
> explore them.". Does that imply that they are documented and free to use?
>
> And in general, I'd urge R Core to make an explicit list of functions that
> you consider to be part of the exported API, and then grandfather in
> packages that used those functions prior to learning that we weren't
> supposed to.
>
> Hadley
>
>
> --
> http://hadley.nz
>
> [[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] clarifying and adjusting the C API for R

[Hiroaki Yutani]

Thanks so much for your wonderful work, Luke!
I didn't expect such a clarification to happen this soon. This is really
great.

For convenience, I created a quick web page to search the result of
tools:::funAPI().

https://yutannihilation.github.io/R-fun-API/

Hope this helps those who are too lazy to install R-devel to check.

Best,
Yutani

2024年6月6日(木) 23:47 luke-tierney--- via R-devel :

> This is an update on some current work on the C API for use in R
> extensions.
>
> The internal R implementation makes use of tens of thousands of C
> entry points. On Linux and Windows, which support visibility
> restrictions, most of these are visible only within the R executble or
> shared library. About 1500 are not hidden and are visible to
> dynamically loaded shared libraries, such as ones in packages, and to
> embedding applications.
>
> There are two main reasons for limiting access to entry points in a
> software framework:
>
> - Some entry points are very easy to use in ways that corrupt internal
>data, leading to segfaults or, worse, incorrect computations without
>segfaults.
>
> - Some entry point expose internal structure and other implementation
>details, which makes it hard to make improvements without breaking
>client code that has come to depend on these details.
>
> The API of C entry points that can be used in R extensions, both for
> packages and embedding, has evolved organically over many years. The
> definition for the current release expressed in the Writing R
> Extensions manual (WRE) is roughly:
>
>  An entry point can be used if (1) it is declared in a header file
>  in R.home("include"), and (2) if it is documented for use in WRE.
>
> Ideally, (1) would be necessary and sufficient, but for a variety of
> reasons that isn't achievable, at least not in the near term. (2) can
> be challenging to determine; in particular, it is not amenable to a
> computational answer.
>
> An experimental effort is underway to add annotations to the WRE
> Texinfo source to allow (2) to be answered unambiguously. The
> annotations so far mostly reflect my reading or WRE and may be revised
> as they are reviewed by others. The annotated document can be used for
> programmatically identifying what is currently considered part of the C
> API. The result so far is an experimental function tools:::funAPI():
>
>  > head(tools:::funAPI())
>  nameloc apitype
>  1 Rf_AdobeSymbol2utf8 R_ext/GraphicsDevice.heapi
>  2alloc3DArrayWRE api
>  3  allocArrayWRE api
>  4   allocLangWRE api
>  5   allocListWRE api
>  6 allocMatrixWRE api
>
> The 'apitype' field has three possible levels
>
>  | api  | stable (ideally) API |
>  | eapi | experimental API |
>  | emb  | embedding API|
>
> Entry points in the embedded API would typically only be used in
> applications embedding R or providing new front ends, but might be
> reasonable to use in packages that support embedding.
>
> The 'loc' field indicates how the entry point is identified as part of
> an API: explicit mention in WRE, or declaration in a header file
> identified as fully part of an API.
>
> [tools:::funAPI() may not be completely accurate as it relies on
> regular expressions for examining header files considered part of the
> API rather than proper parsing. But it seems to be pretty close to
> what can be achieved with proper parsing.  Proper parsing would add
> dependencies on additional tools, which I would like to avoid for
> now. One dependency already present is that a C compiler has to be on
> the search path and cc -E has to run the C pre-processor.]
>
> Two additional experimental functions are available for analyzing
> package compliance: tools:::checkPkgAPI and tools:::checkAllPkgsAPI.
> These examine installed packages.
>
> [These may produce some false positives on macOS; they may or may not
> work on Windows at this point.]
>
> Using these tools initially showed around 200 non-API entry points
> used across packages on CRAN and BIOC. Ideally this number should be
> reduced to zero. This will require a combination of additions to the
> API and changes in packages.
>
> Some entry points can safely be added to the API. Around 40 have
> already been added to WRE with API annotations; another 40 or so can
> probably be added after review.
>
> The remainder mostly fall into two groups:
>
> - Entry points that should never be used in packages, such as
>SET_OBJECT or SETLENGTH (or any non-API SETXYZ functions for that
>matter) that can create inconsistent or corrupt internal state.
>
> - Entry points that depend on the existence of internal structure that
>might be subject to change, such as the existence of promise objects
>or internal structure of environments.
>
> Many, i

Re: [Rd] [External] Re: changes in R-devel and zero-extent objects in Rcpp

[Hiroaki Yutani]

Sorry to ask about a bit drifted topic, but will there be an alternative
API to DATAPTR?

> DATAPTR is not in the API and can't be at least in this form

I believe it's vital for ALTREP to return the pointer to the expanded
version of a SEXP just like the implementation in base R does [1].
At least, VECSXP has no other measure to expose the pointer if I understand
correctly.

Best,
Yutani

[1]:
https://github.com/r-devel/r-svn/blob/a3508b75d28164b0e5bcb2c87f816ce5169729a4/src/main/altclasses.c#L186


2024年6月9日(日) 10:43 luke-tierney--- via R-devel :

> On Sat, 8 Jun 2024, Ben Bolker wrote:
>
> >  The ASAN errors occur *even if the zero-length object is not actually
> > accessed*/is used in a perfectly correct manner, i.e. it's perfectly
> legal in
> > base R to define `m <- numeric(0)` or `m <- matrix(nrow = 0, ncol = 0)`,
> > whereas doing the equivalent in Rcpp will (now) lead to an ASAN error.
> >
> >  i.e., these are *not* previously cryptic out-of-bounds accesses that
> are
> > now being revealed, but instead sensible and previously legal
> definitions of
> > zero-length objects that are now causing problems.
> >
> >   I'm pretty sure I'm right about this, but it's absolutely possible
> that
> > I'm just confused at this point; I don't have a super-simple example to
> show
> > you at the moment. The closest is this example by Mikael Jagan:
> > https://github.com/lme4/lme4/issues/794#issuecomment-2155093049
> >
> >  which shows that if x is a pointer to a zero-length vector (in plain
> C++
> > for R, no Rcpp is involved), DATAPTR(x) and REAL(x) evaluate to
> different
> > values.
> >
> >  Mikael further points out that "Rcpp seems to cast a (void *) returned
> by
> > DATAPTR to (double *) when constructing a Vector from a SEXP,
> rather
> > than using the (double *) returned by REAL." So perhaps R-core doesn't
> want
> > to guarantee that these operations give identical answers, in which case
> Rcpp
> > will have to change the way it does things ...
>
> It looks like REAL and friends should also get this check, but it's
> not high priority at this point, at least to me. DATAPTR has been
> using this check for a while in a barrier build, so you might want to
> test there as well. I expect we will activate more integrity checks
> from the barrier build on the API client side as things are tidied up.
>
> However: DATAPTR is not in the API and can't be at least in this form:
> It allows access to a writable pointer to STRSXP and VECSXP data and
> that is too dangerous for memory manager integrity. I'm not sure
> exactly how this will be resolve, but be prepared for changes.
>
> Best,
>
> luke
>
> >
> >  cheers
> >   Ben
> >
> >
> >
> > On 2024-06-08 6:39 p.m., Kevin Ushey wrote:
> >> IMHO, this should be changed in both Rcpp and downstream packages:
> >>
> >> 1. Rcpp could check for out-of-bounds accesses in cases like these, and
> >> emit an R warning / error when such an access is detected;
> >>
> >> 2. The downstream packages unintentionally making these out-of-bounds
> >> accesses should be fixed to avoid doing that.
> >>
> >> That is, I think this is ultimately a bug in the affected packages, but
> >> Rcpp could do better in detecting and handling this for client packages
> >> (avoiding a segfault).
> >>
> >> Best,
> >> Kevin
> >>
> >>
> >> On Sat, Jun 8, 2024, 3:06 PM Ben Bolker  >> > wrote:
> >>
> >>
> >>  A change to R-devel (SVN r86629 or
> >>
> https://github.com/r-devel/r-svn/commit/92c1d5de23c93576f55062e26d446feface07250
> >> <
> https://github.com/r-devel/r-svn/commit/92c1d5de23c93576f55062e26d446feface07250
> >
> >> has changed the handling of pointers to zero-length objects,
> leading to
> >> ASAN issues with a number of Rcpp-based packages (the commit message
> >> reads, in part, "Also define STRICT_TYPECHECK when compiling
> >> inlined.c.")
> >>
> >> I'm interested in discussion from the community.
> >>
> >> Details/diagnosis for the issues in the lme4 package are here:
> >> https://github.com/lme4/lme4/issues/794
> >> ,
> >> with a bit more discussion
> >> about how zero-length objects should be handled.
> >>
> >> The short(ish) version is that r86629 enables the
> >> CATCH_ZERO_LENGTH_ACCESS definition. This turns on the CHKZLN macro
> >> <
> https://github.com/r-devel/r-svn/blob/4ef83b9dc3c6874e774195d329cbb6c11a71c414/src/main/memory.c#L4090-L4104
> >> <
> https://github.com/r-devel/r-svn/blob/4ef83b9dc3c6874e774195d329cbb6c11a71c414/src/main/memory.c#L4090-L4104
> >>,
> >> which returns a trivial pointer (rather than the data pointer that
> >> would
> >> be returned in the normal control flow) if an object has length 0:
> >>
> >> /* Attempts to read or write elements of a zero length vector will
> >>  result in a segfault, rather than read and write random memory.
> >>  Returning NULL would be more natural, but Matrix se

Re: [Rd] [External] Re: changes in R-devel and zero-extent objects in Rcpp

[Hiroaki Yutani]

(Mainly reply to self)

I found there's a new API VECTOR_PTR_RO. Thanks for adding this!

https://github.com/r-devel/r-svn/commit/d499fab95b1ba23ee7842293030d4af1e69ae0fe

Best,
Yutani

2024年6月9日(日) 14:13 Hiroaki Yutani :

> Sorry to ask about a bit drifted topic, but will there be an alternative
> API to DATAPTR?
>
> > DATAPTR is not in the API and can't be at least in this form
>
> I believe it's vital for ALTREP to return the pointer to the expanded
> version of a SEXP just like the implementation in base R does [1].
> At least, VECSXP has no other measure to expose the pointer if I
> understand correctly.
>
> Best,
> Yutani
>
> [1]:
> https://github.com/r-devel/r-svn/blob/a3508b75d28164b0e5bcb2c87f816ce5169729a4/src/main/altclasses.c#L186
>
>
> 2024年6月9日(日) 10:43 luke-tierney--- via R-devel :
>
>> On Sat, 8 Jun 2024, Ben Bolker wrote:
>>
>> >  The ASAN errors occur *even if the zero-length object is not actually
>> > accessed*/is used in a perfectly correct manner, i.e. it's perfectly
>> legal in
>> > base R to define `m <- numeric(0)` or `m <- matrix(nrow = 0, ncol =
>> 0)`,
>> > whereas doing the equivalent in Rcpp will (now) lead to an ASAN error.
>> >
>> >  i.e., these are *not* previously cryptic out-of-bounds accesses that
>> are
>> > now being revealed, but instead sensible and previously legal
>> definitions of
>> > zero-length objects that are now causing problems.
>> >
>> >   I'm pretty sure I'm right about this, but it's absolutely possible
>> that
>> > I'm just confused at this point; I don't have a super-simple example to
>> show
>> > you at the moment. The closest is this example by Mikael Jagan:
>> > https://github.com/lme4/lme4/issues/794#issuecomment-2155093049
>> >
>> >  which shows that if x is a pointer to a zero-length vector (in plain
>> C++
>> > for R, no Rcpp is involved), DATAPTR(x) and REAL(x) evaluate to
>> different
>> > values.
>> >
>> >  Mikael further points out that "Rcpp seems to cast a (void *) returned
>> by
>> > DATAPTR to (double *) when constructing a Vector from a SEXP,
>> rather
>> > than using the (double *) returned by REAL." So perhaps R-core doesn't
>> want
>> > to guarantee that these operations give identical answers, in which
>> case Rcpp
>> > will have to change the way it does things ...
>>
>> It looks like REAL and friends should also get this check, but it's
>> not high priority at this point, at least to me. DATAPTR has been
>> using this check for a while in a barrier build, so you might want to
>> test there as well. I expect we will activate more integrity checks
>> from the barrier build on the API client side as things are tidied up.
>>
>> However: DATAPTR is not in the API and can't be at least in this form:
>> It allows access to a writable pointer to STRSXP and VECSXP data and
>> that is too dangerous for memory manager integrity. I'm not sure
>> exactly how this will be resolve, but be prepared for changes.
>>
>> Best,
>>
>> luke
>>
>> >
>> >  cheers
>> >   Ben
>> >
>> >
>> >
>> > On 2024-06-08 6:39 p.m., Kevin Ushey wrote:
>> >> IMHO, this should be changed in both Rcpp and downstream packages:
>> >>
>> >> 1. Rcpp could check for out-of-bounds accesses in cases like these,
>> and
>> >> emit an R warning / error when such an access is detected;
>> >>
>> >> 2. The downstream packages unintentionally making these out-of-bounds
>> >> accesses should be fixed to avoid doing that.
>> >>
>> >> That is, I think this is ultimately a bug in the affected packages,
>> but
>> >> Rcpp could do better in detecting and handling this for client
>> packages
>> >> (avoiding a segfault).
>> >>
>> >> Best,
>> >> Kevin
>> >>
>> >>
>> >> On Sat, Jun 8, 2024, 3:06 PM Ben Bolker > >> <mailto:bbol...@gmail.com>> wrote:
>> >>
>> >>
>> >>  A change to R-devel (SVN r86629 or
>> >>
>> https://github.com/r-devel/r-svn/commit/92c1d5de23c93576f55062e26d446feface07250
>> >> <
>> https://github.com/r-devel/r-svn/commit/92c1d5de23c93576f55062e26d446feface07250
>> >
>> >> has changed the handling of pointers to zero-length objects,
>> leading to
>

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

[Hiroaki Yutani]

> I've looked for other messages on this, and didn't see any besides this
> one explaining why including check_rust() in the checks is a problem.

I agree with you. It seems no one explained what problem it causes to them.
In my understanding (disclaimer: I haven't hit this by myself yet), the
problem is that the "Downloading crates ..." log raises a warning, which
makes the CI check fail. Although it's true that none of this is
"prohibitive," it's just inconvenient.

Maybe it's possible to make it a NOTE instead of a WARNING at least?

I'm suggesting so because otherwise this will end up encouraging the
package authors to hide these logs as a workaround to avoid the CI failure.
As it's very easy, I'm personally fine with the status quo, but if it
becomes a common practice, it makes it harder for the CRAN maintainers to
investigate the installation logs.

Best,
Yutani


2025年3月2日(日) 23:49 Duncan Murdoch :

> You seem to be taking a confontational tone, which isn't likely to
> encourage a reasonable dialogue.
>
> I've looked for other messages on this, and didn't see any besides this
> one explaining why including check_rust() in the checks is a problem.
> The problem you talk about here is that it encourages vendoring, which
> makes it harder for package authors to count downloads.
>
> To be honest, that doesn't seem like a very serious problem.  I assume
> the packages ("crates") we are talking about are open source, so this is
> entirely in the spirit of how they are allowed to be distributed.
>
> If they aren't open source, then users of those packages should be
> warned about that, and a check failure is a good way to do that.
>
> So you need to explain why it is important to be able to download and
> install software and not be warned about it.
>
> I am not in R Core or CRAN, but I can suggest why it is better to
> include source in the package:  it makes the use of that package more
> reliable in the future.  It's not uncommon to run an R computation that
> was written a few years ago.  Sometimes libraries or R have changed, and
> a user will need to go back to a previous version to reproduce the
> calculation.  Being able to able to rebuild a system as it would have
> been back then is important.
>
> Is that possible if the package needs to make a download?  The download
> site that worked a few years ago may no longer exist.  If the site
> exists, the code versions there may be different.
>
> Those are some of the issues that Simon was alluding to.
>
> Duncan Murdoch
>
>
>
> On 2025-03-02 5:45 a.m., Mossa Merhi Reimert via R-devel wrote:
> > Dear Simon Urbanek,
> >
> > 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.org or the proposed patch. Before we talk about anything
> else,
> > it does seem very strange that we cannot get a reasonable dialogue going.
> >
> > I would like to say that the R/Rust community has grown substantially.
> From my end, there are 3 bindings project, extendr, savvy, and roxido.
> > Then, there are now many rust-based packages on CRAN, see this most
> recent compiled list https://github.com/nanxstats/r-rust-pkgs.
> > There is also proof-of-concept https://github.com/r-rust/hellorust that
> integrates `cargo`, rust’s official build system, with R’s package build
> system,
> > and https://github.com/extendr/hellorustc, which showcases how Rust
> compiler could be directly linked with R’s package system.
> >
> >   Let me say, that the current R CMD check is not meant to be “helpful”.
> When a package is built, `cargo` tells the user “Downloading crates”.
> > Thus, this information 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
> > as a good policy. Download statistics is a success metric of a given
> r-package and rust packages. By insisting on vendoring, and thus
> > side-stepping `cargo` / 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 be
> thought of, as fair game, to have CRAN act as a pseudo package manager for
> C/C++ libraries.
> > I’m not going to argue for or against this part.
> >
> > There are many objections from the CRAN side to all things related to
> Rust. I don’t want to open multiple topics in the same thread.
> > But there is plenty to bring up. And I had hoped we could talk this
> little issue through, 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
> perceived as a big, bulky demand.
> >