wigum::website - Computer Sciences

Recovering Windows After Wiping GRUB for Limine

2026-05-15T00:00:00+00:00

I had a working dual-boot setup: Manjaro on one SSD for work, Windows on another for leisure, with GRUB acting as the selector between them. GRUB would chainload Windows at boot. Everything worked fine – until I decided to replace Manjaro with Omarchy, which uses the Limine bootloader instead of GRUB.

I wiped the Manjaro SSD, installed Omarchy, and promptly lost access to Windows.

Here’s what happened and how I fixed it.

What Actually Broke

The setup had a hidden dependency: my UEFI firmware was booting GRUB, and GRUB was chainloading Windows. When I wiped Manjaro, GRUB disappeared – and with it, the only thing pointing at Windows.

Windows itself was completely untouched. The NTFS partitions on the Windows SSD were fine. But the EFI System Partition (ESP), the FAT32 partition that holds bootloaders, was on my NVMe drive alongside Omarchy, and the Windows EFI files (\EFI\Microsoft\Boot\) were simply gone.

Disk Layout

sdb (931 GB)          ← Windows SSD
├─ sdb1  16 MB        Microsoft Reserved Partition
├─ sdb2  930 GB NTFS  Windows C: drive
└─ sdb3  817 MB NTFS  Windows Recovery

nvme0n1 (1.8 TB)      ← Omarchy NVMe
├─ nvme0n1p1  2 GB vfat   ← ESP, mounted at /boot
└─ nvme0n1p2  1.8 TB LUKS → btrfs root

No EFI partition on the Windows SSD at all. The ESP was shared on the NVMe, and Manjaro’s wipe had taken the Windows EFI files with it.

Step 1: Configure Limine

Omarchy uses Limine, so the first task was adding a Windows entry to /boot/limine.conf. The key lesson here: match the path syntax of your working entries.

/Windows
    protocol: efi_chainload
    path: boot():/EFI/Microsoft/Boot/bootmgfw.efi

Step 2: Copy the EFI Files from the Windows Partition

The Windows bootloader (bootmgfw.efi) wasn’t on the ESP, but it was still sitting on the Windows partition itself, under Windows/Boot/EFI/. So I mounted the Windows SSD and copied it over:

sudo mkdir -p /boot/EFI/Microsoft/Boot
sudo cp -r /mnt/Windows/Boot/* /boot/EFI/Microsoft/Boot/

This allowed me to finally boot Windows from Limine, it could now find and launch bootmgfw.efi. But Windows then hit a different wall:

Recovery
The Boot Configuration Data for your PC is missing or contains errors.
File: \EFI\Microsoft\Boot\BCD
Error code: 0xc000000f

Step 3: Rebuild the BCD with bcdboot

The BCD (Boot Configuration Data) is a binary database that tells the Windows bootloader where the OS actually lives. It’s not part of the Windows/Boot/ folder – it gets generated by a Windows tool called bcdboot. You can’t create it from Linux.

This required a Windows installation USB. After booting it and hitting Shift+F10 to open a command prompt, the fix was:

diskpart

select disk 1          :: NVMe (1863 GB)
select partition 1     :: the 2048 MB ESP
assign letter=S

select disk 0          :: Windows SSD (931 GB)
select partition 2     :: the 930 GB primary partition
assign letter=C

exit

bcdboot C:\Windows /s S: /f UEFI

bcdboot regenerated the BCD store on the ESP, pointing it at the Windows installation on the other SSD. One reboot later, Limine showed the Windows entry and it booted cleanly.

SilvaScenes

2025-10-13T00:00:00+00:00

Co-authored paper: SilvaScenes: Tree Segmentation and Species Classification from Under-Canopy Images in Natural Forests

Interest in robotics for forest management is growing, but perception in complex, natural environments remains a significant hurdle. Conditions such as heavy occlusion, variable lighting, and dense vegetation pose challenges to automated systems, which are essential for precision forestry, biodiversity monitoring, and the automation of forestry equipment. These tasks rely on advanced perceptual capabilities, such as detection and fine-grained species classification of individual trees. Yet, existing datasets are inadequate to develop such perception systems, as they often focus on urban settings or a limited number of species. To address this, we present SilvaScenes, a new dataset for instance segmentation of tree species from under-canopy images. Collected across five bioclimatic domains in Quebec, Canada, SilvaScenes features 1476 trees from 24 species with annotations from forestry experts. We demonstrate the relevance and challenging nature of our dataset by benchmarking modern deep learning approaches for instance segmentation. Our results show that, while tree segmentation is easy, with a top mean average precision (mAP) of 67.65%, species classification remains a significant challenge with an mAP of only 35.69%. Our dataset and source code will be available at this https URL.

Docker Workshop

2025-09-07T00:00:00+00:00

Docker and containerization have revolutionized the way applications are developed, deployed, and managed. Containers provide a lightweight and efficient way to package applications and their dependencies, ensuring consistency across different environments.

Setup

The original workshop was designed to use with a virtual machine (willGuimont/IFT2001-Docker). While you can follow the instructions below to set up the virtual machine, you can also choose to follow the workshop using Docker.

Follow these steps to prepare your environment.

Install Docker
docker run -it --rm ubuntu:latest bash
In the Docker container, run:
1. apt update && apt install -y git
2. mkdir .atelier && cd .atelier && git clone https://github.com/willGuimont/IFT2001-Docker ateliers-iftglo-2001
3. cd ateliers-iftglo-2001
4. ./helper/install.sh
5. python3 ./helper/prepare_bashrc.py && source ~/.bashrc
6. Copy the files in your home directory: cd ~/.atelier/ateliers-iftglo-2001/files && cp -r . ~/

Instructions

The instruction above sets up your environment for the workshop. The grading commands are of the form correction_nn, where nn is an integer representing the exercise number, for example correction_03 for exercise 3. Instructions for validating commands will be provided with the first question that has an expected result.

To complete this workshop, you must perform each exercise directly in the terminal. You will use the nano text editor to modify the requested scripts. To open a file with nano, run the following in the terminal.

nano test.sh

You can then edit the file; enter

echo 'Hello world'

To exit nano, press CTRL-X, then answer y to save the changes. Run the following commands to validate that everything works:

chmod +x test.sh
./test.sh

These commands should print Hello world.

Adventurers only

If you are comfortable with the command line, we encourage you to try completing this workshop using vim as your text editor. A brief introduction to vim commands is available on MIT’s The Missing Semester. vim offers many shortcuts to edit text and code very efficiently. As a programmer, you will spend a lot of time writing code, so investing in learning vim is worthwhile for the rest of your career. There are plugins emulating vim commands for most IDEs: Vim for VS Code or IdeaVim for JetBrains products.

Please note that no assistance regarding vim will be provided during this workshop.

Solutions

Proposed solutions to the exercises in these workshops are available in the following GitHub repository: ulavalIFTGLOateliers/IFT2001-Docker.

Docker

After your success with Bash, your manager has given you a new mission: find a solution to the application deployment problem. Your company frequently encounters outages due to incompatibilities between different dependency versions. Indeed, each developer can choose the operating system they wish to work on. Consequently, some developers use different Linux distributions (Ubuntu, Arch, Gentoo), while others prefer Windows.

This situation often leads to version issues, as dependencies vary from one OS to another. And worse, the versions used differ from those deployed on the production server. The recurring excuse “It worked on my machine” when a developer causes a production outage has finally exasperated your manager. He is asking you to find a solution.

That’s how you discover Docker, a platform that lets you build, deploy, and run applications in lightweight, isolated containers. With Docker, you can create a specific container for each microservice, including all required libraries and dependencies. This approach ensures that each application will run consistently, regardless of library versions used by individual developers. Moreover, Docker allows you to reproduce the development environment on the production server, thereby eliminating issues stemming from environment differences.

With Docker, you will tackle the challenge of running your company’s three main microservices. Here are the microservices you must get working:

a web server health monitoring application written in Haskell;
a document management API written in Rust, requiring a PostgreSQL database; and
a Python application for visualizing web server health.

┌────────────────────────────── MICROSERVICES (ARCH OVERVIEW) ───────────────────────────┐
│                                                                                        │
│  (3) python_app (CLI)                                                                  │
│      Image: python_app                                                                 │
│      Mode: --network=host (workshop)                                                   │
│      BACKEND_URL = http://localhost:8080                                               │
│      Uses: list/add endpoints, view uptime stats                                       │
│            │                                                                           │
│            │ HTTP (JSON)                                                               │
│            ▼                                                                           │
│  (1) status-checker (Haskell)                                                          │
│      Image: status-checker                                                             │
│      Port: 8080                                                                        │
│      Storage: monitoring.sqlite (SQLite)                                               │
│            │                                                                           │
│            │ HTTP health probe (/documents or /health)                                 │
│            ▼                                                                           │
│  (2) rust_api (Actix Web)                                                              │
│      Image: rust_api (multi-stage)                                                     │
│      Port: 8081                                                                        │
│      Env: DATABASE_URL=postgres://postgres:postgres@db                                 │
│            │                                                                           │
│            │ SQL (Diesel)                                                              │
│            ▼                                                                           │
│      PostgreSQL                                                                        │
│      Image: postgres                                                                   │
│      Port: 5432                                                                        │
│      Volume: db:/var/lib/postgresql/data                                               │
│                                                                                        │
│  Data Flows (top→down):                                                                │
│    python_app ──HTTP──▶ status-checker ──HTTP──▶ rust_api ──SQL──▶ PostgreSQL          │
│                                                                                        │
│  Summary:                                                                              │
│    - python_app only contacts status-checker.                                          │
│    - status-checker pings rust_api for availability.                                   │
│    - rust_api persists documents in Postgres.                                          │
│                                                                                        │
│  Ports: 8080 (status-checker) | 8081 (rust_api) | 5432 (Postgres)                      │
└────────────────────────────────────────────────────────────────────────────────────────┘

Why containerization?

Isolation
One of the main advantages of containerization is isolation. It often happens that different applications require specific dependency versions. With Docker, you can install different dependency versions in distinct containers, without risking conflicts or compromising other applications. Furthermore, if you need to run applications on different operating systems, such as Ubuntu and Arch Linux, you can simply wrap them in Docker containers, avoiding the need to rewrite applications for each system.

Portability
Portability is another key advantage of Docker. Once you have set up a development environment with all required dependencies, reproducing that configuration on other machines or for new team members becomes tedious. Thanks to Docker, you can create an image that contains all required dependencies and configuration, which can be easily distributed and run on different platforms, whether Linux, Windows, or others. This enables a new team member to start quickly without spending weeks configuring their environment. It’s also an advantage when deploying applications to a server.

Reproducibility
Reproducibility is also simplified with Docker. Docker images are versioned, which means it is easy to reproduce builds identically, ensuring that development, test, and production environments are consistent. You just need to specify the version of the Docker image used to guarantee consistency and avoid issues related to variations across environments.

Efficiency
In terms of efficiency, Docker offers a significant advantage over virtual machines (VMs). Unlike VMs, Docker does not need to run a full operating system for each container, which greatly reduces resource consumption. Docker containers share the host kernel, making them lightweight and quick to start.

Community
Docker’s surrounding community is very active and offers a multitude of preconfigured images for various popular tools and technologies such as Node.js, Python, and many others. These preconfigured images facilitate deployment and usage of these technologies, saving developers time by avoiding manual environment setup.

Industry
Finally, it’s important to emphasize that Docker has become a de facto standard in the software development industry. Many companies use Docker for development, testing, and deployment of their applications. Docker is now an essential tool for software developers.

What is containerization?

Docker is an open-source software platform that lets you create, deploy, and run applications in lightweight, isolated containers. A Docker container is a runtime unit that encapsulates an application together with all of its necessary elements, such as libraries, dependencies, and configuration files. These containers are self-contained and portable, meaning they can run consistently across different systems, whether a development, test, or production environment.

Docker is similar to a virtual machine that isolates an application from the host system. However, Docker is much more efficient than a VM, which requires a full operating system for each instance. Docker instead shares the host operating system’s kernel, saving resources and making containers faster to start and run.

Here is some Docker terminology. You do not have to read the advanced sections to complete this workshop. As a supplement, you can watch the video “Never install locally”.

Docker Image
An image contains the filesystem and user-space components required by the application: binaries, libraries, dependencies, configuration files, and often a Linux distribution’s userland. It does not contain its own Linux kernel. Docker images are typically created from files called Dockerfile that specify the steps to build the image.

Dockerfile
A Dockerfile is a text file that contains the instructions to build a Docker image. It specifies the image layers, dependencies to install, files to include, and commands to run during image construction.

Docker Container
A Docker container is a running instance of a Docker image. It is an isolated environment that runs the application with its dependencies. Containers are lightweight, portable, and self-contained, which makes them easy to deploy across different machines.

Docker Registry
A Docker registry is a centralized repository that stores and manages Docker images. The default public registry is Docker Hub, where you can find many ready-to-use images. You can also create and use your own private registry to store your own images.

Union filesystem (advanced concepts)
The Union Filesystem, also known as UnionFS or OverlayFS, is a technology used by Docker to manage images and container layers efficiently. The Union Filesystem allows you to overlay multiple file systems into a single logical view without physically merging them. This means Docker images and containers can share and reuse common file layers, saving storage space. It also speeds up image builds by caching layers already built. When a container starts, a new read-write layer is added on top of the image layers, enabling container-specific changes without affecting others.

cgroups (advanced concepts)
cgroups, or control groups, are a Linux kernel feature used by Docker to limit and manage system resources used by containers. cgroups allow control of resources such as CPU, memory, disk bandwidth, and network, ensuring balanced and fair resource usage among containers. Docker uses cgroups to set limits and quotas on resources allocated to each container, ensuring isolation and predictable performance.

Namespaces (advanced concepts)
Namespaces are a Linux kernel feature that isolates system resources among processes. Docker uses several types of namespaces to provide isolation between containers, including the PID namespace (process isolation), the network namespace (network isolation), the user namespace (user isolation), and the mount namespace (mount point isolation). These namespaces ensure that each container has its own isolated view of the system, preventing processes in one container from interfering with others or with the host system.

Chroot jail (advanced concepts)
Chroot, or change root, is a Unix/Linux feature that changes a process’s root directory and limits its access to the file system. Docker uses chroot to create an isolated environment inside the container, where the container’s root directory becomes the starting point for all file paths. This limits the container’s access to files and directories outside its isolated environment, thereby strengthening security and isolation.

Containers manually

To clearly illustrate what Docker does, we will manually build a simplified container without using Docker. This section is inspired by p8952/bocker: Docker implemented in around 100 lines of bash. In a terminal, enter the following commands:

# Verify that neofetch is not installed
# The following command should raise an error; do not install the package
neofetch

# Folder for containers
mkdir ~/containers; cd ~/containers

# Build the container's filesystem
sudo apt update; sudo apt install -y debootstrap
sudo debootstrap jammy ./ubuntu-container http://archive.ubuntu.com/ubuntu/

# Create an isolated environment (namespace)
sudo unshare --uts --pid --mount --ipc --fork

# Mount process, system, device, and temp folders
mount -t proc none ./ubuntu-container/proc/
mount -t sysfs none ./ubuntu-container/sys
mount -o bind /dev ./ubuntu-container/dev
mount -o bind /tmp ./ubuntu-container/tmp/
cp /etc/apt/sources.list ./ubuntu-container/etc/apt/sources.list

# Use chroot to launch a shell in the container
chroot ./ubuntu-container/ /bin/bash
# and there you go, you're in an isolated container

# Install neofetch
apt update
apt install -y neofetch

# Test neofetch; the command works!
neofetch

# You can run commands in the container here.

# Exit the container
exit

# Exit unshare
exit

# If we try neofetch again, the command is not found.
# We have indeed isolated the container!
neofetch

As you can see, there is no magic in containers. There is no magic in a container: at its core, Linux provides mechanisms such as namespaces, filesystem isolation, and cgroups. Docker packages these mechanisms behind a convenient image, networking, storage, and lifecycle-management interface.

Docker basics

Exercise 01 – Running a prebuilt image

Run the Docker image hello-world.

To run a Docker image, use the run command.
docker run image-name

If the command works, you will see a message displayed.

Solution

docker run hello-world

To execute a command in the container, specify the command at the end of run. In the following examples, we pass bash -c 'echo "Hello world"' which interprets the string in the Bash interpreter.
# Prints 'Hello world' in an ubuntu container
docker run ubuntu bash -c 'echo "Hello world"'
# Prints information about the host system
cat /etc/os-release
# Prints information from a container running Arch Linux
docker run archlinux bash -c 'cat /etc/os-release'

To launch an interactive command (such as a shell), use the -it flag. The --rm flag removes the container once it exits.
docker run -it --rm archlinux bash

Exercise 02 – Container management

To see running containers: docker ps.

To stop a container: docker stop container_id.

Note that the command may take some time to run.

Tasks:

Launch an interactive terminal with Docker;
Open another terminal and inspect running containers;
Stop the Docker container from the second terminal.

Solution

# In the first terminal
docker run -it archlinux bash

# In the second terminal
docker ps
docker stop id
# or
docker rm -f id

Exercise 03 – Inspecting a running container

Containers often run in the background. Docker provides several commands to inspect and interact with running containers.

To display the output produced by a container:
docker logs container_name
To execute a command inside a running container:
docker exec container_name command
For example, to open an interactive shell:
docker exec -it container_name bash
Finally, docker inspect displays detailed information about a Docker object, including its network configuration, mounted filesystems, environment variables, and process configuration:
docker inspect container_name

Launch an nginx container in the background:

docker run --name web-server -d -p 8080:80 nginx

Tasks:

Verify that the container is running.
Display the container’s logs.
Open an interactive shell inside the running container.
From inside the container, inspect the files in /usr/share/nginx/html.
Use docker inspect to find the container’s IP address.
Stop and remove the container.

Solution


# Verify that the container is running
docker ps

# Display its logs
docker logs web-server

# Execute Bash inside the existing container
docker exec -it web-server bash

# Inside the container
ls /usr/share/nginx/html
exit

# Inspect the container
docker inspect web-server
# Find the IP address
docker inspect \
    --format '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' \
    web-server

# Stop and remove it
docker stop web-server
docker rm web-server

docker run creates a new container, whereas docker exec executes another process inside an already running container. This distinction is useful when debugging services running in the background.

Exercise 04 – PostgreSQL database

To set environment variables in a container, use the -e flag.
docker run -it --rm -e HELLO=hello archlinux sh -c 'echo $HELLO'

To open a network port, use the -p host:docker flag, where host is the port number on the host and docker is the port number inside the container.
docker run -p 127.0.0.1:8080:80 nginx
# You can access the port via the URL http://localhost:8080/
curl http://localhost:8080/

Launch a PostgreSQL database with Docker.

Requirements:

Image name: postgres
Set the environment variable POSTGRES_PASSWORD=postgres
Map Docker port 5432 to host port 5432
Leave this container running.

Solution

docker run -e POSTGRES_PASSWORD=postgres -p 5432:5432 --rm postgres
# or
docker run --name postgres -e POSTGRES_PASSWORD=postgres -p 5432:5432 --rm -d postgres

Dockerfile

Dockerfiles are configuration files used to create custom Docker images. They allow you to define, reproducibly and automatically, an application’s runtime environment inside a Docker container.

A Dockerfile contains a series of instructions that specify the steps needed to build a Docker image. These instructions include actions such as selecting the base image, installing dependencies, configuring environment variables, copying files, running commands, and more.

Here is an annotated example Dockerfile for a Python application.

# Use the Python 3.9 slim base image
FROM python:3.9-slim

# Set the working directory inside the container
# Specifies the directory for RUN, CMD, ENTRYPOINT, COPY, and ADD
WORKDIR /app

# Copy requirements.txt from the host into the Docker container
COPY requirements.txt .

# Run a Bash command to install Python dependencies
RUN pip install -r requirements.txt

# Copy the source code into the Docker container
COPY . .

# Set the default command when the container starts
CMD ["python", "app.py"]

To build the image, use docker build -t <tag> .. The -t <tag> argument gives the image the name <tag>. For the previous application, you could use docker build -t python-app .. Note that the order of instructions matters.

It is crucial to define the order of operations in a Dockerfile due to how Docker builds images. Each instruction in the Dockerfile creates a new layer in the Docker image, and the order can significantly impact build efficiency and performance.

Docker uses a cache to speed up image builds. When you run an instruction, Docker checks whether that instruction has already been executed in a previous layer. If so and the parameters are identical, Docker reuses the cached layer instead of rebuilding it. This saves build time. However, if you modify an instruction higher up in the Dockerfile, all subsequent instructions will have their cache invalidated and must be rebuilt. For example, if you perform resource-intensive operations such as compiling code that changes whenever you modify the source, it can be preferable to place those steps towards the end of the Dockerfile to benefit from caching as much as possible.

Exercise 05 – Haskell service Dockerfile

Use the README.md in the folder ~/Applications/status-checker to write a Dockerfile that runs the Haskell application.

Requirements:

Base image haskell:9.0-buster
Run stack setup --install-ghc
Workdir /app
Copy the source code into /app
Run stack build
Launch the server with stack run

Then, start the container exposing port 8080. If everything works, you should be able to run:

curl http://localhost:8080/endpoints
# Expected response
{}%
# Or
{}

Leave this container running.

Solution

Dockerfile:

FROM haskell:9.0-buster
RUN stack setup --install-ghc
WORKDIR /app
COPY . .
RUN stack build
CMD ["stack", "run"]

Execution:

docker build -t status-checker .
docker run --rm -p 8080:8080 status-checker

Exercise 06 – Python application Dockerfile

Use the README.md in the folder ~/Applications/python_app to write a Dockerfile that runs the Python application.

Then, launch the application interactively and with the correct network mode.

This application will need to access your computer’s local network to make requests to the container from the previous exercise; to keep this exercise simple, use --network="host" when running the container.

Host networking makes the container share the host’s network stack. This is convenient here, but it reduces network isolation and is not the usual way for containers to communicate with each other. Later, Docker Compose will place the containers on a shared Docker network, where services can communicate directly using their service names.

If everything works, you should be able to use the application to add URLs to monitor and see the results.

Solution

Dockerfile:

FROM python:3.9-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "main.py"]

Execution:

docker build -t python_app .
docker run --rm -it --network=host python_app

Advanced Docker

Sometimes, you may need to create more complex Docker images. Here, we will explore two advanced Docker features: multi-stage builds and volumes.

Multi-stage image builds

Multi-stage builds are an advanced Docker feature that enables optimized image creation using several distinct stages in the build process. This separates build and production stages, often resulting in final images that are lighter and more secure by minimizing what remains in the final image.

For example, for a JavaScript React application, we can split the build into two stages.

Create the application:

npx create-react-app my-app

Dockerfile:

# Stage 1: Build the application

# Use `as build` to name this build stage
FROM node:14-alpine as build
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

# Stage 2: Prepare the server
# Here, we start a new image from scratch
FROM nginx:alpine
# Copy the compiled app from the previous stage
COPY --from=build /app/build /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

To run:

docker build -t web-app .
docker run --rm -p 80:80 web-app

Exercise 07 – Rust multi-stage build

Use the README.md in the folder ~/Applications/rust_api to write a Dockerfile that runs the application.

Requirements:

Launch the PostgreSQL database from a previous exercise;
Create a first stage to compile the Rust code;
Create a second stage to run the code;
- Start this image from debian:bullseye-slim;
- Install the package libpq-dev with apt update; apt install -y libpq-dev;
- Set the environment variable DATABASE_URL=postgres://postgres:postgres@localhost
- Copy /app/target/release/rust_api from the previous stage;
Run the container with --network=host and expose the correct port;
Test that everything works with curl http://localhost:8081/documents.

Solution

FROM rust:latest AS build
WORKDIR /app
COPY . .
RUN cargo build --release

FROM debian:bullseye-slim
RUN apt update; apt install -y libpq-dev
WORKDIR /app
COPY --from=build /app/target/release/rust_api ./rust_api
ENV DATABASE_URL=postgres://postgres:postgres@db
CMD ./rust_api

Execution

docker run -e POSTGRES_PASSWORD=postgres -p 5432:5432 postgres
docker build -t rust_api .
docker run --rm --network=host rust_api

# Validate that the server works
curl http://localhost:8081/documents

Volumes and bind mounts

Containers have a writable filesystem, but this filesystem belongs to the container. If the container is removed, the data written inside it is also removed. Docker provides mounts to store data outside the container’s filesystem.

There are two common types of mounts: volumes and bind mounts.

A volume is storage managed by Docker. You give the volume a name, and Docker decides where the data is stored on the host:

docker run -v database-data:/var/lib/postgresql/data postgres

Here, database-data is a Docker volume and /var/lib/postgresql/data is the directory where PostgreSQL sees it inside the container. The data remains available even if the container is removed. Volumes are therefore particularly useful for persistent application data such as databases.

A bind mount directly maps an existing file or directory from the host filesystem into the container:

docker run -v ./src:/app/src my-app

Here, ./src is a directory on the host and /app/src is where it appears inside the container. Changes made on either side are immediately visible on the other side.

Volumes are generally appropriate for persistent application data. Bind mounts are useful when the container must directly access files from the host, for example source code, configuration files, or datasets.

For example, we can persist PostgreSQL data using a named volume:

docker run \
    -e POSTGRES_PASSWORD=postgres \
    -p 5432:5432 \
    --rm \
    -v postgres-data:/var/lib/postgresql/data \
    postgres

Docker creates and manages postgres-data. Removing the container does not remove the volume.

During development, we can instead use a bind mount to expose the Python application’s source code directly inside the container. This avoids rebuilding the image whenever the source code changes.

A DockerfileDev can therefore omit the source code:

FROM python:3.9-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
# We removed the line COPY . .
CMD ["bash"]

Build and run it with:

docker build -t python_app -f DockerfileDev . 
docker run --rm -it -v .:/app python_app
# In the container
python main.py
# Modify the source code
python main.py
# Changes are reflected in the container

Thus, you can reuse the same image even if the source code has changed.

Extras

Some additional Docker features and tools that may be useful in your projects.

Cleanup

When using Docker, it is important to consider the storage used by images, containers, volumes, and other Docker artifacts. Poor storage management can lead to excessive disk usage and make Docker maintenance and resource management difficult. Docker provides several prune commands to remove unused containers and images. To clean up various Docker artifacts, the command docker system prune -a -f removes all unused resources.

Docker Compose

Docker Compose is a tool that allows you to easily define and manage multi-container applications. It simplifies deployment and orchestration of Docker containers using a simple, readable configuration file.

With Docker Compose, you can specify services, networks, volumes, and other configurations needed to run an application composed of multiple containers. You can also define dependencies among containers, environment variables, exposed ports, etc.

Docker Compose uses a YAML configuration file to describe the application’s infrastructure. This file contains sections such as services, networks, volumes, etc., where you can define the different parts of your application and their configurations.

Here is an example docker-compose.yml for the Rust application that launches both the server and the PostgreSQL database:

# List of containers to launch
services:
  # Database container
  # We find many of the same parameters as with `docker run`
  db:
    # Image to launch
    image: postgres:18
    # Restart the database if the container stops
    restart: always
    # Environment variables passed to PostgreSQL
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
    # Store the database outside the container using a named volume
    volumes:
      - db:/var/lib/postgresql/data
    # Test whether PostgreSQL is ready to accept connections
    # Starting a container does not necessarily mean that the
    # application inside it is ready yet.
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5
      start_period: 5s
  
  # Rust server
  api:
    # Build the Dockerfile in the directory containing compose.yaml
    build: .
    # Start the API only once the database healthcheck succeeds
    depends_on:
      db:
        condition: service_healthy
    # Map host port 8081 to container port 8081
    ports:
      - "8081:8081"
    # Containers in the same Compose application share a network.
    # Services can reach each other using their service name.
    # Therefore, the database is available at hostname `db`
    # rather than `localhost`.
    environment:
      DATABASE_URL: postgres://postgres:postgres@db

# Named volumes used by the application
volumes:
  db:
    driver: local

Run with:

docker compose up --build

Compose creates a default network for the application. The api container can therefore resolve db as a hostname and connect directly to the PostgreSQL container.

depends_on normally controls startup order only. By combining it with the database healthcheck and condition: service_healthy, Compose waits until PostgreSQL is actually ready to accept connections before starting the API.

Podman

Podman is an open-source alternative to Docker. Docker and Podman are two popular containerization tools that share similar features but differ in architecture and security approach. Docker uses a client-server architecture, where the Docker daemon runs as a separate process and Docker commands are executed via the CLI. In contrast, Podman uses a daemonless architecture, meaning it runs directly as a regular user and does not require a separate daemon process. Thus, Podman can run without special privileges, limiting potential risks associated with running as superuser. See What is podman? for more information.

Podman also offers tools to manage pods, a topic outside the scope of this workshop.

Kubernetes

Kubernetes is an open-source container orchestration system that facilitates the deployment, management, and scaling of containerized applications. Using Kubernetes offers many benefits, such as fault tolerance, easier deployments, and management and scaling of containerized applications.

Bash Workshop

2025-09-06T00:00:00+00:00

Bash is a powerful command-line interpreter that allows users to interact with their operating system through text commands. As a programmer, you will often need to use the command line to perform various tasks, such as navigating the file system, managing files and directories, and executing scripts.

Setup

The original workshop was designed to use with a virtual machine (willGuimont/IFT2001-Scripting). While you can follow the instructions below to set up the virtual machine, you can also choose to follow the workshop using Docker.

Follow these steps to prepare your environment.

Install Docker
docker run -it --rm ubuntu:latest bash
In the Docker container, run:
1. apt update && apt install -y git
2. mkdir .atelier && cd .atelier && git clone https://github.com/willGuimont/IFT2001-Scripting ateliers-iftglo-2001
3. cd ateliers-iftglo-2001
4. ./helper/install.sh
5. python3 ./helper/prepare_bashrc.py && source ~/.bashrc
6. Copy the files in your home directory: cd ~/.atelier/ateliers-iftglo-2001/files && cp -r . ~/

Instructions

nano test.sh

You can then edit the file; enter

echo 'Hello world'

To exit nano, press CTRL-X, then answer y to save the changes. Run the following commands to validate that everything works:

chmod +x test.sh
./test.sh

These commands should print Hello world.

Adventurers only

If you are comfortable with the command line, we encourage you to try completing this workshop using vim as your text editor. A brief introduction to vim commands is available on MIT’s The Missing Semester. vim offers many shortcuts to edit text and code very efficiently. As a programmer, you will spend a lot of time writing code, so investing in learning vim is worthwhile for the rest of your career. There are plugins emulating vim commands for most IDEs: Vim for VS Code or IdeaVim for JetBrains products.

Please note that no assistance regarding vim will be provided during this workshop.

Solutions

Proposed solutions to the exercises in these workshops are available in the following GitHub repository: ulavalIFTGLOateliers/IFT2001-Scripting.

Introduction to Bash

It’s a day like any other at the office. You arrive early in the morning, coffee in hand and your laptop under your arm. As you enter your department, you notice that your usually calm and relaxed boss is pacing nervously down the hallway. His pale expression and trembling hands immediately catch your attention.

“Worrying — what’s going on?” you ask, concerned.

“Production has crashed,” he replies in a trembling voice. “We’re getting hundreds of customer calls, nothing works anymore…”

Your heart races as you realize the magnitude of the problem. Your company depends on a server that hosts most of its services, and it seems something is malfunctioning. Your boss looks you straight in the eye.

“Solving this problem is your priority,” he says firmly.

He hands you a sheet of paper with the login credentials to access the server. You feel both nervous and excited at the prospect of solving this critical issue. Your boss then leads you to the server room, where an old CRT screen and a keyboard await you. He explains that it’s a Linux server edition, so without a graphical interface. You will therefore have to solve the problems using only the terminal.

┌───────────────────────────── SYSTEM DIAGNOSTIC (BOOT/RESCUE) ──────────────────────────┐
│ Host: crt-prod-01                User: username               TTY: /dev/pts/0          │
│ Kernel: 5.15.x-generic           Uptime: 00:07:13             Load: 1.42 0.97 0.53     │
│ -------------------------------------------------------------------------------------- │
│ LOG SCAN: messages.txt                                                                 │
│   Errors (raw): ................. 37  (use: grep 'Error' messages.txt)                 │
│   Unique 4xx errors: ............ pending (pipe into uniq | sed ...)                   │
│                                                                                        │
│ NEXT STEPS (YOU):                                                                      │
│   [1] Locate build log directory         (Exercise 02)                                 │
│   [2] Back up critical log file          (Exercise 03)                                 │
│   [3] Fix permissions & run diagnostics  (Exercise 04)                                 │
│   [4] Corral *.out + purge temp files    (Exercises 05–07)                             │
│   [5] Triage errors with grep/uniq/sed   (Exercises 09–12)                             │
│   [6] Hunt largest files (du/find/sort)  (Exercise 13)                                 │
│   [7] Awk your way through db.tsv        (Exercise 14)                                 │
│   [8] Script + rollback automation       (Exercises 15–16)                             │
│ -------------------------------------------------------------------------------------- │
│ TIP: Build one-liners incrementally. Example pipeline scaffold:                        │
│        cat file | grep pattern | sort | head -n 5                                      │
│                                                                                        │
│ REMEMBER:                                                                              │
│   man <cmd>    --help flags    help <builtin>    set -x (debug scripts)                │
│                                                                                        │
│ STATUS LAMPS:  [CPU OK] [DISK OK] [NET OK] [SERVICE ERROR] -> Investigate app layer    │
└────────────────────────────────────────────────────────────────────────────────────────┘
(enter the command line below…)

The command line and the manual

Open a terminal with the shortcut Ctrl+Alt+T, or press the Super key (the Windows key on the keyboard) and search for the Terminal application.

As a first step, you decide to inspect the files present on the server in order to find the log files. However, you are not sure which command to use for this.

Fortunately, the command line lets you learn how each command works. The man command allows you to read the manual page corresponding to a specific command. For example, to get the documentation for the ls command, you can use the following command:

man ls

Once you have opened the manual page, you can navigate using the arrow keys to read the content. To quit the manual page, simply press the q key.

Also, some commands accept the --help argument which displays a help message describing the arguments that can be passed to the command. For example:

ls --help

By running this command, you will get a help message detailing the different options and arguments you can use with the ls command.

Do not hesitate to use the --help argument with commands you wish to explore to obtain additional information on their usage. This can help you better understand the available features and correctly use commands in your exploration of the server.

For some commands such as cd (which is a command built into the Bash shell), you should instead use

help cd

Terminal shortcuts

Auto-completion: You can use the Tab key to get auto-completion in the terminal.

Quit a command: In a terminal, the Ctrl+C shortcut, rather than copying, terminates the execution of a command. For example, the yes command indefinitely repeats the letter y in the terminal. To quit, press Ctrl+C:
yes
# Ctrl+C to quit the execution of yes
To copy and paste, the terminal uses Ctrl+Shift+C and Ctrl+Shift+V

To close a terminal, you can use Ctrl+D.

Exercise 01 – Basic commands

This exercise aims to familiarize you with a few basic commands that will be useful throughout the workshop. To do this, use the man command and the --help argument to obtain detailed information on how each command works. In the file exercice_01.txt, briefly describe the purpose of each of the following commands. This cheat sheet will be useful throughout the workshop. You can consult it with the command cat exercice_01.txt.

Open exercice_01.txt with nano with:

nano exercice_01.txt

In another terminal (Ctrl+Alt+T to open another terminal or Ctrl+Shift+T to open another terminal in a tab), use the terminal to determine the behavior of the following commands:

Commands
`nano`
`cd`
`ls`
`cat`
`mkdir`
`rm`
`rmdir`
`mv`
`pwd`
`cp`
`chmod`
`touch`

Solution

Command	Definition
`nano`	Simple text editor
`cd`	Change current directory
`ls`	List files in a directory
`cat`	Display a file’s content
`mkdir`	Create a directory
`rm`	Delete a file or directory
`rmdir`	Delete an empty directory
`mv`	Move/rename a file
`pwd`	Show the path of the current directory
`cp`	Copy a file
`chmod`	Change file permissions
`touch`	Update a file’s timestamp, or create it if it does not exist

Use the commands listed above to explore the directory tree and find the file with the .log extension.

Here are some special paths:

. represents the current directory;

.. represents the parent directory;

~ represents the user’s home directory (/home/username/);

- represents the path of the last visited directory.

You can use these special paths with several commands, notably cd.

# Navigate into the abc/def directory
cd abc/def

# Navigate to the parent directory (abc)
cd ..

# Return to the home directory
cd
# or
cd ~

# Return to the previous directory (abc)
cd -

List the files in the current directory
Move through the different directories and try to find the file with the .log extension
Copy the absolute path (from the root of the file system /) of the directory where the log files are located into the file ~/out_02.txt. Do not add a newline at the end.

Solution

Commands to run:

ls
cd ApplicationData/output/logs
ls
pwd

Expected path: /home/glo2001/ApplicationData/output/logs

Exercise 03 – `home` directory and copy

Now that you have found the log file, it’s time to make a copy of it in your home directory.

The home directory is where a user’s personal files are stored. Each user has their own directory in /home/. If your username is username, so your home directory is located at /home/username.

There is also a shortcut to refer to the home directory: ~. Thus, each of the following commands returns you to the home directory:
# Use an absolute path
cd /home/admin
# Use tilde
cd ~
# Without arguments, cd returns to the home directory
cd

Copy the .log file into the ~/log_backup directory.

Return to your home directory;
Create a new directory named log_backup in your home directory;
Copy the .log file into the backup directory, giving it the name build_backup.log.

Solution

Commands:

cd
mkdir log_backup (typo in LaTeX was mdkdir but intent is mkdir)
cp ~/ApplicationData/output/logs/build.log ~/log_backup/build_backup.log

Exercise 04 – Permissions

Now that you have backed up the log file, it’s time to run the diagnostic script provided by your boss to analyze the system. Go back to the log directory, and try to run the script diagnostic.sh using ./diagnostic.sh.

However, you encounter a permissions error. To fix this, inspect the script permissions using the ls -l command. Then, modify the permissions to make the script executable.

chmod, short for change mode, is a command used to modify access permissions for files and directories. Permissions in bash refer to the access rights granted to users and groups to read, write, and execute files and directories. These permissions control who can perform which operations on a given file or directory. You can list file and directory permissions with ls -l.
drwxr-xr-- 1 user group 4096 Sep  7 10:00 folder
-rwxr-xr-- 1 user group  123 Sep  7 10:00 file
Permissions are generally represented by one character followed by three groups of three characters each, for a total of nine characters, displayed in a specific order:

The first character indicates whether it is a file (-) or a directory (d).

The first group of three characters represents the permissions of the file’s owner.

The second group represents the permissions of the group to which the file belongs.

The third group represents the permissions for other users.

Each group of three characters consists of the following permission types:

r (read): Read the content of the file or directory.

w (write): Modify a file’s contents; for a directory, create, delete, or rename entries inside it.

x (execute): Execute a file; for a directory, traverse it and access entries within it.

To modify these permissions, you can use the chmod command. For example, to add (+) the execute permission to a file:
chmod +x script.sh
To remove the write permission from a directory:
chmod -w folder

Steps:

Inspect the file permissions;
Use chmod with the +x argument to modify permissions;
Run diagnostic.sh.

Solution

# Check permissions
ls -l
# Change permissions
chmod +x diagnostic.sh
# Run the script
./diagnostic.sh

Exercise 05 – Wildcards

The script generated about ten .out files containing the results of the system analysis. You need to move these files into a new folder named output. Instead of moving each file manually with the command mv out_01.out output/, which would be tedious, you can use the wildcard character (*), which allows you to select multiple files at once.

The * character is interpreted by the shell before the command is executed. This is called globbing.

For example:
mv *.out output/
If the current directory contains:
a.out
b.out
notes.txt
Bash expands the command to something equivalent to:
mv a.out b.out output/
The mv command itself does not interpret *.out; Bash first replaces the pattern with the matching filenames, then launches mv. By default, * does not match filenames beginning with ..

Some common glob patterns are:
*       any sequence of characters
?       exactly one character
[abc]   one character among a, b, or c
[0-9]   one digit
For example:
ls *.txt
ls file?.txt
ls image[0-9].png
Globbing is different from regular expressions. A pattern such as *.txt is a shell glob: * matches any sequence of filename characters and . is literal. In a regular expression, . matches any single character and * repeats the preceding element. grep and sed use regular expressions; find -name uses shell-style filename patterns.

Before moving the files, you can try the command cat *. This command displays the contents of matching non-hidden files in the current directory.

However, in your case, you do not want to select all files. You can specify a specific pattern by adding a prefix or suffix to the filenames. For example, to select all .sh files, you can use the command ls *.sh. This will display the list of files with the .sh extension.

Tasks:

Create a folder named output_backup in the ~/ApplicationData/output/logs directory;
Move all files ending with .out into the folder in a single command.

Solution

# Move to the correct directory
cd ~/ApplicationData/output/logs
# Create the output folder
mkdir output_backup
# Move the files into the folder
mv *.out output_backup/

Exercise 06 – Deleting files and folders

In addition to generating .out files, the script also generated temporary .tmp files and a folder named temp. These files and this folder can be deleted.

Tasks:

Delete the files with the .tmp extension;
Delete the temp folder.

Solution

# Delete .tmp files
rm *.tmp
# Delete the folder
rm -r temp

Exercise 07 – Basic scripting

To simplify the task of moving and deleting the files generated by the diagnostic.sh script, you can create a script that will automate these actions for you.

Here is an example Bash script:
#!/usr/bin/env bash
echo 'Start of script'
ls *.sh
echo 'End of script'
In this script, the line #!/usr/bin/env bash is called a shebang (she = #, bang = !). It tells the interpreter which program should be used to run the script—in this case, Bash. It would also be possible to specify another program as the interpreter. For example, to interpret the script as Python 3, we would use the following shebang: #!/usr/bin/env python3.

Using #!/usr/bin/env bash is generally preferable to #!/bin/bash, as it looks up the location of the Bash executable in the user’s environment, making it more portable across systems.

You can create a text file with the .sh extension (for example, example.sh), copy the script above into it, then make the file executable using chmod +x example.sh. Next, you can run the script using ./example.sh.

Now, create a script that performs the following operations:

Create a script named cleanup.sh in the directory ~/ApplicationData/output/logs/;
Give the script execute permissions;
Use the commands you typed in the previous exercises to create your script:
- Create a folder named output_backup;
- Move all files ending with .out into the folder in a single command;
- Delete the files with the .tmp extension;
- Delete the temp folder.
Make sure to delete the output folder you created earlier;
Run diagnostic.sh once more, and test your script.

You can use the history command to view the list of commands you have previously executed in the terminal.

Solution

#!/usr/bin/env bash

# Create the output_backup folder
mkdir output_backup
# Move the files into the folder
mv *.out output_backup/

# Delete .tmp files
rm *.tmp
# Delete the folder
rm -r temp

Advanced commands

Now that you’ve performed some cleanup operations and become familiar with the command line, it’s time to analyze the logs and outputs of the diagnostic program. To do this, you will need to combine several commands using piping and more advanced commands. Before addressing this topic, you will explore some more advanced commands that will be useful later.

Exercise 08 – Advanced commands

As in exercise 1, use the man command and the --help argument to obtain detailed information on the commands in the following table. These commands are a bit different from those seen in exercise 1; they can take a file as input, or you can pipe the output of another command to them, which will be the subject of the next section. You can create a test file (test_file.txt) to test the commands.

In the file exercice_08.txt, briefly describe the purpose of each of the following commands. This cheat sheet will be useful throughout the workshop.

Commands
`tac`
`less`
`find`
`grep`
`sort`
`uniq`
`wc`
`head`
`tail`
`du`
`curl`
`sed`
`awk`
`kill`
`sleep`

Solution

Command	Definition
`tac`	Reverse the order of lines in a file
`less`	Text pagination
`find`	File search
`grep`	Filter lines by a pattern
`sort`	Sort lines
`uniq`	Remove adjacent duplicate lines
`wc`	Count lines, words, and characters
`head`	Display the beginning of a file
`tail`	Display the end of a file
`du`	Show file sizes
`curl`	Network request (HTTP, FTP, etc.)
`sed`	Stream editor
`awk`	Interpreter for the `awk` language
`kill`	Stop a process
`sleep`	Wait for a number of seconds

Exercise 09 – Advanced commands 1

The messages.txt file in the log folder contains the error messages that cause the system outage. Unfortunately, this file also contains a lot of logs that are not useful to you. Rather than manually reading the entire file, you decide to use the Bash commands you just discovered.

Use a command to display all lines of messages.txt that contain the string Error and copy the result into the file ~/errors.txt.

Solution

grep Error messages.txt > ~/errors.txt

Exercise 10 – Advanced commands 2

After inspecting the errors that you copied into ~/errors.txt, you realize there are many duplicates. Use a Bash command to remove duplicate lines and copy the result into ~/errors_2.txt.

uniq removes repeated adjacent lines. If identical lines are separated by other lines, uniq will not detect them.

A common pattern is therefore:
sort file.txt | uniq
sort groups identical lines together, after which uniq removes the duplicates.

Solution

sort ~/errors.txt | uniq > ~/errors_2.txt
# or
sort -u ~/errors.txt > ~/errors_2.txt

Exercise 11 – Advanced commands 3

The log file ~/errors_2.txt contains HTTP errors such as:

Error 404: File not found
Error 403: Access denied
Error 500: Internal server error

For this exercise, all client errors (4xx such as 400, 403 and 404) should be reclassified as warnings while preserving the error code.

For example:

Error 404: File not found

should become:

Warning 404: File not found

With sed -E, match ^Error (4[0-9]{2}): and replace it with Warning \1:. The \1 inserts the captured error code.

The substitution has the form: s/pattern/replacement/g

where:

s means substitute;

pattern is the regular expression to match;

replacement is the text that replaces the match;

g means replace every match on a line, rather than only the first. It is optional when a pattern can match only once per line.

In the regular expression ^Error (4[0-9]{2})::

^ matches the beginning of the line, and : after the code prevents a match on a longer number such as 4000.

4[0-9]{2} matches exactly three digits starting with 4, such as 400, 403, or 404.

The parentheses capture those three digits as group 1.

In the replacement Warning \1::

\1 inserts the text captured by group 1; the literal colon follows it.

Use a Bash command to modify the messages and copy the result into ~/errors_3.txt.

Solution

sed -E 's/^Error (4[0-9]{2}):/Warning \1:/' ~/errors_2.txt > ~/errors_3.txt

Program composition

Program composition is at the heart of the Unix philosophy. Here is an excerpt from The Art of Unix Programming describing the importance of program composition (full chapter available here).

It’s hard to avoid programming overcomplicated monoliths if none of your programs can talk to each other.

Unix tradition strongly encourages writing programs that read and write simple, textual, stream-oriented, device-independent formats. Under classic Unix, as many programs as possible are written as simple filters, which take a simple text stream on input and process it into another simple text stream on output.

Despite popular mythology, this practice is favored not because Unix programmers hate graphical user interfaces. It’s because if you don’t write programs that accept and emit simple text streams, it’s much more difficult to hook the programs together.

Text streams are to Unix tools as messages are to objects in an object-oriented setting. The simplicity of the text-stream interface enforces the encapsulation of the tools. More elaborate forms of inter-process communication, such as remote procedure calls, show a tendency to involve programs with each others’ internals too much.

To make programs composable, make them independent. A program on one end of a text stream should care as little as possible about the program on the other end. It should be made easy to replace one end with a completely different implementation without disturbing the other.

— Chapter 1. Philosophy, Rule of Composition

This program composition can be achieved using different operators, which will be the subject of the next sections.

Composition

The ; operator allows you to run one command after another on the same line.

(command1 ; command2)

For example, for exercise 7, we could rewrite the program as follows:

mkdir output; mv *.out output/; rm *.tmp; rm -r temp

The && operator runs the second command only if the first one succeeded (returns an exit code equal to zero).

(command1 && command2)

# Prints "Hello World" because both commands succeed
echo 'Hello' && echo 'World'

# We print Hello because the directory exists, so cd succeeds
cd existing_directory && echo 'Hello

# We do not print Hello because the directory does not exist, so cd fails
cd non_existent_directory && echo 'Hello'

The || operator runs the second command only if the first one failed (returns a non-zero exit code).

(command1 || command2)

# Prints only Hello, because echo 'Hello' succeeds
echo 'Hello' || echo 'World'

# We do not print Hello, because cd succeeds
cd existing_file || echo 'Hello'

# We print Hello, because cd fails
cd non_existing_file || echo 'Hello'

Pipes

The | operator passes the output of one command as input to another. This operator is also called a pipe.

(command1 | command2)

# List names ending in .txt
ls | grep '\.txt$'

# Sort the lines of a file, keep only the first 5 lines
cat file.txt | sort | head -n 5

Redirection

The > operator redirects a command’s output to a file, overwriting the file.

(command > file)

ls > file.txt

For example, it is possible to download a text file with curl:

curl https://www.ulaval.ca/ > ulaval.txt

To discard a command’s output:

ls > /dev/null 2>&1

The < operator redirects a command’s input from a file.

(command < file)

wc < file.txt

The >> operator, like >, redirects a command’s output to a file, but appends to the end of the file rather than overwriting it:

(command >> file)

ls >> file.txt

The << operator is like <, but allows you to pass multiple lines.

(command <<delim [multiple lines] delim)

cat <<EOF
abc
def
hij
EOF
# We can replace EOF (end of file) with any other string
cat <<ABC
abc
def
hij
ABC

Examples

# Find the first 5 names ending in .txt in alphabetical order
ls | grep '\.txt$' | sort | head -n 5
# 1. List the names
# 2. Keep only names ending in .txt; \ makes the dot literal, and $ matches the end of the line
# 3. Sort alphabetically
# 4. Keep only the first 5 results
# Using find for regular files; -name uses a filename glob, where the dot is already literal
find . -maxdepth 1 -type f -name '*.txt' | sort | head -n 5

# Keep only lines containing the text "warning",
# replace "warning" with "error", then write the result to output.txt
cat data.txt | grep "warning" | sed 's/warning/error/g' > output.txt
# 1. Display the contents of data.txt
# 2. Filter lines to keep only those containing "warning"
# 3. Apply a regex to replace "warning" with "error"
# 4. > writes the result to the file output.txt
# Can also just use grep
grep "warning" data.txt | sed 's/warning/error/g' > output.txt

# Generate a test file
echo -e "1\t2\n2\t3\n3\t4\n" > foo.txt
# 1. Display a formatted string
# 2. Write the result to foo.txt

# Compute the sum of each column
cat foo.txt | awk '{sum += $1; sum2 += $2} END {print sum; print sum2}' \
    | xargs echo "Sum of both columns"
# 1. Display the contents of foo.txt
# 2. Awk accumulates column sums and prints them
# 3. Pass the awk result to echo
# Or omit cat
awk '{sum += $1; sum2 += $2} END {print sum; print sum2}' foo.txt \
    | xargs echo "Sum of both columns"

We recommend trying these commands one at a time to fully understand each step of the pipeline, for example:

ls
ls | grep '\.txt$'
ls | grep '\.txt$' | sort |
ls | grep '\.txt$' | sort | head -n 5

Standard input, output, and errors

Unix programs conventionally use three standard streams:

0   stdin    standard input
1   stdout   standard output
2   stderr   standard error

stdin is where a program reads its input. stdout carries normal output, while stderr carries warnings and errors.

For example:

grep "error" server.log

This reads server.log and writes matching lines to stdout. The > operator redirects stdout to a file:

grep "error" server.log > errors.txt

This is equivalent to explicitly writing 1> because 1 refers to stdout:

grep "error" server.log 1> errors.txt

Errors can be redirected separately with 2>:

grep "error" missing-file.txt 2> errors.log

Normal output would still go to the terminal, while error messages go to errors.log. You can redirect both streams independently:

command > output.txt 2> errors.txt

To discard a stream, redirect it to /dev/null:

command > /dev/null
command 2> /dev/null

To discard both stdout and stderr:

command > /dev/null 2>&1

2>&1 sends file descriptor 2 to the destination currently used by file descriptor 1.

By default, a pipeline passes only stdout from command1 to stdin of command2:

command1 | command2

Errors from command1 still appear on the terminal.

Exercise 12 – Piping and redirection

Use piping and redirection to rewrite exercises 9, 10 and 11 as a single command.

Solution

grep Error messages.txt | sort | uniq | sed -E 's/^Error (4[0-9]{2}):/Warning \1:/' > ~/out_12.txt

Exercise 13 – File sizes

Use this command which returns the list of files and their size:

find ~/Documents -type f -exec du -sb {} +

Each line contains the size in bytes and the file name separated by a Tab character. Use the output of this command to find the five largest files. Your script must return five lines in the same format as du.

Solution

find ~/Documents -type f -exec du -sb {} + | sort -rh | head -n 5 > ~/out_13.txt
# or
find ~/Documents -type f -exec du -sb {} + | sort -h | tac | head -n 5 > ~/out_13.txt
# or
find ~/Documents -type f -exec du -sb {} + | sort -h | tail -n 5 | tac > ~/out_13.txt

Exercise 14 – Data analysis

The file ~/ApplicationData/db.tsv contains data in TSV format (TAB separated value). Format:

id	date	name	type	size
123	2023-12-25	foo	error_log	23

Use this file to find the 10 rows with the smallest size (size column), keeping only the name column. You must keep the header of the retained column, i.e. the first line of ~/out_14.txt should be name.

To accomplish this task, you can use awk, a programming language specialized for text manipulation. For example, to extract the 1st and 3rd columns, separated by a Tab:
awk '{print $1 "\t" $3}' file.txt

Solution

awk '{print $5 " " $3}' db.tsv | sort -h | head -n 11 | awk '{print $2}' > ~/out_14.txt
# or
awk '{print $5 " " $3}' db.tsv | sort -h | head -n 11 | sed 's/^[^ ]* //' > ~/out_14.txt

Scripting

Now that you are more comfortable with Bash, it’s time to create more advanced scripts.

The following examples will help you understand how to create scripts that can take arguments, use variables, and implement control structures such as conditionals and loops.

#!/usr/bin/env bash
# The script arguments are available with $n (where n is a natural number)
echo "The script name is: $0"
echo "The first argument is: $1"
echo "The second argument is: $2"
echo "All arguments: $@"
# {@:2:3} means take a slice starting at 2 (1-based) of length 3
echo "Arguments from 2 to 4: ${@:2:3}"

# Variables; note there are no spaces around the = sign
name="John"
age=25
# $age substitutes the variable’s value inside a string between double quotes
echo "My name is $name and I am $age years old."
# Environment variables
echo "The value of HOME is: $HOME"

# Substitution
current_directory=$(pwd)
# Substitutions work only for double quotes "
echo "The current directory is: $current_directory using double quotes"
# Not for single quotes '
echo 'The current directory is: $current_directory using single quotes'
# It is also possible to call a command directly inside a string
path="$(pwd)"/my/path
echo "Path: $path"

# Conditionals
if [ "$age" -ge 18 ]; then
  echo "You are an adult."
else
  echo "You are a minor."
fi

# Loops
for i in 1 2 3 4 5
do
    echo $i
done

fruits=("apple" "banana" "orange")
for fruit in "${fruits[@]}"
do
    echo "I like $fruit"
done

counter=1
while [ $counter -le 5 ]
do
    echo $counter
    ((counter++))
done

# Function
greet() {
  echo "Hello, $1!"
}

greet "Alice"

Quoting variables

When a variable is expanded without quotes, Bash may split its value into multiple arguments and expand wildcard characters in it.

Consider:

file="my report.txt"
rm $file

Bash expands the command approximately as:

rm my report.txt

So rm receives two filenames:

my
report.txt

This is usually not what we want. Quote the expansion when the value should remain a single argument:

rm "$file"

Now rm receives exactly one filename:

my report.txt

The same rule applies to most variable expansions:

cd "$directory"
cp "$source" "$destination"
kill "$server_pid"
echo "$message"

As a general rule, write "$variable" unless you specifically want Bash to split the value into words or expand wildcard characters in it.

Double quotes still allow variable and command substitution:

name="Alice"
echo "Hello $name"

Single quotes do not:

echo 'Hello $name'

This prints:

Hello $name

Exercise 15 – Test script

After all that cleaning and analysis, you decide it is wiser to just roll back to a previous version of the server until the problem is fixed. As you are not sure which version is functional, you decide to write a script that will test the server and roll back to the previous version if the test fails.

The first step is to write a script that tests whether the server is functional. Save this script in the file ~/test.sh, and give it execute permissions.

#!/usr/bin/env bash

cd ~/server

# Start the server in the background
python3 -m uvicorn main:app &
# Save the process ID (pid) of the server with $!
# $! returns the pid of the last background process started
server_pid=$!

# The `stop_server` function stops the server process
stop_server() {
  kill "$server_pid"
}

# Register the `stop_server` function to be called when this script exits
trap stop_server EXIT

# Wait for the server to be ready
sleep 1

# TODO make an HTTP request to localhost:8000

# TODO If the result is an error, exit with code 1 using `exit 1`
# $? contains the return code of the last command

Solution

#!/usr/bin/env bash

cd ~/server

# Start the server in the background
python3 -m uvicorn main:app &
# Save the process ID (pid) of the server with $!
server_pid=$!

# The `stop_server` function stops the server process
stop_server() {
  kill "$server_pid"
}

# Register the `stop_server` function to be called when this script exits
trap stop_server EXIT

# Wait for the server to be ready
sleep 1

# TODO make an HTTP request to localhost:8080
curl localhost:8000 > /dev/null 2> /dev/null

# TODO If the result is an error, exit with code 1 using `exit 1`
# $? contains the return code of the last command
if [ $? -eq 0 ]; then
  echo "Server is up"
else
  echo "Server is down"
  exit 1
fi
# Or cleaner
if curl localhost:8000 > /dev/null; then
    echo "Server is up"
else
    echo "Server is down"
    exit 1
fi

Exercise 16 – Version rollback script

Now that you have a test script, you can write a script that will roll back to the previous version of the server if the test fails. Use the given revert_last_commit function to roll back to the previous version of the server.

Complete the following script to roll back to a previous version of the server until the test script passes. Save this script in the file ~/revert.sh, and give it execute permissions.

The repository contains a known working version in its history, so repeatedly moving to the previous commit will eventually succeed.

git reset --hard discards uncommitted changes. It is safe here because the workshop repository is disposable. Be careful if you use it in your own projects!

#!/usr/bin/env bash

cd ~/server

revert_last_commit() {
  git reset HEAD~1 --hard
}

exit_status=1
# TODO write a while loop while $exit_status is not equal to 0
# At each iteration, run the test.sh script
# If the script exits with code 0, stop the script with exit 0
# Otherwise, call the `revert_last_commit` function

Solution

#!/usr/bin/env bash

cd ~/server

revert_last_commit() {
  git reset HEAD~1 --hard
}

exit_status=1
while [ "$exit_status" -ne 0 ]; do
  # Run the test script
  ~/test.sh > /dev/null 2>&1
  # Save the test script status
  exit_status=$?

  if [ "$exit_status" -ne 0 ]; then
    echo "The script returned a non-zero exit status ($exit_status). Reverting commit and retrying..."
    revert_last_commit
  else
    echo "The script returned 0 (success)."
    exit 0
  fi

  # Add a delay between retries (optional)
  sleep 1
done

Extras

`.bashrc` file

Below are optional enhancements you can add to your ~/.bashrc (or ~/.bash_profile depending on your shell startup rules) to make day‑to‑day terminal work more pleasant.

Prompt customization

Simple minimal prompt (user@host:cwd$):

PS1='\u@\h:\w$ '

Prompt with colors, Git branch and exit code indicator (status inlined, no helper function):

# Compute git branch (if any)
parse_git_branch() {
  git rev-parse --is-inside-work-tree > /dev/null 2>&1 || return
  local br
  br=$(git symbolic-ref --short HEAD 2>/dev/null || git rev-parse --short HEAD 2>/dev/null)
  [ -n "$br" ] && printf ' (%s)' "$br"
}

prompt_command() {
  local exit=$?  # exit status of previous command
  local status
  if [ $exit -eq 0 ]; then
    status='\[\e[32m\]✔\[\e[0m\]'
  else
    status="\[\e[31m\]✘ $exit\[\e[0m\]"
  fi
  local git_segment=""
  if git rev-parse --is-inside-work-tree > /dev/null 2>&1; then
    git_segment=$(parse_git_branch)
  fi
  PS1="\[\e[36m\]\u@\h\[\e[0m\]:\[\e[33m\]\w\[\e[0m\]${git_segment} ${status}\n$ "
}
PROMPT_COMMAND=prompt_command

Retro prompt:

workshop_prompt() {
  local code=$?
  local green="\[\e[32m\]" red="\[\e[31m\]" cyan="\[\e[36m\]" yellow="\[\e[33m\]" reset="\[\e[0m\]"
  local status
  if [ $code -eq 0 ]; then
    status="${green}OK${reset}"
  else
    status="${red}ERR:${code}${reset}"
  fi
  local branch=""
  if git rev-parse --is-inside-work-tree > /dev/null 2>&1; then
    b=$(git symbolic-ref --short HEAD 2>/dev/null || git rev-parse --short HEAD 2>/dev/null)
    branch=" ${yellow}${b}${reset}"
  fi
  # Add user@host and current directory like the earlier prompt example
  # Format: user@host:cwd [diag:STATUS]{ branch}
  PS1="${cyan}\u@\h${reset}:${yellow}\w${reset} ${cyan}[${status}]${reset}${branch}\n$ "
}
PROMPT_COMMAND=workshop_prompt

Safety & quality of life options

# Safer rm / mv / cp
alias rm='rm -i'
alias mv='mv -i'
alias cp='cp -i'

# Human readable sizes for common tools
alias l='ls -lh'
alias la='ls -lah'
alias lt='ls -lht'

# Grep with color
alias grep='grep --color=auto'

# Shortcuts to common folders
alias docs='cd ~/Documents'
alias dls='cd ~/Downloads'
alias desk='cd ~/Desktop'

# Some fun aliases
alias please='sudo'
alias emacs='vim'

Enable some helpful shell options:

# Append to history (do not overwrite) and share across sessions
shopt -s histappend
# Re-edit a failed history substitution rather than error
shopt -s histreedit
# Correct minor directory typos with cd
shopt -s cdspell 2>/dev/null || true

Functions

# Extract various archive formats with one command
extract() {
  [ -f "$1" ] || { echo "File not found: $1" >&2; return 1; }
  case "$1" in
    *.tar.bz2) tar xjf "$1" ;;
    *.tar.gz)  tar xzf "$1" ;;
    *.tar.xz)  tar xJf "$1" ;;
    *.tar)     tar xf  "$1" ;;
    *.tbz2)    tar xjf "$1" ;;
    *.tgz)     tar xzf "$1" ;;
    *.zip)     unzip   "$1" ;;
    *.rar)     unrar x "$1" ;;
    *.7z)      7z x    "$1" ;;
    *) echo "Don't know how to extract '$1'" >&2; return 2 ;;
  esac
}

# Quickly serve current directory over HTTP (Python 3)
serve() {
  local port=${1:-8000}
  echo "Serving on http://localhost:${port} (Ctrl+C to stop)"
  python3 -m http.server "$port"
}

`PATH`

The PATH environment variable contains a list of directories where the shell looks for executable files when you type a command. When you type a command, the shell searches through each directory in the PATH variable in order until it finds an executable file that matches the command name. The first matching executable is executed.

The value of PATH is a colon-separated list of directories. Adding directories to your PATH allows you to run executables located in those directories without specifying their full path. For example, if you have a script located in ~/.bin, you can add this directory to your PATH variable to run the script from anywhere.

export PATH="$PATH:~/.bin"

Alias git

As you will likely use git a lot, here are some useful aliases to add to your ~/.bashrc or ~/.gitconfig file. Aliases allow you to create shortcuts for long commands. You can add these aliases in your ~/.gitconfig file under the [alias] section. Here’s an example of useful git aliases from here:

[alias]
	lg1 = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all
	lg2 = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n''          %C(white)%s%C(reset) %C(dim white)- %an%C(reset)' --all
	lg = !"git lg1"
  adog = log --all --decorate --oneline --graph
	st = status
	co = commit
	com = commit -m
	coam = commit --amend
	a = add
	aa = add .
	p = push
	pu = push -u origin HEAD
	cb = checkout -b
	c = checkout
	m = merge
	f = fetch
	g = pull
	wip = commit -a -m "wip"
	wap = commit -a -m
	todo = !"git commit -a -m \"todo\" && git p"
	obs = !"git commit -a -m \"obsidian\" && git p"
	refs = !"git pull && git commit -a -m \"updated references\" && git p"
	figs = !"git pull && git commit -a -m \"updated figures\" && git p"
# In word diff, . matches each non-newline character
	wdiff = diff --word-diff-regex=.
[pull]
    ff = only

Element of Errors Handling

2025-07-25T00:00:00+00:00

Errors are everywhere. Any computation, IO operation, database access, or API call – any of them can fail. Despite this, most programming languages either struggle to make error handling correct or make it painful. It’s almost always easy to write the happy path. The moment something goes wrong, though, most languages make the not-so-happy path either verbose, implicit, or dangerously ignorable.

Handling errors well should be a first-class concern of most programming languages. It feels as if errors are just an afterthought in mainstream languages, added inelegantly out of necessity.

This blog post stems from some error-handling experimentation I did back in 2021. Then, at the end of my undergraduate studies in software engineering at Université Laval, we were assigned a final project in collaboration with an industry partner. They gave us carte blanche to choose the technology. Looking to try less mainstream languages and explore new paradigms, we decided to explore and compare several less conventional stacks – paying particular attention to how each one approached error handling, since our project required high reliability and robustness.

`errno` of Our Ways (C)

Before looking at more modern approaches to error handling, it is worth recalling the baseline most of them react against: C. C has no dedicated error mechanism at all. Functions signal failure through their return value – a NULL pointer, a non-zero integer, or some other sentinel value – and stash the reason in a global variable, errno. You are expected to check the return value, then read errno to find out what actually went wrong.

#include <stdio.h>
#include <errno.h>
#include <string.h>

int main(void) {
    FILE *f = fopen("nonexistent.txt", "r");
    if (f == NULL) {
        // errno was set by fopen; translate it to a message
        fprintf(stderr, "Error: %s\n", strerror(errno));
        // will print the string followed by the string representation of errno
        perror("Error opening file");
        return 1;
    }

    fclose(f);
    return 0;
}

While simple and practical, this model presents some flaws. As C does not support multiple return values – i.e., tuples – without much boilerplate (defining a struct with the return value and the error, a tagged union, or setting output variables via pointers), we end up using a value in-band of the return type: -1 is both a valid integer and might indicate an error. And errno is global mutable state, which means it’s only meaningfully valid immediately after the call, is clobbered by the next failing function, and is a thread-safety hazard (hence errno being a per-thread macro in modern C, since C11). Every guarantee is shifted onto the discipline of the programmer; the language does not provide much tooling to handle errors. With this model, the programmer needs to fix it by convention, for example, returning the value via assignment to a pointer, and keeping the function return value to indicate the error:

#include <errno.h>
#include <stdio.h>
#include <string.h>

// Return value signals success/failure; result is written through `out`.
int divide(int x, int y, int *out) {
    if (y == 0) {
        return EDOM;  // non-zero: error (domain error)
    }
    *out = x / y;
    return 0;         // zero: success
}

int main(void) {
    int result;

    int err = divide(10, 0, &result);
    if (err != 0) {
        fprintf(stderr, "Error: %s\n", strerror(err));
        return 1;
    }

    printf("Result: %d\n", result);
    return 0;
}

`Try`ing to `Catch` Lightning in a Bottle Exceptions (Java and Friends)

The most well-known model is the try/catch mechanism available in most mainstream programming languages. You throw an error and hope someone, somewhere, catches it up the stack. Otherwise, your program crashes unceremoniously.

It’s an easy method for the error-generating code: throw the exception and forget about it, but it is far from simple. This is similar to the distinction between simple and easy made by Rich Hickey in his talk “Simple Made Easy”. Exceptions are complecting by nature; they intertwine normal control flow with error handling. The control flow is no longer linear and predictable; you climb back up the stack looking for a handler.

They let you skip instructions, bubble errors up several layers, and bypass normal control flow. In a way, they are sugar-coated gotos that jump through stack frames.

Yes, try/catch/finally blocks and RAII (in C++/Java with try-with-resources) can clean things up nicely (although I prefer using defer or err_defer, which we will discuss later), but you’re still left with a system where it’s not obvious what code might throw and who handles the exception.

Java attempted to solve the uncertainty around which operations might throw exceptions through checked exceptions, but that just shifted the problem. You now have to annotate everything, tracing all possible failure paths and punting the problem upstream. Most Java developers end up defaulting to unchecked exceptions anyway, sacrificing safety for their sanity. Even Robert C. Martin said in Clean Code:

Checked exceptions can sometimes be useful if you are writing a critical library: You must catch them. But in general application development, the dependency costs outweigh the benefits.

– Robert C. Martin. Clean Code. 2008.

Despite their limitations, exceptions are still very much useful for their convenience and ease of use in simple cases. That said, while it can be convenient to let domain exceptions bubble up – for instance, in a REST API handler where you want a 404 Not Found if the entity is not found in the repository deep in the domain – you’re still playing with possibly impossible-to-predict, and more importantly difficult-to-debug, control flow. This is especially true in large codebases with many layers of abstraction, where an exception thrown deep in the stack can be caught and handled far away from its origin, making it hard to trace the error’s source. While you can try to limit this with coding standards and best practices, it remains challenging and cumbersome if the language does not provide good alternatives.

What Java’s `throws` Wanted to Be (Swift)

Swift 6.0+ offers a variation on the exception model, addressing some of the limitations and drawbacks of traditional exception handling by requiring explicit try annotations, ensuring that potential failure points are visible at the call site. Errors are values conforming to the Error protocol (not a class hierarchy rooted in Throwable), functions advertise fallibility with throws in their signature, and every call site must acknowledge it with try, making throwing operations syntactically visible rather than invisible like Java’s unchecked exceptions.

enum DivisionError: Error {
    case divisionByZero
}

func divide(_ x: Int, by y: Int) throws(DivisionError) -> Int {
    guard y != 0 else { throw DivisionError.divisionByZero }
    return x / y
}

// Must acknowledge the throw with `try`, inside do/catch
do {
    let result = try divide(10, by: 0)
    print("Result: \(result)")
} catch DivisionError.divisionByZero {   // exhaustive: the type is known
    print("Cannot divide by zero")
}

let maybe  = try? divide(10, by: 0)  // nil — collapses the throw into an Optional
let forced = try! divide(10, by: 2)  // 5  — asserts it won't throw; crashes if it does

While similar to Java’s checked exceptions, Swift’s model sidesteps the problems of Java:

It’s opt-in, not mandatory. Plain throws still means “throws anything” — formally throws(any Error). Java forces you to either declare every checked exception in your signatures or wrap them; there’s no escape hatch, so real codebases need to sprinkle throws Exception or convert everything to unchecked RuntimeException. Swift lets you reach for a precise type only where it pays off (a critical domain error) and stay untyped everywhere else.
Call-site ergonomics for choosing your safety level. The try / try? / try! family lets each call decide per-use whether to propagate, downgrade the throw into an Optional, or assert-and-crash.

`C++` and RAII

C++ does have one particularly elegant answer to exceptions: Resource Acquisition Is Initialization (RAII). Instead of explicitly cleaning up resources in every possible failure path, you bind their lifetime to an object: the constructor acquires the resource, and the destructor releases it. When an exception unwinds the stack, destructors for fully constructed local objects are called automatically in reverse order, so files are closed, locks released, and memory freed without finally blocks. Standard types such as std::vector, std::unique_ptr, and std::lock_guard make this the default style of modern C++. RAII does not make exception control flow any less implicit, but it makes that implicit flow considerably safer by ensuring that abandoning a scope does not also abandon its resources—provided, crucially, that destructors themselves do not throw.

`Go`ing Somewhere with Errors (Go)

Go brought back the C-style return code (i.e., non-zero return for errors), modernized as error values returned by the function, now with nil as the successful return value (absence of error). You call a function, and it returns both a result and an error. By convention, the error is the last return value.

import (
    "errors"
    "fmt"
)

// formatNaturalNumber validates the input is non-negative and returns it as a string.
func formatNaturalNumber(input int) (string, error) {
    if input < 0 {
        return "", errors.New("input is not a natural number: value is negative")
    }

    return fmt.Sprintf("Natural Number: %d", input), nil
}

func main() {
    input := 42

    result, err := formatNaturalNumber(input)
    if err != nil {
        // Handle error and exit early
        fmt.Printf("Error: %v\n", err)
        return
    }

    // Continue with the success path
    fmt.Println(result)
}

This makes error handling explicit, which is a good thing: you see where errors can occur and have to deal with them directly. You can follow the code, and you should be able to know exactly what happens when an error is returned. You can handle the error here and there, or return it to the function’s caller.

But this explicitness comes at the cost of verbosity and boilerplate. You will see if err != nil peppered everywhere. Also, Go gives you no tools to help with error handling. You’re mostly on your own to handle errors consistently. Go does not provide any syntactic sugar for error handling, i.e., no try/catch, no pattern matching, no monadic operators. Just if err != nil over and over.

You end up either duplicating error-propagation boilerplate or hiding the verbosity behind a generic helper that turns a non-nil error into a panic (unwound by a recover at the boundary; more on that mechanism below):

func try[T any](v T, err error) T {
    if err != nil {
        panic(err)
    }
    return v
}

At which point you’ve reinvented a monad poorly: you’ve recovered the ?-style short-circuiting from Rust, but with none of the type-level guarantees – the control flow now rides on panic/recover, the compiler no longer sees the failure path, and one stray panic outside a recovering frame takes down the program. The thing Go removed on purpose, smuggled back in through the back door.

To its credit, Go includes one elegant feature for cleanup after an error might have occurred: defer. It allows you to schedule resource cleanup (like closing files or releasing locks) regardless of how the function exits, which pairs well with manual error handling:

package main

import (
	"fmt"
	"os"
)

func main() {
	if err := process(); err != nil {
		fmt.Fprintln(os.Stderr, "Error:", err)
		os.Exit(1)
	}
}

func process() error {
	f, err := os.Open("file.txt")
	if err != nil {
		return err
	}
	defer func() {
		fmt.Println("Closing file")
		f.Close() // Yes, this could also return an error and would need to be handled correctly
	}()

	result, err := doSomething()
	if err != nil {
		// f will still be closed! ("Closing file" prints even on this early return)
		return err
	}

	fmt.Println("Result:", result)
	return nil
}

func doSomething() (string, error) {
	return "done", nil
}

Go also has a second, exception-like channel it would rather you didn’t reach for: panic and recover. A panic unwinds the stack like an exception, and a deferred recover can catch it; it is used almost exclusively for truly unrecoverable bugs or at goroutine boundaries, not ordinary error handling.

package main

import "fmt"

func main() {
	fmt.Println("Result:", safeDivide(10, 0))
	// The panic is caught and recovered, so the program continues running
	fmt.Println("Main keeps running")
}

func safeDivide(a, b int) (result int) {
	defer func() {
		if r := recover(); r != nil {
			// "Catches" the panic and recovers, returning 0 as the result
			fmt.Println("Recovered:", r)
			result = 0
		}
	}()
	return compute(a, b)
}

func compute(a, b int) int {
	return a / b // panics here
}

More idiomatically, Go’s standard library leans on sentinel errors plus wrapping. Wrapping an error with %w preserves it in a chain; errors.Is and errors.As then walk that chain to match a sentinel or extract a typed error. This recovers some of the structure that a bare if err != nil discards.

package main

import (
	"errors"
	"fmt"
)

var ErrDivideByZero = errors.New("divide by zero")

// Custom type carries the operands AND wraps the sentinel
type DivideError struct {
	A, B int
}

func (e *DivideError) Error() string {
	return fmt.Sprintf("cannot divide %d by %d", e.A, e.B)
}

// Unwrap lets errors.Is reach ErrDivideByZero underneath
func (e *DivideError) Unwrap() error { return ErrDivideByZero }

func divide(a, b int) (int, error) {
	if b == 0 {
		return 0, fmt.Errorf("divide failed: %w", &DivideError{A: a, B: b})
	}
	return a / b, nil
}

func main() {
	_, err := divide(10, 0)
	fmt.Println("Error:", err)

	// errors.Is: match the category (walks through DivideError's Unwrap)
	if errors.Is(err, ErrDivideByZero) {
		fmt.Println("Category: divide by zero")
	}

	// errors.As: extract the data
	var de *DivideError
	if errors.As(err, &de) {
		fmt.Printf("Operands: a=%d, b=%d\n", de.A, de.B)
	}
}

Zig

Zig handles errors a bit differently. Instead of adding an explicit error return value, Zig uses error union types. By adding ! before a type, you indicate that the function can return either a value of that type or an error, e.g., fn doSomething() !i32. Thus, it takes the union of the error set and the normal return type. You can optionally narrow down the error set to specific errors by prefixing the error type, e.g., fn doSomethingElse() ErrorType!ReturnType.

In addition, Zig has built-in syntax for propagating errors with try and catch. When you call a function that can return an error, you can use try to automatically propagate the error if it occurs, or get the value if it succeeds. With catch, you can provide a default value or handle the error in place by passing the error to a lambda.

const std = @import("std");

const DivisionError = error{
    DivisionByZero,
};

fn divide(x: i32, y: i32) !i32 {
    if (y == 0) return DivisionError.DivisionByZero;
    return @divTrunc(x, y);
}

// performCalculation uses 'try' to propagate errors to its caller
fn performCalculation(a: i32, b: i32) !i32 {
    // If divide returns an error, performCalculation exits here and returns the error
    const val = try divide(a, b);

    // This line only executes if divide was successful
    return val + 10;
}

pub fn main() !void {
    const result = performCalculation(10, 0) catch |err| {
        std.debug.print("Flow interrupted by error: {}\n", .{err});
        return;
    };

    std.debug.print("Final Result: {}\n", .{result});
}

This minimizes boilerplate while keeping error handling explicit. I quite like this approach, as it makes error propagation concise without losing clarity.

Zig also has defer for cleanup, similar to Go, but it adds errdefer. errdefer is used when you want to clean up resources only if an error occurs. For example, if you allocate a struct and an error happens later, you can use errdefer to free that struct only in the error case, and return the created struct on success.

const std = @import("std");

const ProcessError = error{
    StepTwoFailed,
};

fn complexOperation() !void {
    std.debug.print("Step 1: Resource allocated.\n", .{});

    // errdefer will ONLY run if this function returns an error
    errdefer {
        std.debug.print("Cleanup: Rolling back Step 1 due to failure.\n", .{});
    }

    const failure_condition = true;
    if (failure_condition) {
        std.debug.print("Step 2: Encountered an issue.\n", .{});
        return ProcessError.StepTwoFailed;
    }

    std.debug.print("Step 3: Success! errdefer will not run.\n", .{});
}

pub fn main() !void {
    complexOperation() catch |err| {
        std.debug.print("Final result: {}\n", .{err});
    };
}

Odin

I recently started experimenting with Odin, which has some interesting ideas around error handling. Instead of considering errors as exceptions or special types, Odin treats them as regular return values. As is the case for Go, Odin conventionally returns an error as the last return value of a function. Unlike Zig, which uses error unions that require declaring error types using error{}, Odin, by convention, simply treats non-zero return values as errors. This is paired with Odin’s commitment to make zero values useful defaults, so a function returning zero for an error indicates success.

package main

import "core:fmt"

Division_Error :: enum {
    None, // This is the zero value, indicating no error. Variables of this type default to None (0).
    Division_By_Zero,
    Negative_Input,
}

// Function returns a result and an error enum
divide_positive :: proc(x, y: int) -> (int, Division_Error) {
    if y == 0 do return 0, .Division_By_Zero
    if y < 0 || x < 0 do return 0, .Negative_Input

    return x / y, .None
}

main :: proc() {
    x, y := 10, 0

    res, err := divide_positive(x, y)
    
    if err != .None {
        fmt.printf("Error encountered: %v\n", err)
        return
    }

    fmt.printf("Result: %d\n", res)
}

But Odin goes further with built-in operators to streamline error handling. Assuming the last return value is the error, and that any non-zero value indicates an error, Odin provides or_else, or_return, or_continue, and or_break operators to handle errors concisely:

or_else allows you to provide a default value if an error occurs.
or_return will return from the current function if an error occurs.
or_continue and or_break can be used in loops to skip iterations or exit loops on errors.

package main

import "core:fmt"

Division_Error :: enum {
    None,
    Division_By_Zero,
    Negative_Input,
}

divide_positive :: proc(x, y: int) -> (int, Division_Error) {
    if y == 0 do return 0, .Division_By_Zero
    if y < 0 || x < 0 do return 0, .Negative_Input
    return x / y, .None
}

wrapper_proc :: proc(a, b: int) -> (val: int, error_out: Division_Error) {
    // Because parameters are named, or_return knows to put 
    // the error into 'error_out' and return.
    // Named return values, as everything in Odin, are zero-initialized.
    res := divide_positive(a, b) or_return 
    return res + 100, .None
}

main :: proc() {
    // 1. Example using or_return (via wrapper)
    val, err := wrapper_proc(10, 0)
    if err != .None {
        fmt.printf("wrapper_proc failed: %v\n", err)
    } else {
        fmt.printf("wrapper_proc result: %d\n", val)
    }

    // 2. Example using or_else
    // or_else provides a fallback value if the second return is not .None/false
    final_res := divide_positive(20, -5) or_else 999
    fmt.printf("divide_positive with or_else fallback: %d\n", final_res)
}

Odin’s approach is reminiscent of Go’s explicit error handling but adds syntactic sugar to reduce boilerplate. From these errors-as-values methods, this is probably my favorite. It builds on Go’s explicit error handling while providing operators like or_return to streamline common patterns. It does not require separate error construction like Zig, making it conceptually simpler. Overall, I find Odin’s solution to error handling to be particularly elegant, while staying explicit. It looks like a simpler solution, albeit not necessarily an easy one.

Playing Tag with Errors (Rust)

Rust’s tagged unions Result<T, E> and Option<T> types offer a different approach. Errors are in the type system. The compiler forces you to handle them – or explicitly ignore them (e.g., with unwrap, expect, etc.). You can use Rust’s pattern matching to destructure and handle errors explicitly.

Rust also provides the ? operator for concise error propagation:

#[derive(Debug)]
enum MyError { InvalidInput }

fn divide(x: i32, y: i32) -> Result<i32, MyError> {
    if y == 0 { return Err(MyError::InvalidInput); }
    Ok(x / y)
}

fn calculate() -> Result<i32, MyError> {
    // If divide returns Err, calculate returns Err immediately
    let result = divide(10, 0)?; 
    
    Ok(result + 100)
}

fn main() {
    // Pattern match on the Result
    match calculate() {
        Ok(val) => println!("Result: {}", val),
        Err(e)  => println!("Error: {:?}", e),
    }
}

The ? operator propagates errors up and makes code shorter, but it can also obscure control flow. The whole flow of the function can be interrupted by a single ? character. This single symbol rewires control flow and introduces implicit short-circuiting, which can obscure the data path. At least, the ? operator is limited to functions returning Result or Option, so its use is explicit in the function signature.

This is a limited form of monadic error handling. This is arguably one of Rust’s strengths; it makes functional programming ideas more mainstream, e.g., algebraic data types, pattern matching, higher-order functions, and monadic error handling.

Of course, Rust doesn’t force you to propagate or handle errors safely – you can always opt out:

let val = foo().unwrap(); // panics if Err
let val = foo().expect("better crash message"); // same, but with context

It is worth distinguishing between Result<T, E> and Option<T>. Result<T, E> models a computation that failed and can say why, Option<T> models mere absence, a value that may legitimately not be there, with no error to report. Conflating them is a common design smell. A “Key not found in map” is usually an Option, as absence is expected and unremarkable, whereas “could not read the config file” is a Result; you want the reason. This choice encodes intent directly into the type system, in a way that using nullable does not. Rust lets you convert between them (Option::ok_or, Result::ok) precisely because the boundary is a judgment call that shifts with context; in some cases, absence is error or error is absence.

Riding the Happy Rails (F# / Elm)

The ? operator from Rust is really sugar for a pattern that some languages make the centerpiece: railway-oriented programming (a term coined by Scott Wlaschin for F#). Picture two parallel tracks, success and failure. Each step is a function that takes a success value and returns a Result; bind/andThen chains them so that the first failure switches you onto the error track, where you stay for the rest of the journey.

let parseInt (s: string) =
    match System.Int32.TryParse s with
    | true, n  -> Ok n
    | false, _ -> Error (sprintf "'%s' is not a number" s)

let divide divisor x =
    if divisor = 0 then Error "divide by zero"
    else Ok (x / divisor)

let checkEven x =
    if x % 2 = 0 then Ok x
    else Error (sprintf "%d is not even" x)

// Parse a string, divide by 2, then require the result to be even.
let compute input =
    input
    |> parseInt
    |> Result.bind (divide 2)
    |> Result.bind checkEven

[<EntryPoint>]
let main _ =
    let inputs =
        [ "16"     // 16 / 2 = 8, even   -> Ok
          "12"     // 12 / 2 = 6, even   -> Ok
          "10"     // 10 / 2 = 5, odd    -> fails at checkEven
          "abc" ]  // not a number       -> fails at parseInt

    for input in inputs do
        match compute input with
        | Ok n    -> printfn "ok:    %d" n
        | Error e -> printfn "error: %s" e
    0

Elm spells the same idea Result.andThen. F#’s bind is inspired by Haskell monads, and the bind operator >>=, which will be the subject of the next section.

A Monadic Digression

Before writing this document, I assumed that Rust’s ? operator was limited to built-in types like Result<T, E> and Option<T>, effectively restricting its use to these specific monads. While this holds on stable Rust, the nightly-only try_trait_v2 feature extends the language’s capabilities by allowing custom types to participate in ?-based control flow through the implementation of the Try and FromResidual traits.

#![feature(try_trait_v2)]

use std::convert::Infallible;
use std::ops::{ControlFlow, FromResidual, Try};

#[derive(Debug)]
enum MyResult<T, E> {
    Ok(T),
    Err(E),
}

impl<T, E> Try for MyResult<T, E> {
    type Output = T;
    type Residual = MyResult<Infallible, E>;

    fn from_output(output: T) -> Self {
        MyResult::Ok(output)
    }

    fn branch(self) -> ControlFlow<Self::Residual, Self::Output> {
        match self {
            MyResult::Ok(val) => {
                println!("Encountered Ok with value.");
                ControlFlow::Continue(val)
            },
            MyResult::Err(e) => {
                println!("Encountered Err with value.");
                ControlFlow::Break(MyResult::Err(e))
            },
        }
    }
}

impl<T, E> FromResidual<MyResult<Infallible, E>> for MyResult<T, E> {
    fn from_residual(residual: MyResult<Infallible, E>) -> Self {
        match residual {
            MyResult::Err(e) => {
                println!("Converting residual Err to MyResult.");
                MyResult::Err(e)
            },
            _ => unreachable!(),
        }
    }
}

fn do_something() -> MyResult<i32, &'static str> {
    let x = MyResult::Ok(10)?;
    let y: i32 = MyResult::Err("oops")?;
    MyResult::Ok(x + y)
}

fn main() {
    println!("Output: {:?}", do_something());
}

Outputs:

Encountered Ok with value.
Encountered Err with value.
Converting residual Err to MyResult.
Output: Err("oops")

In this implementation:

from_output is analogous to Haskell’s return (or pure in the applicative context), lifting a value into the Try type.
branch corresponds to a poor man’s monadic bind (>>=), determining whether to propagate the value or short-circuit.
from_residual reconstructs the enclosing Try type from the residual when ? short-circuits. Additional FromResidual implementations can also explicitly permit propagation between compatible residual types.

Despite this flexibility, Rust’s ? operator is fundamentally an abstraction over short-circuiting control flow rather than general monadic sequencing. Result uses that mechanism for errors, Option for absence, and ControlFlow for explicit early termination. In Haskell, by contrast, >>= describes general sequencing of computations and is not inherently associated with early exit.

Despite how tempting it might look to generalize ? to arbitrary monads, I would caution against it. Unlike Haskell, where monads are a first-class abstraction for sequencing computations with various effects, using ? with arbitrary monads could lead to confusion.

A monad is just a monoid in the category of endofunctors, what’s the problem? (Haskell)

Where Rust brings functional error handling into a systems programming language – with Result<T, E>, Option<T>, and ? – Haskell has far more powerful abstractions.

Monads give you composable effects, including errors. You can throw, catch, pattern match, and compose computations in Either, Maybe, or more complex stacks using monad transformers.

As in Rust, Either Error Value encodes a computation that can fail. But in Haskell, you can manipulate it using the full suite of monadic tools.

The example below shows how ExceptT, a monad transformer, extends any base monad (typically IO) with error-handling capabilities. It generalizes the Either e a pattern, allowing you to compose error propagation with other effects (like IO, State, etc.).

import Control.Monad.Except

-- Define error type and a type alias for our error-handling monad
data AppError
  = DivideByZero
  | UnexpectedError String
  deriving (Show)

type AppM = ExceptT AppError IO

-- A function that fails safely
safeDivide :: Int -> Int -> AppM Int
safeDivide _ 0 = throwError DivideByZero
safeDivide x y
  | y < 0     = throwError (UnexpectedError "Negative denominator")
  | otherwise = return (x `div` y)

-- Composed computation
compute :: Int -> Int -> Int -> AppM Int
compute a b c = do
  x <- safeDivide a b
  y <- safeDivide x c
  return y

-- Entry point
main :: IO ()
main = do
  result <- runExceptT (compute 10 2 0)
  case result of
    Left DivideByZero           -> putStrLn "Error: division by zero"
    Left (UnexpectedError msg)  -> putStrLn $ "Unexpected error: " ++ msg
    Right val                   -> putStrLn $ "Success: " ++ show val

This is quite elegant mathematically: you get typed, structured error handling that composes well with IO.

But once you start stacking more than one effect – say, ReaderT, StateT, and ExceptT – it quickly becomes hard to manage. Libraries like mtl, freer, or polysemy try to reduce this friction, but the conceptual weight remains high. The learning curve is steep, and yes, monads still confuse people. Not because they’re inherently difficult, but because most programming education doesn’t equip you to think in algebraic structures.

Excepting Monads

Despite Haskell’s emphasis on pure functions and strong static typing, it still includes support for runtime exceptions. Why? Because not all errors fit cleanly into a type-level model—especially when dealing with I/O or legacy code. However, these exceptions can be safely and idiomatically captured and transformed into more composable types like Either, making them compatible with the broader functional ecosystem.

import Control.Exception (SomeException, try, Exception, throwIO)
import Data.Typeable (Typeable)

-- Example function that may fail at runtime
failingIO :: IO Int
failingIO = throwIO $ userError "Something went wrong"

main :: IO ()
main = do
  result <- try failingIO :: IO (Either SomeException Int)
  case result of
    Left e  -> putStrLn $ "Caught error: " ++ show e
    Right v -> print v

Parsing and Non-Empty Chains (Scala)

This brings us to 2021, when this blog post really began. During my final undergraduate project with a company, we decided to step away from the mainstream and explore more functional tooling. That led us to Scala, and more specifically, to Cats.

In many real-world domains – especially parsing, validation, and data ingestion – you don’t just want to know if something failed. You want to know everything that failed.

Scala’s Cats library handles this elegantly with Validated and NonEmptyChain. Unlike Either, which short-circuits on the first failure, Validated accumulates all errors.

import cats.data.{Validated, NonEmptyChain}
import cats.syntax.all._

// Types
type Error = String
type Result[A] = Validated[NonEmptyChain[Error], A]

// Domain model
case class User(name: String, email: String, age: Int)

// Input model (e.g., raw user-submitted data)
case class RawInput(name: String, email: String, age: String)

// Validation functions
def validateName(name: String): Result[String] =
  if (name.trim.nonEmpty) name.validNec
  else "Name cannot be empty".invalidNec

def validateEmail(email: String): Result[String] =
  if (email.contains("@")) email.validNec
  else "Email must contain '@'".invalidNec

def validateAge(ageStr: String): Result[Int] =
  ageStr.toIntOption match {
    case Some(age) if age >= 0 => age.validNec
    case Some(_)               => "Age must be non-negative".invalidNec
    case None                  => "Age must be a valid number".invalidNec
  }

// Aggregate all validations
def validateUser(input: RawInput): Result[User] =
  (
    validateName(input.name),
    validateEmail(input.email),
    validateAge(input.age)
  ).mapN(User.apply)

@main def runValidation(): Unit = {
  val goodInput = RawInput("Alice", "alice@example.com", "30")
  val badInput  = RawInput("", "no-at-symbol", "-5")

  println("Valid input result:")
  println(validateUser(goodInput))

  println("\nInvalid input result:")
  println(validateUser(badInput))
}

Outputs:

Valid input result:
Valid(User(Alice,alice@example.com,30))

Invalid input result:
Invalid(Chain(Name cannot be empty, Email must contain '@', Age must be non-negative))

If name and email both fail, you get both errors, not just the first. That’s the kind of robustness you want in real-world parsing, form validation, or config loading. And all that without much boilerplate code.

It is important to note, though, that Validated is not a monad due to the accumulation of errors.

Effect Systems (Haskell++)

Effect systems bring to error handling – and to side effects more broadly – more powerful tools. Rather than wrapping all effects in a monad like IO, these systems explicitly track them in the type signature. This means you can determine exactly which effects a function might perform (I/O, logging, error handling, state, etc.) directly from its type – not by convention, but enforced by the compiler.

The polysemy library in Haskell is a good example of such a system. Here’s a simple example extracted from willGuimont/exercises_api. It combines state, logging, and error handling, all visible in the type signature.

-- Error type
data ExerciseError
  = ExerciseNotFound ExerciseId
  -- And other types of errors...
  deriving (Show, Eq, Generic)

-- Persistence effect to query exercices
data Persistence m a where
  -- Exercise
  GetExerciseById :: ExerciseId -> Persistence m (Maybe Exercise)
  -- And other effects...

makeSem ''Persistence

runPersistenceOnIO :: (Member (Embed IO) r) => Sem (Persistence ': r) a -> Sem r a
runPersistenceOnIO =
  interpret $
    \case
      -- Exercise
      GetExerciseById eId -> embed @IO . runSqlite sqliteDbName $ do
        let key = toSqlKey eId :: DbExerciseId
        eDb <- getEntity key
        pure $ toExercise <$> eDb
    -- and others...

-- Example function using persistence
getExercise :: Members [Persistence, Logging, Error ExerciseError] r => ExerciseId -> Sem r Exercise
getExercise eId = do
  logInfo "getExercise"
  getExerciseById eId >>= \case
    Nothing -> throw $ ExerciseNotFound eId -- Error if the exercise is not found
    Just e -> pure e

-- Server
formatNotFoundError :: Show a => BLU.ByteString -> a -> Either ServerError b
formatNotFoundError entityType eId  = Left err404 {errBody = LBS.concat [entityType <> " ", BLU.fromString $ show eId, " does not exist"]}

createApp :: IO Application
createApp = do
  loggerStdout <- fst <$> newFastLogger (LogStdout defaultBufSize)

  _ <- runM $ runPersistenceManagingOnIO executeMigration
  _ <- runM $ runLoggingOnLogger loggerStdout . logInfo $ "Starting server on port " <> pack (show port)

  return (serve exerciseApi $ hoistServer exerciseApi (`interpretServer` loggerStdout) server)
  where
    interpretServer sem loggerStdout =
      sem
        & runPersistenceOnIO
        & runLoggingOnLogger loggerStdout
        & runError @ExerciseError -- Transforms thrown ExerciceError into Either ExerciseError a
        & runM
        & exerciseErrorHandler

    -- Convert Either ExerciseError a into a Servant error
    exerciseErrorHandler = Handler . ExceptT . fmap handleExerciseErrors
    handleExerciseErrors (Left (ExerciseNotFound eId)) = formatNotFoundError "Exercise" eId
    -- and other errors
    handleExerciseErrors (Right value) = Right value

port :: Port
port = 8080

startServer :: IO ()
startServer = do
  app <- createApp
  withStdoutLogger $ \appLogger -> do
    let settings = setPort port $ setLogger appLogger defaultSettings
    runSettings settings $ simpleCors app

This makes exception handling more explicit and modular – you can define and run separate interpreters for each type of error, allowing each subsystem to handle its own failures independently.

This approach tickles my functional programming itch, but it comes with complexity. It is very elegant to think of your program as a series of composable effects that are then interpreted at the edges of your system. More complex operations can be decomposed into smaller effects before being interpreted. In some ways, it feels like a sort of interpreter that compiles your source code into a simpler bytecode (core language primitive operations) that is then executed. However, the learning curve is steep, and the abstraction overhead can be significant for small to medium projects.

Resuming the Conversation (OCaml, Koka, Effekt)

Polysemy’s interpreters live in Haskell’s type system, but effects can be a language feature. OCaml 5, Koka, and Effekt provide algebraic effects with handlers, and crucially, a handler can resume the suspended computation, not just abort it. Where try/catch only ever unwinds, an effect handler holds a continuation it can call to pick up exactly where the effect was performed.

The real power shows up when you keep the computation fixed and swap only the handler. Here, the pipeline is written once and knows nothing about how a division by zero is dealt with; two handlers impose two completely different policies on it:

open Effect
open Effect.Deep

(* The effect carries the numerator, so the handler has something to decide with. *)
type _ Effect.t += Div_by_zero : int -> int Effect.t

let divide x y =
  if y = 0 then perform (Div_by_zero x) else x / y

(* The computation. It does NOT know how divide-by-zero is handled. *)
let pipeline () =
  let a = divide 10 2 in   (* 5 *)
  let b = divide 7 0 in    (* performs Div_by_zero 7 *)
  let c = divide 20 4 in   (* 5 — runs only if b resumes *)
  a + b + c

(* Policy 1: resume, substituting the numerator as the result. *)
let resume_with_numerator f =
  match_with f ()
    { retc = (fun v -> v)
    ; exnc = raise
    ; effc = (fun (type a) (eff : a Effect.t) ->
        match eff with
        | Div_by_zero n -> Some (fun (k : (a, _) continuation) -> continue k n)
        | _ -> None) }

(* Policy 2: abort the whole computation with a sentinel. *)
exception Aborted
let abort_on_zero f =
  match_with f ()
    { retc = (fun v -> v)
    ; exnc = raise
    ; effc = (fun (type a) (eff : a Effect.t) ->
        match eff with
        | Div_by_zero _ -> Some (fun (_ : (a, _) continuation) -> raise Aborted)
        | _ -> None) }

let () =
  (* Same pipeline, two policies — only the handler differs. *)
  Printf.printf "resume: %d\n" (resume_with_numerator pipeline);  (* 5 + 7 + 5 = 17 *)
  match abort_on_zero pipeline with
  | n -> Printf.printf "abort:  %d\n" n
  | exception Aborted -> Printf.printf "abort:  aborted\n"

This is the separation of concerns that exceptions can’t express. pipeline decides where a problem is raised; the handler decides what it means. Under resume_with_numerator, the handler calls continue k 7, it resumes the suspended divide 7 0 in place, hands back 7, and execution flows on to c, so the block completes and sums to 17. Under abort_on_zero, the handler simply doesn’t call the continuation; it raises instead, discarding the rest of the computation, and c never runs. Same code, opposite outcomes, and the pipeline is none the wiser.

That’s the leverage: with try/catch the decision to abort is baked into the throwing code (once you throw, the frames are gone). With effects, “abort” and “resume” are just two handlers you can choose between after the fact; abort is the special case where you decline to resume. That resumption ability, recovering without unwinding, is the bridge to one of the oldest ideas in this whole post: Common Lisp’s conditions and restarts.

Terms and Conditions (Common Lisp)

Most mechanisms here fuse three concerns into one act: signaling a problem, deciding how to recover, and performing the recovery all happen at the catch site, after the stack has already been torn down. Common Lisp’s condition system, predating almost everything above, keeps them separate, and never unwinds until it’s good and ready.

A condition is signaled deep in the stack. Restarts are named recovery strategies defined at that same low level. But the handler that chooses which restart to invoke sits high up – and it runs with the stack still intact, in the dynamic context of the signaling code.

(define-condition divide-by-zero (error)
  ((numerator :initarg :numerator :reader numerator-of)))

(defun divide (x y)
  (restart-case
      (if (zerop y)
          (error 'divide-by-zero :numerator x)
          (/ x y))
    ;; Recovery strategies, defined DOWN at the point of failure:
    (use-value (v) :report "Supply a replacement result." v)
    (use-zero  ()  :report "Treat the result as 0."       0)))

(defun run-pipeline ()
  ;; The policy, decided UP here - chosen without unwinding the stack:
  (handler-bind
      ((divide-by-zero
         (lambda (c)
           (invoke-restart 'use-value (numerator-of c)))))
    (let ((a (divide 10 2))   ; 5
          (b (divide 7 0))    ; signals -> handler picks the use-value restart -> 7
          (c (divide 20 4)))  ; 5 -- still runs, because the restart resumed in place
      (+ a b c))))            ; 5 + 7 + 5 = 17

(format t "result: ~a~%" (run-pipeline))  ; => 17

When (divide 7 0) runs, divide does two things and stops: it signals a condition and publishes a menu of restarts (use-value, use-zero). Signalling is not throwing: nothing unwinds, so divide’s frame is still alive. The matching handler-bind runs while the stack is frozen, reads the numerator off the condition, and calls (invoke-restart 'use-value 7). That resumes divide in place with 7, so c still runs, and the block sums to 17.

The whole idea is that one split: signal (where), restart (how), handler (which). divide provides the recovery mechanisms without choosing one; run-pipeline chooses the policy without knowing how recovery works. Swap the handler to use-zero, and divisions by zero become 0; decline to restart, and you abort, all without touching divide.

And because the restarts are just a published menu, if no handler matches, Lisp doesn’t crash; it drops into the debugger and offers those same restarts to a human, who can pick one and resume the live program. Error handling, interactive recovery, and debugging are one mechanism.

This is the most general model in the post: exceptions are just the degenerate case where the only restart is “unwind to the handler.” It pairs naturally with Elixir’s “let it crash” as the opposite pole, where Erlang isolates failure and restarts a process; Lisp keeps the process alive and restarts a computation.

Trust, but verify `assert` (D)

Some languages, like Eiffel and D, support design by contract, a declarative way to specify preconditions, postconditions, and invariants. If a contract is violated, the program crashes or throws, often with minimal recovery. They are often even omitted when compiled in release mode. Thus, they are not, as the other techniques overviewed in this document, ways to validate user input or alternatives to exceptions.

Design by contract is about catching programmer mistakes, not handling external failures. If a function says “I expect a non-empty list,” and you give it an empty one, that’s not a runtime error to recover from – it’s a logic bug. The contract makes that explicit.

In contrast, exceptions, Either, Result, and Validated are about handling real-world uncertainty: invalid input, missing files, network timeouts, and corrupted data. These are expected failures that your program should handle gracefully.

Here’s a simple example of contract programming using D:

import std.stdio;

struct BankAccount {
    private {
        string owner;
        double balance;
    }

    this(string owner, double initialDeposit)
    in {
        assert(owner.length > 0, "Owner name cannot be empty.");
        assert(initialDeposit >= 0, "Initial deposit must be non-negative.");
    }
    do {
        this.owner = owner;
        this.balance = initialDeposit;
    }

    invariant() {
        assert(balance >= 0, "Invariant failed: balance must be non-negative.");
    }

    void deposit(double amount)
    in {
        assert(amount > 0, "Deposit amount must be positive.");
    }
    do {
        double oldBalance = balance;
        balance += amount;
        assert(balance >= oldBalance, "Postcondition failed: balance didn't increase.");
    }

    void withdraw(double amount)
    in {
        assert(amount > 0, "Withdrawal amount must be positive.");
        assert(amount <= balance, "Insufficient funds.");
    }
    do {
        double oldBalance = balance;
        balance -= amount;
        assert(balance <= oldBalance, "Postcondition failed: balance didn't decrease.");
    }

    double getBalance() const {
        return balance;
    }

    string getOwner() const {
        return owner;
    }
}

void main() {
    auto acc = BankAccount("Alice", 1000.0);
    acc.deposit(500.0);
    acc.withdraw(200.0);

    writeln("Owner: ", acc.getOwner());
    writeln("Balance: ", acc.getBalance());

    // Uncomment to test contract violations
    // acc.withdraw(2000); // Insufficient funds
    // acc.deposit(-100);  // Negative deposit
    // auto bad = BankAccount("", -10); // Invalid initial values
}

Contracts in D – namely in, out, and invariant blocks - act like free unit tests embedded directly within your code. They document and verify the intended behaviour of functions and invariants of types, automatically checked at runtime in debug builds. For instance, a precondition on withdraw guarantees that the withdrawal amount is valid before the function runs, while a postcondition ensures the balance decreases. Unlike traditional unit tests, which are often separate and may omit corner cases, contracts enforce correctness systematically and immediately during development, catching logic errors as soon as they are introduced. They don’t replace unit tests entirely, but they eliminate many boilerplate checks, serving as a robust safety net and specification tool during implementation.

Let It Go Crash (Elixir)

Elixir (and its Erlang foundations) embraces a fundamentally different philosophy: don’t prevent all errors - expect them, isolate them, and recover from them.

Instead of striving for defensive, error-free code at every level, Elixir leverages lightweight, isolated processes and robust supervision trees. Each process operates independently. When a failure occurs, it doesn’t propagate through shared memory or unwind a global stack. The process simply crashes – and a supervisor decides what to do next.

Here, errors are also values, represented as tagged tuples {:ok, value} and {:error, reason}. Functions return these tuples, and you pattern match on them to handle success and failure cases explicitly.

case do_something() do
  {:ok, result} -> 
    next_step(result)
    
  {:error, reason} -> 
    handle(reason)
    
  _ -> 
    # Catch-all for any other return value
    IO.puts("Unexpected result")
end

This design makes fault tolerance an architectural feature, not an implementation detail. Pattern matching ensures that error handling remains explicit and readable. Elixir’s paradigm forces you to think about the not-so-happy path from the beginning. Every function that returns :ok or :error reminds you that failure is part of the domain. You can’t ignore it – you have to model it.

Unlike Go, where the programmer is responsible for inspecting and propagating every error manually, Elixir encourages you to crash early and let the system self-heal. Resilience is not patched in – it’s built in.

Conclusion: Errors Are the Norm, Not the Exception

There is no perfect model. But there are better tradeoffs.

Every meaningful computation—every I/O operation, API call, database query – can fail. Yet most programming languages treat error handling as a second-class concern: either overly verbose, dangerously ignorable, or both. The happy path is (almost) always easy to write. The hard part is everything else.

There’s no silver bullet. But there are better tradeoffs – depending on your constraints, goals, and team culture. Personally, my thoughts on error handling have evolved over time. In the past, I leaned towards leveraging the type system to make errors explicit, like Haskell and Rust. But lately, I’ve come to appreciate the simplicity of Odin’s approach, which balances explicitness with conciseness and Elixir’s philosophy of embracing failure as a first-class concern rather than defensive coding.

Errors are the norm, not the exception. The best systems are those that make handling them not only simple, but obvious.

3D-Printed AprilTags That Withstand the Real World

2025-05-27T00:00:00+00:00

In many robotics projects, AprilTags are indispensable. But the standard approach — printing on paper, gluing to cardboard — doesn’t hold up outside the lab. Tags peel, warp, fade, and disintegrate when exposed to handling, humidity, or rough environments.

Tracker3D.jl solves this. It generates 3D-printable AprilTags engineered for the real world: flat, durable, weather-resistant, and easy to integrate directly into enclosures or mounts. Whether you’re field-testing robots or deploying long-term vision systems, these tags won’t fail you.

Why Tracker3D.jl?

🚫 No more flimsy paper or fragile adhesives
✅ Always flat, robust, and easy to embed
☁️ Weatherproof and reusable
🧩 Ideal for industrial, outdoor, or educational setups

GitHub: willGuimont/Tracker3D.jl

Ready-to-print tags: Thingiverse

Using Citizen Science Data for UAV Image Analysis

2025-04-09T00:00:00+00:00

Co-authored paper in MDPI: Using Citizen Science Data as Pre-Training for Semantic Segmentation of High-Resolution UAV Images for Natural Forests Post-Disturbance Assessment

The ability to monitor forest areas after disturbances is key to ensure their regrowth. Problematic situations that are detected can then be addressed with targeted regeneration efforts. However, achieving this with automated photo interpretation is problematic, as training such systems requires large amounts of labeled data. To this effect, we leverage citizen science data (iNaturalist) to alleviate this issue. More precisely, we seek to generate pre-training data from a classifier trained on selected exemplars. This is accomplished by using a moving-window approach on carefully gathered low-altitude images with an Unmanned Aerial Vehicle (UAV), WilDReF-Q (Wild Drone Regrowth Forest—Quebec) dataset, to generate high-quality pseudo-labels. To generate accurate pseudo-labels, the predictions of our classifier for each window are integrated using a majority voting approach. Our results indicate that pre-training a semantic segmentation network on over 140,000 auto-labeled images yields an $F1$ score of 43.74% over 24 different classes, on a separate ground truth dataset. In comparison, using only labeled images yields a score of 32.45%, while fine-tuning the pre-trained network only yields marginal improvements (46.76%). Importantly, we demonstrate that our approach is able to benefit from more unlabeled images, opening the door for learning at scale. We also optimized the hyperparameters for pseudo-labeling, including the number of predictions assigned to each pixel in the majority voting process. Overall, this demonstrates that an auto-labeling approach can greatly reduce the development cost of plant identification in regeneration regions, based on UAV imagery.

Free 3D Scanning using iOS devices

2025-03-03T00:00:00+00:00

The current state of 3D scanning apps on the App Store is a bit disappointing. Most of them are either paid or have a subscription model. Not doing enough scanning to justify the cost, I decided to look for a free alternative.

I was pleasantly surprised to find that Apple’s own RealityKit framework has a sample app for exactly this purpose. Scanning objects using Object Capture is a free app that lets you scan objects using your iOS device.

To get started, install Xcode and download the sample app from the Object Capture sample code. Build and run the app on your iOS device, and follow the instructions to scan an object.

Once done, you can export the scanned object as a USDZ file or save all the images to your device. The images can then be used with Building an object reconstruction app to create a high-quality 3D model.

Since USDZ is not a widely supported format in the 3D printing world or CAD software, you can convert it to other formats using tools like Blender.

Terrain Classification for Boreal Forests

2024-09-10T00:00:00+00:00

Co-authored paper at IROS 2024: Proprioception Is All You Need: Terrain Classification for Boreal Forests

Recent works in field robotics highlighted the importance of resiliency against different types of terrains. Boreal forests, in particular, are home to many mobility-impeding terrains that should be considered for off-road autonomous navigation. Also, being one of the largest land biomes on Earth, boreal forests are an area where autonomous vehicles are expected to become increasingly common. In this paper, we address the issue of classifying boreal terrains by introducing BorealTC, a publicly available dataset for proprioceptive-based terrain classification (TC). Recorded with a Husky A200, our dataset contains 116 min of Inertial Measurement Unit (IMU), motor current, and wheel odometry data, focusing on typical boreal forest terrains, notably snow, ice, and silty loam. Combining our dataset with another dataset from the literature, we evaluate both a Convolutional Neural Network (CNN) and the novel state space model (SSM)-based Mamba architecture on a TC task. We show that while CNN outperforms Mamba on each separate dataset, Mamba achieves greater accuracy when trained on a combination of both. In addition, we demonstrate that Mamba’s learning capacity is greater than a CNN for increasing amounts of data. We show that the combination of two TC datasets yields a latent space that can be interpreted with the properties of the terrains. We also discuss the implications of merging datasets on classification. Our source code and dataset are publicly available online.

Fix Obsidian Broken Graph View

2024-07-14T00:00:00+00:00

If the Graph View in Obsidian is broken after an update, you can fix it by following these steps:

# Close Obsidian
cd ~/.config/obsidian
rm -rf Cache Code\ Cache DawnCache GPUCache
# Reopen Obsidian

Cite website Bookmarklet

2024-06-08T00:00:00+00:00

To automatically cite a website in bibme.org, add the following bookmarklet to your bookmarks bar:

javascript:void((function(){location.href='https://www.bibme.org/apa/website-citation/search?q='+location.href;})());

Clicking the bookmarklet will open the current page in bibme.org’s citation generator.

Benchmarking of Real-Time Object Detection Models

2024-06-05T00:00:00+00:00

Published a paper to ArXiv: Replication Study and Benchmarking of Real-Time Object Detection Models.

This work examines the reproducibility and benchmarking of state-of-the-art real-time object detection models. As object detection models are often used in real-world contexts, such as robotics, where inference time is paramount, simply measuring models’ accuracy is not enough to compare them. We thus compare a large variety of object detection models’ accuracy and inference speed on multiple graphics cards. In addition to this large benchmarking attempt, we also reproduce the following models from scratch using PyTorch on the MS COCO 2017 dataset: DETR, RTMDet, ViTDet and YOLOv7. More importantly, we propose a unified training and evaluation pipeline, based on MMDetection’s features, to better compare models. Our implementation of DETR and ViTDet could not achieve accuracy or speed performances comparable to what is declared in the original papers. On the other hand, reproduced RTMDet and YOLOv7 could match such performances. Studied papers are also found to be generally lacking for reproducibility purposes. As for MMDetection pretrained models, speed performances are severely reduced with limited computing resources (larger, more accurate models even more so). Moreover, results exhibit a strong trade-off between accuracy and speed, prevailed by anchor-free models - notably RTMDet or YOLOx models. The code used is this paper and all the experiments is available in the repository at this https URL.

RandAugment

2024-04-03T00:00:00+00:00

Presentation made for the course GIF-7010: Avancées en apprentissage automatique at Université Laval on RandAugment.

Here are the slides:

Sync Obsidian vaults to Android using Git

2024-03-25T00:00:00+00:00

Updated way to sync your Obsidian vault to an Android phone using Git. Previous method can be found here.

Here’s the procedure to sync your Obsidian vault to an Android phone.

First, you’ll have to run these commands on your computer:

Create a SSH key using ssh-keygen -f ~/obsidian-phone-key -t ed25519 -C "your_email@example.com"
Add the public key (~/obsidian-phone-key.pub) to your GitHub account
Connect your phone to your computer and allow the computer to access phone data (e.g., using LocalSend)
Copy the private key (~/obsidian-phone-key) to your phone

Now, on your phone:

Install F-Droid
Open F-Droid and install Termux
In Termux, install git using pkg install git
In Termux install termu-am using pkg install termux-am
Mount the phone storage using termux-setup-storage
Copy your SSH key into ~/.ssh/ using cp ~/storage/shared/path/to/obsidian-phone-key ~/.ssh/
Follow these instructions to add the ssh key
Now go to the location you want to clone the repository (should be in ~/storage/shared/ for Obsidian to have access) and clone it using git clone git@github.com:username/repo.git
You can now open Obsidian
1. Open folder as vault
2. Browse to the repository you copied from your computer
Open F-Droid and install MGit
From the settings page of MGit, import the SSH key
1. SSH Keys
2. Download button in the upper right corner
3. Select obsidian-phone-key you copied from your computer
Go back to the main menu of MGit, press the three dots in the upper right and press the Import Repository button
Browse to the repository you copied from your computer
You should now be able to pull from MGit
Your Obsidian vault is now synced using Git!
(Optional) If you want to also be able to manage the repository from Termux, run the command git config --global --add safe.directory ~/storage/shared/path/to/repo

Segment Anything

2024-02-21T00:00:00+00:00

Presentation made for the course GIF-7010: Avancées en apprentissage automatique at Université Laval on Segment Anything.

Here are the slides:

Wayback Machine Bookmarklet

2023-12-29T00:00:00+00:00

To automatically open a website in the Wayback Machine, add the following bookmarklet to your bookmarks bar:

javascript:void((function(){location.href='https://web.archive.org/web/*/'+location.href;})());

