Translation fidelity along the traceability map: compare each COBOL paragraph with the Java method it became

未关闭
  • 哪里不对？
#7,532 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
22/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
java, python
领域
tooling

调研方向

Start from traceability.json produced by the forge/det-port, which maps each generated Java method to its COBOL source line and fact, and from the existing structural fingerprint tooling (sfs) the issue contrasts against. The new tool goes under tests/tools/; first check how traceability entries link paragraphs to methods. Done means a per-paragraph structural comparison with shuffled and unrelated controls, plus a run on the burned-estate ports in both styles.

由索引模型根据 Issue 内容生成。

描述

enhancement legacy-modernization

Why

A structural-fidelity analysis of the det-port on the burned estates (2026-11-02; ~/gitgalaxy/cics-fidelity/ on nyx) found two things:

  • The translations are complete: 184 cases, 47,717 statements, 0 holes.
  • They keep each estate's relative structure: the between-program distance geometry is preserved (Mantel ρ 0.45-0.47, p = 0.001), and per-program function count and size correlate 0.82-0.86.

But a global fingerprint (sfs, portable or structure lens) cannot pick out a port's own COBOL source: 1-3 of 124 programs, against 0.8 % chance. A plain size matcher does better. The reason is that det-port Java is mechanical by design: byte storage, a runtime, one call per statement, dispatch methods. Every port has the same shape, a median of 32-36 Java methods against 7 COBOL paragraphs, and that shared style swamps each program's individual signal.

So whole-program fingerprints are the wrong instrument for translation fidelity. The forge and det-port already know the mapping: every generated class and method is traced to its source line and fact (traceability.json). Fidelity should be measured along that map.

Proposal

For each translated program, pair every COBOL paragraph or section with the Java method(s) traced to it, and compare their structure:

  • branch outcomes (IF/EVALUATE/PERFORM UNTIL against if/switch/loops);
  • calls out (PERFORM / CALL / LINK against invocations);
  • size, and the reads/writes of data items against field access.

Report per program, per paragraph and per estate:

  • the share of paragraphs whose structure survives within a tolerance;
  • the outliers;
  • an estate-level fidelity score.

Controls: shuffled paragraph-method pairs, and pairs from unrelated programs, so a fidelity score comes with its chance level.

Where it fits

  • The architecture roadmap's "cross-language blueprint fidelity" item.
  • A structural layer beside the equivalence proofs. Proofs say the Java does what the COBOL did; this would say the Java is shaped like the COBOL, paragraph by paragraph, which is what a reviewer reads.
  • It is measurement only: no new cases or proofs on the burned estates (that evidence work is melek's lane).

Acceptance

  • A tool (tests/tools/…) that reads a port plus its traceability.json and writes a per-paragraph structural comparison.
  • Shuffled and unrelated controls, with the score reported against them.
  • A run over the burned-estate det-ports in both styles (default, --style structured --typed --groups), with the headline numbers posted here.
主要语言
Python
星标
57
派生
11
平均合并
1 小时 30 分钟
30 天内合并 PR
971

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

squid-protocol/gitgalaxy 的其他 Issue

查看 squid-protocol/gitgalaxy 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。