DEV Community: Kazuhiro Fujieda

Split a List into Sublists of Size N in C#

Kazuhiro Fujieda — Wed, 22 Jun 2022 10:45:59 +0000

How do you write a code in C# to split the list [a, b, c, d, e, f, g, h] into sublists [a, b, c], [d, e, f], [g, h] each with three elements and the last with less than three? The most popular answer is the following LINQ.

List<List<T>> Split<T>(this IList<T> source, int length)
{
    return source
        .Select((x, i) => new { Index = i, Value = x })
        .GroupBy(x => x.Index / length)
        .Select(x => x.Select(v => v.Value).ToList())
        .ToList();
}

In StackOverflow, this LINQ got more than 900 upvotes as of the answer to two questions (Split a List into smaller lists of N size [duplicate], Split List into Sublists with LINQ).

However, this method has the worst performance in any assumed answers. It creates the same number of objects with Index and Value as the length of the source. Object creation is a costly operation in terms of both memory and speed. Although the cost is much smaller, the exact count of divisions and comparisons as the length of the source is also not good for performance.

If you need performance, you should not use LINQ in the first place, but if you insist on a concise LINQ, how about the following solution.

List<List<T>> Split<T>(this IList<T> source, int length)
{
    return Enumerable
        .Range(0, (source.Count + length - 1) / length)
        .Select(n => source.Skip(n * length).Take(length).ToList())
        .ToList();
}

The following are the benchmark results taken from BenchmarkDotNet, which splits a 1000-length array of ints into three pieces each. The first answer is Splitter1, and the above is Splitter2. Mean is the average, and the rests are measurement errors. The results show Splitter2 was more than 3.5 times faster than Splitter1.

BenchmarkDotNet=v0.13.1, OS=Windows 10.0.19044.1766 (21H2)
AMD Ryzen 7 3800X, 1 CPU, 16 logical and 8 physical cores
.NET SDK=6.0.106
  [Host]  : .NET 6.0.6 (6.0.622.26707), X64 RyuJIT
  LongRun : .NET 6.0.6 (6.0.622.26707), X64 RyuJIT

Job=LongRun  IterationCount=100  LaunchCount=3  
WarmupCount=15

Method	Mean	Error	StdDev
Splitter1	89.94 μs	0.351 μs	1.779 μs
Splitter2	24.04 μs	0.100 μs	0.517 μs

If the target framework of your projects is .NET 6 or later, you should use the Chunk method for this operation, which is introduced in .NET 6. The benchmark results, including the Chunk method, are shown below. It was more than 4,000 times faster than Splitter2.

Method	Mean	Error	StdDev
Splitter1	88,650.102 ns	245.2557 ns	1,251.8625 ns
Splitter2	23,481.503 ns	117.8934 ns	600.6975 ns
Chunk	5.609 ns	0.0198 ns	0.0984 ns

The dotnet format command and StyleCop.Analyzers

Kazuhiro Fujieda — Sun, 03 Apr 2022 06:57:16 +0000

This article explains how to use the dotnet format command with .editorconfig and its limitations and then shows you that StyleCop.Analyzers can overcome them. This article also mentions how to apply the StyleCop ruleset to all projects in a solution.

About dotnet format

The dotnet format can format all source codes at once in a project or solution according to rulesets. The .NET SDK version 6.0 or later includes the dotnet format by default. If you use .NET Core 3.1, you can install it as follows.

dotnet tool install -g dotnet-format

The dotnet format reads one or more rulesets from .editorconfig files in a target project or solution folder or its ancestor folders. If you want to format your source codes to follow the C# Coding Style, you can use this .editorconfig in the .NET Runtime repository.

When you use the dotnet format with the .editorconfig, you need to specify the info level severity. Otherwise, the dotnet format ignores most of the rules.

If dotnet format --version shows 6.0 or higher

dotnet format --severity info

Otherwise

dotnet format --fix-style info

The above command formats the following code to the next one.

async private Task<string> readLineAsync(NetworkStream stream)
{
    var result = new List<byte>();
    var buffer = new byte[1];


    do {
        var n = await stream.ReadAsync(buffer);
        if ( n == 0 ) break;
        result.Add(buffer[0]);
    } while ( buffer[0] != 0x0a );

    return Encoding.UTF8.GetString(result.ToArray()).TrimEnd('\r', '\n');

}

private async Task<string> readLineAsync(NetworkStream stream)
{
    var result = new List<byte>();
    byte[] buffer = new byte[1];


    do
    {
        int n = await stream.ReadAsync(buffer);
        if (n == 0) break;
        result.Add(buffer[0]);
    } while (buffer[0] != 0x0a);

    return Encoding.UTF8.GetString(result.ToArray()).TrimEnd('\r', '\n');

}

This result is not sufficient. Despite the coding style, the method name keeps camelCase, and the if statement remains in a single line. There are unnecessary empty lines, too.

StyleCop.Analyzers

To get more disciplined results, we can use StyleCop.Analyzers. The StyleCop.Analyzers provides a way to enforce the StyleCop ruleset traditionally provided by an extension for Visual Studio.

When you format source codes in a project with StyleCop.Analyzers, you need to add the StyleCop.Analyzers package to the project as follows. Then, StyleCop.Analyzers works with the default ruleset.

dotnet add package Stylecop.Analyzers

The default ruleset doesn't follow the coding style. Therefore, you need to download and adjust the default ruleset file from the StyleCop.Analyzers repository. You should add the following lines to the project file when you save the ruleset file as stylecop.ruleset.

<PropertyGroup>
  <CodeAnalysisRuleSet>stylecop.ruleset</CodeAnalysisRuleSet>
</PropertyGroup></script>

Then, you can adjust the rules to follow the coding style in the stylecop.ruleset as follows. You can download the adjusted file in my repository.

--- StyleCopAnalyzersDefault.ruleset    2022-03-13 18:23:36.312971000 +0900
+++ stylecop.ruleset    2022-03-13 18:26:56.342161300 +0900
@@ -38,7 +38,7 @@

     <Rules AnalyzerId="StyleCop.Analyzers" RuleNamespace="StyleCop.Analyzers.ReadabilityRules">
         <Rule Id="SA1100"  Action="Warning" />          <!-- Do not prefix calls with base unless local implementation exists -->
-        <Rule Id="SA1101"  Action="Warning" />          <!-- Prefix local calls with this -->
+        <Rule Id="SA1101"  Action="None" />             <!-- Prefix local calls with this -->
         <Rule Id="SA1102"  Action="Warning" />          <!-- Query clause should follow previous clause -->
         <Rule Id="SA1103"  Action="Warning" />          <!-- Query clauses should be on separate lines or all on one line -->
         <Rule Id="SA1104"  Action="Warning" />          <!-- Query clause should begin on new line when previous clause spans multiple lines -->
