Up to Main Index Up to Journal for September, 2019
JOURNAL FOR THURSDAY 19TH SEPTEMBER, 2019
______________________________________________________________________________
SUBJECT: Spitting feathers
DATE: Thu 19 Sep 18:56:44 BST 2019
I spent last week lounging around in someone’s conservatory with the intention
of lazily working away on WolfMUD. I had my ‘work anywhere’ setup, consisting
of a Chromebook and Raspberry Pi Zero W, with me — albeit with the Zero only
running Go 1.12 as 1.13 wouldn’t compile. However, as it turned out I could
only work in the late evening and at night. Why? Stupid bloody glossy screen
on the Chromebook — there was so much ambient light I couldn’t see a damn
thing on the Chromebook’s screen, even with the brightness on full and the
Chromebook powered from the mains :( I always have, and always will, hate the
abomination that is the glossy screen.
With yesterday being a WolfMUD Wednesday I thought I’d sit down to do some
coding. First of all sync with the Raspberry Pi to get my desktop up to date.
Then run the tests to see where I was at and then… what the hell?
$go test ./...
2019/09/19 14:19:42.323771 config.go:111: Server started, logging using UTC
timezone.
flag provided but not defined: -test.testlogfile
Usage of /tmp/go-build364329464/b001/attr.test:
FAIL code.wolfmud.org/WolfMUD.git/attr 0.016s
:
:
Digging around I found out this is issue #31859[1], seems to be intentional
and is covered in the release notes by:
Testing flags are now registered in the new Init function, which is invoked
by the generated main function for the test. As a result, testing flags are
now only registered when running a test binary, and packages that call
flag.Parse during package initialization may cause tests to fail.
The WolfMUD server can take an optional parameter which specifies an alternate
configuration file to use. The config package has an init function which looks
for said parameter so it knows the correct configuration file to use. An init
function is used in the config package so that the configuration values are
available to other packages in their init functions. This has worked for years
without issue.
With Go 1.13 if I use flags.Parse in config.init to get the parameter for
which configuration file to use then testing can break mysteriously? WTF? Here
we have a change to the standard library’s testing package that is breaking
the WolfMUD code — what about the Go1 compatibility promise?
Issue #31859 has a response[2] to that:
“We knew that fbc6a97 was going to break some people. It's arguably on the
fence on whether it's inside the go1compat umbrella (it's half API, half
tooling) and we guessed it would affect very few people. (generally more
advanced people who could read the docs/release notes & work around)”
*sigh* :(
I’m probably more worked up over this than I would otherwise be due to it
being ‘yet one more thing’ on top of: the addition of modules (whatever, could
be useful, documentation still a mess and all over the place, few people seem
to understand the intricacies of exactly how everything works), module mirrors
and proxies (no I don’t want to pull in code I can’t easily get at and verify
as it’s buried somewhere in the build cache), and finally the failure to
compile Go 1.13 on the Raspberry Pi.
So what am I going to do? I’m fed up and pissed off, so probably doing nothing
for now would be a wise idea. I might give the WolfMUD code a poke to see if
there is a simple workaround. I might wait and see if Go 1.13.1 changes
anything related to the issue — not holding my breath though.
Then again I might just wander off to “The Cottage”[3] for a little while…
--
Diddymus
[1] Go issue #21859 testing: DO NOT UNPIN panic in Init if flag.Parse has
already been called https://github.com/golang/go/issues/31859
[2] https://github.com/golang/go/issues/31859#issuecomment-489671173
[3] The Cottage: ../5/27.html
Up to Main Index Up to Journal for September, 2019