https://generalistprogrammer.com/tutorials/php-traits-complete-guide

Thinking out loud… tell me if I’m wrong.

I’m mulling the idea of using Traits to compose static classes with no state.

The static class would act as a Facade. It could implement an Interface.

The static class would be paired with a state object, which could contain all the state. This pairing would allow a clean separation of data from algorithms.

The Traits would contain no state. State, or portions of state, are passed in as parameters to methods.

Maybe it would be possible to create no-state objects, to allow for class-based dispatch (a kind of polymorphism).

Notebooking

This is the first draft. It worked, but it it useful?

<?php

interface AnimalInterface {
    static function sayHello(Animal $a);
    static function doPoo(Animal $a);
    static function doEat(Animal $a);
}

class Animal implements AnimalInterface {
  use Speak;
  use Poop;
  use Eat;
}

trait Speak {
    static function sayHello(Animal $a) 
    {
        echo 'Says: ' . $a->speech . "\n";
    }
}

trait Poop {
    static function doPoo(Animal $a)
    {
        echo 'Defecates: ' . $a->defecate . "\n";
    }
}

trait Eat {
    static function doEat(Animal $a)
    {
        echo 'Eats: ' . $a->food . "\n";
    }
}

class AnimalState {
    public $state = [];

    function init() 
    {
        $this->state['dog'] = new Dog();
        $this->state['cat'] = new Cat();
        $this->state['bird'] = new Bird();
    }
}

class Dog extends Animal {
    public readonly string $speech;
    public readonly string $defecate;
    public readonly string $food;
    public readonly int $age;

    function __construct($age = 1) 
    {
        $this->speech = 'woof';
        $this->defecate = 'dog loaf';
        $this->food = 'kibble';
        $this->age = $age;
    }
}

class Cat extends Animal {
    public readonly string $speech;
    public readonly string $defecate;
    public readonly string $food;
    public readonly int $age;

    function __construct($age = 1) 
    {
        $this->speech = 'mew';
        $this->defecate = 'hairpoo';
        $this->food = 'tuna';
        $this->age = $age;
    }
}

class Bird extends Animal {
    public readonly string $speech;
    public readonly string $defecate;
    public readonly string $food;
    public readonly int $age;

    function __construct($age = 1) 
    {
        $this->speech = 'chirp';
        $this->defecate = 'birdstool';
        $this->food = 'millet';
        $this->age = $age;
    }
}

$s = new AnimalState();
$s->init();

echo "\ndog\n";
Animal::sayHello( $s->state['dog'] );
Animal::doPoo( $s->state['dog'] );
Animal::doEat( $s->state['dog'] );
echo "\ncat\n";
Animal::sayHello( $s->state['cat'] );
Animal::doPoo( $s->state['cat'] );
Animal::doEat( $s->state['cat'] );
echo "\nbird\n";
Animal::sayHello( $s->state['bird'] );
Animal::doPoo( $s->state['bird'] );
Animal::doEat( $s->state['bird'] );

// we create a new bird to replace the old one
$s->state['bird'] = new Bird(5);

echo "\nthe new bird has age: " . $s->state['bird']->age . "\n\n";

var_dump($s);

<?php

interface AnimalInterface {
    static function sayHello(Animal $a);
    static function doPoo(Animal $a);
    static function doEat(Animal $a);
}

class Animal implements AnimalInterface {
  use Speak;
  use Poop;
  use Eat;
}

trait Speak {
    static function sayHello(Animal $a) 
    {
        echo 'Says: ' . $a->speech . "\n";
    }
}

trait Poop {
    static function doPoo(Animal $a)
    {
        echo 'Defecates: ' . $a->defecate . "\n";
    }
}

trait Eat {
    static function doEat(Animal $a)
    {
        echo 'Eats: ' . $a->food . "\n";
    }
}

class AnimalState {
    public $state = [];

    function init() 
    {
        $this->state['dog'] = new Dog();
        $this->state['cat'] = new Cat();
        $this->state['bird'] = new Bird();
    }
}

class Dog extends Animal {
    public readonly string $speech;
    public readonly string $defecate;
    public readonly string $food;
    public readonly int $age;

    function __construct($age = 1) 
    {
        $this->speech = 'woof';
        $this->defecate = 'dog loaf';
        $this->food = 'kibble';
        $this->age = $age;
    }
}

class Cat extends Animal {
    public readonly string $speech;
    public readonly string $defecate;
    public readonly string $food;
    public readonly int $age;

    function __construct($age = 1) 
    {
        $this->speech = 'mew';
        $this->defecate = 'hairpoo';
        $this->food = 'tuna';
        $this->age = $age;
    }
}

class Bird extends Animal {
    public readonly string $speech;
    public readonly string $defecate;
    public readonly string $food;
    public readonly int $age;

    function __construct($age = 1) 
    {
        $this->speech = 'chirp';
        $this->defecate = 'birdstool';
        $this->food = 'millet';
        $this->age = $age;
    }
}

$s = new AnimalState();
$s->init();

echo "\ndog\n";
Animal::sayHello( $s->state['dog'] );
Animal::doPoo( $s->state['dog'] );
Animal::doEat( $s->state['dog'] );
echo "\ncat\n";
Animal::sayHello( $s->state['cat'] );
Animal::doPoo( $s->state['cat'] );
Animal::doEat( $s->state['cat'] );
echo "\nbird\n";
Animal::sayHello( $s->state['bird'] );
Animal::doPoo( $s->state['bird'] );
Animal::doEat( $s->state['bird'] );

// we create a new bird to replace the old one
$s->state['bird'] = new Bird(5);

echo "\nthe new bird has age: " . $s->state['bird']->age . "\n\n";

var_dump($s);

This code has interesting qualities.

First, the AnimalState is the only thing that holds state.

Everything else doesn’t hold state.

The Dog, Cat, and Bird types are stateful classes, and instantiated, but aren’t mutable. All the properties are readonly.

Look at line 109. I cannot set the value of $age, because it’s readonly, but I can initialize a new Bird of 5 years old. Some languages also have this restriction, where named values are immutable.

