| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
shipped .aar
The comment omitted -javapkg, the second -target ABI and -androidapi. A
clean clone following it got a .aar whose classes sit under
go.mobile.gojni instead of xyz.labunix.dlectio.engine.mobile, carries only
arm64-v8a, and declares no minSdkVersion match to the app's 26 -- the app
cannot import the result. Verified by rebuilding the binding with the
corrected command and confirming the artifact's ABIs, package and
minSdkVersion against the shipped one.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
| |
A week through Days benchmarks at ~9-10ms/op, versus ~23ms for seven
full days through Day.
|
| | |
|
|
|
mobile/mobile.go and its go.mod/go.sum additions were sitting untracked in
the working tree. Recorded here unchanged so the work that follows has a
diff baseline; no lines of it are modified by this commit.
Also ignore the cmd/dlectio-gen build product and the SDD scratch dir.
|
