Building and Running .NET’s CoreCLR on OS X • Hacker News Board

Re: Building and Running .NET’s CoreCLR on OS X

#41

Post by mdaniel » Tue, Feb 10, 2015, 6:19 PM UTC

ubertaco wrote: post #13

chii wrote: post #9

i wonder if other languages can start targeting the CLR, and have a competing cross platform runtime to java that's got a big name behind it.

As a POSIX-loving, open-source-breathing guy: platform availability being equal, why choose Java over C#?

I would venture it's a ton easier to find Java programmers than C# ones (at the current moment), and the same story for libraries for likely the same underlying reason.

As a pragmatic issue, if you weren't already using Mono, then it would probably be wise to let the newly open-sourced CoreCLR stew for a while to find subtle kinks introduced by the process through which it was open-sourced and/or the pressures exerted upon it by full-time dev or test (or even prod!) usage on non-Windows platforms.

As a much more subjective issue, Intellij versus every C# editor is an unfair matchup. It's possible JetBrains will get into the C# editor space now that they might have more marketshare who are not on Windows, but it's probably very far down their priority queue.

Re: Building and Running .NET’s CoreCLR on OS X

#42

Post by praeclarum » Tue, Feb 10, 2015, 6:20 PM UTC

pionar wrote: post #14

chii wrote: post #9

i wonder if other languages can start targeting the CLR, and have a competing cross platform runtime to java that's got a big name behind it.

You mean like these[0]? [0] http://en.wikipedia.org/wiki/List_of_CLI_languages

What got me interested in the CLR in the first place was how easy it is to write a compiler for it. When insomnia hits, I'll still load F# and write a little parser and code emitter for some silly language I have been thinking of. It's fun.

Re: Building and Running .NET’s CoreCLR on OS X

#43

Post by jbigelow76 » Tue, Feb 10, 2015, 6:21 PM UTC

elektronjunge wrote: post #37

jbigelow76 wrote: post #28

Earlier quoted context omitted.

>Cross platform .NET usually means using a native toolkit on each different platform and the result is WPF on Windows, GTK# on Linux, and MonoMac on Mac. What are the odds Microsoft announces WPF open sourcing and maybe a wrapper of some sorts for OSX support at Build this year? I give it at least 50/50 on the open sourcing part.

Doubtful. WPF isn't even the recommended GUI toolkit on windows anymore.

According to whom? And what is the current recommended GUI toolkit?

Re: Building and Running .NET’s CoreCLR on OS X

#44

Post by zamalek » Tue, Feb 10, 2015, 6:30 PM UTC

> libmscordaccore is that. I’ve heard that it “helps debugging”, but at 4KB, I have my doubts. No, this is just an ugly wart growing off an otherwise prefectly packaged piece of software. Best ignore it.

If it's anything like MSCORDACWKS (which "mscordac" alludes to), it's an absolutely crucial piece of code. Basically it's an abstraction layer over the way .Net lays things out in memory. It's aware of the .Net heap structure, threads, stacks, object headers, you name it: it knows how to abstract it and read it.

This means that if there is a production issue at a customer, you can grab a memory dump from them and this one tiny DLL - and then you can start digging into things (Microsoft actually now provides differing versions on their public symbol servers: so you only need the memory dump nowadays). I'm pretty sure it's also how Visual Studio interacts with .Net memory.

Unlike other environments where you have to have the same version as the customer, or at least a compatible one.

Microsoft ships it with the .Net installation package and you [Mac users] should always keep it next to coreclr, too. Literally, deploy it with alongside coreclr and mscordac. Never let them be apart, ever. Don't just ignore it, having the correct version will save your bacon one day. 4KB that will wrangle gigabytes of dumped memory for you.

Re: Building and Running .NET’s CoreCLR on OS X

#45

Post by praeclarum » Tue, Feb 10, 2015, 6:48 PM UTC

zamalek wrote: post #44

> libmscordaccore is that. I’ve heard that it “helps debugging”, but at 4KB, I have my doubts. No, this is just an ugly wart growing off an otherwise prefectly packaged piece of software. Best ignore it. If it's anything like MSCORDACWKS (which "mscordac" alludes to), it's an absolutely crucial piece of code. Basically it's an abstraction layer over the way .Net lays things out in memory. It's aware of the .Net heap…

Sorry - I have a very client-side/consumer facing attitude and these low level debuggers just don't matter. But I acknowledge that it's certainly useful in the scenario you outlined.

Thank you for the clarification!

Re: Building and Running .NET’s CoreCLR on OS X

#46

Post by praeclarum » Tue, Feb 10, 2015, 7:03 PM UTC

jbigelow76 wrote: post #43

elektronjunge wrote: post #37

Earlier quoted context omitted.

Doubtful. WPF isn't even the recommended GUI toolkit on windows anymore.

According to whom? And what is the current recommended GUI toolkit?

Windows RT (aka Metro, aka Store Apps). It's a model based on WPF but not fully compliant - it took in lessons learned form Silverlight. Call it WPFlight.

Re: Building and Running .NET’s CoreCLR on OS X

#47

Post by jbigelow76 » Tue, Feb 10, 2015, 7:12 PM UTC

praeclarum wrote: post #46

jbigelow76 wrote: post #43

Earlier quoted context omitted.

According to whom? And what is the current recommended GUI toolkit?

Windows RT (aka Metro, aka Store Apps). It's a model based on WPF but not fully compliant - it took in lessons learned form Silverlight. Call it WPFlight.

Okay, yeah, so still XAML. I've only recently looked into Windows RT, my time was always spent in ASP.NET, so WPF/WinRT/Silverlight, it all seems like the same thing to me, but I do know a lot of Windows app developers that bitch up a storm about the diffs between WinRT XAML and what can be done in WPF :)

Re: Building and Running .NET’s CoreCLR on OS X

#48

Post by praeclarum » Tue, Feb 10, 2015, 8:58 PM UTC

jbigelow76 wrote: post #47

praeclarum wrote: post #46

Earlier quoted context omitted.

Windows RT (aka Metro, aka Store Apps). It's a model based on WPF but not fully compliant - it took in lessons learned form Silverlight. Call it WPFlight.

Okay, yeah, so still XAML. I've only recently looked into Windows RT, my time was always spent in ASP.NET, so WPF/WinRT/Silverlight, it all seems like the same thing to me, but I do know a lot of Windows app developers that bitch up a storm about the diffs between WinRT XAML and what can be done in WPF :)

The truth is they are essentially the same. I just draw the distinction because porting apps between them isn't always automatic.

Re: Building and Running .NET’s CoreCLR on OS X

#49

Post by kangaroo » Tue, Feb 10, 2015, 9:20 PM UTC

jevinskie wrote: post #12

> Rewriting bits of high performance assembly in bytes (not opcodes) as Mac’s as refused to generate the desired instructions. Ouch. They should really look into using clang and its integrated assembler. All mnemonics should Just Work. as on mac is a patched up binutils 1.38 version.

We are using clangs integrated assembler. The issue is its always choosing to emit jumps in long form which is screwing the aligned of the imm's which are patched at runtime.

Near as I can tell there is no support for the short operator either. Am I missing something?

Re: Building and Running .NET’s CoreCLR on OS X

#50

Post by Sir_Cmpwn » Tue, Feb 10, 2015, 9:32 PM UTC

jevinskie wrote: post #12

> Rewriting bits of high performance assembly in bytes (not opcodes) as Mac’s as refused to generate the desired instructions. Ouch. They should really look into using clang and its integrated assembler. All mnemonics should Just Work. as on mac is a patched up binutils 1.38 version.

The core CLR is compiled with clang.