Well, I didn't touch the Earley parser, so, um, "success". Instead, I pulled up some old prototype code from I don't remember exactly how long ago, and tried to polish it up. In this case, the code was for representing card decks. The plan is to incorporate this into one of my other projects, but I haven't done that yet, preferring to go through a few prototype phases.
So, after I posted the last entry, I basically pulled up the most recent prototype, and started retyping and adapting it in Jupyter. Replacing old questionable decisions with new questionable decisions, that kind of thing.
Earlier today, I was able to set it up to represent a basic 52-card deck, and I also got some hanafuda decks in there, albeit missing lots of details. I regard this as pretty promising, because it proved out the following features:
- Representing a very regular matrix of rank and suit
- Representing extra one-off cards
- Representing distinct "copies" of a card
- Representing "copies" of a rank or suit (the hanafuda kasu are currently represented via duplicates of the kasu rank, rather than duplicates of the combination of rank and suit; assuming this distinction makes sense, I don't know if it's relevant, and if so, whether I should be implementing it this way, or, like, the opposite way; my hope is that details of ordering are more relevant than the precise semantics that I use to handle the duplication)
At this point, there are two major things to work on:
- Making sure the code is correct
- Representing more decks
Honestly, as I think about planning this, everything comes back around to MOTR. I want to do things like:
- Cut a new MOTR release
- Pick my other Python projects back up using MOTR
- Pull this code into it, taking advantage of modules to keep it from being, like, super long
Everything comes back to this project, for a simple reason: I see MOTR as my chance to turn my task runner code into a more compact, maintainable format than what I have currently. I assume tox has changed a bunch since I last tried to write a config file, but my experiences working with other people's parameterized tox files have kind of soured me on that idea. I much prefer Nox, but I never did figure out how to track dependencies between sessions, and I want to try to take advantage of concurrent execution.
- tox has concurrent execution, but its dependency tracking is designed differently from MOTR, and I prefer MOTR's design, obviously, because why would I design something that I don't want?
- I don't know if Nox has any kind of inter-session dependencies planned or implemented, but I do remember seeing an issue asking for concurrent execution get bogged down in how to reconcile "execute things in parallel" with "real-time command output"
- MOTR discards the latter, at least for now, in exchange for focusing on producing viewable artifacts, principally HTML, so I can look over them afterwards
Thinking about working on this, I think the right tack to take is to focus on other stuff like the poetry until next weekend, and then get back into this. We'll see if I can hold myself to that. Anyway, it's late.