FeepingCreature

#!/usr/bin/env python3
# Helper script that classifies the structure of a JSON object.
# Useful for getting an overview of novel JSON data.
# Created largely by Claude 3 Opus.

import json
import sys

class JSONType:
    def is_similar(self, other):

FeepingCreature

The D GC

The D GC is tuned by default to trade memory for performance. This can be clearly seen in the default heap size target of 2.0, ie. the GC will prefer to just allocate more memory until less than half the heap memory is alive. But with long-running user-triggered processes, memory can be more at a premium than CPU is, and larger heaps also mean slower collection runs. Can we tweak GC parameters to make D programs use less memory? More importantly, what is the effect of doing so?

Adjustable parameters

FeepingCreature

You are doing JSON APIs wrong.

When you use JSON to call an API - not a REST API, but something like JSON-RPC - you will usually want to encode one of several possible messages.

Your request body looks like this:

{
 "type": "MessageWithA",

FeepingCreature

        auto service1 = ...;
        assert(service1 !is null);
        Service[] services = [service1, service2];
        assert(services[0] !is null); /// this fails??

FeepingCreature

module test;

import core.memory : GC;
import core.sync.semaphore;
import core.sys.linux.sys.mman : MADV_DONTNEED, madvise;
import core.thread;
import std;

enum keys = [
    "foo", "bar", "baz", "whee",

FeepingCreature

module test;

import core.memory : GC;
import core.sync.semaphore;
import core.thread;
import std;

static string[] keys = [
    "foo", "bar", "baz", "whee",
    "foo1", "foo2", "foo3", "foo4", "foo5", "foo6", "foo7", "foo8",

FeepingCreature

module test;

import core.memory : GC;
import core.sync.semaphore;
import core.thread;
import std;

static string[] keys = [
    "foo", "bar", "baz", "whee",
    "foo1", "foo2", "foo3", "foo4", "foo5", "foo6", "foo7", "foo8",

FeepingCreature

int main() {
    unsigned char *target = mmap(NULL, 1024, PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
    Buffer buffer = {target, 1024, 0};
    char *param = "Hello World\n";
    void (*fn)(char*) = (void(*)(char*)) printf;
    append_x86_64_push_reg(&buffer, X86_64_RBP);
    append_x86_64_set_reg_reg(&buffer, X86_64_RBP, X86_64_RSP);
    append_x86_64_set_reg_imm(&buffer, X86_64_RDI, (size_t) param);
    append_x86_64_set_reg_imm(&buffer, X86_64_RAX, (size_t) fn);
    append_x86_64_call_reg(&buffer, X86_64_RAX);

FeepingCreature

# bind ctrl-G to "directory up"
bind '"\C-g":"cd ..\C-m"'

# bind ctrl-E to "edit fuzzy"
function edit_fuzzy() {
  TARGET=$(fzf)
  if [ $? -eq 0 ]
  then
    echo -e "${PS1@P}edit $TARGET"

FeepingCreature

SEML - Somewhat Easier YAML

This is a YAML variant intended to avoid having to read the absurdly large YAML spec. Every SEML document is also valid YAML, but not the reverse.

Each file corresponds to a JSON value. To avoid the Norway problem and similar issues, all values are parsed as strings.

This is version 1.0 of the SEML spec.