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