Skip to content
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

Bump F# to 4.7 #16763

Closed
auduchinok opened this issue Sep 10, 2019 · 25 comments
Closed

Bump F# to 4.7 #16763

auduchinok opened this issue Sep 10, 2019 · 25 comments
Assignees
Labels

Comments

@auduchinok
Copy link

Please update the F# compiler bundled to Mono distribution.

It's probably finally the time to have it updated after the 4.5 update celebration time. #10919 (comment) :)

@marek-safar
Copy link
Member

/cc @steveisok

@abhsrivastava
Copy link

Can you please prioritize this. Anonymous records are so cool

@auduchinok
Copy link
Author

@cartermp Is there a chance the F# compiler in Mono distribution could be aligned with .NET Core SDK releases?

@cartermp
Copy link

Not that I'm aware of. We just produce the bits; Mono infrastructure still needs to do dependency uptake. I don't know how that's handled on the Mono repo.

@auduchinok auduchinok changed the title Bump F# to 4.6 Bump F# to 4.7 Sep 25, 2019
@charlesroddie
Copy link

Will the situation remain like this (difficult manual updates) until .Net 5 comes out?
Presumably when .Net 5 comes out this problem goes away?

Currently the average F#/Xamarin user will have no idea what F# features can be used. You have to search through a lot of github issues and be a compiler expert to work out the current status.

Until the underlying problem is fixed we need an F# language status showing the latest F# version that can be used on different systems. I gather this is currently: VS2019: 4.7. VS4Mac: 4.5. Mac builds without VS4Mac: 4.5.

Related issue which presumably affects a disjoint set of F# mac and/or Xamarin usage: mono/monodevelop#8864

@nosami
Copy link
Member

nosami commented Nov 6, 2019

cc @dsyme

@nosami
Copy link
Member

nosami commented Nov 6, 2019

Not that I'm aware of. We just produce the bits; Mono infrastructure still needs to do dependency uptake. I don't know how that's handled on the Mono repo.

Mono builds F# from the fsharp/fsharp repo. That has since been deprecated in favor of dotnet/fsharp (fsharp/fsharp#903)

F# 4.7 from dotnet/fsharp doesn't work under Mono. Mono isn't targetted by the build scripts - only netcoreapp2.1 output is produced.

image

@dsyme
Copy link
Contributor

dsyme commented Nov 7, 2019

The situation is unsatisfactory, though I'm not certain the best path. It depends

  1. on the Xamarin/mono roadmap

  2. the level of difficulty in preparing an F# 4.7 for mono. (I suspect it would be a lot less work than F# 4.5, just integrating across the non-project-file changes in src/fsharp into fsharp/fsharp, but it would need to be done carefully)

@akoeplinger
Copy link
Member

I looked at this a month ago and was able to get it mostly working by continuing the work done by @baronfel in baronfel/fsharp#1 and merging in master, I pushed it to https://github.com/akoeplinger/fsharp/tree/mono. There are some parts that I don't fully understand so it probably needs more tweaks.

Unfortunately another task preempted me from finishing this for now.

@baronfel
Copy link

baronfel commented Nov 7, 2019

Oh that's great news @akoeplinger! I think I had got most of the way to a working build, but the specifics of recreating the installed binaries tree during make install eluded me. I wasn't sure what mono was still supporting for the old F# build targets vs. going all-in on requiring fsharp.core via packagereference like the new SDK does.

@vshapenko
Copy link

Any updates on issue?

@akoeplinger akoeplinger assigned nosami and unassigned akoeplinger Apr 5, 2020
@vshapenko
Copy link

@dsyme , may you take a look at this issue? Looks forbidden and forgotten for unknown reasons

@jwosty
Copy link

jwosty commented May 24, 2020

It would be great if this could be resolved. Having mono be 2 F# versions behind, using the compiler that was current almost 2 years ago is not a good look. The result is that its simply impossible to use modern F# in Xamarin or mono applications... This is sorely needed. My current fix is to rip out anonymous records from my code in order to get it to build on macOS. 😢

@charlesroddie
Copy link

charlesroddie commented May 26, 2020

