matthewwarren

Thanks for the link, looks interesting!

> Regardless, this doesn't actually sniff for ASCII art as much as comments themselves.

Yeah you're right. The regex just finds comments. I then wrote some very simple code that analysed the text inside the comments to find potentially interesting ASCII Art. I then looked through these manually to get the ones for the post.

> but in these cases it seems their purpose besides explanation is to imply that there is a good reason the code is the way it is, and that you had better have a very good reason to change the code (and the accompanying comment). In other words, they serve to also guard against change, in parts of the code which should not change often.

Interesting, I'd not thought about that 'side-effect', but you're right, it does guard against that

Wow, 'Stack Trace Art' is very cool, thanks for the links!

> Is there a detailed description of Test.CoreLib anywhere?

You can see the code and README for it here https://github.com/dotnet/corert/tree/master/src/Test.CoreLi... and I also wrote a bit about it in this post https://mattwarren.org/2018/06/07/CoreRT-.NET-Runtime-for-AO...

There's a high-res version on his blog https://lukecarvill.com/portfolio/london-transit-map/

Here's the talk abstract:

Have you ever stopped to think about all the things that happen when you execute a simple .NET program?

This talk will delve into the internals of the recently open-sourced .NET Core runtime, looking at what happens, when it happens and why.

Making use of freely available tools such as 'PerfView', we'll examine the Execution Engine, Type Loader, Just-in-Time (JIT) Compiler and the CLR Hosting API to see how all these components play a part in making 'Hello World' possible.

Here's the talk abstract:

Have you ever stopped to think about all the things that happen when you execute a simple .NET program?

This talk will delve into the internals of the recently open-sourced .NET Core runtime, looking at what happens, when it happens and why.

Making use of freely available tools such as 'PerfView', we'll examine the Execution Engine, Type Loader, Just-in-Time (JIT) Compiler and the CLR Hosting API to see how all these components play a part in making 'Hello World' possible.

Ah, I didn't realise that, thanks for the info

I don't know if it solves your specific scenario, but I do know that there's been some work done in this area.

See https://github.com/dotnet/source-build#net-core-build-script... and https://github.com/dotnet/arcade#arcade

> Also Matt Warren's blog is super cool.

Thanks! I'm glad you like it

> I also love that people are doing write ups about the source of .NET Core and it's internals.

Me too!

BTW, if you want more on the same topic check out http://mattwarren.org/2018/07/12/Presentations-and-Talks-cov... and http://mattwarren.org/2018/01/22/Resources-for-Learning-abou...

Interesting fact, when they forked the CLR, they actually started with the Silverlight code base. See https://channel9.msdn.com/Blogs/dotnet/NET-Foundations-2015-... (somewhere near the beginning)

I guess it makes sense. Before .NET Core, Silverlight was the most x-plat version of the Microsoft .NET Runtime(s) (excluding Xamarin/Mono), so it would've been a good starting point.

> truth is that .NET still has a bit to catch up outside Windows, while Java lost a bit of its mojo on desktops.

I agree, that's quite a nice summary of the 2 ecosystems

> The origins of the CLR can be found in the purchase of Colusa in 1996 which had the Omni VM for running C++ in a sandbox. The original C# language was called cool and came from that project.

Thanks, I'd heard about 'cool', but I didn't know the part about Omni VM, that's interesting to know

I tried to only focus on runtimes, although the line got a bit blurred at times! But yeah, it would be nice to have included a mention of NGEN. When I get a chance I'll update the post

> And the cloud compiler created for Windows Phone 8.x, based on Bartok from Singularity.

Interesting, I didn't realise that all this came from Bartok, thanks for the info

Nice! Thanks for the info, I'll check those out, I'd not heard of either of them.

I think that an update to the post is due, turns out that I missed quite a few!

Nice! Thanks for the info. I think that an update to the post is due, turns out that I missed quite a few!

I'm glad you liked that! (I spent more time that I should've trying to show that in a meaningful way and I was pretty glad when I remembered about 'Beyond Compare')

Nice, that's a pretty cool approach! (random user input)

The .NET Profiling API gives you a way to modify IL code before it's JITted, so that could be one way to do this. See http://mattwarren.org/2018/08/21/Monitoring-and-Observabilit... for a bit more info ('SetILFunctionBody() API')

Thanks for the link, I'd not heard of EMI techniques before, they look interesting

Nice! Not many people can say that their university project made it into the New York Times!

> This is a very narrow definition of a fuzzer. There are a lot of types of fuzzer that do not generate source code, and are not intended to test compilers

Yeah, that's true, I completely missed out other uses for 'fuzzers', thanks for clarifying that

Glad you liked it!

It's certainly one of my motivations to show that the .NET Runtime is a serious work of engineering.

.NET (in general) might not be to everyone taste, but it's hard to argue that it doesn't have a impressive range of features and functionality! I've been blogging about the internals for over 2 years now and there still lots more to discover!

Every time I delve into the internals of the .NET Runtime, I am somehow aware that I don't really know that much and I marvel at the ingenuity of the Engineers who wrote the code! :-)

Especially in this post, the crazy, low-level tricks that the Profiling APIs and the Debugger have to do are amazing, for instance read 'How do Managed Breakpoints work?' https://blogs.msdn.microsoft.com/jmstall/2004/12/28/how-do-m...

I tried to figure some actual numbers related to this, see http://mattwarren.org/2017/12/19/Open-Source-.Net-3-years-la... for a write-up

Just a small thing, the Roslyn compiler (or any C# compiler) does very few optimisations, see https://blogs.msdn.microsoft.com/ericlippert/2009/06/11/what... for some details.

Almost all of the 'compiler' optimisations are done by the JIT at run-time when it converts the IL code into machine/assembly code

The code written during the presentation is available here https://github.com/chrisdunelm/DotNetAnywhere/blob/master/mi...

> It's great for sure but there were deep dive books much more comprehensive than this on the clr and jit that I read a decade ago.

Out of interest, which books are you referring to? I'm always on the lookout for more (decent) technical books to read! :-)