* Increase randomness in random sorting of new cards
Currently, the new cards appear roughly in the same order on consecutive days (if they are skipped by burying). This change aims to increase randomness by spreading out the salt across the hash space.
* Fix errors
* Feat/Easy Days
* format
* add easy_days_percentages to deck_config
* configure Easy Days via table
* remove unused code
* add translatable strings & add default of easy days
* don't check easy_days_percentages when deserialize
* pass test::all_reserved_fields_are_removed
* consider next_day_at when interval_to_weekday
* remove y-axis-title created in last simulation
* EstimatedTotalKnowledge should be integer
* Reorder deck option sections (dae)
- Move FSRS to bottom left, to move it closer to the top, and so
the left and right columns appear roughly balanced when FSRS is
enabled.
- Move Easy Days above Advanced
* Don't crash if wrong number of days (dae)
* Use lower field number (dae)
Repeated fields are more compactly stored in the first 15 fields.
* start of load balancer
* add configuration options; option to load balance per deck
* formatting
* clippy
* add myself to contributors
* cleanup
* cargo fmt
* copyright header on load_balancer.rs
* remove extra space
* more formatting
* python formatting
* ignore this being None
only doing this cause python has awful lambdas and can't
loop in a meaningful way without doing this
* only calculate notes on each day if we are trying to avoid siblings
* don't fuzz intervals if the load balancer is enabled
* force generator to eval so this actually happens
* load balance instead of fuzzing, rather than in addition to
* use builtin fuzz_bounds rather than reinvent something new
* print some debug info on how its load balancing
* clippy
* more accurately load balance only when we want to fuzz
* incorrectly doublechecking the presence of the load balancer
* more printfs for debugging
* avoid siblings -> disperse siblings
* load balance learning graduating intervals
* load balancer: respect min/max intervals; graduating easy should be at least +1 good
* filter out after-days under minimum interval
* this is an inclusive check
* switch load balancer to caching instead of on the fly calculation
* handle case where load balancer would balance outside of its bounds
* disable lb when unselecting it in preferences
* call load_balancer in StateContext::with_review_fuzz instead of next to
* rebuild load balancer when card queue is rebuilt
* remove now-unused configuration options
* add note option to notetype to enable/disable sibling dispersion
* add options to exclude decks from load balancing
* theres a lint checking that the link actually exists so I guess I'll add the anchor back in later?
* how did I even update this
* move load balancer to cardqueue
* remove per-deck balancing options
* improve determining whether to disperse siblings when load balancing
* don't recalculate notes on days every time
* remove debug code
* remove all configuration; load balancer enabled by default; disperse siblings if bury_reviews is set
* didn't fully remove caring about decks from load balancer sql query
* load balancer should only count cards in the same preset
* fuzz interval if its outside of load balancer's range
* also check minimum when bailing out of load balancer
* cleanup; make tests happy
* experimental weight-based load balance fuzzing
* take into account interval when weighting as it seems to help
* if theres no cards the interval weight is just 1.0
* make load balancer disableable through debug console
* remove debug prints
* typo
* remove debugging print
* explain a bit how load balancer works
* properly balance per preset
* use inclusive range rather than +1
* -1 type cast
* move type hint somewhere less ugly; fix comment typo
* Reuse existing deck list from parent function (dae)
Minor optimisation
Due to the orphan rule, this meant removing our usages of impl ProtoStruct,
or converting them to a trait when they were used commonly.
rslib now directly references anki_proto and anki_i18n, instead of
'pub use'-ing them, and we can put the generated files back in OUT_DIR.
* Move open_test_collection into Collection test impl
* Fix invalid ids when checking database
* Report fixed invalid ids
* Improve message when trying to export invalid ids
Also move ImportError due to namespace conflicts with snafu macro.
* Take a human name in DeckAdder::new
* Mention timestamps in the db check message (dae)
Will help to correlate the fix with the message shown when importing/
exporting.
* Ensure state mutator runs after card is rendered
* Ensure ease buttons only show when states are ready
* Pass context into states mutator
* Revert queuing of state mutator hook
Now that context data is exposed users shouldn't rely on the question
having been rendered anymore.
* Use callbacks instead of signals and timeout
... to track whether the states mutator ran or failed.
* Make mutator async
* Remove State enum
* Reduce requests and compute seed on backend
* Remove outdated comment.
* Revert removal of independent bury rules
* Revert 'hierarchical bury modes'
It's now again allowed to bury new, but not review cards e.g., but
siblings of previously gathered card queues will not be buried.
* Tweak docs (dae)
* Add missing Learn and PreviewRepeat queues
* Add CardAdder test helper
* Add option to have new cards ignore the review limit
Also entails a lot of refactoring because the old code was deeply
coupled to the previous behaviour.
* Add global option to ignore review limit
* Refactor decrementation
* Unify testing
* Enforce hierarchical bury modes
Interday learning burying is only allowed if review burying is enabled
and review burying is only allowed if new burying is enabled.
Closes#2352.
* Switch front end to new bury modes
* Wording tweaks (dae)
* Hide interday option if using v2 scheduler (dae)
* Run cargo +nightly fmt
* Latest prost-build includes clippy workaround
* Tweak Rust protobuf imports
- Avoid use of stringify!(), as JetBrains editors get confused by it
- Stop merging all protobuf symbols into a single namespace
* Remove some unnecessary qualifications
Found via IntelliJ lint
* Migrate some asserts to assert_eq/ne
* Remove mention of node_modules exclusion
This no longer seems to be necessary after migrating away from Bazel,
and excluding it means TS/Svelte files can't be edited properly.
* Add crate snafu
* Replace all inline structs in AnkiError
* Derive Snafu on AnkiError
* Use snafu for card type errors
* Use snafu whatever error for InvalidInput
* Use snafu for NotFoundError and improve message
* Use snafu for FileIoError to attach context
Remove IoError.
Add some context-attaching helpers to replace code returning bare
io::Errors.
* Add more context-attaching io helpers
* Add message, context and backtrace to new snafus
* Utilize error context and backtrace on frontend
* Rename LocalizedError -> BackendError.
* Remove DocumentedError.
* Have all backend exceptions inherit BackendError.
* Rename localized(_description) -> message
* Remove accidentally committed experimental trait
* invalid_input_context -> ok_or_invalid
* ensure_valid_input! -> require!
* Always return `Err` from `invalid_input!`
Instead of a Result to unwrap, the macro accepts a source error now.
* new_tempfile_in_parent -> new_tempfile_in_parent_of
* ok_or_not_found -> or_not_found
* ok_or_invalid -> or_invalid
* Add crate convert_case
* Use unqualified lowercase type name
* Remove uses of snafu::ensure
* Allow public construction of InvalidInputErrors (dae)
Needed to port the AnkiDroid changes.
* Make into_protobuf() public (dae)
Also required for AnkiDroid. Not sure why it worked previously - possible
bug in older Rust version?
* Enable state-dependent custom scheduling data
* Next(Card)States -> SchedulingStates
The fact that `current` was included in `next` always bothered me,
and custom data is part of the card state, so that was a bit confusing
too.
* Store custom_data in SchedulingState
* Make custom_data optional when answering
Avoids having to send it 4 extra times to the frontend, and avoids the
legacy answerCard() API clobbering the stored data.
Co-authored-by: Damien Elmes <gpg@ankiweb.net>
* avoid repinning Rust deps by default
* add id_tree dependency
* Respect intermediate child limits in v3
* Test new behaviour of v3 counts
* Rework v3 queue building to respect parent limits
* Add missing did field to SQL query
* Fix `LimitTreeMap::is_exhausted()`
* Rework tree building logic
https://github.com/ankitects/anki/pull/1638#discussion_r798328734
* Add timer for build_queues()
* `is_exhausted()` -> `limit_reached()`
* Move context and limits into `QueueBuilder`
This allows for moving more logic into QueueBuilder, so less passing
around of arguments. Unfortunately, some tests will require additional
work to set up.
* Fix stop condition in new_cards_by_position
* Fix order gather order of new cards by deck
* Add scheduler/queue/builder/burying.rs
* Fix bad tree due to unsorted child decks
* Fix comment
* Fix `cap_new_to_review_rec()`
* Add test for new card gathering
* Always sort `child_decks()`
* Fix deck removal in `cap_new_to_review_rec()`
* Fix sibling ordering in new card gathering
* Remove limits for deck total count with children
* Add random gather order
* Remove bad sibling order handling
All routines ensure ascending order now.
Also do some other minor refactoring.
* Remove queue truncating
All routines stop now as soon as the root limit is reached.
* Move deck fetching into `QueueBuilder::new()`
* Rework new card gather and sort options
https://github.com/ankitects/anki/pull/1638#issuecomment-1032173013
* Disable new sort order choices ...
depending on set gather order.
* Use enum instead of numbers
* Ensure valid sort order setting
* Update new gather and sort order tooltips
* Warn about random insertion order with v3
* Revert "Add timer for build_queues()"
This reverts commit c9f5fc6ebe.
* Update rslib/src/storage/card/mod.rs (dae)
* minor wording tweaks to the tooltips (dae)
+ move legacy strings to bottom
+ consistent capitalization (our leech action still needs fixing,
but that will require introducing a new 'suspend card' string as the
existing one is used elsewhere as well)
`counts.learning` includes interday learning cards, so it is not
suitable to determine how many cards from the (intraday!) learning queue
are already included in the learning count when updating it.
The 'avoid showing learning card twice' logic is now only applied
when the next learning card was already due to be shown. This'll mean
there will be cases where a learning card does get shown twice near
the end, but it makes the behaviour easier to reason about, for both
us and end users.
There were a few issues going on here:
- If some operation had invalidated the queues, they were subsequently
recreated with a call to .get_queues() in the undo handling code. This
could happen after the changes to the card had already been reverted,
leading to a queue state that didn't match our expectations.
- More generally, it's not safe to assume our mutations will apply
cleanly after the queue has been rebuilt. The next card will vary
depending on the number of remaining cards when interspersing cards of
different types, and a queue-invalidating operation will have changed
the learning cutoff.
So rather than rebuilding the queues on demand, we now check that they
already exist, and were created at the time we expect. If not, we
invalidate them and skip applying the mutations, and a subsequent
refresh of the UI should rebuild the queues correctly.
As part of this change, the cutoff snapshot has been moved into the
normal answer update object.
One possible downside here is that adding a note during review may cause
a newly due learning card to appear when undoing a different review.
If this proves to be a problem, we could potentially note down the
learning cutoff and apply it when queues are rebuilt later.
Context: https://forums.ankiweb.net/t/more-cards-today-question-about-v3/12400/10
Previously, interday learning cards and reviews were gathered at the
same time in v3, with the review limit being applied to both of them. The
order cards were gathered in would change the ratio of gathered learning
cards and reviews, but as they were displayed together in a single count,
a changing ratio was not apparent, and no special handling was required
by the deck tree code.
Showing interday learning cards in the learning count, while still
applying a review limit to them, makes things more complicated, as
a changing ratio will result in different counts. The deck tree code
is not able to know which order cards will appear in, so without changes,
we would have had a situation where the deck list may show different counts
to those seen when clicking on a deck.
One way to solve this would have been to introduce a separate limit for
interday learning cards. But this would have meant users needed to
juggle two different limits, instead of having a single one that controls
total number of (non-intraday) cards shown.
Instead, the scheduler now fetches interday cards prior to reviews -
the rationale for that order is that learning cards tend to be more
fragile/urgent than reviews. The option to show learning cards
before/after/mixed with reviews still exists, but it applies only after
cards have been capped to the daily limit.
To ensure the deck tree code matches the counts the scheduler gives,
it too applies limits to interday learning cards first, and reviews
afterwards.
Interday learning cards are now counted in the learning count again,
and are no longer subject to the daily review limit.
The thinking behind the original change was that interday learning cards
are scheduled more like reviews, and counting them in the review count
would allow the learning count to focus on intraday learning - the red
number reflecting the fact that they are the most fragile memories. And
counting them together made it practical to apply the review limit
to both at once.
Since the release, there have been a number of users expecting to see
interday learning cards included in the learning count (the latest being
https://forums.ankiweb.net/t/feedback-and-a-feature-adjustment-request-for-2-1-45/12308),
and a good argument can be made for that too - they are, after all, listed
in the learning steps, and do tend to be harder than reviews. Short of
introducing another count to keep track of interday and intraday learning
separately, moving back to the old behaviour seems like the best move.
This also means it is not really practical to apply the review limit to
interday learning cards anymore, as the limit would be split between two
different numbers, and how much each number is capped would depend on
the order cards are introduced. The scheduler could figure this out, but
the deck list code does not know card order, and would need significant
changes to be able to produce numbers that matched the scheduler. And
even if we ignore implementation complexities, I think it would be more
difficult for users to reason about - the influence of the review limit
on new cards is confusing enough as it is.
