Closes#766
- changes the on-disk representation from % to a multiplier,
eg 250 -> 2.5, as this is consistent with the other options
- resets deck configs at or below 1.3 to 2.5
- for any cards that were using a reset deck config, reset their
current factor if it's at or below 2.0x. The cutoff is arbitrary,
and just intended to make sure we catch cards the user has rated
Easy on multiple times. The existing due dates are left alone.
- Fix permissions in `/opt` to allow non-root user to compile Anki (which requires reading and/or creating files below `/opt`).
- Create `pythonbuilder` stage, which runs only `make build`. The wheels from this stage are copied into the final stage.
- Add README.docker
The only dependency which required nightly compilers was pyo3, which
supports stable Rust (1.39.0 and later) since version 0.11.0. Supporting
stable Rust makes it easier to package Anki for distributions. No other
code changes were required.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
We can't link against libzip2.so.1 when building manylinux wheels, but
the only dependency which required this was "zip" and we don't appear to
make use of bzip2 in Anki.
This fixes the following "make build" error on Linux:
x maturin failed
Caused by: Failed to ensure manylinux compliance
Caused by: Your library is not manylinux compliant because it links the following forbidden libraries: ["libbz2.so.1"]
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
The previous implementation had some slightly questionable memory safety
properties (older versions of PyO3 didn't uphold the Rust aliasing rules
and would thus create multiple &mut references to #[pyclass] objects).
This explains why Backend has internal Mutex<T>s even though all of its
methods took &mut self.
The solution is to simply make all methods take &self, which luckily
doesn't pose too make issues -- most of the code inside Backend already
has sufficient locking. The only two things which needed to be
explicitly handled where:
1. "self.runtime" which was fairly easy to handle. All usages of
the Runtime only require an immutable reference to create a new
Handle, so we could switch to OnceCell which provides
lazy-initialisation semantics without needing a more heavy-handed
Mutex<tokio::runtime::Handle>.
2. "self.sync_abort" was simply wrapped in a Mutex<>, though some of the
odd semantics of sync_abort (not being able to handle multiple
processes synchronising at the same time) become pretty obvious with
this change (for now we just log a warning in that case). In
addition, switch to an RAII-style guard to make sure we don't forget
to clear the abort_handle.
As a result, we now no longer break Rust's aliasing rules and we can
build with newer versions of PyO3 which have runtime checks for these
things (and build on stable Rust).
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
prost-build doesn't generate rustfmt-safe code, so we had to add it to
the ignore list for rustfmt on "make check". However, the ignore list
isn't supported by stable rustfmt, so we have to work around this some
other way -- in this case, just do "rustfmt" on the generated file in
"build.rs" (this way, formatting errors in checked-in source code are
still caught but generated code doesn't cause spurrious errors).
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Docker provides a standard way of installing software. This is particularly useful with software that requires fairly complex dependencies, like Anki. The Dockerfile added in this commit builds a Docker image with Anki. The Docker image is based on `python:3.8`, which is based on a Debian Buster image. This Docker image can be useful to end users, because it can be installed on any system that has Docker (e.g., Windows, macOS, Linux), and it is also useful to developers who might not have -- or want to install -- the dependencies that Anki requires at compile time.
To build the image, run `docker build --tag anki .` in the project root directory.
To run the image with a GUI (on Unix-like systems), run
```
docker run --rm -it --env "DISPLAY=$DISPLAY" --volume /tmp/.X11-unix:/tmp/.X11-unix anki
```
One may also mount a user's Anki directory into the container and run the container as the current user.
One may also run with Singularity (which typically has more transparent support for GUI applications and behaving as the current user) by first building the Docker image as above and then converting to Singularity Image Format (SIF) with
```
sudo singularity build anki.sif docker-daemon://anki:latest
```
Run the Singularity image with
```
singularity run anki.sif
```