Method names and property names matter. For all the parts to work, they must conform. The AnimalInterface enforces the method names. Nothing enforces the property names.

Is it useful? I’m not sure. It’s a lot of extra boilerplate.

What’s Missing?

PHP 8.3.6 doesn’t support public readonly protected(set). If it did, I think I could move the variable declarations up into Animal, and it would act like a contract for the subclasses.

I tried moving the properties like $speech into the Trait (rather than in the Class like it is above). It linted with php -l, failed with phpstan, and didn’t run. It refused to initialize the $speech property from the Trait because it was out of the Dog scope.

Here’s the json_encode($s) output:

{
    \"state\": {
        \"dog\": {
            \"speech\": \"woof\",
            \"defecate\": \"dog loaf\",
            \"food\": \"kibble\",
            \"age\": 1
        },
        \"cat\": {
            \"speech\": \"mew\",
            \"defecate\": \"hairpoo\",
            \"food\": \"tuna\",
            \"age\": 1
        },
        \"bird\": {
            \"speech\": \"chirp\",
            \"defecate\": \"birdstool\",
            \"food\": \"millet\",
            \"age\": 5
        }
    }
}

It’s OK, but it needs a _class property so it can rehydrate correctly (which is easy to add).

$s->state['bird']->age = 100; // this code passes php’s lint, but it’s a bug.

Ideally, this bug would be caught at compile time, because assigning a value to a readonly property throws an error when run.

I found this good post about PHP linters.

phpstan found the bug with –level 3.

(I tried installing psalm, but my PHP version was too low.)

More Thinking

In a real-world scenario, you would probably have a more elaborate state structure of nested arrays, terminating in these read-only objects, or arrays of read-only objects.

Your application would be a bunch of Interfaces and implementation, read-only objects, and some logic to make the app happen.

I think you’d have lots of code like this:

$s->state['x']['y']['z'] = 
    SomeService::doAThingTo( $s->state['x']['y']['z'] );

You’d have that mixed in with a lot of traditional logic.

You’d write functions to manipulate the state yourself.

Some things could get easy, like saving the app state with each request: use a flatter namespace, and save it to Redis. (Examples: ‘config’, ‘app’, ‘user’, ‘documents’.)

Retrieve the state from Redis. Add a feature to lazy-load the data, and write subsets of the state.

AnimalState doesn’t need to be initialized with objects. It’s just an array. It should probably use magic methods to allow $s->dog to return the Dog object.

Setter magic methods could verify that the new value is of the same class as the old value; so a Dog object must be replaced with another Dog object.

DocBlocks might be able to add a type annotation, but I don’t know if it would be honored.

Magic getters could map a key like ‘dog’ to a property named ‘_dog’, which has a type signature that phpstan might recognize. The magic getter should be coded up with a switch statement rather than doing string mangling and isset().

Example:

public readonly Dog $_dog;

function __get($key): Animal
{
    switch($key) {
        case 'dog': return $this->_dog;
        default: // some error situation, die nicely
    }
}

The robot overlords can understand that code path, and won’t need to “reason” about some string mangling code like this (code not checked):

public $state;
...
function __get($key): object 
{
    $kkey = "_$key";
    if (isset($this->state[$kkey])) {
        return $this->state[$kkey];
    } else {
       // die politely
    }
}

I realize the latter is more general, but that begs the question: should everything be generalized and flexible at runtime, even if it’s the thing holding the application state?

The answer in 2026 is “no”.

The post PHP Traits first appeared on 🍙.

1. Don’t have the recipe. It was B-. I really liked it.

Recipe for Falafel

■ Ingredients

(for 20 pieces)
– 400 grams of dried chickpeas.
– Handful of leaf parsley.
– 1 large onion.
– A few drops of sesame oil.
– 2 to 3 tablespoons of wheat flour.
– 1 or 2 cloves of garlic.
– 1 teaspoon of cumin powder.
– 1 teaspoon of cayenne pepper.
– Pinch of salt.

My modifications: jalapeno instead of cayenne, a little less onion and a lot more parsley.

■ Preparation

– Soak the chickpeas overnight in cold water. You will notice that the volume more or less doubles. Don’t use canned chickpeas for this recipe, they are already cooked.
– Cut the garlic and onion into large pieces.
– Remove the stalks from the parsley and fine the leaves.
– Put the chickpeas with all ingredients in a blender and grind them until you get a crumbly dough. Make sure there are no longer large pieces in it, but don’t blend the dough for too long.
– Wet your hands and roll small balls off the dough. You choose the diameter yourself, but smaller balls are fried faster.
– Fry them until they are golden yellow on both sides.
– Make a delicious dip sauce to your own taste.

The post Falafel first appeared on 🍙.

New ways to use old structures to help LLMs write better code. Techniques to reduce token use, reduce context size, reduce errors.

Adapting Traditional OOP Style

Classic object-oriented design — inheritance hierarchies, polymorphic dispatch, encapsulated state — predates LLMs by decades. Much of what made OOP ergonomic for humans (deep class trees, implicit constructor injection, framework-managed lifecycles) introduces exactly the kind of implicit decisions that hurt one-shot generation. The good news: you can keep the spirit of OOP while stripping out the parts that confuse a model.

Inheritance → Composition + Interfaces

Deep extends chains force the model to track overridden methods across multiple files, guess which superclass field is shadowing which, and infer initialization order. Adaptation:

• Prefer interfaces / traits / protocols over base classes. A flat interface PaymentProcessor { process(order: Order): Result } gives the model a complete contract in one place. No diamond problems, no super-call ordering to reason about.
• Use composition for shared behavior. Mixins, embedded structs, or trait implementations (impl Display for MyType) are self-contained blocks the model can generate without knowing the rest of the hierarchy.
• If you must inherit, keep depth ≤ 2. One concrete base + one leaf is manageable; three levels with abstract intermediates start to exceed what the model tracks reliably in a single pass.

Encapsulation → Explicit Data Structures

Private fields with getters/setters hide data flow behind method calls the model must predict. Adaptation:

