Re: [R-pkg-devel] R, Rust and CRAN
No, because I don't use Rust. That's why I was saying that the Rust users should get together and create a such package. Some of the packages listed have experience in fixing the problems, so I would hope they can provide guidance or a good starting point. This is something for the interested community to do. Cheers, Simon > On Nov 13, 2022, at 9:20 AM, Dirk Eddelbuettel wrote: > > > On 13 November 2022 at 08:15, Simon Urbanek wrote: > | sorry, I think you misunderstood: CRAN machines have the compilers, but the > packages were not detecting it properly and/or were violating the CRAN > policies as noted, so that's why I was saying that it would make sense to > have a unified approach so that each package author doesn't have to make the > same mistakes over again. > > Would you be able to provide a sample package, say, "hello.rust", that does > that to guide us all? > > Dirk > > -- > dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R, Rust and CRAN
On 13 November 2022 at 08:15, Simon Urbanek wrote: | sorry, I think you misunderstood: CRAN machines have the compilers, but the packages were not detecting it properly and/or were violating the CRAN policies as noted, so that's why I was saying that it would make sense to have a unified approach so that each package author doesn't have to make the same mistakes over again. Would you be able to provide a sample package, say, "hello.rust", that does that to guide us all? Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R, Rust and CRAN
Jeroen, sorry, I think you misunderstood: CRAN machines have the compilers, but the packages were not detecting it properly and/or were violating the CRAN policies as noted, so that's why I was saying that it would make sense to have a unified approach so that each package author doesn't have to make the same mistakes over again. Cheers, Simon > On Nov 13, 2022, at 7:27 AM, Jeroen Ooms wrote: > > On Sat, Nov 12, 2022 at 12:49 AM Simon Urbanek > wrote: >> >> this does not directly address your question, but I think it would make a >> lot of sense to standardize the process, given how many issues there were >> with packages using Rust (mainly not detecting compilers correctly, not >> supplying source code, unsolicited writing into user's directories, not >> checking binaries etc.). Doing this right is not entirely trivial which is >> presumably where the "friction" comes from. > > All we need is the rustc/cargo toolchain to be installed on the CRAN > win/mac builders (it already is on Fedora/Debian). As mentioned above > (and before in e.g. https://jeroen.github.io/erum2018), rust uses the > native C FFI, does not need any runtime library, and can be called > directly from an R package using the C interface. There is really no > need for frameworks or engines (like Rcpp/rJava/V8), this is precisely > what makes Rust so nice as an embedded language, and why it is being > adopted in many C projects such the Linux kernel, that would never > want to deal with Java/C++/JS. > >> I'm not a Rust user myself, but just based on the other languages that have >> interfaces from R I would think that Rust users could coalesce and write a >> package that does the heavy lifting and can be used by packages that contain >> Rust code as a foundation - that's what most other language interfaces do. >> (It's quite possible that some of the projects you listed would be a good >> start). I would not recommend putting that burden onto each package author >> as it screams maintenance nightmare. > > I understand the sentiment but Rust is very different from e.g. Java. > There really isn't much "heavy lifting" to do, because there are no > complex type conversions or runtime library involved. If the same > structs are used in C and Rust, the C functions can directly call Rust > functions and vice versa. Therefore it is possible for libraries to > incrementally port pieces of C code to Rust without breaking the ABI. > Just have a look at the hello world examples such as: > https://github.com/r-rust/hellorust or for a real world example: > https://cran.r-project.org/package=gifski > __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R, Rust and CRAN
On 12 November 2022 at 19:27, Jeroen Ooms wrote: | On Sat, Nov 12, 2022 at 12:49 AM Simon Urbanek | wrote: | > | > this does not directly address your question, but I think it would make a lot of sense to standardize the process, given how many issues there were with packages using Rust (mainly not detecting compilers correctly, not supplying source code, unsolicited writing into user's directories, not checking binaries etc.). Doing this right is not entirely trivial which is presumably where the "friction" comes from. | | All we need is the rustc/cargo toolchain to be installed on the CRAN | win/mac builders (it already is on Fedora/Debian). As mentioned above | (and before in e.g. https://jeroen.github.io/erum2018), rust uses the | native C FFI, does not need any runtime library, and can be called | directly from an R package using the C interface. There is really no | need for frameworks or engines (like Rcpp/rJava/V8), this is precisely | what makes Rust so nice as an embedded language, and why it is being | adopted in many C projects such the Linux kernel, that would never | want to deal with Java/C++/JS. Seconded. CRAN works best when tools are uniformly provided. It would be good to have that for Rust too. (Small nit about C++ here. Its compatibility with C and use of FFI via C is a major reason for its success. As you know there is no run-time so equating with Java or VS is a little off, at least on my ledger.) | > I'm not a Rust user myself, but just based on the other languages that have interfaces from R I would think that Rust users could coalesce and write a package that does the heavy lifting and can be used by packages that contain Rust code as a foundation - that's what most other language interfaces do. (It's quite possible that some of the projects you listed would be a good start). I would not recommend putting that burden onto each package author as it screams maintenance nightmare. | | I understand the sentiment but Rust is very different from e.g. Java. | There really isn't much "heavy lifting" to do, because there are no | complex type conversions or runtime library involved. If the same | structs are used in C and Rust, the C functions can directly call Rust | functions and vice versa. Therefore it is possible for libraries to | incrementally port pieces of C code to Rust without breaking the ABI. | Just have a look at the hello world examples such as: | https://github.com/r-rust/hellorust or for a real world example: | https://cran.r-project.org/package=gifski Again, ditto for C++ but Rust is another very compelling candidate that would be good to support (and to e.g. access projects like polars more easily). CRAN is often seen as having somewhat difficult-to-overcome resistance for outside help (with Rtools4 a very notable and successful exception). Maybe enabling Rust support could be a pilot-project for another approach? Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R, Rust and CRAN
On Sat, Nov 12, 2022 at 12:49 AM Simon Urbanek wrote: > > this does not directly address your question, but I think it would make a lot > of sense to standardize the process, given how many issues there were with > packages using Rust (mainly not detecting compilers correctly, not supplying > source code, unsolicited writing into user's directories, not checking > binaries etc.). Doing this right is not entirely trivial which is presumably > where the "friction" comes from. All we need is the rustc/cargo toolchain to be installed on the CRAN win/mac builders (it already is on Fedora/Debian). As mentioned above (and before in e.g. https://jeroen.github.io/erum2018), rust uses the native C FFI, does not need any runtime library, and can be called directly from an R package using the C interface. There is really no need for frameworks or engines (like Rcpp/rJava/V8), this is precisely what makes Rust so nice as an embedded language, and why it is being adopted in many C projects such the Linux kernel, that would never want to deal with Java/C++/JS. > I'm not a Rust user myself, but just based on the other languages that have > interfaces from R I would think that Rust users could coalesce and write a > package that does the heavy lifting and can be used by packages that contain > Rust code as a foundation - that's what most other language interfaces do. > (It's quite possible that some of the projects you listed would be a good > start). I would not recommend putting that burden onto each package author as > it screams maintenance nightmare. I understand the sentiment but Rust is very different from e.g. Java. There really isn't much "heavy lifting" to do, because there are no complex type conversions or runtime library involved. If the same structs are used in C and Rust, the C functions can directly call Rust functions and vice versa. Therefore it is possible for libraries to incrementally port pieces of C code to Rust without breaking the ABI. Just have a look at the hello world examples such as: https://github.com/r-rust/hellorust or for a real world example: https://cran.r-project.org/package=gifski __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R, Rust and CRAN
Florian, this does not directly address your question, but I think it would make a lot of sense to standardize the process, given how many issues there were with packages using Rust (mainly not detecting compilers correctly, not supplying source code, unsolicited writing into user's directories, not checking binaries etc.). Doing this right is not entirely trivial which is presumably where the "friction" comes from. I'm not a Rust user myself, but just based on the other languages that have interfaces from R I would think that Rust users could coalesce and write a package that does the heavy lifting and can be used by packages that contain Rust code as a foundation - that's what most other language interfaces do. (It's quite possible that some of the projects you listed would be a good start). I would not recommend putting that burden onto each package author as it screams maintenance nightmare. Cheers, Simon > On Nov 12, 2022, at 12:31 AM, Florian Rupprecht wrote: > > Hi all, > > Are there any current recommendations on integrating Rust (and Cargo, its > official package manager) in an R package complying to CRAN's policies? > > To be clear: This question is not about how to integrate Rust in the > package, it is about how to do it without creating friction with the CRAN > team and infrastructure. I want to write the Rust-C-R interface and build > scripts myself. > > To me, Rust seems like a very good fit for R interop as it has a native C > FFI, and has address and UB safety guarantees that top the strictest C++ > compiler warnings. However Rust's standard library is very small by design, > so Cargo integration would be needed. > > I know there is: > > - rextendr (https://cran.r-project.org/package=rextendr): > I don't think there is a package using this on CRAN yet. > > - cargo-framework (https://CRAN.R-project.org/package=cargo) > Removed from CRAN. > > - r-rust/gifski (https://cran.r-project.org/package=gifski) > Downloads precompiled binaries on windows for CRAN (which is, as I > understand it, strongly discouraged for a number of reasons: > https://stat.ethz.ch/pipermail/r-devel/2022-September/082027.html). > > Thank you very much for your time, > Florian > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R, Rust and CRAN
Hi Matthias, Thank you very much for your response! Putting the entire compiler toolchain of Rust into an R package is likely just too much (it would need to compile the entire LLVM compiler which would take hours just to build alone). However, it is a very interesting idea to consider with dependencies. (Having a separate optional package that contains the source code of all Rust-dependencies necessary for the package) So thank you for sharing! I was also made aware of this similar thread: https://stat.ethz.ch/pipermail/r-package-devel/2022q3/008291.html Best, Florian On Fri, Nov 11, 2022 at 8:21 PM matthias-gondan wrote: > Hi Florian, I am doing something similar with Swi-Prolog. Feel free to > contact me if needed. My steps were:Get swipl to compile on Windows, > MSYS2, then Rtools4.2.Then, an R package rswipl that just includes the > swipl runtime for those people who don't have swipl installed. Then > (basically right now, not yet on CRAN), an R package that does the > interface between R and swipl (either installed on the system or the R > package.Best wishes Matthias > Ursprüngliche Nachricht Von: Florian Rupprecht < > floru...@gmail.com> Datum: 11.11.22 12:31 (GMT+01:00) An: List > r-package-devel Betreff: [R-pkg-devel] R, > Rust and CRAN Hi all,Are there any current recommendations on integrating > Rust (and Cargo, itsofficial package manager) in an R package complying to > CRAN's policies?To be clear: This question is not about how to integrate > Rust in thepackage, it is about how to do it without creating friction with > the CRANteam and infrastructure. I want to write the Rust-C-R interface and > buildscripts myself.To me, Rust seems like a very good fit for R interop as > it has a native CFFI, and has address and UB safety guarantees that top the > strictest C++compiler warnings. However Rust's standard library is very > small by design,so Cargo integration would be needed.I know there is:- > rextendr (https://cran.r-project.org/package=rextendr):I don't think > there is a package using this on CRAN yet.- cargo-framework ( > https://CRAN.R-project.org/package=cargo)Removed from CRAN.- > r-rust/gifski (https://cran.r-project.org/package=gifski)Downloads > precompiled binaries on windows for CRAN (which is, as Iunderstand it, > strongly discouraged for a number of reasons: > https://stat.ethz.ch/pipermail/r-devel/2022-September/082027.html).Thank > you very much for your time,Florian [[alternative HTML version > deleted]]__ > R-package-devel@r-project.org mailing listhttps:// > stat.ethz.ch/mailman/listinfo/r-package-devel > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R, Rust and CRAN
Hi Florian, I am doing something similar with Swi-Prolog. Feel free to contact me if needed. My steps were:Get swipl to compile on Windows, MSYS2, then Rtools4.2.Then, an R package rswipl that just includes the swipl runtime for those people who don't have swipl installed. Then (basically right now, not yet on CRAN), an R package that does the interface between R and swipl (either installed on the system or the R package.Best wishes Matthias Ursprüngliche Nachricht Von: Florian Rupprecht Datum: 11.11.22 12:31 (GMT+01:00) An: List r-package-devel Betreff: [R-pkg-devel] R, Rust and CRAN Hi all,Are there any current recommendations on integrating Rust (and Cargo, itsofficial package manager) in an R package complying to CRAN's policies?To be clear: This question is not about how to integrate Rust in thepackage, it is about how to do it without creating friction with the CRANteam and infrastructure. I want to write the Rust-C-R interface and buildscripts myself.To me, Rust seems like a very good fit for R interop as it has a native CFFI, and has address and UB safety guarantees that top the strictest C++compiler warnings. However Rust's standard library is very small by design,so Cargo integration would be needed.I know there is:- rextendr (https://cran.r-project.org/package=rextendr):I don't think there is a package using this on CRAN yet.- cargo-framework (https://CRAN.R-project.org/package=cargo)Removed from CRAN.- r-rust/gifski (https://cran.r-project.org/package=gifski)Downloads precompiled binaries on windows for CRAN (which is, as Iunderstand it, strongly discouraged for a number of reasons:https://stat.ethz.ch/pipermail/r-devel/2022-September/082027.html).Thank you very much for your time,Florian [[alternative HTML version deleted]]__r-package-de...@r-project.org mailing listhttps://stat.ethz.ch/mailman/listinfo/r-package-devel [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
