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

DOOM study write-up: lineage survival vs linuxdoom across all ports + cross-language subsystem comparison (engine metric calibration)

Aperta
  • Qualcosa non va?
#5,620 3 commenti 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
24/100
Tipo di issue
Documentazione
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
c, cpp, csharp, go, java, python, rust, sql
Ambito
data-engineering, documentation, tooling

Direzione di ricerca

Start with tests/tools/doom_speedrun/manifest.csv, the existing round-1 survival.py and canonical.py, and the harness scan outputs. Port the scripts into the suggested tests/tools/doom_speedrun/lineage.py or tests/doom_crucible/ location, then define the documented lineage and cross-language metrics. Done means one pinned-corpus command regenerates every requested table, docs/research/doom-port-study.md reports only reproducible measurements, and each calibration finding is filed with evidence.

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

Descrizione

claim:nyx enhancement metrics needs:doom-corpus priority: medium scope:frontier

Goal

Produce the analysis the DOOM study was for: how much of id Software's 1997 linuxdoom survives in each port, how ports diverge, and how the same subsystems look across languages. It doubles as an engine check: are GitGalaxy's metrics comparable across languages? (If a Go or COBOL renderer scores wildly differently from the C original for the same algorithm, that is an engine calibration finding.)

Inputs

  • Corpus: tests/tools/doom_speedrun/manifest.csv (39 ports; moving to tests/doom_crucible/ with #5619) plus the ports added by the manifest-expansion issue (COBOL, Python, SQL, web...).
  • Round-1 method (16 ports, C-family only, engine a8510fc07), local on nyx at /srv/storage_16tb/projects/gitgalaxy/doom-study/scripts/survival.py + canonical.py: function bodies sliced by engine boundaries, normalised, sha1 + difflib similarity vs linuxdoom's 659 functions, per subsystem (renderer, playsim, menus, netcode, ...). Example result: chocolate-doom keeps 86.6% of linuxdoom function names, 35.1% exact bodies; doomretro 68.9% names, 0.2% exact.

Work

  1. Port the round-1 scripts into the repo as our own tool (tests/tools/doom_speedrun/lineage.py or under tests/doom_crucible/), reading the harness scans; rerun on all ports at current main.
  2. Lineage table: per port, survival of linuxdoom names / exact bodies / near (>=0.9) / derived (>=0.6), per subsystem; checked against each port's stated lineage in the manifest (does Chocolate -> Crispy -> inter-doom show monotone drift? do rewrites show ~0 exact bodies but high name survival?).
  3. Cross-language: map subsystems by file/function-name families (r_* renderer, p_* playsim, m_* menu...), then compare per subsystem across C / C++ / C# / Java / Go / Rust / COBOL / Python: function count, LOC, cyclomatic complexity, call fan-out. Report where the engine's metrics are comparable and where they are not, with the language-specific reason; file an engine issue for each calibration defect found.
  4. Write-up: docs/research/doom-port-study.md, measurements only (third-party policy: no code, no reconstructions, brief quotes with attribution), every number reproducible by one command; per-port clean-scan table before/after the fixes (round 2 585c243e9 -> current).

Acceptance

  • One command regenerates every table from the pinned corpus.
  • Lineage for all C-family ports + name-level lineage for the rewrites; cross-language subsystem table including at least C, C++, C#, Java, Go, Rust, and COBOL/Python once added.
  • Calibration findings filed as issues (or "none found", with the evidence).

Part of #5457.

🤖 Generated with Claude Code

Lingua principale
Python
Stelle
57
Fork
11
Merge medio
1h 41m
PR unite (30g)
978

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 squid-protocol/gitgalaxy

Tutte le issue di squid-protocol/gitgalaxy

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.