Do not follow this link

~ntietz/isabella-db

Update CI build to use current valid Fedora image
134f1c0b — Sam Calvert 1 year, 3 months ago
Update proc-macro2 and remove is_some_and feature declaration.

- Update proc-macro2 because of regression in nightly toolchain
- Remove is_some_and feature declaration as it is now stable
Change ticket tracker link in README.md to link directly to tracker instead of list of trackers
Simplify the data structures without degrading performance

Implements: https://todo.sr.ht/~ntietz/isabella-db/15
Load shards and serve query results from all shards.

Implements: https://todo.sr.ht/~ntietz/isabella-db/14
Parallelize loading of PNGs and add script to split PNGs into
smaller files for more efficient loading.

Implements: https://todo.sr.ht/~ntietz/isabella-db/13
Fix bug in bitwise-and which resulted in skipping lots of games
Add sorting of games to improve performance of index lookups

Implements: https://todo.sr.ht/~ntietz/isabella-db/10
Add benchmarking crate and make a benchmark of UniqueFixedIndex
Create opening tree.

This creates a basic opening tree UI which will show the available moves
from a given position, along with their result stats (percents
win/loss/draw).

This entailed some related changes. Mostly, these changes were utilities
in the SparseBitmap.

This is moderately slow right now. With a reasonably sized dataset (3.8M
games) on my server, it takes ~150 ms to generate the moves for an
early-game opening position. Future work will improve this or track down
the cause.

Implements: https://todo.sr.ht/~ntietz/isabella-db/7
Implement GameResultIndex to allow finding games which have a particular result
Implement BitOr and BitAnd for SparseBitmap, and add an iterator.

This implements bitwise operations for the SparseBitmap so that we can
combine two bitmaps to get the end result of that. (Or will be used more
than And, likely, but both are good to have.)

In the process of implementing this feature, the implementation of the
bitmap was also simplified. Instead of alternating between runs of 0s
and 1s, we simply record just the runs of 1s along with their starting
position. The size should be the same (up to +/- 4 bytes per bitmap),
and this drastically simplifies the implementation of and and or.
Create very basic opening tree web service.

This adds in a new bin target (`web`) and serves a few routes for that
service. Basically, it lets you see a board position and the legal moves
from there, then click through to the legal moves and see it evolve.

This doesn't do anything particularly useful yet, but is the foundation
that displaying win/loss/draw percents for openings will be based on.
Add custom debug impl for large types
Fix incorrect comment which still referred to an old hash size
Write basic bitmap and position index implementation along with design
doc for where things are headed.

This is an incomplete position index implementation which serves as the
foundation for what is needed going forward. It's primarily missing:

- nice iterator to consume results (todo with the consumer)
- metrics/stats as laid out in the doc

Signed-off-by: Nicholas Tietz-Sokolsky <me@ntietz.com>
Implements: https://todo.sr.ht/~ntietz/isabella-db/6
Read in the entire file, rather than use buffering, to shave off a bit of time (25% savings in read)
Switch from messagepack to bincode crate for faster load/save.

It now takes ~30 seconds to save and ~50 seocnds to load. I think this can be faster
with a custom binary protocol, but I think this is also quite adequate for now.
Switch to new PGN parser and implement to-disk serialization.

This makes it so that we can read in the full Caissabase file without
any errors. We can also save the database back in a Messagepack format.
That format is pretty slow to save and slower to read, so we will want
to do something different; I think some manual binary packing of a
format is in order.
Next
Do not follow this link