• Expose plain data structures (structs, records, frozen objects) at boundaries. The model sees the shape directly instead of inferring it from accessor pairs.
• Reserve methods for behavior, not for field access. If a “method” just returns a field, make the field public (or readonly) and delete the getter. Fewer indirection layers means fewer places the model can invent a nonexistent accessor.
• Make mutability intentional and visible. A struct with all-public fields communicates “data container.” A class with private state and mutating methods signals “behavior owner.” Mixing both in one type forces the model to guess the invariant.

Polymorphism → Tagged Unions + Pattern Matching

Runtime dynamic dispatch (obj.handle() where the actual type depends on construction site) requires the model to enumerate every possible subclass. Adaptation:

• Replace runtime polymorphism with sum types + exhaustive match wherever the set of cases is closed. enum Shape { Circle(f64), Rect(f64, f64) } matched in one function is unambiguous; a Shape interface with ten subclasses scattered across modules is not.
• For open-ended extensibility (plugin systems, event handlers), use an explicit registry or visitor pattern rather than relying on the model to discover all overrides. The registry is a single lookup table the model can read.
• Sealed hierarchies beat open ones. If the compiler enforces exhaustiveness (Kotlin sealed, Scala sealed, TypeScript discriminated unions), the model knows the case list is complete. Open hierarchies invite phantom branches.

Dependency Injection → Explicit Constructor Parameters

Frameworks that inject dependencies via annotations, reflection, or container magic hide the dependency graph. The model can’t see what a class actually needs until it reads the DI configuration. Adaptation:

• Pass dependencies through constructors explicitly. fn new(db: &Pool, cache: &Cache) is visible at the call site. @Inject annotations require reading a separate wiring file the model may not have in context.
• Keep constructor arity low (≤ 4). Beyond that, bundle related deps into a config/options struct. Long parameter lists are where models drop arguments or swap types.
• Avoid builder-pattern fluency for core types. Fluent builders (new Widget().red().big().build()) scatter construction logic across chained calls. A single constructor call with a struct literal is easier to generate correctly.

Framework Magic → Plain Entry Points

Spring beans, Rails controllers, Angular decorators, and similar frameworks interpose lifecycle hooks, serialization, and routing logic between your code and its observable behavior. Adaptation:

• Isolate framework glue in thin adapters. Keep business logic in plain functions/classes with no framework annotations. The adapter translates HTTP request → function call → response. The model generates the interesting part (logic) without needing to satisfy framework constraints simultaneously.
• Prefer functional entry points for pure computation. A controller that calls calculate_total(items, discount_code) is testable and generatable independently of the web framework. Embedding that calculation inside a decorated class method couples two concerns the model must get right at once.
• Document the framework contract in the prompt if unavoidable. If the target code must be a Spring @Service or a React component, include one minimal working example in the prompt. One concrete exemplar reduces hallucination more than any amount of prose description.

State Machines → Enum-Driven Flows

Implicit state held in boolean flags (isLoading, hasError, isSubmitted) creates combinatorial explosion the model struggles to navigate. Adaptation:

• Model explicit states as enums. enum CheckoutState { Idle, FillingCart, ValidatingPayment, Processing, Complete(Error?) } makes invalid transitions impossible and gives the model a finite, named space to work in.
• Transition functions take (state, event) → new_state. Pure transition functions are trivially verifiable and easy to generate. Mutating a stateful object’s internal booleans is not.
• Guard clauses over nested conditionals. match state { Idle => ..., Processing => ... } beats four levels of if (flag1 && !flag2 || flag3) that the model must untangle.

Summary Checklist

The overarching principle is the same as the rest of this article: remove implicit decisions. Traditional OOP optimizes for human maintainability in large teams over years — hiding internals, deferring binding, distributing behavior across a hierarchy. LLM one-shot generation optimizes for a different constraint: everything relevant must be visible, local, and unambiguous within a single context window. You don’t abandon OOP thinking; you flatten it so the model doesn’t have to reconstruct the hidden architecture from fragments.

The post Adapting Traditional OOP Style to the LLM World first appeared on 🍙.

A quick-reference list of language features and conventions that make one-shot code generation more reliable. The common thread: predictability. Features that appear frequently in training data, parse unambiguously, and leave few implicit choices produce fewer hallucinations and fewer subtle bugs.

Type System & Static Structure

• Explicit type annotations. Languages with strong static typing (TypeScript, Rust, Go, Java) constrain the solution space dramatically. An annotation like fn process(input: Vec<u8>) -> Result<String, Error> tells the model exactly what goes in and comes out, eliminating an entire class of guessing.
• Algebraic / sum types. Enums, tagged unions, sealed classes, and Result<T, E> force exhaustive handling. The model can’t silently forget a case the way it can with a bare integer or string status code.
• Optionality made explicit. Option<T>, nullable markers, or required-field syntax prevent “did I check for null?” ambiguity from leaking into generated logic.

Naming & Conventions

• Descriptive, conventional identifiers. Names that follow community norms (getUserName, not gn()) match high-frequency patterns in training data. The model essentially autocomplete-s from convention.
• Standard library names used as-is. Reaching for collections.defaultdict instead of inventing a helper keeps the output verifiable and familiar.

Syntax Predictability

• Uniform function/method call syntax. Consistent f(x) across the language means the model rarely fumbles call shapes. Languages mixing macro invocations, operator overloading, and special dispatch forms are harder to get right blind.
• No hidden mutation or side effects baked into syntax. Properties, getters/setters, and overloaded operators introduce behavior the model must infer. Plain functions and plain fields are safer bets.
• Single, obvious control-flow forms. One canonical for x in items: loop beats five dialects. When a language has many ways to express the same thing, the model picks whichever was most frequent in its slice of training data — which may not be your house style.

Module & Import Clarity

• Explicit imports. Languages where every symbol must be imported (Go, ES modules, Rust use) give the model a clear contract. Implicit global namespaces increase the chance of name collisions and wrong-symbol guesses.
• Flat, predictable module paths. Deep dynamic import chains are harder for the model to resolve correctly than shallow, named ones.

