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

Translator consumes engine record layouts (fact_ownership.md follow-up): POINTER width as a parameter, shared stand-in copybooks, retire the duplicate layout computation

Abierto
  • ¿Algo no está bien?
#5,649 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@squid-protocol ya está trabajando en esto.

Desde el 21/10/2026.

  • #5850 de @squid-protocol — abierto

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
30/100
Tipo de issue
Refactorización
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
python
Área
backend, compilers

Línea de trabajo

Start with gitgalaxy/tools/cobol_to_java/det/layout.py, the engine's GalaxyIR layout path, and core/copy_libraries.py. Then examine the offsets entries in tests/cobol_mainframe/fact_crosscheck_ledger.json and the layout guidance in docs/language_status/fact_ownership.md. Completion requires parameterizing POINTER width, sharing stand-in copybooks, switching translator layout use, and reducing the listed offset disagreements to zero while all relevant equivalence cases pass.

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

Descripción

core-engine enhancement lane:nyx priority: high scope:core

Why

docs/language_status/fact_ownership.md:82 (record layouts / offsets) left a follow-up: "revisit having the translator consume engine layouts once #4457 / #4458 are fixed and POINTER width is a parameter: the engine would then match the translator everywhere on these corpora." #4457 and #4458 closed on 2026-10-05; the follow-up was never picked up. Today both sides compute every record layout; the translator uses its own (gitgalaxy/tools/cobol_to_java/det/layout.py), the engine's go to analysis (record_data, via GalaxyIR).

Where the two sides still differ (fact cross-check ledger tests/cobol_mainframe/fact_crosscheck_ledger.json, 2026-10-19)

586 offsets disagreements, all definitional, no engine-wrong layout left:

  • 380 translator-uses-mq-stand-ins (#4892): the translator expands its shipped IBM MQ stand-in copybooks (CMQV, CMQODV, CMQMDV, CMQGMOV, ...); the engine doesn't see them.
  • 210 pointer-width: POINTER is 4 bytes on z/OS (engine, answer keys) and 8 in the GnuCOBOL storage the proofs run on (oracle_assumptions.md C9).
    Plus small definitional ones elsewhere (translator-uses-stand-in-copybook CEEIGZCT #4884, refusals by name).

Work

  1. POINTER width as a parameter of the engine's layout computation (default z/OS 4; the translator asks for its storage's width), so one computation serves both.
  2. Stand-in copybooks as a shared library: the engine resolves the same shipped stand-ins (MQ, CEEIGZCT) the translator uses, through core/copy_libraries.py, flagged as stand-ins in the facts.
  3. Translator consumes engine layouts (through GalaxyIR / the port ticket, like COPY resolution since #4468) for offsets, lengths, OCCURS strides, REDEFINES; keep the translator's own computation behind a check mode for one release so any difference fails loudly.
  4. Update fact_ownership.md: layouts owned and computed by the engine; the gate keeps checking until the translator's copy is deleted.

Acceptance

  • Fact cross-check: offsets disagreements for the two causes above go to 0 (ledger lowered in the same PR, per its two-way ratchet).
  • Re-proof: every CICS / estate / golden crucible port and equivalence case passes byte-for-byte with the translator on engine layouts.
  • Builds on the shared preprocessor (#5648) if it has landed (the expanded text both sides lay out should be the same text); can start with steps 1-2 before it.

Part of the CICS→Java path (Training Montage).

🤖 Generated with Claude Code

Lenguaje dominante
Python
Estrellas
57
Forks
11
Merge medio
1 h 41 min
PR fusionados (30 d)
978

Preparar el entorno

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

Todos los issues de squid-protocol/gitgalaxy

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.