> 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
prob
(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 alt
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
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
> 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 "docum
ion 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 m
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
gt;
>
> 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,
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
t
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.
>
> >
/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
> n
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] "."
?dirnam
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,
> >
> > T
d()
> x
[1] "\"col1\",\"col2\"" "\"\x82\xa0\",\"\x82\xa2\""
> iconv(x, from = "CP932", to = "UTF-8")
[1] "\"col1\",\"col2\"" "\"あ\",\"い\"
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),
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 w
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&
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.
>
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
202
o 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
日(水) 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
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:
&
ed 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 b
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
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 s
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
26 matches
Mail list logo
