It's me, and I'm back working on the Zorchpad. This is the brainchild of one Kragen. We have somewhat different, but related ideas for where to take the project. The idea is to make a computer that will continue to work as long as the human using it.

It's been a while (9 months) since I've posted about the Zorchpad. Basically, I developed an ugh field* around the case. I had been designing it in CAD and trying to print 3D versions of it, for approaching 2 or 3 months, and I just got sick of it. I kept getting stuck, and delayed, and etc. The problem was that I was just emotionally burnt out on the whole subject, and unwilling to look at the case, let alone try to make it yet again. (Even though there are probably some pretty easy ways to do it, like cardboard or clay.)

Adam Simonyi to the rescue! I sat down with Adam and woefully begged him to take care of the case for me. And he did!

Blame any aesthetic shortcomings on me -- I pushed him pretty hard on "we're just testing electronics! It should look like shit!

Now I am feeling much better and mostly unstuck. I'm ready to start work on the pad again. <3 Thanks Adam!

Even though no big milestones have been accomplished recently, this seems like a good time to summarize the state of the project.

tl;dr: The power budget is 1 milli-watt. As a bit of context, Kragen's approach to making a computer that lasts a long time is to avoid parts that fail. In his experience (he walks around with pocket computers a lot), this seems to include dead batteries. They're out of charge, or need replaced, or there's no power outlet, or he forgot his charger. So his design does not include a battery. Instead, the whole thing is designed to run on solar cells indoors, and hide any power failures from the user. Think an old-school pocket calculator. So, because we want to run on indoor solar, we have a REALLY small power budget (1 milli-watt). Personally, I think even if you have to run on battery, low power use will still be cool.

This heavily influences our hardware choices. We're experimenting and seeing how it works in practice!

Okay, on to the prototype. Where is it at? Get ready for a dump of how my brain works.

v0.1 Roadmap

• CPU:
  • Priority: (Done)
  • Design notes: Apollo3 system-on-a-chip (on an Adafruit breakout board)
  • Hardware State: Working.
  • Software State: Working.
  • Power: Not tested.
• Keyboard:
  • Priority: Blocking
  • Design notes: We need a low-power keyboard. I'm making a "matrix" keyboard (zero power usage, needs outside electronics). You can buy these premade up to numpad size.
  • Hardware State: Not working. I have a 12x5 plate to put keyswitches into, I have switches, and I have keycaps. I should be able to assemble the hardware. Then I will hand-solder them, following instructions from the custom mechanical keyboard community.
  • Software State: Partially working. Tested with 4x4 keyboard.
  • Power: Not tested.
  • Next step: 3D Print
• Video (Screen):
  • Priority: (Done)
  • Design notes: We need a low-power screen. We selected the SHARP memory-in-pixel display.
  • Hardware State: Working.
  • Software State: Working.
  • Power: Not tested.
  • Next step blocker: Power measurement
• Audio Out:
  • Priority: (Done for v0.1)
  • Design notes: Audio is low-power enough that we can do it for headphones. We are adding an audio jack. This also has the advantage that earbuds are easier to replace than speakers.
  • Hardware State: Working.
  • Software State: Beeps only (with PWM)
  • Power: Not tested.
  • Next step blocker: Power measurement
• Persistent Storage:
  • Priority: High
  • Hardware State: Working (built-in to apollo3)
  • Software State: Working.
  • Power: Not tested.
  • Next step blocker: Power measurement
• Power Switch:
  • Priority: Blocking
  • Hardware State: Trivial
  • Next step: Do it
• Wire reduction:
  • Priority: Blocking
  • Design notes: A 12x5 matrix keyboard needs not (12+5) wires, but 9 wires. Combined with all the other peripherals, that's too many, so we need something like a shift register to reduce the wire count.
  • Hardware State: Not working. Have not found a low-power shift register or alternative.
  • Software State: (Blocked on hardware)
  • Next step: Order parts OR Do it with high-power shifter for v0.1
