🎌 Čeština, Deutsch, English, Español, Français, Italiano, Kurdi, Lietuvių, Nederlands, Norsk, Polski, Português, Türkçe, Ελληνικά, العربية, 日本語, 正體中文, 简体中文, 한국어
Le code source de ce dépôt a été numérisé manuellement à partir de papiers imprimés, les fautes de frappe et autres anomalies ont donc été introduites accidentellement. Le code doit être modifié pour être cohérent avec les impressions numérisées suivantes :
GitHub prend en charge nativement la syntaxe pour le langage assembleur AGC. Malheureusement, votre éditeur de texte ne l’aura pas. Mais il y a des extensions pour le langage AGC pour les éditeurs suivants :
- Atom†
- CodeBlocks
- Eclipse
- Kate
- ProgrammersNotepad
- Sublime Text 3†
- TextPad
- Vim
- Visual Studio Code†
- jEdit
† Prend en charge le formatage automatique
Note : GitHub et les extensions marquées ci-dessus vous assureront d'utiliser automatiquement le bon formatage.
- Utiliser une tabulation (tab) pour l'indentation
- Utiliser une largeur de 8 caractères pour la tabulation
- Pas d'espace à la fin des lignes
Tout écart entre les scans et le code source dans ce référentiel.
- Les commentaires dans le code transcrit doivent correspondre exactement aux scans.
- Les problèmes courants que vous devez rechercher lors de la vérification sont les suivants. Attention, la liste n'est pas exhaustive !
À certains endroits, les développeurs originaux ont fait des erreurs typographiques en écrivant des commentaires. Certaines d’entre elles ont été corrigées par erreur lors de la numérisation initiale, mais la numérisation a également introduit des erreurs typographiques qui n’étaient pas présentes dans les scans.
Par exemple, si les commentaires numérisés contiennent SPACECRAFT
, mais que SPAECRAFT
a été imprimé dans les scans, la numérisation DOIT être corrigée en SPAECRAFT
(C manquant).
De même, si un mot a une faute de frappe dans la numérisation mais est correctement orthographié dans les scans, alors la faute de frappe DOIT être corrigée.
Les espaces entre deux caractères dans les commentaires DEVRAIENT correspondre aux scans. Dans la plupart des cas (voir la discussion dans #316), c'est:
- Espace unique pour les nouveaux mots
- Double espace pour les nouvelles phrases
- Triple espace pour les indentations
Toutes les pages des scans ne suivent pas cette généralisation, si les scans n'ont qu'un seul espace au lieu d'un double espace, utiliser un seul espace.
- Les lignes avec
R0000
dans la colonne 1 doivent correspondre exactement aux scans. - Les sauts de ligne sans
R0000
dans la colonne 1 ne doivent contenir que 1 ou 2 lignes vides d'affilée.- Si il y a plus de 2 lignes vides, supprimer les sauts de ligne supplémentaires.
- Ne pas prendre en compte les lignes avec
R0000
dans la colonne 1.
- Ne pas prendre en compte les lignes avec
- Dans les images sources, celles-ci ont été créées à cause d'un caractère non imprimé dans la colonne 8. Un 2 a forcé un double espace (une seule ligne vide) et un 3 a forcé un triple espace (double ligne vide). Les valeurs 4-8 ont été définies mais n’ont jamais été utilisées. Pour en savoir plus #159
- Si il y a plus de 2 lignes vides, supprimer les sauts de ligne supplémentaires.
Par exemple, ce qui suit :
R0819 SUBROUTINE TO SKIP...
R0820
0821 LAMPTEST CS IMODES33
Doit devenir :
R0819 SUBROUTINE TO SKIP...
R0820
0820 LAMPTEST CS IMODES33
Avant de faire une PR, assurez-vous que vos modifications soient cohérentes avec les scans !