WIP - Fsi module

[vanceism7]

@matthid: This module is basically finished (depending on your view point), I just have a few questions to clear up. Fsi module is essentially built the same exact way the fsc module is. There were two sets of code here, one to run an external exe and one to run the internal fsi from fsharp compiler service. I think it may be better to split these into two modules such as DotNet.Fsi.Exe and DotNet.Fsi.Service, but if consistency is more important, I can put both inside a basic DotNet.Fsi module like we did with DotNet.Fsc. If we do take the two module route, do you have any naming suggestions? Calls to Exe.function don't look super great in a script since Exe is very vague. Not sure how I should name these if we keep it as two.

Also, as was mentioned previously, the internal FCS version of fsi is not currently working in .net core so should we just release the external exe functionality for now or should both be added before releasing this module?

[matthid]

I think we can have a uniform API to use across FSharp.Compiler.Service and external process. We can have a property for that in the arguments (UseExternalProcess for example).

Also I'm completely happy if we skip FSharp.Compiler.Service for now because I have some notes on that:

• We should probably remove the caching implementation (it is basically buggy and you don't get that when using an external process) - the reason it is there is historic (because we shared this implementation for running fake itself).
• The Service implementation contains some hacks we probably can clean up

If you decide to keep the FSharp.Compiler.Service implementation in this PR I can do a more thorough review once the caching is removed.

Regarding the external process I think we need to look at some examples how this new API is used. Ideally - according to API guidelines - we should

open Fake.DotNet

Fsi.exec (fun p -> { w with ... })

But it seems currently we need to (or "can do" depending on the view)

open Fake.DotNet.Fsi

Exe.execFsiSimple ...

Which is a bit unusual to how other modules work. I guess we should do some minor refactorings there in order to get the above. What do you think? At the very least we should probably add some example usages in the in-line comments to guide users into the "proper"/"suggested" usage scenario.

[vanceism7]

I agree, the current usage is definitely a little awkward. I wish f# allowed modules to be split between files haha, that would have alleviated some of weirdness of its current usage. For now, I'll work to get it back to a more consistent usage of just Fsi.exec, with some sort of arg to choose between external or internal fsi. I'll look more into the internal FCS implementation after that

[vanceism7]

Hey @matthid, I think I've fixed up the API a lot better now. I also added in the FCS runner, but I don't totally know if this is working correctly or not since I believe it doesn't work on netcore yet. I did get some scripts to run in fsi successfully but I was getting weird errors regarding cli arguments and things of that sort. Also I'm not sure if it's missing something in comparison to the old yaaf implementation. I've left it commented out for now but if this all seems good to you, I can uncomment it and finish the process of adding this module to the set of fake 5 modules

[matthid]

Looks good, can you add src/app/Fake.DotNet.Fsi/Fake.DotNet.Fsi.fsproj to Fake.sln (otherwise I'm not sure it is built at all)

[vanceism7]

Hey @matthid: I think this is ready. The checks are failing for the 'Tests' target, I don't believe its related to my changes. Also, I apologize for the mixed up commits, they got a little messed up it seems. My rebase was acting weird and I couldn't figure out how to get it working without overwriting my commits. Let me know if I need to put any more effort towards fixing it or if its ok as is.

[matthid]

changed the base to release/next as there was a problem with some tests, can you commit a dummy commit to trigger CI (or rebase)?

[matthid]

I guess this doesn't work, have you tried that?
(because args.ToWindowsCommandLine is doing the escaping FSI will get a literal quote character).
I think we can just remove the quotes from the sprintf.

I guess the same is for argls

[vanceism7]

Ah I guess I didn't test that one. Ill give it a look

[vanceism7]

It looks like it actually works either way, literal quotes in the argument or not -- but I removed them anyways

BTW: I don't know if arguments are passed into the internal FCS version of fsi the same way they are with the cli. I'm basically passing them in the same except I don't include the script to be run in the arguments since thats passed to FsiSession.EvalScript function. Now that I think of it, I didn't run FsiSession in its own process either...

[matthid]

I'd have expected the quotes to be "quoted" again later, strange

[matthid]

Thanks! After looking at this several times I'll probably change some details:

• comment the "internal" version
• rename execExternal to exec and execExternalRaw to execRaw
• we can switch to "internal" via a new flag in FsiParams,
• Will change the "ToolPath" to a DU with "Internal" and "External" - throws NotSupportedException when using "Internal"

What do you think?

[vanceism7]

That all sounds good to me. I had thought about the param to switch between external and internal previously, I just was debating with myself if keeping fsiparams specifically for fsi args was better for design

[matthid]

@vanceism7 Please consider reviewing 575330d

[vanceism7]

I'll try and check it out hopefully later today or sometime this weekend. Thanks for your help! @matthid