Up to Main Index                         Up to Journal for September, 2020

                  JOURNAL FOR SATURDAY 19TH SEPTEMBER, 2020
______________________________________________________________________________

SUBJECT: A delayed post from the release & compiling Go on RPi Zero W
   DATE: Sat 19 Sep 20:11:38 BST 2020

This post is way overdue. I started writing it at the beginning of the week,
however things happened in real live and I suddenly found myself very busy :/

The new release is out and I can’t hear any screaming, email is quiet, I guess
it went okay. Putting the release out this time was actually a bit of a pain.

When I build a release I try to test[1] as many of the downloads I make
available on actual hardware. For Go versions 1.13 and 1.14 I’ve been unable
to compile Go from source on the Raspberry Pi Zero W[2]. With Go 1.15 I
noticed that memory and swap usage on my Raspberry Pi 3B was a lot less. So, I
tried compiling Go 1.15 on the RPi Zero and it worked, it took 5 hours to
compile and run the tests, but it worked!

I built all of the downloads, started testing them, and before I could publish
Go 1.15.1 was released on the 1st September :/

Another 5 hours to compile Go 1.15.1 on the RPi Zero, plus compile from source
on the RPi 3B, RPi 4 and on the desktop for Linux and Windows. Then to start
testing everything again.

While testing WolfMUD on the RPi Zero — with 2,000+ ‘players’ connected :) — I
had a weird nil pointer panic occur. I was busy debugging the issue when Go
1.15.2 was released on the 9th September ;(

Another 5 hours, blah blah blah, retest everything again…

At this point I had to decide whether to release with a potential bug or not.

After updating to Go 1.15.2 I couldn’t recreate the bug on the RPi Zero. I’m
not sure if Go 1.15.2 fixed an issue, or if it’s a very rare corner case in my
code. While I was debugging I just couldn’t see how the nil pointer could have
occurred. I wanted to debug with the race detector, but that’s not an option
on the RPi Zero — or any of my RPi at the moment[3]. I ran through tests on
the desktop with the race detector, but no errors of any kind showed up.
Testing on the desktop was a fun exercise, running the server with the race
detector and 2,000+ ‘players’ connected quickly consumed the 8Gb of memory the
desktop has available.

Actually, looking at the downloads page[4] I now realise there is no mention
of the Raspberry Pi 4. I’m still using GOARM=7 for the RPi4 for ARMv7 as
leaving GOARM unset for ARMv8 seems to require setting GOARCH=arm64 for 64bit
ARM instead of GOARCH=arm for 32bit ARM. Hrm, maybe I should mention the
builds are 32bit ARM on the downloads page? Hrm, hrm, maybe I should get a
64bit OS up and running on a Raspberry Pi…

Question now is what should I work on next?

  1. I *need* to sort out saving players that are wearing, wielding or holding
     items and have them load in the same state.
  2. I *need* to finish the combat system.
  3. I *want* to sort out the attribute system used for defining everything in
     the game world.

Options 1 and 2 are very important. However, if I work on option 3 it would
make sorting out options 1 and 2 much easier. The trouble with option 3 is:

  a. I don’t know how long it will take.
  b. Will it actually make things better or worse in the long run?

I think the best thing to do is dive into option 3, try some code, see how it
goes. If it’s not working out, or is going to take ages, I’ll work on options
1 and 2 and revisit option 3 after that.

--
Diddymus

  [1] Currently I have hardware for Linux ARMv5, ARMv6, ARMv7, amd64 and use
      kvm-qemu for Windows amd64. I could emulate Linux and Windows i386.

  [2] See “Case in point…”: ../../2019/9/10.html

  [3] The Go race detector is only available for 64bit ARM, not 32bit :(

  [4] Download area: ../../../downloads/


  Up to Main Index                         Up to Journal for September, 2020