Error Handling

• Structured errors over exceptions-as-control-flow. Returning error values or using typed result types is easier for the model to wire up correctly than try/catch ladders with implicit propagation.
• One idiomatic recovery path. If the ecosystem has a single accepted pattern (e.g., Rust’s ? operator), the model converges on it reliably.

Immutability & Data Flow

• Default-immutability languages (Rust ownership, immutable-by-default JS bindings via const discipline, Clojure values) reduce the state-space the model must track. Fewer aliasing surprises mean fewer off-by-one-mutation bugs.
• Pure-function-friendly design. Functions whose output depends only on inputs are trivially composable and easy for the model to reason about step by step.

Formatting & Tokenization Friendliness

• Consistent whitespace-based structure (Python indentation, standard 4-space blocks) maps cleanly onto token boundaries. Irregular formatting or mixed-indentation legacy code increases noise.
• Common delimiters and punctuation. Braces, parentheses, semicolons used uniformly tokenize predictably; exotic delimiter schemes add risk.

Testability Surface

• Small, independently callable units. A language/ecosystem where you can unit-test a function without bootstrapping a framework gives the model a natural stopping point and makes verification cheap.
• Deterministic behavior by default. No hidden randomness, no wall-clock dependence inside core logic — the model can reason about outputs concretely.

Practical Takeaways

Rule of thumb: when choosing a language or refactoring a prompt for better one-shot results, pick the option that leaves the fewest implicit decisions to the model. Every explicit choice you encode in the language itself is a decision the model doesn’t have to guess.

Language Competition

Comparing these languages: JavaScript, TypeScript, Lua, Go, Rust, C++, C, ObjC, Haskell, Elm, Python3, Perl, Perl6, PHP8, Vala, Java, Kotlin, Swift, C#, F#.

The post Language Characteristics that Help LLMs Write Better Code first appeared on 🍙.

So, here’s my current desktop layout. It’s a laptop plugged into a HD monitor, for two screens.

My system is MINT Linux Cinnamon, but with Regolith, a GNOME environment with the i3 full-screen/tiling window manager. Here’s a video about it:

i3 uses named workspaces (also known as Desktops, Virtual Desktops, or Spaces in Windows and MacOS), numbered from 1 to 19, and you jump to them by pressing Win+1, Win+2… Win+Ctrl+1… etc. (Win can also be the Apple Key or “Super”)

Normally, you have to press Win+Shift+1 to move a window to workspace 1.

Starting up a session can be a pain, because you bring up the apps you want, and they all show up in the current workspaces.

I like to keep all my comms apps, like Signal, in workspace 1. I want my first browser to go to workspace 3.

I also want all my odd-numbered workspaces on the big screen on the left, and even numbered workspace on the right, on the laptop screen.

Here’s my config file: .config/regolith3/i3/config.d/workspace-to-display.config

# mkdir -p  ~/.config/regolith3/i3/config.d
# vi ~/.config/regolith3/i3/config.d/workspace-to-display.config 
# Run xrandr --listmonitors to get the monitor names
#
# Sample output:
#
# Monitors: 2
# 0: +*HDMI-1 1920/509x1080/286+0+0  HDMI-1
# 1: +eDP-1 1920/309x1080/173+1920+0  eDP-1
#
# Paste the configs below in and edit to match your desired monitor setup

workspace "$ws1" output HDMI-1
workspace "$ws2" output eDP-1
workspace "$ws3" output HDMI-1
workspace "$ws4" output eDP-1
workspace "$ws5" output HDMI-1
workspace "$ws6" output eDP-1
workspace "$ws7" output HDMI-1
workspace "$ws8" output eDP-1
workspace "$ws9" output HDMI-1
workspace "$ws10" output eDP-1
workspace "$ws11" output HDMI-1
workspace "$ws12" output eDP-1
workspace "$ws13" output HDMI-1
workspace "$ws14" output eDP-1
workspace "$ws15" output HDMI-1
workspace "$ws16" output eDP-1
workspace "$ws17" output HDMI-1
workspace "$ws18" output eDP-1
workspace "$ws19" output HDMI-1

assign [class="thunderbird"] "$ws1"
assign [class="proton-mail"] "$ws1"
for_window [class="Signal"] move to workspace "$ws1"
# These don"t work
for_window [class="Element *"] move to workspace "$ws1"
for_window [class="WhatsApp"] move to workspace "$ws1"

assign [class="firefox"] "$ws3"

# mkdir -p  ~/.config/regolith3/i3/config.d
# vi ~/.config/regolith3/i3/config.d/workspace-to-display.config 
# Run xrandr --listmonitors to get the monitor names
#
# Sample output:
#
# Monitors: 2
# 0: +*HDMI-1 1920/509x1080/286+0+0  HDMI-1
# 1: +eDP-1 1920/309x1080/173+1920+0  eDP-1
#
# Paste the configs below in and edit to match your desired monitor setup

workspace "$ws1" output HDMI-1
workspace "$ws2" output eDP-1
workspace "$ws3" output HDMI-1
workspace "$ws4" output eDP-1
workspace "$ws5" output HDMI-1
workspace "$ws6" output eDP-1
workspace "$ws7" output HDMI-1
workspace "$ws8" output eDP-1
workspace "$ws9" output HDMI-1
workspace "$ws10" output eDP-1
workspace "$ws11" output HDMI-1
workspace "$ws12" output eDP-1
workspace "$ws13" output HDMI-1
workspace "$ws14" output eDP-1
workspace "$ws15" output HDMI-1
workspace "$ws16" output eDP-1
workspace "$ws17" output HDMI-1
workspace "$ws18" output eDP-1
workspace "$ws19" output HDMI-1

assign [class="thunderbird"] "$ws1"
assign [class="proton-mail"] "$ws1"
for_window [class="Signal"] move to workspace "$ws1"
# These don"t work
for_window [class="Element *"] move to workspace "$ws1"
for_window [class="WhatsApp"] move to workspace "$ws1"

assign [class="firefox"] "$ws3"

Workspaces Associated with Displays

