I would like to open F# compiler solution (FSharp.sln) from https://github.com/fsharp/fsharp/ in an IDE on a mac, then make some changes and run the compiler or ideally step through the code.
I tried JetBrains Rider, but it gets stuck soon after opening the solution: "Initial file processing: prim-type-prelude.fs". Code completion is not available.
I also tried opening another solution from https://github.com/Microsoft/visualfsharp, but both Rider and Visual Studio For Mac crash almost immediately.
What's the best way of working on F# compiler source code on a Mac? Is this feasible only on Windows? I'm new to .net and F#.
Edit: I had much better luck with Windows and Visual Studio. Everything worked pretty much out of the box. I was able to run the project, debug selected test and make minor changes with code completion enabled. I might be missing something, but it seems like it's a much smoother experience on Windows than on a Mac.
Related
When learning about .NET Core, I heard that it would be possible to edit .CS code while debugging (e.g. controllers). Now that we're at .NET Core 2, I still can't find a way to get this to work.
This all stems from working with PHP/JavaScript developers who absolutely hate, with reason, the lack of editing while debugging. You have to stop the app, edit the code, run, wait for build, and then see it. I get it's because of the compilation, but I thought they were changing something in .NET Core and VS 2017. This even goes down to stupid things like adding images to your project.
Any ideas on how to enable some of this?
The answer is yes and no.
There are "watchers" in .NET Core that means your code is constantly recompiled as you make changes. To do this you just add this nuget package :
Install-Package Microsoft.DotNet.Watcher.Tools
And then run the watch command from your command line tool :
dotnet watch run
But again, this is simply recompiling your code as fast as possible so that when you refresh in your browser, the live changes are there. It's similar to other watches in things like Gulp etc.
It's possible to "attach" the debugger to your running instance, but as soon as your code is recompiled you need to reattach the debugger. If you are looking to be able to use breakpoints while using watchers for example, I don't think it's possible.
More info :
https://dotnetcoretutorials.com/2017/01/31/live-coding-net-core-using-dotnet-watch/
https://learn.microsoft.com/en-us/aspnet/core/tutorials/dotnet-watch
I am attempting to debug my Xamarin.Forms app through a Mac Agent on Visual Studio 2015. The iPhone Simulator works well but whenever it comes across an error VS (On Windows) always breaks at the same line, no matter where the error is in the code.
ie. on Main.cs This line:
UIApplication.Main(args,null,"AppDelegate");
The stack info is of no use either. The only way to find the actual error line is to put a break point and step through until it crashes. This is very slow and annoying.
Does anyone know a better way to debug on VS using a Mac Agent?
Thanks in advance
You can go to Debug->Windows->Exception settings and set Common Language Runtime Exceptions to be set. With that your code will break on every exception. Unfortunately, this will also break on exceptions in libraries so that will give you some noice, but this way helped me find some exception causes.
Is it technically possible (I don't think this would be restricted), and how do you go about it?
I got my little test app building fine, but when I run it I get a failure dialog.
The debug output is slightly more informative:
The thread 0xe4c has exited with code -1073741515 (0xc0000135).
The program '[3400] OpenCVTest2.exe' has exited with code -1073741515 (0xc0000135) 'A dependent dll was not found'.
Then I created a Win8 Desktop app, which also built fine but failed to run.
MSVP100D.dll is part of the VC++ 2010 Redistributable which is not compatible with Win8. (Being a hacker I tried it anyway, the installer runs to completion - but the bits aren't installed.)
Is there a compiler flag I can try? Possibly a custom build of OpenCV would fix it, but that would be a last resort, and it might only fix the desktop app.
This guy shows an example of using OpenCV library for performing face detection in a Windows 8 Store app written using C++/CX:
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/DEV322
Also, at the below post he also describes how the C++ Runtime works for Windows 8Store apps:
http://blogs.msdn.com/b/vcblog/archive/2012/09/28/10354327.aspx
MSVP100D is not a part of VC10 redist. Note the "D" at the end of its name. That package only includes release builds. Your release builds should work fine. But mixing libraries from different VC versions might get you in trouble. See this. Your best chance is to build from source with VC11.
I recently installed the latest rounds of Windows updates, including the .NET 4.0 updates and the Visual Studio updates (but not VS2010 SP1). Since then, my F# compiler has been running really, really slow. I thought it might be this problem with crl.microsoft.com, but it turns out not to be. Also, I think mscorsvw.exe has completed running. (I forget the command to force it, but it doesn't kick in, even when the machine is idle.)
Also:
The F# compiler is producing correctly running code, just slowly.
The C# compiler remains as fast as always.
Has anyone else experienced this problem?
-Neil
I forgot to run ngen.exe. After running that, F# compiles are back to normal speed.
-Neil
I'm pretty much at my wits end at the moment.
I am using Delphi 2009 (Update 3) on Vista (service pack 2) and without fail, if integrated debugging is enabled and I try to run a project, it will give an access violation and the project will crash out.
This happens even if I haven't even added any code to the default project template.
The only way I get around this is by disabling the integrated debugger, (then I may as well just be using a text editor and a command line compiler...)
Does anyone have any advice for this? I've been googling without much success.
Thanks in advance.
I have used this combination without any problem.
Have you tried at at a clean machine (just installing delphi and try a "hello world" application?
Go to Project > Options, Compiler tab. Uncheck Optimization, check stack frames. This seems to be the usual advice in the faqs on Delphi debugging. It may only apply to the earlier versions of Delphi but is worth trying.