December Adventure

Realizing it is December already and having been on a decent (for me at least) streak of working on 65cha02 and Org Roam usage, I decide to take part in the December Adventure!

For today's adventure I'll just set up this page on Sourcehut Pages.

This is quite difficult, because Org is fucking ancient, so it can't just be as simple as running one command, you have to figure out what the heck org-publish-project-alist is.

This is the official example configuration:

(setq org-publish-project-alist
      '(("org"
         :base-directory "~/org/"
         :publishing-function org-html-publish-to-html
         :publishing-directory "~/public_html"
         :section-numbers nil
         :with-toc nil
         :html-head "<link rel=\"stylesheet\"
                    href=\"../other/mystyle.css\"
                    type=\"text/css\"/>")))

It uses absolute paths, so that's already a red flag. Trying to place it in .dir-locals.el leads to a listp error. StackOverflow (btw, fuck that company) recommends either eval-ing a function that I define elsewhere, or writing a bespoke exporter script in Elisp. Since the whole point is that I don't want to pollute my (Doom) Emacs config with anything project-specific, I opt for the latter.

I realize that the answer giver obviously did not run their code, because it references a nonexistent variable.

In the process I converted all the old links in my memex that were just [[...]], which in Org means that there is no description for the link. I initially tried to do it with sed, like so:

git ls-files wiki/ -z | xargs -0 sed -i 's/\[\[\([^\[\]]*\)\]\]/\1/g'

Fun fact: -iE does not mean -i -E, it instead creates backup files with E as their suffix, re-learned that the hard way.

Anyways, that did not work, feel free to figure out why, I have no idea. Instead I wrote a short Lua script that did the same thing, except much better and way more readable.

#!/usr/bin/env lua
for _, path in ipairs({...}) do
  local out = assert(io.open(path..".new", "w"))
  local file = assert(io.open(path))
  for line in file:lines() do
    out:write((line:gsub("(%[%[([^%[%]]-)%]%])",
                         function(all, link)
                           -- internal links and links to files are kept as is
                           if link:match("^[%w%s]+$") or link:match("%.org$") then
                             return all
                           else
                             return link
                           end
                         end
              )),"\n")
  end
  assert(file:close())
  assert(out:flush())
  assert(out:close())
  assert(os.rename(path..".new", path))
end

Note to self: gg0VG selects the whole file in Vim and Doom in evil-mode.

Another neat Emacs finding: you can move a file that is open in a buffer using Dired's rename (R in Doom) and it will automatically update the buffer to point to the new file! You don't even have to specify the name if you are moving it to a directory, it works just like the mv command does!

Alright, I just moved this file to a publish directory for now, I guess once I Roam-ify all my links the directory structure won't matter. Time to tar it up and publish it with hut!

Not so fast! Tried to add an index page and got another link error. Turns out I need to add yet another step to the publisher script: org-html-export-to-html: Unable to resolve link

And of course that leads to another error about org-element--cache-active-p being void. Maybe related to this bug report?

Annnd another bug, I can't paste the clipboard contents to Emacs. So now I can't paste the bug report's URL. {BUG} org-agenda: definition is void: org-element–cache-active-p Okay, it was at the end of the kill-ring when I pressed M-y. But org-cliplink did not process it. Anyways, adding (require 'org-element) fixed it.

Yay!

It's so late that I could start writing day 2's entry, haha ha ha … ha …… haaa. Why is Emacs like this.

Annnd another snag

# wrong, tar will have a _pages directory at the top level
./org-publish && tar --create --gzip _pages | hut pages publish -d raingloom.srht.site
# correct, tar will have the files from _pages at the top level
./org-publish && (cd _pages; tar --create --gzip .) | hut pages publish -d raingloom.srht.site
# or even nicer
./org-publish && tar --directory=_pages --create --gzip . | hut pages publish -d raingloom.srht.site

Now it's finally published! Welcome to Csepp's stuff! (name and custom domain pending)

Okay, last addition: made today's entry into a proper Org heading with an ID, so I can permalink to it.

Now I should really go to sleep!

Made a little progress during lunch refining the EWoz monitor. Looked through the code a bit more and made some inital changes, but its formatting doesn't play nicely with Emacs's assembly-mode, so I'm going to reformat it first, to make the commits nice and atomic.

I observed some input handling code that I can probably safely remove - like backspace handling - since the web frontend will take care of it. But… maybe I should keep it in, if I keep the API then someone might make a frontend that sends raw ASCII to backend. But I should add a way to delete the contents of the input buffer and also one for soft resetting back into the monitor.

I suppose hard resetting could be added too, it would keep most of the memory, but load the monitor again and jump to it.

I conked out early yesterday, so the first task today is to upload yesterday's notes.

Hhh okay, didn't write any code on my lunch break and now it's well past midnight. Going to at least do the formatting.

Upon looking at the EWoz source further, I realize it doesn't even follow cc65's syntax. What gives? I check out the link in the file header, it's dead. But the Wayback Machine still has this old thread! It looks like the Github gist I found was a simple copy-paste of the forum post.

I decide to use the plain wozmon source instead and build on that.

While editing it I change course again: no more in-RAM ring buffer. It's pointless, even though I put a lot of time into it. 6502 programmers will likely be more comfortable using the ACIA, so instead I choose to add a buffer to i6502's rudimentary ACIA implementation. Well, I can still reuse the ring buffer code.

I also found where EWoz was used: https://github.com/glitchwrks/ewoz_r6501 Not a 6502, but some weird clone.

Hmm, actually, let's keep the ring buffers. The reason I went with this design was to make concurrent RAM writes slightly less chaotic. Users can still move the buffers around.

Alright, so let's rework Wozmon then.

Do I need to keep its internal input buffer? Since it works one line at a time… maybe not? But then I have to make sure it only pops from the input buffer when necessary.

True facepalm moment: while looking at the addresses for the ring buffers I realized why I was getting that weird corruption. The start of the output buffer was calculated as input+capacity, but the whole ring buffer data structure is actually 2+capacity large, because of the offset and length fields. Duh. Adjusting the Go and asm code to reflect that and testing if the bug is still present… first calculating the address ($302+$FF) by hand and then checking it with M-x calc… yup, correct.

Note: d 6 switches to hexadecimal mode, but input is still decimal, enter hex values as 16#FF, the part before the # is the radix.

It doesn't work… but that's because I also switched the ring buffers around to start from $200 instead of $300, fixing that on the Go side, re-running.

Huh… very peculiar. Once the output fills it stops copying the input, instead of dropping old bytes from the output. Let's investigate.

Found the archivd page of the assembler that was used for EWoz. This newer snapshot is what I first tried, weird to think that ISPs used to provide web hosting for everyone.

Okay, that should be enough for today, time to sleep, my partner has been asleep for 2 hours already.