Clicking the bookmarklet will open the current page in the Wayback Machine.

Ph.D. Proposal Passed

2023-09-25T00:00:00+00:00

Passed the Ph.D. proposal exam!

Ph.D. Proposal Final Version

Ph.D. Proposal - A First Draft

2023-09-25T00:00:00+00:00

This is my Ph.D. proposal. It is a work in progress: Ph.D. Proposal

Random quotes about research

2023-09-15T00:00:00+00:00

A small collection of random quotes about research.

Research is what I’m doing when I don’t know what I’m doing.

– Wernher von Braun

If it works in theory, it also works in practice. In theory.

And some quotes from discussions with friends.

Research is like wandering through a maze in search of an knowledge. But you can’t see the walls, and you don’t know if you’re lost. So you just keep bumping into walls until you find the something.

– A friend of mine

Where’s the box?

Me: Let’s think outside of the box to solve this.

A friend: But there is no box to think outside of.

And a ~~poem~~ joke about this video Socialism Is When The Government Does Stuff

Science is when you know stuff.

And it’s more sciencey the more stuff you know.

And if you know a real lot of stuff, it’s a paper.

– A friend of mine

Atelier Bash et Docker

2023-09-05T00:00:00+00:00

Ces ateliers ont été conçus pour le département d’informatique et de génie logiciel de l’Université Laval. Ils ont été donnés dans le cadre du cours IFT-2001 et GLO-2001 Systèmes d’exploitation.