• Wiring, General:
  • Priority: Blocking
  • Hardware State: Not working. (Plan is jumpers or connectors, with wire ends soldered to boards)
  • Next step: Draw wiring diagram, Order parts
• Power Supply:
  • Priority: Blocking
  • Design notes: The first version will probably just be a AA battery (not solar)
  • Hardware State: Not working
  • Next step: Order parts (AA holder), Check required voltages for all parts, Design schematic

v0.2 Roadmap

• E-ink Screen:
  • Priority: Mid
  • Design notes: I'm testing adding an e-ink display as well, because the memory-in-pixel display goes up to around 3-4 inches diagonal only.
  • Hardware State: Not spec'ed. I have two around the house.
  • Software State: Large screen working on RPi but not apollo3, small screen not working.
  • Power: Probably uses too much power. Looking around for different screens that use less.
  • Next step: Research
• PC Communicator:
  • Priority: High.
  • Design notes: How do we talk to the apollo3 from a normal computer? With the larger apollo3 breakout board, we get a UBS programmer, which solves this for early versions. But we can't measure power usage with USB plugged in, it uses some GPIO pins, and it won't work for the final prototypes with the small breakout board. The main goal is to reprogram the software, not to "talk" and send internet traffic.
  • Power: Not tested (could be net power gain!)
  • Next step blocker: GPIO pins
• Audio In:
  • Priority: Very Low
  • Design notes: (none)
  • Hardware State: The apollo3 may have an integrated microphone, I wasn't clear.
  • Software State: Not working.
  • Power: Not tested.
  • Next step: Research
• Hard Disk:
  • Priority: Low
  • Design notes: First version will use a microsd.
  • Hardware: Not working. If we want a slot (as opposed to soldering to the pads), also not ordered.
  • Software: Not working.
  • Power: Not tested.
  • Next step: Buy parts
• Audio Out:
  • Priority: Mid
  • Design notes: Improve to support voices
  • Hardware State: ?
  • Software State: No voice/music yet. Unclear whether that will need a hardware upgrade.
  • Power: Not tested.
  • Next step: Programming, Testing
• GPIO:
  • Priority: Mid
  • Design notes: To let us hook up new peripherals and/or talk to a computer
  • Hardware State: Not working
  • Software State: Not working
  • Next step blocker: Wire reduction
• Power supply v2: Capacitor buffer:
  • Priority: Low
  • Design notes: The actual power source is solar power or a battery. We want a buffer so that when the power dies, we have enough time to hibernate.
  • Next step: Ask for help
• Power supply v3: Solar power:
  • Priority: Low
  • Design notes: Testing solar panels is high priority to make sure they can supply the right amounts of power, but not actually using them.
  • Next step: Buy panels, Test panels
• Power Use Measurement:
  • Priority: Mid
  • Next step: Ask for help (in progress)
• Battery Level Measurement:
  • Priority: Mid
  • Design notes: Monitor the current battery %/runtime, capacitor %/runtime. Optional: trigger an alert when the battery/solar panel is removed, so we can know to hibernate.
  • Next step: Ask for help
• Clock:
  • Priority: Very Low
  • Design notes: Is this needed for power monitors? If so becomes a high priority.
  • Next step: Research
• Connectors + Sockets:
  • Priority: Low
  • Design notes: I'd like to learn how to make sockets. This enables to use better connectors than jumper wires, slot in more expensive chips like the apollo3 to re-use them across builds, and use displays with flex ribbon cables. It also allows end-user servicability.
  • Next step: Requirements, Research, Order parts
• Circuitboarding:
  • Priority: Low
  • Design notes: We're wiring together a bunch of floating parts with hot glue and jumper wires. Switch to having circuitboards instead at some point. Could be perfboard or traditional printed circuits. Printed circuits could be done with a service or at home.
  • Next step: Design in KiCAD, Print
  • Next step blocker: Connectors + Sockets
