Hello babe. I've started taking the Metformin and got past the initial side effects (bad stomach ache), although it might be messing with my sleep.

I do feel better this week (five days in, maybe?), nothing I can put my finger on, but definitely better. (Still all fatigued though).

Hubs has given me the Fitbit Charge 6 they bought themselves a couple of months back. I've had it on for less than a day so far, no initial thoughts further than it's easy to wear.

$WORK is being stupid, we're coming to the end of a project and there's not enough work for the team. This wouldn't be a problem, except I don't feel right getting on with $PROJECT stuff on work time.

Overall, doing ok.



Comparing C# and JavaScript Syntax

Simple statements

The syntax of simple statements are identical.

for ([initializer]; [test]; [increment]) {
  ...
}

[initializer]
while ([test]) {
  ...
  [increment]
}

if ([test]) {
  ...
} else if ([test]) {
  ...
} else {
  ...
}

Variables

JavaScript is dynamic typed, meaning that any given variable can hold any type of value. C# is static typed, so variables get a type at creation time and can only accept values of the correct type.

Variables in JavaScript are declared with one of three keywords: var, let, const. C# also uses var to declare variables, but they have different meanings.

var in C# tells the compiler to infer the type of the variable from context, e.g. in the statement var x = "string";, x can only be a string type.

var in JavaScript creates a variable that can be used anywhere in a function (the variable definition is hoisted to the start of the enclosing function).

Comparison

Comparison of values is one of the places where JavaScript and C# diverge due to the static/dynamic natures of the languages.

Because JavaScript can only know the type of a value at runtime it relies on type coercion to force values to be the same type. It is therefore safe in JavaScript to compare e.g. a string and a number, because the runtime will coerce the number to a string. However, this leads to unexpected results, so modern JavaScript provides an === operator that does not coerce the values, and so different typed values will not match (e.g., "1" == 1 is true, but "1" === 1 is false).

Functions

Calling a function is mostly the same in both languages: result = function(arg1, arg2). Of course, in C# result must be the correct type (or the code won't compile).

C# won't let you call a function with the wrong number of arguments, or arguments of the wrong type. JavaScript will pass along to the functions any arguments you provide, filling in missing arguments with 'undefined' and adding any extra arguments onto the end of the formal parameters. (You can access extra arguments through the arguments array).


I don't think c# is the right language for an activity pub server. There's to much "fuzzy" - properties that could be a list or a string, or one of a bunch of broadly similar types that aren't really sub-types.

If I had a JavaScript engine I was happy with, that could work, but I don't.

F# feels like it's probably a good fit, and this is probably the right size of project to start with, but I'm not sure. F# feels like a "write only" language (like Scala) in that it's very dense and the compiler picks up much of the slack, so getting a hook into understanding code is tickets.

I'm tempted by C. I can write a basic JSON parser (which knows that it's not going to have to deal with extreme cases), but even so it's the same old C problem (that there's just so much more to type)


Of course, even in c# I don't need to parse JSON into a type right away, although I do still need to cope with the "can be an array or string" (and "object or reference") cases.

I could dereference links at parse time, although I'd need to be careful of depth (and cache timeouts).

I still can't believe that the type tree has two roots (Object and Link).


I need to keep the wire format and the database schema separate in my head so I don't keep running into the "link or object"/"list or string" stuff.

The database can store normalised data, and then separately we can stringify and parse as needed, maybe using intermediate types of it makes life easier.

That should push much more of the complexity to the edge, where it belongs.


New thought: Since the protocol is based on "Actions", do I want to do this as an event sourced thing? Keep current state in memory, write events to disk ("Alice Followed Bob", "Bob Posted a thing", only using ids instead of names) and rebuild state at start time?

Doesn't really solve the "What types do I need" problem, but it makes the database schema easier: an event table with (id, verb, id) triples, and an object table with (id, bob) pairs.

Remote objects (anything I'm not hosting) need to have cache properties along with everything else: last updated, last validated, valid until. Management of that can be wrapped in the Dereference call that can pull from the cache or the network (and might want to do something clever like queue requests for an item while a fetch is in progress).


public readonly struct Entity { public long Id { get; init; } }

public interface ISystem { public void Update(); }

public interface IComponent{ public long Id { get; set; } }

public Dictionary<IComponent, IList> EntityComponents


Linux Kconfig

The point is to give Values to Symbols.

Symbols have:

  • name (string)
  • type (bool, trivalue, string, int, hex, range)
  • default (expression)
  • value (trivalue, string, null)
  • dependencies (expression)
  • reverse dependencies (expression)
  • weak reverse dependencies (expression)
  • visible (expression)
  • help text (multi line string)

Advanced sleep tracker

A page of buttons for activities

A page that shows the data in the approved format, along with a print option (and print css)

Run only on phone, ideally no network after first download


To remember your current position in the blog, this page must store some data in this browser.

Are you OK with that?