So my previous post documented a couple of simple "scripting languages" for small computers, allowing basic operations in a compact/terse fashion.
I mentioned that I might be tempted to write something similar for CP/M, in Z80 assembly, and the result is here:
0m 16k rP _ _
C3 03 EA 00 00 C3 06 DC 00 00 00 00 00 00 00 00
Numbers automatically get saved to the A-register, the accumulator. In addition to that there are three dedicated registers:
M-register is used to specify which RAM address to read/write from.
The instruction m copies the value of accumulator to the M-register.
The instruction M copies the value of the M-register to the accumulator.
K-register is used to execute loops.
The instruction k copies the value of accumulator to the K-register.
The instruction K copies the value of the K-register to the accumulator.
U-register is used to specify which port to run I/O input and output from.
The instruction u copies the value of accumulator to the U-register.
The instruction U copies the value of the U-register to the accumulator.
So the program above:
0m
0 is stored in the accumulator.
m copies the value of the accumulator to the M-register.
16k
16 is stored in the accumulator.
k copies the value of the accumulator (16) to the K-register, which is used for looping.
- Starts a loop.
The K-register is decremented by one.
If the K-register is greater than zero the body is executed, up to the closing brace.
Loop body:
r Read a byte to the accumulator from the address stored in the M-register, incrementing that register in the process.
P: Print the contents of the accumulator.
_ _ Print a space.
End of the loop, and end of the program.
TLDR: Dump the first sixteen bytes of RAM, at address 0x0000, to the console.
Though this program allows delays, RAM read/write, I/O port input and output, as well as loops it's both kinda fun, and kinda pointless. I guess you could spend hours flashing lights and having other similar fun. But only if you're like me!
All told the code compiles down to about 800 bytes and uses less than ten bytes of RAM to store register-state. It could be smaller with some effort, but it was written a bit adhoc and I think I'm probably done now.
Recently I was looking around the internet and looking for something to do with some ESP8266 devices, which I've been neglecting over recent years.
When I was on paternity-leave, five years ago, I decided I wanted a new hobby for my "down" time. I had two obvious choices a) developing applications for mobiles, or b) working with "hardware". I chose the latter.
By accident I came across a couple of simple scripting languages, FORTH-esque. Sample usage looks something like this (which obviously sends the command over a serial-device to the connected-board):
$ echo '5 6d 1o 100m 0o 100m ' >/dev/cu.usbmodem12341
That's a little terse, but briefly:
5 ...
Execute the block five times.
6d
Set the output pin, in the example "D6".
1o
Output "1" to the pin we've selected, D6 in this example.
100m
Delay for 100 milliseconds.
0o
Output "0" to the pin we've selected, D6 in this example.
The end result is a blinking LED, for five iterations anyway. The code for this interpreter is described in the following link, with the code in the linked gist:
This is derived from an older, and simpler, project which has a similar focus but slightly different built-in operations (and which lacks loops/conditionals):
Both of these implementations are very similar, I guess due to the shared history and obvious FORTH-inspiration. Each allows port I/O, delays, and simple math opertions. We can pretend they're stack-based, though there are some differences and some niggles.
I'm kinda tempted to port one of them to Z80 assembly, and see if I can get it running under CP/M. I guess I could add a REPL for interactive use, though without actual hardware connected to my single-board computer it might all feel a little pointless. Then again I have Turbo Pascal, and even a tiny C-compiler, so I guess with those in mind any toy-language is pointless in a completely different regard.
It seems I'm having a theme recently on this blog, of making emacs-related posts. Here's another.
I write a bunch of stuff in markdown, such as my emacs init-file, blog-posts and other documents. I try to be quite consistent about vertical spacing, for example a post might look like this:
# header1
Some top-level stuff.
## header2
Some more details.
## header2
Some more things on a related topic.
# header2
Here I'm trying to breakup sections, so there is a "big gap" between H1 and smaller gaps between the lesser-level headings.
After going over my init file recently, making some changes, I noticed that the spacing was not at all consistent. So I figured "How hard could it be to recognize headers and insert/remove newlines before them?"
A trivial regexp search for "^#" identifies headers, and that counting the "#" characters lets you determine their depth. From their removing any previous newlines is the work of a moment, and inserting the appropriate number to ensure consistency is simple.
I spent 15 minutes writing the initial implementation, which was markdown-specific, then another 30 minutes adding support for org-mode files - because my work-diary is written using the org-diary package (along with other helpers, such as the org-tag-cloud.
Anyway the end result is that now when I save a markdown/org file the headers are updated automatically:
As I've mentioned in the past I keep a work-log, or work-diary, recording my activities every day.
I have a bunch of standard things that I record, but one thing that often ends up happening is that I make references to external bug trackers, be they Jira, Bugzilla, or something else.
Today I hacked up a simple emacs minor-mode for converting these references to hyperlinks, automatically, via the use of regular expressions.
Given this configuration:
When the minor-mode is active the any literal text that matches the pattern, for example "XXX-1234", will suddenly become a clickable button that will open Jira, and BUG-1234 will become a clickable button that opens the appropriate bug in Bugzilla.
There's no rewriting of the content, this is just a bit of magic that changes the display of the text (i.e. I'm using a button/text-property).
Since I mostly write in org-mode I could have written my text like so:
[[jira:XXX-1234][XXX-1234]]
But that feels like an ugly thing to do, and that style of links wouldn't work outside org-files anyway. That said it's a useful approach if you're only using org-mode, and the setup is simple:
This year had a lot of things happen in it, world-wide, as is always the case.
Being more selfish here are the things I remember, in brief unless there are comments/questions:
I learned more Finnish.
Lots of things with our child.
I helped teach him to swim.
He learned to tell the time with an analog clock/watch.
I took him to a circus for the first (only) time ever.
He cut his hair for the first time in six years.
He spent his a birthday with my parents, in the UK - His languages skills were on top-form, understanding the various UK accents.
And another with family here in Finland - Where he watched me roll, naked, in the snow after sauna, and then he asked "Daddy why you did that?"
On the topic of Finnish I'm getting pretty damn good at understanding, albeit less good in speaking. Finnish is all about the suffixes, so:
A car
auto
My car
autoni
In a car
autossa
In my car
autossani
With my car
autoll ni
From a car
autosta
Car-less
autoton
Most of this is regular, so you can be childless via the "ton" suffix - lapsiton is "lapsi" (child) "ton" (less). The hard part in communication is thus twofold:
Knowing the word you want to use, be it car, cake, spoon, or smile.
Getting the appropriate suffix for the use you want.
Our child turned six recently, and most of the year was spent doing things with him, for him, and to him. He's on the verge of learning to read (English and Finnish), he's interested in maths and completes little puzzles freely and happily. He likes to help with Sodoku, for example and not just the child-versions.
In the past couple of weeks I let him play Super Mario & Super Mario Bros 3, on a NES Classic, and he dies constantly, with a smile on his face. But he does love to tell me what to do when he watches me play!
He's learned to ice-skate, and ski, and almost learned to swim. (I'll say he can swim 3m inside a pool, without aid, but then he starts to sink.) We've got a couple of regular rituals with each other - including going to sauna every week or two, and other similar things.
He's gotten more interested in helping me cook, and his mother too. (My wife and I live in separate houses..)
I guess the next big milestone will be him walking to school by himself, which will start next year. As things stand I wake up early, go over to his house, and do all the morning-things, before I take him there. I expect I'll still want to go there, give him his breakfast, his medicine, and help him get dressed. After that I guess I kick him out, and he makes his own way there.
Happily the walk to school is a few hundred meters, and doesn't involve crossing any roads. But of course it does bring other complications: if he's not collected, and walks home himself, then he needs a key to one/other house, and there's the potential need for a phone to say "I'm late", "I'm lost", or us to say "Where are you?".
Anyway .. interesting year .. good year. Despite everything else.
I recently wrote about yet another lisp I'd
been having fun with.
Over the past couple of years I've played with a few toy scripting languages,
or random interpreters, and this time I figured I'd do something beyond the
minimum, by implementing the Language Server Protocol.
In brief the language server protocol (LSP) is designed to abstract
functionality that might be provided by an editor, or IDE, into a small
"language server". If the language-server knows how to jump to definitions,
provide completion, etc, etc, then the editor doesn't need to implement those
things for NN different languages - it just needs to launch and communicate
with something that does know how to do the job.
Anyway LSP? LISP? Only one letter different, so that's practically enough
reason to have a stab at it.
Thankfully I found a beautiful library that implements a simple framework
allowing the easy implementation of a golang-based LSP-server
Using that I quickly hacked up a server that can provide:
Overview of all standard-library functions, on hover.
Completion of all standard-library functions.
I've tested this in both GNU Emacs and Neovim, so that means I'm happy
I support all editors! (More seriously if it works in two then that
probably means that the LSP stuff should work elsewhere too.)
Here's what the "help on hover" looks like, within Emacs:
Vim looks similar but you have to press K to see the wee popup. Still
kinda cute, and was a good experiment.
So this week I recycled a talk I'd given in the past, about how even using
extremely simple parsers allows a lot of useful static-analysis to be done,
for specific niche use-cases.
This included examples of scanning comments above classes to ensure they
referred to the appropriate object, ensuring that specific function
calls always included a specific (optional) parameter, etc.
Nothing too complex, but I figured I'd give a new example this time, and
I remembered I'd recently written a bunch of functions for an interpreter
which I'd ordered quite deliberately.
Assume you're writing a BASIC interpreter, you need to implement a bunch of
built-in maths functions such as SIN, COS, TAN, then some string-related
functions LEFT$, RIGHT$, MID$, etc.
When it comes to ordering there are a couple of approaches:
Stick them all in one package:
builtins/builtins.go
Create a package and group them:
builtins/maths.go
builtins/string.go
.. etc
Personal preference probably dictates the choice you make, but either way I think it would be rational and obvious that you'd put the functions in alphabetical order:
I did that myself, and I wrote a perl-script to just parse the file using a simple regexp "^func\s+([^(]+)\(" but then I figured this was a good time to write a real static-analysis tool.
The golang environment is full of trivial little linters for various purposes, and the standard "go vet .." driver makes it easy to invoke them. Realizing that I was going to get driven in the same way it was obvious I'd write something called "alphaVet".
So anyway, half written for a talk, half-written because of the name:
Golang linter that reports failures if functions aren't in alphabetical order
Over the past few months (years?) I've posted on my blog about the various toy interpreters I've written.
I've used a couple of scripting languages/engines in my professional career, but in public I think I've implemented
Each of these works in similar ways, and each of these filled a minor niche, or helped me learn something new. But of course there's always a question:
Which is fastest?
In the real world? It just doesn't matter. For me. But I was curious, so I hacked up a simple benchmark of calculating 12! (i.e. The factorial of 12).
The specific timings will vary based on the system which runs the test(s), but there's no threading involved so the relative performance is probably comparable.
Anyway the benchmark is simple, and I did it "fairly". By that I mean that I didn't try to optimize any particular test-implementation, I just wrote it in a way that felt natural.
The results? Evalfilter wins, because it compiles the program into bytecode, which can be executed pretty quickly. But I was actually shocked ("I wrote a benchmark; The results will blow your mind!") at the second and third result:
here we see that FOTH, my FORTH implementation, comes second. I guess this is an efficient interpreter too, bacause that too is essentially "bytecode". (Looking up words in a dictionary, which really maps to indexes to other words. The stack operations are reasonably simple and fast too.)
Number three? BASIC? I expected better from the other implementations to be honest. BASIC doesn't even use an AST (in my implementation), just walks tokens. I figured the TCO implemented by my lisp would make that number three.
Anyway the numbers mean nothing. Really. But still interesting.
In my previous post I introduced yet another Lisp interpreter. When it was posted there was no support for macros.
Since I've recently returned from a visit to the UK, and caught COVID-19 while I was there, I figured I'd see if my brain was fried by adding macro support.
I know lisp macros are awesome, it's one of those things that everybody is told. Repeatedly. I've used macros in my emacs programming off and on for a good few years, but despite that I'd not really given them too much thought.
If you know anything about lisp you know that it's all about the lists, the parenthesis, and the macros. Here's a simple macro I wrote:
There you see that if the condition is true then we call the supplied body, and then recurse. Doing two actions as a result of the single if test is a neat shortcut.
Of course we need to wrap that up in a macro, for neatness:
We've gone from using lists to having a while-loop, with a couple of simple macros and one neat recursive function.
There are a lot of cute things you can do with macros, and now I'm starting to appreciate them a little more. Of course it's not quite as magical as FORTH, but damn close!
Recently I've been working with simple/trivial scripting languages, and I guess I finally reached a point where I thought "Lisp? Why not". One of the reasons for recent experimentation was thinking about the kind of minimalism that makes implementing a language less work - being able to actually use the language to write itself.
FORTH is my recurring example, because implementing it mostly means writing a virtual machine which consists of memory ("cells") along with a pair of stacks, and some primitives for operating upon them. Once you have that groundwork in place you can layer the higher-level constructs (such as "for", "if", etc).
Lisp allows a similar approach, albeit with slightly fewer low-level details required, and far less tortuous thinking. Lisp always feels higher-level to me anyway, given the explicit data-types ("list", "string", "number", etc).
Here's something that works in my toy lisp:
;; Define a function, fact , to calculate factorials (recursively).
(define fact (lambda (n)
(if (<= n 1)
1
(* n (fact (- n 1))))))
;; Invoke the factorial function, using apply
(apply (list 1 2 3 4 5 6 7 8 9 10)
(lambda (x)
(print "%s! => %s" x (fact x))))
The core language doesn't have helpful functions to filter lists, or build up lists by applying a specified function to each member of a list, but adding them is trivial using the standard car, cdr, and simple recursion. That means you end up writing lots of small functions like this:
This all feels very sexy and simple, because the implementations of map, apply, filter are all written using the lisp - and they're easy to write.
Lisp takes things further than some other "basic" languages because of the (infamous) support for Macros. But even without them writing new useful functions is pretty simple. Where things struggle? I guess I don't actually have a history of using lisp to actually solve problems - although it's great for configuring my editor..
Anyway I guess the journey continues. Having looked at the obvious "minimal core" languages I need to go further afield:
So my previous post introduced a trivial interpreter for a TCL-like language.
In the past week or two I've cleaned it up, fixed a bunch of bugs, and added 100% test-coverage. I'm actually pretty happy with it now.
One of the reasons for starting this toy project was to experiment with how easy it is to extend the language using itself
Some things are simple, for example replacing this:
puts "3 x 4 = [expr 3 * 4]"
With this:
puts "3 x 4 = [* 3 4]"
Just means defining a function (proc) named *. Which we can do like so:
proc * a b
expr $a * $b
(Of course we don't have lists, or variadic arguments, so this is still a bit of a toy example.)
Doing more than that is hard though without support for more primitives written in the parent language than I've implemented. The obvious thing I'm missing is a native implementation of upvalue, which is TCL primitive allowing you to affect/update variables in higher-scopes. Without that you can't write things as nicely as you would like, and have to fall back to horrid hacks or be unable to do things.
# define a procedure to run a body N times
proc repeat n body
set res ""
while > $n 0
decr n
set res [$body]
$res
# test it out
set foo 12
repeat 5 incr foo
# foo is now 17 (i.e. 12 + 5)
A similar story implementing the loop word, which should allow you to set the contents of a variable and run a body a number of times:
proc loop var min max bdy
// result
set res ""
// set the variable. Horrid.
// We miss upvalue here.
eval "set $var [set min]"
// Run the test
while <= [set "$$var"] $max
set res [$bdy]
// This is a bit horrid
// We miss upvalue here, and not for the first time.
eval incr "$var"
// return the last result
$res
loop cur 0 10 puts "current iteration $cur ($min->$max)"
# output is:
# => current iteration 0 (0-10)
# => current iteration 1 (0-10)
# ...
That said I did have fun writing some simple test-cases, and implementing assert, assert_equal, etc.
In conclusion I think the number of required primitives needed to implement your own control-flow, and run-time behaviour, is a bit higher than I'd like. Writing switch, repeat, while, and similar primitives inside TCL is harder than creating those same things in FORTH, for example.
Recently I was reading Antirez's piece TCL the Misunderstood again, which is a nice defense of the utility and value of the TCL language.
TCL is one of those scripting languages which used to be used a hell of a lot in the past, for scripting routers, creating GUIs, and more. These days it quietly lives on, but doesn't get much love. That said it's a remarkably simple language to learn, and experiment with.
Using TCL always reminds me of FORTH, in the sense that the syntax consists of "words" with "arguments", and everything is a string (well, not really, but almost. Some things are lists too of course).
A simple overview of TCL would probably begin by saying that everything is a command, and that the syntax is very free. There are just a couple of clever rules which are applied consistently to give you a remarkably flexible environment.
To get started we'll set a string value to a variable:
set name "Steve Kemp"
=> "Steve Kemp"
Now you can output that variable:
puts "Hello, my name is $name"
=> "Hello, my name is Steve Kemp"
OK, it looks a little verbose due to the use of set, and puts is less pleasant than print or echo, but it works. It is readable.
Next up? Interpolation. We saw how $name expanded to "Steve Kemp" within the string. That's true more generally, so we can do this:
set print pu
set me ts
$print$me "Hello, World"
=> "Hello, World"
There "$print" and "$me" expanded to "pu" and "ts" respectively. Resulting in:
puts "Hello, World"
That expansion happened before the input was executed, and works as you'd expect. There's another form of expansion too, which involves the [ and ] characters. Anything within the square-brackets is replaced with the contents of evaluating that body. So we can do this:
puts "1 + 1 = [expr 1 + 1]"
=> "1 + 1 = 2"
Perhaps enough detail there, except to say that we can use and to enclose things that are NOT expanded, or executed, at parse time. This facility lets us evaluate those blocks later, so you can write a while-loop like so:
set cur 1
set max 10
while expr $cur <= $max
puts "Loop $cur of $max"
incr cur
Anyway that's enough detail. Much like writing a FORTH interpreter the key to implementing something like this is to provide the bare minimum of primitives, then write the rest of the language in itself.
You can get a usable scripting language with only a small number of the primitives, and then evolve the rest yourself. Antirez also did this, he put together a small TCL interpreter in C named picol:
My code runs the original code from Antirez with only minor changes, and was a fair bit of fun to put together.
Because the syntax is so fluid there's no complicated parsing involved, and the core interpreter was written in only a few hours then improved step by step.
Of course to make a language more useful you need I/O, beyond just writing to the console - and being able to run the list-operations would make it much more useful to TCL users, but that said I had fun writing it, it seems to work, and once again I added fuzz-testers to the lexer and parser to satisfy myself it was at least somewhat robust.
Feedback welcome, but even in quiet isolation it's fun to look back at these "legacy" languages and recognize their simplicity lead to a lot of flexibility.
Recently I've been getting much more interested in the "retro" computers of my youth, partly because I've been writing crazy code in Z80 assembly-language, and partly because I've been preparing to introduce our child to his first computer:
An actual 1982 ZX Spectrum, cassette deck and all.
No internet
No hi-rez graphics
Easily available BASIC
And as a nice bonus the keyboard is wipe-clean!
I've got a few books, books I've hoarded for 30+ years, but I'd love to collect some more. So here's my request:
If you have any books covering either the Z80 processor, or the ZX Spectrum, please consider dropping me an email.
I'd be happy to pay 5-10 each for any book I don't yet own, and I'd also be more than happy to cover the cost of postage to Finland.
I'd be particularly pleased to see anything from Melbourne House, and while low-level is best, the coding-books from Usbourne (The Mystery Of Silver Mountain, etc, etc) wouldn't go amiss either.
I suspect most people who have collected and kept these wouldn't want to part with them, but just in case ..
Back in April 2021 I introduced a simple text-based adventure game, The Lighthouse of Doom, which I'd written in Z80 assembly language for CP/M systems.
As it was recently the 40th Anniversary of the ZX Spectrum 48k, the first computer I had, and the reason I got into programming in the first place, it crossed my mind that it might be possible to port my game from CP/M to the ZX Spectrum.
To recap my game is a simple text-based adventure game, which you can complete in fifteen minutes, or less, with a bunch of Paw Patrol easter-eggs.
You enter simple commands such as "up", "down", "take rug", etc etc.
You receive text-based replies "You can't see a telephone to use here!".
My code is largely table-based, having structures that cover objects, locations, and similar state-things. Most of the code involves working with those objects, with only a few small platform-specific routines being necessary:
Clearing the screen.
Pausing for "a short while".
Reading a line of input from the user.
Sending a $-terminated string to the console.
etc.
My feeling was that I could replace the use of those CP/M functions with something custom, and I'd have done the 99% of the work. Of course the devil is always in the details.
Let's start. To begin with I'm lucky in that I'm using the pasmo assembler which is capable of outputting .TAP files, which can be loaded into ZX Spectrum emulators.
I'm not going to walk through all the code here, because that is available within the project repository, but here's a very brief getting-started guide which demonstrates writing some code on a Linux host, and generating a TAP file which can be loaded into your favourite emulator. As I needed similar routines I started working out how to read keyboard input, clear the screen, and output messages which is what the following sample will demonstrate..
First of all you'll need to install the dependencies, specifically the assembler and an emulator to run the thing:
# apt install pasmo spectemu-x11
Now we'll create a simple assembly-language file, to test things out - save the following as hello.z80:
; Code starts here
org 32768
; clear the screen
call cls
; output some text
ld de, instructions ; DE points to the text string
ld bc, instructions_end-instructions ; BC contains the length
call 8252
; wait for a key
ld hl,0x5c08 ; LASTK
ld a,255
ld (hl),a
wkey:
cp (hl) ; wait for the value to change
jr z, wkey
; get the key and save it
ld a,(HL)
push af
; clear the screen
call cls
; show a second message
ld de, you_pressed
ld bc, you_pressed_end-you_pressed
call 8252
;; Output the ASCII character in A
ld a,2
call 0x1601
pop af
call 0x0010
; loop forever. simple demo is simple
endless:
jr endless
cls:
ld a,2
call 0x1601 ; ROM_OPEN_CHANNEL
call 0x0DAF ; ROM_CLS
ret
instructions:
defb 'Please press a key to continue!'
instructions_end:
you_pressed:
defb 'You pressed:'
you_pressed_end:
end 32768
Now you can assemble that into a TAP file like so:
$ pasmo --tapbas hello.z80 hello.tap
The final step is to load it in the emulator:
$ xspect -quick-load -load-immed -tap hello.tap
The reason I specifically chose that emulator was because it allows easily loading of a TAP file, without waiting for the tape to play, and without the use of any menus. (If you can tell me how to make FUSE auto-start like that, I'd love to hear!)
I wrote a small number of "CP/M emulation functions" allowing me to clear the screen, pause, prompt for input, and output text, which will work via the primitives available within the standard ZX Spectrum ROM. Then I reworked the game a little to cope with the different screen resolution (though only minimally, some of the text still breaks lines in unfortunate spots):
The end result is reasonably playable, even if it isn't quite as nice as the CP/M version (largely because of the unfortunate word-wrapping, and smaller console-area). So now my repository contains a .TAP file which can be loaded into your emulator of choice, available from the releases list.
Here's a brief teaser of what you can expect:
Outstanding bugs? Well the line-input is a bit horrid, and unfortunately this was written for CP/M accessed over a terminal - so I'd assumed a "standard" 80x25 resolution, which means that line/word-wrapping is broken in places.
That said it didn't take me too long to make the port, and it was kinda fun.
In the past I used to run a number of virtual machines, or dedicated hosts. Currently I'm cut things down to only a single machine which I'm planning to remove.
Email
Email used to be hosted via dovecot, and then read with mutt-ng on the host itself. Later I moved to reading mail with my own console-based email client.
Eventually I succumbed, and now I pay for Google's Workspace product.
Git Repositories
I used to use gitbucket for hosting a bunch of (mostly private) git repositories. A bad shutdown/reboot of my host trashed the internal database so that was broken.
I replaced the use of gitbucket, which was very pretty, with gitolite to perform access-control, and avoid the need of a binary database.
I merged a bunch of repositories, removed the secret things from there where possible, and finally threw them on a second github account. GPG-encryption added where appropriate.
Static Hosts
Static websites I used to host upon my own machine are now hosted via netlify.
There aren't many of them, and they are rarely updated, I guess I care less.
Dynamic Hosts
That leaves only dynamic hosts. I used to have a couple of these, most notably the debian-administration.org, but that was archived and the final commercial thing I did was retired in January.
I now have only one dynamic site up and running, https://api.steve.fi/, this provides two dynamic endpoints:
One to return data about trams coming to the stop near my house.
One to return the current temperature.
Both of these are used by my tram-display device. Running these two services locally, in Docker, would probably be fine.
However there is a third "secret" API - blog-comment submission.
When a comment is received upon this blog it is written to a local filesystem, and an email is sent to me. The next time my blog is built rsync is used to get the remote-comments and add them to the blog. (Spam deleted first, of course).
Locally the comments are added into the git-repository this blog is built from - and the remote files deleted now and again.
Maybe I should just switch from writing the blog-comment to disk, and include all the meta-data in the email? I don't wanna go connecting to Gmail via IMAP, but I could probably copy and paste from the email to my local blog-repository.
I can stop hosting the tram-APIs publicly, but the blog comment part is harder. I guess I just need to receive incoming FORM-submission, and send an email.
Maybe I host the existing container on fly.io, for free?
Maybe I write an AWS lambda function to do the necessary thing?
Or maybe I drop blog-comments and sidestep the problem entirely? After all I wrote five posts in the whole of last year ..
So in my previous post I mentioned that we were going to spend the Christmas period in the UK, which we did.
We spent a couple of days there, meeting my parents, and family. We also persuaded my sister to drive us to Scarborough so that we could hang out on the beach for an afternoon.
Finland has lots of lakes, but it doesn't have proper waves. So it was surprisingly good just to wade in the sea and see waves! Unfortunately our child was a wee bit too scared to ride on a donkey!
Unfortunately upon our return to Finland we all tested positive for COVID-19, me first, then the child, and about three days later my wife. We had negative tests in advance of our flights home, so we figure that either the tests were broken, or we were infected in the airplane/airport.
Thankfully things weren't too bad, we stayed indoors for the appropriate length of time, and a combination of a couple of neighbours and online shopping meant we didn't run out of food.
Since I've been back home I've been automating AWS activities with aws-utils, and updating my simple host-automation system, marionette.
Marionette is something that was inspired by puppet, the configuration management utility, but it runs upon localhost only. Despite the small number of integrated primitives it actually works surprisingly well, and although I don't expect it will ever become popular it was an interesting research project.
The aws-utilities? They were specifically put together because I've worked in a few places where infrastructure is setup with terraform, or cloudformation, but there are always the odd thing that is configured manually. Typically we'll have an openvpn gateway which uses a manually maintained IP allow-list, or some admin-server which has a security-group maintained somewhat manually.
Having the ability to update a bunch of rules with your external IP, as a single command, across a number of AWS accounts/roles, and a number of security-groups is an enormous time-saver when your home IP changes.
I'd quite like to add more things to that collection, but there's no particular rush.
I realize it has been quite some time since I last made a blog-post, so I guess the short version is "I'm still alive", or as Granny Weatherwax would have said:
I ATE'NT DEAD
Of course if I die now this would be an awkward post!
I can't think of anything terribly interesting I've been doing recently, mostly being settled in my new flat and tinkering away with things. The latest "new" code was something for controlling mpd via a web-browser:
This is a simple HTTP server which allows you to minimally control mpd running on localhost:6600. (By minimally I mean literally "stop", "play", "next track", and "previous track").
I have all my music stored on my desktop, I use mpd to play it locally through a pair of speakers plugged into that computer. Sometimes I want music in the sauna, or in the bedroom. So I have a couple of bluetooth speakers which are used to send the output to another room. When I want to skip tracks I just open the mpd-web site on my phone and tap the button. (I did look at android mpd-clients, but at the same time it seemed like installing an application for this was a bit overkill).
I guess I've not been doing so much "computer stuff" outside work for a year or so. I guess lack of time, lack of enthusiasm/motivation.
So looking forward to things? I'll be in the UK for a while over Christmas, barring surprises. That should be nice as I'll get to see family, take our child to visit his grandparents (on his birthday no less) and enjoy playing the "How many Finnish people can I spot in the UK?" game
Like many I use pass for storing usernames and passwords. This gives me easy access to credentials in a secure manner.
I don't like the way that the metadata (i.e. filenames) are public, but that aside it is a robust tool I've been using for several years.
The last time I talked about pass was when I talked about showing the age of my credentials, via the integrated git support.
That then became a pass-plugin:
frodo ~ $ pass age
6 years ago GPG/root@localhost.gpg
6 years ago GPG/steve@steve.org.uk.OLD.gpg
..
4 years, 8 months ago Domains/Domain.fi.gpg
4 years, 7 months ago Mobile/dna.fi.gpg
..
1 year, 3 months ago Websites/netlify.com.gpg
1 year ago Financial/ukko.fi.gpg
1 year ago Mobile/KiK.gpg
4 days ago Enfuce/sre.tst.gpg
..
Anyway today's work involved writing another plugin, named env. I store my data in pass in a consistent form, each entry looks like this:
username: steve
password: secrit
site: http://example.com/login/blah/
# Extra data
The keys vary, sometimes I use "login", sometimes "username", other times "email", but I always label the fields in some way.
Recently I was working with some CLI tooling that wants to have a username/password specified and I patched it to read from the environment instead. Now I can run this:
That's ideal, because now I can source that from within a shell:
$ source <(pass env internal/cli/tool-name)
$ echo username
steve
Or I could directly execute the tool I want:
$ pass env --exec=$HOME/ldap/ldap.py internal/cli/tool-name
you are steve
..
TLDR: If you store your password entries in "key: value" form you can process them to export $KEY=$value, and that allows them to be used without copying and pasting into command-line arguments (e.g. "~/ldap/ldap.py --username=steve --password=secrit")
Like many I use pass for storing usernames and passwords. This gives me easy access to credentials in a secure manner.
I don't like the way that the metadata (i.e. filenames) are public, but that aside it is a robust tool I've been using for several years.
The last time I talked about pass was when I talked about showing the age of my credentials, via the integrated git support.
That then became a pass-plugin:
frodo ~ $ pass age
6 years ago GPG/root@localhost.gpg
6 years ago GPG/steve@steve.org.uk.OLD.gpg
..
4 years, 8 months ago Domains/Domain.fi.gpg
4 years, 7 months ago Mobile/dna.fi.gpg
..
1 year, 3 months ago Websites/netlify.com.gpg
1 year ago Financial/ukko.fi.gpg
1 year ago Mobile/KiK.gpg
4 days ago Enfuce/sre.tst.gpg
..
Anyway today's work involved writing another plugin, named env. I store my data in pass in a consistent form, each entry looks like this:
username: steve
password: secrit
site: http://example.com/login/blah/
# Extra data
The keys vary, sometimes I use "login", sometimes "username", other times "email", but I always label the fields in some way.
Recently I was working with some CLI tooling that wants to have a username/password specified and I patched it to read from the environment instead. Now I can run this:
That's ideal, because now I can source that from within a shell:
$ source <(pass env internal/cli/tool-name)
$ echo username
steve
Or I could directly execute the tool I want:
$ pass env --exec=$HOME/ldap/ldap.py internal/cli/tool-name
you are steve
..
TLDR: If you store your password entries in "key: value" form you can process them to export $KEY=$value, and that allows them to be used without copying and pasting into command-line arguments (e.g. "~/ldap/ldap.py --username=steve --password=secrit")
In my previous post I wrote about how I'd been running CP/M on a Z80-based single-board computer.
I've been slowly working my way through a bunch of text-based adventure games:
The Hitchhiker's Guide To The Galaxy
Zork 1
Zork 2
Zork 3
Along the way I remembered how much fun I used to have doing this in my early teens, and decided to write my own text-based adventure.
Since I'm not a masochist I figured I'd write something with only three or four locations, and solicited facebook for ideas. Shortly afterwards a "plot" was created and I started work.
I figured that the very last thing I wanted to be doing was to be parsing text-input with Z80 assembly language, so I hacked up a simple adventure game in C. I figured if I could get the design right that would ease the eventual port to assembly.
I had the realization pretty early that using a table-driven approach would be the best way - using structures to contain the name, description, and function-pointers appropriate to each object for example. In my C implementation I have things that look like this:
name: "generator",
desc: "A small generator.",
use: use_generator,
use_carried: use_generator_carried,
get_fn: get_generator,
drop_fn: drop_generator ,
A bit noisy, but simple enough. If an object cannot be picked up, or dropped, the corresponding entries are blank:
name: "desk",
desc: "",
edesc: "The desk looks solid, but old." ,
Here we see something that is special, there's no description so the item isn't displayed when you enter a room, or LOOK. Instead the edesc (extended description) is available when you type EXAMINE DESK.
Anyway over a couple of days I hacked up the C-game, then I started work porting it to Z80 assembly. The implementation changed, the easter-eggs were different, but on the whole the two things are the same.
Certainly 99% of the text was recycled across the two implementations.
Anyway in the unlikely event you've got a craving for a text-based adventure game I present to you:
So my previous post documented a couple of simple "scripting languages" for small computers, allowing basic operations in a compact/terse fashion.
I mentioned that I might be tempted to write something similar for CP/M, in Z80 assembly, and the result is here:
To sum up it allows running programs like this:
Vim looks similar but you have to press