an estradiol is an estrogen in the category of endocrine systems

type of guy who refuses to call it “monosodium glutamate” or “msg” and exclusively refers to it as “e621”

note: currently hard linking saves 1115.40 MiB
35499 store paths deleted, 89914.82 MiB freed

Earlier this year, I read Martin Uecker's proposal N3212 to add parametric polymorphism to C. It's easy to scoff at the idea of adding generic programming to plain C, when C++ already has templates, and nearly every modern systems language has some form of generic programming support, but it got me thinking there is an opportunity to do something meaningfully and usefully different from those other languages. C++ templates rely on monomorphization, meaning that when you write a generic function or type, the compiler generates a distinct specialization for every set of types you use it with. Most other systems-ish languages follow C++'s lead, because monomorphization allows each specialization to be individually emitted and optimized specifically for the set of types it's instantiated on, and the resulting specializations don't need any runtime support to handle different types. However, monomorphization also implies a much more complicated compilation and linking model, where the source code (or some intermediate representation thereof) of generic definitions has to be consistently available to the compiler in order to generate new instantiations as needed.

Although C is not really the "portable assembly language" many want it to be, one function definition in C generally leads to one symbol in an object file, and having access to function bodies after they've been compiled once is unnecessary (although helpful for optimization), and it would be good to retain these properties. A less-trodden path for implementing parametric polymorphism in systems-ish languages, used by Swift and also proposed here in N3212, is to use runtime metadata to handle generic types dynamically. N3212 proposes a new _Type primitive type, which carries some metadata about a type's size and other properties, so that other values can be declared with the type represented by that _Type using the _Var specifier:

void sort(_Type T, size_t N, _Var(T) array[N], 
          int (*compare)(const _Var(T)*, const _Var(T)*))
{
   qsort(array, N, sizeof(_Var(T)), compare);
}

One challenge specifying a language-integrated metadata system is that it needs to provide enough information to serve any possible use that the language supports, even if a particular interface only needs a subset of that metadata. A traditional qsort function only needs the size of the elements to do its work, but other generic functions might want to know a type's alignment, its name, how values of the type interact with the function calling convention, the specifier to use in printf, and so on. The vast body of existing C code uses all sorts of different idioms for ad-hoc polymorphic interfaces, so a language design that prescribes a single metadata mechanism is going to have a tough time finding a balance between providing enough metadata to support a wide range of use cases and not bloating code generation with too much metadata that most clients don't need.

So that's why I'd like to explore a third approach that has the potential to be simpler to understand and implement, more flexible, and I think more in the subjective "spirit of C" than C++ style monomorphization or the proposed N3212 design. I think the combination of type-erased generics, paired with a default argument mechanism to collect situationally-appropriate metadata at call sites, could provide a surprising amount of expressivity, allow for better type checking to be retrofitted to existing C interfaces.

Disclaimer

To be up front, my language designer duties are focused elsewhere, and I'm not going to formally propose this to the C working group any time soon. As such, I'm only going to describe the broad strokes of a design direction here without working out all the details. I'm strictly in "ideas guy" mode here. If you want to stop reading, that's fine. But if it inspires you to actually implement and/or propose something like this, then great!

You might also ask, why spend so much time thinking about big new features for C? Isn't C illegal now anyway? Well, I also think it'd be generally good to see more systems languages that don't fall into the well-worn monomorphization rut. Maybe these thoughts will inspire an ambitious systems language designer to try something different.

Generic functions

In order for a single compiled version of a generic function to work with any input type, without needing any predefined runtime metadata about that type, then the function can't do anything that depends on the concrete layout of a specific type. C already has incomplete types, which are similar; you can forward-declare a struct or union, and the forward-declared type can be used as the pointee type of pointers, but not directly as the type of a variable or function parameter. As a starting point, we can say that generic type parameters also behave like incomplete types:

// T can appear as the pointee of a pointer, be cv-qualified, …
void good_generic«T»(const T *a, T *b);

// …but can't appear as a parameter type by itself
void bad_generic«T»(T a); // error; incomplete generic type T

It may not seem like you'd be able to do much in a generic function in this world, since you can't directly do anything with the value of an incomplete type. However, by passing function pointers with matching pointer argument types down along with a pointer, you can make useful generic functions:

// Traverse a list, given operations to visit each node in the list
// and to advance to the next node
void each_node«Node»(Node *head,
                     Node *(*next)(Node *),
                     void (*body)(Node *)) {
  for (Node *node = head; node; node = next(node)) {
    body(node);
  }
}

struct int_node {
  struct int_node *next;
  int value;
};

struct int_node *next_int_node(struct int_node *node) {
  return node->next;
}

void print_int_node(struct int_node *node) {
  printf("%d\n", node->value);
}

int main() {
  struct int_node list[] = {
    { .next = &list[1], .value = 1 },
    { .next = &list[2], .value = 2 },
    { .next = &list[3], .value = 3 },
    { .next = &list[4], .value = 5 },
    { .next = NULL,     .value = 8 },
  };

  each_node«struct int_node»(&list[0], next_int_node, print_int_node);
}

This is akin to passing a vtable for a generic interface (or a "witness table" as Swift calls them), but entirely under the program's control to indicate what's in that vtable.

Default arguments for gathering type metadata

To do much else with a generic value or data structure, you need more metadata about the type. To operate on an array or other data structure of some unknown element type, you generally need to know at least the size and possibly alignment of the elements. Needing to explicitly pass large bundles of metadata at every call site will get tedious, and it'd also undermine the safety benefits of generics, since callers could easily pass the "wrong" metadata. If a generic function declaration could specify default arguments, that could provide a mechanism for automatically collecting relevant metadata from call sites:

// Reduce the values in an array
void reduce«T»(T *out, const T *array, size_t count,
               void (*sum)(T *out, const T *element),
               size_t element_size = sizeof(T)) {
  unsigned i;
  const T *element;
  for (i = 0, element = array;
       i < count;
       ++i, element = (const T*)((const char *)T + element_size)) {
    sum(out, element);
  }
}

void sum_int(int *out, const int *value) {
  out += value;
}

int main() {
  int values[] = {0, 1, 1, 2, 3, 5, 8, 13};

  int sum = 0;

  // call site implicitly passes element_size = sizeof(int)
  reduce«int»(&sum, values, sizeof(values)/sizeof(int), sum_int);

  printf("%d\n", sum);
}

(Having to manually advance the element pointer in the reduce loop by casting to char* and back is kinda gross, so maybe there should be a way to associate a size expression with a generic type, just so pointer arithmetic works:)

// Declaring a generic parameter as T[size_expr] expresses that
// sizeof(T) == size_expr
void reduce«T[element_size]»(T *out, const T *array, size_t count,
                             void (*sum)(T *out, const T *element),
                             size_t element_size = sizeof(T)) {
  unsigned i;
  const T *element;
  for (i = 0, element = array;
       i < count;
       // We can use normal pointer arithmetic on a T* if T has a
       // size expression
       ++i, ++element) {
    sum(out, element);
  }  
}

