Add helpful information to the SETUP.md #32
Comments
|
The SETUP.md file is rather unhelpful if you're an Linux command line user. I've found the following to get me at least to the point where I can run the tests:
This isn't perfect though since it doesn't let auto-complete work (needs fsproj files). |
|
Not sure how helpful it is, but with the following trimmed down <?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<ProductVersion>8.0.30703</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{116CC2F9-F987-4B3D-915A-34CAC04A73DA}</ProjectGuid>
<OutputType>Library</OutputType>
<RootNamespace>BobTest</RootNamespace>
<AssemblyName>BobTest</AssemblyName>
<Name>BobTest</Name>
<BuildOrder>
<BuildOrder>
<String>BobTest.fs</String>
</BuildOrder>
</BuildOrder>
<TargetFSharpCoreVersion>4.3.0.0</TargetFSharpCoreVersion>
<MinimumVisualStudioVersion Condition="'$(MinimumVisualStudioVersion)' == ''">11</MinimumVisualStudioVersion>
<OutputPath>bin</OutputPath>
<PlatformTarget>x86</PlatformTarget>
</PropertyGroup>
<ItemGroup>
<Reference Include="mscorlib" />
<Reference Include="System" />
<Reference Include="System.Core" />
<Reference Include="FSharp.Core" />
<Reference Include="nunit.framework">
<HintPath>..\packages\NUnit.Runners\tools\nunit.framework.dll</HintPath>
</Reference>
</ItemGroup>
<ItemGroup>
<Compile Include="Bob.fs" />
<Compile Include="BobTest.fs" />
</ItemGroup>
<Choose>
<When Condition="'$(VisualStudioVersion)' == '11.0'">
<PropertyGroup>
<FSharpTargetsPath>$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets</FSharpTargetsPath>
</PropertyGroup>
</When>
<Otherwise>
<PropertyGroup>
<FSharpTargetsPath>$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\FSharp\Microsoft.FSharp.Targets</FSharpTargetsPath>
</PropertyGroup>
</Otherwise>
</Choose>
<Import Project="$(FSharpTargetsPath)" Condition="Exists('$(FSharpTargetsPath)')" />
</Project> |
|
/cc @jwood803 Just making sure you're seeing this. |
|
Improved version of .fsproj, this one runs unit tests after building: <?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<Configuration>Debug</Configuration>
<Platform>x86</Platform>
<ProductVersion>8.0.30703</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{116CC2F9-F987-4B3D-915A-34CAC04A73DA}</ProjectGuid>
<OutputType>Library</OutputType>
<RootNamespace>BobTest</RootNamespace>
<AssemblyName>BobTest</AssemblyName>
<Name>BobTest</Name>
<BuildOrder>
<BuildOrder>
<String>BobTest.fs</String>
</BuildOrder>
</BuildOrder>
<TargetFSharpCoreVersion>4.3.0.0</TargetFSharpCoreVersion>
<MinimumVisualStudioVersion Condition="'$(MinimumVisualStudioVersion)' == ''">11</MinimumVisualStudioVersion>
<OutputPath>bin</OutputPath>
<PlatformTarget>x86</PlatformTarget>
<MSBuildCommunityTasksPath>.</MSBuildCommunityTasksPath>
</PropertyGroup>
<ItemGroup>
<Reference Include="mscorlib" />
<Reference Include="System" />
<Reference Include="System.Core" />
<Reference Include="FSharp.Core" />
<Reference Include="nunit.framework">
<HintPath>..\packages\NUnit.Runners\tools\nunit.framework.dll</HintPath>
</Reference>
</ItemGroup>
<ItemGroup>
<Compile Include="Bob.fs" />
<Compile Include="BobTest.fs" />
</ItemGroup>
<Choose>
<When Condition="'$(VisualStudioVersion)' == '11.0'">
<PropertyGroup>
<FSharpTargetsPath>$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets</FSharpTargetsPath>
</PropertyGroup>
</When>
<Otherwise>
<PropertyGroup>
<FSharpTargetsPath>$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\FSharp\Microsoft.FSharp.Targets</FSharpTargetsPath>
</PropertyGroup>
</Otherwise>
</Choose>
<Target Name="NUnit">
<PropertyGroup>
<ExeLauncher Condition="('$(OS)' != 'Windows_NT')">mono</ExeLauncher>
</PropertyGroup>
<Exec Command="$(ExeLauncher) ..\packages\NUnit.Runners\tools\nunit-console.exe $(OutputPath)$(AssemblyName).dll"/>
</Target>
<Import Project="$(FSharpTargetsPath)" Condition="Exists('$(FSharpTargetsPath)')" />
<Target Name="AfterBuild" DependsOnTargets="NUnit"></Target>
</Project> |
|
@pminten @jwood803 @kytrinyx I am working on a command-line script that can build and test all exercises. Currently, it is intended to be used in the Travis build (#13), but I could probably rather easily amend it to allow it to run tests from the command-line. I could even do exercise-specific test runs. The only thing I'm not sure of: how can I supply additional files to users when they fetch the exercises? |
|
Any files that you add to an exercise will be fetched to the user, unless it has [Ee]xample in the file name. |
|
@kytrinyx To be clear, that means that if I add a file named Is it also possible to have a file fetched in the root of the language directory, in this case F#? |
|
Correct -- adding a
Not yet. It's on the wishlist, but I haven't had time to implement that. It would require changes to both the x-api and the cli. |
|
Thanks for the heads-up. We'll wait for that then :) |
|
@kytrinyx Any progress on the two issues mentioned before? |
|
No, it has totally gotten lost in the chaos, and I haven't worked on it. As of right now I am putting it on my "think about and make progress on this in the near future" list. Thanks for the reminder! |
|
@kytrinyx No problem, I know you're terribly busy! Thanks for the heads-up. |
|
@kytrinyx Slight bump :) Have you had the opportunity to think about the above issue (how to include extra files when fetching exercises)? |
|
Oh, my. Not really. I am now in a new job and have finished 3 months of intense conference travel, so things are calming down a bit. We need this for several tracks, so I think it needs to go towards the top of the list (finally). |
|
No problem! Great to hear its on the top of the list. Hurray! 🎉 |
|
Beyond the command line stuff (which is awesome) I've never been able to get a single test to successfully run on Xamarin Studio on a Mac. |
|
@rebelwarrior Hmmm, that's odd. I'll see if I can find anything related to this. |
|
I'm sure I'm doing something wrong. But the instructions aren't super clear for Mac.
|
|
I've been thinking on how to improve the workflow of the F# track, and I am considering creating an Another benefit would be that it opens up the possibility for creating a simple build script (using FAKE). That means that people would also be able to run their tests just by running a batch file. We could also provide this build script for every exercises. The main "disadvantage" of the above suggestions is that there are more files fetched, and people might get a bit confused (although I think fsproj files will make sense for virtually everyone). What do you think? @jwood803 @rebelwarrior @pminten @kytrinyx? |
|
Sounds great to me. I think the ppl that are super familiar with VS will know what to do and ppl like me can rely on having the proper files downloaded. Sent from my mobile.
|
|
That would most likely be better for the users so they wouldn't have to go through the trouble of creating their own projects and would greatly simplify the documentation to get started with the track. |
|
+100 for lowering the friction to getting started with the track. |
|
I think that introducing people to FAKE and Paket, via a simple Then in later tests when you might want to introduce FParsec, or show how to use FsCheck for property-based testing, you can simply put a line in the README to say "For this exercise, first run |
|
Getting up to speed on FAKE and Paket was problematic for me when I started, so indeed the hope is that people will get to know it this way. Introducing FParsec later seems to be a great option, especially if we have people try to install it themselves. |
#!/bin/sh
set -e
if [ $# -eq 0 ]; then
srcfile=$(ls -1 *.fs | grep -v Test)
if [ -z "$srcfile" ]; then
echo "found no .fs files, run in a directory with one, or specify one."
echo "usage: $0 [srcfile [testfile]]"
exit 1
fi
fi
if [ $# -lt 2 ]; then
testfile=*Test.fs
testdll="$(echo $testfile | cut -d. -f1).dll"
else
testfile=$2
testdll="$(echo "$testfile" | cut -d. -f1).dll"
fi
srcdll="$(echo "$srcfile" | cut -d. -f1).dll"
nunit=/usr/lib/cli/nunit.framework-2.6.3/nunit.framework.dll
fsharpc -a $srcfile
fsharpc -a -r:$nunit -r $srcdll $testfile
nunit-console --noxml $testdll
rm $srcdll $testdll
|
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
I think there's still value in keeping this one open, so this is a quick ping to prevent the issue being auto-closed. I'd still like to see some sort of scaffolding repo that a newbie could clone and have immediate access to FAKE, Packet, and a build.sh / build.cmd script. |
|
I added the pinned label so probot wont close it for inactivity. |
|
Any progress on this issue? I'm a Linux user and I'm totally lost how to get started. |
|
@Mousaka I don't know that there has been any movement, but this would be a fantastic opportunity to figure out exactly what needs to go into there, if you're willing to help us think this through step by step. The first thing I'm going to try to do is help narrow down where you're stuck—that might be an Exercism problem in general, or an F# problem specifically. Have you ever used Exercism before? We're working on making Exercism easier to use and understand in general. We actually launched a prototype of a new design yesterday that's been in the works for quite a while. I wouldn't recommend trying the prototype yet if you're new to Exercism, but definitely check out the homepage as it does a great job of explaining what Exercism is: https://v2.exercism.io/ How new are you to F#? If you could say a little bit about what type of exposure you've had to F# before, that would help a lot. And finally, I suppose, what have you done so far in the process of trying to get started on this track? (If it feels like the answer to that is "nothing, I have no idea where to begin" that's totally fine, too!) |
|
@Mousaka At the moment, we don't have a detailed workflow. But you should be able to follow the instructions on http://fsharp.org/use/linux/ We will be porting the F# track over to .NET Core, which will make the whole track completely cross-platform. |
|
@kytrinyx @ErikSchierboom Thanks for answering so quickly.
Yes, I have used it before and I've solved around 20 problems or so in Elm, Elixir, Java and JavaScript. My experience is that it has been fairly easy to get started - only being well familiar with Java and JavaScript before starting out.
I am quite new to F# but I have read half a book about it and I have had a basic "hello world"-webserver-project working. After not coding for a while and having a new computer I decided to give F# a go again. This time i started out with the quite new "Rider" IDE from jetbrains. I managed to open an old project of the Exercism "Leap" problem - that I totally forgot how I set up - and I submitted a solution successfully. I can probably manage to do this again if I spend some more time but after one evening trying to do it with Rider unsuccessfully and with MonoDevelop AND with Visual Code (briefly) I really felt like giving up. Edit:
I really don't want to do all these steps for every new problem. I'm sure of course there are a lot smarter ways to this than what I just did but they can probably be difficult for a newbie like me to find. I hope this input can be of some help and I'm happy to try any suggested new solutions or help out more in some way. Cheers |
@Mousaka -- nope, it sounds like this is specifically linked to the F# track, since you've successfully used Exercism for other languages.
Ouch, yes! Neither would I. @ErikSchierboom a few questions about this in general:
You mentioned switching to .NET Core to make the process cross-platform, would that still involve significant setup for each problem? |
|
@Mousaka welcome to the F# track, and I'm sorry that you've had a rough time getting started :( I appreciate your tenacity and taking the time to share your feedback with us. I agree with @kytrinyx's assessment that this is an F# track issue not a larger, Exercism issue. IMO, newcomers to a given track should be able to get the Hello World up and running quickly and seamlessly otherwise it's not going to entice people to stay with the track. With the current F# setup, particularly on Linux we have definitely not achieved that goal. I'd like to breakdown my response into two parts:
What (if anything) can we do in the short term to reduce the barrier of entry to the track?For full disclaimer I am working on Windows so things aren't always the same, but when I did the F# track here was my flow: Onetime setup:
Exercise per workflow:
@Mousaka I would be curious to know if you tried this flow whether it works for you and if there are any Linux only pitfalls I didn't hit since I'm running on Windows. ** @Mousaka you asked what the difference between an fsproj and a sln are and they are ways to split up code. A sln is a larger component that can contain multiple fsproj's inside. One common setup for small projects is to have one sln and then one fsproj for the code and one fsproj for the tests. Fsproj's can have dependencies between them. You don't actually need a sln and can work with a bare fsproj, although Visual Studio prefers having a sln. What is the long term vision for the track?Microsoft has historically been a very Windows-centric company and the older implementations of .NET reflect that. You can get them to run on Linux but it requires a lot of manual tweaking and effort. However, recently Microsoft has changed and have started investing in cross platform which includes the .NET core @ErikSchierboom referred to. .NET core is something that's been designed from the ground up with non-Windows platforms in mind, they're not just an afterthought. @ErikSchierboom has done an incredible job at migrating the C# track to using .NET core including a sample csproj (the fsproj equivalent for C#) for every exercise. That prevents people from having to write the boilerplate code that you do today. The workflow for people in the C# track is:
We want to get there with the F# track as well, but unfortunately it's not free. @ErikSchierboom could give a better estimate on how long it would take to do this, based on his experience doing it with the C# track, but it's something measured in days or weeks not minutes or hours is my guess. @kytrinyx asked if .NET core would take a lot of work to setup each problem and the answer is no. After the initial investment to get .NET core setup, creating a new problem is not a lot of work. I just added a new exercise in the C# track which you can see here: The boilerplate code is the csproj which was a copy/paste from another exercise just renaming the file. |
|
Here's the process I use on Linux:
The first step in making this all work is to download Paket and run
|
|
There is indeed a bit of a learning curve, as well as some manual stuff you have to do at the moment. However, as @robkeim said, we are planning to move to .NET Core which will alleviate most if not all problems. The problem for a long time was: F# support on .NET Core was not in .NET Core 1.0, but with the recently released .NET Core 2.0, we can finally work on adding this integration. It is on the top of the list of the F# track's issues. |
|
FYI: I've started working on this |
|
@ErikSchierboom if you're able to describe it in a way where people could pick off specific pieces I could write about it in the next newsletter and tweet about it and maybe we could get people to help pitch in. |
|
@kytrinyx Well, it's a bit hard as there is a fixed order and most of it is bulk updates. But I'll think about it! Thanks for the offer. |
|
This may be a weird question but why do we need NET.core at all? Isn't F# in mono as well?
Is the testing Lib tied to net.core?
- David
Sent from my mobile.
… On Aug 21, 2017, at 11:27 AM, Erik Schierboom ***@***.***> wrote:
@kytrinyx Well, it's a bit hard as there is a fixed order and most of it is bulk updates. But I'll think about it! Thanks for the offer.
―
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Well, it is not .NET Core per se, I have not phrased it correctly. What we are doing is moving to .NET Standard 2.0, of which .NET Core 2.0 is one of the runtimes. The benefit of moving to .NET Standard 2.0 are many:
I hope I have explained things better. Mono will thus still be a completely viable runtime to use for the F# track. |
|
@robkeim Thanks for your reply and for trying to help me out.
Improved solution 1I did not try your workflow but I tried something similar inspired by what you told me about how solutions-project-structure work:
This made things a bit smoother but still too much hassle in my opinion. At least there is no need of moving around files after fetching or before submitting... Improved solution 2Inspired by @rmunn 's solution I did something similar with some additional scripting...
and
NOTE: My nunit.framework.dll did not have the same path as yours, mine was Then when fetching a new problem I can use my script -> https://gist.github.com/Mousaka/f3b4127d93b73279515d1343d693df3a and a required template fsproj file (mostly copied from the one @rmunn posted but I did some fiddeling with it) -> https://gist.github.com/Mousaka/c5d03a02faa2428eafe36db28bb60be4 and it will fetch the F# problem from exercism and setup the problem directive to be a fsproject The build.sh file is the equivalent of @rmunn This hacky solution took a while to make but after initial setup I can use this workflow for every new problem:
ThoughtsMy experience with F# on linux so far is that following different setups and tutorials are often not that straight forward at this point in time. There are many pitfalls and many inconsistencies. Depending on when you try to install the tooling by following instructions versions may have changed and the only possible way of installing something might not be what the "Getting started" page says anymore. Though I've learned a lot struggling the past days and I'm now able to start with my exercism problems it REALLY glads me to hear that @ErikSchierboom, and hopefully others too, are working on creating a better future for F# and surrounding tooling in the land of Linux =) thank you |
|
In case it can be helpful, I share what I did to work on the F# track. These instructions are confirmed to work as of the time of writing this comment. Here is the Vagrantfile I used: # -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure('2') do |config|
config.vm.box = 'ubuntu/xenial64'
# Hey why not put C# on too, since we have Mono ready to go...
config.vm.synced_folder '../csharp', '/vagrant_csharp'
config.vm.provision 'shell', inline: <<-SHELL
ln -s /vagrant /home/ubuntu/fsharp
ln -s /vagrant_csharp /home/ubuntu/csharp
apt-get update
apt-get install -y mono-devel fsharp nunit-console
SHELL
endHere is the #!/bin/sh
set -e
if [ $# -eq 0 ]; then
srcfile=$(ls -1 *.fs | grep -v Test)
if [ -z "$srcfile" ]; then
echo "found no .fs files, run in a directory with one, or specify one."
echo "usage: $0 [srcfile [testfile]]"
exit 1
fi
fi
if [ $# -lt 2 ]; then
testfile=*Test.fs
testdll="$(echo $testfile | cut -d. -f1).dll"
else
testfile=$2
testdll="$(echo "$testfile" | cut -d. -f1).dll"
fi
srcdll="$(echo "$srcfile" | cut -d. -f1).dll"
nunit=/usr/lib/cli/nunit.framework-2.6.3/nunit.framework.dll
fsharpc -a $srcfile
fsharpc -a -r:$nunit -r $srcdll $testfile
nunit-console --noxml $testdll
rm $srcdll $testdllGiven that my Exercism directory is ~/exercism:
|
|
@Mousaka If you're interested, you can follow progress on this issue on my branch: https://github.com/ErikSchierboom/fsharp/tree/dotnet-core |
|
@petertseng I like how you use vagrant to make the installation setup more consistent. If someone would try my setup it's likely they're gonna run in to trouble. But in some way isn't it kind of a weird setup to have to run tests in a VM but code on host? I guess maybe it's kind of like having a build server you push changes to except that it's the only way to run tests. |
I guess I don't notice the difference because it's all in a terminal no matter whether it's on the host machine or the VM. It is possible I accidentally try to start up my text editor in the VM or test.sh on the host machine, but rare. |
|
@ErikSchierboom Great job! I will try it out. I saw the PR you merged.. it looked like a lot of work.. so.. Really awesome that you did all that for all the F#-curious people out there!! thank you so much 🎊 👍 |
|
Really easy to fetch problems and get going now!! Love it. You only have to type three commands to run tests now replace last command with something like |
|
@Mousaka Thanks for testing! Great to hear it works :) |
The contents of the SETUP.md file gets included in
the README.md that gets delivered when a user runs the
exercism fetchcommand from their terminal.
At the very minimum, it should contain a link to the relevant
language-specific documentation on
help.exercism.io.
It would also be useful to explain in a generic way how to run the tests.
Remember that this file will be included with all the problems, so it gets
confusing if we refer to specific problems or files.
Some languages have very particular needs in terms of the solution: nested
directories, specific files, etc. If this is the case here, then it would be
useful to explain what is expected.
Thanks, @tejasbubane for suggesting that we add this documentation everywhere.
See exercism.io#2198.
The text was updated successfully, but these errors were encountered: