digitalsignalperson

#!/usr/bin/env bash
set -euo pipefail

# Walk up from CWD looking for .uw
find_uw_root() {
    local dir="$PWD"
    while [[ "$dir" != "/" ]]; do
        if [[ -f "$dir/.uw" ]]; then
            echo "$dir"
            return 0

digitalsignalperson

Disclaimer: Written by claude to turn my local projects structure into a short guide.

I also pointed it to mention the discussion from this issue astral-sh/uv#17351, as I was looking for a way to have nested projects with their own uv.lock and be be able to independently uv sync --frozen in the inner projects, while still having the convenience of an outer workspace containing everything. Another solution that seems ok is to make a sibling meta-package that acts as the workspace, using path sources to include all the sibling packages in one place.

The result:

uv Workspaces for Multi-Package Python Repos

A uv workspace lets you develop multiple Python packages in one repo with a single

digitalsignalperson

//------------------------------------------------------------------------------
//  imgui-endpoint-viewer-sapp.cc
//------------------------------------------------------------------------------
#include "sokol_app.h"
#include "sokol_gfx.h"
#include "sokol_log.h"
#include "sokol_glue.h"
#include "sokol_fetch.h"
#include "imgui.h"
#include "implot.h"

digitalsignalperson

#!/bin/bash

cleanup(){
  [[ -n $1 ]] && rm -f "$1"
}

tempfile=$(mktemp -t screenshot-XXXXXX.png)
trap "cleanup '$tempfile'" EXIT

spectacle --fullscreen --background --nonotify --output "$tempfile" &

digitalsignalperson

// toggle visibility with `kill -USR1 $(cat /tmp/casilda-tty.pid)` (assign this as the cmdline for a global hotkey)

#include "gtk4-layer-shell.h"
#include <gtk/gtk.h>
#include "casilda-compositor.h" // https://gitlab.gnome.org/jpu/casilda
#include <unistd.h>
#include <glib-unix.h>

GtkWidget *window;
#define TTY_SOCKET "/tmp/casilda-tty.sock"

digitalsignalperson

#!/bin/python
import os
import json

vault_path = "/mnt/0/obsidian/andy"  # <--- SET THIS TO YOUR VAULT PATH
output_path = os.path.join(vault_path, "bookmarks.md")  # <--- SET TO OUTPUT MARKDOWN FILE
format_as_list = False  # <--- set to True or False to change output format


bookmarks_path = os.path.join(vault_path, ".obsidian/bookmarks.json")

digitalsignalperson

.tabbrowser-tab {
    max-width: none !important;
    --tab-min-height: 0px;
    --inline-tab-padding: 0px;
    border: 1px solid var(--tab-selected-bgcolor) !important;
}

sidebar-main[expanded] div#vertical-tabs {
    width: 300px !important;
    max-width: none !important;

digitalsignalperson

[Unit]
Description=my service

[Service]
Restart=always
RestartSec=10
ExecStart=
Environment="ALERT_PATH=/home/asdf/%N-failure"
ExecStopPost=/bin/bash -c '\
    echo $$SERVICE_RESULT, $$EXIT_CODE, $$EXIT_STATUS | logger; \

digitalsignalperson

ref openzfs/zfs#12580

Here's a script showing the predictability of this post-mount extra data that is created. When the previous snapshot contained 1024 files, the extra data written after mounting the received snapshot is proportional to this. Taking a snapshot of this extra data shows ~1024 "OBJECT" and ~1024 "FREE" lines in the zstream dump, with the raw data for the objects all starting with "ZP/"

Side-note: I also note that immediately after creating any dataset, the "written" is non-zero, a similar effect to this post-receive data?

diff_similarity() {

digitalsignalperson

#!/bin/bash

VMNAME=arch-zfs-test

vm_bash() { incus exec $VMNAME -- bash "$@"; }
vm_exec() { incus exec $VMNAME -- "$@"; }
vm_wait() { until vm_exec true; do sleep 1; done; }
vm_start() { incus start $VMNAME; }
vm_console() { incus console $VMNAME --type vga; }
vm_status() { incus info $VMNAME | grep "^Status: " | awk '{ print $2 }'; }