Retrofitting generics onto existing functions

With these two features, we already have enough to retrofit some existing common C functions to take advantage of generics. N3212 uses sorting as a motivating example, and demonstrates a new sort interface as an alternative to the traditional qsort standard library function. But let's see if we can upgrade the existing qsort in place without breaking compatibility with existing C. qsort's traditional prototype looks something like:

void qsort(void *base, size_t nel, size_t width,
           int (*compar)(const void *, const void *));

where base is a pointer to the first element in an array, nel is the number of elements in the array, width is the size of an element, and compar is a three-way comparison function that returns whether the first pointed-to element is considered less than, equal, or greater than the second. We could change this to:

void qsort«T[width]»(T *base, size_t nel, size_t width = sizeof(T),
                     int (*compar)(const T *, const T *));

Since the generic type declaration itself has no runtime effect, it doesn't need to have any effect on the calling convention of qsort. And we're still passing pointers in all the same places we were passing pointers before. However, one concession to tradition is that the width parameter ought to default to sizeof(T), but it's not the final argument to qsort, so if we follow C++'s default argument rules, this wouldn't be allowed. But we could loosen that restriction, and allow any argument to be defaulted at a generic call site:

int compare_ints(const int *a, const int *b) {
  return a - b;
}

int main() {
  int array[] = {0, 1, 1, 13, 2, 21, 3, 34, 5, 8};

  qsort«int»(array, sizeof(array)/sizeof(int), /*default*/,
             compare_ints);
}

To allow existing C code to continue to call qsort after its retroactive genericization, we could say that calling a generic function without generic arguments devolves those arguments back to void. Default arguments that depend on the generic parameters aren't available at a nongeneric call site, and the caller has to be supply an argument manually. Backward compatibility aside, this would also be useful as a way to get back into generic code using runtime metadata that's been stored in a way that can't be statically reasoned about. (Of course, this is also an easy way to escape type safety, though C is full of those already… maybe there should be a more opt-in way to do so?)

Generic structs

User-defined types could also be parameterized, with the same constraint as function parameters that the type parameters act like incomplete types and can't influence the layout of the type. A generic struct can package up methods and information about a type into a single value. For instance, to support a generic hash table implementation, we might need to know the size and alignment of keys, as well as how to hash a key and compare it for equality with another key. This is another place where defaults are helpful to capture information about a type that the compiler can automatically fill in:

struct hashable«Key» {
  size_t size = sizeof(Key), alignment = alignof(Key);

  uint64_t hash(const Key *value);
  bool equal(const Key *a, const Key *b);
};

const struct hashable«int» int_hashable = {
  .hash = int_hash,
  .equal = int_equal,
};

Incomplete types can also usefully carry generic parameters, to provide some type safety at an interface boundary:

struct hash_table«Key, Value»;


struct hash_table«Key, Value» *hash_table_alloc«Key, Value»(
  size_t initial_buckets,
  const struct hashable«Key» *key_type,
  size_t value_size = sizeof(Value),
  size_t value_alignment = alignof(Value));


void hash_table_insert«Key, Value»(
  struct hash_table«Key, Value» *hash,
  const Key *key,
  const Value *value);


const Value *hash_table_find«Key, Value»(
  struct hash_table«Key, Value» *hash,
  const Key *key);

Generic unions and enums

Enums and unions are interesting because they represent alternatives. Borrowing an idea from GADTs in functional languages, we can say that an enum or union can not only be generic, but also restrict some or all of its members to be available only for specific generic parameters. Among other things, this could allow for more type-safe tagged unions:

enum json_tag«T» {
  null«struct null»,
  boolean«bool»,
  number«double»,
  string«const char *»,
  array«struct json_array»,
  object«struct json_object»,
};

struct json«T» {
  enum json_tag«T» tag;

  union {
    struct null null«struct null»;
    bool boolean«bool»;
    double number«double»;
    const char *string«const char *»;
    struct json_array array«struct json_array»;
    struct json_object object«struct json_object»;
  };
};

struct json«double» zero = { .tag = number, .number = 0.0 };
struct json«const char *» greeting = {
  .tag = string,
  .string = "hello world"
};

struct json«double» bad_number = {
  // error, enum constant 'null' has type 'json_tag«struct null»', not
  // 'json_tag«double»'
  .tag = null,
  // error, union field 'string' has type '(anonymous union)«const char *»'
  .string = "0.0"
};

Parameterized globals?

The default argument mechanism works well for populating metadata parameters from builtin operations like sizeof and alignof, but C as it exists today doesn't provide a way to make open, user-defined associations between types and values. (_Generic does exist, but any one `_Generic expression can only cover a closed set of type alternatives.) The hash table example above demonstrates this:

struct hash_table«Key, Value» *hash_table_alloc«Key, Value»(
  size_t initial_buckets,
  const struct hashable«Key» *key_type,
  size_t value_size = sizeof(Value),
  size_t value_alignment = alignof(Value));

The Value's size and alignment can be prepopulated using sizeof and alignof, but there isn't a good way to default the key_type parameter to a canonical hashable struct for a given type (aside from maybe using _Generic for a closed set of types). C++-style template specialization is probably not a great idea, since it makes type checking dependent on template instantiation, but one possible design might be to allow a global variable name to be declared as being parametric:

// Declare a compound name
_Generic const struct hashable«T» hashable_impl«T»;

This wouldn't define any actual global variable itself, but would allow for definitions to be provided for specific types:

// Provide definitions for some common types:
const struct hashable«int» hashable_impl«int» = { ... };
const struct hashable«bool» hashable_impl«bool» = { ... };
const struct hashable«void *» hashable_impl«void *» = { ... };

Other than the common name, each individual global variable definition would behave like an independent variable definition. Trying to access a parametric name for which no definition is visible would be an error:

auto *hashable_char = &hashable_impl«char»; // error, no such definition

const struct hashable«char» hashable_impl«char» = { ... };

auto *hashable_char = &hashable_impl«char»; // OK

but this would give us the open association we need to provide a nice default for our hash table API:

struct hash_table«Key, Value» *hash_table_alloc«Key, Value»(
  size_t initial_buckets,
  const struct hashable«Key» *key_type = &hashable_impl«Key»,
  size_t value_size = sizeof(Value),
  size_t value_alignment = alignof(Value));

However, we're still type-erasing everything, so there's no dynamic lookup structure to recover this association at runtime. That would mean that you would not be able to refer to a parametric global generically, which might be weird:

const struct hashable«T» *get_hashable_impl«T»(void) {
  // error, can't look up hashable_impl for a generic type T
  return &hashable_impl«T»;
}

Conclusion

This might be a half-baked idea, but hopefully I've demonstrated that there's some potential here for a generics design that isn't in conflict with some of the nice implementation properties of plain C, preserving the ability to do separate compilation without requiring any additional runtime support.

