blagae / elisio Goto Github PK

Make sure unit tests cover every possible successful outcome in all subtypes of the hendecasyllabus parser, and a representative sample of failing scenarios. We also need to test the HendecaCreator.

Letter adds virtually nothing and is a simple data type, which can be easily replaced by a small collection of some sorts containing the information we want.

The senarius is an iambic verse form mostly used in dramatic poetry, and is known for its high flexibility, which presumably makes it hard to put into an algorithm.

The Elisio engine should be able to handle the senarius in a correct and testable way.

Replace the current front-end API calls with GraphQL calls in order to reduce the number of round-trips that are necessary to populate the fields for individual verses and (in the future) the query tool.

Design and write a tool that can be used to run specific analyses on subsets of the verse corpus.
Users must be able to:

• define which analysis they want from a predefined list (which may contain user-defined content) e.g. the use of faciebat in hexameter clausulae.
• specify a specific subset to run the analysis on, which may be a composite of several items e.g. all works of Vergilius + the Metamorphoses.

This task comprises at the very least:

• a front-end GUI design & implementation for the query assembler
• the back-end script that can execute the analysis and return results
• a rate limiter that puts reasonable constraints on the amount of CPU time a user can hog.

Nice-to-haves are:

• an option to schedule analysis
• an option to abort an analysis
• an option to reuse past analyses as much as possible
• an option to simulate analysis, in order to estimate cost

Make sure unit tests cover every possible successful branching statement in the Hexameter parser step. We also need a representative sample of failing scenarios where there is not enough information or conflicting situations e.g. a verse starting with HEAVY-LIGHT-HEAVY syllables.

For successful tests, the current situation is only problematic for BalancedHexameter. For failing tests, coverage can be improved on all subtypes.

This improvement may reveal dead branches (impossible scenarios) in BalancedHexameter. These should be weeded out.

Coverage analysis has shown that there are a few code paths in BalancedHexameter which will never be executed, because their preconditions are already caught by other code. Determine whether to remove these.

Use https://github.com/blagae/open_words to get the root of words being used, so that we can have better metrical data for declinable words and fewer verses with not enough information.

In practice, this means refactoring the WordOccurrence to either leverage open_words or be replaced by it. Also make sure to feed back that metrical data into open_words (or its handling code/db mechanism).

Try to work with the current setup to create a basic parallel implementation that can scan some sample Greek verses. The outcome should be a set of pointers and suggestions for refactorings that can make implementing a full Greek hexameter scanner easier.

The effort on this ticket is allowed to contain "bad" code because it does not have to be usable as-is, but of course it is better if it's easily mergeable.