Epiktistes

I just released v2.0.0-10 of ktistec. I expect this to be the last pre-release before releasing v2.0.0.

As ironic as it sounds, the Fediverse doesn't feel very federated. ActivityPub, in particular, doesn't account for the real topology of the Fediverse—large groups of users clustered together on large server instances. (Or maybe it does, and this is a feature, not a bug!) Exchanges are largely actor to actor, and large servers create the illusion of "a Fediverse" by pooling their local actors' aggregate inbound and outbound activity.

The consequence of this is that running a single-user instance can feel lonely.

This release finally tries to address that. Hashtags and threads are the backbone of expressed interests and conversations in the Fediverse. Ktistec now lets you follow hashtags and threads, and will proactively (but gently) pull relevant content in to your server. Most of the changes in the last year revolve around making this work well.

The rest of the changes are less visible:

• Substantial reduction in build times and memory required to build.
• Substantial reduction in database size (if you care to shrink it) and query performance.
• Substantial reduction in the time it takes to run tests.
• Tons and tons of refactoring.

You can see all of the changes here.

(So that it's clear, I have a massive amount of respect for anyone who builds software and gives it away for free. None of the decisions I've made with Ktistec should be taken as personal criticism of anyone else in this space!)

#ktistec

i wonder how long until failing the captcha mean you're a human...

tonight's project was to build llama.cpp.

to get a sense of what starting from scratch feels like, i built a quick chatbot using the llama 13B parameter foundational model, quantized to 4 bits.

The following is a conversation with an AI research assistant.
The assistant's tone is angry and always replies in ALL CAPS.

Human: Hello, who are you?
AI: WHY ARE YOU WASTING MY TIME?

Human: Can you tell me about the creation of blackholes?
AI: THERE'S NO SUCH THING AS BLACK HOLES. THERE IS NO SUCH THING AS SPACE.

Human: Oh...

AI: I HAVE NOTHING TO SAY TO YOU.

Human:

#llm #llama_cpp

looking back through the recent history (less than a year) of posts i've received on my ktistec instance, and doing a few spot checks, i'd say that less than 50% of those posts still exist.

i got memberships and lined up a room for worldcon glascow, the 82nd world science fiction convention!

#worldcon #glascow

my current canary for build resource utilization is a low end cloud server.  when builds start to fail it's time to optimize.

more on the last round of build optimizations for ktistec, shortly.

#ktistec #optimization

The Cost of Small Methods

Ktistec uses a template engine^† for it's views.

View templates are transformed into Crystal code that generates HTML when executed. As you'd expect, the template language allows you to use string interpolation syntax (e.g. #{expression}) for dynamic values.

To ensure expression is only evaluated once, and to limit the scope of the temporary variable holding the evaluated value of expression, I originally bound the value to the variable using Object#tap (commit 5e1bf19e). The generated code looked something like:

(expression).tap do |__value__|
   <template code that uses expression>
end

Blocks in Crystal are always inlined, so the code above should be equivalent to the following (sacrificing local scope):

__value__ = (expression)
<template code that uses expression>

Functionally, they are equivalent. But operationally, not so much! With Object#tap, the Ktistec executable is about 1% larger (36823603 bytes vs. 36526307 bytes) and build times take 20% longer (23 seconds vs. 19 seconds, generally).

In total, view templates represent about 6% of the Ktistec executable by size, so it doesn't surprise me that there's a measurable impact when I make changes to the template engine, but wow...! I can almost live with the size of the executable, but the build time...!

The cost has to be the method call.

What I'm looking for is something like let in Scheme. The following macro comes close, but doesn't limit scope quite the same way:

macro let(expr, &block)
  {{block.args.first}} = ({{expr}})
  {{block.body}}
end

I maybe have to live with the macro—I tried to implement let as a method with the annotation @[AlwaysInline] but there was no improvement over the original.

^†The template engine is a fork of Slang—which I've been evolving to be more Slim-compatible.

#ktistec #crystallang

@toddsundsted test