At the top of my config, I have some comments to remind me how I did it. You run xrandr –listmonitors to get the monitor names:

xrandr --listmonitors

xrandr --listmonitors

Then you put these lines to assign a workspace to a display:

workspace "$ws1" output HDMI-1
workspace "$ws2" output eDP-1
.
.
.
workspace "$ws18" output eDP-1
workspace "$ws19" output HDMI-1

workspace "$ws1" output HDMI-1
workspace "$ws2" output eDP-1
.
.
.
workspace "$ws18" output eDP-1
workspace "$ws19" output HDMI-1

Then, you assign windows to workspaces:

assign [class="thunderbird"] "$ws1"
assign [class="proton-mail"] "$ws1"
for_window [class="Signal"] move to workspace "$ws1"
# These don"t work
for_window [class="Element *"] move to workspace "$ws1"
for_window [class="WhatsApp"] move to workspace "$ws1"

assign [class="firefox"] "$ws3"

assign [class="thunderbird"] "$ws1"
assign [class="proton-mail"] "$ws1"
for_window [class="Signal"] move to workspace "$ws1"
# These don"t work
for_window [class="Element *"] move to workspace "$ws1"
for_window [class="WhatsApp"] move to workspace "$ws1"

assign [class="firefox"] "$ws3"

The first three lines work, and the last line works, but the lines for Element and WhatsApp don’t work. These config lines are tricky to figure out, because you don’t know what info the app is exposing to the window manager. Finding out is a pain in the butt, but here are instructions:

https://stackoverflow.com/questions/65049414/in-i3wm-how-can-i-open-programs-on-another-workspace-at-startup

One of these days, I may update this with a bunch of programs configured to show up on specific workspaces.

Errors

For a while, I had my own config in .config/regolith3/i3/config, which I think may have caused error messages and weird behavior. (I may be wrong, though.)

The workspace names were causing problems. The “names” looked like HTML – because they were:

1:<span> </span>1 <span foreground="#3584E4"></span><span> </span>

1:<span> </span>1 <span foreground="#3584E4"></span><span> </span>

That’s the name, with all the HTML in it. It gets rendered by Pango.

However, when this line is expanded, it breaks:

# The original config line:
workspace "$ws1" output HDMI-1
# The line after the variable expansion:
workspace "1:<span> </span>1 <span foreground="#3584E4"></span><span> </span>" output HDMI-1

# The original config line:
workspace "$ws1" output HDMI-1
# The line after the variable expansion:
workspace "1:<span> </span>1 <span foreground="#3584E4"></span><span> </span>" output HDMI-1

The problem is the double quote within the double-quoted string. I got a ton of error messages.

I thought, “this is easy. Try using single-quotes”:

# The original config line:
workspace '$ws1' output HDMI-1
# The line after the variable expansion:
workspace '1:<span> </span>1 <span foreground='#3584E4'></span><span> </span>' output HDMI-1

# The original config line:
workspace '$ws1' output HDMI-1
# The line after the variable expansion:
workspace '1:<span> </span>1 <span foreground='#3584E4'></span><span> </span>' output HDMI-1

OK, I don’t know what the hell was going on, but single quotes caused the variable expansion to also use single quotes inside the string.

I tried it without any quotes at all, but that didn’t work, because variable expansions are done before the entire line is parsed. So all the spaces in the code would separate the name into words. That’s why the quotes were there.

After reading a lot, and digging around, I found where these long, troublesome names were being generated: /usr/share/regolith-look/default/wm

The code looks a little like this:

#define Q(x) #x
#define QUOTE(x) Q(x)
#define glyph typeface_bar_glyph_workspace
#define WORKSPACE_NAME(INDEX, COLOR, GLYPH) INDEX:<span> </span>INDEX <span foreground=COLOR>GLYPH</span><span> </span>

wm.workspace.01.name: WORKSPACE_NAME(1, QUOTE(color_blue), glyph)
.
.
.

#define Q(x) #x
#define QUOTE(x) Q(x)
#define glyph typeface_bar_glyph_workspace
#define WORKSPACE_NAME(INDEX, COLOR, GLYPH) INDEX:<span> </span>INDEX <span foreground=COLOR>GLYPH</span><span> </span>

wm.workspace.01.name: WORKSPACE_NAME(1, QUOTE(color_blue), glyph)
.
.
.

Yes, those are C preprocessor (cpp) directives.

For the 99% of people who don’t know what C or the C Preprocessor is: it’s a macro language. Here’s a video about it. Skip it if you know it.

The obvious fix was to single-quote the color value, so the expansion would look like this:

workspace "1:<span> </span>1 <span foreground='#3584E4'></span><span> </span>" output HDMI-1

workspace "1:<span> </span>1 <span foreground='#3584E4'></span><span> </span>" output HDMI-1

I tried:

#define SQ(X) 'X'

#define SQ(X) 'X'

That didn’t work, because the X would not expand within a single (or double) quoted string. (This was one of the features of the cpp.)

After an hour or two of reading, talking to AI, and looking for solutions, and failing to ever get it working with macros, I figured out something: I needed to run the cpp on the config files to get the computed config, because the workspace name definitions would be in there.

The file at the top of all the configs, with all the #includes, was called root, and the command to spit out the config:

cpp /usr/share/regolith-look/default/root

cpp /usr/share/regolith-look/default/root

That showed me the computed config:

wm.workspace.01.name: 1:<span> </span>1 <span foreground="#3584E4"></span><span> </span>
wm.workspace.02.name: 2:<span> </span>2 <span foreground="#95E6CB"></span><span> </span>
wm.workspace.03.name: 3:<span> </span>3 <span foreground="#33D17A"></span><span> </span>
.
.
.

wm.workspace.01.name: 1:<span> </span>1 <span foreground="#3584E4"></span><span> </span>
wm.workspace.02.name: 2:<span> </span>2 <span foreground="#95E6CB"></span><span> </span>
wm.workspace.03.name: 3:<span> </span>3 <span foreground="#33D17A"></span><span> </span>
.
.
.

Now, we just need to be able to override what the macros produced.

This can be done through Xresources.

