So, there are now two additional repos of my code on GitHub that recently got published, both under the MIT license. Neither is any show-stopping major project, but I figured I’d let everyone know nevertheless, and write up a few notes about it. Both have been added to my programming portfolio garden.

Repo #1: Crate Version of Prefix Ranges#

Arvid Norlander (blog, GitHub) reached out to me to ask if I wanted to publish my little Rust module from my post on prefix ranges as a crate, or, failing that, if I could license it as open source so he could publish it. I had thought of most of my code on this blog up until this point as example code not worth licensing, but his prompting changed my mind. If it’s just trivial example code, it’s not worth not open sourcing, so I might as well release the website’s example code under an MIT license.

This particular piece of code seems like the wrong end solution to the problem at hand – though it is the solution I ended up using when faced with the problem in a larger project. Ideally, I would like to write a follow-up piece to the prefix range article, discussing how to fix BTreeMap to generalize not just to splitting on various keys based on their ordering properties, but based on any appropriate function that acts as a range (i.e. that monotonically transitions from false to true when looping over items in sorted order by the Ord trait), as a generalization of Bound. Then, prefixes could be represented in terms of such a function, and we could leverage the full efficiency of a BTreeMap without having to do any extra UTF-8-mongering.

But fully implementing such a thing would mean patching the standard library, and fully writing that blog post would mean a lot of benchmarking work. I still plan on doing it someday, but as I point out many times, this is a hobby blog (although I do now support buying me a coffee, that is meant in the true spirit of buying me an extra beverage as a token of thanks. At the time of this writing no one has clicked it, and I certainly expect no more than occasional literal coffees to come of any money from it), and so follow-up posts will happen when they happen (although nagging me about it, nicely, over e-mail is allowed).

Repo #2: Texas Hold-Em Library/Quiz App#

I’ve been writing some code to do with the most popular modern poker variant, Texas Hold-Em. It lives in a repo on GitHub. Ideally, it’ll turn into an app to help me and some buddies practice reading flops, counting outs, seeing who’s ahead, and doing other hold-em mental calculations. I might also extract a library or even a framework for writing AIs, or playing against them. Maybe even a front-end app could be added, either in Rust or in Reflex in Haskell.

But no promises! See the hobby blog note above! If you really want a feature, I’ll happily accept PRs!

Of course, this wouldn’t be the first such codebase, or even the first in Rust. I’m just having run. I enjoyed writing the code so far, and I figured I’d put it on GitHub in the meantime, even if it never becomes particularly useful.

Writing it with all its combinatoric randomness made me really learn to appreciate itertools, a collection of iterator methods that for various reasons haven’t been accepted or stabilized in the standard library. It’s been good exercise writing in functional programming, iterator and iterator-transformer style, which is a little harder in Rust than in Haskell.

Also, while I understand why Rust doesn’t have generators (there is an excellent blog series about the topic on “Without Boats”), many of the reasons are historical and, well, I just really wish it did.

Additional future exploration might include zany optimizations, perhaps inspired by (but not directly following in the feet of) this zany hand evaluation algorithm implemented in Rust many places including here by Wataru Inariba – although regular optimizations probably come first.