Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Goal] Fix missing-value parity in real Wasm rolling kernels

Abierto
#496 5 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
rust, typescript, wasm
Área
data, testing-qa

Línea de trabajo

Start by reproducing rollingMedianF64Accelerated before and after loadWasm(), then inspect the relevant Rust rolling kernels and tests under rust/ and tests/wasm/. Build with wasm-pack from rust/ and run the focused accelerated-wrapper tests plus the listed cargo, typecheck, and lint commands. Done means loaded Wasm matches fallback semantics, regression coverage passes, and candidate-head evidence is recorded.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

goal-completed

Goal

Make all-missing rolling-window results agree between the existing TypeScript fallback and the real Rust/Wasm acceleration path, without a Wasm trap. This is a focused follow-up to #349, not a claim that the whole pandas or Wasm port is complete.

Completion Contract

  • Reproduce rollingMedianF64Accelerated(new Float64Array([NaN, 1, NaN, 3]), 1, 0) before and after loadWasm(). The loaded implementation must return [null, 1, null, 3], not throw RuntimeError: unreachable.
  • Check rolling min/max for empty/all-missing windows at minPeriods = 0, preserving current TypeScript fallback semantics including infinities. Cover positive minPeriods, mixed finite/NaN input, empty input, and representative window sizes so the fix does not only special-case the reproduction.
  • Add Rust regression tests and TypeScript integration tests that execute the actual accelerated wrappers with the Wasm module successfully loaded. Test the fallback in an isolated process before loading, so previous tests cannot secretly choose the backend. A missing module or early return is a failure, not passing evidence.
  • Build Wasm from the candidate's Rust source; do not validate only the old checked-in binary. Keep the required generated bindings/binary consistent with source if this repository tracks them.
  • Confirm candidate-head CI and the focused source-built Wasm verification pass, then reconcile published evidence in a subsequent run. Do not close the issue on a queued push, stale branch, syntax-only test, or fallback-only result.

Evidence / Verification

Record the candidate SHA and actual commands, outcomes, and assertion counts. Run cargo test --locked --manifest-path rust/Cargo.toml, wasm-pack build --target nodejs rust/ --out-dir pkg, the relevant bun test tests/wasm/ tests, affected core/window tests, bun run typecheck, and bun run lint. Report missing tooling or failing checks honestly. Link the published PR and current-head runs. A standalone Wasm Verification workflow is being installed; use it when available and do not claim its result until it completes.

Scope and Constraints

Only change the relevant Rust rolling kernels, focused tests under tests/wasm/ and Rust tests, and corresponding generated rust/pkg/ artifacts when necessary. Do not modify README, AGENTS, .autoloop/programs/, workflow policies, benchmarks, general Series/DataFrame behavior, or issue #1. Preserve existing fallback semantics; do not weaken assertions or mark cases ineligible to get a green result. One small coherent fix per commit.

Iteration Policy

First reproduce the crash and semantic mismatch, add a focused regression, fix the smallest coherent defect, and publish one canonical PR. A later run checks the real published candidate and CI evidence before accepting or completing it. If verification exposes another in-scope defect, fix it in a separate small checkpoint. Do not repeat an unchanged diagnosis or create duplicate PRs.

Blocked Stop Condition

Stop and report one actionable blocker if required tooling cannot run, the permitted scope cannot repair the behavior, branch publication fails, or evidence contradicts the claimed result. Leave the issue open and record the next required action. Never infer successful verification from unavailable results.

Lenguaje dominante
TypeScript
Estrellas
9
Forks
4
Merge medio
3 d 3 h
PR fusionados (30 d)
15

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de githubnext/tsb

Todos los issues de githubnext/tsb

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.