Atelier d’introduction à Bash

Ce premier atelier a pour but de vous familiariser avec le terminal et le langage de script Bash. Vous apprendrez à utiliser les commandes de base de Bash et à écrire des scripts simples.

Énoncé Bash

Solutionnaire Bash

Code source

Atelier d’introduction à Docker

Ce deuxième atelier a pour but de vous familiariser avec Docker. Vous apprendrez à utiliser les commandes de base de Docker et à écrire des Dockerfile.

Énoncé Docker

Solutionnaire Docker

Code source

MaskBEV

2023-07-11T00:00:00+00:00

Accepted paper at IROS 2023: MaskBEV: Joint Object Detection and Footprint Completion for Bird’s-eye View 3D Point Clouds

Recent works in object detection in LiDAR point clouds mostly focus on predicting bounding boxes around objects. This prediction is commonly achieved using anchor-based or anchor-free detectors that predict bounding boxes, requiring significant explicit prior knowledge about the objects to work properly. To remedy these limitations, we propose MaskBEV, a bird’s-eye view (BEV) mask-based object detector neural architecture. MaskBEV predicts a set of BEV instance masks that represent the footprints of detected objects. Moreover, our approach allows object detection and footprint completion in a single pass. MaskBEV also reformulates the detection problem purely in terms of classification, doing away with regression usually done to predict bounding boxes. We evaluate the performance of MaskBEV on both SemanticKITTI and KITTI datasets while analyzing the architecture advantages and limitations.

