You might have seen this on IRC, but I’ve been working on reviving the old Haiku port of Mono. There has been code, but of course, refactors happen, bitrot occurs. The good news is I’ve documented the basics of what needed to be done and am working on getting changes merged upstream.
The bad news? Neither C# compiler (The default Microsoft one, or Mono’s) works; and it seems both are due to issues related to reflection. I’m trying to see if I can get a Mono internals expert to look at this.
Having Mono on Haiku would be epic! Keep up the good work…
Awesome job! Mono would be an overkill for people like me (.NET all the way). I tried to look through dependencies needed for .NET Core, but we don’t seem to be able to port it any time soon. Thank you for reporting the progress as well. Good luck on that! 
CoreCLR looks a bit trickier to port, and there was already the groundwork of it in the Mono tree - as well as some less hairy dependencies.
Once Mono works enough, the next goal will be writing BeAPI bindings.
It would be great if you could provide commands you used to compile it and where can you get Roslyn executable (I don’t see anything in their GitHub repo).
This would make it easier for others to look what might be causing the issue.
EDIT: now I see that apparently autogen downloads Roslyn.
My branch (in the pull request) is all set up; just run ./configure; make (and probably want to do -j, Haiku is good at that 
)
It’ll download Roslyn or mcs when running the Makefile, as they’re both written in C# and thus would be impossible to bootstrap otherwise.
I have looked into it and here is what I got:
mono/runtime/mono-wrapper add "Debugger " before ${MONO_EXECUTABLE} in the last line.mono/mcs run make --no-print-directory -s NO_DIR_CHECK=1 PROFILES='binary_reference_assemblies net_4_x xbuild_12 xbuild_14 ' CC='gcc' all-profiles. This will let you see what’s happening with the Debugger.mono/mini/mini-exceptions.c:558. Run a few times, mono_arch_unwind_frame will fail eventually.Unfortunately I don’t have more time to work on this. Good luck!
Good news: Mono upstream merged my branch. The bad news it still doesn’t work yet; I imagine the problem, is with the runtime. They said they’d rather have it in master than in a branch that could bitrot though.
Getting further, this time on amd64. It’s compiling the stdlib, but runs into GC threading issues?
Some updates: Mono upstream merged the amd64 branch into upstream master. I set up a new x86 VM and got to compiling - ./configure (after installing libtool and gettext; OFC on x86 use gcc5) seems to just work now; and we got further than before - Roslyn works now! The bad news is the runtime seems to have regressed; seems to Roslyn terminate successfully, but the runtime hangs on thread suspend during exit cleanup.
This is still quite advanced work, but I’m unsure if it’s a Haiku problem or a Mono problem; if I could get some people to help with debugging; that’d be handy!
As mentioned above, you can edit runtime/mono_wrapper so you can put options or automatically fire up the debugger.
More news: going to unbreak amd64; and I think I’ve determined what causes Mono to not terminate, (inf loop and inf sleep in suspend_sync_nolock) though I still need to determine why.
Any reason for wasting time on Mono if .NET Core is now open sourced?
What does Mono bring with it that .NET Core doesn’t?.. just curious really.
Mono is mature and much of the work already done - you’d be starting from scratch with CoreCLR, and it’s a big hairy LLVM mess.
These are really good news to hear!
I would actually donate for this work if there was such an option.
Thank you for your effort! Haiku is finally getting ready for daily use.
@dcatt .NET Core would be a real hell to port (remember, Haiku is not Linux).
Unless we get guys from Microsoft working full time on that port…
I filed a bug relating to the runtime termination issue upstream; they’ve just switched to GitHub issues, it seems. Let’s hope people smarter than me take notice!
Really cool Calvin !
You da’ man, Calvin! Awesome effort on your part. This is very deep code stuff.
Going to get this off my chest in one post only:
Get a GSOC slot for the Mono port. And, once that works, get another one to get the Haiku GUI parts working. I mean, geezus people, like anyone is ever going to code in Swift on Haiku?? What were you GSOC decision-makers thinking with THAT?! The only outcome from that was code rot. No one cares about Swift on Linux or Windows 7/8/10. That, in itself, tells you all you needed to know to reject that porting request.
Three other GSCO worthwhile projects:
On a brighter note , kudos to whomever did all of that effort on Qt4 and Qt5. Monumental!
The GSoC “decision makers” can only pick from the proposal submitted by students. We had a student who wanted to port Swift, and he submitted a very good proposal.
Our goal with GSoC is not to get work done. We tried that, and the outcome is that the mentor working alone would get a lot more of it by investing the same amount of time. So, we do GSoC to get new contributors. The mentors are there to train them and get them up to speed, but they can’t decide what the students want to work on. They can only give some inspiration through the ideas list.
Everyone is free to contribute whatever code to whatever project for free. But, regardless of whether it’s Haiku’s donation monies or Google’s, you shouldn’t pay for code that you wouldn’t be willing to use the Haiku money on if you had a little more funding.
All that’s been confirmed now is it’s okay to waste Google’s money IF your proposal is spiffy enough AND you won’t be wasting any core developer’s time.
I think the core kernel developers have felt like pigs in slop for years. Release? Get the next nightly build. THERE’S your “release”! There’s no purposeful direction from that herd of cats or else the forward pacing wouldn’t have been so glacial. Linux has viability because it has commercial application. Haiku has no such aspirations but that’s what you need to get orders of magnitude of world interest.
It takes more of a rich userland development experience like NodeJS and Mono / .Net Core / Web to get noticed at the level where you’re going to get attraction from a whole set of programmer’s who could care less about what the next kernel tweak is. But you need those kinds of developers to drive demand. They’re the ones driving kernel changes, not the other way around.
Haiku is exactly where it is because the core kernel developers are happy where it is. I didn’t know Phipps but he seems to have seen this coming from miles away.
Calvin, I apologize. I’m 100% finished on that topic. I’ll go back to lurking for the foreseeable future unless I can make some progress on Mono.