J’ai écrit à JL, il ne reste plus que JB qui a participé (en se basant sur le header, il faudrait peut être jeter un coup d’oeil à l’historique SVN pour vérifier qu’on oublie personne) à French1PSP.h: svn.tuxfamily.org/viewvc.cgi/in … iew=markup
Je vais lui envoyer un MP.
(Je pense pas qu’on ait à remonter jusqu’à Jose Luis Diaz pour avoir le droit de définir la licence, sinon ce serait sans fin.)
Pour JB je dois répondre à un de ses mails ce soir, alors je lui demanderai ! (Je sais pas si il consulte encore ses MP)
Si tu trouves un meilleur moyen de le faire vas-y 
tu peux sans doute cloner mon dépôt extensions-i6 si tu en as besoin. C’est vrai que c’est dommage pour les timestamps, même si je croyais qu’ils étaient dans « git log »…
(Si tu fais joujou avec mon dépôt, mon premier commit est uncopier-coller du fichier svn, alors fais gaffe en l’appliquant !)
Pour mes extensions, vu qu’elles sont pas spécifiques au français je sais pas si c’est nécessairement pertinent de le mettre dans i6-french, mais pourquoi pas…
Pour la licence MIT, pourquoi pas, mais a-t-on le droit de ‹ relicencier › comme ça ? (Ça posera pas de problème avec le fait que Graham Nelson a fait le reste des libs en Artistic ?)
Ce ne serait pas mieux de mettre le dépôt I6 dans le même projet que le dépôt I7 ? Comme ça on renomme ce projet en « Inform en français » ou quelque chose du genre. À moins que vous trouvez que les deux sont assez indépendant (je ne pense pas que ce soit le cas).
Stormi m’a trouvé son mail, donc je lui ai déjà écrit. Mais si tu veux insister, n’hésite pas 
C’est noté, j’essaie de regarder ça ce soir ou demain.
Ah, du coup c’est pas forcément nécessaire non, c’est toi qui voit. Je sais pas si avoir tous nos travaux Inform dans la même organisation est mieux pour leur visibilité, ou si tu préfères garder tes extensions en projet solo.
Bien vu, j’y pensais aussi en chemin. Comme nos libs dérivent de celles de Graham Nelson, il faut en effet qu’on se conforme à leur licence, donc le plus simple est bien d’utiliser l’Artistic License 2.0 nous aussi 
Je ne sais pas trop ce que Bitbucket entend par « Projets », mais pourquoi pas. Par contre le projet actuel n’a pas de nom, ça fait pas très classe Mais je pense que tu as raison, il pourrait y avoir un projet « inform-french-lib » ou un truc du genre avec les deux dépôts pour I6 et I7, et des extensions francophones éventuellement (genre scenic5sens.h). On pourrait aussi faire un projet « games » (ou « jeux », ça reste des projets bien francophones) et migrer les jeux qu’on a fait ensemble comme Lieux Communs depuis SVN.
En fait, moi non plus je ne sais pas exactement ce qu’est un projet (apparemment, c’est juste pour organiser les dépôts). Il n’y en avait pas au départ, mais une mise à jour de BitBucket en a ajouté un automatiquement aux équipes (et donc à inform-fr). On n’y a pas touché, alors c’est resté « Untitled project ». 
J’ai eu des réponses de JL et JB pour passer la bibliothèque sous Artistic Licence 2.0 :
Argh, on dirait que tu as raison. J’ai fait un clone du dépôt actuel, et le git log est correct. Bitbucket est pas capable de marquer les commits avec la date correcte ? 
Edit : Ah je vois le problème. La bonne date, listée dans le git log, est la « author date » et est préservée. Mais celle que montre Bitbucket est la « committer date », qui date d’hier puisque tu n’as probablement pas bricolé assez pour préserver la « committer date » initiale Je vais voir ce que je peux faire.
Edit 2 : J’ai un résultat pas mal en local, mais j’ai pas eu le temps de finaliser à cause d’un meeting IRC. Je finis ça demain
J’en suis à ça pour l’instant : github.com/akien-mga/inform6-fr … its/master (sur GitHub tant que je bricole, je passerai ça sur Bitbucket une fois prêt).
Il me reste juste à trouver comment ne pas apparaître moi même en tant que committer pour les commits d’Hugo
Edit : OK, j’ai réussi ! github.com/akien-mga/inform6-fr … its/master
Il m’a fallu faire un commit et l’antidater pour la transition entre SVN et git, parce que Mule avait laissé son IDE retirer les quelques espaces en fin de lignes qui étaient présents dans la version SVN : github.com/akien-mga/inform6-fr … d6351fb7c6
Voilà, j’ai fini : bitbucket.org/informfr/i6-frenc … ommits/all
Suite aux retours de Natrium, j’ai renommé le projet sans nom (qui contient i7-french-language) inform-french-libs, et j’y ai ajouté un dépôt git i6-french-language. Les deux dépôts sont dans dans la même organisation informfr, et dans le même projet inform-french-libs.
Pour faire ce dépôt, j’ai pas mal bricolé avec git, trichant pas mal de façon éhontée avec la git history pour préserver les dates et auteurs de commits initiaux. Le dépôt est donc a priori tel qu’il l’aurait été si Mule avait fait une conversion svn → git dès le départ, puis travaillé sur ce nouveau dépôt.
Pour référence, voici ce que j’ai fait (il m’aura fallu pas mal d’essais pour trouver ce qui a marché au final, je vous donne donc la version aboutie) :
Conversion du dépôt svn en dépôt git
git svn clone svn+ssh://akien@svn.tuxfamily.org/svnroot/informfr/informfr/ --trunk=inform6-fr/trunkCette commande crée un nouveau dépôt git à partir du dépôt svn passé en URL, et j’ai défini comme trunk le dossier inform6-fr/trunk, vu que je ne voulais avoir que l’historique pour la lib I6 dans ce nouveau dépôt.
Ça a affiché plein de trucs, m’a demandé mon mot de passe TuxFamily au moins 8 fois, mais au final ça m’a créé un dépôt git avec exactement ce que je voulais. Je n’ai pas cherché à faire importer les tags, préférant les refaire à la main plutôt que d’avoir a bricoler une séparation I6/I7.
Rebasage du dépôt git d’Hugo par dessus ce nouveau dépôt
Ça c’était le gros morceau. Je suis parti du travail déjà fait par Hugo pour extraire seulement les fichiers pertinents de son dépôt original (qui contenait des extensions en plus de la lib francophone, et pas French1PSP.h).
Premier problème : le premier commit d’Hugo ajoutait les fichiers French.h et FrenchG.h dans la même version que sur svn, donc a priori je n’avais qu’à me passer de ce premier commit et importer les changements à partir du 2ème commit. Le soucis est que lors de son import initial, Hugo a laissé son IDE retirer les espaces en fin de ligne qui existaient dans la version svn. Ça n’a évidemment pas plu à git lorsque j’ai essayé d’appliquer le deuxième commit, j’ai donc dû faire un commit intermédiaire moi-même pour retirer ces espaces en fin de ligne: github.com/akien-mga/inform6-fr … d6351fb7c6
Pour préserver l’ordre chronologique, j’ai dû antidater mon commit :
git commit --date="Fri Nov 21 00:01 2014 +0100"Comme indiqué plus haut, le nouveau dépôt i6-french était bien fait par Hugo, à part la date de commit (git fait une différence entre date d’écriture du patch par l’auteur, et date de commit du patch par le committer, qui peut être une autre personne). Du coup le dépôt i6-french avait les bonnes dates d’écrire (s’échelonnant entre 2014 et 2015), mais toutes les dates de commit étaient le 25 mai 2016. Or ce sont ces dates de commit que Bitbucket montre, du coup ce n’est pas top pour voir rapidement quand un commit a été écrit.
Pour corriger ça, j’ai commencer par récupérer tous les commits sous forme de patchs :
git format-patch d8287d6^..2c63a41Puis j’ai appliqué tous ces patches dans mon nouveau dépôt (de la transition svn → git) en utilisant l’option –committer-date-is-author-date pour m’assurer que la date de commit soit la même que la date d’écriture. Autre subtilité, pour que l’identité du committer ne soit pas la mienne mais celle d’Hugo, j’ai aussi dû tricher à ce niveau là :
GIT_COMMITTER_NAME='hlabrand' GIT_COMMITTER_EMAIL='<adresse email d'Hugo>' git am --committer-date-is-author-date 00*.patchEt voilà ! Un beau dépôt tout neuf avec pas mal de bricolage, mais qui contient tout l’historique du dépôt SVN + du dépôt git d’Hugo
Bien joué ! C’est une bonne chose de faite ! Et merci pour ton walkthrough 
Bon, alors maintenant question subsidiaire : comment bouge-t-on les anomalies que j’ai logguées dans i6-french hier pour les mettre dans i6-french-language? X)
(En tout cas ne supprimez pas i6-french, hein !!)
Ah j’avais pas vu les rapports de bug/tâches que tu as déjà créées dans le dépôt i6-french.
Je peux tenter de faire un force push du contenu de i6-french-language dans i6-french, et garder i6-french comme projet principal (donc virer i6-french-language, et ensuite éventuellement renommer/bouger i6-french).
Edit : C’est fait : bitbucket.org/informfr/i6-french-language
Le nouveau i6-french-language est donc l’ancien dépôt i6-french avec le contenu git de l’ancien i6-french-language
Trop fort <3
J’y pense, est-ce qu’il serait envisageable de « standardiser » les biblis ? Je pensais à un truc du genre on crée une FI qui effectue plein de commandes, pour tester les réponses des actions, ou la grammaire, entre autres, et on compare le texte qui sort à une transcription de référence. Il faudrait que cette transcription soient indépendante de la version d’Inform (excepté pour les différences normales, comme les actions qui ont disparu avec I7), comme ça, un jeu fait avec I6 se comportera de la même manière qu’un jeu fait avec I7.
Ce serait sans doute beaucoup de travail pour pas grand-chose : il faudrait documenter le comportement standard, créer deux projets (un pour I6 et un pour I7) qui se comportent pareils, et qui testent absolument tout. Ça ne doit pas être nécessaire vu la quantité de jeux Inform qui sortent chaque année.
au niveau des commandes, j’avais fait ça à l’époque, mais je pense que les bibl. ont pas mal été modifiées depuis le temps :
ifwiki.org/index.php/Le_Roi_de_Fihnargaia
D’ailleurs je viens de voir que c’était le jeu inclus dans la bibliothèque d’inform 7 en français à l’époque.
Oui, c’est toujours l’exemple inclus dans l’extension. Mais je pensais à quelque chose de plus systématique (pour tester par exemple toutes les réponses à tous les temps et à toutes les personnes).
Ce sujet m’a donné envie d’essayer I6 (ne serait-ce que pour pouvoir mieux comprendre quand j’en injecte dans I7). J’ai eu un peu de mal au début, parce que la plupart des aides (notamment sur le site) pour Mac ne sont pas à jour. Le truc qui m’a vraiment embêté, c’est l’encodage : quand j’ouvre les bibliothèques, ça s’affiche comme ça :
[attachment=0]encodage.png[/attachment]
Je suis obligé d’ouvrir mes fichiers Inform avec TextWrangler (mon éditeur de code) en spécifiant bien qu’il faut les ouvrir en ISO Latin 1, puis de les sauvegarder en UTF-8 (pour pas à refaire ces étapes à chaque fois). En tout cas, la compilation avec -Cu ne m’a pas posé problème (une fois les biblis françaises passées en Unicode). Y a-t-il un problème pour tout mettre définitivement en Unicode ? (à part le fait que l’utilisateur ne doit pas oublier le -Cu. Si vous voulez mon avis, le compilateur devrait le faire par défaut.)
À l’époque il fallait impérativement utiliser l’iso-machintruc et non pas l’utf-8 sinon ça ne compilait pas. Je ne sais pas ce qu’il en est maintenant. Je ressors un vieux jeux, et effectivement le code est en iso-8859-1 (ça s’ouvre automatiquement dans le bon format avec le logiciel Geany ou Kate sous Linux). Ma version d’inform est la 6.31 de 2006. Je vais essayer de faire les mises à jour vers les nouvelles bibliothèques, on verra ce qu’il en est, ça me dérange aussi un peu de garder un autre format que l’utf-8.
Oui, passer en UTF-8 est nécessaire ; le seul truc qu’il faut peut-être vérifier avant de le faire c’est est-ce que ça va gêner un utilisateur lambda ? Si on donne un fichier UTF-8 à manger au compilateur sans le flag, est-ce qu’il dit « utilisez le flag -Cu » ou est-ce qu’il perd la boule et donne une erreur ésotérique ? (On pourrait dire « c’est pas notre problème », mais bon…)
Il me semble qu’il y a un moyen de spécifier des flags de compilation dans le code source (peut-être avec % au début de la ligne ?). Je me souviens plus de comment on fait ; mais si y’a moyen de forcer le flag -Cu avec une instruction dans la bibli (de sorte qu’un utilisateur lambda n’a rien à faire), ça serait mieux.
Je pense qu’il faudrait « faire pression » sur les développeurs d’inform6 pour qu’ils l’incluent d’office (ils ne se rendent pas forcément compte que c’est nécessaire s’ils sont anglo saxons) et permettent un flag pour utiliser l’iso-machin à la place. On est en 2016, ça fait plus de 10 ans que j’ai passé tous mes fichiers textes en utf8, et même si je suis pour le maintien des anciennes fonctionnalités le plus longtemps possible et ne pas tout casser d’une version à l’autre, ici ça me semble quand même nécessaire depuis le temps. Reste à savoir ce que donne l’ouverture d’un fichier utf8 depuis windows (genre l’odieux notepad.exe), est-ce qu’il va pouvoir relire le texte correctement ?
I � unicode
c’est pas encore gagné…
Déjà, j’avais l’habitude d’utiliser plusieurs sources de bibliothèques, séparées par des virgules. Visiblement, maintenant ça bloque si le chemin est trop long :
vers la fin, le « tr » fait référence à « trunk », il n’a pas pu aller au bout. En fait, dans la nouvelle organisation des fichiers, le dossier « outils » n’existe plus, du coup je ne sais pas si cet affichage a été provoqué par cela ou si c’est lié à une limitation qu’il n’y avait pas auparavant. En tout cas avant on mettait divers chemins possibles et inform se débrouillait avec cela. Vu que ce nouveau compilateur est prévu pour Inform7, avec des chemins quasi intangibles, c’est possible que ça soit moins souple qu’auparavant
J’ai corrigé les chemins chez moi, et mis uniquement de vrais chemins existant :
inform -v5 +include_path=/usr/local/share/inform/lib,/home/monlogin/perso/_mesdocs/mes_vcs/i6-french-language/,/home/monlogin/perso/_mesdocs/mes_vcs/svn_inform_tuxfamily/informfr/outils/divers/trunk/ +Language_name=French monjeuNéanmoins j’ai là une autre erreur :
J’ai copié dans un dossier temporaire les 2 dossiers qui posaient problème + les options qui vont bien :
inform -v5 +include_path=./lib,/usr/local/share/inform/lib,/tmp/libs +Language_name=French '$MAX_VERBS=180' '$MAX_ACTIONS=250' '$MAX_DICT_ENTRIES=2000' monjeu et là il manque trop de choses :
(12 erreurs en tout)
Je vois que dans English.h il y a une référence à « Constant COLON__TX », il faudra sans doute le rajouter, ainsi que d’autres dans la bibl francophone, ou bien modifier le fichier parser.h
Et à mon avis, ce n’est pas terminé… les fichiers parser.h et english.h ont été complètement modifiés depuis la version 6.11, du coup je pense que ça va être un gros travail pour mettre ça à jour.