Here are the config lines that define the $ws1… variables:

###############################################################################
# Workspace Names
# These are the labels which define each workspace.
###############################################################################

set_from_resource $ws1  wm.workspace.01.name "1"
set_from_resource $ws2  wm.workspace.02.name "2"
set_from_resource $ws3  wm.workspace.03.name "3"
.
.
.

###############################################################################
# Workspace Names
# These are the labels which define each workspace.
###############################################################################

set_from_resource $ws1  wm.workspace.01.name "1"
set_from_resource $ws2  wm.workspace.02.name "2"
set_from_resource $ws3  wm.workspace.03.name "3"
.
.
.

set_from_resource sets a variable value, first looking for the value in Xresources, and if it’s not there, using the supplied default.

The canonical way for end users to configure Regolith is through the Xresources file. (Having now tried to mess with the config files, I understand why: it’s easy to completely screw up the config files.)

So setting the correct value was as simple as pasting this into the .config/regolith3/Xresources file:

wm.workspace.01.name: 1:<span> </span>1 <span foreground='#3584E4'></span><span> </span>
wm.workspace.02.name: 2:<span> </span>2 <span foreground='#95E6CB'></span><span> </span>
wm.workspace.03.name: 3:<span> </span>3 <span foreground='#33D17A'></span><span> </span>
wm.workspace.04.name: 4:<span> </span>4 <span foreground='#F6D32D'></span><span> </span>
wm.workspace.05.name: 5:<span> </span>5 <span foreground='#FF7800'></span><span> </span>
wm.workspace.06.name: 6:<span> </span>6 <span foreground='#E01B24'></span><span> </span>
wm.workspace.07.name: 7:<span> </span>7 <span foreground='#75507B'></span><span> </span>
wm.workspace.08.name: 8:<span> </span>8 <span foreground='#9141AC'></span><span> </span>
wm.workspace.09.name: 9:<span> </span>9 <span foreground='#986A44'></span><span> </span>
wm.workspace.10.name: 10:<span> </span>10 <span foreground='#3584E4'></span><span> </span>
wm.workspace.11.name: 11:<span> </span>11 <span foreground='#95E6CB'></span><span> </span>
wm.workspace.12.name: 12:<span> </span>12 <span foreground='#33D17A'></span><span> </span>
wm.workspace.13.name: 13:<span> </span>13 <span foreground='#F6D32D'></span><span> </span>
wm.workspace.14.name: 14:<span> </span>14 <span foreground='#FF7800'></span><span> </span>
wm.workspace.15.name: 15:<span> </span>15 <span foreground='#E01B24'></span><span> </span>
wm.workspace.16.name: 16:<span> </span>16 <span foreground='#75507B'></span><span> </span>
wm.workspace.17.name: 17:<span> </span>17 <span foreground='#9141AC'></span><span> </span>
wm.workspace.18.name: 18:<span> </span>18 <span foreground='#986A44'></span><span> </span>
wm.workspace.19.name: 19:<span> </span>19 <span foreground='#3584E4'></span><span> </span>

wm.workspace.01.name: 1:<span> </span>1 <span foreground='#3584E4'></span><span> </span>
wm.workspace.02.name: 2:<span> </span>2 <span foreground='#95E6CB'></span><span> </span>
wm.workspace.03.name: 3:<span> </span>3 <span foreground='#33D17A'></span><span> </span>
wm.workspace.04.name: 4:<span> </span>4 <span foreground='#F6D32D'></span><span> </span>
wm.workspace.05.name: 5:<span> </span>5 <span foreground='#FF7800'></span><span> </span>
wm.workspace.06.name: 6:<span> </span>6 <span foreground='#E01B24'></span><span> </span>
wm.workspace.07.name: 7:<span> </span>7 <span foreground='#75507B'></span><span> </span>
wm.workspace.08.name: 8:<span> </span>8 <span foreground='#9141AC'></span><span> </span>
wm.workspace.09.name: 9:<span> </span>9 <span foreground='#986A44'></span><span> </span>
wm.workspace.10.name: 10:<span> </span>10 <span foreground='#3584E4'></span><span> </span>
wm.workspace.11.name: 11:<span> </span>11 <span foreground='#95E6CB'></span><span> </span>
wm.workspace.12.name: 12:<span> </span>12 <span foreground='#33D17A'></span><span> </span>
wm.workspace.13.name: 13:<span> </span>13 <span foreground='#F6D32D'></span><span> </span>
wm.workspace.14.name: 14:<span> </span>14 <span foreground='#FF7800'></span><span> </span>
wm.workspace.15.name: 15:<span> </span>15 <span foreground='#E01B24'></span><span> </span>
wm.workspace.16.name: 16:<span> </span>16 <span foreground='#75507B'></span><span> </span>
wm.workspace.17.name: 17:<span> </span>17 <span foreground='#9141AC'></span><span> </span>
wm.workspace.18.name: 18:<span> </span>18 <span foreground='#986A44'></span><span> </span>
wm.workspace.19.name: 19:<span> </span>19 <span foreground='#3584E4'></span><span> </span>

NOTE: the color values are single quoted. I copied this from the config dump above, and did a search-replace for “, replacing with ‘.

That corrected the config file errors I was getting, and a few other problems I may have introduced.

Conclusion

This was way more difficult than it needed to be.

This workspace naming scheme seems like a bad idea, at least if the name is more than a single word. Rather than referring to a workspace by it’s fancy HTML code label, a named workspace should also have a “label” property, for this string to display.

The cpp is kind of cool, but kind of a pain in the ass.

The post Configuring Regolith to Send Windows to Workspaces (long) first appeared on 🍙.

DIY GNOME Environment Markdown Editor

This is a script that makes a simple “Markdown editor” that’s a gedit window, and a md-fileserver program, that, together, work like editors like Apostrophe.

One window is for editing.

The other is a preview.

Save it into md-edit, and do a chmod u+x md-edit to make it an executable command. Note that it uses zsh, not bash, so you need zsh installed.

