Onfim’s drawing of two people

He was no Rafael, but look at this piece, could have been a banger punk rock cover!

I appreciate the idea, but the picture is good enough for me, thanks for that!

@keleshev.com not sure whether you already saw, but Compiling to Assembly from Scratch got a review in c't 9/25 (the largest German IT magazine)

Oh, wow! Thanks for noting!

A probable self portrait by Rafael, drawn when he was around the same age (1499), Ashmolean Museum, Oxford, UK.

Onfim was not the greatest artist, but why do you have to rub it in like that?!

Basically ‘class Parser[T]: pass’ is same as what used to be (from memory):

from typing import Generic, TypeVar
T = TypeVar(“T”)
class Parser(Generic(T)): pass

@dataclass class Parser[T]: parse: Callable[[Source], ParseResult[T] | None] @staticmethod def regexp(regexp: Pattern) -> Parser[str]: return Parser(lambda source: source.match(regexp)) @staticmethod def constant[U](value: U) -> Parser[U]: return Parser(lambda source: ParseResult(value, source))

Like, what language is this?

@dataclass class Parser[T]: _parse: Callable[[Source], ParseResult[T] | None] def parse(self, s: Source) -> ParseResult[T] | None: return self.__dict__['_parse'](s) @staticmethod def regexp(regexp: Pattern) -> Parser[str]: return Parser(lambda source: source.match(regexp)) @staticmethod def constant[U](value: U) -> Parser[U]: return Parser(lambda source: ParseResult(value, source))

Glad to see that Python finally got more dedicated syntax for type annotations in 3.12. Now it looks quite decent. So I updated the Python version of the book's compiler to use the new syntax: github.com/keleshev/com...

I have a contrarian urge to reply "that's just easy!", which it's not; however, here's a bunch of techniques that I found very helpful:

keleshev.com/advanced-err...

But it relies on polymorphic variants, which is an OCaml-only feature, as far as I know.

How to reconcile that the standard says:

prog [-xyz] == prog [-x] [-y] [-z]
prog [options] == prog [-x] [-y] [-z]

but at the same time,

prog [<x> <y>] != prog [<x>] [<y>]

Found this counter-example from the standard:

cal [[<month>] <year>]

(which is clearly not the same as [<month>] [<year>])

pubs.opengroup.org/onlinepubs/9...

My only problem that makes me keep returning to this is that in EBNF the square brackets don't work this way ([<x> <y>] != [<x>] [<y>]), and the POSIX utility convention notation is clearly inspired by EBNF…

Then there's the `[options]` shortcut. If we assume that the `options` from the options shortcut stands for all the options in the `Options:` section, then the original behavior also makes more sense:

[options] => [-x -y -z] => [-x] [-y] [-z]

But maybe the right way is to say that this is only the case for these short option strides, and not for anything else?

[-xyz] => [-x] [-y] [-z]
[-x -y -z] => [(-x -y -z)]

That's because the POSIX standard has examples like `prog [-xyz]` where it is clear that this means the same as `prog [-x] [-y] [-z]`.

In original docopt, square brackets mean each item is optional. For example, `prog [<x> <y>]` is the same as `prog [<x>] [<y>]`. Weird or not? To make both-or-nothing you need to group them like `prog [(<x> <y>)]`. You know why this was the design decision?

😲

Exactly. At my desk I have two USB-C connectors, one for Raspberry Pi, and another one for laptops, and it doesn't work if you plug in the wrong one.

My LG monitor (32UN880-B) is advertised at 60W PD, but at 5V it gives my Pi 400 low voltage warnings and crashes at high loads.

Another BenQ monitor I have (PD3205U) advertises 90W PD and works just fine powering Pi 400.

Pi 5 and Pi 500 require 27W at 5V, and almost certainly no device will provide that via USB-C other than the official power supply.

Power new Raspberry Pis is tricky nowadays, isn't it?

Pi 4 needs 15W at 5V, but normally hubs/screens/power supplies advertise their max power delivery at a higher voltage, so there's no way to know without trying.

Everyone know shat 3840 × 2160 divided by two gives 1920 × 1080, but did you know that 3840 × 2160 divided by *three* gives 1280 × 720!

So, 720p looks crisp (but pixelated) on 4K, but horribly scaled on an 1080p panel.

Pinebook Pro has a 1080p panel, and downscaling looks horrible. On the other hand, Pi 400 used with 4K monitor can be downscaled, to 1080p or 720p without scaling issues.

Originally my plan was to get two Pinebook Pro for kids. I got one to test out, but could not get Minecraft running with a good frame rate (neither Bedrock, nor Java).

Of course, ever since Pi 400 came out it was obvious that there will be a Raspberry Pi laptop at some point in time, and the new Raspberry Pi screen is also an obvious stepping stone to that, but it's surprising how long it takes, considering what PINE64 folks done with Pinebook Pro long ago.

I remember it took me several evenings to tweak Minecraft with different plugins to get a good frame rate, but I got it working. With new Pi 500, I assume you can just use stock Minecraft Java without issues, since it performs 3x on video benchmarks.

Two Raspberry Pi 400 wrapped in Minecraft gift paper.

I got two Pi 400 originally as Minecraft devices for kids on Christmas, but since then they are not using it much for Minecraft, more for Math Academy and school stuff. We got Nintendo Switch since then, so most gaming moved there.

It's 2–3 times faster, and has a real power button, and that's the complete list of improvements.

Everybody seems to be disappointed about the missing NVME slot, but I don't care much about it.

Not going to upgrade kids to Raspberry Pi 500 (from their Pi 400). Waiting for the next Pi X00 series for four years, of course it's a disappointment.

Did exactly that a few years back and after few days someone tried to use my card details to withdraw 300 bucks in Chile… 😬