@@ -75,11 +75,11 @@
         <Rule Id="SA1136"  Action="Warning" />          <!-- Enum values should be on separate lines -->
         <Rule Id="SA1137"  Action="Warning" />          <!-- Elements should have the same indentation -->
         <Rule Id="SA1139"  Action="Warning" />          <!-- Use literal suffix notation instead of casting -->
-        <Rule Id="SX1101"  Action="None" />             <!-- Do not prefix local calls with 'this.' -->
+        <Rule Id="SX1101"  Action="Warning" />          <!-- Do not prefix local calls with 'this.' -->
     </Rules>

     <Rules AnalyzerId="StyleCop.Analyzers" RuleNamespace="StyleCop.Analyzers.OrderingRules">
-        <Rule Id="SA1200"  Action="Warning" />          <!-- Using directives should be placed correctly -->
+        <Rule Id="SA1200"  Action="None" />             <!-- Using directives should be placed correctly -->
         <Rule Id="SA1201"  Action="Warning" />          <!-- Elements should appear in the correct order -->
         <Rule Id="SA1202"  Action="Warning" />          <!-- Elements should be ordered by access -->
         <Rule Id="SA1203"  Action="Warning" />          <!-- Constants should appear before fields -->
@@ -105,16 +105,16 @@
         <Rule Id="SA1303"  Action="Warning" />          <!-- Const field names should begin with upper-case letter -->
         <Rule Id="SA1304"  Action="Warning" />          <!-- Non-private readonly fields should begin with upper-case letter -->
         <Rule Id="SA1305"  Action="None" />             <!-- Field names should not use Hungarian notation -->
-        <Rule Id="SA1306"  Action="Warning" />          <!-- Field names should begin with lower-case letter -->
+        <Rule Id="SA1306"  Action="None" />             <!-- Field names should begin with lower-case letter -->
         <Rule Id="SA1307"  Action="Warning" />          <!-- Accessible fields should begin with upper-case letter -->
         <Rule Id="SA1308"  Action="Warning" />          <!-- Variable names should not be prefixed -->
-        <Rule Id="SA1309"  Action="Warning" />          <!-- Field names should not begin with underscore -->
+        <Rule Id="SA1309"  Action="None" />             <!-- Field names should not begin with underscore -->
         <Rule Id="SA1310"  Action="Warning" />          <!-- Field names should not contain underscore -->
         <Rule Id="SA1311"  Action="Warning" />          <!-- Static readonly fields should begin with upper-case letter -->
         <Rule Id="SA1312"  Action="Warning" />          <!-- Variable names should begin with lower-case letter -->
         <Rule Id="SA1313"  Action="Warning" />          <!-- Parameter names should begin with lower-case letter -->
         <Rule Id="SA1314"  Action="Warning" />          <!-- Type parameter names should begin with T -->
-        <Rule Id="SX1309"  Action="None" />             <!-- Field names should begin with underscore -->
+        <Rule Id="SX1309"  Action="Warning" />          <!-- Field names should begin with underscore -->
         <Rule Id="SX1309S" Action="None" />             <!-- Static field names should begin with underscore -->
     </Rules>

@@ -140,7 +140,7 @@
         <Rule Id="SA1500"  Action="Warning" />          <!-- Braces for multi-line statements should not share line -->
         <Rule Id="SA1501"  Action="Warning" />          <!-- Statement should not be on a single line -->
         <Rule Id="SA1502"  Action="Warning" />          <!-- Element should not be on a single line -->
-        <Rule Id="SA1503"  Action="Warning" />          <!-- Braces should not be omitted -->
+        <Rule Id="SA1503"  Action="None" />             <!-- Braces should not be omitted -->
         <Rule Id="SA1504"  Action="Warning" />          <!-- All accessors should be single-line or multi-line -->
         <Rule Id="SA1505"  Action="Warning" />          <!-- Opening braces should not be followed by blank line -->
         <Rule Id="SA1506"  Action="Warning" />          <!-- Element documentation headers should not be followed by blank line -->

The dotnet format can format source codes with StyleCop.Analyzers. If the version of the dotnet format is 6.0 or higher, there needs nothing special to use StypeCop.Analyzers. You can use the same command shown above.

dotnet format --severity info

If the version is 5.*, you should run the command with an additional option.

dotnet format --fix-style info --fix-analyzers info

After running the above command, you can get the following result much better than the previous result.

private async Task<string> ReadLineAsync(NetworkStream stream)
{
    var result = new List<byte>();
    byte[] buffer = new byte[1];

    do
    {
        int n = await stream.ReadAsync(buffer);
        if (n == 0)
            break;
        result.Add(buffer[0]);
    }
    while (buffer[0] != 0x0a);

    return Encoding.UTF8.GetString(result.ToArray()).TrimEnd('\r', '\n');
}

Directory.Build.props

When you need to format every project in a solution folder, you need to add the StyleCop.Analyzers package to each project. There is, however, a way to eliminate this effort, the Directory.Build.props file.

When you put Directory.Build.props in the solution folder, MSBuild imports this file to the top of each project file. So you can place the following Directory.Build.props file in the solution folder to make Stylecop.Analyzers available in every project.

<Project>
  <PropertyGroup>
    <CodeAnalysisRuleSet>..\stylecop.ruleset</CodeAnalysisRuleSet>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="StyleCop.Analyzers" Version="1.1.118">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
  </ItemGroup>
</Project>

Conclusion

I illustrated how to use the dotnet format command with StyleCop.Analyzers and the Directory.Build.props file. You can format source codes in every project in a solution folder to use them and get more disciplined results than only with the .editorconfig file.

How to Make Excellent Commits

Kazuhiro Fujieda — Sun, 30 Jan 2022 13:39:29 +0000

This article explains how to make good commits in version control systems such as git. First, I'll explain the purposes of creating commits, then I'll show you how to make good commits, and finally, I'll explain how to write good commit messages. Please note that I won't write anything easily found by searching "git commit message".

The purposes of making commits

We continually change artifacts (documentation, source code, etc.) in software development over time. Version control systems, including git, manage those changes and allow us to capture a moment in between the time by a commit.

One of the purposes to capture is to preserve the moment when the software is working correctly. If a bug occurs in changes from that moment, you can go back to the previous commit to recover the working state. If you find a bug in a commit that should work, you can go back to one more commit. If you don't find the same bug there, you can identify that the bug occurred in the next commit.

The other purpose is to place a message at a moment and record it. The message helps you remember the reason for the change in the commit afterward, and other people can understand your work by investigating your commits.