• Persistence on Power Loss:
  • Design notes: We're planning to run on solar (maybe also battery). If it's dark, you shouldn't lose state. We should just "pause" until the light comes back.
  • Hardware notes: Blocked
  • Software notes: Difficult. This is an OS-level software problem.
  • Next step blockers: Capacitor buffer, Battery level measurement
• OS / VM:
  • Design notes: We want an OS that stops badly-written software from locking up your machine in unfixable ways.
  • Software notes: Not designed
  • Next step: Write software
• Software:
  • Design notes: We need some test software! Text editor, text reader, software editor/compiler.
  • Software notes: Not written
  • Next step: Write software

I recently read "The Go Programming Language" by Alan A. A. Donovan and Brian W. Kernighan. (I like to imagine Mr. Donovan's full name is Alan Alan Alan Donovan--please don't correct me.) So far I have read the book cover to cover, but not programmed any significant Go.

While reading, I wrote myself a list of questions to look up after I finished. Here are the questions (together with answers).

Q20: Go came out in 2012 with version 1.0. The book was published in 2016 and uses Go 1.5. As of writing it is 2025, and the latest version is 1.24. What has changed in Go since the book came out and now? (Note: Language changes only, no library or tooling changes mentioned)

• 1.6 (2016) - No changes
• 1.7 - No changes*
• 1.8 (2017) - No changes*
• 1.9
  • Introduced type aliases
• 1.10 (2018) - No changes*
• 1.11 - No changes
• 1.12 (2019) - No changes
• 1.13
  • New number literal syntax.
  • Shift count can be signed now.
• 1.14 (2020)
  • Allow overlapping methods for embedded interfaces (solves the diamond problem for interfaces)
• 1.15 - None
• 1.16 (2021) - No changes
• 1.17
  • Allows conversion from slice to fixed-size array pointer (can panic)
• 1.18 (2022)
  • Generics--type parameters can be used in type definitions as well as function definitions.
  • Added type any as a shorter name for interface{}
  • Added type comparable: == works
  • Added union types: A or B or C
  • Added type ~T : ~int is any type whose underlying type is int
• 1.19 - None*
• 1.20 (2023)
  • Allow conversion from slice to fixed-size array.
  • Broading of 'comparable' to include interfaces that might panic at runtime.
• 1.21
  • New built-ins (min, max)
  • New built-in (clear) -- applies or slice or map
  • Type inference improvements which went a bit over my head.
  • Fixed an edge case around panic(nil).
• 1.22 (2024)
  • Fixes the loop iteration gotcha caused by lexical scoping inside loops. (Previously, there was one loop index which was updated -- now a new variable is created and assigned each loop).
  • For loops can range over integers.
• 1.23
  • Added iterator ranges (iterations are functions).
• 1.24 (2025)
  • Type aliases can be parameterized.

Q1: If you try to take the address &map, the compiler prevents you, because the address of a map is its backing store, which can silently change. How is this done? Can I do it for my own types?

Note: You can take the address of &map, just not &map[2].

"It just does that". Map is a built-in type, not an implementation, so it just does stuff you can't. No you can't do it for your own types. There are garbage collection reasons they made it work this way but they're not interesting.

Q2: Can you take the address of a slice? Can the same problem happen?

You can take the address of both &slice and &slice[2].

If append(slice, 599) re-allocates the backing store, the second points to the original backing store, and prevents it from being garbage collected. Also, any changes to it are not affected in the slice returned by append, so you probably shouldn't.

Q3: What are all the forms of for loops?

• for INITIALIZER; CONDITION; POST {} - C for loop
• for {} - Loop forever
• for CONDITION - C while loop
• for index, value := range THING {} or for index := range THING {} or for range THING {}. Range can iterate over:
  • array/slice (index, value)
  • string (index, value) - this is unicode code points ("runes") and not bytes
  • map (key, value) - this is in random order
  • channel (e, N/A) - received elements of a channel
  • Since 1.22: int (index, N/A) - from 0 to N-1
  • Since 1.23: function (T1, T2) - function is called with a "loop body" function, which can be called once with each value, and returns whether to keep iterating
