admin-mrrm/mrrmlabapp
1
0
Fork 0
Code Issues 20 Pull requests 3 Projects Releases 43 Packages 5 Wiki Activity Actions
43 releases 51 tags
  • v0.6.6-rc15 2b269a7d1f

    v0.6.6-rc15
    All checks were successful
    continuous-integration/drone/push Build is passing
    Details
    continuous-integration/drone/tag Build is passing
    Details
    Stable

    admin-mrrm released this 2026-06-07 18:11:32 +02:00 | 145 commits to main since this release

    rc14 zeigte: ONNX-Download hängt bei 0 Bytes auf cas-bridge.xethub.hf.co ohne User-Agent (Tokenizer-Downloads mit UA gehen durch). Fix: gleicher UA-String für ONNX-Request + Sanity-Check nach Download (size < 1 MB → delete + throw mit URL).

    Highlights

    • User-Agent-Header für ONNX-Download (war nur auf Tokenizer)
    • Post-Download-Größencheck: <1 MB → löschen + actionable error
    • spec-Tests sperren beide Verhalten gegen Regression
    Downloads
  • v0.6.6-rc14 f62f945d16

    v0.6.6-rc14
    All checks were successful
    continuous-integration/drone/push Build is passing
    Details
    continuous-integration/drone/tag Build is passing
    Details
    Stable

    admin-mrrm released this 2026-06-07 17:35:08 +02:00 | 147 commits to main since this release

    Wechsel auf transformers.js-Mirror Xenova/multilingual-e5-small — hostet onnx/model_quantized.onnx (118 MB) im transformers.js-Convention-Pfad. intfloat-Original-Repo hat diese Datei nicht (nur model.onnx 470 MB + AVX512-spezifische Variante). Cache-Verzeichnis auf embedding-e5-small-xenova umbenannt, um die korrupte 15-Byte-Datei aus rc13 zu invalidieren.

    Highlights

    • MODEL_REPO: intfloat → Xenova
    • cache-dir bumped → invalidiert kaputten rc13-Download
    • spec-Test sperrt URL gegen erneute Drift auf intfloat
    Downloads
  • v0.6.6-rc13 336632c269

    v0.6.6-rc13
    All checks were successful
    continuous-integration/drone/push Build is passing
    Details
    continuous-integration/drone/tag Build is passing
    Details
    Stable

    admin-mrrm released this 2026-06-07 15:57:57 +02:00 | 149 commits to main since this release

    rc12-Gerätetest ist DER entscheidende Befund: die Debug-Bar zeigt 'embedder: loading tokenizer · [awaiting from_pretrained]' und kein einziges 'fetch#N ' folgt — AutoTokenizer.from_pretrained hängt SYNCHRON bevor der erste fetch-Call überhaupt rausgeht. Patchen am fetch-Layer hilft prinzipiell nicht; der Hang liegt vor der HTTP-Schicht (vermutlich in transformers' get_file_metadata / Cache-Lookup auf Hermes). Quellanalyse zeigt: from_pretrained ist nur ein Convenience-Wrapper, der die zwei JSONs lädt und sie an new PreTrainedTokenizer(tokenizerJSON, tokenizerConfig) weiterreicht. Die Dateien haben wir bereits seit rc8 lokal — rc13 überspringt from_pretrained komplett und ruft den Konstruktor direkt. Der ganze fetch-Interceptor wird obsolet und entfällt.

    Highlights

    • feat(embedding): PreTrainedTokenizer wird direkt mit den geparsten JSONs auf Disk konstruiert (#122) — AutoTokenizer.from_pretrained wird nie mehr aufgerufen. Bypass des Hangs auf Hermes.
    • remove(embedding): hf-fetch-interceptor-Modul + Spec entfernt — kein Code-Path mehr, der huggingface.co anspricht (Tokenizer-Konstruktor ist synchron, ONNX-Session lädt nur lokale Datei). Cleanup von ~150 LOC.
    • ensureModelFilesDownloaded() gibt jetzt {modelPath, tokenizerJsonPath, tokenizerConfigPath} zurück; initialize() liest beide JSONs und konstruiert den Tokenizer in einem Schritt.
    • Tests umgebaut: '@huggingface/transformers'-Mock liefert jetzt PreTrainedTokenizer als Konstruktor-Mock; AutoTokenizer-Spielereien fliegen raus.
    Downloads
  • v0.6.6-rc12 0709229a17

    v0.6.6-rc12
    All checks were successful
    continuous-integration/drone/push Build is passing
    Details
    continuous-integration/drone/tag Build is passing
    Details
    Stable

    admin-mrrm released this 2026-06-07 15:22:57 +02:00 | 151 commits to main since this release

    rc11-Tag-Build failte im lint-Step: 'clearHfLocalPaths' war in embedding-service.ts importiert aber nur im Test verwendet. rc12 entfernt den unused Import — identischer Code-Path wie rc11, einziger Unterschied ist die saubere Import-Liste.

    Highlights

    • fix(embedding): unused 'clearHfLocalPaths'-Import in embedding-service.ts entfernt — wird ausschließlich im Spec verwendet. Sonst keine Code-Änderung gegenüber rc11.
    Downloads
  • v0.6.6-rc10 8ddc339ceb

    v0.6.6-rc10
    Some checks failed
    continuous-integration/drone/push Build is failing
    Details
    continuous-integration/drone/tag Build is passing
    Details
    Stable

    admin-mrrm released this 2026-06-07 14:46:24 +02:00 | 154 commits to main since this release

    rc9 lieferte die Tokenizer-Files erfolgreich auf Disk (User-Agent-Header genügte offenbar dem HF-CDN), aber AutoTokenizer.from_pretrained hängt wieder genau wie in rc6 — diesmal mit installiertem Fetch-Interceptor. Wahrscheinlichste Erklärung: transformers.js holt vor den /resolve/main/-Dateien noch andere HF-URLs (z.B. /api/models//tree/main für Revision-Lookup), die NICHT auf HF_BASE matchen → Interceptor lässt durch → Original-Fetch hängt erneut auf Hermes. rc10 erweitert den Interceptor auf ALLE huggingface.co-URLs (unbekannte → synthetisches 404) und emittiert pro Fetch-Aufruf einen Status mit URL-Pfad. Das macht sichtbar welche URLs transformers.js anfragt und ob der Interceptor überhaupt getriggert wird.

    Highlights

    • feat(embedding): Interceptor fängt jetzt jede huggingface.co-URL (#122). Bekannte /resolve/main/ → Disk-Read; alles andere → 404. Verhindert dass nicht-erfasste HF-API-Calls den nativen fetch hängen lassen.
    • feat(embedding): Pro Fetch-Aufruf wird 'loading-tokenizer' mit filename='fetch#N ' re-emittiert. Debug-Bar zeigt jetzt 'embedder: loading tokenizer · fetch#3 api/models/intfloat/multilingual-e5-small/tree/main' — der Hang ist einer konkreten URL zuzuordnen.
    • Tests bleiben grün (18/18); Interceptor-Verhalten für non-HF-URLs (passthrough) unverändert.
    Downloads
  • v0.6.6-rc9 5060112365

    v0.6.6-rc9
    All checks were successful
    continuous-integration/drone/push Build is passing
    Details
    continuous-integration/drone/tag Build is passing
    Details
    Stable

    admin-mrrm released this 2026-06-07 14:17:33 +02:00 | 156 commits to main since this release

    rc8 zeigte auf dem Gerät 'embedder: downloading tokenizer files' und hängt da — also auch der native expo-Downloader klemmt für die kleinen JSON-Files, obwohl er die 120 MB ONNX-Datei einwandfrei geladen hat. Bevor wir die Lösung wählen (Bundling als Asset vs. eigener Mirror vs. andere CDN) brauchen wir einen klaren Diagnosesignal: welche Datei genau hängt und ob überhaupt Bytes fließen. rc9 emittiert pro-Datei Progress mit Dateinamen + Bytes und timeoutet jede Datei nach 45s — wir sehen jetzt 'downloading tokenizer tokenizer.json 0.0 / 17.4 MB' bzw. 'error: tokenizer-download timeout (45s): tokenizer.json'.

    Highlights

    • feat(embedding): pro-Datei 'downloading-tokenizer' Status mit filename + bytesWritten/bytesTotal (#122). Debug-Bar rendert 'embedder: downloading tokenizer X.X / Y.Y MB' — Hang ist jetzt einer konkreten Datei zuzuordnen.
    • feat(embedding): Per-File-Timeout (45s) via Promise.race um downloadAsync — kein indefinites Hängen mehr, klare Error-Message mit Dateiname.
    • feat(embedding): User-Agent-Header 'mrrmlab/0.6.6 expo-file-system' im Download-Request — Falsifiziert die Hypothese 'HF blockt anonyme Requests'.
    • EmbeddingProgress um optionales 'filename'-Feld erweitert; bestehende Tests bleiben grün.
    Downloads
  • v0.6.6-rc8 1600bcca8f

    v0.6.6-rc8
    All checks were successful
    continuous-integration/drone/push Build is passing
    Details
    continuous-integration/drone/tag Build is passing
    Details
    Stable

    admin-mrrm released this 2026-06-07 13:51:53 +02:00 | 158 commits to main since this release

    rc7 lieferte den entscheidenden Hinweis (via dem neuen Maestro-Flow): der Probe-fetch zu huggingface.co hängt selbst — Hermes' JS-fetch klemmt komplett gegen HF. Dieselbe Domain funktioniert hingegen über expo-file-system's nativen Downloader (createDownloadResumable hat den 120 MB ONNX-File bereits einwandfrei geladen). rc8 zieht die Konsequenz: alle vier Tokenizer-Dateien (tokenizer.json, tokenizer_config.json, special_tokens_map.json, config.json) werden jetzt ebenfalls per nativem Downloader auf Disk geholt, und ein fetch-Interceptor leitet alle HF-URLs in transformers.js auf lokale Disk-Reads um. Der JS-fetch sieht huggingface.co nie wieder.

    Highlights

    • feat(embedding): ensureModelFilesDownloaded lädt 4 Tokenizer-JSONs zusätzlich zum ONNX-Model via createDownloadResumable (#122). Neue Sub-Status 'downloading-tokenizer' wird in der Debug-Bar als 'embedder: downloading tokenizer files' angezeigt.
    • feat(embedding): globalThis.fetch-Monkey-Patch in initialize() — alle Requests an huggingface.co/intfloat/multilingual-e5-small/* werden über FileSystem.readAsStringAsync aus dem lokalen Cache bedient. AutoTokenizer.from_pretrained ruft transparent gegen Disk, kein Network-Hang mehr möglich. Non-HF-URLs gehen unverändert durch.
    • Test-getrieben: rc7-Probe-Tests entfernt (Mechanismus aufgegeben), 5 neue Tests (Tokenizer-Download-Liste, downloading-tokenizer-Status, Interceptor-Disk-Read, Query-String-Stripping, Passthrough für Non-HF).
    Downloads
  • v0.6.6-rc7 761034195b

    v0.6.6-rc7
    All checks were successful
    continuous-integration/drone/push Build is passing
    Details
    continuous-integration/drone/tag Build is passing
    Details
    Stable

    admin-mrrm released this 2026-06-07 12:41:04 +02:00 | 160 commits to main since this release

    rc6 (via dem neuen Maestro-Flow phase1-indexing-smoke) hat eindeutig gezeigt: der Embedder hängt bei 'loading tokenizer' — also genau inside AutoTokenizer.from_pretrained() von transformers.js. ONNX-Download + Datei-auf-Disk sind ok, InferenceSession.create wird nie erreicht. Da der Hang innerhalb der HF-Lib silent ist (kein Error, kein Progress) braucht es einen direkten Probe-Schritt davor: rc7 fetched tokenizer_config.json selbst per fetch() und emittiert das als eigene Sub-Status 'loading-tokenizer-probe'. Probe-Erfolg bedeutet: Netzwerk + HF-Endpoint sind ok, der Hang liegt in transformers.js Internals. Probe-Fehler liefert sofort HTTP-Status statt unendlich zu hängen.

    Highlights

    • feat(embedding): neue Sub-Status 'loading-tokenizer-probe' vor AutoTokenizer.from_pretrained (#122). Direkter fetch() auf https://huggingface.co/intfloat/multilingual-e5-small/resolve/main/tokenizer_config.json — Erfolg → next status 'loading-tokenizer'; Fehler → throw mit HTTP-Status statt Lib-Hang.
    • Debug-Bar rendert jetzt 'embedder: probing tokenizer endpoint' bzw. 'embedder: loading tokenizer' — auf dem Phone unterscheidet sich Netz-Hang von transformers.js-Hang.
    • Test-getrieben: 3 neue embedding-service.spec Tests (probe-call vor from_pretrained, probe-Status-Emit-Order, Probe-Fehler-Pfad mit HTTP-Status im error-Event).
    Downloads
  • v0.6.6-rc6 7cd934d914

    v0.6.6-rc6
    All checks were successful
    continuous-integration/drone/push Build is passing
    Details
    continuous-integration/drone/tag Build is passing
    Details
    Stable

    admin-mrrm released this 2026-06-07 11:54:22 +02:00 | 162 commits to main since this release

    rc5 zeigte am Phone 'embedder: loading' und blieb dort hängen. 'loading' fasste bisher zwei sequenzielle Schritte zusammen: AutoTokenizer.from_pretrained (HF-Tokenizer-Download via transformers.js) und InferenceSession.create (ONNX-Parse). rc6 splittet das in 'loading-tokenizer' / 'loading-session' damit der Bottleneck auf dem Gerät sichtbar wird. Parallel: erster echter Maestro-E2E-Flow (phase1-indexing-smoke), den scripts/maestro-pi.sh auf dem rpi5+Phone fährt — er drückt den Debug-Button und wartet bis 'embedder: ready' erscheint (timeout 3min). Damit kann jeder zukünftige RC autonom verifiziert werden.

    Highlights

    • feat(embedding): EmbeddingStatus split 'loading' → 'loading-tokenizer' + 'loading-session' (#122). Debug-Bar rendert jetzt 'embedder: loading tokenizer' bzw. 'loading session' — entlarvt welcher der zwei Schritte auf dem Gerät hängt (Tokenizer-Fetch von HF vs. ONNX-Compile).
    • feat(e2e): phase1-indexing-smoke.yaml — neuer Maestro-Flow der den Debug-Index-Button drückt und auf 'embedder: ready' wartet. Läuft via scripts/maestro-pi.sh, kein clearState (cached ONNX bleibt auf disk → 30s statt 3min auf Re-Runs). Erlaubt autonome Fix-Verifikation ohne menschliche Lesung.
    • Test-getrieben: 1 neuer embedding-service.spec Test prüft loading-tokenizer → loading-session → ready Reihenfolge.
    Downloads
  • v0.6.6-rc5 b6cc6f7d88

    v0.6.6-rc5
    All checks were successful
    continuous-integration/drone/push Build is passing
    Details
    continuous-integration/drone/tag Build is passing
    Details
    Stable

    admin-mrrm released this 2026-06-07 08:07:34 +02:00 | 164 commits to main since this release

    Folge-RC zu rc4: rc4 zeigte am Phone 'embedder: idle' nach Druck auf den Debug-Button. Da idle → downloading nur durch tatsächlichen embed()-Call ausgelöst wird, ist der wahrscheinliche Grund: extractChunks gibt [] zurück (z.B. Shopping-List ohne Items vom Typ 'shopping' oder Notiz mit leerem Body), die for-Loop in IndexingService.indexSource läuft nicht, embed() wird nie aufgerufen. rc5 macht das sichtbar und ergänzt parallel die Embedder-Bytes-Anzeige für den Fall dass der Download tatsächlich klemmt.

    Highlights

    • feat(search): IndexingService emittiert 'chunks-extracted' nach jedem extractChunks-Call (#122) — auch wenn count=0. Debug-Bar zeigt 'X Quellen → Y Chunks extrahiert', damit man 0/0 (Daten leer/falscher Typ) von 'läuft noch' unterscheidet.
    • feat(search): EmbeddingProgress liefert bytesWritten + bytesTotal zusätzlich zum % (#122). Debug-Bar rendert 'downloading 23.4 / 120.0 MB' — '0.0 / 0.0 MB' (kein Content-Length) lässt sich von '0.0 / 120.0 MB' (Request akzeptiert, kein Byte) und '12.0 / 120.0 MB' (langsam) unterscheiden.
    • Test-getrieben: 1 neuer Test in indexing-service.spec für chunks-extracted (0 vs. >0), 1 neuer Test in embedding-service.spec für die Byte-Felder.
    Downloads