Another purpose is to decide when to share your changes with the team members. In version control systems, you need to make commits to share your changes with others; in git, you need to push them to a shared repository, but whatever the case, you need commits to share your changes with others.

Excellent commits

Thinking about the purpose of a commit makes it easier to understand the criteria for a good commit, i.e., which moment of the ever-changing artifacts you should capture.

Commits to capture the working states

A commit that preserves the working state and helps us track down bugs should be made when you can assume the software works properly. You should try not to have more than one bug in a commit to make it easy to identify which commit a bug resides.

A perfect moment to make a commit is the next time the software works correctly, after making small changes that are unlikely to introduce multiple bugs from the previous commit.

From this point of view, a commit with absolutely no room for bugs is useless because it only adds another step when you track down a bug. It's really unnecessary if it doesn't meet other purposes described below.

Commits to place messages on certain moments

Of course, a commit to place a message at a specific moment should be made when there are no changes unrelated to the message. And the message must make it easy to understand the commit both for you and others.

The message should have one thing. So, if it is something like "A and B", the commit should be divided into two. And the message should be concrete enough to narrow the differences included by the commit.

A commit with a few thousand lines of changes represented by a vague message is not helpful to anyone. On the other hand, even if a commit has thousands of lines of changes, it is still helpful if it has a concrete message like "Change the method name A to B".

Commits to share changes with other members

When you make a commit to tell other members about your changes, it is even more important to place a concrete message and make the changes small. Since you are asking another member to review your commit, you should not make the commit something even you don't feel like reviewing. Of course, if there are team rules about commits, you have to follow them.

You should make such a commit when the development process in your team requires it. For example, if your team uses an issue management system, such as GitHub issue, you need to create a commit when you solve the issue assigned to you, and you must follow the rules in your team to tie your commit to the issue.

Excellent commit messages

Because a commit is a snapshot of a moment, the accompanying message should either describe the changes that occurred between last and this time, describe the event that triggered the snapshot, or both.

You should summarize the commit in the first line of the message. Because many version control systems, including git, only show the first line of the message on the commit log in the briefest format. This format provides a bird' eye view of the many commits and becomes more valuable by good first-line summaries.

In git, there is a convention requiring us to write one line summary with less than 50 characters at the first line. It's a good practice. Though the line can be longer than 50 characters, it shouldn't be too long because humans have a limit of how many characters they can read at a glance.

On a version control system in your team, your commit messages are messages to other members, and the commit log is an essential component of communication in the team. The commit log is like a bulletin board to help the communication, and the messages placed on it should be brief and to the point.

A suitable manner of writing the message depends on the product being developed and the team developing the product. Still, you should write "what has been done" in an imperative form, "do something" to summarize your changes. The candidates as the verb are shown below.

Add
Implement
Create
Fix
Update
Change
Improve
Remove/Delete
etc.

Examples of messages are "Fix a bug in the signature algorithm.", "Improve speed of displaying the user list.", "Update models to reflect changes in tables", "Change ConnectionCreator to ConnectionBuilder".

As many projects are doing, prefixing a message with one or more tags to identify the related issue, module, or subsystem, can help narrow down the scope of the "what" in a short number of characters.

If this is necessary and you can keep it short, you may add "what for". If it becomes too long, you can move the details to the second line (the third line after a blank line in git) or later. And for a commit tied to an issue on an issue management system, you can leave the details in the comments of the corresponding issue.

Conclusion

I started by explaining the purposes of commits and showed you how to make excellent commits. By the way, I wrote this article to encourage my current team members to improve the granularity of commits and the quality of their messages. Many sentences started with "you should do," but most of them mean just "I would like my team members to do," so please forgive me for that.

Equality Comparison of Floating-Point Numbers in C# (and Others)

Kazuhiro Fujieda — Sun, 11 Jul 2021 13:04:58 +0000

tl;dr

You should compare two floating-point numbers for equality in C# as follows:

bool Equals(double x, double y, double tolerance)
{
    var diff = Math.Abs(x - y);
    return diff <= tolerance ||
           diff <= Math.Max(Math.Abs(x), Math.Abs(y)) * tolerance;
}

tolerance must be much larger than double.Epsilon.

The problem in the equality operator

You should avoid using the equality operator == to compare two floating-point numbers for equality. This is because the equality operator can return false for two intuitively equal numbers. The following list and the output indicate the problem.

ar one = 0d;
for (var i = 0; i < 10; i++)
    one += 0.1;
var pairs = new[]
{
    (1.0 - 0.9, 0.1),
    (0.15 + 0.15, 0.1 + 0.2),
    (one, 1.0)
};
foreach (var p in pairs)
{
    var (x, y) = p;
    Console.WriteLine($"x: {x:f18}, y: {y:f18},\r\n    " +
        $"x == y: {x == y}, Abs(x-y): {Math.Abs(x - y):f18}");
}

x: 0.099999999999999978, y: 0.100000000000000006,
    x == y: False, Abs(x-y): 0.000000000000000028
x: 0.299999999999999989, y: 0.300000000000000044,
    x == y: False, Abs(x-y): 0.000000000000000056
x: 0.999999999999999889, y: 1.000000000000000000,
    x == y: False, Abs(x-y): 0.000000000000000111

The equality comparisons between 1.0 - 0.9 and 0.1, between 0.15 + 0.15 and 0.1 + 0.2, and the sum of ten 0.1 and 1.0 unexpectedly result in false. The errors in the floating-point numbers cause these results.

Tolerating absolute errors

The well-known way to resolve this problem is to compare the absolute error of two numbers with a minuscule number. The following results are as expected because the absolute errors are less than 1e-10.

const double tolerance = 1e-10;
foreach (var p in pairs)
{
    var (x, y) = p;
    var r = Math.Abs(x - y) <= tolerance;
    Console.WriteLine($"x: {x:f18}, y: {y:f18},\r\n    " +
        $"TolerateAbsError: {r}, Abs(x-y): {Math.Abs(x - y):f18}");
}

x: 0.099999999999999978, y: 0.100000000000000006,
    TolerateAbsError: True, Abs(x-y): 0.000000000000000028
x: 0.299999999999999989, y: 0.300000000000000044,
    TolerateAbsError: True, Abs(x-y): 0.000000000000000056
x: 0.999999999999999889, y: 1.000000000000000000,
    TolerateAbsError: True, Abs(x-y): 0.000000000000000111

This approach has a problem where the absolute error between two large numbers can easily exceed the minuscule number. For example, the comparison between 0.1 added to 1e6 ten times and 1e6 plus 1.0 results in false because the absolute error exceeds 1e-10.

const double tolerance = 1e-10;
double x, y;
x = y = 1e6;
for (var i = 0; i < 10; i++)
    x += 0.1;
y += 1.0;
var r = Math.Abs(x - y) <= tolerance;
Console.WriteLine($"x: {x:f18}, y: {y:f18},\r\n    " +
    $"TolerateAbsError: {r}, Abs(x-y): {Math.Abs(x - y):f18}");

x: 1000000.999999999767169356, y: 1000001.000000000000000000,
    TolerateAbsError: False, Abs(x-y): 0.000000000232830644

Tolerating relative errors

You can resolve this problem by tolerating the relative error instead of the absolute error. A relative error of two numbers is the absolute error divided by the maximum of their absolute values.

The following comparison tolerant of the relative error between the two additions to 1e6 returns true because the relative error is less than 1e-10. Please notice a / b <= c forms a <= b * c to avoid division by zero.

x and y are the same as above.
var r = Math.Abs(x - y) <= Math.Max(Math.Abs(x), Math.Abs(y)) * tolerance;
var error = Math.Abs(x - y) / Math.Max(Math.Abs(x), Math.Abs(y));
Console.WriteLine($"x: {x:f18}, y: {y:f18},\r\n    " +
    $"TolerantRelativeError: {r}, RelativeError: {error:f18}");

x: 1000000.999999999767169356, y: 1000001.000000000000000000,
    TolerantRelativeError: True, RelativeError: 0.000000000000000233

This technique causes another problem. The relative error between two minuscule numbers almost equal to zero can become very large. For example, the comparison tolerant of the relative error between 1e-11 and 1e-12 returns false.

const double tolerance = 1e-10;
var x = 1e-11;
var y = 1e-12;
var r = Math.Abs(x - y) <= Math.Max(Math.Abs(x), Math.Abs(y)) * tolerance;
var error = Math.Abs(x - y) / Math.Max(Math.Abs(x), Math.Abs(y));
Console.WriteLine($"x: {x:f18}, y: {y:f18},\r\n    " +
    $"TolerantRelativeError: {r}, RelativeError: {error:f18}");

x: 0.000000000010000000, y: 0.000000000001000000,
    TolerantRelativeError: False, RelativeError: 0.900000000000000022

Torelating both errors

The equality comparison must tolerate both the absolute and relative errors of two numbers to solve those problems.

bool Equals(double x, double y, double tolerance)
{
    var diff = Math.Abs(x - y);
    return diff <= tolerance ||
           diff <= Math.Max(Math.Abs(x), Math.Abs(y)) * tolerance;
}

The above equality comparison returns true for both of the corner cases.

const double tolerance = 1e-10;
double x, y;
bool r;
x = y = 1e6;
for (var i = 0; i < 10; i++)
    x += 0.1;
y += 1.0;
r = Equals(x, y, tolerance);
Console.WriteLine($"x: {x:f18}, y: {y:f18},\r\n    "+
                  $"TolerateRelativeAndAbsError: {r}");
x = 1e-11;
y = 1e-12;
r = Equals(x, y, tolerance);
Console.WriteLine($"x: {x:f18}, y: {y:f18},\r\n    "+
                  $"TolerateRelativeAndAbsError: {r}");

x: 1000000.999999999767169356, y: 1000001.000000000000000000,
    TolerateRelativeAndAbsError: True
x: 0.000000000010000000, y: 0.000000000001000000,
    TolerateRelativeAndAbsError: True

The myth of machine epsilon

I have arbitrarily chosen 1e-10 as the tolerance so far, but there is a mathematically rigid number misunderstood as an appropriate value in this case. It is machine epsilon.

Many programming languages define machine epsilon as the difference between 1 and the next larger floating-point number, even though the formal definition is different from it. In C#, Double.Epsilon has machine epsilon.

You can't use machine epsilon as the tolerance. When adopting Double.Epsilon as the tolerance, the comparison between the sum of ten 0.1 and 1.0 in the first example returns false. Machine epsilon is too small, and cumulative errors of arithmetic operations easily exceed it.

var one = 0d;
for (var i = 0; i < 10; i++)
    one += 0.1;
var r = Equals(one, 1.0, Double.Epsilon);
Console.WriteLine($"x: {one:f18}, y: {1.0:f18},\r\n    "+
                  $"UseMachineEpsilonAsTolerance: {r}");

x: 0.999999999999999889, y: 1.000000000000000000,
    UseMachineEpsilonAsTolerance: False

After all, the tolerance should be based on the precision necessary to your application. It also should be much larger than machine epsilon.

Conclusion

The equality comparison of floating-point numbers should take into account both the absolute and relative errors. Furthermore, the error tolerance in the comparison should be chosen based on the required accuracy in your application. If you would like to know more details of this topic, you should consult Comparing Floating Point Numbers, 2012 Edition.

This GitHub repository has the above examples and the implementation of EqualityComparer<double> and IComperer<double> based on this article.

Implementing a System Tray App with WPF and MVVM

Kazuhiro Fujieda — Tue, 27 Apr 2021 11:23:20 +0000

This article illustrates the implementation of a system tray application with WPF and the MVVM pattern. The full source code is in the GitHub repository.

The implementation has two distinctive points. First, it does not use notable WPF NotifyIcon because the license, CPOL, isn't compatible with any OSS licenses. Then, the implementation obeys the MVVM pattern so it has no code behind.

A Wrapper of NotifyIcon

The central part of the implementation is NotifyIconWrapper, a wrapper of the NotifyIcon class in WinForms. The wrapper has the dependency property NotifyRequest to invoke the ShowBaloonTip method.

private static readonly DependencyProperty NotifyRequestProperty =
    DependencyProperty.Register("NotifyRequest", typeof(NotifyRequestRecord), typeof(NotifyIconWrapper),
        new PropertyMetadata(
            (d, e) =>;
            {
                var r = (NotifyRequestRecord)e.NewValue;
                ((NotifyIconWrapper)d)._notifyIcon?.
                    ShowBalloonTip(r.Duration, r.Title, r.Text, r.Icon);
            }));

When the application sets a NotifyRequestRecord to the bound property in the ViewModel, the callback function is invoked by the change of the value defined in PropertyMetadata invokes ShowBaloonTip based on the record.

private void Notify(string message)
{
    NotifyRequest = new NotifyIconWrapper.NotifyRequestRecord
    {
        Title = "Notify",
        Text = message,
        Duration = 1000
    };
}

The following is the constructor. If the constructor is invoked not by the XAML editor, It creates the NotifyIcon and the context menu to which event handlers are attached.

public NotifyIconWrapper()
{
    if (DesignerProperties.GetIsInDesignMode(this))
        return;
    _notifyIcon = new NotifyIcon
    {
        Icon = Icon.ExtractAssociatedIcon(Assembly.GetExecutingAssembly().Location),
        Visible = true,
        ContextMenuStrip = CreateContextMenu()
    };
    _notifyIcon.DoubleClick += OpenItemOnClick;
    Application.Current.Exit += (obj, args) => { _notifyIcon.Dispose(); };
}

private ContextMenuStrip CreateContextMenu()
{
    var openItem = new ToolStripMenuItem("Open");
    openItem.Click += OpenItemOnClick;
    var exitItem = new ToolStripMenuItem("Exit");
    exitItem.Click += ExitItemOnClick;
    var contextMenu = new ContextMenuStrip {Items = {openItem, exitItem}};
    return contextMenu;
}

NotifyIconWrapper defines the routed event OpenSelected and ExitSelected raised by the event handler OpenItemOnClick and ExiteItemOnClick shown above respectively.

The following XAML shows how to use the wrapper. The dependency property NotifyRequest is bound to the property mentioned above. Each routed event is bound to the corresponding routed command with Xaml.Behaviors.WPF.

<Window x:Class="SystemTrayApp.WPF.MainWindow"
        xmlns:bh="http://schemas.microsoft.com/xaml/behaviors"
...
    <Grid>
        <local:NotifyIconWrapper NotifyRequest="{Binding NotifyRequest}">
            <bh:Interaction.Triggers>
                <bh:EventTrigger EventName="OpenSelected">
                    <bh:InvokeCommandAction Command="{Binding NotifyIconOpenCommand}">
                </bh:EventTrigger>

Hiding and Restoring Window

The application implements hiding and restoring its window through data bindings. The following XAML bind WindowState and ShowInTaskbar to the properties in the ViewModel.

<Window x:Class="SystemTrayApp.WPF.MainWindow"
...
        ShowInTaskbar="{Binding ShowInTaskbar}"
        WindowState="{Binding WindowState}"
        Title="SystemTrayApp" Height="200" Width="300">

When the window gets minimized, the bound property WindowState is changed. The set accessor sets ShowInTaskbar false to hide the application from the taskbar. To restore the window, the ViewModel sets WindowState.Normal to the WindowState property.

ublic WindowState WindowState
{
    get => _windowState;
    set
    {
        ShowInTaskbar = true;
        SetProperty(ref _windowState, value);
        ShowInTaskbar = value != WindowState.Minimized;
    }
}

The weird workaround ShowInTaskbar = true is to prevent the following window consisting only of the title from leaving at the bottom of the desktop on minimizing.

Loaded and Closing Events

The application hides its window on starting up by handling the Loaded event of the window. Xaml.Behavior.WPF binds the event to the routed command LoadedCommand. The command sets WindowState.Minimized to WindowState to hide the window. In this approach, the window inevitably appears just for a moment on starting up.

XAML
<bh:Interaction.Triggers>
    <bh:EventTrigger EventName="Loaded">
        <bh:InvokeCommandAction Command="{Binding LoadedCommand}"/>
    </bh:EventTrigger>

ViewModel
public MainWindowViewModel()
{
    LoadedCommand = new RelayCommand(Loaded);
...
}

public ICommand LoadedCommand { get; }

private void Loaded()
{
    WindowState = WindowState.Minimized;
}

When users click the close button on the title bar, the application must cancel the Closing event to prevents itself from existing. To realize it, the event handler needs to set true to the Cancel property of the event argument. Xaml.Behavior.WPF passes the argument to the routed command when PassEventArgsToCommand is true so that the command can do it.

    <bh:EventTrigger EventName="Closing">
        <bh:InvokeCommandAction Command="{Binding ClosingCommand}" PassEventArgsToCommand="True"/>
    </bh:EventTrigger>
</bh:Interaction.Triggers>

ViewModel
public MainWindowViewModel()
{
...
    ClosingCommand = new RelayCommand<CancelEventArgs>(Closing);
...
}

public ICommand CloasingCommand { get; }

private void Closing(CancelEventArgs? e)
{
    if (e == null)
        return;
    e.Cancel = true;
    WindowState = WindowState.Minimized;
}

Conclusion

This article explained the implementation of the system tray application in the GitHub repository. It depends on Microsoft.Toolkit.Mvvm but can be easily ported to other MVVM frameworks. The license is 0BSD, equal to the public domain. You can freely use the code to create another system tray application.

Migrate To MahApps.Metro 2.x

Kazuhiro Fujieda — Thu, 25 Mar 2021 09:39:16 +0000

This article shows the migration steps from MahApps.Metro 1.3.0 to 2.4.3 for BurageSnap, a screen capture tool. BurageSnap uses MahApps.Metro to realize its small footprint, as shown below.

Adapt Theme

I first changed the theme specifications as explained in the official document Migration to v2.0.

Old

<ResourceDictionary Source="pack://application:,,,/MahApps.Metro;component/Styles/Controls.xaml" />
<ResourceDictionary Source="pack://application:,,,/MahApps.Metro;component/Themes/MetroWindow.xaml" />
<ResourceDictionary Source="pack://application:,,,/MahApps.Metro;component/Styles/Colors.xaml" />
<ResourceDictionary Source="pack://application:,,,/MahApps.Metro;component/Styles/Accents/Steel.xaml" />
<ResourceDictionary Source="pack://application:,,,/MahApps.Metro;component/Styles/Accents/BaseLight.xaml" />

New

<ResourceDictionary Source="pack://application:,,,/MahApps.Metro;component/Styles/Controls.xaml"/>
<ResourceDictionary Source="pack://application:,,,/MahApps.Metro;component/styles/Themes/light.steel.xaml"/>

Adapt Style

Then I had to fix the following style settings. MetroWindow in MahApps 2.x doesn't have the dynamic resource and the properties.

<Style x:Key="WindowStyle" TargetType="mah:MetroWindow">
...
    <Setter Property="BorderBrush" Value="{DynamicResource AccentColorBrush}"/>
    <Setter Property="TitlebarHeight" Value="24"/>
    <Setter Property="TitleCaps" Value="False"/>
    <Setter Property="WindowMinButtonStyle" Value="{StaticResource WindowButtonStyle}"/>
    <Setter Property="WindowCloseButtonStyle" Value="{StaticResource WindowButtonStyle}"/>
...

AccentColorBrush

The resource of the same brush can be referred as follows in MahApps 2.x.

<Setter Property="BorderBrush" Value="{StaticResource MahApps.Brushes.Accent}"/></script>

Window Title

TitlebarHeight was just superseded by TitleBarHeight. TitleCaps was replaced by TitleCharacterCasing but having a CharcterCasing type value. I modified these settings as follows.

<Setter Property="TitleBarHeight"Value="24">
<Setter Property="TitleCharacterCasing" Value="Normal"/>

Window Buttons

I used the style properties WindowMinButtonStyle and WindowCloseButtonStyle to make the minimize and close buttons small. But these were eliminated in the 2.x.

Instead, WindowButtonCommands inside MetroWindow has the corresponding properties, LightMinButtonStyle and LightCloseButtonStyle in case of light themes. When defining a style inside another style, we can use Style.Resources as follows.

<Style x:Key="WindowStyle" TargetType="mah:MetroWindow">
...
    <Style.Resources>
        <Style TargetType="mah:WindowButtonCommands" BasedOn="{StaticResource MahApps.Styles.WindowButtonCommands}">
            <Setter Property="LightCloseButtonStyle" Value="{StaticResource WindowButtonStyle}"/>
            <Setter Property="LightMinButtonStyle" Value="{StaticResource WindowButtonStyle}"/>
        </Style>
    </Style.Resources>
...
</Style>

I defined the above WindowButtonStyle to make the button width narrow as follows, but the base style MetroBaseWindowButtonStyle is missing in MahApps 2.x so I had to replace it with MahApps.Styles.Button.MetroWindow.Light.

<Style x:Key="WindowButtonStyle" TargetType="Button" BasedOn="{StaticResource MahApps.Styles.Button.MetroWindow.Light}">
    <Setter Property="Width" Value="26"/>
</Style>

Button Labels

There were other errors in the following ButtonStyle to disable capitalization and boldness of the button labels in the default style. There aren't the MetroButton style and the ButtonHelper class in the 2.x.

<Style x:Key="ButtonStyle" TargetType="Button" BasedOn="{StaticResource MahApps.Styles.ButtonMetroButton}">
    <Setter Property="mah:ControlsHelper.ContentCharacterCasing" Value="Normal"/>
    <Setter Property="FontWeight" Value="Normal"/>
</Style>

These replacements are MahApps.Styles.Button and ControlsHelper respectively. ControlsHelper, however, have ContentCharacterCasing not PreserveTextCase. Those errors were fixed as follows.

<Style x:Key="ButtonStyle" TargetType="Button" BasedOn="{StaticResource MahApps.Styles.ButtonMetroButton}">
    <Setter Property="mah:ControlsHelper.ContentCharacterCasing" Value="Normal"/>
    <Setter Property="FontWeight" Value="Normal"/>
</Style>

Next Step

That's all of the migration. Next, I had to migrate Prism from 6.2 to 8.0. MahApps.Metro 2.x is incompatible with the older versions of Prism. Because XamlBehaviors.WPF, the 2.x depends on, conflicts with Windows.Interactivity, the older Prism depends on. I will show the migration steps in another article.

Controlling Unity Application Through NamedPipe

Kazuhiro Fujieda — Wed, 17 Feb 2021 08:32:27 +0000

This article shows how to control scenes on a Unity standalone player by a Windows application with NamedPipe like the following demonstration. The full source is on the GitHub repository.

Windows Side

You can use this IPC class as a NamePipe client to send requests to a Unity standalone player. In the WPF application, a property setter bound to a view sends a request with IPC.Send as follows. IPC.Send waits and returns the response from the player.

public string SelectedScene
{
    set
    {
        if (value == null)
            return;
        Task.Run(async () =>
        {
            IsEnabled = false;
            try
            {
                Status = await _ipc.Send("Scene " + value);
            }
            catch (Exception e)
            {
                Status = e.Message;
            }
            IsEnabled = true;
        });
    }
}

Unity Side

In the first place, you must change Api Compatibility Level to .NET 4.x in Player Settings to make NamedPipe available. NamePipe works on the Unity editor's play mode even in .NET Standard 2.0, but it results in an error on a standalone player.

You can use this IPC class as a NamedPipe server to receive requests from a Windows application. The following is the implementation of IPC.Receive to wait for connections from a Windows application.

private static async UniTask<string> Receive()
{
    try
    {
        _pipe = new NamedPipeServerStream(PipeName);
        return await UniTask.Run(() =>
        {
            var buffer = new byte[1024];
            _pipe.WaitForConnection();
            var len = _pipe.Read(buffer, 0, buffer.Length);
            return Encoding.UTF8.GetString(buffer, 0, len);
        });
    }
    catch (Exception e)
    {
        _pipe?.Dispose();
        Debug.Log(e.Message);
        return "";
    }
}

This is an asynchronous method implemented with UniTask. UniTask is much easier than coroutines to implement asynchronous operations. This method uses synchronous methods of NamedPipe because Unity doesn't implement the asynchronous versions. They don't cause any errors in compilation but result in errors at runtime.

The following Controller class processes requests from the Windows application. You have to put an empty GameObject on every scene and attach a Controller object to the GameObject.

public class Controller : MonoBehaviour
{
    private GameObject _target;

    private void Awake()
    {
        if (FindObjectsOfType<Controller>().Length > 1)
            Destroy(gameObject);
        DontDestroyOnLoad(gameObject);
    }

    private void Start()
    {
        _target = GameObject.Find("/Target");
        IPC.Run(Handler);
    }

    private async UniTask Handler(string message)
    {
        var tokens = message.Split(' ');
        if (tokens.Length != 2)
        {
            await IPC.Send("Invalid message: " + message);
            return;
        }
        switch (tokens[0])
        {
            case "Scene":
                SceneManager.LoadScene(tokens[1]);
                await IPC.Send("Succeeded");
                _target = GameObject.Find("/Target");
                return;
            case "Color":
                if (_target == null)
                {
                    await IPC.Send("Target not exists");
                    return;
                }
                if (ColorUtility.TryParseHtmlString(tokens[1], out var color))
                    _target.GetComponent<Renderer>().material.color = color;
                await IPC.Send("Succeeded");
                return;
        }
        await IPC.Send("Invalid command: " + tokens[0]);
    }

    private void OnApplicationQuit()
    {
        IPC.Close();
    }
}

Awake invokes DontDestroyOnLoad not to destroy the Controller on a scene change. Otherwise, the Controller can't send the response of a scene change request after LoadScene. Start invokes IPC.Run with a request handler to start receiving requests.

OnDisable invokes IPC.Close of which implementation is shown below. The method immediately returns on the scene change, in which case the pipe is connected.

public static void Close()
{
    if (_pipe != null && _pipe.IsConnected)
        return;
    _cancelled = true;
    try
    {
        var pipe = new NamedPipeClientStream(PipeName);
        pipe.Connect(500);
        pipe.Flush();
        pipe.Close();
    }
    catch (FileNotFoundException)
    {
    }
    catch (Exception e)
    {
        Debug.Log(e.Message);
    }
    finally
    {
        _pipe?.Close();
    }
}

Otherwise, it connects its own NamedPipe to stop IPC.Receive waiting for connections. When the code runs on the editor's play mode, if not doing so, a waiting thread leaves on the editor and freezes it on terminating and reloading code.

I originally implemented the above IPC classes. Some articles are showing how to use NamedPipe on Unity. But they are just experimentations and not appropriate to use in real applications. So I Implemented them.

A Quite Simple Memory Pool in C#

Kazuhiro Fujieda — Mon, 28 Dec 2020 08:45:04 +0000

This article shows a quite simple memory pool to make a thread-unsafe library thread-safe without performance degradation in single-threaded programs. Same as the previous article, this article is about DynaJson.

Thread-safety requires overhead to allocate an instance by each invocation to isolate data being altered. Unless thread-safety is required, we can use a static class or a singleton to eliminate any additional allocation.

When I made DynaJson thread-safe, I adopted a memory pool to avoid the allocations in single-threaded programs. When a program start, DynaJson allocates one instance in the memory pool. In single-threaded programs, DynaJson repeatedly rents and returns the instance from/to the pool. In multi-threaded programs, DynaJson allocates additional instances only when more than one thread uses DynaJson at the same time because the memory pool gets empty.

As for a memory pool, there is an implementation on the .NET platform, that is, MemoryPool<T>. But .NET Standard 2.0, an API set that DynaJson uses, doesn't have the class. So I originally implemented a memory pool.

In implementing a memory pool, we need to care how the speed of the operations gets much faster than the allocations. We mainly use locks to implement thread-safe data structures. But locks are slower than the allocations, so we must implement a memory pool in a lock-free way.

In C#, most implementations of lock-free data structures use Interlocked.CompareExchange. This article shows a lock-free stack implemented with the method. I implemented a quite simple memory pool referring to this stack as follows.

internal class BufferPool<T>
{
    private class Node
    {
        public Node Next;
        public T Item;
    }

    private readonly Node _head = new Node();

    public void Return(T item)
    {
        var node = new Node {Item = item};
        do
        {
            node.Next = _head.Next;
        } while (Interlocked.CompareExchange(ref _head.Next, node, node.Next) != node.Next);
    }

    public T Rent()
    {
        Node node;
        do
        {
            node = _head.Next;
            if (node == null)
                return default;
        } while (Interlocked.CompareExchange(ref _head.Next, node.Next, node) != node);
        return node.Item;
    }
}

I have to say this is a poor implementation because it causes another allocation whenever an application returns an instance. Nevertheless, the size of the allocated instance is only 16 bytes, so that this memory pool can reduce the overall cost of the allocations in DynaJson.

The following chart compares the times to parse a simple JSON {"X":1234.5,"Y":5.6789,"Name":"Sakura"} without and with the memory pool. The memory pool reduces the processing time by 203 ns.

NaN Boxing in C# to realize a fast JSON parser

Kazuhiro Fujieda — Wed, 09 Dec 2020 11:53:03 +0000

This article shows how to use NaN Boxing to improve the performance of a JSON parser for C# named DynaJson.

About DynaJson

DynaJson is a fast JSON parser for C# compatible with DynamicJson. I feel DynamicJson is very useful but lack sufficient performance, so I developed a faster replacement.

DynaJson acts the same as DynamicJson, as shown below. It returns a dynamic type value representing a JSON object resulting from parsing a JSON string. We can access each member of the JSON object with the member access operator like a C# object. This manner is useful to process a large JSON with duck typing.

dynamic json = JsonObject.Parse(@"{
    ""foo"": ""json"",
    ""nest"": {""foobar"": true}
}");
string a1 = json.foo; // "json"
bool a2 = json.nest.foobar; // true

A benchmark result of DynaJson is shown below. The benchmark measured the time to process a large JSON file named citm_catalog.json, whose size is about 1.7MB. The benchmark compared DynaJson with Utf8Json, Jil, Newtonsoft.Json, DynamicJson. The measurement ran on .NET Core 3.1 on Ubuntu 18.04 on Azure D2Ds_v4.

The result shows DynaJson is quite faster than others. DynaJson is optimized for this use case, so the result is natural.

citm_catalog.json is one of the files used in Native JSON Benchmark. Many benchmarks for JSON parsers use this file.

An optimization by NaN Boxing

JSON parsers generate a large number of objects representing JSON values on parsing a large JSON file. So DynaJson represents a JSON value as a 16 bytes structure type. Copying a 16 bytes structure is much faster than larger ones because it needs only one load and store instruction for 128bit SIMD operations.

vmovdqu   xmm0,xmmword ptr [rdi]
vmovdqu   xmmword ptr [rsp+8],xmm0

The definition of the structure is shown below. It folds members into 16 bytes with an Explicit layout. The parser uses each of String, Array, and Dictionary alternately based on the value of Type, so the members can be laid out at the same offset. How about Number and Type? Type of an enum type overlaps the upper 4 bytes of Number. It can seemingly break Number.

[StructLayout(LayoutKind.Explicit)]
internal struct InternalObject
{
    [FieldOffset(4)] public JsonType Type;
    [FieldOffset(0)] public double Number;
    [FieldOffset(8)] public string String;
    [FieldOffset(8)] public JsonArray Array;
    [FieldOffset(8)] public JsonDictionary Dictionary;
}

NaN Boxing can realize the overlap safely. NaN, standing for Not a Number, represents zero divided by zero and the square root of a negative number in floating-point arithmetics. See the Wikipedia entry for more details. One of the binary representations of NaN defined in IEEE 754 is 0xfff8000000000000. The lower 51 bits can have an arbitrary number, so NaN Boxing boxes data in the bits.

The definition of an enum type JsonType is shown below. JsonType has not only types of JSON values but also the values themselves for null, true, and false. The definition assigns a legitimate value as the upper 4 bytes of NaN to each member. The values never collide with the upper part of ordinary doubles. Any conjunctions with any lower 4 bytes become a legitimate double.

enum JsonType : uint
{
    Null = 0xfff80001,
    True = 0xfff80002,
    False = 0xfff80003,
    String = 0xfff80004,
    Array = 0xfff80005,
    Object = 0xfff80006
}

A usage of JsonType is shown below. ToValue is a method to extract a value JsonValue represents. If the value of obj.Type is not anything in the defined members, it must be an upper 4 bytes of an ordinary double, so ToValue returns obj.Number. This manner realizes the clear separation of Number and Type.

object ToValue(InternalObject obj)
{
    switch (obj.Type)
    {
        case JsonType.Null:
            return null;
        case JsonType.True:
            return true;
        case JsonType.False:
            return false;
        case JsonType.String:
            return obj.String;
        case JsonType.Array:
        case JsonType.Object:
            return new JsonObject(obj);
        default:
            return obj.Number;
    }
}

The following benchmark result shows the effect of NaN Boxing. The benchmark measured parsing time in each definition of InternalObject as a class, 20 bytes (8 + 8 + 4) structure without NaN Boxing, and 16 bytes one with NaN Boxing. The 20 bytes structure made the parser 20% faster than the class, and NaN Boxing improved 6.8% more.

Other usages of NaN Boxing

JavaScript engines such as Mozilla's SpyderMonkey and WebKit's JavaScriptCore use NaN Boxing, but Google's V8 doesn't use it. LuaJIT and mruby also use NaN Boxing. These implementations overlap a pointer with a double and compact the size of all values into 8 bytes. C# doesn't allow a managed pointer to overlap a double, so it is impossible to compact InternalObject into 8 bytes.

How to Make JSON Parser Strict

Kazuhiro Fujieda — Sat, 26 Sep 2020 07:32:17 +0000

I developed a JSON Parser for C# named DynaJson. It is very strict to the standard of RFC 8259. The parser accepts all conformant and rejects all non-conformant JSONs except for two exceptions.

One exception is trailing-commas. Another is leading 0 in numbers, for example, 02 and -02. The former is for practicality. The latter is for compatibility with DynamicJson.

JSON's grammar is simple, but carelessly implemented parsers don't accept all conformant and not reject non-conformant JSONs. An excellent article of Parsing JSON is a Minefield shows where mines are in implementing JSON parsers.

For example, some parsers reject just scalars such as null. Some parsers reject arrays of empty arrays such as [[][]], or numbers whose exponent digit is 0 like 1e0. Many parsers reject objects whose keys are not unique such as {"a":1,"a":2}.

Most parsers accept various non-conformant JSONs. They allow numbers such as .2, -.1, and +1, strings containing not escaped control characters or trailing garbage such as [0]].

DynaJson had struck many mines at first because of prejudice and carelessness. I finally made it strict, as mentioned above. It rejects most non-conformant JSONs to detect breakage.

JSON Parsing Test Suite developed by the article's author can show how parsers handle these corner cases. I created a fork of it to check six parsers for .NET and show the results below.

The left part shows the files of tested JSONs. The center has the results. The right shows the JSONs. Parsers must accept files starting with y_, should reject with n_, can take either way about i_. The upper-left corner shows how the color of each result means.

System.Text.Json introduced since .NET Core 3.0 is the strictest. It accepts all conformant and rejects all non-conformant, but can accept trailing-commas with an option. Only Utf8Json among them can't take trailing-commas.

Each parser has a pattern of accepted non-conformant JSONs. Json.NET takes objects whose keys are not strings. Utf8Json allows trailing garbages. DynamicJson takes objects not enclosed with }. Jil allows incorrect exponent parts in numbers.

The results colored red at the bottom are of parsing JSONs nested 100,000 times and not closed. Parsers should reject them. But DynamicJson resulted in a timeout after processing 5 sec. Jil and Utf8Json caused stack overflow and crashed.

Json.NET allows unlimited nesting until the upper bound of memory by default. It can reject them with syntax errors. System.Text.Json and DynaJson have configurable maximums of the nesting level. The former is 64, and the latter is 512. So both reject the JSONs because of too deep nesting.

[Unity] How to Use Physics.OverlapCapsule

Kazuhiro Fujieda — Fri, 25 Sep 2020 13:03:03 +0000

Updated on 2021-09-06: This article was largely revised to take into account the rotation of the attached game object and the direction of the CapsuleCollider.

You can use Physics.OverlapCapsule to get the two Colliders overlapped with the CapsulCollider as above. This method takes the position and size of a capsule and returns all Colliders overlapped by the capsule.

You can also get the Colliders by configuring a Kinematic Rigidbody Trigger Collier and handling the OnTriggerEnter message, but the method is handy and has useful applications.

The following shows the signature without optional arguments of Physics.OverlapCapsule.

Collider[] OverlapCapsule(Vector3 point0, Vector3 point1, float radius);

The left side of the following figure illustrates these arguments. Each of point0 and point1 has the center of either of the hemispheres. The radius has the radius. The specs of a CapsuleCollider on the right side have its center, height, and radius. They are quite different, so you need to convert them.

The following shows how to calculate the point0 and point1 for the CapsuleCollider. The calculation must take into account the direction property of the CapsuleCollder, which can be 0, 1, or 2 correspondings to X, Y, or Z-axis, respectively.

var col = GetComponent<CapsuleCollider>();
var direction = new Vector3 {[col.direction] = 1};
var offset = col.height / 2 - col.radius;
var localPoint0 = col.center - direction * offset;
var localPoint1 = col.center + direction * offset;

We must specify the point0 and point1 in the world space.

var point0 = transform.TransformPoint(localPoint0);
var point1 = transform.TransformPoint(localPoint1);

We must translate the radius of the CapsuleCollider to the world space for the radius of Physics.OverapCapsule. But, it is not simple. If the attached game object is elliptic on the surface perpendicular to the direction, it is necessary to expand the radius of the CapsuleCollider to the long diameter side.

The following shows the implementation of this translation. Please notice that some components of the vector returned by the TransformVector can be minuses.

var r = transform.TransformVector(col.radius, col.radius, col.radius);
var radius = Enumerable.Range(0, 3).Select(xyz => xyz == col.direction ? 0 : r[xyz])
    .Select(Mathf.Abs).Max();

Finally, we can invoke Physics.OverlapCapsule with the values calculated so far.

var cols = Physics.OverlapCapsule(point0, point1, radius);

Notice that the returned Colliders naturally include the CapsuleCollider. You can disable it in advance if you want to exclude it.

Physics.OverlapCapsule is so useful that you can give it a slightly smaller size to exclude just touched Colliders from the result. You can also give it a larger size to get almost colliding Colliders.

By the way, Physics.OverlapCapsule allocates and returns an array to store the results in each invocation, so it causes a lot of allocation when you invoke it on every frame.

In this case, you should use Physics.OverlapCapsuleNonAlloc. This variant stores the results to an array allocated in advance. The usage is shown below.

class DetectOverlap
{
    readonly Collider[] _result = new Collider[5];

    void Update()
    {
        ...
        var num = Physics.OverlapCapsuleNonAlloc(point0, point1, radius, _result);
    }
}

In this usage, Physics.OverlapCapsuleNonAlloc can detect up to 5 overlapped Colliders. The method takes an array of 5 Colliders allocated outside Update, stores the results in the array, and returns the number.