• Note that break and continue affect loops

Q4: What are the signatures of range, if it's a function?

No, it's a keyword (p27, for Go 1.4 see also p141 gotchas). See Q3 for all the range variants, and Q18 for general function overloading.

Q5: Why does Go say -0 is not equal to 0 in the following code?

var z float64
fmt.Println(-z) // Prints -0

IEEE 754 defines a negative zero. Positive and negative compare equal, so code will generally work as you expect. Go chooses to print "-0" rather than "0" for this value in format strings, while other languages print "0" for both.

Additional discoveries:

• int(-z) is 0
• the constant -0.0 is positive zero (!)

Q6: (p98) Why does ReadRune() in invalid unicode return a replacement char with length 1 ? The replacement char has byte length 2. Is this a deliberate signal value?

Yes (no citation)

Q7: What happens if you convert Inf, -Inf, NaN, or a float too large to fit into an int, to an int? Book claims conversions don't panic.

All of them are converted to

• uint/uint64: 2^63 = 9223372036854775808
• int/int64: -2^63 = -9223372036854775808 (even +Inf and 1e200)

I don't know why these particular values. I have asked on Stack Overflow

Q8: In Go, can you marshal functions or closures?

No.

Reflect does not support it (and so neither does json.Marshal, etc). I couldn't immediately come up with a way even to distinguish closures and non-closures, or get the name of a function. You can get a function pointer and then do some heuristics to get the name, maybe.

Q9.1: How do map literals work for non-strings?

map[Point]string{Point{0, 0}: "orig"}
    or
map[Point]string{{0, 0}: "orig"} // Names can be left out of keys or values in map literals

Q9.2: Can I make user types with this mechanism? (ex. my own literal initialization)

No. Literals are only for built-in types, and the mechanism is not extensible. (But you can have the underlying type be a map an initialize your type with one.)

Q10: Struct fields can have metadata ("struct tags"). Can whole types?

No.

Q11: How does ... variadic notation fail if the slice can be too short to fill all arguments? Is it only allowed for the variadic argument or can it span multiple?

Yeah, you have to match it with the variadic argument.

Q12: Thomson, Pike, Kernighan, Richie -- fill in a Venn Diagram of what they made/wrote.

• Ken Thompson: B, Unix, Plan 9, Go, regexes, UTF8, QED, ed, chess endgames, Inferno, "Reflections on Trusting Trust"
• Dennis Richie: B, C, Unix (inc. man pages?), Plan 9, Inferno, Limbo, "The C Programming Language"
• Brian Kernighan: awk, "The C Programming Language" (including "Hello, world!"), "The Go Programming Language", "The Elements of Programming Style", "The Practice of Programming", "The Unix Programming Environment"
• Rob Pike: Plan 9, Go , Inferno, Limbo, Newsqueak, sam, acme, Sawsall, "The Unix Programming Environment", "The Practice of Programming"

Q13: What order are deferreds called in?

Last in, first out. Then exit the function, and so on up the stack.

Q14: What happens if a panic happens, a deferred is called, and the deferred panics?

It prints nested panics informationally, but continues to pop the deferreds

Q15: map[x] = y panics if map is a nil map, but slice = append(slice, 1) works fine if slice is a nil slice. Why? I feel like I'm being nickle-and-dimed by Go that the zero value panics.

Both slice and map suck if they're nil. It's just that slice is so bad (normal use case of append panics even for non-nil values) that they added a library append function, which happened to deal with the nil case too.

You can write a map_set which returns a new map much like append. You can't write a better map, because there's no operator overloading (see also Q17)

Q16: Why is the *p vs p method consistency principle a thing?

Because a.Method() notation sugars between the two, but interfaces don't. You want at least one of *p and p to support an interface.

