-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
.NET 5 Support #210
.NET 5 Support #210
Conversation
- New style SDK projects - Change remoting to System.IO.Pipes - Started migration of FAKE to v5
- tested on macos 11 big sur apple silicon m1
Wow! Thanks for doing all this work! I am no longer actively involved in the project (or in the .NET world really) but I would be happy to merge the PR if nobody else who is more involved has an opinion. What is the backwards-compat story with these changes? What happens if someone is using RProvider with an older .NET version with which it is currently compatible? |
@AndrewIOM. This is big! Thanks a lot for making it happen. I would like to test it locally and see whether Deedle's RProvider plugin can work with this as you already target .Net 5 while Deedle is still on netstandard2.0. |
Thanks for the input. I've had a quick look into the backwards compatability issues. It looks like only the xunit.runner.visualstudio package is dependent on greater than netstandard2.0; this can be downgraded to version 2.4.1 for netstandard2.0. I got RProvider itself to build on netstandard2.0 easily by replacing any references to net5.0. However, I'm not sure how to handle packaging up the RProvider.Server app, as netcoreapp older versions are no longer supported. I can invesstigate further. A second problem is that I assumed that mono and .net framework support could be dropped and removed a check that changed the running of RProvider.Server from mono to dotnet (see RInteropClient.fs line 62). I'm not sure if figuring out how to set this up to support .NET Framework and mono could be complex, or if the same exe / dll could be called from both mono and dotnet. Any expertise appreciated. Perhaps people on .NET Framework and mono could continue to use the previously released package and this project could support .NET Core / 5 going forward? |
Make the clean break to .NET 5. Many other projects have already done this. |
This is fantastic work. |
@AndrewIOM If you agree I would like to make you co-maintainer on this project, given the depth and quality of this work. @zyzhu I trust that would be ok? |
@AndrewIOM I'll marge this. but we also need to re-enable automated CI testing - the Travis support can be removed in favout of new Github actions. I'll make a start on that now, if you could help get it green that would be great |
Of course. 👍 BTW, @AndrewIOM, I have difficulties building it locally on Windows at the step of building test project.
I tried it on Mac but I'm not sure how to setup R_HOME environment correctly on Mac. I got the following error message
|
@dsyme Thanks for checking the code and kind words. I'm more than happy to be co-maintainer on this project and help it move forward. Would like for F# to become more widely adopted in scientific research. @zyzhu I can have a look at the issue tomorrow, although I'm currently travelling without a Windows machine. For Mac, you can export the R_HOME env variable temporarily within an open terminal session with: export R_HOME=somepath Where somepath is the output of R RHOME It would be ideal if we can set this value automatically given that the code is already retrieving it from running R RHOME. |
👍 This is fantastic work and I second @dsyme's suggestion to make you a co-maintainer of the project if you are up for that! |
@hmansell @tpetricek @zyzhu @muehlhaus let me know if any of you no longer want to be maintainers (you all have "maintain" access right now) thanks |
I don't need to be maintainer anymore. We are in good hands now. 👍 |
I don’t think it makes sense for me to be a maintainer anymore, either, sad
to say…
…On Tue, Sep 14, 2021 at 8:14 AM Zhenyong Zhu ***@***.***> wrote:
I don't need to be maintainer anymore. We are in good hands now. 👍
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#210 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHPPC2MABCARXLBWGNZIP3UB44APANCNFSM5DZSGNFA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
I also do not need to be a maintainer of RProvider. I agree with @zyzhu and @dsyme, it is awesome to see @AndrewIOM excellent contributions driving FsLab further into data science. |
I also do not need to be a maintainer, but if it is useful to have someone on the list as a backup in case everyone else gets hit by a bus, I'm happy to remain listed. (But I'm also owner of the fslaborg organization and the www.fslab.org domain, which I'm happy to keep paying for - right now, it is paid for until October 2024...) |
Thank you @tpetricek, @muehlhaus - adjsutments made! |
Have you enabled .net core scripting in VS too? I'll get the nuget publish key added later tonight |
Yep: Microsoft (R) F# Interactive version 11.4.2.0 for F# 5.0 I checked last night around 23:00 EST, 27 Sep: #r "nuget: RProvider" still yields compiler error with ... R.NET failed initialization ... |
Doesn't work for Windows and R 4.0.2 and later. #r "nuget: RProvider" All get compilers errors with R.NET initialization failed. @AndrewIOM Thank you for the light. This tunnel was so dark & cramp. You essentially brought something valuable back from the dead. Hallelujah JesusIOM, no pun intended ... |
I have been working to get the RProvider running on .NET5 using the dotnet sdk.
To get RProvider to work, I had to update the following:
I have tested this implementation using both the .NET 5 and .NET 6 preview 7 SDKs, with all tests passing and sample scripts working as expected. This is on macOS 11 Big Sur on both an Intel mac and M1 mac. I have tested against the latest R version 4.1.1 (2021-08-10) -- "Kick Things"
There was a small change required to the PipeMethodCalls library, but I was unsure if this is something that can be addressed in RProvider. Essentially, there is an issue with reflection where I needed to use GetRuntimeMethods rather than GetMethods to discover the interface's methods.
NB The only prerequisite to run is that R_HOME environment variable is set.
Addresses issues #188.
Follows discussion in #209