hashedixsearch VS xbattbar3

Around April 2020 I identified a project need for an "inverted search engine" - a system that would accept documents (recipe ingredient lines, like "three large onions") as input, and would match those against a dataset of terms (ingredient names, like "tofu" or "tomato").

That would have been possible with a feature like percolation[1] in Elasticsearch, but I felt that the overhead of maintaining state (percolator queries) by using a network service would be excessive and that building an in-process alternative would be feasible.

The result is hashedixsearch[2], a pure-Python search engine library with support for stemming, synonyms and a few other features[3] to support the use-case.

It builds upon inverted index support provided by the hashedindex[4] library.

[1] - https://www.elastic.co/guide/en/elasticsearch/reference/curr...

[2] - https://pypi.org/project/hashedixsearch/

[3] - https://github.com/openculinary/hashedixsearch/blob/6980ee63...

[4] - https://github.com/michaelaquilina/hashedindex/

I depend on my battery monitoring tools every day (xbattbar[1] for X and wattbar[2] for Wayland), and each of those was written over about two days time.

However, the coolest thing would have to be the project I'm in the middle of now, but it requires some explanation. At Hackerspace.gent, the center of the lounge area is Bloembak[3], a 1x1m table with a 32x32 pixel display covering its surface. During a discussion at a local bar with its creator, I decided it would be absolutely brilliant to be able to run shaders on it. So in my spare time over the last week, I wrote an interpreter for SPIR-V shaders to check my understanding, and then over the course of about 2 days, I rewrote the entire thing to target LLVM. While it's not finished (I only implement ~2/3 of the opcodes in SPIR-V and 1/10 of GLSL.std.450), it's already sufficient to run quite a few shaders off shadertoy at a reasonable framerate.

[1] https://github.com/thequux/xbattbar3