Why invent a new file format when there is https://jsonresume.org/? Its also quite easy to customize and add more things as it does not prohibit extra values

The JSON Resume schema did not support what we needed, so we deliberately created our own.

We wanted to define 9 different entry schemas that could be used under any section title. In our schema, each section, regardless of its title, contains a list composed of one of these nine entry types. This is different from the JSON Resume approach, where specific entry schemas are tied to specific sections (work schema for work section, etc.).

In RenderCV, users can choose any section title they want and use any of the 9 entry types within it. Each entry type is rendered differently in the generated PDF.

fk lese(&selbst, schlsl: Zeichenkette) -> Ergebnis<Möglichkeit<&Zeichenkette>, Zeichenkette> { wenn lass Etwas(wöbu) = gefährlich { WÖRTERBUCH.als_ref() } { Gut(wöbu.hole(&schlsl)) } anderenfalls { Fehler("Holt das Wörterbuch".hinein()) } }

https://github.com/michidk/rost

I don't like the non-Germanic ref here in als_ref is not Germanic enough. als_ver (from Verweis) would be nicer.

I read it as als_referenz, which arguably makes sense!

For sure it's valid German but for maximum fun it's nice to have it be as Germanic as possible and avoid words that share roots with the standard English programming terms.

As a non-Bavarian German, I'm offended by the German = Bavarian stereotype! (jk, it's just mildly annoying sometimes and this is meant to be silly)

Almost perfect. I'm missing the Schwabacher typeface rendering.

Indent with two spaces for code formatting.

  fk lese(&selbst, schlsl: Zeichenkette) -> Ergebnis<Möglichkeit<&Zeichenkette>, Zeichenkette> {
            wenn lass Etwas(wöbu) = gefährlich { WÖRTERBUCH.als_ref() } {
                Gut(wöbu.hole(&schlsl))
            } anderenfalls {
                Fehler("Holt das Wörterbuch".hinein())
            }
        }

isn't the idea behind programming "languages", that they are sentences readable to both humans and the compiler?

This absolutely is not readable to me. But woerterbuch and schluessel should of course not be abbreviated, for legibility.

If German was seriously used in programming languages, I'd hope for some better and shorter terms. Some here might be intentionally too literal translations anyway. "Let" is from mathematics, it's called "Sei" in German. "Sei x = 5". "Anderenfalls" could be "sonst". "Zeichenkette" is just too long and would require some thinking or a historical accident to find a shorter term.

Ready surprisingly nice to me anyway.

I would use "sei" instead of "lass" for "let" to be more in line with notation in mathematical proofs.

see https://stabl.com/

those devcontainer are no vscode devcontainers though. they use the vscode remote feature

Yes, exactly this! We are actually spending soo much time deriving, thinking, formulating & refining OKRs from roadmap items that we could just declare as simple "Goals". We could get so much shit done during that time.

Most of the time as the quarter goes on, we then scrap those OKRs anyway because we didn't manage to do them or they were too specific and requirements changed.

I always had the feeling that what we are doing is bullshit. So great to finally hear it from someone else.

I wonder how many engineering companies actually use OKRs though.

I call it planning palooza. It keeps a ton of people employed though.

Such a great explanation. Wish I would have had something like this back in my gamedev days.

Yeah I thought sth like this is possible, but (correct me if I'm wrong) this (ab)uses the ELF header and punts data in there, which goes against my requirement

> It should be a ‘proper‘ executable binary according to the spec

yes, this one conforms to 'whatever linux agrees to exec(2)', which apparently is a lot that is out of spec.

Hehe a nice idea. But then it would not always print Hello World and you cannot execute it directly.

I was able to shave off one additional byte with this:

  ...
  xor rax, rax       ; = 0
  inc rax            ; = 1 - syscall: sys_write
  mov rdi, rax       ; copy 1 - file descriptor: stdout
  lea rsi, [rel msg] ; pointer to message
  mov rdx, 14        ; message length
  syscall
  ...

  $ nasm -f bin -o elf elf.asm; wc -c elf; ./elf
  166 elf
  Hello, World!

So I guess NASM already optimizes this quite well

However, using the stack-based instructions as xpasky hinted at:

  ...
  push 1             ; syscall: sys_write
  pop rax
  pop rdi       ; copy 1 - file descriptor: stdout
  lea rsi, [rel msg] ; pointer to message
  push 14            ; message length
  pop rdx
  syscall
  ...

I get down to 159 bytes! I updated the article to reflect that

That second snippet is pretty funny:

  push 1
  pop rax
  pop rdi

You can't push a value once and pop it twice, that's not how a stack works! You're popping something else off the stack. So why does this even work?

Linux passes your program arguments on the stack, with argc on top. So when you don't pass any arguments, argc just HAPPENS to be 1. Which you then pop into rdi. Gross!

Of course - you are completely right, an oversight in wanting to correct my mistake as quickly as possible.

With that fixed, is there any reason not to use push here?

Yes, because:

  push 1       ; 6A 01 (2 bytes)
  pop rdi      ; 5F    (1 byte)

is longer than a simple:

  mov edi, eax ; 89 C7 (2 bytes)

I think your statement might only apply to 32 bit (one of the constraints mentioned early in the blog post was 64 bit).

But even if it was 32 bit, then we would't have to copy a 1, since the syscall number for sys_write would be 4 instead of 1.

I get the same total size with both variants in 64 bit mode.

  push 1
  pop rax
  mov rdi, rax

Assembling to 48 89 C7 (3 bytes)

seems to be same in size as

  push 1
  pop rax
  push 1
  pop rdi

Assembling to 6A 01 5F (3 bytes)

That's because you're using `mov rdi, rax` again. You keep changing `edi, eax` to `rdi, rax`. Why?

The default operand size in 64-bit mode is, for most instructions, still 32 bits. So `mov edi, eax` encodes the same in 32- and 64-bit mode.

For `mov rdi, rax` you need an extra REX prefix byte [1], that's the 48 you're seeing above, but you don't need it here.

[1] https://wiki.osdev.org/X86-64_Instruction_Encoding#REX_prefi...

okay, I didn't know that, thanks for the background. I wonder why the assembler would not optimize this though.

I noticed that I then could also shave of one byte more by using lea esi, [rel msg] instead of lea rsi, [rel msg].

should be ... push 1 ; syscall: sys_write pop rax push 1 pop rdi

of course

Thanks, that makes total sense. I was so focused on the ELF part that I didn't even consider optimizing the initial assembly further. Will fix it and edit the article.