autost is a cohost-compatible archive and blog engine, which i use right here on shuppy.org. for another autost blog, check out LotteMakesStuff dot PINK :D

your posts are now rebloggable, thanks to the microformats2 h-entry format! for the most consistent experience, be sure to set your [self_author] display_handle setting to a domain name.

you can now reblog posts with autost import. for example, to reblog Natalie’s post Reblogging posts with h-entry:

$ autost import https://nex-3.com/blog/reblogging-posts-with-h-entry/
2024-10-03T15:30:33.221087Z  INFO run_migrations: autost::migrations: hard linking attachments out of site/attachments
2024-10-03T15:30:33.411823Z  INFO autost::command::import: writing RelativePath { inner: "posts/imported/1.html", kind: Other }
2024-10-03T15:30:33.422458Z  INFO autost::command::import: click here to reply: http://[::1]:8420/posts/compose?reply_to=imported/1.html

you can now create attachments from local files with autost attach. for example:

$ autost attach ~/Downloads/atom{1,2}.png
2024-10-11T11:47:39.031943Z  INFO run_migrations: autost::migrations: hard linking attachments out of site/attachments
2024-10-11T11:47:39.137328Z  INFO autost::command::attach: created attachment: <attachments/d9c42006-07ca-4027-8abb-dfa670a7e637/atom1.png>
2024-10-11T11:47:39.137477Z  INFO autost::command::attach: created attachment: <attachments/887df41f-a1ce-4e66-8a9f-09ef1f6fedca/atom2.png>

warning: autost attach does not strip any exif data yet, so be careful not to leak your gps location in any photos you upload! use exiftool or a photo editor to check.

the atom output is also way better now! most importantly, threads with multiple posts are no longer an unreadable mess:

note that your subscribers will need to convince their clients to redownload your posts, or unsubscribe and resubscribe, to see these effects on existing posts.

subscribe here for updates, or email me on autost@shuppy.org if you have any questions. enjoy :3

Natalie wrote:

Once I add the ability to embed arbitrary blog posts from other blogs on here it's over. I'm gonna be reblogging like a wild animal. Y'all are gonna have your eyes blown clean outta your heads.

Thrilled to announce that I now have this up and running, at least in its most basic aspect. The embed above is automatically generated and pulled down directly from the source post. Nothing in this is specific to my blog; I can also do it with someone else's. By way of example, please enjoy this post from my beautiful wife:

Liz wrote:

there is a very specific feeling of relief upon realizing I don’t need to hurry to finish a library book before it’s due, because I definitely will want to buy a copy for future reference and cross-checking.

(the book in question is Gossip Men: J. Edgar Hoover, Joe McCarthy, Roy Cohn, and the Politics of Insinuation by Christopher M. Elias)

Injecting embeds

Here's what the embed looks like in my blog source right now:

{% genericPost "https://nex-3.com/blog/once-i-add-the/",
    time: "2024-09-20T07:06:00Z",
    tags: "#meta",
    author: "Natalie",
    authorUrl: "/",
    authorAvatar: "/assets/avatar.webp" %}
  <p>
    Once I add the ability to embed arbitrary blog posts from other blogs on
    here it's over. I'm gonna be reblogging like a wild animal. Y'all are gonna
    have your eyes blown clean outta your heads.
  </p>
{% endgenericPost %}

I have a template for the embed, some CSS to style it, and a little custom Liquid tag to bring it all together. But the real magic is in how I generate the genericPost in the first place. Here's what the original source looks like before I run my embed injector on it:

 
https://nex-3.com/blog/once-i-add-the/

That's it! Just a URL surrounded by empty lines. The injector pulls down the webpage, extracts critical information about the blog post, and replaces the URL with a call to genericPost. My Letterboxd and Cohost embeds work the same way, with their own custom templates and metadata that let me match the style of the original websites.

Structured post data with h-entry

But I did say that this wasn't specific to my blog. With Letterboxd and Cohost, I've just hard-coded their HTML structure. I can't rely on that if I want to get information from any old blog, though. They all use different HTML structures!

So instead, I'm making use of the h-entry microformat. This is a tiny little specification that defines a way to mark up an existing post to indicate metadata in the existing HTML structure. At its simplest, it's just a few class names annotated with the HTML. Here's the simplified HTML for the post above:

<article class="h-entry">
  <p class="attribution">
    <a href="/blog/once-i-add-the/" rel="canonical" class="u-url">
      Posted
      <time datetime="2024-09-20T07:06:00Z" class="dt-published">
        20 September 2024
      </time>
      by
      <span class="p-author h-card">
        <span class="p-name">Natalie</span>
        <data class="u-url" value="/"></data>
        <data class="p-logo" value="/assets/avatar.webp"></data>
      </span>
    </a>
  </p>

  <div class="e-content">
    <p>
      Once I add the ability to embed arbitrary blog posts from other
      blogs on here it's over. I'm gonna be reblogging like a wild animal.
      Y'all are gonna have your eyes blown clean outta your heads.
    </p>
  </div>

  <ol class="tags"><li><a href="/tag/meta" class="p-category">meta</a></li></ol>
</article>

Here are the special class names I'm using:

• h-entry wraps the entire thing, indicating that it's a post.
• u-url goes on a link and indicates the post's canonical URL.
• dt-published goes on a <time> element and indicates when the post was made.
• p-author can just be the author's name, but I've made it into a whole h-card with the following metadata:
  • p-name is my name.
  • u-url is my personal URL, which is to say this website.
  • p-logo is the URL of my avatar, so people reblogging me have something to show by my posts.
• p-name isn't used here because this post is untitled, but if it had a title that would be the class for it.
• e-content is the HTML content of the post itself.
• p-category is the name of a tag associated with the post.

Of these, only h-entry, u-url, and e-content are really critical. There are a handful of other features defined in the spec, including a way to indicate which post you're replying to, that you should check out if you're interested. But these are the most critical.

Make your posts rebloggable!

You should do this too! If you can edit your blog's post layout, it's extremely easy. Just add those classes to the appropriate places, and you're off to go. If you don't already have an HTML element for some piece of information, you can add invisible <data> tags like I did above to provide the info to consumers without changing the way your post looks to readers.

Even if your blog doesn't allow you to edit the layout, if you can add HTML to the posts you can do this by hand. There's no need to use the specific <article> or <p> tags I do above... just divs will work. You can even make your rebloggable content different than the original, which I'm planning to do to avoid having my embeds look too weird if they get reblogged.

If you end up adding h-entry support, or even better if you end up making use of mine, drop me a comment and let me know!

shoutout @delan for a lovely carbonara

…and hopefully feed reader?

want to archive your chosts on your website but have too many for the cohost web component? want something like cohost-dl except you can keep posting?

autost is my take on that. you can see what it looks like on shuppy.org:

it’s pretty much a static site generator that can import chosts. some features:

---

• perfect html rendering of your chosts and css crimes
  (css things like bounce and spin work too, but not yet 100%)
