Loren Osborn loren-osborn

When Improving Test Coverage Raised a Different Question Entirely

I started this work with a fairly narrow, pragmatic goal.

I’ve been exploring an exact- and interval-oriented number format, heavily inspired by John Gustafson’s work on posits. Before taking that idea very far, I wanted a concrete proof of concept—something substantial enough to explore design tradeoffs and failure modes in practice.

After some research, I decided that building on top of the Stillwater Universal library made sense. It already implements a wide range of numeric representations, including elastic rationals, and it’s actively maintained.

As I integrated Universal into a new project, I ran into a handful of compiler and testing issues. Over the course of several weeks, that turned into multiple pull requests, some back-and-forth with the maintainer, and eventually those fixes were merged.

Build Better Stories – Pilot Episode

Title: “You Can Build Anything”
Series: Build Better Something
Duration: ~7–8 minutes

[Opening Visual: Blueprint‑style background with doodles of tools and stars]

TEXT ON SCREEN:
Build Better Something

	Please write a GNU autotools detection mechanism to test for `grep` on the target system, and if grep is present, detect it's capabilities to support EREs, PCREs, and the correct command line switches to put grep into that mode.

	As autotools traditionally tests systems and/or tools for their support for individual features, to see if they are properly supported. My suggestion would be to test the grep command in four phase:
	1. Including any possible shell builtins, find all grep variations (including`grep`, `egrep`, `fgrep`, etc.) that are defined or installed in the current shell path.
	2. Enumerate all modal "production features" (not features like `--help` as it is intended as a user/developer aid, and not intended to be used within a script) and any command line flags/switches that have been used to enable them in any popular versions of grep, then determine which switches each version of grep variation recognizes and/or allows without generating an error. Ideally I would prefer to identify a long and sh

	// Package main is a toy app demoing a defect in `staticcheck`s test for "S1021"
	package main

	import "fmt"

	// Foo is a sample custom type
	type Foo struct {
	Value int
	runabble func()
	}

	#!/bin/bash

	extractOsXUserHash() {
	xmlOfUsertPlist="$( \
	plutil -convert xml1 - -o - \
	)"
	if [ -z "$xmlOfUsertPlist" ] ; then \
	1>&2 echo "No input detected"
	exit 127
	fi

	<?php

	/**
	* File to demonstrate isSubclassOf inconsistancy.
	*/

	use Go\ParserReflection\ReflectionClass as ParsedReflectionClass;
	use Go\ParserReflection\ReflectionEngine as ParsedReflectionEngine;
	use Go\ParserReflection\Locator\CallableLocator as MockLocator;
	use Go\ParserReflection\Locator\ComposerLocator as RealLocator;

	#!/opt/local/bin/python

	from sympy import *


	g, r, m, j = symbols('g r m j')
	c, f, d, h = symbols('c f d h ')

	# Eq((c+m)/j, g / d)
	# Eq((c+m)/j, r / f)

	Facter.add(:overridable_fact_dest) do
	setcode do
	Facter.value(:overridable_fact_src) \|\| 'default_value'
	end
	end

	<?php

	namespace Acme\DemoBundle\Entity;

	// use Doctrine\ORM\Mapping as ORM;
	use Symfony\Component\Validator\Constraints as Assert;

	/**
	* FooTester
	*