Up to Main Index Up to Journal for December, 2020
JOURNAL FOR TUESDAY 29TH DECEMBER, 2020
______________________________________________________________________________
SUBJECT: New Go beta, module mode, new keyboard…
DATE: Tue 29 Dec 20:10:09 GMT 2020
On the 17th December Go1.16 beta 1 was released. I’ve been using it. For me
the biggest change is that “Module-aware mode is enabled by default”.
At the moment WolfMUD uses the default GOPATH mode. This makes it simple for
users to grab the code and compile it using the default mode. With the change
to module mode being the default, users will now have to fiddle around to use
GOPATH mode. In the interests of keeping things simple for users of WolfMUD
I’ll be making the switch to module mode…
[ THIS PARAGRAPH INTENTIONALLY LEFT BLANK ]
I had a big rant here about go modules, but decided it didn’t help anyone.
Adopting module mode is supposed to be simple. Just drop a go.mod file into
the root of your code and job done. Hrm, no. If it was that simple why are
there reams of documentation[1] just to deal with modules? I had a few issues
with the Go tools complaining about GOPATH and/or GOBIN being set and/or
unset. Only to then have the Go tools complain again because I then wanted to
cross-compile[2] and have the binaries put in a specific place[3]. Of course,
all of my build and release scripts now need to be updated. The documentation
on compiling WolfMUD from source will need updating — which will require some
maintenance of the WolfMUD download archive so that the correct documentation
is linked to for any given version.
There is some good news. Moving to modules will let me clean up the project
structure a little. Currently it looks like:
/home/diddymus/gits/WolfMUD/src
|-- bin
|-- pkg
|-- release
`-- src
`-- code.wolfmud.org
`-- WolfMUD.git
|-- attr
|-- cmd
|-- comms
|-- config
|-- data
|-- docs
|-- event
|-- frontend
|-- has
|-- log
|-- message
|-- recordjar
|-- robot
|-- server
|-- stats
|-- text
|-- tools
`-- zones
Now I can have a simpler structure:
/home/diddymus/gits/WolfMUD.git
|-- attr
|-- bin
|-- cmd
|-- comms
|-- config
|-- data
|-- docs
|-- event
|-- frontend
|-- has
|-- log
|-- message
|-- recordjar
|-- release
|-- server
|-- stats
|-- text
|-- tools
`-- zones
For now I have the bin and release directories in the main tree. The bin
directory is where all the different executables go with sub-directories for
different platforms when cross-compiling. The release directory is where
project releases get built. Before modules bin and release were outside the
project structure. This may change as I experiment more.
With module mode I’m using ‘go build’ instead of ‘go install’, compiling with
the equivalent of:
go build -o ./bin ./...
Build is used rather than install because a) install does not support -o to
put the binaries where I want — you have to set GOBIN instead, b) the same
build command can be used whether compiling native or cross-compiling.
In other news, for the past 20+ years I’ve used a Happy Hacking keyboard
(HHKB) as my daily driver and loved it. Well I mush have — they are not cheap,
I have two. Both are PS/2[4] models PD-KB100W that were first available in
1999. However, if you are sitting at a computer all day, every day, you need a
good keyboard. I like the 60% form factor, the feel of the keys and the
placement of the control key (where the caps lock is on a ‘normal’ keyboard).
After 20+ years my main keyboard has developed an annoying habit. The ‘9’ key
does not always register unless you hit it square on. I use the ‘9’ key a lot,
with a modifier key, when swapping virtual desktops. Holding down the modifier
while hitting the ‘9’ means I seldom manage to hit the ‘9’ square on, very
irritating.
This year for Christmas and birthday[5] my family all clubbed together and got
me a new Happy Hacking professional classic model PD-KB401W. They did check
with me first, I didn’t want the new Hybrid model with keymap customisation
and Bluetooth.
The new keyboard is… different, is the best way to describe it. I guess this
is to be expected after 20 years of development and refinement.
Straight away you notice that the key caps are thinner and seem shorter. I
think this may account for the keys being slightly clacky. The switches have
also changed from being membrane rubber dome to Topre. The older keys had a
nice, almost tactile, ‘pop’ to them. The new keys feel almost linear when
pressed but push back when rising. While typing I also noticed that I am
bottoming out more — resulting in a soft thock noise. The switches are still
supposed to be 45g but seem to be a lot lighter than my older keyboards.
Like I said the new keyboard is different, which is expected after 20+ years.
The new HHKB is still a very nice keyboard and I haven’t found another I’d
rather be typing on :)
--
Diddymus
[1] Go modules documentation: https://golang.org/ref/mod
[2] Cross-compiling has changed:
>GOBIN=${PWD}/bin/ GOOS=linux GOARCH=arm GOARM=7 go install ./...
go install: cannot install cross-compiled binaries when GOBIN is set
# What!?
>GOBIN=${PWD}/bin/ GOOS=linux GOARCH=arm GOARM=7 go build -i ./...
go build: -i flag is deprecated
>ls bin
# Hrm... nothing...
>GOOS=linux GOARCH=arm GOARM=7 go install -o ./bin/ ./...
flag provided but not defined: -o
usage: go install [build flags] [packages]
Run 'go help install' for details.
# But -o *is* a build flag :(
>GOBIN=${PWD}/bin/ GOOS=linux GOARCH=arm GOARM=7 go build ./...
>ls bin
# Still nothing...
>GOOS=linux GOARCH=arm GOARM=7 go build -o ./bin/ ./...
>ls bin
server wrjfmt
# Eureka! :|
>
Using -i when building is deprecated so much nothing is produced…
[3] Cross-compiling needs to put the binaries into specific directories.
Compiling for Arm v5, v6 and v7 puts all of the binaries for all of the
different versions into an linux_arm directory overwriting each other.
[4] I use a Cypress PS2toUSB KBM Bridge V2.02a which is a pain as it does
not like USB auto suspend.
[5] My birthday is close to Christmas and I often get a combined present.
Up to Main Index Up to Journal for December, 2020