• include and exclude specific tags or chosts in your archive
• tag your archived chosts without editing them on cohost
• automatically rename and add tags based on the existing tags
• make new posts with mostly-cohost-compatible markdown
  (there’s even a post composer with live preview! but it’s very much a wip)

i’ve only had a couple weeks to work on this, so it’s not the most polished, and for now you need a bit of command line knowledge to get it going.

but my goal here is to make a blog engine with the same posting and reading experience as cohost, where you can follow people with rss/atom feeds, see their posts on a chronological timeline, and share their posts on yours.

does that vibe with anyone? should i keep working on this? let me know!

some big usability improvements in this one, plus a couple of breaking changes!

breaking changes: cohost2autost no longer takes the ./posts and site/attachments arguments, and render no longer takes the site argument. these paths were always ./posts, site/attachments, and site (#8).

when viewing your site with the server, there’s a compose button now (#7).

---

in the server, you also get a link to your site in the terminal now, and you no longer get a NotFound error if your base_url setting is not /.

you no longer have to type RUST_LOG=info to see what’s happening (#5).

attachment filenames containing % and ? are now handled correctly (#4).

questions and contributions are welcome! if you run into any problems, or want to help out, let me know on github or email me on autost@shuppy.org.

oh and go here for updates once cohost noposts :)

…and hopefully feed reader?

want to archive your chosts on your website but have too many for the cohost web component? want something like cohost-dl except you can keep posting?

autost is my take on that. you can see what it looks like on shuppy.org:

it’s pretty much a static site generator that can import chosts. some features:

---

• perfect html rendering of your chosts and css crimes
  (css things like bounce and spin work too, but not yet 100%)
• include and exclude specific tags or chosts in your archive
• tag your archived chosts without editing them on cohost
• automatically rename and add tags based on the existing tags
• make new posts with mostly-cohost-compatible markdown
  (there’s even a post composer with live preview! but it’s very much a wip)

i’ve only had a couple weeks to work on this, so it’s not the most polished, and for now you need a bit of command line knowledge to get it going.

but my goal here is to make a blog engine with the same posting and reading experience as cohost, where you can follow people with rss/atom feeds, see their posts on a chronological timeline, and share their posts on yours.

does that vibe with anyone? should i keep working on this? let me know!

:/

i love test images for browser engines because they're always like this

source

oh and i’ve updated my contact details!! say hi and send me stuff :3

i had an old website, but for a variety of reasons it really didn’t feel like a good successor to my cohost page. i feel like what i really want is to Continue Chosting next month, just on my own website? (well no, what i really want is cohost, but failing that…)

so i made this! and many of my old chosts are there now too! i’ll need a bit more time to figure out how to actually make new posts (lol) and have them play nice with my old chosts, but hey, now you know where to find me once i do o/

oh and i’ve updated my contact details!! say hi and send me stuff :3

i had an old website, but for a variety of reasons it really didn’t feel like a good successor to my cohost page. i feel like what i really want is to Continue Chosting next month, just on my own website? (well no, what i really want is cohost, but failing that…)

so i made this! and many of my old chosts are there now too! i’ll need a bit more time to figure out how to actually make new posts (lol) and have them play nice with my old chosts, but hey, now you know where to find me once i do o/

• “reticulation” unexplainable term used by the isolated peoples of western australia to refer to irrigation
• “bubbler” the only defensible term for a water fountain
• “since day dot” notionally australian slang. i seem to be the only remaining user
• “footy” clearly refers to rugby league. wtf is afl
• “you won't, you're way scared” isolated to like three schools in brisbane. say it. you won't, you're way scared

late update

• “ekka” does anyone go? it's just a cool public holiday

One of my main goals with my new blog is to preserve the concept of "reposting" that's both a successful and, I think, desirable aspect of the "social network" model. It's a great way to spread visibility of other people's work and engage in conversation across different blogs. It's a big part of why I'm putting so much work into the concept of "embeds", as for Cohost and Letterboxd.

These embeds are quite automated: I just drop a link in my blog and as long as it's one of the supported sites, a little post-processing tool automatically fetches the information and adds it as template params. All in all, I'm pretty happy with this flow, but there's one critical problem: it requires me to write a separate scraper for every website.

The great strength of independent websites for social interaction is that everyone's can be as different as they'd like, but that also means that there's no standard way to understand or interact with them. Even something as simple as "what is the text of the post at this URL" is difficult to answer in general. We'd all hope that everyone would use semantic HTML so perfectly that you could just read the contents of the outermost <article> tag on the page, but the real world is never so pristine. We need a more explicit way to indicate the critical prose and metadata for something that's considered a "post".

I've been rolling this problem around in my head for the past week, and I have what is at least the germ of an idea. The core observation is that RSS and Atom feeds already have all the metadata that's strictly necessary for something like this, but they suffer from being time-limited—their use-case is focused on syndication, so a website can only be expected to have its most recent posts available in such a nice format.

So imagine if we co-opted this format for use in something more persistent. Something like:

<link rel="somens:reblog" href="post.xml">

where the XML file looks like

<?xml version="1.0" encoding="utf-8"?>
<reblog xmlns="https://nex-3.com/somens" xmlns:atom="http://www.w3.org/2005/Atom">
  <atom:link href="https://nex-3.com/blog/once-i-add-the/post.xml" rel="self"/>
  <atom:link href="https://nex-3.com/"/>
  <atom:entry>
    <atom:link href="https://nex-3.com/blog/once-i-add-the/" rel="alternate"/>
    <atom:id>https://nex-3.com/blog/once-i-add-the/</atom:id>
    <atom:published>2024-09-20T07:06:00Z</atom:published>
    <atom:updated>2024-09-20T07:06:00Z</atom:updated>
    <atom:author>
      <atom:name>Natalie</atom:name>
      <atom:uri>https://nex-3.com/</atom:uri>
    </atom:author>
    <atom:category>meta</atom:category>
    <atom:content type="html">&lt;p&gt;Once I add the ability to embed arbitrary blog posts from other blogs on here it&#39;s over. I&#39;m gonna be reblogging like a wild animal. Y&#39;all are gonna have your eyes blown clean outta your heads.&lt;/p&gt;</atom:content>
  </atom:entry>
</reblog>

Do you see my vision? This is mostly just stealing structure from Atom, but with the explicit guarantee that any logical "entries" on the page in question will also exist in the "reblog" XML. Maybe there should be some sort of way to explicitly link the two as well, idk. But in the general case, a page with one post would link to a single-post XML file which could then be used as the source for a reblog. Wouldn't that be neat?

Edit: Something like this already exists! Hooray!

oh and i’ve updated my contact details!! say hi and send me stuff :3

i had an old website, but for a variety of reasons it really didn’t feel like a good successor to my cohost page. i feel like what i really want is to Continue Chosting next month, just on my own website? (well no, what i really want is cohost, but failing that…)

so i made this! and many of my old chosts are there now too! i’ll need a bit more time to figure out how to actually make new posts (lol) and have them play nice with my old chosts, but hey, now you know where to find me once i do o/

oh and i’ve updated my contact details!! say hi and send me stuff :3

i had an old website, but for a variety of reasons it really didn’t feel like a good successor to my cohost page. i feel like what i really want is to Continue Chosting next month, just on my own website? (well no, what i really want is cohost, but failing that…)

so i made this! and many of my old chosts are there now too! i’ll need a bit more time to figure out how to actually make new posts (lol) and have them play nice with my old chosts, but hey, now you know where to find me once i do o/

oh and i’ve updated my contact details!! say hi and send me stuff :3

i had an old website, but for a variety of reasons it really didn’t feel like a good successor to my cohost page. i feel like what i really want is to Continue Chosting next month, just on my own website? (well no, what i really want is cohost, but failing that…)

so i made this! and many of my old chosts are there now too! i’ll need a bit more time to figure out how to actually make new posts (lol) and have them play nice with my old chosts, but hey, now you know where to find me once i do o/

oh and i’ve updated my contact details!! say hi and send me stuff :3

i had an old website, but for a variety of reasons it really didn’t feel like a good successor to my cohost page. i feel like what i really want is to Continue Chosting next month, just on my own website? (well no, what i really want is cohost, but failing that…)

so i made this! and many of my old chosts are there now too! i’ll need a bit more time to figure out how to actually make new posts (lol) and have them play nice with my old chosts, but hey, now you know where to find me once i do o/

what if rss or atom had a way to say that a post was in reply to another post from another feed. and feed readers let you display posts in threaded order

• EMAILS WERE NOT SUPPOSED TO HAVE BUTTONS
• YEARS OF COMMUNICATING yet NO REAL WORLD USE FOUND for more than text/plain
• Wanted to style content anyway for a laugh? We had a tool for that: It was called "WEBSITES"
• "Yes please embed an IMAGE in my email. Please use MULTIPLE FONTS in it" - Statements dreamed up by the utterly DERANGED

I can’t agree more  J

signed: a guy who lost points of sanity having to fork HTML parsers to explicitly not crash on non valid HTML in emails because, well, Gmail parses it fine so I have to parse it fine too

• EMAILS WERE NOT SUPPOSED TO HAVE BUTTONS
• YEARS OF COMMUNICATING yet NO REAL WORLD USE FOUND for more than text/plain
• Wanted to style content anyway for a laugh? We had a tool for that: It was called "WEBSITES"
• "Yes please embed an IMAGE in my email. Please use MULTIPLE FONTS in it" - Statements dreamed up by the utterly DERANGED

As proposed by alex norris of webcomic name:

https://webcomicname.com/post/758899080600715264

transcription of the linked comic, for the screen readers

Three-pane comic titled "learning", from "webcomic name" (alex norris):

1. Pink blob is sitting in a pile of books. Their face is obscured by the book they are currently reading, and only their oversized head is visible, implying a huge brain. Orange blob smiles and says: "you must understand the world so well".
2. Pink blob puts away the book, revealing their expressionless face with hollow eyes (idk how to put it, but pink blob looks like they've seen some shit). Pink blob replies: "the more I learn, the more confusing and complex everything is to me". Orange blob is no longer smiling.
3. Pink blob starts emitting smoke, raises their arms in despair, and their face turns ever so slightly angry, as they say: "I overstand". Orange blob: "oh no".

Examples:

• someone who "overstands Unicode" will be unable to answer a question like "how do I count the number of characters in a string"
• I "overstand CDs" ever since I figured out how to create a complete disc image of a CD-RW on Linux
• the Myst community "overstands Myst lore": when you ask an innocent question about the red and blue books, you'll get 25 replies citing something a developer once said in the 90s on a defunct mailing list

... I'm actually having a hard time coming up with good examples, because most of the ones I can think of are complicated or obscure enough that I can't explain them in one sentence 🙃

VTOL means Vermont: Take Off and Leave

there are no high-quality image versions of these stickers that i could find online (they're the Pharmaceutical Society of Australia's "Cautionary Advisory Labels") so i had to make my own (well, didn't really have to, just wanted to). and then i noticed this incredible coincidence.

network telephone service access code test number at VXG 4 MSC.

(details)

@delan: sous vide? that's where you like boil a bag right

@bark: like, you're not wrong. but it's the kinda thing someone who's only /seen/ sous vide would say. you've never done sous vide. you've only seen someone do it. you've seen someone put some Meat in a Bag and then dunk it in some water. it's like you're not allowed within 400 feet of a sous vide. like you've only perved on sous vide through a window. you know how they say "10000 ft perspective"? this is. this is so much further than ten thousand feet. i think an alien who saw sous vide all the way from their planet in space would be able to tell me more

this concludes our intensive three week course

“she’s a real gooner in the doona” — hypothetical review of yours truly

how many meanings can one tag have?
the most i’ve found is #goon, with four (4)

• goon, as in gooning, goon cave, etc
• goon, as in boxed wine
• goon, as in something awful user
• goon, as in henchman

https://www.youtube.com/watch?v=idOy3p5opcQ

ty @srxl for getting me back into osu :3

SPARCstations have a unique serial-like interface for keyboard and mouse input, using a single 8-pin mini-din port. usb3sun allows you to use an ordinary usb keyboard and mouse with your sun workstation, and now rev B0 is available on tindie!

this revision has been all about polish, with improvements to reliability and debuggability. we’ve fixed bugs where resetting the adapter drops you into an ok prompt (#2) and (rarely) hangs until power cycled (#11), and you can now use the debug uart without disabling the sun keyboard interface (#10).

we’ve also added a fun new debug cli, allowing you to send keyboard and mouse input to the workstation via the (now always accessible) debug uart. while it doesn’t yet support all possible inputs, you can already use this as a limited form of automation!

▶

since we still have a few rev A3 adapters left in stock, those are now 20 USD off on tindie. rev A3 is affected by the reset errata, and lacks support for debugging with the sun keyboard interface enabled, but for most people it should still be more than usable.

print your own enclosure

legodude designed a 3d-printed enclosure for the usb3sun! it should be compatible with all boards rev A1 and newer, though it doesn’t currently provide access to the debug header or led indicators.

break preventer (#2)

when resetting older adapters, the workstation would drop you into an ok prompt. this pauses the running operating system (or program) until you type “go” to continue, but programs don’t always handle that well. for example, on solaris running X11, the screen contents may get mangled and it may even kernel panic if booted over nfs.

sun workstations are designed to pause when the keyboard is disconnected and reconnected. they do this by detecting if the keyboard tx line goes from the “break” state to the “idle” state. there are actually only two symbols ever transmitted over a serial line, “mark” (1) and “space” (0), so what are “break” and “idle”?

the receiver (workstation) holds the line in “space” (0) by default, but the sender (keyboard), if present, holds the line in “mark” (1) by default. since every frame starts with a “space” (0), we know that nothing is being sent if there are no spaces. this is known as “idle”.

since an 8N1 serial line also guarantees at least one “mark” (1) every ten symbols, the receiver can infer that nothing is connected if the line is “space” (0) for longer than that. this is known as “break”.

but the workstation also pauses when we reset our adapter, because during reset, INT_KTX is floating, leaving our level shifter to its default state of high, which in sun’s inverted serial logic means “space” (0). this is indistinguishable from a break.

we fixed this by adding a mosfet that pulls INT_KTX low unless the firmware asserts KTX_ENABLE#. during reset, KTX_ENABLE# is deasserted by a pullup resistor.

display external reset (#11)

resetting older adapters can also make them hang until power cycled, especially if you mash the reset button several times in quick succession. you’ll know when this happens because the pico’s onboard led indicator will be stuck on.

this happens because the display module malfunctions, holding SDA low so we can’t send anything. while the SSD1306 itself has a reset pin, the 4-pin display modules that we use do not, so there’s no way to reset them when they malfunction.

we fixed this by adding a mosfet that acts as an external reset, disconnecting the display from ground unless the firmware asserts DISPLAY_ENABLE. during reset, DISPLAY_ENABLE is deasserted by a pulldown resistor.

pinout v2 (#10)

for proper debug logging that includes deps like tinyusb and arduino-pico, we need to use our serial debug port (UART_TX and UART_RX). logging over usb cdc is fragile, breaks when stepping through a debugger, and for tinyusb it would also be a chicken-and-egg.

to avoid a chicken-and-egg inside arduino-pico, we need to use a hardware uart specifically, because everything other than the hardware uart module itself, including the other serial modules, expect that they can use debug logging for errors.

we’re already using both hardware uarts for the sun interface — one for the sun keyboard (sunk) and one for the sun mouse (sunm), so we need to move one of those to SerialPIO, a pio-based uart. but some pio resources are already taken up by usb and the buzzer (as of this commit):

• pio0 has 4 sm (state machines) and 32 instructions
• pio1 has 4 sm (state machines) and 32 instructions
• usb tx needs 1/4 sm and 22/32 instructions within one pio unit
• usb rx needs 2/4 sm and 31/32 instructions within one pio unit
• buzzer needs 1/4 sm and 9/32 instructions within one pio unit
• SerialPIO tx needs 1/4 sm and 6/32 instructions within one pio unit
• SerialPIO rx needs 1/4 sm and 7/32 instructions within one pio unit

let’s play the world’s most annoying bin packing game!

the state machines fit easily, e.g. (1+1+1)/4 sm on pio0, (2+1)/4 sm on pio1.

the instructions? not so much. even ignoring the split between pio units, 22+31+9 = 62/64 instructions, which leaves no space for 6 or 7 more, so we need to move the buzzer back to hardware pwm.

now we’re at 22+31 = 53/64 instructions, again ignoring the split, which is enough for 6 or 7 more, but not 6 and 7 more, so we can only move one tx or one rx to pio, not both.

but moving one rx to pio would not be useful for debug logging, so we can only move one tx to pio, not both or just one rx.

uarts operate at a single baud rate in both directions, which is 1200 baud for the sun keyboard, so if we move sunk tx to pio, the debug port would need to run at 1200, not 115200 baud. this is not a problem for the sun mouse, which has no rx, so we need to keep the sun keyboard on a hardware uart while moving the sun mouse to pio.

this gives us 1+2+1 = 4/8 sm and 22+31+6 = 59/64 instructions, which we can split such that pio0 has 1+1 = 2/4 sm and 22+6 = 28/32 instructions, while pio1 has 2/4 sm and 31/32 instructions. so we’re done right?

ahaha no, of course not

in our pcb, the debug port was on UART0, the same hardware uart as the sun keyboard, so we need to move either the debug port or the sun keyboard to UART1.

since the hardware uarts have restrictions on which pins you can use them with, and none of the pins can be used with both uarts, that means both of them were wired to pins only valid for UART0, so we’ll also need to change our pcb.

older versions of adafruit tinyusb, prior to these commits that were completely unrelated to debug logging, only supported debug logging to Serial1 (UART0), so i figured it was preferable to move the sun keyboard to UART1 while keeping the debug port on UART0.

so altogether, here’s what we had to do…

• move the buzzer from pio to hardware pwm
• keep UART_TX and UART_RX on GP0/GP1 (UART0)
• move sun mouse tx from GP8 (UART1) to GP14 (SerialPIO)
• move sun keyboard tx/rx from GP12/GP13 (UART0) to GP8/GP9 (UART1)
• tie a new PINOUT_V2 pin (GP7) high to let the firmware know that we’re on the new pinout, so the same firmware can be used for both old and new boards

→

…and here’s how we made the pcb changes!

adobe acrobat just gave me a loud audible notification to make it my default pdf reader.
it is 2am. i have not opened a pdf since turning this computer on. wh-

this has been your first warning.

1. e4 e5 2. Nf3 Nf6 3. d4 d5 4. Nc3 Nc6 5. Qe2 dxe4 6. Nxe4 exd4 7. Nxf6# 1-0. wat

hehehe i'm totally lying on my back with my pawsies in the air holding up a toy so happy

Like this

Listen I need people to know about this. This is widely-known in culinary circles but the general public has not been properly informed of how this works.

In industrial pasta making, pasta dough is forced through a shaping tool known as a 'die' and extruded into shape. Traditionally, these dies are made out of machined bronze; bronze is food-safe and dissipates heat well, which is important because those dies get quite hot as large volumes of dough are forced through.

More modern dies are made out of steel and coated with Teflon, which extends their usable life and is cheaper. It also allows the machines to just push more volume of pasta out.

The bronze dies essentially impart their tool marks from the machining process onto the extruded pasta, creating a roughened texture full of micro-scale scratches. The PTFE-lined dies, predictably, don't.

You can tell this, of course, if you compare a Barilla fettucine to a De Cecco fettucine, the latter is just noticeably rougher. These surface imperfections left by the traditional bronze process cause the pasta to 1. shed more starch as it cooks, leading to starchier pasta water that is a more effective emulsifier for sauces, 2. retain a rough microtexture that captures and holds on to sauces better.

As a result, bronze-die pasta just gives you better results even though the ingredient list is identical to that of other pastas.

Pasta that is bronze-cut generally says so on the packaging. Barilla is, notably, not bronze-cut in spite of costing as much as several brands that are.

Everybody wants to talk about the technology of steampunk but never what fuel is needed to run it. It's coal btw. Might as well call that shit coal-fantasy.

"uhhh... oh, that's not coal smoke, it's steam! steam from the steamed punks we're having! mmmm, steamed punks!"

ever since i found out that nuclear plants produce power by just making steam really fast, and therefore nuclear power is also steampunk, i've been so mad about this

hey you don't have to power those boilers with coal OR itanium or whatever. the reason there isn't much old growth forest in the northeastern United States is most of it was chopped down to fuel trains in the 1800s.

“girls could fix me” but in a tone that implies this is not just a hope, but a last resort

i live with this idiot baby

swap art style

_________9

---

solution

...okay so now i'm just gonna put in a load of text that won't show up on-screen but should pad out the off-site embeds (like discord) enough that the solution won't actually get spoiled in the embed hopefully maybe. wouldn't it be great if cohost hid the spoiler tags from the embed text? i think that'd be neat. okay hopefully that's enough padding now fingers crossed. anyway if the embed is still going then *gasp* spoilers, the solution is HORSESHOE

TOILETSIT

oaughhh your clock is too fast. oaaugghh im angry im gonna behave badly. im gonna do wild stuff. oaaguaguauguugg your timing is wrong your routing is bad ouaoiuoiauieuoghh im a silly little fpga

you've heard of predatory journals. now, get ready for prey journals. they're so small. be careful, don't squish them with your huge impact factor

click to play

https://www.desmos.com/calculator/llkjmrdq8q

Fun Microsystems

Sillycon Graphics

※ these words have no meaning, they just popped into my head, and I needed to type them

The spacing and font size is off, but I don’t care :3.

Original logo sourced from: here (the font used is also listed).

The thrilling sequel. Couldn’t think of a funny thing to change “microsystems” to.

❖ ❖ ❖

Original logo taken from here

Font used is “ITC Garamond Book Condensed Italic”.

Feel free to do anything you want with these edited logos btw :3. No need to credit me.

australian chastity cage, call it a Locked Bag

7

6, but also 5

4

3

two (2)

twenty (20) hours

7

6, but also 5

4

3

two (2)

7

6, but also 5

4

3

forljg ulnk fmld when you’re in game, call that a qwksfo h;hkjf

7

6, but also 5

4

7

6, but also 5

This is the same image, as a GIF ready to be imported to Windows 95.
The image looks vertically stretched, because it is rendered with non-square pixels in Windows.

Open in Internet Explorer; right-click, save picture as, and select "BMP File" under type.
Save it, then open it in Paint. Select all, copy.
Open another Paint window, and open \Windows\logos.sys.
Paste over the image, then save it. Shut down to see it in action.

7

belter creole has two language codes, “qbc” and “art-x-belter”. but how?

“qbc” is from the “reserved for local use” area (“qaa” through “qtz”) of the three-letter iso 639-3 language codes, like “eng” for english, “cmn” for mandarin chinese, or “ckb” for sorani. conlang code registry is a project to informally coordinate “assignments” in this area for conlangs, and that’s why belter creole is “qbc”. who knows, maybe someday it will transcend the expanse (2015) and upgrade to a standard code, like toki pona did from “qtk” to “tok”.

this reminds me of cambridge g-rin, a project to informally coordinate “assignments” in the rfc 1918 address spaces, that is, private ipv4 addresses like 10.0.0.1 and 192.168.0.1. in both cases, a public registry that allows anyone who knows about it to avoid taking someone else’s spot.

“art-x-belter” starts with “art”, the iso 639-3 code for “artificial languages”. the “-x-belter” part uses an ietf extension to those codes (bcp 47) that lets you add “private-use” extra details, and that’s why belter creole is “art-x-belter”. internet standards love “x-” for private use. see also http headers like “X-Real-IP” or “X-Forwarded-For”, or mime headers like “X-Spam-Score”.

by the way, another language code with private-use extra details is in the html spec, of all places. thanks hixie :)

<!DOCTYPE html>
<html class="split index" lang=en-US-x-hixie>
<script src=/link-fixup.js defer=""></script>
<meta charset=utf-8>
[...]

https://datatracker.ietf.org/doc/html/rfc6648

i am sorry to report but the internet no longer loves x-headers

The primary problem with the "X-" convention is that unstandardized parameters have a tendency to leak into the protected space of standardized parameters, thus introducing the need for migration from the "X-" name to a standardized name. Migration, in turn, introduces interoperability issues (and sometimes security issues) because older implementations will support only the "X-" name and newer implementations might support only the standardized name. To preserve interoperability, newer implementations simply support the "X-" name forever, which means that the unstandardized name has become a de facto standard (thus obviating the need for segregation of the name space into standardized and unstandardized areas in the first place).

a related example of these problems is on the web platform, with vendor prefixes in css and javascript. they sound like a good way to mark something as experimental, but in practice they just made a mess that forces browsers and webdevs to write everything five times:

-webkit-transition: all 4s ease;
-moz-transition: all 4s ease;
-ms-transition: all 4s ease;
-o-transition: all 4s ease;
transition: all 4s ease;

window.requestAnimationFrame =
  window.requestAnimationFrame ||
  window.mozRequestAnimationFrame ||
  window.webkitRequestAnimationFrame ||
  window.oRequestAnimationFrame ||
  window.msRequestAnimationFrame;

in some cases, we’ve even come full circle with the permanence of vendor prefixes: the standard (and in fact only) way to set the stroke or fill color of text in html is to use -webkit-text-stroke and -webkit-text-fill-color.

nowadays we prefer to put experimental features behind feature flags, requiring either the user to opt in, or a specific website to opt in for a limited time only. this allows webdevs to experiment with these new features as they evolve, without allowing them to rely on the feature in its current state in production. what are you gonna do, tell your customers that they need to change some weird browser setting to use your bank website?

the internet is the only thing in computing we’ve ever built at such a large scale, and this has had fascinating implications for language and protocol engineering.

postel’s law was once considered a fundamental principle of the internet, but we’ve since found that it can cause some gnarly problems with interoperability, and it can even interfere with our ability to make intentional changes and improvements down the line.

speaking of interfering with our ability to make intentional changes and improvements, even well-intentioned extension mechanisms can prove impossible to use in practice. this is known as protocol ossification.

dns is the protocol for looking up domain names like “cohost.org”. names consist of labels, like “cohost” and “org”, and there’s even a special type of label to help with compressing dns messages. but the other two label types, while reserved for future use, are actually impossible to ever use because we forgot to specify how many bits they take up. if no existing dns software knows how many bits to skip, that makes any message containing such a label unreadable from that point onwards.

cryptographic agility, by adam langley, is another great discussion of these problems. tls (née ssl) is an old and complex protocol, with too many ways to extend it and too much flexibility. you can send “extensions” in any order, except you can’t because too much software wrongly expects them in a certain order. you can negotiate from a set of dozens of crypographic algorithms, except that also means a third party can force a downgrade to broken or even more broken algorithms.

langley argues that tls should have had a single, simple extension mechanism, ideally one that controls everything else (which algorithms, what to send, in what order). tls has a version number, which could have been that! except we didn’t bump the version number for ten years, so now tls 1.3 has to pretend to be tls 1.2 because too much software wrongly expects the version to forever be 1.2.

internet engineering is hard.

internet engineering is hard

one of the hardest problems of solving problems of internet scale, other than convincing people the problem exists, is to get them to adopt a solution that actually works—over one everyone believes will work.

take semver

in theory, it solves lots of problems (except for things like "are these two packages the same, which order did these packages get released in, are these two packages compatible, what's the support lifetime of this package, and what features are deprecated", but i digress)

in practice, semver just creates problems: everyone has their own special version selection string parser, and every package ends up with one of three versions: sticking at 0.x and promising nothing, incrementing the number every month and promising nothing, or sticking at 1.x and slowly rotting under the burden of backwards compatibility.

it doesn't matter that we spent the better part of two decades learning that "version number detection is a bad idea", either—because version number numerology is easier to understand, nothing else has a chance.

SPARCstations have a unique serial-like interface for keyboard and mouse input, using a single 8-pin mini-din port. usb3sun allows you to use an ordinary usb keyboard and mouse with your sun workstation, and now rev B0 is available on tindie!

this revision has been all about polish, with improvements to reliability and debuggability. we’ve fixed bugs where resetting the adapter drops you into an ok prompt (#2) and (rarely) hangs until power cycled (#11), and you can now use the debug uart without disabling the sun keyboard interface (#10).

we’ve also added a fun new debug cli, allowing you to send keyboard and mouse input to the workstation via the (now always accessible) debug uart. while it doesn’t yet support all possible inputs, you can already use this as a limited form of automation!

▶

since we still have a few rev A3 adapters left in stock, those are now 20 USD off on tindie. rev A3 is affected by the reset errata, and lacks support for debugging with the sun keyboard interface enabled, but for most people it should still be more than usable.

print your own enclosure

legodude designed a 3d-printed enclosure for the usb3sun! it should be compatible with all boards rev A1 and newer, though it doesn’t currently provide access to the debug header or led indicators.

break preventer (#2)

when resetting older adapters, the workstation would drop you into an ok prompt. this pauses the running operating system (or program) until you type “go” to continue, but programs don’t always handle that well. for example, on solaris running X11, the screen contents may get mangled and it may even kernel panic if booted over nfs.

sun workstations are designed to pause when the keyboard is disconnected and reconnected. they do this by detecting if the keyboard tx line goes from the “break” state to the “idle” state. there are actually only two symbols ever transmitted over a serial line, “mark” (1) and “space” (0), so what are “break” and “idle”?

the receiver (workstation) holds the line in “space” (0) by default, but the sender (keyboard), if present, holds the line in “mark” (1) by default. since every frame starts with a “space” (0), we know that nothing is being sent if there are no spaces. this is known as “idle”.

since an 8N1 serial line also guarantees at least one “mark” (1) every ten symbols, the receiver can infer that nothing is connected if the line is “space” (0) for longer than that. this is known as “break”.

but the workstation also pauses when we reset our adapter, because during reset, INT_KTX is floating, leaving our level shifter to its default state of high, which in sun’s inverted serial logic means “space” (0). this is indistinguishable from a break.

we fixed this by adding a mosfet that pulls INT_KTX low unless the firmware asserts KTX_ENABLE#. during reset, KTX_ENABLE# is deasserted by a pullup resistor.

display external reset (#11)

resetting older adapters can also make them hang until power cycled, especially if you mash the reset button several times in quick succession. you’ll know when this happens because the pico’s onboard led indicator will be stuck on.

this happens because the display module malfunctions, holding SDA low so we can’t send anything. while the SSD1306 itself has a reset pin, the 4-pin display modules that we use do not, so there’s no way to reset them when they malfunction.

we fixed this by adding a mosfet that acts as an external reset, disconnecting the display from ground unless the firmware asserts DISPLAY_ENABLE. during reset, DISPLAY_ENABLE is deasserted by a pulldown resistor.

pinout v2 (#10)

for proper debug logging that includes deps like tinyusb and arduino-pico, we need to use our serial debug port (UART_TX and UART_RX). logging over usb cdc is fragile, breaks when stepping through a debugger, and for tinyusb it would also be a chicken-and-egg.

to avoid a chicken-and-egg inside arduino-pico, we need to use a hardware uart specifically, because everything other than the hardware uart module itself, including the other serial modules, expect that they can use debug logging for errors.

we’re already using both hardware uarts for the sun interface — one for the sun keyboard (sunk) and one for the sun mouse (sunm), so we need to move one of those to SerialPIO, a pio-based uart. but some pio resources are already taken up by usb and the buzzer (as of this commit):

• pio0 has 4 sm (state machines) and 32 instructions
• pio1 has 4 sm (state machines) and 32 instructions
• usb tx needs 1/4 sm and 22/32 instructions within one pio unit
• usb rx needs 2/4 sm and 31/32 instructions within one pio unit
• buzzer needs 1/4 sm and 9/32 instructions within one pio unit
• SerialPIO tx needs 1/4 sm and 6/32 instructions within one pio unit
• SerialPIO rx needs 1/4 sm and 7/32 instructions within one pio unit

let’s play the world’s most annoying bin packing game!

the state machines fit easily, e.g. (1+1+1)/4 sm on pio0, (2+1)/4 sm on pio1.

the instructions? not so much. even ignoring the split between pio units, 22+31+9 = 62/64 instructions, which leaves no space for 6 or 7 more, so we need to move the buzzer back to hardware pwm.

now we’re at 22+31 = 53/64 instructions, again ignoring the split, which is enough for 6 or 7 more, but not 6 and 7 more, so we can only move one tx or one rx to pio, not both.

but moving one rx to pio would not be useful for debug logging, so we can only move one tx to pio, not both or just one rx.

uarts operate at a single baud rate in both directions, which is 1200 baud for the sun keyboard, so if we move sunk tx to pio, the debug port would need to run at 1200, not 115200 baud. this is not a problem for the sun mouse, which has no rx, so we need to keep the sun keyboard on a hardware uart while moving the sun mouse to pio.

this gives us 1+2+1 = 4/8 sm and 22+31+6 = 59/64 instructions, which we can split such that pio0 has 1+1 = 2/4 sm and 22+6 = 28/32 instructions, while pio1 has 2/4 sm and 31/32 instructions. so we’re done right?

ahaha no, of course not

in our pcb, the debug port was on UART0, the same hardware uart as the sun keyboard, so we need to move either the debug port or the sun keyboard to UART1.

since the hardware uarts have restrictions on which pins you can use them with, and none of the pins can be used with both uarts, that means both of them were wired to pins only valid for UART0, so we’ll also need to change our pcb.

older versions of adafruit tinyusb, prior to these commits that were completely unrelated to debug logging, only supported debug logging to Serial1 (UART0), so i figured it was preferable to move the sun keyboard to UART1 while keeping the debug port on UART0.

so altogether, here’s what we had to do…

• move the buzzer from pio to hardware pwm
• keep UART_TX and UART_RX on GP0/GP1 (UART0)
• move sun mouse tx from GP8 (UART1) to GP14 (SerialPIO)
• move sun keyboard tx/rx from GP12/GP13 (UART0) to GP8/GP9 (UART1)
• tie a new PINOUT_V2 pin (GP7) high to let the firmware know that we’re on the new pinout, so the same firmware can be used for both old and new boards

→

…and here’s how we made the pcb changes!