Synchronise Obsidian vaults to Android using Git

2023-07-07T00:00:00+00:00

Here’s the procedure to sync your Obsidian vault to an Android phone.

First, you’ll have to run these commands on your computer:

Create a SSH key using ssh-keygen -f ~/obsidian-phone-key -t ed25519 -C "your_email@example.com"
Add the public key (~/obsidian-phone-key.pub) to your GitHub account
Connect your phone to your computer and allow the computer to access phone data
Copy the private key (~/obsidian-phone-key) to your phone
Also copy your Obsidian vault, including the .git folder

Now, on your phone:

Install F-Droid
Open F-Droid and install MGit
From the settings page of MGit, import the SSH key
1. SSH Keys
2. Download button in the upper right corner
3. Select obsidian-phone-key you copied from your computer
Go back to the main menu of MGit, press the three dots in the upper right and press the Import Repository button
Browse to the repository you copied from your computer
You should now be able to pull from MGit
You can now open Obsidian
1. Open folder as vault
2. Browse to the repository you copied from your computer
Your Obsidian vault is now synced using Git!

Learn Transformers

2023-03-23T00:00:00+00:00

Here’s a small library I made to explain the Transformer architecture in PyTorch: willGuimont/transformers. The code is heavily commented and should be easy to follow.

This repository also contains some popular transformer-based models, such as Vision Transformer.

