aboutsummaryrefslogtreecommitdiff
path: root/internal/readings/offline.go
Commit message (Collapse)AuthorAgeFilesLines
* perf(readings): stack calendar layers and load the book table once per Days callLukasz Kasprzak2026-08-241-6/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mobile.Days (dlectio's 7-day calendar view) called readings.Load once per date. Load's offlineLoad re-ran caldata.Stack (parses the embedded calendar INI, plus any user calendar layer) and bible.LoadBookTable (parses the embedded books.ini, plus any user override) on every call, even though neither depends on the date -- only on cfg.Selection().Form and cfg.Use, which mobile.Days holds fixed across its whole loop. Verified before changing anything: isolated benchmarks put Stack+ LoadBookTable at ~1.1ms/call (OF) and ~1.6ms/call (EF) -- real INI parsing and, for a user override, file I/O -- and for the OF form that redundant work was ~67% of a 7-day view's total time. Load gains a Prepared value (the layer stack + book table) and a Prepare/LoadWith pair: Prepare builds a Prepared once, LoadWith reuses it across dates. Load itself is unchanged, still calling Prepare on every invocation -- every existing caller keeps its current behaviour untouched. mobile.Days now Prepares once and loops LoadWith; mobile.Day picks up the same fix for its own two same-cfg Load calls. Benchmarked (interleaved before/after pairs, to control for machine thermal drift): the OF 7-day view (BenchmarkDaysWeek) drops from ~11.5ms to ~6.4ms/op (allocs 53359 -> 16347, -69%), an EF 7-day view (BenchmarkDays7EF) from ~74ms to ~66-73ms/op (allocs 299204 -> 253815, -15%; the EF form's per-day calendar computation dominates its total cost far more than OF's does, so the fix's share of the win is smaller there), and a single Day call (BenchmarkDay1) from ~4.3ms to ~2.9ms/op (allocs 15357 -> 9192, -40%). Output identity verified separately (not part of this diff): a 288-case sweep of mobile.Day/mobile.Days across both forms, both UI languages, all four corpora, a leap day, the Sacred Triduum, a Requiem day, and windows spanning Christmas/Pentecost/Assumption/All Souls produced byte-identical (SHA-256-equal) JSON before and after this change. New TestLoadWithAgreesWithLoad asserts LoadWith(Prepare(cfg), cfg, opts) equals Load(cfg, opts) for every case, so the fast path cannot silently drift from the slow one. go test ./... and make ci (both build tags, oracle/differential suite included) are green.
* calendar/readings: report Sunday as its own display rank, not solemnityLukasz Kasprzak2026-08-051-1/+47
| | | | | | | | | | | | | | | | The Ordinary Form's Table of Liturgical Days treats Sunday as its own category, never a solemnity. temporal.go's sundayDay() already marks these days distinctly from named solemnities (Class stays unset, unlike solemn()'s ClassLord); internal/readings/offline.go now reads that existing signal to relabel the REPORTED rank to "sunday" for ordinary and privileged-season Sundays alike, leaving Celebration.Rank, ofRankOrder and all precedence untouched. Named solemnities landing on a Sunday (Easter, Pentecost, ...) and feasts of the Lord (Holy Family) keep reporting their own rank. The 1962 form is untouched. Added calendar.RankSunday (display-only, deliberately excluded from ofRankOrder), the i18n Sunday/niedziela words, and a test pinning the exact dates from the original bug report.
* readings: PartIDs(new) stops declaring aklamacja, which the engine never emitsLukasz Kasprzak2026-08-051-1/+13
| | | | | | | | | | | | | | | | | | | | | caldata.go:42 parses only first/psalm/second/gospel out of the lectionary data, so no OF reading ever carries Part == "acclamation". PartIDs("new") listed aklamacja anyway, so the app built a checkbox from it that filters an ID that never appears -- a dead control, same defect class the app previously shipped for the whole 1962 form. ofPartOrder stays the full five-ID set: it also drives render.LocalizeHeading's label matching, where a scraped heading can still read "Aklamacja" even though this engine's own readings never produce that section. PartIDs now draws from a new, narrower ofEmittedPartOrder instead. Rewrote TestPartLabelsMatchesWhatTheEngineEmits's OF half: it compared PartLabels("of") to a hand-copied duplicate of ofPartOrder, asserting a declaration against itself, which cannot fail for this class of bug. It now sweeps Days over calendar year 2026 and asserts PartLabels("of") matches the observed part-ID set exactly (0.5s). Confirmed red against the pre-fix code, green after.
* i18n: pin the Polish part labels; cross-reference the part-ID ordersLukasz Kasprzak2026-08-041-0/+9
|
* readings: 1962 part labels become i18n data; export PartIDsLukasz Kasprzak2026-08-031-13/+37
|
* i18n: correct rank doc comments and pin the Polish wordingLukasz Kasprzak2026-08-031-3/+4
|
* liturgy: carry the observed rank on DayInfoLukasz Kasprzak2026-08-031-0/+1
|
* naming: localise liturgical day names in any languageLukasz Kasprzak2026-07-281-17/+4
| | | | | | | | | | | | | | | | | | | | | | | | Add internal/naming, which renders temporal day names and celebration display names from the calendar engine's slugs in any language. English is the built-in baseline; a language is data -- an embedded lang/<code>.ini (pl shipped) and/or a user file at <config dir>/names/<code>.ini that overrides it key by key. Names compose from a small vocabulary plus per-language format templates, so word order and grammatical case can differ (e.g. Polish genitive "3. Niedziela Okresu Zwykłego"); any string a language omits falls back to English. - Move day-name generation out of calendar (calendar.HumanizeSlug removed, calendar stays a pure engine) into naming.DayName; the English golden cases carry over verbatim. - naming.CelebrationName unifies the three duplicated resolvers (cli/readings/calfeed): name.<lang> -> English -> Latin -> humanized slug. Saint names stay in the calendar data (name.<lang>), overridable via calendar layers. - config: ui_language now accepts any code (lower-cased, not clamped to en/pl) so names/<code>.ini applies; UI chrome still resolves en/pl and falls back to English. Add NamesDir(); wire naming.SetUserDir (and the previously unwired bible.SetUserCorporaDir) in the TUI and web mains too, so external corpora and name files work across all three binaries.
* feat(readings): compute the daily view offline (OF + EF)Lukasz Kasprzak2026-07-281-0/+140
Route readings.Load through the embedded calendar engine and lectionary data instead of the niedziela/missalemeum scrapers. The daily view now computes each day (calendar.Compute + caldata.Readings) and renders text from the public-domain corpora, with citations resolved per corpus. - bible.OFRef: normalise an English-canonical OF citation (drop sub-verse letters, ";" -> ",") and renumber Psalms for the target Psalter (Hebrew->Vulgate chapter for vul/grb/wuj; DRB title-fold verses for drb). - liturgy.Section gains Ref (English-canonical lookup ref) alongside Citation (sigla-dialect display); the loader fills both, resolveRef uses Ref, headings/citation command show Citation. - EffectiveVersions always drops "bt" (no offline corpus); the single daily version defaults to vernacularVersion (reading corpus else Latin). Scraper packages remain in the tree, unreferenced, pending removal.