Reporting on slack discussions. It turns out the problem is rather contained.

  1. The problem is isolated to mono builds on MacOS and will go away with dotnet5. Mono/mono has the problematic fsharp/fsharp references under MacSDK. dotnet/runtime doesn't have any fsharp reference except in tests (so the parts of mono that were merged in don't contain the problem).
  2. @TimLariviere reports that you can build netstandard F# 4.7 projects using dotnet build on Mac. So in Xamarin.Forms, if you have the platform-specific Xamarin projects in C# (or F# 4.5) you can use F# 4.7 features in referenced netstandard projects with a dotnet build pre-build step in the platform projects.

@vshapenko
Copy link

@charlesroddie The question is, how to be with projects targeting android or ios using f# 4.7. For now, we are forced to build our ios applications on windows using mac as pairing counterpart. Does not looks solid when i cant build an ios app on MacOS itself. I understand reasons about upcoming net 5 (in November), but this story has begun long ago. No blames, but it looks like a problem nobody responsible wants to solve by unknown reasons.

@charlesroddie
Copy link

charlesroddie commented May 27, 2020

@vshapenko You seem to be replying to the answer (point 2 above) with the question. Usually it's the other way around!

@vshapenko
Copy link

@vshapenko You seem to be replying to the answer (point 2 above) with the question. Usually it's the other way around!

That does not solve the problem if ios/android project written using f# 4.7 features. And yes, this is a (possibly) working solution. But anyway , current state of f# support in mono for macos brings much pain for those who are developing for ios.

@charlesroddie
Copy link

Usually there is minimal code in platform-specific projects if using Xamarin.Forms. Understood that it may not resolve the problem for devs using Xamarin.iOS and Xamarin.Android directly instead of Forms. But for a large majority of F#/Xamarin use it's a workaround that should address the problem until Nov when dotnet5 comes out. Main pain point is that you need to know about this thread and put in a pre-build step.

@Dolfik1
Copy link

Dolfik1 commented May 27, 2020

Usually there is minimal code in platform-specific projects if using Xamarin.Forms. Understood that it may not resolve the problem for devs using Xamarin.iOS and Xamarin.Android directly instead of Forms. But for a large majority of F#/Xamarin use it's a workaround that should address the problem until Nov when dotnet5 comes out. Main pain point is that you need to know about this thread and put in a pre-build step.

I tried to build shared project with dotnet build command and then build iOS project from VS for Mac, but got this error:
изображение

@charlesroddie
Copy link

charlesroddie commented May 27, 2020

I added "Or F# 4.5" based on this conv:

@charlesroddie Do we know what happens if you have project A using F# 4.7 features, and dotnet build it, and reference it from an F# Xamarin.ios project which uses F# 4.5 features, and build the latter on a Mac? (edited)
@cartermp If A exposes something that F# 4.5 doesn't understand, it won't work (just typical forwards-compatibility woes). But otherwise it should work, since things are binary compatible. I can publish a NS 2.0 library with the latest preview of the F# compiler and you can consume that from a Xamarin app

Does "expose" means forming part of the public API? So the netstandard libraries can contain anonymous records that are private/internal/locally scoped?

We don't use F# platform-specific projects so can't test this ourselves.

@TimLariviere
Copy link

I guess, as long as you don't directly interact with F# > 4.5 features in your F# Android/iOS projects, it will work.

I have an example here: https://github.com/TimLariviere/Fabulous/blob/a16badd359de2c270c60ba467c8f284b20da9187/Fabulous.XamarinForms/samples/CounterApp/CounterApp/CounterApp.fs