Q17: Is there operator overloading?

No.

And Go has a broader principle that none of the core language calls any specific method name (String(), Error(), etc), which came up in the 1.23 iterator design.

Q18: Is there function overloading? (range, map.get, json.Marshal, type assertion)

Map lookup, type assertion, and channel receive are keyword-level overloading, not functions. They are special cases.

In general, a function has to take the same number of inputs and return the same number of outputs, of the same types. There is one exception, which is that one of the inputs can be variadic--for example, the built-in function make.

1.6 (2016) answer: BUT, you can "return" a generic type like interface{} (which the user has to cast unsafely to the right type) or modify one of the inputs (which can be something like interface{}). The latter is how json.Marshal works and knows what type to deserialize. To compliment this, you can do runtime inspect of types through a select statement or the reflect module.

1.18 (2022) answer: Same for number of arguments, but also functions can now be generic (ex. type A -> A). If only the return type varies, you can use named returns to do stuff with the return type. See Q24 also.

Q19: Does Go have parametric polymorphism?

1.6 (2016): No.

1.18 (2022): Yes.

Q21: Can I extend someone else's package after the fact? (ex. add new methods to json, perhaps to make it support some interface)

No. (But you can do type and interface embedding.)

Q22: What happens if I call defer inside a defer function or during a panic?

It works normally, either way.

If you create an infinite loop of deferred functions (with or without infinite panics) it does a stack overflow, and it's not obvious it was mid-panic immediately.

Q23: (p208) Why does .( type assertion return one OR two things depending? Did not seem to cover in multiple return assignments.

See Q18.

Q24: Can type switching do slices, maps, arrays, etc? (p212)

1.6 (2016): No. You need to use reflection.

1.18 (2022): Unsure. Generics were introduced, and I don't know how they interface with type switching. I think type switches only take (fully-specified) concrete types in the case statements?

Q25: Does Go have a preprocessor or macros?

No to both.

Q26: TODO: Read proposal that caused unix pipes

There wasn't a written one, I was misremembering Douglas McIlroy's suggestions as being a formal memo. The v3 vs v4 pipeline description seems interesting to compare, however. See v3, 1973 notation (p121-123, 3 pages) vs v4, 1973 (p98, one paragraph).

Q27: Is 'make' a keyword? What args does it take for each type? (Can I change what it takes for my types)

Both make and new are built-in functions, not keywords. make takes a type, and optionally size parameters, and returns that type. new takes a type and returns a pointer to a new variable of that type.

• make(CHANNEL\_TYPE, size) - size defaults to 0
• make(SLICE\_TYPE, size, capacity) - capacity defaults to size. (no default for size?)
• make(MAP, starting size) - starting size defaults to something reasonable
• new(TYPE) - only one form

Q28: Can you write 'map' in Go? (or something to join two channels)

1.6 (2016): Only awkwardly, using reflection (see Q19). Map could have the signature: map(in_list interface{}, f interface{}, out_list interface{})

1.18 (2022): Yes, both. Generics got added.

Q29: Are CSP in Go + Erlang basically the same model?

Not sure, didn't look this one up. But basically no, even if the deeper model is the same.

• Erlang has out-of-order reading, indefinitely growing channel size, one unidirection 'channel' per process, and the notion of 'links' between processes to cause cascading failure.
• Go has channel closing, and the notion of a specific channel size (which defaults to 0), so it's more synchronous by default.

Q30: Why is there a & in memo := &Memo{request: make(chan request)} on p278, when I thought you couldn't address constants (p159)?

It's a special case for & and new only. From Stack Overflow:

Calling the built-in function new or taking the address of a composite literal allocates storage for a variable at run time. Such an anonymous variable is referred to via a (possibly implicit) pointer indirection.

Suggested exerciae 31: (p280) Test # of goroutines and stack sizes before crash

Knock yourself out.

Suggested exercise 32: Test # of bits in an int/uint

^uint(0) >> 63 == 1

Q33: How do you detect int overlow (signed or unsigned) in Go?

You can't. There is a library for it

While reading the book, I noticed three big problems in Go that popped out to me.

• The gotchas around for-loop scoping (fixed in 2024)
• The lack of generics looked really painful (fixed in 2022). Functional programming looked pretty impossible (annoying, since Go lets you pass around functions and even closures), and it looked hard to glue together channels at a high level. The book's example of memoization code was pretty bad. This mostly seems all fixed (although I'm not sure how to test "A is a B" for non-concrete B at runtime).
• The number of built-in panics looked bad. In particular, I though the default value for map being nil, which panics when you try to insert something, was a dumb default. Now that I learned more, I think it's a dumb default and the default slice is dumb too.

