DEV Community: semuserable

dotnet cross-platform interop with C via Environment.ProcessId system call

semuserable — Fri, 28 Mar 2025 08:19:12 +0000

The goal of this article is to understand how high-level dotnet code interoperates with low-level C code in a cross-platform manner when making system call via Environment.ProcessId in dotnet.

We'll delve into the differences between running it on windows and unix-like (macOS, Linux) operating systems in a cross-platform manner. We'll also write some C code to check and prove that we really understand what's going on.

Before the start

I assume my reader is a person who is well-versed with general programming concepts and have a curiosity towards inner working of dotnet platform.

Just to note, I'm not an expert in system programming topic, so I may be wrong or misinterpret something. But for this article, I wanted to play around with C and prove the concepts that I want to understand. Basically, the whole point of this article is to document my findings.

Pre-requisites

If you want to follow along, this is the suggested list of tools that should be installed

dotnet (.NET 9 is used for this article) and C# decompiler
a copy of dotnet runtime
IDE of choice - Visual Studio Code, Visual Studio, Rider
any operating system (OS) you're most comfortable with - macOS, Linux, Windows
docker and/or any virtualization technology - Parallels, UTM, virtualbox

All provided examples were done on macOS M1 (aarch64 architecture), docker and Rider was used as an IDE and decompiler for C#.

System call

Before delving into the code, let's provide a definition to a system call.

System call is a mechanism that allows user-level applications to request services from the operating system's kernel, such as accessing hardware, managing files, creating and terminating processes, and facilitating communication between processes.

As an example, if your code creates a file (via File.Create high-level API) you're basically making a system call to the underlying operating system. If you make an HTTP request, you do a system call, and so on.

The path of Environment.ProcessId

We'll start exploring the simplest possible system call - Environment.ProcessId (get the unique identifier for the current process).

Let's introduce various deepness levels:

client-level developer-level calls, the decompilation starts here, this code is expected to be written by a developer and called in Production
high-level decompiled C# code, implementation details can start to differ, this is not expected to be written directly by a developer
low-level direct or indirect calls to C\C++ code, operating system specific implementation details, the lowest level we're aiming for

Each level will be accompanied by a diagram for visual understanding of calls. For various operating systems, an appropriate decompiled code will be presented too.

Let's get started!

Client-level

This is the code that you should write if you want to get a process id

var processId = Environment.ProcessId;
Console.WriteLine(processId); // output: 1 (this is an example value)

Let's start outlining this call via a diagram

High-level

Now we need to decompile Environment.ProcessId which resides in System.Runtime.dll. We'll be decompiling for two major flavours of operating systems:

unix-like - various Unix and Unix-like operating systems: macOS, gnu/Linux (Debian, Ubuntu, etc.), musl/Linux (Alpine), iOS, Android
windows - Windows only

info "Decompilation"

unix-like flavour is decompiled on macOS M1 via Rider

windows flavour is decompiled on Windows 11 on Parallels via Rider

Decompiled code

unix-like

public static partial class Environment
{
  public static int ProcessId
  {
    get
    {
      int processId = s_processId;
      if (processId == 0)
      {
          s_processId = processId = GetProcessId();
          // Assume that process Id zero is invalid for user processes. It holds for all mainstream operating systems.
          Debug.Assert(processId != 0);
      }
      return processId;
    }
  }
}

windows

public static partial class Environment
{
  public static int ProcessId
  {
    get
    {
      int processId = Environment.s_processId;
      if (processId == 0)
        Environment.s_processId = processId = Environment.GetProcessId();
      return processId;
    }
  }
}

note "Implementation details"

These are the implementation details, important point here is that it can change between dotnet versions. Don't expect it to be be always the same.

We can already notice differences between unix-like and windows operating systems. Although it looks quite similar, in reality these are two completely different calls. Notice that Environment class is declared as static partial meaning that during dotnet runtime build process we can use (substitute) platform-specific implementations.

Low-level

In order to really see this difference we need to go one level deeper. Let's decompile GetProcessId() for unix-like and Environment.GetProcessId() for windows.

unix-like

// Environment.Unix.cs
public static partial class Environment
{
  [MethodImplAttribute(MethodImplOptions.NoInlining)] // Avoid inlining PInvoke frame into the hot path
  private static int GetProcessId() => Interop.Sys.GetPid();
}

// Interop.GetPid.cs
internal static partial class Interop
{
    internal static partial class Sys
    {
        [LibraryImport(Libraries.SystemNative, EntryPoint = "SystemNative_GetPid")]
        internal static partial int GetPid();
    }
}

windows

// Environment.cs
public static partial class Environment
{
  [MethodImpl(MethodImplOptions.NoInlining)]
  private static int GetProcessId() => (int) Interop.Kernel32.GetCurrentProcessId();
}

// Interop.cs
internal static class Interop
{
  internal static class Kernel32
  {
    [LibraryImport("kernel32.dll")]
    [DllImport("kernel32.dll")]
    internal static extern uint GetCurrentProcessId();
  }
}

note "Combined results"

These are combined results from several levels of decompilation.

Here we've been introduced to Interop class which is a bridge between managed and unmanaged (native) worlds.

From now on, we'll investigate each operating system flavour separately starting with windows and then moving on to unix-like, which will be covered in more depth.

windows

Firstly, we'll look into windows chain of calls.

[LibraryImport("kernel32.dll")]
[DllImport("kernel32.dll")]
internal static extern uint GetCurrentProcessId();

All C interop calls are facilitated via DllImport (old approach) and/or LibraryImport (new approach). DllImport (or LibraryImport) is the real bridge that connects managed and unmanaged worlds in dotnet. This is part of dotnet Platform Invoke (P/Invoke) technology.

This code is telling the following: import kernel32.dll dynamic library (only exists on Windows) allowing access to native GetCurrentProcessId function. Using the above declaration the function name must fully match the native counterpart, otherwise it won't work.

This is it for windows. It's just a direct call to GetCurrentProcessId from kernel32.dll, that's it. But for unix-like it's not that simple.

unix-like

Now it's turn to delve into unix-like chain of calls.

[LibraryImport(Libraries.SystemNative, EntryPoint = "SystemNative_GetPid")]
internal static partial int GetPid();

Shim via `Libraries.SystemNative`

This is where the things start to diverge quite a bit. Firstly, instead of kernel32.dll a lib called Libraries.SystemNative
is being loaded instead. Secondly, LibaryImport.EntryPoint property says that there is a function called SystemNative_GetPid that needs to be used in order to get process id.

Let's go step by step. Looking into dotnet runtime we can find that Libraries.SystemNative acts as a shim (adapter) to a dynamic library called libSystem.Native.

internal static partial class Interop
{
    internal static partial class Libraries
    {
        internal const string libc = "libc";

        // Shims
        internal const string SystemNative = "libSystem.Native";
        internal const string NetSecurityNative = "libSystem.Net.Security.Native";
        internal const string CryptoNative = "libSystem.Security.Cryptography.Native.OpenSsl";
        internal const string CompressionNative = "libSystem.IO.Compression.Native";
        internal const string GlobalizationNative = "libSystem.Globalization.Native";
        internal const string IOPortsNative = "libSystem.IO.Ports.Native";
        internal const string HostPolicy = "libhostpolicy";
    }
}

info "shim explained"

In the context of dotnet and system libraries, a shim is a small compatibility layer that acts as an intermediary between your application and the actual system APIs. It does the following:

hides platform-specific details and provides a unified API

allows dotnet code to run on multiple operating systems without changing how it calls system functions

libSystem.Native on various unix-like operating systems

So, it seems that for unix-like operating systems there is an additional library called libSystem.Native that's supplied by dotnet runtime. Let's inline it's name and check the call again.

[LibraryImport("libSystem.Native", EntryPoint = "SystemNative_GetPid")]
internal static partial int GetPid();

In order for this to work libSystem.Native dynamic library must be physically present on unix-like operating system.

Let's find it!

info "dynamic libraries on various operating systems"

Various operating systems use different dynamic library extensions:

macOS - .dylib

Linux - .so

Windows - .dll

macOS

find /usr/local/share/dotnet -name "libSystem.Native.*"

output

/usr/local/share/dotnet/shared/Microsoft.NETCore.App/9.0.2/libSystem.Native.dylib

Linux

run via docker

docker run --rm mcr.microsoft.com/dotnet/runtime:9.0 find / -name "libSystem.Native.*"

output

/usr/share/dotnet/shared/Microsoft.NETCore.App/9.0.2/libSystem.Native.so

Windows

there is no libSystem.Native.dll on Windows as this shim is used for unix-like only

So, depending on the operating system dotnet supplies a specific libSystem.Native version of the library: .dylib for macOS, .so for Linux.

SystemNative_GetPid and System.Native

We've found where libSystem.Native resides, it's provided by dotnet runtime, now it's time to understand what SystemNative_GetPid call is.

The real implementation of SystemNative_GetPid can be found in pal_process.c (with accompanying header file) which is inside System.Native folder.

But before we continue, let's get acquainted with PAL concept first. In dotnet runtime, PAL stands for Platform Abstraction Layer. It's a component that enables dotnet to run on multiple operating systems and hardware platforms. It provides a consistent interface between dotnet runtime and the underlying operating system, abstracting away platform-specific details. This allows the majority of dotnet runtime code to be platform-agnostic.

Now onto C code

// System.Native/pal_process.h, declaration
PALEXPORT int32_t SystemNative_GetPid(void); 

// System.Native/pal_process.c, implementation
#include <unistd.h> // 'getpid' resides here
int32_t SystemNative_GetPid(void)
{
  return getpid();
}

// System.Native/entrypoints.c, exporting to be available in C# interop
static const Entry s_sysNative[] =
{
  DllImportEntry(SystemNative_GetPid)
}

source code: pal_process.h, pal_process.c, entrypoints.c

The crux of provided snippet is the real implementation that works on all unix-like operating systems. Let's finalize the flow of calls by adding low-level chain of calls into the diagram.

Conclusion? Not yet

getpid() is the function that's being called on unix-like operating systems.

We've basically covered all flows for Environment.ProcessId call and the article could finish here. But my curiosity was still thirsty and I needed to know exactly what getpid function does, how it works on different unix-like systems and where it resides.

If you're like me, then continue reading.

C Standard Library (libc) and POSIX

Here is getpid() function and it gets current process id. But wait a sec, how does it do that? If getpid() is being called from libSystem.Native then where is the lib where the actual getpid() resides? Also, how it handles various unix-like operating systems?

I'm glad you've asked! This is the topic we'll start exploring now. But first, we need to understand what C Standard Library (libc) and POSIX are.

libc

C Standard Library (libc) is the standard library for the C programming language, also called libc (this term will be used from now on). libc provides various macros, type definitions and functions for tasks such as string manipulation, mathematical computation, input/output processing, memory management, and so on.

From C language perspective libc defines a set of header files which can be used in programs: stdio.h, math.h, etc. (full list can be found here). libc is available on all C-compliant platforms, it works on Windows, macOS, Linux.

Example time!

Let's write a simple C program which will be using libc function calls and which will work on all major operating systems.

#include <stdio.h> // '<stdio.h>' header resides in 'libc' library
#include <math.h>  // '<math.h>' header resides in 'libc' library

int main(void) {
  printf("This is 'libc' call!\n"); // 'printf' function is from '<stdio.h>' header which resides in 'libc' library
  printf("exp(1) = %f\n", exp(1));  // 'exp' function is from '<stdio.h>' header which resides in 'libc' library
  return 0;
}

It's time to compile and run it!

info "compiling C in a cross-platform manner"

I want to compile C program for various operating systems from one machine, that's why on macOS M1 I use zig drop-in replacement compiler (can be used on Linux, Windows too) for cross-platform compilation.
There are also clang, gcc (usually pre-installed on macOS and Linux). For Windows there are
Visual Studio installer or mingw (which installs gcc).

Another important thing to remember is that I compile for aarch64 architecture for M1 series of processors, if you use Intel or AMD you'd need to
compile for x64/x84 architecture.

macOS (native)

compile

zig cc -o libc_example_macos libc_example.c

./libc_example_macos

output

This is 'libc' call!
exp(1) = 2.718282

gnu/Linux (cross-compile)

compile

zig cc -o libc_example_linux_gnu libc_example.c -target aarch64-linux-gnu

run via docker

docker run --rm -v "$PWD":/app -w /app debian:latest sh -c "./libc_example_linux_gnu"

output

This is 'libc' call!
exp(1) = 2.718282

musl/Linux (cross-compile)

compile

zig cc -o libc_example_linux_musl libc_example.c -target aarch64-linux-musl

run via docker

docker run --rm -v "$PWD":/app -w /app alpine:latest sh -c "./libc_example_linux_musl"

output

This is 'libc' call!
exp(1) = 2.718282

Windows (cross-compile)

compile

zig cc -o libc_example_windows.exe libc_example.c -target aarch64-windows

run via virtual machine

libc_example_windows.exe

output

This is 'libc' call!
exp(1) = 2.718282

info "Linux flavours: gnu and musl"

There are various Linux flavours. Broadly speaking there are two main ones: gnu (Debian, Ubuntu, etc) and musl (Alpine, etc).

Awesome! libc_example.c program works everywhere!

But where is libc actually lives? We're ready to answer that: each operating system implements its own version of libc. libc can be treated as an interface and each operating system implements its own version. Let's visualize that.

info "How to read a table"

Below is a reference table comparing how the libc is >implemented across major operating systems. Each row describes the >following:

Operating system self-explanatory

C standard library (libc) the name by which libc is commonly known on each platform

Dynamic library name the actual dynamic library file that contains the implementation

Function name an example function name that remains consistent across platforms despite the different underlying implementations

Operating system	macOS	Linux	Windows
C standard library (libc)	BSD	gnu or musl	MSVRT/UCRT
Dynamic library name	libSystem.dylib	libc.so.6 or libc.so	msvcrt.dll
Function name	printf	printf	printf

Each operating system links its own version of libc (via dynamic or static linking) during C compilation phase. It means that all functions from libc are always available and can be used from any C program without any additional setup. Important thing to note is that it can actually be several physical files (dynamic libraries) that implement libc and dynamic library name can also differ (we'll see it in the context of macOS later, as it's an operating system level implementation detail).

Phew!

We covered libc, but we still haven't figured out where getpid lives and how it's connected to libc, the next section will provide more details on that.

POSIX

POSIX is a family of standards for maintaining compatibility between operating systems. It defines a common set of APIs and
behaviors for unix-like operating systems. Before POSIX, Unix systems were highly fragmented — each vendor had different APIs,
making cross-platform development difficult. POSIX was introduced to standardize system calls and libraries. On unix-like systems POSIX API is part of libc
(aka superset of libc).

And you know what? getpid() is POSIX API call! Here's getpid for Linux and
getpid for macOS.

Important distinction between unix-like and windows is that POSIX API is not supported on Windows. Windows uses WinAPI instead and GetCurrentProcessId from kernel32.dll is WinAPI call. That's why we have two completely different flows from dotnet PAL perspective.

info "POSIX support for Windows"

Altough, built-in libc on Windows doesn't support POSIX API and dotnet uses WinAPI instead, POSIX support can be added externally via cygwin, WSL or MinGW.

Remember that dotnet as a platform has been on Windows for tens of years already (via .NET Framework which is outdated) and a final cross-platform support was added only starting from .NET Core. There is also Mono runtime but let's leave it for now as it's not related for the current article. Overall, here's the [history of dotnet (https://en.wikipedia.org/wiki/.NET) if you need more details.

Are you confused yet?

I guess some examples are needed here! So, let's call POSIX API for unix-like and WinAPI for windows to get process id in C language.

unix-like (file name: get_pid_unix_like.c)

#include <stdio.h>   // '<stdio.h>' header resides in 'libc' library
#include <unistd.h>  // '<unistd.h>' header resides in 'libc' library and it's 'POSIX API'

int main() {
    pid_t pid = getpid();  // 'getpid' function is from '<unistd.h>' header which resides in 'libc' library and it's 'POSIX API'
    printf("Current Process ID: %i\n", pid);

    return 0;
}

windows (file name: get_pid_windows.c)

#include <stdio.h>    // '<stdio.h>' header resides in 'libc' library
#include <windows.h>  // '<windows.h>' header resides in 'WinAPI' library

int main() {
    DWORD pid = GetCurrentProcessId(); // 'GetCurrentProcessId' function is from '<windows.h>' header which resides in 'WinAPI' library
    printf("Current Process ID: %lu\n", (unsigned long)pid);

    return 0;
}

Now it's time to compile and run.

info "Linux: glibc vs musl"

For gnu/Linux the actual implementation of libc and POSIX API is called glibc while for musl it's called... musl. By the way, musl is mostly POSIX-compliant, not fully. But for the sake of current discussion it doesn't matter, as getpid will work on any Linux flavour.

For the next example, I specifically excluded musl/Linux as for musl compilation static linking is used instead of dynamic linking. During static linking, the call to getpid will be directly included into the resulting program so we won't be able to see the actual dynamic library file whereabouts.

macOS (native get_pid_unix_like.c)

compile

zig cc -o get_pid_macos get_pid_unix_like.c

./get_pid_macos

output

Current Process ID: 67194

gnu/Linux (cross-compile get_pid_unix_like.c)

compile

zig cc -o get_pid_linux_gnu get_pid_unix_like.c -target aarch64-linux-gnu

run via docker

docker run --rm -v "$PWD":/app -w /app debian:latest sh -c "./get_pid_linux_gnu"

output

Current Process ID: 7

musl/Linux (cross-compile get_pid_unix_like.c)

compile

zig cc -o get_pid_linux_musl get_pid_unix_like.c -target aarch64-linux-musl

run via docker

docker run --rm -v "$PWD":/app -w /app alpine:latest sh -c "./get_pid_linux_musl"

output

Current Process ID: 1

Windows (cross-compile get_pid_windows.c)"

compile

zig cc -o get_pid_windows.exe get_pid_windows.c -target aarch64-windows

run via virtual machine

get_pid_windows.exe

output

Current Process ID: 17256

Based on the provided examples, when get_pid_unix_like.c is compiled it will work only on unix-like systems and get_pid_windows.c will work only on windows respectively. As we've seen previously, for windows, dotnet calls into GetCurrentProcessId() function directly, without any explicit C code ...

[LibraryImport("kernel32.dll")]
[DllImport("kernel32.dll")]
internal static extern uint GetCurrentProcessId();

... while for unix-like it calls directly into C via getpid.

#include <unistd.h> // 'getpid' resides here
int32_t SystemNative_GetPid(void)
{
  return getpid();
}

Now, where does getpid actually live?

"I want to physically know the library this function lives in!" (c) me

`getpid` whereabouts

We need to understand what operating system we're targeting. We'll focus only on two "flavours" of them: macOS and gnu/Linux (Debian, Ubuntu).

As we already compiled get_pid_macos and get_pid_linux_gnu from previous step, we can check which dynamic libraries were linked during the compilation phase.

macOS

run otool

otool -L ./get_pid_macos

output

./get-process-id-macos:
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)

gnu/Linux

run ldd

docker run --rm -v "$PWD":/app -w /app debian:latest sh -c "ldd ./get_pid_linux_gnu"

output

    linux-vdso.so.1 (0x0000ffffaa71a000)
    libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffffaa520000)
    /lib/ld-linux-aarch64.so.1 (0x0000ffffaa6dd000)

Based on provided outputs we can conclude the following:

on macOS - getpid function resides in libSystem.B.dylib dynamic library
on gnu/Linux (Debian) - getpid function resides in /lib/aarch64-linux-gnu/libc.so.6 dynamic library

When program is compiled, the system standard libraries (glibc/POSIX, WinAPI) are linked automatically so all of their functionality is available by default.

Conclusion

As a reminder from where we started

var processId = Environment.ProcessId;
Console.WriteLine(processId); // output: 1 (this is an example value)

Environment.ProcessId call does the following:

for unix-like operating systems (including macOS and various Linux flavours: gnu, musl), calls getpid function (which is POSIX)
for Windows, calls GetCurrentProcessId function (which is WinAPI)
each unix-like operating system implements its own version of C Standard Library (libc) and has its own flavour of libc - glibc (Debian, Ubuntu, etc), musl (Alpine, etc)
libc and WinAPI libraries are linked automatically during program compilation

We've only covered one simple system call, but it gave us a proper view into the inner details of how low-level interoperability with C is being done in dotnet runtime.

There are a lot of other system calls such as: working with files (IO), making HTTP requests, etc. All of them follow a similar pattern.

We also need to remember that all of that are implementation details and the actual chain of calls may change in future versions of dotnet.

Flavours of rounding

semuserable — Tue, 24 Aug 2021 00:00:00 +0000

How often do you round various numbers in your day-to-day job? Do you know what type of rounding do you actually use?

Let's compare several programming languages and their default (meaning without additional parameters if the rounding function allows it) rounding techniques.

I'll use several notions of rounding: banker's rounding, away from zero and round half up. More info about different techniques can be found on Wikipedia.

.NET

In dotnet (Framework, Core, 5+) banker's rounding is used by default.

Math.Round(0.5); // 0
Math.Round(1.5); // 2
Math.Round(2.5); // 2
Math.Round(3.5); // 4

Math.Round(-23.5); // -24

If you need away from zero, use the following

Math.Round(0.5, MidpointRounding.AwayFromZero); // 1
Math.Round(1.5, MidpointRounding.AwayFromZero); // 2
Math.Round(2.5, MidpointRounding.AwayFromZero); // 3
Math.Round(3.5, MidpointRounding.AwayFromZero); // 4

Math.Round(-23.5, MidpointRounding.AwayFromZero); // -24

If you need round half up, use the following

Math.Round(0.5, MidpointRounding.ToPositiveInfinity); // 1
Math.Round(1.5, MidpointRounding.ToPositiveInfinity); // 2
Math.Round(2.5, MidpointRounding.ToPositiveInfinity); // 3
Math.Round(3.5, MidpointRounding.ToPositiveInfinity); // 4

Math.Round(-23.5, MidpointRounding.ToPositiveInfinity); // -23

JavaScript

In JavaScript round half up is used be default.

Math.round(0.5); // 1
Math.round(1.5); // 2
Math.round(2.5); // 3
Math.round(3.5); // 4

Math.round(-23.5); // -23

Python (2.7, 3+)

In Python 2.7 away from zero is used by default.

round(0.5) # 1
round(1.5) # 2
round(2.5) # 3
round(3.5) # 4

round(-23.5) # -24

But in Python 3+ banker's rounding is used by default.

round(0.5) # 0
round(1.5) # 2
round(2.5) # 2
round(3.5) # 4

round(-23.5) # -24

This was quite surprising, to be honest.

Java

In Java (JDK 1.8.0, 9, 10, 11) round half up is used by default.

Math.round(0.5); // 1
Math.round(1.5); // 2
Math.round(2.5); // 3
Math.round(3.5); // 4

Math.round(-23.5); // -23

Go

In Go away from zero is used by default.

math.Round(0.5) // 1
math.Round(1.5) // 2
math.Round(2.5) // 3
math.Round(3.5) // 4

math.Round(-23.5) // -24

But if you want banker's rounding there is a default function for this too.

math.RoundToEven(0.5) // 0
math.RoundToEven(1.5) // 2
math.RoundToEven(2.5) // 2
math.RoundToEven(3.5) // 4

math.RoundToEven(-23.5) // -24

PHP

In PHP away from zero is used by default.

round(0.5); # 1
round(1.5); # 2
round(2.5); # 3
round(3.5); # 4

round(-23.5); # -24

Postgres pg_stat_statement setup via docker

semuserable — Tue, 29 Jun 2021 17:44:03 +0000

Sometimes we want to track and analyze SQL in postgres. It may be that you use some fancy ORM and all SQL is abstracted away, but then you begin to notice some performance drops and you're starting to suspect that the SQL you expected to be run "very efficiently", in fact performs poorly.

That's how I've got acquainted with pg_stat_statements tool. I suggest to read about it on the official site.

Here, we'll setup it for local development via docker.

Prerequisites

Docker

Configuration

run postgres in docker

docker run --name test-postgres -p 5432:5432 -e POSTGRES_PASSWORD=secretpass -d postgres

Make sure the port 5432 is not occupied by any process, otherwise the postgres won't be started (although container will be created).

go into container command prompt via interactive mode

docker exec -it test-postgres /bin/bash

edit postgresql.conf

In order to enable pg_stat_statements functionality we need to edit some settings in postgres config file. Execute the following commands one by one (or via &&).

echo "shared_preload_libraries = 'pg_stat_statements'" >> $PGDATA/postgresql.conf
echo "pg_stat_statements.max = 10000" >> $PGDATA/postgresql.conf
echo "pg_stat_statements.track = all" >> $PGDATA/postgresql.conf

Check if config is updated by running cat $PGDATA/postgresql.conf. New lines will be at the end.

Check F.29.3. Configuration Parameters for pg_stat_statements.max and pg_stat_statements.track properties.

connect to postgres shell via psql

psql -U postgres postgres

Where -U postgres (default user) is username and postgres is a database name.

Connection can be also established via any database tool like dbeaver (free), DataGrip (paid), etc.

create an extension via SQL

CREATE EXTENSION pg_stat_statements;

We've finished with the configuration and ready to start using the tool. We need to restart a container for changes to take an effect.

Run exit to leave postgres shell, then exit to leave container shell. Then start postgres again - docker start test-progres.

Playground

Connect to the database. We'll be using psql from within a docker container.

go into container bash again

docker exec -it test-postgres /bin/bash

then psql

psql -U postgres postgres

run some SQL several times.

SELECT * FROM pg_stat_statements;

You will see something like this.

userid	dbid	query	calls	total_time
10	13408	SELECT * FROM pg_stat_statements	1	0.1371

This is an excerpt, another columns don't really matter right now.

The most interesting columns are query, calls, total_time (in milliseconds).

Let's create moviesdb database first and then call the previous SQL again.

CREATE DATABASE moviesdb;

Query pg_stat_statements.

SELECT * FROM pg_stat_statements;

userid	dbid	query	calls	total_time
10	13408	SELECT * FROM pg_stat_statements	2	0.412
10	13408	CREATE DATABASE moviesdb	1	334.0824

We just touched a tip of an iceberg. There are numerous ways to query the table and get various insights. Try it out for yourself!

Starting with Fable (F#)

semuserable — Sat, 01 Feb 2020 19:06:47 +0000

TLDR: https://github.com/semuserable/fable-basic-interop

Starting with Fable (F#)
- Preface
- Tools
Bootstrapping
- Project structure
- JavaScript side
- Fable side
Basic interop
- window.alert()
- Math.random()
- DOM
- p5.js
Additional resources

Starting with Fable (F#)

Preface

I like F# and somewhat dislike vanilla JavaScript. When I found out that you can write front-end using F#, I was perplexed. That's how I met Fable - a compiler which translates F# into JavaScript via Babel. There are already a plethora of different languages which can be converted into JavaScript. So, why choosing F# specifically?

This is not a tutorial about F#, so I want to suggest checking out the awesome fsharpforfunandprofit and you can decide for youself. But for me personally, F# is a very powerful, pragmatic, functional language which allows to write succinct, statically typed (bullet-proof!) code without any semantic noise.

I want to write front-end with statically-typed language. Today, TypeScript is standard de-facto if you want to write 'JavaScript-with-types'. But still, you must understand what exactly TypeScript brings to the table. You must be prepared mentally. If you're too accustomed to type-less (dynamic) code, migration to TypeScript will be painful. You must embrace the types and learn how to use them otherwise you will be writing the same old JavaScript.

For me, Fable was a rough start. It's a fresh technology and as F# is not that widespread in the wild (in comparison to JavaScript, TypeScript), information about Fable is scarce. The official example projects are not easy to comprehend when you just want to start simple. They usually involve some tinkering around.

So, I decided to create an easy to follow tutorial about how you can start using Fable today. I want to spread the word about F# and Fable specifically, so more people can try using it.

I hope you'll like it. Enjoy!

Tools

Before the start, make sure you have everything installed.

nodejs with npm
dotnet core SDK
IDE - personally I use JetBrains Rider, but you can choose Visual Studio Code with ionide plugin or Visual Studio

Bootstrapping

Let's start by understanding the basic folder structure of a simple Fable app. I prefer to start simple and build upon that.

In order to bootstrap a project you could use an official guide, but personally I'm not using that approach much. You will be redirected to fable2-sample repository, but it's not that convenient to navigate inside (as for my taste). There are a bunch of projects with different setup and it's hard to find a really 'empty' project. Even 'minimal' one is not that 'minimal' and contains Fable.React, Fable.Elmish.React dependencies. For a person who just want to start, it could be overwhelming.

I still highly recomment to check fable2-sample as it contains a plethora of different approaches which you can use in Fable.

Latest Fable version is 3, so you can think that fable2-sample contains outdated projects, which is not true. All projects are on the latest version.

In dotnet world we use dotnet new commands to start new projects. I would like to do the same with Fable, but there are no official templates. That's why I created templates project where you just type dotnet new fable-empty and an empty project without redundant dependencies is created.

It's time to create a new empty project.

install templates

dotnet new -i Semuserable.Fable.Templates::*

create a folder and move into it
run

dotnet new fable-empty

If you want to uninstall templates, run dotnet new -u Semuserable.Fable.Templates

A minimal Fable project is created.

Let's ensure that everything is working

execute npm install
execute npm start
open up http://localhost:8080
press F12 and open Console tab

Here we can see Hello from Fable!

Project structure

Each Fable project can be split into 2 sides

JavaScript side - webpack, npm, static content (.html, .css etc)
Fable side - F# project

- public
    | index.html 
- src
    | App.fs
    | App.fsproj
| package.json
| package-lock.json
| webpack.config.js

public - static content
src - F# project (Fable) itself
package.json, package-lock.json - npm dependencies
webpack.config.js - webpack configuration

In this tutorial I'll use Fable.Core library without any additional dependencies.

JavaScript side

In order for Fable to interop with JavaScript eco-system, we must ensure that all needed libraries are installed with npm. For such a simple example, we won't use many dependencies, just the core ones in order to start the dev server and run Fable compiler.

Let's quickly review two important files - package.json and webpack-config.js

open up package.json

{
  "name": "App",
  "private": false,
  "scripts": {
    "start": "webpack-dev-server"
  },
  "dependencies": {
    "@babel/core": "^7.7.7",
    "fable-compiler": "^2.4.12",
    "fable-loader": "^2.1.8",
    "webpack": "^4.41.5",
    "webpack-cli": "^3.3.10",
    "webpack-dev-server": "^3.10.1"
  }
}

Here we see minimal dependencies that are needed to start a server. There are Fable specific ones: fable-compiler and fable-loader.

open up webpack.config.js

// Note this only includes basic configuration for development mode.
// For a more comprehensive configuration check:
// https://github.com/fable-compiler/webpack-config-template

var path = require("path");

var contentFolder = "./public";

module.exports = {
    mode: "development",
    entry: "./src/App.fsproj",
    output: {
        path: path.join(__dirname, contentFolder),
        filename: "bundle.js",
    },
    devServer: {
        contentBase: contentFolder,
        port: 8080,
    },
    module: {
        rules: [{
            test: /\.fs(x|proj)?$/,
            use: "fable-loader"
        }]
    }
}

Very basic webpack config. All we need to know right now is that content will be served from ./public folder (must have index.html created there), server will be listening to port 8080 and the bundle.js (an app) will be generated in ./public folder.

Fable side

Here we have a very basic .fsproj project setup. App.fsproj is a netstandard application and App.fs contains the actual Fable app.

Load src/App.fsproj project into IDE of your choice and open up App.fs file.

module App

// import Fable core types
open Fable.Core 

// JavaScrpt interop call
JS.console.log "Hello from Fable!"

By default, we just wrote some info into JavaScript console. Input some new stuff into log and refresh the page - http://localhost:8080.

That's some very basic interop provided by Fable.Core library.

Basic interop

In order to utilize the full power of Fable and F# we need to write some interop code to glue F# and JavaScript together. Our minimum job is to understand how to map JavaScript types to F# ones. We also can use some helpers in the form of TypeScript type definition files, more on that later.

There is an official Fable interop documentation which you can try on your own. Armed with the interop knowledge we can start implementing it by ourselves.

In this tutorial we'll implement window.alert() (which is absent from Fable.Core), Math.random() (which exists in Fable.Core, but we'll implement it nonetheless and I'll show additionally how you can find what is implemented by default and what's not), a little bit of DOM API and p5.js lib.

window.alert()

Let's start with window.alert(). Firstly, we need to understand what we try to implement here. Is this a JavaScript library, a React component (heavily used in real Fable apps, but we won't touch it here) or maybe something global?

window is a global object in JavaScript. Next thing, what is alert() call actually do? Does it accept parameters? These questions are usually answered by comprehensive documentation. Let's open it and see how it can help. From docs, we see that alert function accepts one optional parameter of type string.

Now we have all necessary info for F# implementation. Let's try!

Open up App.fs and write

// interface
type Window =
    // function description
    abstract alert: ?message: string -> unit

// wiring-up JavaScript and F# with [<Global>] and jsNative
let [<Global>] window: Window = jsNative

// client calls
window.alert ("Global Fable window.alert")
window.alert "Global Fable window.alert without parentheses"

Here I used an F# interface approach which described a mapping between JavaScript and F# via some interface magic.

If you still has a process running after previous npm start just save and reload the page. You should see two sequential alert popups!

Let's try another approach.

// Special attribute for mapping, $0 == message parameter
[<Emit("window.alert($0)")>]
let alert (message: string): unit = jsNative

alert ("Emit from Fable window.alert")
alert "Emit from Fable window.alert without parentheses"
"Emit from Fable window.alert with F# style" |> alert

You can choose whatever approach you want, it mostly depends on your style or libraries which you try to incorporate.

Have you noticed a subtle difference between the two calls? The former call has an optional parameter while the latter one is required.

Math.random()

Next one is Math.random(). Using the knowledge we already gained, we know that math is also a global object in JavaScript. If you are unsure you can always check the official docs.

// interface
type Math =
    abstract random: unit -> float

let [<Global>] Math: Math = jsNative

// client call
JS.console.log (Math.random())

Pretty easy, but I want to point out one important thing. Have you noticed that we wrote Math and not math where jsNative is used? Thats's because by importing it like that you must be sure that F# name is exactly the same as a JavaScript one. JavaScript API is Math.random(), not math.random().

Another one

[<Emit("Math.random()")>]
let random(): float = jsNative

JS.console.log (random())

Math.random() is implemented in Fable.Core, you don't need to recreate it again. You can find what's implemented or not by taking a look at official Fable packages.

Reload the page and check the console (F12 -> Console)

DOM

Now, we'll work with DOM! We'll create a div element with a text inside and attach it to some div.

Here's what we'll implement

// https://developer.mozilla.org/en-US/docs/Web/API/Document/createElement#JavaScript

var newDiv = document.createElement("div"); 
var newContent = document.createTextNode("Hi from F# Fable!"); 
newDiv.appendChild(newContent);  

var currentDiv = document.getElementById("app"); 
document.body.insertBefore(newDiv, currentDiv);

Alright, we need to understand where we want a new div to be attached. Do you remember index.html file? It's time to open it - project_folder/public/index.html.

Open index.html and add <div id="app"></div> above script

<!DOCTYPE html>
<html>
    <body>
        <div id="app"></div>
        <script src="bundle.js"></script>
    </body>
</html>

We'll be adding new stuff before app div.

Where should we start with this one? Again, documentation. We need to understand what functions we're going to use.

document.createElement() - returns Element which is Node
document.createTextNode() - returns Text which is Node
Node.appendChild() - returns Node
document.getElementById() - returns Element which is Node
Node.insertBefore() - returns Node

By using info from the docs, create the following F# structure

// interfaces
type Node =
    abstract appendChild: child: Node -> Node
    abstract insertBefore: node: Node * ?child: Node -> Node

type Document =
    abstract createElement: tagName: string -> Node
    abstract createTextNode: data: string -> Node
    abstract getElementById: elementId: string -> Node
    abstract body: Node with get, set

let [<Global>] document: Document = jsNative

// client code
let newDiv = document.createElement("div")

"Good news everyone! Generated dynamically by Fable!"
|> document.createTextNode
|> newDiv.appendChild
|> ignore

let currentDiv = document.getElementById("app")
document.body.insertBefore (newDiv, currentDiv) |> ignore

Notice that I implemented document.createElement without an options parameter which is optional in docs. That's totally fine.

close the npm process by pressing Ctrl-Z. index.html in public folder is NOT auto-reloading.
run npm start

Open up http://localhost:8080/ in a browser and behold!

If you want to work with DOM you don't need to recreate all the bindings from scratch, there is an official library! It's called Fable.Browser.Dom. Also, there are all other sorts of default stuff implemented in this official repository.

Now you know how to work with DOM via Fable.

p5.js

It's time to implement some part of the 3rd party library. I chose p5js as it's a library to draw graphics and animation!

Stop the current npm process (Ctrl+Z), move to the root of the project and run

npm install p5 --save

p5.js is installed locally and ready to be used. It's time to write some bindings!

There are several approaches which we can take here. We can open node_modules/p5/lib/p5.js and try to decipher functions and types, but I personally don't recommend to do it (only if you have no other choice) if you have access to the source code. Because what's stored in node_modules could be packed/abridged/minified version of the library.

First approach is to check the source code of the project. Like p5 constructor and createCanvas.

Next approach would be to check TypeScript type definition files by DefinitellyTyped. I highly recommend to check it for other libraries too. Taking p5.js as an example we have p5 constructor type definition and createCanvas type definition. The cool thing about this apporach, is that we already have types which we can convert directly (not always but still) to F# types, but we should do it manually.

Final approach would be to use ts2fable tool to convert TypeScript definition files into F# itself! It's like the second approach but automatic. You just supply *.ts file and it outputs F# types! How cool is that? But be aware, this output is not always what you want to include in your final bindings. You need to check if its what you really need. There are some differences between TypeScript and F# type systems, which must be checked manually.

Armed with all this knowledge we can finally write some p5.js bindings with Fable.

open Fable.Core

// p5.js interface
[<StringEnum>]
type Renderer =
    | [<CompiledName("p2d")>] P2D
    | [<CompiledName("webgl")>] WebGL

type [<Import("*", "p5/lib/p5.js")>] p5(?sketch: p5 -> unit, ?id: string) =    
    member __.setup with set(v: unit -> unit): unit = jsNative
    member __.draw with set(v: unit -> unit): unit = jsNative
    member __.createCanvas(w: float, h: float, ?renderer: Renderer): unit = jsNative
    member __.background(value: int): unit = jsNative
    member __.millis(): float = jsNative
    member __.rotateX(angle: float): unit = jsNative
    member __.box(): unit = jsNative

// client code
let sketch (it: p5) =
    it.setup <- fun () -> it.createCanvas(300., 300., WebGL)
    it.draw <- fun () ->
        it.background(255)
        it.rotateX(it.millis() / 1000.)
        it.box()

// draw    
p5(sketch) |> ignore

Lo and behold!

That's it for this tutorial. The final project can be found here.

Thanks for reading, I hope it was helpful!

Additional resources

fable.io - official site
Fable REPL - ready to use projects with REPL style
Fable community - libs, projects, templates
awesome Fable - curated list of useful Fable goodness, inspired by awesome

Simplest TypeScript project using Visual Studio Code

semuserable — Sun, 03 Mar 2019 12:19:27 +0000

Disclaimer: originally posted on medium, but revised and updated for dev.to

This tutorial is aimed for newcomers to TypeScript and Visual Studio Code. You won’t find here deep programming concepts or challenges as I tried to come up with the simplest possible solution. Originally it was written just for myself, but then I decided to share it. Also, it’s for Windows platform, but if you use another OS it’s not difficult to make a switch.

Preface

I won’t go into much detail about what TypeScript is as all the relevant info can easily be found on wiki, but rather how to start using it from within Visual Studio Code.

Setup

get Visual Studio Code
get Node.js. It comes with npm package manager
open command prompt and run the following command to install the latest stable version of TypeScript globally

npm install -g typescript

check globally installed packages

npm list -g --depth=0

Configuration

Create an empty folder and open it in Visual Studio Code.

First thing we need to do is to create tsconfig.json file. In order to do so we'll execute this command in terminal (Ctrl+` to open terminal)

tsc --init

create source code (ex. main.ts)

interface Person {
    age: number,
    name: string,
    say(): string
}

let mike = {
    age: 25, 
    name:"Mike", 
    say: function() { 
        return `My name is ${this.name} and I'm ${this.age} years old!`;
    }
}

function sayIt(person: Person) {
    return person.say();
}

console.log(sayIt(mike))

now we want to setup a convenient build process in order to run the project with a couple of buttons. Press Ctrl+Shift+P and start typing Configure Default Build Task, press Enter to select it then tsc: build - tsconfig.json. This will create a file named tasks.json in .vscodefolder (click Refresh Explorer on a project tab to see the changes). Now we have all needed commands and arguments for our build.

This is our project structure after all the steps.

Run

It’s time to finally run the build task. Press Ctrl+Shift+B and if all went well a new file will be created (main.js). In order to see the output we need to feed it into node command.

node main.js

Let’s see it in action!

Alrighty! We had fun with command line and eager to try something new. Let’s create a minimal html and change some DOM properties of the page through TypeScript.

Working with DOM

Create a new file named index.html. It’s so minimalist that I’m even embarassed a little bit.

<!DOCTYPE html>
<html>    
    <body>
        <h1>Fun with TypeScript</h1>
        <p id="rock_id">Let's rock</p>

        <script src="main.js"> </script>
    </body>
</html>

Let’s change main.ts file and modify <p> element inner text using TypeScript. The main part here is <script src=”main.js”> element. main.js is a transplied code from TypeScript and will run naturally.

WARNING!!! Another minimalist example!

document.getElementById("rock_id")!.innerHTML = "Changed by TypeScript!"

Final project structure after all the changes.

Press Ctrl+Shift+B and check main.js file (just for curiosity). Next, open index.html and observe the result. Wow! So easy!

index.html page

Awesome, but there is something strange in this example. What is ! symbol doing here? It’s called the non-null assertion operator. Compiler forces us to check for null/undefined values if tsconfig.json is configured with strict flag. If we try to omit it the compiler will yell at you.

Compiler error with -strict flag

We must explicitly check for null/undefined in order to safely use the return value from .getElementById. But in this example it’s redundant because I’m 100% sure that it won’t return any null/undefined. So I just use !.

That’s it! Thanks for reading!

DEV Community: semuserable

dotnet cross-platform interop with C via Environment.ProcessId system call

Before the start

Pre-requisites

System call

The path of Environment.ProcessId

Client-level

High-level

Low-level

windows

unix-like

Shim via Libraries.SystemNative

libSystem.Native on various unix-like operating systems

SystemNative_GetPid and System.Native

Conclusion? Not yet

C Standard Library (libc) and POSIX

libc

POSIX

getpid whereabouts

Conclusion

Flavours of rounding

.NET

JavaScript

Python (2.7, 3+)

Java

Go

PHP

Postgres pg_stat_statement setup via docker

Prerequisites

Configuration

Playground

Starting with Fable (F#)

Starting with Fable (F#)

Preface

Tools

Bootstrapping

Project structure

JavaScript side

Fable side

Basic interop

window.alert()

Math.random()

DOM

p5.js

Additional resources

Simplest TypeScript project using Visual Studio Code

Preface

Setup

Configuration

Run

Working with DOM

Shim via `Libraries.SystemNative`

`getpid` whereabouts