I'm using anonymous records and open static classes in a .NET Standard 2.0 project.
It builds with dotnet 3.1.300, then Android/iOS builds and runs fine. (don't rebuild though, otherwise MSBuild will try to build the shared project itself and it will fail).

@Dolfik1
Copy link

Dolfik1 commented May 27, 2020

I added "Or F# 4.5" based on this conv:

@charlesroddie Do we know what happens if you have project A using F# 4.7 features, and dotnet build it, and reference it from an F# Xamarin.ios project which uses F# 4.5 features, and build the latter on a Mac? (edited)
@cartermp If A exposes something that F# 4.5 doesn't understand, it won't work (just typical forwards-compatibility woes). But otherwise it should work, since things are binary compatible. I can publish a NS 2.0 library with the latest preview of the F# compiler and you can consume that from a Xamarin app

Does "expose" means forming part of the public API? So the netstandard libraries can contain anonymous records that are private/internal/locally scoped?

We don't use F# platform-specific projects so can't test this ourselves.

We have referenced project with anonymous records, but they do not used in iOS project

@jwosty
Copy link

jwosty commented May 28, 2020

I do want to clarify why this is an issue without a solution for me in particular right now, today. I have a cross-platform application that does audio processing. There is a huge chunk of shared code between platforms targeting .Net Standard, and so that bit could theoretically use F# 4.7 with @charlesroddie 's approach. However I do end up with large chunks of code that directly use the Xamarin.Mac bindings to Apple's CoreAudio APIs, and so those bits have to be dependent on whatever version of F# Xamarin.Mac works with. It sounds like this will go away with .Net 5, at which point (AFAIK) I will be able to use .Net 5 + Xamarin.Mac + F# 4.7, is that correct? That just means I have to wait until .Net 5 is release. Which I can deal with since it's supposed to come out soon (a few months).

@KirillOsenkov
Copy link
Member

@marek-safar this is a very impactful issue, we get tons of feedback on this

akoeplinger added a commit that referenced this issue Oct 27, 2020
jonpryor added a commit to jonpryor/xamarin-android that referenced this issue Nov 6, 2020
Context: mono/mono#16763
Context: mono/mono#20490
Context: mono/mono#20533
Context: xamarin/xamarin-macios#9949

Changes: mono/mono@ca11fb0...ac59637

  * mono/mono@ac596375c76: Add support for OP_FCONV_TO_I to mini-arm64.c. (#20548)
  * mono/mono@392fe5b87b2: [2020-02][watchOS] Add simwatch64 support (#20552)
  * mono/mono@a22ed3f094e: Fix potential crash for Encoder.Convert (#20522)
  * mono/mono@970783731fc: Bump to F# 5.0 (#20511)
  * mono/mono@32ab5066f72: Bump msbuild to fix a build issue
  * mono/mono@93a7fe77e8e: Ensure special static slots respect alignment. (#20506)
  * mono/mono@3db5b358413: [debugger] Switch to GC Unsafe in signal handler callbacks (#20495)
  * mono/mono@af315f44c40: [2020-02][corlib] ThreadAbortException protection for ArraySortHelper (#20468)
jonpryor added a commit to dotnet/android that referenced this issue Nov 9, 2020
Context: mono/mono#16763
Context: mono/mono#20490
Context: mono/mono#20533
Context: xamarin/xamarin-macios#9949

Changes: mono/mono@ca11fb0...ac59637

  * mono/mono@ac596375c76: Add support for OP_FCONV_TO_I to mini-arm64.c. (#20548)
  * mono/mono@392fe5b87b2: [2020-02][watchOS] Add simwatch64 support (#20552)
  * mono/mono@a22ed3f094e: Fix potential crash for Encoder.Convert (#20522)
  * mono/mono@970783731fc: Bump to F# 5.0 (#20511)
  * mono/mono@32ab5066f72: Bump msbuild to fix a build issue
  * mono/mono@93a7fe77e8e: Ensure special static slots respect alignment. (#20506)
  * mono/mono@3db5b358413: [debugger] Switch to GC Unsafe in signal handler callbacks (#20495)
  * mono/mono@af315f44c40: [2020-02][corlib] ThreadAbortException protection for ArraySortHelper (#20468)
jonpryor added a commit to jonpryor/xamarin-android that referenced this issue Nov 22, 2020
Context: dotnet/runtime#35008 (comment)
Context: mono/mono#15418
Context: mono/mono#16763
Context: mono/mono#20490
Context: mono/mono#20533
Context: xamarin/xamarin-macios#9949

Changes: mono/mono@be2226b...ac59637

  * mono/mono@ac596375c76: Add support for OP_FCONV_TO_I to mini-arm64.c. (#20548)
  * mono/mono@392fe5b87b2: [2020-02][watchOS] Add simwatch64 support (#20552)
  * mono/mono@a22ed3f094e: Fix potential crash for Encoder.Convert (#20522)
  * mono/mono@970783731fc: Bump to F# 5.0 (#20511)
  * mono/mono@32ab5066f72: Bump msbuild to fix a build issue
  * mono/mono@93a7fe77e8e: Ensure special static slots respect alignment. (#20506)
  * mono/mono@3db5b358413: [debugger] Switch to GC Unsafe in signal handler callbacks (#20495)
  * mono/mono@af315f44c40: [2020-02][corlib] ThreadAbortException protection for ArraySortHelper (#20468)
  * mono/mono@ca11fb0fd81: [2020-02] Bump ikvm-fork to include mono/ikvm-fork#20 (#20452)
@charlesroddie
Copy link

charlesroddie commented Dec 3, 2020

I'm figuring the status of this, in public in case it interests anyone on this thread.

The F# 5.0 update is in:

This documentation PR for azure pipelines/github actions, created 2 days ago and just merged, includes these updates for VS for Mac and mono: actions/runner-images#2183 . Assuming this is correct, this is now deployed to azure pipelines.

jonpryor added a commit to jonpryor/xamarin-android that referenced this issue Dec 14, 2020
Context: dotnet/runtime#35008 (comment)
Context: mono/mono#15418
Context: mono/mono#16763
Context: mono/mono#20490
Context: mono/mono#20533
Context: xamarin/xamarin-macios#9949

Changes: mono/mono@be2226b...5e9cb6d

  * mono/mono@5e9cb6d1c1d: Use explicit arithmetic checks in the amd64 watchOS simulator. (#20647)
  * mono/mono@4fdfb5b1fd5: Bump bockbuild for gtk+ patch
  * mono/mono@6f6c3286b66: [runtime] Avoid checking for hardened runtime on ios, its not needed, and it causes alerts because of PROT_WRITE|PROT_EXEC. (#20623)
  * mono/mono@124f1157141: Fix iOS sdks build on Xcode 12 (#20574)
  * mono/mono@dfbfe5eed19: [2020-02] Build makefile to support Mac Catalyst (#20566)
  * mono/mono@ac596375c76: Add support for OP_FCONV_TO_I to mini-arm64.c. (#20548)
  * mono/mono@392fe5b87b2: [2020-02][watchOS] Add simwatch64 support (#20552)
  * mono/mono@a22ed3f094e: Fix potential crash for Encoder.Convert (#20522)
  * mono/mono@970783731fc: Bump to F# 5.0 (#20511)
  * mono/mono@32ab5066f72: Bump msbuild to fix a build issue
  * mono/mono@93a7fe77e8e: Ensure special static slots respect alignment. (#20506)
  * mono/mono@3db5b358413: [debugger] Switch to GC Unsafe in signal handler callbacks (#20495)
  * mono/mono@af315f44c40: [2020-02][corlib] ThreadAbortException protection for ArraySortHelper (#20468)
  * mono/mono@ca11fb0fd81: [2020-02] Bump ikvm-fork to include mono/ikvm-fork#20 (#20452)
jonpryor added a commit to dotnet/android that referenced this issue Dec 15, 2020
Context: dotnet/runtime#35008 (comment)
Context: mono/mono#15418
Context: mono/mono#16763
Context: mono/mono#20490
Context: mono/mono#20533
Context: xamarin/xamarin-macios#9949

Changes: mono/mono@be2226b...5e9cb6d

  * mono/mono@5e9cb6d1c1d: Use explicit arithmetic checks in the amd64 watchOS simulator. (#20647)
  * mono/mono@4fdfb5b1fd5: Bump bockbuild for gtk+ patch
  * mono/mono@6f6c3286b66: [runtime] Avoid checking for hardened runtime on ios, its not needed, and it causes alerts because of PROT_WRITE|PROT_EXEC. (#20623)
  * mono/mono@124f1157141: Fix iOS sdks build on Xcode 12 (#20574)
  * mono/mono@dfbfe5eed19: [2020-02] Build makefile to support Mac Catalyst (#20566)
  * mono/mono@ac596375c76: Add support for OP_FCONV_TO_I to mini-arm64.c. (#20548)
  * mono/mono@392fe5b87b2: [2020-02][watchOS] Add simwatch64 support (#20552)
  * mono/mono@a22ed3f094e: Fix potential crash for Encoder.Convert (#20522)
  * mono/mono@970783731fc: Bump to F# 5.0 (#20511)
  * mono/mono@32ab5066f72: Bump msbuild to fix a build issue
  * mono/mono@93a7fe77e8e: Ensure special static slots respect alignment. (#20506)
  * mono/mono@3db5b358413: [debugger] Switch to GC Unsafe in signal handler callbacks (#20495)
  * mono/mono@af315f44c40: [2020-02][corlib] ThreadAbortException protection for ArraySortHelper (#20468)
  * mono/mono@ca11fb0fd81: [2020-02] Bump ikvm-fork to include mono/ikvm-fork#20 (#20452)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.