Adding generics to the language made me much more likely to give it a whirl.

References:

[1]: https://go.dev/play/ "The Go Playground"

[2]: https://go.dev/doc/#references "The Go Documentation"

[3]: The Go Programming Language, by Alan A. A. Donovan and Brian W. Kernighan

I finished the text editor I was working on to learn OCaml.

It's (tentatively) called textmu. The selling point is that it's designed for multiple users, all SSH-ed into the same machine, to edit a document collaboratively. Otherwise, I basically made it a simplified knockoff of nano.

Source code is on github.

If you'd like to try it out (and don't want to compile it locally), feel free to get an account on my public server, tilde.

Also, an update. The OCaml folks said it's fine to publish their book, so you can now get your own copy if you want one (link goes to updated blog post with photos).

Update: the book is available for sale on Lulu to the public. Volume 1 and Volume 2.

Recently I've been teaching myself new programming languages with books. I got one for D, Elixir, Erlang, and Go.

OCaml was also on my list of languages to learn, but there is no good OCaml book available. I started reading an online course textbook (for Cornell's CS 3110), only to find it painfully slow, beginner-level, and aimed at course tools besides. Eventually, I found the official OCaml manual to be the best source of information.

Unforunately, there is no published version of the manual. It is available online as HTML, PDF, or even a text file, but that's all. So, I went to Lulu and published my own copy of their PDF.

The PDF is so long I split it into two volumes. I'm pleased by how the manual turned out, though I haven't actually used it much for reference -- I've already spent two weeks programming OCaml before it arrived (Lulu is not fast).

I've been working on a terminal text editor in OCaml for two weeks. I'll post about that in more detail if and when I finish it.

• Year 0 – I filled 10 32-GB Kingston flash drives with random data.
• Year 1 – Tested drive 1, zero bit rot. Re-wrote drive 1 with the same data.
• Year 2 – Tested drive 2, zero bit rot. Re-tested drive 1, zero bit rot. Re-wrote drives 1-2 with the same data.
• Year 3 – Tested drive 3, zero bit rot. Re-tested drives 1-2, zero bit rot. Re-wrote drives 1-3 with the same data.
• Year 4 – Tested drive 4, zero bit rot. Re-tested drives 1-3, zero bit rot. Re-wrote drives 1-4 with the same data.
• Year 5 - Re-tested drives 1-3, zero bit rot. Re-wrote drives 1-3 with the same data.

Will report back in 1 more year when I test drive 5.

The full test plan is available in the year 4 blog post

FAQ: https://blog.za3k.com/usb-flash-longevity-testing-year-2/

Having prepped my ESP-32, I decided to make an LED fireplace today.

The plan was to put an LED strip on a piece of cardboard, and have slowly shifting red, orange, and yellow lights going up and down, somewhat like a music visualizer. I knew the bare LEDs wouldn't look good, so the plan was to put the cardboard somewhat deep into the fireplace, and add some translucent tissue paper layers in front to diffuse the lights.

Sadly, of my three ESP-32s, two were broken. I ended up instead using an ESP-8266, since I had several laying around. Annoyingly, the boards I have are so wide it's impossible to breadboard the, so I used perfboard instead.

Having carefully set up the circuit, I flipped the on switch and... nothing happened. It was about 10pm at this point, and I was starting to run out of energy, so I gave up.

Very late that night, I found the problem was the resistor I added--the LED strip has a built-in resistor as well, and apparently the two together were too much. I eventually got the lights to turn on, but too late to finish the project for the day.

A while back, I was trying to set up a power monitoring system, and I mistakenly bought the wrong ESP dev board. The ones I ended up are sold by some fake-named Chinese manufacturer. They seem pretty fine, much like any other ESP32 dev board, but they have an unusual 30-pin layout.

I tried to add some electronics to my whiteboard hack earlier this month, but got frustrated pretty quickly, failing to program the microcontroller, and with no idea what the pinout was.

Today I decided to take it slower. I'd figure out how to program it, and understand the pins. If I had any time left over, I'd do a project.

First, I got flashing the chip to work. It turns out my main problem from the first time was a bad upload serial rate. I debugged the problem with the help of friendly folks on IRC. Espressif (the ESP32 manufacturer) has helpful troubleshooting instructions, which suggest using the python serial terminal, miniterm. By taking a step at a time, I got the microcontroller working.

Next, I installed and set up platformio, which I had never used before. My experience was that it was pretty good once set up, but a little hard to get started on the command line. Still, I'm happy, and will probably use it again. Platformio has two options--the popular Arduino framework libraries, or the Espressif-provided esp-idf libraries. Based on the small code samples I found, I'll most likely use the Arduino libraries, but some specialty features are just not available on Arduino.

Finally, I set up platformio one last time, with the VS-Code based PlatformIO IDE. Again my experience was pretty good. Sadly, the open-source VS-Code does not show the same set of extensions, and I had to use the binary version. (Aside: Come on, vs-code. Don't call your package and program code. That's a dick move.)

The writeup of how to get your dev environment set up is on github.

Finally, I made the below pinout diagram with the rest of my night.

Happy hacking!

Today I made a minecraft mod, using Fabric. Modding sure has changed a lot since I last tried it in Forge, maybe ten years ago! Java's changed a little too, even.

My mod adds a dirt slab, that's it. I didn't really have time to get past the basics, but I think the occasional hack that's just a learning experience is okay.

Code and mod download are both on github this time.

Fabric is well-documented and friendly. The main downside is that there's no "abstraction later" between Minecraft and the mod. This means your mod will work with exactly one minecraft version on release. Additionally, when a new version of minecraft is released, you need to update and re-release your mod (and there are usually actual changes to be made).

Tutorials used:

• Fabric wiki
• Fabric documentation
• Changelog
• Fabric Discord Server

I made a coding challenge, vaguely tied up as a game. Your goal is to complete simple coding challenges, with a major twist--you only get one try. You can only hit RUN once. (Well, actually you can hit RUN more than once. But it gets marked as failed.)

It put together about 10 challenges, together with some story narration.

The game problems are now tested.

You can play online. The code is on github

One feature I really liked about older ThinkPad models was that when you plugged in power, it would give a little chirpy beep. Same when you disconnected it.

The downside to system beeping is that it gets really annoying. I don't want a failed tab completion to go "beep" aloud, especially when I'm in public.

I aggressively turn off all kinds of system bells, etc. Sadly, I get no beeps either.

Today I wrote a little python script to monitor power beep how I want. It plays it through my computer speakers (unmuting them if needed, just long enough to beep). It works for me on both ALSA and pulseaudio with an ALSA bridge (I have a few computers on each).

My default settings are:

• Two falling tones when power is unplugged
• Two rising tones when power is plugged back in
• Two warning beeps when the lowest battery reaches 10% (my laptop has two)
• Three warning beeps when the lowest battery reaches 5%.

Source code is on github if you want to use it too. To change the thresholds or beeps, you'd have to change the code. No fancy configs, sorry!