Flash card tool (like Anki/Mnemosyne) for plan9

bbacfa7 ignore unused results

2 months ago

021ee65 cli: fix infinite loop when stdin is closed during prompt

9 months ago


If you need help, or just want to chat, drop by #dsm-9 on libera.chat

SuperMemo-2 algorithm implementation (primarily intended) for Plan9. This fills the same niche as Mnemosyne / Anki, except without sucking. There are no dependencies (both Mnemosyne and Anki depend on Python3, QT5, PyQt5, and a ton more). This implementation is designed to be useful both with digital cards and physical cards, but physical cards are the primary niche DSM-9 targets.

A single deck may contain up to 65,534 cards. Cards are stored as lines with three fields. The first field, which is mandatory, is the unique name. The second and third are both optional, and are the front and back of the card respectively. The fields are separated with three at symbols (@@@), a sequence which is not allowed to ever appear within a field. The front and back may be stored in any plain text format - unadorned text, markdown, HTML, or anything else. Note that, despite the front and back being optional, the delimiter is currently required.

Deck files must have one field per line, the card ID. More fields can be added with @@@ as the delimiter, but will be ignored by the current programs. Deck files must end in .deck. A log file will be maintained by the implementation alongside the deck file, with the same name but the .log extension. This file is plain text, and should be compatible with oboeta and any other software which accepts the simple format used.

In addition to the deck file, there is a log file, which is managed entirely by DSM-9. All that you need to know, as the user, is that the log file must be kept in the same folder as the deck file, and must have the same name (with the only difference being the file extension). Details are provided here for completeness; this section is not important to usage of DSM-9. Every line in a log file contains three fields, each separated by the three-at-symbol delimiter: a card name, the timestamp at which the card was tested, and the grade given at the time of testing. On startup, every line is processed, each line is mapped to a card via the name, and the card's due date is updated. When a new value is logged, it is written to the file, and the internal values are updated.


Note: while binaries are installed into /$objtype/bin/dsm9 on plan9, resulting in invocations like dsm9/due, they're installed to /usr/bin on Linux systems with a dsm9 prefix instead. Thus, where the manual says dsm9/due, the Linux equivalent is dsm9due.

dsm9/due [-c count] [-o offset] deck

dsm9/due prints out the list of due cards. By default, it prints out the first 30 due cards. This can be overridden by setting the count via -c. Setting the offset with -o skips to after the specified offset. For instance, if there are 45 due cards, and the invocation is dsm9/due -c 10 -o 30, 10 due cards starting at the 31st due card will be printed out.

dsm9/log [-s] [-c max] deck

dsm9/log is a useful logging tool for when cards are tested in the order in which they are due, with no divergence. It prompts for grades for cards in the due order, and produces the appropriate log entries.

The -s option enables "sequential mode," in which cards are tested according to their order in the deck, instead of the due date. This is especially useful when you plan on testing a full deck anyways.

By default, 12 cards are prompted for. This limit can be changed by overriding the maximum with -c.

dsm9/log prints the name of the card being tested, then prompts for user input. Either a grade in [0, 5] should be entered, or the letter 'q' to quit.

dsm9/cli [-c max] [-a] [--renderer renderer] deck

dsm9/cli is a pleasant interactive tool for using decks in a purely digital fashion. It tracks what cards are due, renders the front of the card, then the back, and prompts for a grade as with dsm9/log. It keeps going until no cards are due or the user-specified limit (default: 30) is hit. With -a, the entire deck will be tested in linear order. The --renderer flag can be used to select the renderer which will be used to display the cards.

On Plan 9, the default is to assume cards are written in roff, render them to PostScript, and send them to the plumber. With default plumbing rules, this reuses an instance of page (or spawns one if none is open) for rendering.

On Linux, cards are assumed to be in HTML, and are rendered into text via w3m. The text is then displaying using the less pager. Plain text will, of course, work just as well.

The text renderer is platform-independent, and will cause cards to be rendered by simply dumping them to standard output. This is especially suitable for plain text, but can also work well for Markdown and other light markup formats. The html renderer is the default w3m renderer on Linux, and is a plumber-based renderer on plan9. It has been tested to work well with both mothra and netsurf.


Copyright 2020-2021 Noam Preil

This implementation is currently licensed under the GPLv3