This program automatically creates a document in “MarkdownNotes”, so I can create notes without naming the file. I realize this isn’t everyone’s use case, and I’m just presenting this as an example.

#! /usr/bin/zsh

# Markdown editor setup using md-fileserver

if [[ -z "$1" ]]; then
    F="Untitled-`date +%Y-%m-%d`-$RANDOM.md"
    mkdir -p ~/Documents/MarkdownNotes
    cd ~/Documents/MarkdownNotes
else
    F="$1"
fi

touch "$F"

gedit "$F" &

echo 
echo Uses: https://github.com/commenthol/md-fileserver
echo 
echo URL to view the doc
echo
echo http://localhost:4000/`pwd`/$F
echo
echo http://localhost:4000/`pwd`/
echo
echo Settings
echo
echo http://localhost:4000/config
echo
echo Confluencer docs: https://www.npmjs.com/package/confluencer
echo
mdstart -c "$F"

#! /usr/bin/zsh

# Markdown editor setup using md-fileserver

if [[ -z "$1" ]]; then
    F="Untitled-`date +%Y-%m-%d`-$RANDOM.md"
    mkdir -p ~/Documents/MarkdownNotes
    cd ~/Documents/MarkdownNotes
else
    F="$1"
fi

touch "$F"

gedit "$F" &

echo 
echo Uses: https://github.com/commenthol/md-fileserver
echo 
echo URL to view the doc
echo
echo http://localhost:4000/`pwd`/$F
echo
echo http://localhost:4000/`pwd`/
echo
echo Settings
echo
echo http://localhost:4000/config
echo
echo Confluencer docs: https://www.npmjs.com/package/confluencer
echo
mdstart -c "$F"

I wrote this post in md-edit

You can usually copy-paste Markdown into WordPress, and it’ll automatically format it the same way. gedit is way faster than the WordPress block editor.

Other Markdown Editors I like

Obsidian – the best editor, is also a note-taker, outliner, and knowledge graph editor. Has great renaming UI (you can’t tell it’s there). An awesome tool for writing your LLM files.

Apostrophe – the slickest one. A “no distraction” editor.

Cryptpad.fr/code‘s code editor. A nice, no-install, encrypted solution.

The post Markdown Editors first appeared on 🍙.

I haven’t done a thorough test, mainly because I’m still learning Elm, but some LLMs seem to do great with Elm code, and some seem to run endless loops of debugging failures. I’ve been playing with Nemotron, Muse Spark, MiMo, and Thaura Work.

The debugging cycles are super nice. When things are working well, the code generated compiles the first time, or after one or two cycles through the compiler.

One time, I asked to replicate the layout of an Indymedia site, and gave a brief description of what it was, and what parts I wanted. It cranked out the code quickly, and it compiled, and it looked nice.

Even more important: it was under 100 lines of Html library code. The CSS was a bit longer.

Thaura advised using https://elm-pages.com, and at least one LLM produced code that compiled.

The post Learning Elm: LLMs first appeared on 🍙.

LLMs are amazing, but they also hallucinate. People who skip the thinking get burned.

I don’t use the LLM to write my documents; I use it to critique them.

Generating a critique is as simple as pasting your text into the chat and asking for a critique. Example:

A critique of this: <paste text here>

Then I read the critique and rewrote; I repeat the loop if necessary.

Setting Up a Reusable Editor

Over time, my prompt got more complex, with more instructions. I wanted the spelling fixed, but the grammar and style critiqued without changing the text. I wanted my logical fallacies pointed out. The prompt was getting unmanageable.

I’m using Thaura.ai, which has a feature called Projects that lets you save prompts for a recurring task.

My first editor project used this prompt:

Extremely critical editor looks for all kinds of flaws, particularly flaws of logic, the regular list of logical fallacies, unusual or unconventional definitions, grammar errors, florid language, passive voice, failures to acknowledge limitations, ahistoricism, errors of fact, spelling errors, references to controversial sources, references to low quality sources, profanity, race stereotype, gender stereotyping, homophobia, insensitivity to issues of economic or social class, rudeness insolence.

That prompt caught plenty, but I wanted consistent scoring, so I added a system prompt to calculate a score for each flaw, plus an overall document score. The per-flaw scores told me what to fix first; the overall score gave me a number to compare against after each rewrite:

Reply listing each flaw, with a brief explanation, and a severity score of 1 to 3, higher is worse. Calculate an aggregate score of 0 to 100, using some kind of quadratic function, and advise on publishing the text.

The criticisms were often harsh, but they forced me to actually defend what I’d written, and the drafts got better for it.

Sometimes, the critique I got was brief, but even then, I forced myself to re-read the text and rework it. Doing a rewrite of a first draft usually improved it, but occasionally, reviewing my own work made me reconsider whether to publish it at all.

The whole loop is fast: paste, read the critique, revise. You don’t need to agree with every point — the value is in being forced to re-read your own words.

(This post was written with an editing assistant, which I’ll describe in a future post.)

The post Thaura: Writing with an LLM first appeared on 🍙.

I found much of the content for this article at: https://sporto.gitbooks.io/elm-tutorial/content/en/01-foundations/02-functions.html

Here’s now to create a learning environment where you can edit a file full of Elm code, and play with the code.

# make a directory and turn it into an Elm project
mkdir elm
cd elm
elm init

# fire up an editor
gedit &

# open up an elm console
elm repl

# make a directory and turn it into an Elm project
mkdir elm
cd elm
elm init

# fire up an editor
gedit &

# open up an elm console
elm repl

Add the “.” directory to elm.json. This will tell Elm to search for modules in there:

    "source-directories": [
        "src",
        "."
    ],

    "source-directories": [
        "src",
        "."
    ],

Next up, make the file Sample.elm, and just keep it open in the editor:

module Sample exposing (..)

add : Int -> Int -> Int
add a b = a + b

mul : Int -> Int -> Int
mul a b = a * b

sub : Int -> Int -> Int
sub a b = a - b

module Sample exposing (..)

add : Int -> Int -> Int
add a b = a + b

mul : Int -> Int -> Int
mul a b = a * b

sub : Int -> Int -> Int
sub a b = a - b

That’s a bunch of function definitions.

Jump back to the Elm REPL in the terminal:

> import Sample exposing (..)
> mul 2 3
6
> sub 1 2
-1

You can type in more function definitions, and they’ll be available when you type them into the REPL.

So, we’ve created functions so we can type out a language that looks like LISP:

> (add 1 2)
3 : Int
> (add (mul 2 2) (mul 5 2) )
14 : Int
> mul (add 2 3) (mul 2 2)
20 : Int
> add (mul (mul 2 3) 5)
<function> : Int -> Int
> add (mul (mul 2 3) 5) 100
130 : Int

That second to last call to add returned a function. The function takes one argument. Putting a 100 after it added 30 to the 100.

(add 1) returns a function that takes one argument, and returns a value that’s one added to the argument.

(add 9) returns a function that takes one argument, and returns a value that’s 9 added to the argument.

Elm has some syntax that messes with the ordering, called a pipe. Here’s the pipe in action:

records
    |> map getCost
    |> filter (isOver 100)
    |> sum

records
    |> map getCost
    |> filter (isOver 100)
    |> sum

So, that makes sense. It’s like Unix pipes. Records piped into map getCost, piped into filter (isOver 100), piped into sum.

In English: all the costs from records, filtered to be over 100, and summed.

The pipe, |>, rearranges the way functions work. These two function calls are the same:

> add 1 2
3 : Int
> 2 |> add 1
3 : Int

What’s going on?

“2 |> add 1” means 2 passed to add 1. What is “add 1”?

(add 1) returns a function that takes a single argument, and adds 1 to it.

The following are all the same ((2 + 3) * (2 * 2)):

> mul (add 2 3) (mul 2 2)
20 : Int
> (mul 2 2) |> mul (add 2 3)
20 : Int
> (2 |> mul 2) |> mul (3 |> add 2)
20 : Int
> 2 |> mul 2 |> mul (3 |> add 2)
20 : Int

You can reformat the last one in the indented pipes layout:

2
    |> mul 2
    |> mul (3 |> add 2)

Yeah, it doesn’t make anything clearer, but you can try to work out how Elm evaluates the final value, and it will help clarify the pipe |>.

To show what I mean, I’ll highlight (in red) functions that can resolve to a function:

2
    |> mul 2
    |> mul (3 |> add 2)

Next, we pass values (on the left of the |>) into these functions, and they evaluate to values (in green).

4
    |> mul 5

That mul 5 will return a function:

4
    |> mul 5

Then, we pass 4 into the function returned by (mul 5) and evaluate.

20

Obviously, there are more appropriate places to use pipe notation, and this isn’t one of them.

This example below, however, is a good use of pipes.

records
    |> map getCost
    |> filter (isOver 100)
    |> sum

records
    |> map getCost
    |> filter (isOver 100)
    |> sum

That is the same as:

(sum (filter (isOver 100) (map getCost records)))

The post Learning Elm: pipe tricks first appeared on 🍙.

To get started, you need to install Elm. Then, you’ll get the elm command, which is like npm or composer. elm is a package manager and a build tool. Here’s part of the help when you type “elm”:

elm repl --help
elm init --help
elm reactor --help
elm make --help
elm install --help
elm bump --help
elm diff --help
elm publish --help

The main tools to use as a beginner are elm reactor, the web browser dev tool, and elm repl, the “console” where you can type Elm code and try it out.

I started with Array, List, and Maybe. Also see the syntax reference card and the core language reference.

It was a good way to get familiar with the notation:

fromList : List a -> Array a

The Array.fromList function takes a list as an argument, and returns an array.

push : a -> Array a -> Array a

The push function takes a value, and an array as arguments, and returns an array with the value appended to the end.

Arrays and Lists made sense, but Maybe was different. Type these lines into the REPL.

import Array exposing (..)

x = fromList [1, 2, 3]
get 1 x

-- returns Just 2 : Maybe number

The return value, Just 2, is not 2. You expect 2, but get Just 2. What is up with that?

Just 2 is of type Maybe. Maybe values can be “Just number” or “Nothing”. From the docs:

type Maybe a
    = Just a
    | Nothing

“Represent values that may or may not exist. It can be useful if you have a record field that is only filled in sometimes. Or if a function takes a value sometimes, but does not absolutely need it.”

So, this looked weird to me, but here’s a quick way to convert it to a normal value:

-- here's the function
withDefault : a -> Maybe a -> a

-- usage
withDefault 0 (Just 2)
-- returns the value 2 : number

OK, that is still weird. (Most languages have type coercion or functions to convert values.)

Here’s an example from the syntax guide:

<code>case maybeList of
    Just xs -> xs
    Nothing -> []</code>

This is a different way to coerce values. It switches based on the type variant of maybeList.

So Maybe is a type, with two variants “Just xs” and “Nothing“.

The case switching isn’t based on the value of the variable, but on the variant.

(This might look like a variant is, itself, a type. This isn’t the case, because maybeList must be a Maybe. The case switch will match only variants of Maybe. This is more restrictive than the case switch statements you see in OOP languages with a typeof() operator.)

I’ll stop at this point, because types are important to Elm. I have to spend more time studying it. It’s reminding me of types in Haskell: and that means it’s part of how the program executes.

https://dev.to/jigargosar/elm-vs-the-feature-addiction-epidemic-in-programming-ach

https://riptutorial.com/elm

https://guide.elm-lang.org/types

https://learnyouanelm.github.io/pages/03-types.html

https://www.elmcraft.org/

https://elmprogramming.com/

https://lamdera.com

https://github.com/sporto/awesome-elm

https://pragmaticstudio.com/tutorials/what-is-elm

https://www.sitepoint.com/functional-reactive-programming-elm-introduction/#google_vignette

https://en.wikibooks.org/wiki/Elm_programming_language

https://www.toptal.com/developers/front-end/getting-started-elm-language

https://dev.to/marciofrayze/why-is-elm-such-a-delightful-programming-language-2em8

https://github.com/elm

The post Learning Elm first appeared on 🍙.