A bit loopy, feeling stretched and compressed. Slightly mad, depressed, and generally feeling a bit weird. As I write this on the 4th of February 2022, yet another new year has begun – not the calendar year this time around, rather the lunar new year, the Year of the Tiger.
Omicron remains an issue, now we have whispers of “child of Omicron”, the new variant. Apparently even more transmissible, but still moderately harmless. 30 deaths a day in my state, which sounds bad, but it could be a lot worse without the vaccinations. Still everyone remains safety obsessed and are hunkering down to an extent which seems to be a bit irrational. People are saying “sure, Omicron is harmless, but that doesn’t guarantee the new variant won’t be far more deadly”. Well, that is the director general of the WHO, so I guess that is fair enough! But yes generally fatigue. Everyone wants things to be over.
Kids have returned to school. The AdBlue situation has been sorted out. Assertive going on aggressive rumblings from the regional hegemon have died down, at least for now. There are indications that maybe in another few weeks the state government may be more assertive in trying to coax corporations to send workers back to the CBD and greenlight more movement in the city. The mandarins of the state public health response are still adopting a “wait-and-see” approach though I think, they would like to see where the statistics are heading before increasing the miscibility of people in the city.
RAT tests are still hard to come by. They’ve been taken off eBay due to concerns of price-gouging / gaming of the system, and Chemist Warehouse doesn’t list them online. This makes this tricky, because some people prefer not to see younger ones (such as myself) without having the check and balance of a RAT test. Hopefully though general public availability of RATs improves as February progresses.
The statistics are looking encouraging, we are down to less than 750 hospitalisations in the state now, ICU figures are also decreasing, less than 80 as of today. Hospitals are still in Code Brown though, which means no elective surgery in the state at present.
Of course it is mid-summer now, Winter is June / July. Hopefully the coming Winter will be kind to us.
I damaged one of the family cars, we had to make a claim on it, we should have it back within a couple of weeks. Low velocity collision with a concrete pole in a parking lot, no-one was hurt.
I’m feeling a bit compressed psychologically. Work has been a good distraction but I’ve been suffering because work is being held against me as a mark of condemnation. I am feeling slightly sick, not as sick as I was several days ago, but slightly sick mentally.
I went for a run yesterday, that helped a little. I’ve also been trying to slow down a bit, that has helped too (although evidently there are limits, because I can’t just stop doing paid work, as income is important for things like paying bills). It might not appear to be the case, but I have been taking more time out of hobby work, trying to make time for just empty space, or reading, or conversations.
Hopefully things improve over the coming weeks.
What went well?
This month I:
Rebuilt and streamlined my terraform deployments of my Kafka VM,
Managed to get the Protongraph Provider consuming from the rebuilt Kafka VM,
Managed to get the Protongraph Provider pushing consumed messages to the Protongraph Worker,
Started planning how to get the Protongraph Worker producing back to Kafka if operating in Producer mode.
I’m very happy with progress this month with regards to the Sandbox project. One or two milestones of moderate complexity were passed. I’m feeling optimistic that the creative subsystem should be more or less drafted within another one to two sprints.
I even made some progress with some long running research objectives in regards to another off and on project.
What didn’t go so well?
My mental health took a beating this month. Hopefully next month is better.
What’s the outlook?
Good.
I will endeavour to produce to the Kafka VM from the Protongraph Worker next sprint.
After that, I’ll draft a PR against the main public Protongraph Worker repo, making sure that I document things moderately clearly and well – which could be a bit of work in and of itself.
If I have any time left after that I might start looking into plumbing in the creative subsystem by producing to a Kafka topic from the communication subsystem on receipt of an appropriate signal from a client (within a given instance). For reference, here is the general picture as to how I wish to use this system again. I’ve done (4) and (5), will hopefully finish (6) in the next sprint, and after that hopefully be able to make a start on (2) and (3).
Today I started looking into setting up a Producer from the Worker to Kafka, once the job has done its thing. I also tidied up manual compilation of the Protongraph binary slightly.
While looking into this, I realised that there is a little bit more to it than this, I need a way to build the Worker so that it can take an optional config containing Kafka secrets – so that it can inject that into the compiled binary, and also actually drafting a Makefile so that I can compile a binary! Fortunately I have a template for at least the latter of these, I just need a way to parse arguments provided to make so as to know when to use a secrets file, i.e. make -secrets <secrets_path>, with -secrets an optional flag to pass to the make command … can GNU make take command flags as arguments?
Also when running Protongraph, I need to compile it in Kafka mode or in Default responder mode. This distinction is important because if in Default responder mode I want to emit back along the Websocket connection when a job is done, otherwise I want to instead produce to Kafka per a provided Kafka topic.
The Kafka topic also will need to be a config parameter, as Protongraph is a public project and I don’t want to expose this; also the Kafka broker as well.
So when making Protongraph all I need to do is just have something like make kafka, where kafka is a new makefile task, i.e. just have a new command in the makefile called “kafka”. Then this can read from a config folder if present, and the config folder can have the secrets, as well as a config file containing the broker, topic, and anything else that the producer needs to know.
Then if compiling as a kafka binary, there should be a flag discoverable within the application code when the job is done that allows the binary to know where to send the output. Presumably I want to read from a config (based on what has been passed to make, and then copied into the corresponding position in the compiled executable) and then within the application code, do something like:
var _ipc_server: IPCServer
var topic, broker: string
var config: boolean
func _init():
_ipc_server = default_godot_websocket_server()
config = retrieve_config(<config_location>)
if config != null
topic = config.topic
broker = config.broker
func output (msg):
if config:
librdkafka.produce(broker, topic, msg)
else:
_ipc_server.send(msg)
Today I managed to get easywsclient onforwarding a message manually generated in my Kafka VM, consumed by the Provider, and then emitted and acknowledged by the Worker.
This is excellent progress.
Next, I will move to tidy up my PR producing to Kafka from the Worker in a branch I’m currently working on. After I’ve done that, I will draft a new PR against the main Protongraph repo’s develop branch – and will have completed the current sprint. Looks like I might be able to complete it this time, I’m not sure.
After that, one thing that I’d like to look into is adding threading support to the Provider using https://github.com/aphenriques/thread. I think that this would be a good idea while this work is still fresh in my mind.
Today I started down the path of implementing easywsclient in the Provider.
I managed to get most of the code in place, but for some reason I can’t make easywsclient a shared library! Confusing. I think I need to build it as a dylib somehow … regardless, I configured mklove with it, that didn’t work, but I think I’m on the right track. Maybe I need to include mklove.base in my Makefile?
No, including mklove is a bad idea, it seems to have things hardcoded in it that are librdkafka specific (here, here). Better to do things from first principles, I think a -shared flag should be enough to pass to gcc. I’ll look into massaging the Makefile accordingly; currently it is set to use the default gcc settings I believe – much too terse, I’ll need to configure things a bit more than what is specified in the current Makefile.
Good is the search for and generation of pattern. Evil is the search for techniques to disrupt pattern; generation of antipatterns.
But antipattern provokes the development of deeper pattern in controlled dosage to the overall system state, rather akin to hormesis. For instance, antipatterns in software often inspire the development of stronger patterns in order to detect and test for their emergence, along the lines of linting, functional programming, or the usage of proof-based languages / category theory to drive innovations in tooling.
Nonetheless, this search for the pattern of antipattern and pattern is itself prone to antipattern, paradox.
One can only proceed by approximations of the possible. One’s own inclination and stance as to the balance of order and chaos, building or pulling apart.
I like to build. But the world is a big place. There are those that wish to pull apart. Nonetheless Romans 8:38-39 holds to those that remain firm.
So I’ll need to build Boost instead and link it in order to use websocketpp. It looks like boost makes heavy use of gitsubmodules, so I’ll likely want to fix commits on a git submodule fetch when I run the master make command in the Provider repo.
Rust apparently has a number of advantages over C++, namely automatic garbage collection, although both languages remain under active development. Apparently to garbage collect in C++ one needs to have a properly defined destructor for every class. One can unit test destructors by following the suggestions in thesetwo stackoverflow answers.
However, I was wondering if there might be a dark horse here, in that there could be another way to write highly performant code suitable for a game engine, and I wondering about Julia (https://julialang.org/). Cribbing directly from the lede of the wikipedia entry for Julia:
Where's my hat?! 