Skip to content

Instantly share code, notes, and snippets.

View warpfork's full-sized avatar

Eric Myhre warpfork

View GitHub Profile
@warpfork
warpfork / Gar.md
Last active July 17, 2024 15:46
Gar -- a git-inspired archive and content-addressed deduplicating cache manager tool

Git archive. Comparable to tar, in a way.

Purpose

Maintains directories of Content Addressable content.

Meant to play nice as a provider of an immutable append-only cache that's easy to integrate with any system based on files and directories.

@warpfork
warpfork / preface.md
Last active July 17, 2024 10:38
Rust drives me bonkers, 2024

I'm not sure if this is a good list of issues I have with Rust.

Maybe some of them can be addressed. Maybe even immediately, in ways I don't yet know.

But the theme of the file below is that I started very enamored with rust... and then my practical experience with it after about a hundred hours was that I had staggeringly low productivity, because of an endless series of papercuts.

I'm no longer convinced rust is a slam dunk choice. (But I still wish it was.)

@warpfork
warpfork / warpforge-api-evolution-and-recursive-expanders-in-build-plans.md
Last active April 26, 2024 08:29
warpforge evolution directions (and recursive expanders for build plans)

This is a working document to snapshot some thoughts about the evolution of Warpforge and its APIs.

Observations (that lead to some desires for changes)

  • We should seriously consider moving the Catalogs to an even yet plainer format.
    • The Catalog format as it stands today is a pain to edit manually, due to its inclusion of hashes. (This has been remarked upon by essentially every user to date.)
    • We also derive very little value from the use of hashes in the middle of the Catalog data, because in practice, we find we're continuously embedding the Catalog data in other version control systems, which already contain their own checksums. While there is elegance to having our own hashing scheme provide our own bespoke incrementally verifiable trees, there is little strong demonstration of that providing direct value (and very many demonstrations of it creating problematic friction).
    • The Catalog format seems like it could become more generally usable (and thus more appealing for others to interact
@warpfork
warpfork / tcat-rfc.md
Last active April 19, 2024 00:12
Text Catalogs RFC

Text Catalogs: an RFC

Abstract

This document proposes "Text Catalogs" -- "tcat" for short -- a convention for file naming and content organization for document stores. Text Catalogs are specifically aimed to be legible to humans, friendly to version control,

@warpfork
warpfork / zappifier
Created November 25, 2023 21:44
A bash Zappifier. (Not the latest version, due to... computer ownership shenanigans.)
#!/bin/bash
set -euo pipefail
#set -x
## HOW TO HOLD IT:
##
## Give the program you want to zapp as the first argument.
##
## For the couple of different usage patterns:
@warpfork
warpfork / WarpVer.md
Last active June 5, 2024 09:55
WarpVer -- it's not semver

WarpVer Versioning

A software versioning scheme.

It's not semver ™️.

The Rules

@warpfork
warpfork / static_site_roundup_2021.md
Last active November 27, 2021 08:45
Static Site Generator Roundup 2021

Static Site Generator Roundup 2021

Criteria & Considerations

  • does it consume markdown?
  • is it fast?
    • (a "hello world" site should take milliseconds or less to build. Definitely not full seconds; certainly not multiple full seconds.)
  • is it reasonably shipped?
@warpfork
warpfork / gist:8dd88ffb90bdd40eff9945cf7a67fc15
Last active November 2, 2020 21:03
IPLD Strings, round 4

IPLD Strings

For an IPLD library to have "Complete" support for the IPLD Data Model, Strings MUST support the full range of 8-bit bytes. Strings SHOULD use UTF-8, and library designers may encourage this however they see fit. In particular, NFC-normalized form is encouraged. However, this MUST NOT result in the inability of a library to handle non-UTF-8 byte sequences where Strings are handled, nor should libraries apply normalizations to data they read. (In other words: using normalized forms when creating new data is encouraged,

@warpfork
warpfork / ipld-strings.md
Last active November 6, 2020 19:05
IPLD: Strings

Strings in IPLD

"Strings" are a familiar concept in how programs handling digital data. However, for all its familiarity, it is also subtle. Solid systems require clear specifications. In this document, we will describe Strings in IPLD, where they appear, and what specifications we make about their domain.

Prerequisites

@warpfork
warpfork / ipld-map-order.md
Last active November 11, 2020 12:23
IPLD: Data Model: Order of Maps

Data Model: Order of Maps

Maps in IPLD are typically order-preserving: if you put data into them in some order, you can expect that the iterators will return that information in the same order; and transformation functions will generally operate on data without reordering it.

However, there are also several exceptions to this rule, so it's important to be aware of what to expect in the different scenarios.