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

Use process dependencies for fsi #6324

Merged
merged 8 commits into from
Apr 1, 2019

Conversation

KevinRansom
Copy link
Member

So …

1:
with the current dotnet fsi command:

open System.Diagnostics
printfn "%x" (Process.GetCurrentProcess());;

Yields an error:

  printfn "%x" (Process.GetCurrentProcess());;
  --------------^^^^^^^

stdin(2,15): error FS0039: The value, namespace, type or module 'Process' is not defined.

This occurs because neither the dotnet cli doesn't list the implementation assembly that contains the netstandard 2.0 Apis for System.Diagnostics.Process.

This change recurses the dependencies of netstandard2.0 to collect all of the dependent assemblies, so we don't have to manually list out all of the dependent assemblies.

2:
Moves the implementation out into a separate source file DotnetFrameworkDependences.fs rather than smack in the middle of CompileOps.fs.

3:
COMPILER_SERVICE_ASSUMES_DOTNETCORE_COMPILATION is not used in this repo, or the CompilerService repo.

**** NOTE ****
In dotnet 3.0 FSI compile time references will be against reference assemblies not implementation assemblies. This PR continues our current behavior of using implementation assemblies. We are negotiating APIs that will make it possible for us to more easily find the correct reference assemblies in SDK installs.

Because the current implementation is against implementation assemblies, care must be taken when creating cross platform scripts. If you only use netstandard 2.0 Apis, in your scripts they will work well.
But you may see "Not Implemented exceptions" if you use an API that isn't implemented on all platforms.

@cartermp
Copy link
Contributor

Link #6215

if assumeDotNetFramework then
getDependenciesOf (getDesktopDefaultReferences useFsiAuxLib)
else
// Coreclr supports netstandard assemblies only for now
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we expand this to also include the closure of netcoreapp? This would allow things like span in scripting

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cartermp
as discussed, here is using Span.

c:\kevinransom\visualfsharp>artifacts\toolset\dotnet\dotnet.exe artifacts\bin\fsi\Release\netcoreapp2.1\fsi.exe

Microsoft (R) F# Interactive version 10.2.3 for F# 4.5
Copyright (c) Microsoft Corporation. All Rights Reserved.

For help type #help;;

> // Learn more about F# at http://fsharp.org

open System

//[<EntryPoint>]
let main argv =
    printfn "Hello World from F#!"

    let t = Span.Empty
    0 // return an integer exit code
let _ = main [| "Hello" |];;
Hello World from F#!
val main : argv:'a -> int

Span can't be a top level function in fsi. Perhaps we need to think about how that might look if we enabled it. Or may not.

@KevinRansom
Copy link
Member Author

@dsyme, please take a look at this.

  • This uses the coreclr implementation assemblies for compilation on coreclr. Instead of listing them, I just reflect over them to get the dependencies.

  • Desktop is as before.

  • I refactored the code out of CompileOps.fs into DotNetFrameworkDependencies.fs.

  • I will be submitting a new PR shortly adding support for coreclr framework reference assemblies packages.

@KevinRansom KevinRansom merged commit e1f4933 into dotnet:master Apr 1, 2019
@cartermp
Copy link
Contributor

cartermp commented Apr 1, 2019

@KevinRansom can you verify this one works? #6215

@KevinRansom
Copy link
Member Author

> open System.Net.Http;;
> let client=HttpClient();;

  let client=HttpClient();;
  -----------^^^^^^^^^^^^

stdin(2,12): warning FS0760: It is recommended that objects supporting the IDisposable interface are created using the syntax 'new Type(args)', rather than 'Type(args)' or 'Type' as a function value representing the constructor, to indicate that resources may be owned by the generated value

val client : HttpClient

>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants