Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#988 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
kotlin, python
Domain
testing-qa, tooling

Research direction

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.

Written by the indexing model from the issue text.

Description

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.

Dominant language
Kotlin
Stars
52
Forks
15
Avg merge
1d 15h
Merged PRs (30d)
36

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from SKaiNET-developers/SKaiNET

All issues in SKaiNET-developers/SKaiNET

Similar issues

More Kotlin issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.