Replace SDL2 with glium and glutin for better rendering.
Also we can then use imgui-rs.

The current implementation of hasherlife uses IDs as handles to the actual Nodes in the HashMap<ID, Node>. Instead it would be sufficient to use references (&Node) into a HashSet<Node>.

The largest problem with this refactoring lies in satisfying the borrowck because there are a lot of lifetimes involved. I'm not sure if it is even feasible to do a trivial refactoring or if it's necessary to use different data structures altogether. Maybe there is unsafe code necessary.

Another problem is the immutability of the hashset entries. We need a different way to memoize the computed Inode::result because we can't mutate the Nodes.

At the moment lifeash (library) lacks good error handling.
We should return Result from all fallible funcitons. I'd propose the thiserror crate.

Cremator should use the eyre crate for error handling.

We should consider if it makes sense to split hasherlife into a library and a separate binary crate.

Library

The library contains mainly the implementation of Gosper's algorithm, a universe interface and a RLE reader.
For error handling we should implement our own error types using the thiserror crate.

Binary

The binary contains stuff like the graphical renderer and probably a CLI.
For error handling we should use the eyre crate.

In the java reference ./refs/java/HashLifeTreeNode.java they use a updated way for computing the evolution of a node. We should take a look at it and maybe port it.

The hole purpose of the hashlife algorithm is a concept called "superspeed". It is the idea that the state of a node is not computed one generation into the future but instead multiple generations far into the future. The state of a node at level n can be computed 2^(n-2) generation steps into the future.
The result is then memoized and will be stored in the hashtable.

This has yet to be implemented.

We need a graphical renderer for (the binary part of) hasherlife.

We first need to consider which crate is best suitable for 2D rendering.

We should implement a more sophisticated RLE pattern reader.

It should also provide a selection of popular life patterns which should be easily usable. A good resource for popular patterns is the LifeWiki.

A CLI could help to specify the way the pattern should be read. File reading, stdin reading or just using a provided existing pattern.

In the smeagol reference (./refs/smeagol/src/util.rs) a Leaf of the QuadTree lives at level 3 and consists of an 8x8 grid of boolean values. It can therefore be represented as an u64. We should port this idea.

Create documentation for lifeash and cremator by writting doc comments.