Future-proofing the example code
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 30/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- git
- Área
- documentation, tooling
Línea de trabajo
Comienza en el directorio preproc del repositorio y compara el preprocesador incluido con el preprocesador links predeterminado de mdBook. Investiga cómo los commits referenciados pueden seguir siendo alcanzables desde master y cómo se deben seleccionar las partes de los archivos que se incluirán. Se considera terminado cuando el tutorial puede extraer una porción de código en línea de un commit especificado sin depender de actualizaciones manuales repetidas.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Parts II and III will have the reader (and thus, the writer as well) working iteratively on a codebase. Where it gets iffy is that any change made to earlier lessons must be consistently reflected in later lessons. (This could happen for example because an earlier lesson is amended to make "room for" a later one, to update the syntax for a newer RGBDS version etc.)
Propagating these changes throughout the tutorial, where they would be presented "inline", would be a massive pain. Instead, I suggest the codebase should be checked out into Git, and inline code examples pulled from that repo.
This does get somewhat involved in several ways (e.g. ensuring that all referenced commits are reachable from the master branch, keeping referenced line numbers consistent when rebasing, etc.), but I think is essential if we want to avoid the tutorial irremediably bit-rotting in the longer term.
The concrete solution, I'd say, is to build a mdBook preprocessor (either stand-alone, or as part of the bundled one), that is able to include portions of files (like the default links preproc is able to), but picking a version of that file in a specific commit. libgit integration is desirable so as to avoid a ton of slow git checkouts, but not necessary—the priority is to it make work.
- Lenguaje dominante
- Assembly
- Estrellas
- 179
- Forks
- 64
- Merge medio
- 7 d 22 h
- PR fusionados (30 d)
- 1
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de gbdev/gb-asm-tutorial
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
gbdev/gb-asm-tutorial#194 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
gbdev/gb-asm-tutorial#184 · 1 comentario ·
-
good first issue
Dificultad 1/5 Menos de una hora Aptitud para principiantes 75/100
gbdev/gb-asm-tutorial#141 · 2 comentarios · 2 reacciones ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 65/100
gbdev/gb-asm-tutorial#109 ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 55/100
gbdev/gb-asm-tutorial#183 ·
Todos los issues de gbdev/gb-asm-tutorial
Issues similares
-
Crush Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
catppuccin/catppuccin#3125 ·
-
Link Checker Report Abiertoautomated issue report
Dificultad 1/5 Menos de una hora Aptitud para principiantes 95/100
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
VoltAgent/awesome-design-md#469 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
KhronosGroup/glTF#2648 ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
sccn/sccn.github.io#108 ·