This was made while developping new practical exercises for GLO-7030 at Université Laval.

torch_waymo

2023-02-02T00:00:00+00:00

Here’s a small library I made to use the Waymo Open Dataset in PyTorch, without any dependency to Tensorflow: willGuimont/torch_waymo.

Here’s the corresponding PyPI package: torch-waymo.

Apprentissage profonds sur les nuages de points 3D

2022-09-12T00:00:00+00:00

Papier réalisé pour le cours IFT-6001 @ Université Laval sur l’apprentissage par réseaux de neurones profonds sur les nuages de points 3D: Apprentissage par réseaux de neurones profonds sur les nuages de points 3D

APIs using Haskell and polysemy

2022-06-08T00:00:00+00:00

Here’s a simple API in Haskell using Servant and Polysemy: willGuimont/status-checker.

And another one: willGuimont/exercises_api

Point-BERT IFT-6001

2022-04-28T00:00:00+00:00

Voici une présentation que j’ai donnée le 28 avril 2022 pour le cours IFT-6001 Introduction à la recherche en informatique : communication et méthodologie à l’Université Laval sur Point-BERT.

Voici les diapositives: Point-BERT

Voici l’enregistrement de la présentation:

Les tests en pratique

2022-03-14T00:00:00+00:00

Tester, ce n’est pas seulement s’assurer que le code « marche ». C’est une démarche structurée pour réduire l’incertitude, détecter les erreurs tôt et donner confiance dans le système. Trop souvent, les tests sont vus comme une contrainte ou un ajout après coup. En pratique, bien utilisés, ils deviennent un outil de conception, de documentation et de robustesse.

Ces slides présentent une approche concrète : les différents niveaux de tests (unitaires, intégration, système, acceptation), leurs rôles respectifs et les pièges fréquents. On y retrouve aussi des principes simples : un test doit être automatisé, indépendant et binaire. Il doit rester lisible, rapide et maintenable.

À travers l’exemple d’UTournament, nous verrons comment structurer un test (Arrange-Act-Assert), comment limiter la fragilité et comment élargir la portée avec des approches comme le property-based testing. L’objectif est de montrer qu’avec un minimum de rigueur, les tests deviennent un allié au développement plutôt qu’un fardeau.

Slides: Les tests en pratique

Understanding monads: Some resources

2021-10-14T00:00:00+00:00

Instead of doing like everyone else and write a long-winded blog post about my aha moment about monads, I’ll only link some useful resources about monads.

Transformers in Computer Vision

2021-09-02T00:00:00+00:00

On September 2nd 2021, I gave a talk on transformer-based neural network architectures for computer vision. I gave the in University Laval’s Norlab.

Here are the slides: Transformers in Computer Vision

And here is the recording of the event:

Inward and Outward Polymorphism

2020-07-09T00:00:00+00:00

I’ve recently become fond of Algebraic Data Types (ADT).

Languages like Haskell and Rust allows you to model your domain in a concise way using ADT. What would take several classes (and files) in Java (Interface-Oriented Programming (IOP)) can be expressed in a couple of lines. This got me thinking about software architecture using those two.

Both IOP and ADT have advantages and disadvantages.

ADT is a lot more concise but requires to use pattern-matching. Adding a new ADT type would then mean that you’ll have to add a case to every function matching on the type. Whereas adding a new function acting on an ADT is easy, you simply need to write the function.

For IOP on the other hand, adding a new implementation of the interface is easy. You simply implement the needed methods. Whereas adding a new function in the interface can quickly become expensive, you’ll have to add the method to every class implementing the interface. I’ll include Haskell’s type-classes and Rust’s traits as IOP.

I discussed that compromise a bit more in a previous post on abstract data types. Albeit about a different type of ADT (algebraic vs abstract), the post is still relevant to understand the difference between ADT and IOP.

Here, I would like to discuss the software engineering aspect of using IOP and ADT when designing modules. I’ll introduce the concept of inward and outward polymorphism.

Motivation

To motivate the introduction of those concepts, let’s start with two small examples.

Algebraic Data Type

You are charged to build a networking library in Rust. You want to support both IPv4 and IPv6. Each one represents addresses in different ways, IPv4 stores address using four 8 bits numbers, while IPv6 stores it as a string. Using Rust, and having recently read the Rust Book’s chapter on enums, you decide to declare them the following way:

enum IpAddr {
    V4(u8, u8, u8, u8),
    V6(String),
}

The user will call your functions, like connect_to(ip: IpAddr), using the polymorphic nature of IpAddr to use either IPv4 or IPv6.

Interface-Oriented Programming

The next day, you are writing Java (poor you). You have to implement an application that provides support for plugins. So, you make an interface and write your code calling that interface. The user can then implement your interface with their code, and you can call their class since it implements your interface.

So, your library calls the user’s code polymorphically.

Inward or Outward

In the last two examples, we can see two different uses of polymorphism. In the first example, the user called your library passing polymorphic data type, while the second one, the user implemented an interface so that your library would call their code.

We can see that the flow of control is different in both cases. In the first example, the flow moves into your code whereas, in the other example, the flow moves out of your code.

Based on the control flow, we can define inward polymorphism as polymorphism used when the user calls your code. Outward polymorphism would then be the use of polymorphism when your code is expected to call the user’s code.

The examples were about libraries, but the same concept of inward or outward can be applied to modules.

ADT or IOP

Inward and outward polymorphism impose different types of constraints.

When I need to write inward polymorphic code, I like to use the expressiveness of ADT. This can make the code elegant and concise.

For outward polymorphism, you have to use IOP, so that both your module and the user’s code can communicate using a common interface.

The choice between ADT and IOP can be really difficult and, as always, there is no apply to all solutions in software architecture. The only real answer you’ll receive is “it depends”.

TossingBot

2020-04-29T00:00:00+00:00

This video presents TossingBot, a robotic arm that learns to throw arbitrary objects with residual physics.

This video was made for the class GLO-7030: Deep Learning at Université Laval.

On Learning

2020-01-23T00:00:00+00:00

This is just some rambles on learning…

I’m currently taking a class on deep neural networks. In the first class, we discussed multiple ways to have artificial intelligence systems.

One way would be to code hand-designed programs to accomplish the task. If something happens, then the system does that, else if this other thing happens, then do this, else if… We can achieve great things using rule-based programs, but on more complex tasks we would need a lot of cases to handle a lot of different cases.

Another way would be to make the computer learn from the data. So we analyze the data, find features for the system to learn from, then use classical machine learning algorithms such as SVM. Again, for complex tasks, we may miss some useful feature to correctly learn from the data.

The next step is to make the algorithm find features by itself. This is what neural networks do. Each layer of a deep neural network extract features for the higher layers to “reason” about. The classical example is a neural network that detects faces. The first layers might detect very simple patterns like edges. Higher up, a layer might detect corners and contours. Layers at the end of the network might detect complex object parts used by the final layer to classify the object. This is what is called representation learning, the artificial intelligence system finds a way of representing the data so that it is easy to solve the task.^[1].

A good way of visualizing the different takes on artificial intelligence is from the book Deep Learning^[1].

Dreyfus

When I learned about representation learning, it got me thinking about how we learn and the Dreyfus model^[2].

I think we can draw links between the Novice stage and rule-based systems. In this first stage of the Dreyfus model, the learner relies on rules to determine the action.

Perhaps, there are other links between machine learning and the Dreyfus model.

Mental representations

In The Sciences of the artificial^[3] from Herbert A. Simon, the author discusses the experience of A. de Groot and al. on chess perception. They showed chessboard with pieces in positions of real games for 5 seconds, then removed the pieces. Then they asked the subjects to put the pieces back in their position.

As you might guess, somebody not accustomed to chess would have a pretty hard time to reconstruct the positions. For grandmasters and masters though, they were able to reconstruct the positions with almost no error!

They then retried the experiment with random piece positions. In that case, even grandmasters could not reconstruct the board.

This shows that a grandmaster or a master built a good mental representation of the game. Instead of memorizing all pieces, they memorized relations between pieces, which allow them to memorize them more easily.

So, when I learned about representation learning, this reminded me of that particular example. Under the hood, a neural network tries to do exactly what the grandmaster did, build a good representation of the problem to solve. Once the representation is built, a simple linear layer can solve the problem!

I think this is what is really going on when humans learn. All the studying isn’t about memorizing facts or formulas, it’s about building a good mental representation that can be used to solve many problems. Once you understand basic algebra, you can use that framework to solve many problems you weren’t trained on.

In a neural network, we are usually not concerned about memorizing all the input data, instead, we want to generalize to unseen examples.

Perhaps we should tell students that they aren’t in school to memorize facts, but instead to build a toolbox of mental representations to help them in life. Our brain is a neural network that needs to be trained with great care!

Sources

Goodfellow, Ian & Bengio, Yoshua & Courville, Aaron. Deep Learning. 2016. ↩ ↩2
Dreyfus, Stuart E. The Five-Stage Model of Adult Skill Acquisition. 2004. ↩
Simon, Herbert A. The Sciences of the Artificial, 1969. ↩

PROSAC

2019-12-26T00:00:00+00:00

Recently, for a graduated mobile robotics class, I had to present a scientific paper. Loving algorithms, I decided to read Matching with PROSAC - Progressive Sample Concensus^[1], a paper presenting a variant of the popular RANSAC algorithm.

This article will be a more detailed version of the presentation I gave for that class, the slides are here. I won’t go into much of the mathematics, the details are in the paper. What I want to do with this article is to give you the intuition behind the algorithm more than writing a lot of equations.

To supplement the presentation, I wrote an implementation of PROSAC in Python: willGuimont/PROSAC.

Before jumping in PROSAC, let’s just review RANSAC a bit.

RANSAC - Random sample consensus

The main goal of RANSAC is to estimate a model from noised data with outliers.

