> 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
ors 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
> > patc
ack 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
LTREP 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
&
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
pe the R community and the Rust community have
respect for each other.
Best,
Yutani
[1]: https://crates.io/crates/addr2line
[2]: https://github.com/gimli-rs/addr2line/blob/0.20.0/Cargo.toml
[3]:
https://doc.rust-lang.org/cargo/reference/manifest.html#the-authors-field
2023年8月27日(日) 12:07 Simon U
Simon,
> it's assumed that GitHub history is the canonical source with the
provenance, but that gets lost when pulled into the package.
No, not GitHub. You can usually find the ownership on crates.io. So, if you
want a target to blame, it's probably just a problem of the script to
auto-generate
.org/inside-rust/2023/01/30/cargo-sparse-protocol.html
[3]: https://packages.debian.org/testing/cargo (it seems 0.66 means 1.66)
2023年7月14日(金) 9:58 Hiroaki Yutani :
> Simin,
>
> Sorry that my question was not clear. Let me clarify.
>
> I think we all agree that "cargo
Simin,
Sorry that my question was not clear. Let me clarify.
I think we all agree that "cargo vendor" is the primary option. Since
downloading without explicit permission is not allowed on CRAN in general,
it's reasonable. I'm happy that the instructions will describe it clearly.
But, some R
Thank you for the correction. I see.
Best,
Yutani
2023年7月13日(木) 16:08 Tomas Kalibera :
>
> On 7/13/23 05:08, Hiroaki Yutani wrote:
> > I actually use cargo vendor.
> >
> >
> https://github.com/yutannihilation/string2path/blob/main/src/rust/vendor.sh
> >
> >
he tar balls may be too
> big to make it part of the package, but it's yet another can of worms...).
>
> Cheers,
> Simon
>
>
>
> > On 13/07/2023, at 12:37 PM, Hiroaki Yutani wrote:
> >
> > Hi,
> >
> > I'm glad to see CRAN now has its official policy about
em, because it's not
>> uncommon to use R in environments that have no Internet access, but the
>> download is a concession for extreme cases where the tar balls may be too
>> big to make it part of the package, but it's yet another can of worms...).
>>
>> Cheers,
&g
Hi,
I'm glad to see CRAN now has its official policy about Rust [1]!
It seems it probably needs some feedback from those who are familiar with
the Rust workflow. I'm not an expert, but let me leave some quick feedback.
This email is sent to the R-package-devel mailing list as well as to cran@~
so
Thanks so much for the quick response. It answered everything!
It was my mistake that I didn't consider these types of installations.
I'll fix my package as soon as I can.
Best,
Yutani
2023年7月10日(月) 17:51 Martin Maechler :
> >>>>> Hiroaki Yutani
> >>>>>
Hi,
My package, string2path, using Rust fails on the CRAN check of MKL [1],
with an error that seems irrelevant to MKL. The error says:
> thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value:
Os { code: 2, kind: NotFound, message: "No such file or directory" }',
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.
>
> > &quo
d/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 wh
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] "."
ath/pull/35 (work in
progress)
2022年7月27日(水) 17:12 Tomas Kalibera :
>
> On 7/27/22 08:08, Tomas Kalibera wrote:
> >
> > On 7/27/22 00:30, Hiroaki Yutani wrote:
> >> Hi,
> >>
> >> Recently I got the following email from the CRAN maintainer about my
>
ntel macOS.
>
> Also. make sure that the authorship and copyright of code you download
> (and hence include in the package) is clear from the DESCRIPTION file.
> as required by the CRAN policy.
>
Best,
Hiroaki Yutani
[1]: https://cran.r-project.org/package=string2path
[2]:
https://g
I see, thanks. I filed here:
https://bugs.r-project.org/show_bug.cgi?id=18292
Best,
Yutani
2022年1月27日(木) 1:35 Tomas Kalibera :
>
> Hi Yutani,
>
> On 1/26/22 16:42, Hiroaki Yutani wrote:
> > Hi Tomas,
> >
> > Thanks, but, if I understand correctly, there'
but let me
hold off for a while.
Best,
Yutani
2022年1月27日(木) 0:21 Tomas Kalibera :
>
>
> On 1/26/22 15:44, Hiroaki Yutani wrote:
> > Hi Tomas,
> >
> > Thanks for your helpful advice. This time, it seems the cause of the
> > error was an allocator mismatch; I mistake
Hi,
I'm trying to create a Rust library that can implement an R graphic
device[1], but the R session crashes on `dev.off()` on Windows with R
4.1.2. Strangely, it works without errors on Linux, on macOS, and even
on Windows with R-devel.
Looking at the stack trace below by WinDbg, the problem is
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 f
uot;\"col1\",\"col2\"" "\"\x82\xa0\",\"\x82\xa2\""
> iconv(x, from = "CP932", to = "UTF-8")
[1] "\"col1\",\"col2\"" "\"あ\",\"い\""
I read the sourc
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),
Yes, it's my fault that I didn't consider the case when no fonts are
available. I'll improve the code until the next submission to CRAN.
Thanks for your advice!
Best,
Hiroaki Yutani
2021年12月17日(金) 1:40 Tomas Kalibera :
>
>
> On 12/16/21 5:16 PM, Hiroaki Yutani wrote:
> > Thanks
Thanks for the details and the suggestions. My package uses
systemfonts package for illustration purposes only in the examples, so
I'm not that desperate to find the root cause this time. I'll try
using winbuilder in case I need to.
Best,
Hiroaki Yutani
2021年12月17日(金) 0:52 Tomas Kalibera
ting quickly! Then, it seems I should wait for the
problem to be solved on systemfonts' side. I'm curious what's the
difference between r-devel-windows-x86_64-new-TK, on which the check
doesn't fail, by the way.
Best,
Hiroaki Yutani
2021年12月16日(木) 23:57 Uwe Ligges :
>
>
>
> On 16.12.202
version to avoid this test
failure. Note that, the other Windows r-devel machine
(r-devel-windows-x86_64-new-TK) doesn't fail. So, it might be just
that something is wrong with r-devel-windows-x86_64-new-UL.
Any suggestions?
Best,
Hiroaki Yutani
__
R
So, probably no one knows the right answer...
Best,
Hiroaki Yutani
[1]: https://cran.r-project.org/web/checks/check_results_string2path.html
[2]: https://stat.ethz.ch/pipermail/r-package-devel/2021q3/007262.html
2021年9月24日(金) 23:50 Roy Mendelssohn - NOAA Federal via R-package-devel
:
>
> Hi All
till 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:
&g
, 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.
&g
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
2021年9月9
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
Sorry, I pointed a wrong package. I meant,
[2]: https://cran.r-project.org/package=gifski
[3]: https://cran.r-project.org/package=baseflow
Best,
Hiroaki Yutani
2021年8月5日(木) 8:17 Hiroaki Yutani :
>
> Hi,
>
> I recently submitted my package, which needs compilation of Rust code,
&g
,
Hiroaki Yutani
[1]: https://doc.rust-lang.org/nightly/rustc/platform-support.html
[2]: https://cran.r-project.org/package=cargo
[3]: https://cran.r-project.org/package=baseflow
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman
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:
&
any 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
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#:
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 sho
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
44 matches
Mail list logo
