Generalized async return types — it is a new C#7 feature that allows using not only Task as a return type of async methods but also other types (classes or structures) that satisfy some specific requirements.
At the same time, async/await is a way to call a set of "continuation" functions inside some context which is an essence of another design pattern — Monad. So, can we use async/await to write a code which will behave in the same way like if we used monads? It turns out that — yes (with some reservations). For example, the code below is compilable and working:
async Task Main()
{
foreach (var s in new[] { "1,2", "3,7,1", null, "1" })
{
var res = await Sum(s).GetMaybeResult();
Console.WriteLine(res.IsNothing ? "Nothing" : res.GetValue().ToString());
}
// 3, 11, Nothing, Nothing
}
async Maybe<int> Sum(string input)
{
var args = await Split(input);//No result checking
var result = 0;
foreach (var arg in args)
result += await Parse(arg);//No result checking
return result;
}
Maybe<string[]> Split(string str)
{
var parts = str?.Split(',').Where(s=>!string.IsNullOrWhiteSpace(s)).ToArray();
return parts == null || parts.Length < 2 ? Maybe<string[]>.Nothing() : parts;
}
Maybe<int> Parse(string str)
=> int.TryParse(str, out var result) ? result : Maybe<int>.Nothing();Further, I will explain how the code works...
Beginning with C# 8.0 on .NET Core 3.0, you can define an implementation when you declare a member of an interface. The most common scenario is to safely add members to an interface already released and used by innumerable clients.
In this tutorial, you'll learn how to:
I guess one of the most important issues in this topic is building an exception handling architecture in your application. This is interesting for many reasons. And the main reason, I think, is an apparent simplicity, which you don’t always know what to do with. All the basic constructs such as IEnumerable, IDisposable, IObservable, etc. have this property and use it everywhere. On the one hand, their simplicity tempts to use these constructs in different situations. On the other hand, they are full of traps which you might not get out. It is possible that looking at the amount of information we will cover you’ve got a question: what is so special about exceptional situations?
However, to make conclusions about building the architecture of exception classes we should learn some details about their classification. Because before building a system of types that would be clear for the user of code, a programmer should determine when to choose the type of error and when to catch or skip exceptions. So, let’s classify the exceptional situations (not the types of exceptions) based on various features.
Starting with Visual Studio 2019 Preview 4 and RC, we’ll be adjusting how C# versions are treated in .NET tooling. Read more below <cut>.
Firstly, we’re adding two new Language Version (LangVersion) values: LatestMajor and Preview. Here’s how they stack up with the currently supported list of values:
I'm putting part of older WebForms portions of my site that still run on bare metal to ASP.NET Core and Azure App Services, and while I'm doing that I realized that I want to make sure my staging sites don't get indexed by Google/Bing.
I already have a robots.txt, but I want one that's specific to production and others that are specific to development or staging. I thought about a number of ways to solve this. I could have a static robots.txt and another robots-staging.txt and conditionally copy one over the other during my Azure DevOps CI/CD pipeline.
Then I realized the simplest possible thing would be to just make robots.txt be dynamic. I thought about writing custom middleware but that sounded like a hassle and more code that needed. I wanted to see just how simple this could be.
Today, we are announcing .NET Core 3.0 Preview 6. It includes updates for compiling assemblies for improved startup, optimizing applications for size with linker and EventPipe improvements. We’ve also released new Docker images for Alpine on ARM64.
Download .NET Core 3.0 Preview 6 right now on Windows, macOS and Linux.
Release notes have been published at dotnet/core. An API diff between Preview 5 and 6 is also available.
ASP.NET Core and EF Core are also releasing updates today.
If you missed it, check out the improvements we released in .NET Core 3.0 Preview 5, from last month.
Structured logging is gaining more and more popularity in the developers' community. In this article I'd like to demonstrate how we can use structured logging with the Microsoft.Extensions.Logging package and show the idea how we can extend it using the new features of C# 10.
X=np.array([[0,1,1,0],[0,1,1,1],[1,0,0,1]])
y=np.array([[0],[1],[1]])
def sigmoid ():
return 1/(1 + np.exp(-x))
def derivatives_sigmoid ():
return x * (1-x)epoch=10000
lr=0.1
inputlayer_neurons = X.shape[1]
hiddenlayer_neurons = 3
output_neurons = 1
wh=np.random.uniform(size=(inputlayer_neurons,hiddenlayer_neurons))
bh=np.random.uniform(size=(1,hiddenlayer_neurons))
wout=np.random.uniform(size=(hiddenlayer_neurons,output_neurons))
bout=np.random.uniform(size=(1,output_neurons))
Here’s a quick look at algorithm vectorization capabilities in .NET Framework and .NET Core. This article is for those who know nothing about these techniques. I will also show that .NET doesn’t actually lag behind "real compiled" languages for native development.
Since I’ve been working with the community on porting desktop applications from .NET Framework to .NET Core, I’ve noticed that there are two camps of folks: some want a very simple and short list of instructions to get their apps ported to .NET Core while others prefer a more principled approach with more background information. Instead of writing up a “Swiss Army knife”-document, we are going to publish two blog posts, one for each camp:
If you prefer watching videos instead of reading, here is the video where I do everything that is described below.