The basic idea is to randomly sample points from all points; fit a model on those randomly chosen points; then check if the model fits with the rest of the data.

As you can see, the algorithm is relatively simple: sample, fit, check, rinse and repeat.

Pseudocode

Let $m$ be the minimum required number of points to fit a model. For a linear model in 2D, $m$ would be equal to $2$.

Let $M$ a model to fit on the data.

Let $\epsilon_{tol}$ be the maximum error between a point and the model to be considered an inlier.

Let $\tau$ the fraction of inlier over the total number of points above which we are satisfied by the model. If we achieve that ratio, we stop early.

Let $w$ be the probability of a given point to be an inlier. This is used to estimate the number of times we have to run RANSAC before finding a satisfying solution.

Let $I$ be the set of inliers of maximal cardinality.

RANSAC

Sample $m$ points
Estimate a model $M$ from the $m$ sampled points
Find the number of inliers with model $M$ with tolerance $\epsilon_{tol}$. If the number of inliers is greater than the number of previously found inliers, replace $I$ with the new set of inliers.
If the fraction of inliers over the total number of points is greater than $\tau$, estimate the model with all inliers and stop.
Repeat steps 1 to 4, a maximum of $\frac{1}{w^m}$ times
After $\frac{1}{w^m}$ iterations, estimate the model with $I$.

Limitations of RANSAC

In the paper, they looked at estimating epipolar geometry from a pair of pictures.

With this pair of pictures, there is a lot of repetitive patterns on the floor and leaves, so there will be a lot of false matches. We have $m=7$ (epipolar geometry) and $w=9.2%$. The number of iteration of RANSAC is given by $\frac{1}{w^m}$. The estimated number of samples is over $8.43 \times 10^7$ !!! RANSAC would take a pretty long time before finding a good solution… That’s not realistic!

When the model is complex and the number of correct points is low, RANSAC often takes very long before finding a satisfying solution. Let’s see if PROSAC can help.

PROSAC - Progressive sample consensus

PROSAC adds the notion of quality to points with the basic assumption that points of greater quality have more chances to be correct.

So, to make the algorithm quicker, the algorithm starts by trying to fit with points of greater quality first. Then we progressively add points of lesser quality.

Intuition

Let’s say that the points in red are outliers. We would like to fit a model of complexity $m=2$ on those points.

RANSAC	PROSAC
$p_1$	$p_2$
$p_2$	$p_4$
$p_3$	$p_6$
$p_4$	$p_3$
$p_5$	$p_5$
$p_6$	$p_1$

In RANSAC, we would be sampling $2$ points among all points, so we would have a probability of $\frac{3}{6}\cdot\frac{2}{5}=20%$. So, we would need, on average, $5$ samples before finding an uncontaminated sample.

Whereas in PROSAC, we sort points by quality. The first points would be of higher quality. We would start sampling from the top 2 points, so we would sample $p_2$ and $p_4$, both of which are correct. In this case, we would have found an uncontaminated sample on the first draw.

Even with this simple example, we can see the possible speedup.

Simplified pseudo code

PROSAC

Sort points by quality (highest quality first)
Consider the first $m$ points ($n\leftarrow m$)
Sample $m$ points from the top $n$
Fit the model
Verify model with all points
If the stopping criteria are not met, repeat steps 3 to 6, adding progressively points ($n\leftarrow n + 1$). Otherwise, fit the model on all inliers and terminate.

Quality

There are multiple ways of defining quality. For feature matching on images, we could use the correlation of intensity around features on each image.

In the paper, they mention Lowe’s distance. Lowe’s distance is the ratio between the most and second most similar matches.

$s_1$: distance of the most similar match

$s_2$: distance of the second most similar match

$\text{distance} = \frac{s_1}{s_2}$

This distance allows us to select the first points that are significantly better than any other. A match with a low Lowe’s distance has more chances of being correct.

To define quality, we could inverse the ratio.

$\text{quality} = \frac{s_2}{s_1}$

You can use any metric you want, as long as the higher the quality is, the higher the probability of the point being correct is.

Fast sampling

We could simply sample $m$ points from the top $n$ points, but that would be inefficient. We could sample multiple times the same set of points. So, to better explore the new possibles sets of $m$ points, we use the fact that when adding a new point $p_{n+1}$, we add a number $a$ of new samples. Each new sample contains the new point $p_{n+1}$ and $m-1$ from the $n$ first points.

So, we can simply sample $a$ times, picking $p_{n+1}$ and $m-1$ points in the best $n$ points. That way, we ensure the quickly explore the possibles sets of $m$ points.

End criterion

The algorithm has two stopping criteria.

Non-random solution
Maximality

Non-random solution

This criterion states that for a solution to be considered correct, it must have more inliers than what would randomly happen for an incorrect model.

This is computed by estimating the probability that an incorrect model (fitted on a sample) is supported by a given point, not in the sample.

The solution is considered non-random if the probability of having its number of inliers by chance is smaller than a certain threshold (usually 5%).

Maximality

We want to stop sampling when the chance of getting a model that fit more points is lower than a certain threshold. This is computed by looking at the odds of missing a set of inliers bigger than previously found after a number of draws. If this probability falls under a certain threshold (usually 5%), it is not worth continuing drawing and we terminate.

Code

Not having found any implementation of PROSAC online, I decided to post mine: willGuimont/PROSAC.

Sources

Chum, Ondrej & Matas, Jiri. Matching with PROSAC - Progressive Sample Consensus. 2005. ↩

Rubik's Cube Timer in Vue.js

2019-06-23T00:00:00+00:00

Here a simple Rubik’s Cube Timer I made in Vue.js

Link to the timer

Pomodoro Timer in Vue.js

2019-03-20T00:00:00+00:00

Here a simple Pomodoro Timer I made in Vue.js.

Link to the timer

Exercice conditions avec des photorésistances

2019-03-03T00:00:00+00:00

Le but de cet exercice est de vous faire pratiquer les conditions et la boucle principale. De plus, vous aurez la chance de vous pratiquer à lire de la documentation.

Photorésistance

Une photorésistance est une composante électronique dont la résistance change selon la lumière qui l’éclaire. En bref, on peut regarder la tension aux bornes de la photorésistance.

But de l’exercice

Écrivez le code pour qu’une DEL s’allume lorsque la photorésistance est à l’ombre et éteindre la DEL lorsqu’elle est éclairée.

Liens utiles

analogRead

Serial pour afficher des informations à l’écran

Introduction aux conditions et à la boucle principale

2019-03-02T00:00:00+00:00

Dans l’article précédant, nous avons vu comment faire clignoter une DEL 2 fois avant de s’éteindre. Maintenant, essayons de n’allumer la DEL que lorsqu’un bouton est enfoncé.

En mots, on voudrait demander à l’Arduino:

Si le bouton est enfoncé
1. Allumer la DEL
2. Attendre 3 secondes
3. Éteindre la DEL
Sinon
1. Laisser la DEL éteinte

Pour ce faire, on branche un bouton de la façon suivante.

Les zig-zags représentent la résistance. Le symbole avec les deux points vides et le bout de fil représente un bouton ou un interrupteur.

Fonctions de bases

Pin en lecture

pinMode(2, INPUT);

Cette fonction permet de mettre la pin 2 en mode lecture.

Lecture d’une pin

digitalRead(2);

Cette fonction retourne HIGH si la tension est près de 5V sur la pin, ou LOW si la tension est près de 0V.

Variables

On aimerait pouvoir garder l’état du bouton pour pouvoir comparer sa valeur. Pour ce faire, on utilise des variables. Les variables sont comme des boîtes. On peut donner un nom à la boîte et mettre une valeur dedans.

On peut demander à l’Arduino de nous créer une boîte avec un certain nom. On peut ensuite mettre une valeur à l’intérieur. Si on veut, on peut mettre une autre valeur dans la boîte par la suite.

Exemple

int maVariable;
maVariable = 4;
maVariable = 2;
maVariable = maVariable + 1;

int correspond au type de la variable. maVariable est donc de type int. int veut dire integer, c’est-à-dire entier en français. Un nombre entier sont des nombres comme 0, 1, 2, 3, 4, -3, 42 et -245. On a donc que maVariable peut contenir des nombres entiers. On commence par donner la valeur 4 à maVariable. Ensuite, on change cette valeur pour 2. Ensuite, on met dans maVariable la valeur de maVariable + 1. Comme maVariable valait 2, on a que maVariable est maintenant 2 + 1, donc 3.

On remarque que le signe = n’a pas le même sens qu’en mathématique. En mathématique, il serait faux de dire 2 = 3. Dans notre cas, on assigne la valeur de droite à la variable de gauche.

Remarque: On aurait pu utiliser n’importe quel autre nom pour la variable.

Remarque: D’autres opérateurs que l’addition (+) sont définis, on peut faire des soustractions (-), des multiplications (*), des division (/) et le modulo (%). La division est toutefois tronqué avec des int puisqu’un int ne peut contenir que des nombres entiers. Le modulo calcule le reste de la division. Pour le moment, ne vous inquiétez pas avec cela.

Storer l’état du bouton dans une variable

Maintenant que nous savons ce qu’est une variable et comment récupérer l’état du bouton, sauvegardons l’état du bouton dans une variable.

pinMode(2, INPUT);                 // pin 2 en lecture
int etatBouton = digitalRead(2);   // mettre l'etat du bouton dans etatBouton

Voilà, nous avons l’état du bouton dans etatBouton.

Conditions

Maintenant que nous avons l’état du bouton dans une variable, on aimerait pouvoir réaliser certaines actions SI une condition est vraie et d’autres SINON.

Il existe en C++ une façon de réaliser des branchements conditionnelles, c’est-à-dire de faire certaines chose si la condition est vraie. En voici un exemple simple:

int x = 5;
if (x < 10)
{
    x = 10;
}

if veut dire si en français. Si on lit le code en français, on a:

Créer une variable nommée x et mettre 5 dedans
Si x est plus petit que 10 alors
1. On mets 10 dans x

Comme 5 est plus petit que 10, on a que la valeur de x est maintenant 10.

Voici un second exemple:

int x = 42;
if (x == 42)
{
    x = x - 10;
}

if veut dire si en français. Si on lit le code en français, on a:

Créer une variable nommée x et mettre 42 dedans
Si x est égal à 42 alors
1. On mets x - 10 dans x

Comme x est bien égal à 42, on soustrait 10 à x. x a donc la valeur de 32 après l’exécution.

Remarque: == veut dire est égal à, à ne pas confondre avec = qui veut dire assigner

Disons que nous voulons réaliser ceci:

Soit un entier x qui vaut 39
Si x == 42
1. x = x - 10
Sinon
1. x = 0

Comment pouvons nous traduire cela en code? Il existe le mot-clef else qui fait exactement cela.

On aurait alors

int x = 39;
if (x == 42)
{
    x = x - 10;
}
else
{
    x = 0;
}

Comme x = 39, on a que la condition x == 42 est fausse, donc on n’exécute pas x = x - 10, on entre ensuite dans le else où on assigne 0 à x.

Maintenant que nous savons comment faire des conditions, on peut allumer la DEL si l’état du bouton est à HIGH.

void setup() 
{
  pinMode(13, OUTPUT);
  pinMode(2, INPUT);                 // pin 2 en lecture
  int etatBouton = digitalRead(2);   // mettre l'etat du bouton dans etatBouton
  if (etatBouton == HIGH)
  {
    digitalWrite(13, HIGH); // Si le bouton est a HIGH, on allume
  }
  else
  {
    digitalWrite(13, LOW); // Sinon on laisse éteint
  }
}

void loop()
{
}

Il y a toutefois un petit problème, la lumière ne s’allume ou ne s’éteint qu’au démarrage de l’Arduino. Pour changer l’état de la lumière, il faut appuyer sur le bouton, puis redémarrer l’Arduino avec le bouton reset. Ce n’est pas très pratique. On aimerait que cela se fasse en tout temps.

Pour palier à ce problème, on peut utiliser loop. Comme son nom l’indique, loop est une boucle, c’est-à-dire que le code dans cette fonction s’exécute continuellement après l’exécution de setup. Déplaçons donc ce qui doit être exécuté plusieurs fois dans loop.

void setup() 
{
  pinMode(13, OUTPUT);  // pin 13 en sortie
  pinMode(2, INPUT);    // pin 2 en lecture
}

void loop() 
{
  int etatBouton = digitalRead(2);   // mettre l'etat du bouton dans etatBouton
  if (etatBouton == HIGH)
  {
    digitalWrite(13, HIGH); // Si le bouton est a HIGH, on allume
  }
  else
  {
    digitalWrite(13, LOW); // Sinon on laisse éteint
  }
}

On remarque que les pinMode sont restés dans setup. En effet, on ne veut réserver ces pin qu’une seule fois.

Alors que le if et else a été déplacé dans loop, puisque l’on veut continuellement vérifier si le bouton est enfoncé.

Maintenant, on a que la lumière s’allume et s’éteint dès que l’on appuie ou relâche le bouton.

Introduction à Arduino

2019-03-01T00:00:00+00:00

Qu’est-ce qu’Arduino

The UNO is the best board to get started with electronics and coding. If this is your first experience tinkering with the platform, the UNO is the most robust board you can start playing with. The UNO is the most used and documented board of the whole Arduino family.

– Site officiel Arduino.cc

Il s’agit d’une carte comprenant un micro-contrôleur. La puce sur la carte est un petit ordinateur que l’on peut programmer. Il y a un port USB pour envoyer le code sur la puce et communiquer avec un ordinateur. Les pins sur le côté permettent d’avoir des entrées-sorties vers le vrai monde. On peut activer des lumières et des moteurs. On peut aussi lire les données envoyées par un capteur de distance à l’ultrason ou une photorésistante pour savoir s’il fait noir.

Introduction à la programmation

Un programme est une suite d’instructions exécutées les unes après les autres. On peut voir un programme comme une recette très précise pour réaliser des choses.

On pourrait vouloir donner la suite d’étape pour faire un sandwich au beurre d’arachides. On pourrait essayer de demander à l’ordinateur de faire:

Faire un sandwich au beurre d’arachide

Toutefois, l’ordinateur ne comprend pas comment faire cela. On devrait alors décrire les étapes de façon plus précises de façon à ce que l’ordinateur comprenne. On aurait alors:

Ouvrir le sac contenant le pain
Sortir une tranche de pain
Sortir le pot de beurre d’arachide de l’armoire
Sortir un couteau
Ouvrir le pot
Tartiner le pain avec le couteau
Sortir une seconde tranche de pain
Placer la tranche sur l’autre qui est déjà beurrée

Ouf ! C’est beaucoup d’étapes pour un simple sandwich. Pour programmer un robot, c’est très semblable. On ne peut pas dire au robot de:

Avancer pendant 10 secondes

Il faut plutôt lui dire:

Actionne les moteurs
Attendre 10 secondes
Arrête les moteurs

DEL et Arduino

DEL: Diode Électro Luminescente

En bref, une DEL est une lumière qui ne demande que très peu d’énergie. On peut donc l’alimenter directement depuis l’Arduino.

Si l’on applique une tension aux deux bornes de la DEL, elle s’allumera.

Une DEL a deux “pattes”. L’une d’elles est légèrement plus longue, il s’agit de la patte positive. L’autre est la négative. Lors du branchement, il faut faire attention de bien brancher la DEL.

Faire clignoter une DEL

On voudrait demander à l’Arduino de faire clignoter une la DEL deux fois en la laissant 2 secondes éteintes et 3 secondes allumées. En mots, on aurait:

Allumer la DEL
Attendre 3 secondes
Éteindre la DEL
Attendre 2 secondes
Allumer la DEL
Attendre 3 secondes
Éteindre la DEL

Télécharger Arduino

Il est maintenant temps d’essayer de demander à l’Arduino de faire ces étapes. Téléchargeons le logiciel depuis le site officiel d’Arduino.

On peut télécharger le ZIP ne demandant pas d’installation à cette adresse.

On peut maintenant lancer l’application.

Premiers pas en Arduino

On voit maintenant un code de base fournit par Arduino.

void setup() {
  // put your setup code here, to run once:

}

void loop() {
  // put your main code here, to run repeatedly:

}

setup est exécuté qu’une fois au démarrage de l’Arduino.

loop est ensuite exécuté continuellement.

Toutefois, avant de commencer à coder, branchons la DEL dans l’Arduino.

Dans le cadre de ce document, nous allons utiliser la pin numéro 13. Vous pouvez en choisir une autre si vous voulez. La longue patte doit être connectée dans la pin 13 et la courte au ground. Le ground est le 0 volt de référence de l’Arduino.

Pour empêcher de brûler la DEL, on place une résistance en série avec la DEL. La résistance doit être entre 220 et 280 Ohms. Elle peut être placée avant ou après la DEL.

Fonctions de base

Pour faire clignoter une DEL, on doit pouvoir être capable de l’allumer, de l’éteindre et d’attendre. Nous allons voir comment réaliser ces actions dans Arduino.

Configuration de la DEL

On doit indiquer à l’Arduino quelles pins on désire utiliser, dans notre cas il s’agit de la pin 13. On appelle alors la fonction suivante:

pinMode(13, OUTPUT);

OUTPUT signifie que l’on veut se servir de la pin comme d’une sortie, donc mettre une certaine tension à la pin plutôt que de lire la tension. On aurait pu utiliser INPUT pour initialiser la pin comme une entrée. Nous allons en voir une exemple par la suite.

Allumer la DEL

Pour allumer la DEL, on doit mettre une certaine tension aux bornes de la DEL. Comme la patte négative est branchée au ground, on doit appliquer un voltage positif à la patte branchée dans la pin 13. Pour ce faire, on utilise la fonction suivante:

digitalWrite(13, HIGH);

HIGH signifie une tension positive. Dans le cas d’une Arduino UNO, on met 5 volts sur la pin 13.

Éteindre la DEL

Pour l’éteindre, on procède de façon semblable.

digitalWrite(13, LOW);

Attendre

Pour attendre un certain temps, on utilise la fonction:

delay(1000);

Ici, 1000 représente le temps à attendre en millisecondes. On a qu’une seconde est 1000 ms. Par exemple, pour attendre 5 secondes, on devrait indiquer 5000 ms.

Mettre le tout ensemble

Reprenons la liste d’étapes à suivre pour faire clignoter notre DEL:

Allumer la DEL
Attendre 3 secondes
Éteindre le DEL
Attendre 2 secondes
Allumer la DEL
Attendre 3 secondes
Éteindre la DEL

On peut maintenant “traduire” chaque étape en code. Il manque toutefois l’initialisation de la pin au début. Avec les informations un peu plus haut, on peut maintenant coder notre Arduino.

void setup() 
{
  pinMode(13, OUTPUT);     // 0. On dit a l'Arduino que l'on réserve la pin 13
  digitalWrite(13, HIGH);  // 1. Allumer la DEL
  delay(3000);             // 2. Attendre 3 secondes
  digitalWrite(13, LOW);   // 3. Éteindre le DEL
  delay(2000);             // 4. Attendre 2 secondes
  digitalWrite(13, HIGH);  // 5. Allumer la DEL
  delay(3000);             // 6. Attendre 3 secondes
  digitalWrite(13, LOW);   // 7. Éteindre le DEL
}

void loop() 
{

}

On peut maintenant connecter l’Arduino par USB à l’ordinateur.

On doit premièrement vérifier que l’Aduino est connectée dans Outils -> Port. Il faut s’assurer que le port selectionné est bien celui de l’Arduino.

On peut envoyer le code sur l’Arduino avec le bouton “Téléverser” (la flèche vers la droite). Après un certain temps, l’Arduino devrait faire clignoter la DEL deux fois selon les délais définit.

À l’infini

Et si on désirait faire clignoter le DEL à l’infini? Il faudrait demander à l’Arduino de la faire clignoter pleins de fois. On pourrait avoir:

void setup() 
{
  pinMode(13, OUTPUT);     // 0. On dit a l'Arduino que l'on réserve la pin 13
  digitalWrite(13, HIGH);  // 1. Allumer la DEL
  delay(3000);             // 2. Attendre 3 secondes
  digitalWrite(13, LOW);   // 3. Éteindre le DEL
  delay(2000);             // 4. Attendre 2 secondes
  digitalWrite(13, HIGH);  // 5. Allumer la DEL
  delay(3000);             // 6. Attendre 3 secondes
  digitalWrite(13, LOW);   // 7. Éteindre le DEL
  //
  digitalWrite(13, HIGH);  
  delay(3000);             
  digitalWrite(13, LOW); 
  delay(2000);             
  digitalWrite(13, HIGH);  
  delay(3000);           
  digitalWrite(13, LOW);   
  //
  digitalWrite(13, HIGH);  
  delay(3000);             
  digitalWrite(13, LOW); 
  delay(2000);             
  digitalWrite(13, HIGH);  
  delay(3000);           
  digitalWrite(13, LOW);   
  //
  digitalWrite(13, HIGH);  
  delay(3000);             
  digitalWrite(13, LOW); 
  delay(2000);             
  digitalWrite(13, HIGH);  
  delay(3000);           
  digitalWrite(13, LOW);   
  //....
}

void loop() 
{

}

Et on devrait continuer ainsi pendant longtemps… Heureusement, il y a une meilleure façon !

La fonction loop est exécutée continuellement après setup, il suffit donc d’avoir le code suivant:

void setup() 
{
  pinMode(13, OUTPUT);     // 0. On dit a l'Arduino que l'on réserve la pin 13
}

void loop() 
{
  digitalWrite(13, HIGH);  // 1. Allumer la DEL
  delay(3000);             // 2. Attendre 3 secondes
  digitalWrite(13, LOW);   // 3. Éteindre le DEL
  delay(2000);             // 4. Attendre 2 secondes
}

On a donc que la lumière s’allume pour 3 secondes, et s’éteint pendant 3 secondes à l’infini. On remarque qu’il y a moins de code copier-collé !

Stacks

2019-02-15T00:00:00+00:00

Stacks are very much like a stack of plates. When you don’t want to do the dishes, you simply push the dirty plate on top of the others. Whereas when you are washing them, you take to plate on the top of the stack and proceed to pop them all.

In the same way, the stack abstract data type allows you to push and pop elements on the top of the stack.^[1]

We can see a stack as a bottle, you can only access the content from the top.

Since the last element pushed on the stack is the first one to be popped, we say that the stack is a last in, first out (LIFO) data structure.

We can define our stack in an imperative manner. Each operation modifies a stack instance.

We could also define the stack in a functional manner. The operations applied to the stack is viewed as a mathematical function that maps the old state to the new state. Refer to the example below for more information.

Imperative Definitions

An imperative stack has two essential operations:

Operation	Description
$\text{Push}(S, x)$	Add the element $x$ on the stack $S$
$\text{Pop}(S)$	Remove the most recently added element to $S$ and return it

We can add non-essential operations to ease programming. We note the non-essential operations:

Operation	Description
$\text{Peek}(S)$	Return the most recently added element in $S$ without removing it
$\text{Create}()$	Create a new Stack
$\text{IsEmpty}(S)$	Return a Boolean value specifying if the stack $S$ is empty

As $\text{Peek}(S)$ can be defined in terms of $\text{Push}$ and $\text{Pop}$, we say that this operation is non-essential.

In pseudo code (Python), we could define $\text{Peek}$ as:

def peek(S):
    top_value = pop(S)
    push(S, top_value)
    return top_value

Imperative Implementations

Stack ADT in C

For simplicity, the stack is implemented with an array, but it could be implemented using a linked list.

// stack.h
#ifndef STACK_H
#define STACK_H

#include <stdlib.h>

typedef struct stack_rep stack_rep;
typedef stack_rep *stack_t;
typedef void *stack_item_t;


stack_t stack_create(unsigned int size);

void stack_free(stack_t s);

void stack_push(stack_t s, stack_item_t x);

stack_item_t stack_pop(stack_t s);

stack_item_t stack_peek(stack_t s);

int stack_empty(stack_t s);

#endif //STACK_H

// stack.c
#include "stack.h"

struct stack_rep {
    unsigned int top;
    unsigned int size;
    stack_item_t *elements;
};

stack_t stack_create(unsigned int size) {
    stack_t s = malloc(sizeof(struct stack_rep));
    s->top = 0;
    s->size = size;
    s->elements = malloc(size * sizeof(stack_item_t));
    return s;
}

void stack_free(stack_t s) {
    if (s) {
        free(s->elements);
        free(s);
    }
}

void stack_push(stack_t s, stack_item_t x) {
    if (s->top < s->size) {
        s->elements[s->top] = x;
        s->top++;
    }
}

stack_item_t stack_pop(stack_t s) {
    if (!stack_empty(s))
        s->top--;
}

stack_item_t stack_peek(stack_t s) {
    if (!stack_empty(s))
        return s->elements[s->top - 1];
    else
        return NULL;
}

int stack_empty(stack_t s) {
    return s->top == 0;
}

// main.c
#include <stdio.h>

#include "stack.h"

int main() {
    stack_t stack = stack_create(4);

    const int numValue = 4;
    int values[] = {1, 2, 3, 4};

    printf("Is stack empty: %s\n", stack_empty(stack) ? "true" : "false");

    for (int i = 0; i < numValue; ++i) {
        printf("Pushing: %d\n", values[i]);
        stack_push(stack, values + i);
    }

    printf("Is stack empty: %s\n", stack_empty(stack) ? "true" : "false");

    for (int i = 0; i < numValue; ++i) {
        int popped = *(int*)stack_peek(stack);
        printf("Popping: %d\n", popped);
        stack_pop(stack);
    }

    printf("Is stack empty: %s\n", stack_empty(stack) ? "true" : "false");

    stack_free(stack);
    return 0;
}

Note that from the user point of view, stack_t is completely opaque to the user. Only stack.c knows the inner representation of stack_t, since we only declared stack_t in stack.h.

We could completely change the implementation detail and nothing would change from the user point of view.

Notice that we pass the stack to the function so that they know on which instance work. This is akin to Python self.

class ValuePrinter:
    def __init__(self, value):
        self.value = value

    def print_value(self):
        print(self.value)

The self argument is passed automatically to the object when calling the function on the instance. Both lines are equivalents.

vp = ValuePrinter(42)
vp.print_value()  # prints 42
ValuePrinter.print_value(vp)  # prints 42 too

Note that the two statements are equivalent because we know that print_value is not overridden. That way we are sure that vp.print_value() is equivalent to ValuePrinter.print_value(vp).

Object Oriented Stack in Java

// Stack.java
package io.github.willguimont;

public interface Stack<T> {

    class FullStackException extends RuntimeException {

    }

    class EmptyStackException extends RuntimeException {

    }

    void push(T element);

    void pop();

    T peek();

    boolean isEmpty();
}

// StackArray.java
package io.github.willguimont;

public class StackArray<T> implements Stack<T> {

    private Object[] elements;
    int top;
    int size;

    public StackArray(int size) {
        elements = new Object[size];
        top = 0;
        this.size = size;
    }

    @Override
    public void push(T element) {
        if (top < size) {
            elements[top] = element;
            top++;
        } else
            throw new FullStackException();
    }

    @Override
    public void pop() {
        if (isEmpty())
            throw new EmptyStackException();
        top--;
    }

    @Override
    public T peek() {
        if (isEmpty())
            throw new EmptyStackException();
        else
            return (T) elements[top - 1];
    }

    @Override
    public boolean isEmpty() {
        return top == 0;
    }
}

// StackList.java
package io.github.willguimont;

import java.util.LinkedList;
import java.util.List;

public class StackList<T> implements Stack<T> {

    private List<T> elements;
    private int size;

    public StackList() {
        elements = new LinkedList<>();
    }

    @Override
    public void push(T element) {
        elements.add(element);
        size++;
    }

    @Override
    public void pop() {
        if (isEmpty())
            throw new EmptyStackException();
        elements.remove(size - 1);
        size--;
    }

    @Override
    public T peek() {
        if (isEmpty())
            throw new EmptyStackException();
        else
            return elements.get(elements.size() - 1);
    }

    @Override
    public boolean isEmpty() {
        return elements.isEmpty();
    }
}

// Main.java
import io.github.willguimont.*;

public class Main {

    public static void main(String[] args) {
        // Both work
        //Stack<Integer> stack = new StackArray<Integer>(10);
        Stack<Integer> stack = new StackList<>();

        int[] values = {1, 2, 3, 4};

        System.out.println("Is stack empty: " + stack.isEmpty());

        for (int i = 0; i < values.length; ++i) {
            System.out.println("Pushing value: " + values[i]);
            stack.push(values[i]);
        }

        System.out.println("Is stack empty: " + stack.isEmpty());

        for (int i = 0; i < values.length; ++i) {
            int value = stack.peek();
            System.out.println("Popping value: " + value);
            stack.pop();
        }

        System.out.println("Is stack empty: " + stack.isEmpty());
    }
}

Note how easy it is to add new represents of the stack. This is one of the strong points of object-oriented programming compared to ADT.

Here the stack is defined with an interface that differs from the way we defined stack_t in C. stack_t is an opaque type that only the operations know the inner details, whereas the interface declares the methods a stack has to implement.

For more information on the comparison of ADT and object, see Introduction to Abstract Data Types.

Functional Definitions

On the contrary to the imperative stack, a functional implementation doesn’t mutate the state of the stack. Instead, the operations are seen as mathematical functions that map from the old state to the new frame.

Much like a function $ f(x) = x^{2} $ that maps a value $x$ to its square. The initial value of $x$ stays unchanged.

In a functional paradigm, we need three operations to fully define a stack.

$\text{Push}(S, x)$: Returns a new stack with an element $x$ pushed on top of $S$

$\text{Pop}(S)$: Return the stack $S$ without its first element

$\text{Top}(S)$: Returns the value on top of $S$

Note that we don’t need a $\text{Create}$ operation because there is no instance. Instead, we define a special state $\Lambda$ (or empty) that represents the empty state.

Also note that we don’t need an $\text{isEmpty}$ operation either, because we can simply test the equality to $\Lambda$.

Functional Implementations in Haskell

This bit of code is adapted from haskell.org^[2].

-- stack.hs
module Stack (Stack, empty, isEmpty, push, top, pop) where
 
empty :: Stack a
isEmpty :: Stack a -> Bool
push :: a -> Stack a -> Stack a
top :: Stack a -> a
pop :: Stack a -> (a,Stack a)
    
newtype Stack a = StackImpl [a]

empty = StackImpl []
isEmpty (StackImpl s) = null s
push x (StackImpl s) = StackImpl (x:s)
top (StackImpl s) = head s
pop (StackImpl (s:ss)) = (s,StackImpl ss)

-- main.hs
import Stack
import Control.Monad (unless)

printStack :: (Show a) => Stack a -> IO()
printStack x = unless (isEmpty x) $ do
    let (a, s) = pop x
    print a
    printStack s

main :: IO()
main = do
    let stack = foldl (flip push) empty [1, 2, 3, 4]
    printStack stack

Note here that this code is much shorter and that the stacks aren’t mutated, instead, the functions return a new stack each time.

Summary

Stacks are an elementary data structure. They are fundamentals in computer science. We note their uses in multiples places such as solving sudokus using backtracking algorithms, recursion, converting equations to reverse Polish notation and much more. We even see stacks used in how CPUs handle subroutines. They truly are fundamental to the computer science field, from the theoretical to the practical.

References

Thomas H. Cormen et al. Introduction to Algorithms. 2009. ↩
Haskell org. Abstract Data Types. 2014. ↩

Introduction to Abstract Data Types

2019-01-27T00:00:00+00:00

The proposition of abstract data types by Liskov and Zilles is an important step in the way we build computer software. Abstract data types allow programmers to leverage the power of abstraction. By hiding implementation details, they allow programmers to use a structure by only being concerned about their behaviors and not how the structure works inside.

This gives programmers tools to think at a higher level, focused on the problem to solve.

History

Abstract data types (ADT) were proposed in 1974 by, 2008 Turing Award winner, Barbara Liskov and her coauthor Stephen Zilles in the paper Programming with abstract data types^[1]. This paper wasn’t only a theoretical paper, they implemented the concept in a programming language. Liskov and her students created the programming language CLU that included abstract data types. ADTs are often seen as a step in the development of object-oriented programming.

ADTs were proposed in the 70s, around the time when the term software crisis was coined. People wanted to build sophisticated software programs but didn’t know how to build them effectively. Projects often ran over-budget, over-time, and the resulting software was often unmanageable, hard to maintain, and of low quality.

It was around that time that the use of the Go To statement was still controversial. Dijkstra wrote Go To Statement Considered Harmful^[2] in 1968. At that time, the use of Go To statements was widespread, which led to hard to debug and maintain codes.

The only kind of abstraction commonly used was procedures that weren’t necessarily used for abstraction per see but save space. If a bit of code was called often, they’d factor it out in a procedure, but not necessarily in a logical module. ^[3]

Moreover, languages like Algol60 used global variables for the communication between modules, which led to spaghetti code when scaling up. ^[3]

The landscape of software programming was a bit messy, people were building software programs in a non-structured manner.

The ideas discussed in Liskov & Zilles’s paper may seem obvious now but remember the time when they were proposed. In the last 50 years of building software programs, we learned a lot. This concept paved the way for object-oriented programming and better software design.

Definitions

ADT

Liskov & Zilles describe ADT as following:

An abstract data type defines a class of abstract objects which is completely characterized by the operations available on those objects. This means that an abstract data type can be defined by defining the characterizing operations for that type. […] Implementation information, such as how the object is represented in storage, is only needed when defining how the characterizing operations are to be implemented. The user of the object is not required to know or supply this information.

– Liskov & Zilles^[1]

We learn from the definition that an ADT defines a type and a set of operations. From the perspective of the user, the type is completely opaque, meaning we can’t see the inner representation of the data it contains.

The type is completely opaque from outside of its operations. This contributes to build abstraction. For the user, the type is nothing particular, he has to use the operations.

If we want to have multiple representations for an ADT, the operations need to be aware of them. Adding a new representation in an ADT is therefore costly, we need to modify the existing operations. We will discuss later the implications of that fact.

We can observe two categories of operations: essentials and non-essential. Basically, non-essential can be defined from essential operations. We will see an example later in this article.

Abstraction

Liskov & Zilles describe abstraction:

What we desire from an abstraction is a mechanism which permits the expression of relevant details and the suppression of irrelevant details.

– Liskov & Zilles^[1]

This allows programmers to use complex objects by being only concerned by their behaviors and not how they are implemented. This helps to have a higher level of reasoning, we can solve the problem using abstraction, then solve the subproblems that are those abstractions. This allows splitting the source code in logical modules, thus improving code reusability. We also separate the level of abstraction, the high-level code isn’t polluted by low-level details, therefore improving code readability.

As Robert C. Martin said in Clean Code:

Mixing levels of abstraction within a function is always confusing. Readers may not be able to tell whether a particular expression is an essential concept or a detail.

– Robert C. Martin^[4]

A small example

To make it concrete, here a simple example.

Abstract data types are like the built-in types of a programming language. When a programmer uses the type Integer of a programming language, he’s usually not concerned about the binary representation of the integer, i.e. a string of bits. He thinks about the Integer and the operations related to it as indivisible and atomic, when in fact they can be translated to multiple machine instructions. We define the operations on Integer by their behaviors. We expect (+) to add two Integer and (*) to multiply them, but we’re usually not concerned about how those operations are made under the hood. Abstract data types bring that idea of abstraction to user-defined structures. The client code can use those structures “as-is”, much like Integers, without knowing the implementation details.

However, the abstraction is not perfect for most types. In the case of Integer, we may be interested in knowing if an overflow happened. The overflow depends on the implementation. A 32 bits Integer will overflow at a lower value than 64 bits one. More generally, most built-in types are not perfect abstraction because, in practice, we need to know when the implementation fails to represent the data.

Computational complexity and ADT

In a more practical context, we consider that the behavior of the object isn’t enough to characterize completely the type. Let’s imagine we have two implementations of the Stack ADT (see example below). In the first implementation, the push operation is done in $$O(1)$$. The second one was written poorly and the push operation is done in $$O(n!)$$. From a behavioral perspective, both are equivalent. They both correctly implement the expected behavior of a Stack, but in a real software program, it would be better to use the first implementation. That’s the reason why some authors include the complexity of the operations as well in the definition of abstract data types.

Simple examples

The Stack is an example of an abstract data type. We can define the behavior of a stack by giving it two operations.

Push: Add an element on the stack

Pop: Remove the most recently added element and return it

With those two operations, we can completely define the Stack. We note that those two operations are essential to a stack to effectively be a stack. We can derive other operations from those two. We can, for example, define the Peek operator from a pop followed by a push and then returning the value that was popped. Peek isn’t essential because it can be derived from other operations.

Differences with object-oriented programming

To help demonstrate the differences and trade-offs between object-oriented programming and abstract data type. Here is an adapted version of the Shape example from chapter 6 of Clean Code of Robert C. Martin^[4]

Procedural Shape (modified)

public class Geometry {
    public final double PI = 3.141592653589793;

    public class Square {
        private Point topLeft;
        private double side;
    }

    public class Rectangle {
        private Point topLeft;
        private double height;
        private double width;
    }

    public class Circle {
        private Point center;
        private double radius;
    }

    public Square createSquare(Point topLeft, double side) {
        Square s = new Square();
        s.topLeft = topLeft;
        s.side = side;
        return s;
    }

    public Rectangle createRectangle(Point topLeft, double height, double width) {
        Rectangle r = new Rectangle();
        r.topLeft = topLeft;
        r.height = height;
        r.width = width;
        return r;
    }

    public Circle createCircle(Point center, double radius) {
        Circle c = new Circle();
        c.center = center;
        c.radius = radius;
        return c;
    }

    public double area(Object shape) throws NoSuchShapeException
    {
        if (shape instanceof Square) {
            Square s = (Square)shape;
            return s.side * s.side;
        }
        else if (shape instanceof Rectangle) {
            Rectangle r = (Rectangle)shape;
            return r.height * r.width;
        }
        else if (shape instanceof Circle) {
            Circle c = (Circle)shape;
            return PI * c.radius * c.radius;
        }
        throw new NoSuchShapeException();
    }
}

Firstly, we notice that outside of the class Geometry; Square, Rectangle and Circle are completely opaque. This hides the implementation details of the shapes.

We also notice that if we want to add a new shape, we have to modify all the operations of the Geometry class. Here, we would need to add another clause to handle the new kind of shape.

On the contrary, if we wanted to add an operation, we would only need to add a method. The types of shape don’t need to change. The process of adding operations is additive, meaning we do not have to modify existing code.

Polymorphic shapes

public interface Shape {
    double area();
}

public class Square implements Shape {
    private Point topLeft;
    private double side;

    public double area() {
        return side*side;
    }
}

public class Rectangle implements Shape {
    private Point topLeft;
    private double height;
    private double width;

    public double area() {
        return height * width;
    }
}

public class Circle implements Shape {
    private Point center;
    private double radius;
    public final double PI = 3.141592653589793;

    public double area() {
        return PI * radius * radius;
    }
}

Here, we notice that if we want to add a new type of shape, we don’t have to modify anything, the process is purely additive. We create a new class that implements Shape and that’s it.

On the other side, if we want to add an operation to Shape, we would need to modify all existing classes that implement Shape.

ADT and OOP

Briefly, we can say that it is easy to add operations on ADT without modifying the existing structure. On the other hand, object-oriented code makes it easy to add new representation without modifying existing operations. ^[4]

Another way to say it: ADTs make it difficult to add new structures because we would need to modify all existing operations. OO code makes it difficult to add new operations because we would need to modify all existing classes. ^[4]

OO and ADT are complementary concepts. Sometimes we want to be able to easily add new representation while other times we want to be able to add operation at our heart’s content. Not everything is an object.

Advantages of ADT

ADT allows abstraction. As stated above, abstraction allows the programmer to think at a higher level, using tools to solve his problems without being embarrassed by the implementation details. This is achieved by hiding implementation details behind an opaque type. This allows separating the level of abstractions. High-level operations are not punctuated of low-level operations that hinder the understanding of the code.

Moreover, ADTs allow the implementation to change without changing the calling code because the interface is kept secret. This allows the user code to be protected against changes in the implementation because they are hidden behind a fixed interface.

Another implementation of the ADT can be used interchangeably because of their characterizing behaviors. This allows for performance increase when some implementations are faster in some situations without having to rewrite the client code.

As stated above, ADTs make it easy to add new operations on a type. In a context where the number of representations won’t change, but you will often add operations, ADTs are preferable to object.

Summary

In this article, we discussed the concept of an abstract data type. They are an important historical step in the way we build software programs. They are complementary to object in the way they make it easy to add operation while objects make it easy to add new representation.

References

Liskov, Barbara & Zilles, Stephen. Programming with Abstract Data Types. 1974. ↩ ↩2 ↩3
Edsger W. Dijkstra. Go To Statement Considered Harmful. 1968. ↩
Barbara Liskov. Keynote: The Power of Abstraction. 2013. ↩ ↩2
Robert C. Martin. Clean Code. 2008. ↩ ↩2 ↩3 ↩4

wigum::website - Computer Sciences

Recovering Windows After Wiping GRUB for Limine

What Actually Broke

Disk Layout

Step 1: Configure Limine

Step 2: Copy the EFI Files from the Windows Partition

Step 3: Rebuild the BCD with bcdboot

SilvaScenes

Docker Workshop

Setup

Instructions

Solutions

Docker

Why containerization?

What is containerization?

Containers manually

Docker basics

Exercise 01 – Running a prebuilt image

Exercise 02 – Container management

Exercise 03 – Inspecting a running container

Exercise 04 – PostgreSQL database

Dockerfile

Exercise 05 – Haskell service Dockerfile

Exercise 06 – Python application Dockerfile

Advanced Docker

Multi-stage image builds

Exercise 07 – Rust multi-stage build

Volumes and bind mounts

Extras

Cleanup

Docker Compose

Podman

Kubernetes

Bash Workshop

Setup

Instructions

Solutions

Introduction to Bash

The command line and the manual

Exercise 01 – Basic commands

Exercise 02 – File system navigation

Exercise 03 – home directory and copy

Exercise 04 – Permissions

Exercise 05 – Wildcards

Exercise 06 – Deleting files and folders

Exercise 07 – Basic scripting

Advanced commands

Exercise 08 – Advanced commands

Exercise 09 – Advanced commands 1

Exercise 10 – Advanced commands 2

Exercise 11 – Advanced commands 3

Program composition

Composition

Pipes

Redirection

Standard input, output, and errors

Exercise 12 – Piping and redirection

Exercise 13 – File sizes

Exercise 14 – Data analysis

Scripting

Quoting variables

Exercise 15 – Test script

Exercise 16 – Version rollback script

Extras

.bashrc file

Prompt customization

Safety & quality of life options

Functions

PATH

Alias git

Element of Errors Handling

errno of Our Ways (C)

Trying to Catch Lightning in a Bottle Exceptions (Java and Friends)

What Java’s throws Wanted to Be (Swift)

C++ and RAII

Going Somewhere with Errors (Go)

Zig

Odin

Playing Tag with Errors (Rust)

Riding the Happy Rails (F# / Elm)

Exercise 03 – `home` directory and copy

`.bashrc` file

`PATH`

`errno` of Our Ways (C)

`Try`ing to `Catch` Lightning in a Bottle Exceptions (Java and Friends)

What Java’s `throws` Wanted to Be (Swift)

`C++` and RAII

`Go`ing Somewhere with Errors (Go)

Trust, but verify `assert` (D)