Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Ground truth: explore a single-source DSL generating both Kotlin and Python fixtures

Aperta
  • Qualcosa non va?
#988 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
kotlin, python
Ambito
testing-qa, tooling

Direzione di ricerca

Start by reading OperationExecutor's executeOperation mapping and the existing generateKernelMatrix and ops-status-matrix codegen, then compare the signatures for add, relu, and conv2d. Scope a proof of concept that defines those cases once and generates both fixture and dispatch entries; done means deciding whether the reduced duplication justifies expanding the design, or closing the issue as not worth the complexity.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

dsl/api research sub-issue

Sub-issue of #984 — stretch/exploratory, not scoped work yet.

The idea

Define each ground-truth test case (op name, input shapes/dtypes, params) once in a
single declarative spec, then generate both the Python @Executable fixture (for
skainet-ground-truth) and the Kotlin op-dispatch entry (OperationExecutor's
executeOperation when branch) from it — instead of maintaining the mapping between
PyTorch's op API and SKaiNET's TensorOps API by hand in two places that can silently
drift (see #985: today only 4 of ~25 dispatched ops have any Python fixture at all,
and #986: the mapping isn't validated to actually agree on parameter names).

SKaiNET already has real precedent for registry-introspection-driven codegen elsewhere
in the repo (generateKernelMatrix, the ops-status-matrix pipeline) — this would be the
same idea applied across the Kotlin/Python boundary instead of within Kotlin.

What's actually hard here

Not the codegen mechanism (KSP, or a plain script reading a shared spec — either can
emit Python text files, KSP doesn't care what language it's writing). The hard part is
formalizing the semantic mapping between PyTorch's op signatures and SKaiNET's
TensorOps signatures (different parameter names/orderings/defaults per op) into a
schema — that mapping currently only exists as hand-written Kotlin in
OperationExecutor. The payoff of doing this is real (one definition, impossible for
the two sides to drift, closes #985's coverage gap structurally rather than
suite-by-suite) but it's a genuine design project, not a quick win.

Task

Scope a small proof-of-concept for 2-3 ops (e.g. add, relu, conv2d — one trivial,
one unary, one with real params) before committing to anything broader. If it doesn't
clearly pay for itself at that scale, close this as "not worth the complexity" rather
than half-build it.

Lingua principale
Kotlin
Stelle
52
Fork
15
Merge medio
1g 8h
PR unite (30g)
37

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di SKaiNET-developers/SKaiNET

Tutte le issue di SKaiNET-developers/SKaiNET

Issue simili

Altre issue su Kotlin

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.