inform6 et Unicode

[auraes]

La dernière version du compilateur inform6 propose l’option -Cu pour compiler un fichier source en UTF-8, mais impossible de l’utiliser.
Le programme qui suit compile mais l’affichage n’est pas correct.
Si quelqu’un qui maîtrise l’anglais peut poser la question du bon usage de cette option et si elle est valide pour produire un fichier .z5 ou .z8
Merci.

https://github.com/DavidKinder/Inform6

[code]!% -Cu
!% -v8

!Source encoding UTF-8 No Mark

!ReleaseNotes.html : A new command line switch -Cu can be used to specify that the source file character set is UTF-8, allowing source files to contain Unicode characters beyond those defined in ISO 8859-1 to 8859-9.

Zcharacter table + ‹ @{a9} › ‹ @{A2} › ‹ @{2022} ›;
! Le compilateur exige ‹ @{a9} › ‹ @{A2} › dans la ‹ Zcharacter table › alors qu’ils n’ont rien à y faire !?

[ main key;

print "é";
new_line;
print "•";
new_line;
print "@{2022}";
new_line;
@print_unicode $2022;

@read_char 1 ->key;

];[/code]

[Otto_Grimwald]

chez moi ça fonctionne et compile correctement avec une source en utf8 :

inform-6.33b1 -Cu test.inf Inform 6.33 for Linux (2nd February 2013)

mais le fichier résultant donne :

é©

je suppose que le © est en trop.

De plus, en l’appelant dans mon projet I6, ça provoque des erreurs lors de l’appel des biblio francophones (que j’avais converties en utf8 pour l’occasion)

De toute façon je ne vais sans doute pas utiliser inform 6.33 pour mes projets I6, car il y a d’autres problèmes indépendamment de ça, notamment ils ont modifié parserm.h sans incrémenter la version ni la date du fichier, ce qui n’est pas très malin (peut-être ça sera corrigé dans la version finale), mais il y a d’importants ajouts de code et ça provoque des erreurs à la compilation :

"/usr/local/share/inform/6.33b1/module/parserm.h", line 5072: Error: No such constant as "Epilogue" "/usr/local/share/inform/6.33b1/module/parserm.h", line 6600: Error: No such constant as "UpperCase" "/usr/local/share/inform/6.33b1/module/parserm.h", line 6601: Error: No such constant as "LowerCase" "/usr/local/share/inform/6.33b1/module/verblibm.h", line 1019: Error: No such constant as "non_floating" "/usr/local/share/inform/6.33b1/module/verblibm.h", line 1587: Error: No such constant as "ObjectDoesNotFit" Compiled with 5 errors and 4 warnings

la version résultant affiche ces erreurs en plus du jeu lui-même :

[** Programming error: tried to “give” or test “has” or “hasnt” with a non-attribute on the object interrupteur ]
[ Programming error: tried to “give” or test “has” or “hasnt” with a non-attribute on the object baignoire ]
[ Programming error: tried to “give” or test “has” or “hasnt” with a non-attribute on the object objets divers **]

Quoi qu’il en soit il est bien précisé sur le site :

The version of Inform 6 used as the code generator for Inform 7

Donc il y a peut-être des effets de bord non prévu pour des jeux purement inform6.

[Otto_Grimwald]

j’ai posé la question ici :

intfiction.org/forum/viewtop … f=7&t=8834

[Mule_hollandaise]

Ouh là, je vais repasser à la version 6.31 en attendant moi. Merci pour le rapport de bugs Auraes.

Otto, en ce qui concerne les propriétés manquantes, je n’ai pas eu ces bugs-là en compilant Homeland Security, mais peut-être que mon code n’utilise pas les mêmes fonctions.

En tout cas, si le compilateur est officiellement incompatible avec les projets Inform 6, je ne suis pas content Idéalement il faudrait que quelqu’un fasse un fork purement I6, ou en tout cas qu’ils essaient de rendre le compilateur compatible avec I6 (ça doit être possible, avec des #IFDEF, non ?). J’ose espérer que c’est juste une erreur de leur part…

[Otto_Grimwald]

en fait le compilateur 6.33 fonctionne bien pour mon projet, ce sont les nouvelles bibliothèques associées qui posent problème.

Si j’utilise les biblio. de la 6.31 avec le compilateur 6.33 il n’y a pas de souci.

[Mule_hollandaise]

Ah, je comprends. C’est quand même embêtant, mais c’est moins grave.
J’ai vu que Andrew Plotkin t’avait répondu sur le forum, et il dit que normalement toute version du compilateur pourrait/pourra être utilisée pour des projets I6. Ca répond à ma question, et c’est donc rassurant.
Du coup, c’est pour les bibliothèques que c’est embêtant, vu que des nouvelles versions de celles-ci pourraient aussi être utiles (si jamais elles ont des bugs par exemple). On va voir ce que David Griffith dit j’imagine…

(D’ailleurs, si ça intéresse des gens : le compilateur I6 est en développement à l’adresse https://github.com/DavidKinder/Inform6/ et les bibliothèques sont en développement à l’adresse https://github.com/DavidGriffith/inform6lib. Je le dis parce que je confonds toujours leurs noms.)

[auraes]

Moi aussi ça compile. C’est l’affichage qui pose problème avec effectivement un caractère excédentaire.
Le compilateur exige ‹ @{a9} › ‹ @{A2} › dans la ‹ Zcharacter table › alors qu’ils n’ont rien à y faire !?

Je pensais que pour inform6, les caractères UTF-8 du fichier source présents dans ISO-8859-1 seraient simplement convertis, à l’ouverture du fichier, dans ce format et pour les autres, on utiliserait la ‹ Zcharacter table ›.
Bon, c’est bizarre surtout pour les caractères accentués classiques.

Pour le mise en forme des textes Inform6 est une vraie galère (retour ligne, paragraphe, caratère gras…); un peu d’Unicode n’aurait pas fait de mal.

[Otto_Grimwald]

Andrew Plotkin a répondu que ça ne pose pas de problème avec glulx mais il a confirmé le problème avec zcode et il va regarder.

Je le dis parce que je confonds toujours leurs noms.

idem

le mise en forme des textes Inform6 et une vraie galère (retour ligne, paragraphe, caratère gras…); un peu d’Unicode n’aurait pas fait de mal.

De façon générale je préfère avoir tous mes fichiers textes dans un seul encodage, en l’occurrence en utf-8. D’ailleurs je crois que mes fichiers .inf sont les seuls qui sont encore en iso-machin chez moi. Mais d’un autre côté, les éditeurs de texte avancés permettent de détecter correctement l’encodage à l’ouverture, et quand j’utilise Geany ou Vim, ça ne pose pas vraiment de problème. Pour les caractères gras, les retour à la ligne, je ne vois pas en quoi cela a à voir avec l’unicode par contre.

[Mule_hollandaise]

Plotkin vient de régler le bug : il suffisait d’ajouter un « continue » quelque part apparemment. Ca sera sûrement inclus dans la prochaine version (pour l’instant c’est que sur son GitHub, github.com/erkyrath/inform6 , mais ils devraient sans doute propager la modif).

Bien joué auraes, un bug de moins !

[auraes]

Quelle bonne nouvelle et qu’elle réactivité ! Ça fonctionne !
Donc, pour les caractères qui ne sont pas dans la Table ZSCII CHARACTER HIGHER (doc. page 520), il suffit de rajouter l’Unicode du caractère concerné dans la ‹ Zcharacter table ›. Le ‹ + › après ‹ table › signifie que l’on rajoute ces caractères à la table (HIGHER) existante. Sans le ‹ + ›, il est possible de remplacer ceux-ci.
Et il faut bien sûr que la police de caractère de l’interpréteur soit Unicode et qu’elle supporte ces caractères et ne pas oublier de compiler avec l’option -Cu.
Ce qui donne pour une simple ‹ puce › et un ‹ caractère de suspension › :

[code]!% -Cu
!% -v8
!Source encoding UTF-8 No Mark

Zcharacter table + ‹ @{2022} › ‹ @{2026} ›;

[ main key;

print "•…";

@read_char 1 ->key;

];[/code]

[code]!% -Cu
!% -v8
!Source encoding UTF-8 No Mark

Zcharacter table + ‹ @{0178} › ‹ @{00A9} › ‹ @{20AC} › ‹ @{2022} › ‹ @{2026} › ‹ @{2122} › ‹ @{2013} › ‹ @{2014} › ‹ @{202F} › ‹ @{a0} ›;

[ main key;

!Sans la Zcharacter table
print "àâäçèéêëîïôöùûüÿ"; new_line;
print "ÀÂÄÇÈÉÊËÎÏÔÖÙÛÜ"; new_line;
print "«»æÆœŒ"; new_line;

!Avec la Zcharacter table
print "Ÿ©€•…™–—  "; new_line;

@read_char 1 ->key;

];
! http://hapax.qc.ca/conversion.fr.html
[/code]
Merci !

[auraes]

Sous Xp un @pop plante mon système à la compilation avec le compilateur 6.33 ou 6.32. Pas sous linux. Si vous pouvez tester sur différents systèmes.

!% -C1 !% -v5 [ main; @pop; ];

[Mule_hollandaise]

[ main; @pop; ]; , c’est le code source minimal ?

C’est de l’I6 ou du Glulxe ? Ca sert à quoi ? (je ne l’ai pas vu dans le DM4)

[auraes]

Bon, apparemment c’est un problème sur les versions 6.32.1 et 6.33.
Sur la 6.32, j’obtiens :

Inform 6.32 for Win32 (18th November 2010)
game\test1.inf(5): Error: Opcode unavailable in this Z-machine version: « pop »

@pop;
Compiled with 1 error (no output)

Mais sur les deux autres, ça crash. En fait l’instruction ‹ pop › n’existe plus dans la version ‹ Z-Machine Standard 1.1 › .Mais cela ne devrait pas faire planter le système.

@Mule hollandaise

C’est de l’I6 ou du Glulxe ? Ca sert à quoi ? (je ne l’ai pas vu dans le DM4)

http://flatassembler.net/docs.php?article=manual
http://www.ifarchive.org/indexes/if-archiveXinfocomXinterpretersXspecification.html

[auraes]

@Otto Grimwald

« /usr/local/share/inform/6.33b1/module/verblibm.h », line 1019: Error: No such constant as « non_floating »

(Inform version 6.33, library version 6/12)
C’est vraiment bizare : c’est parser.h qui inclut linklpa.h qui contient la déclaration de l’attribut non_floating : linklpa.h : [...] Attribute non_floating alias absent;Mais il ne semble pas la considérer tant qu’elle est à l’intérieur de linklpa.h !? Par contre si je l’efface de linklpa.h et je la mets dans parser.h, juste après l’Include de linklpa, cela fonctionne !?parser.h : [...] Include "linklpa"; Attribute non_floating alias absent;Assurément il y a un problème. As-tu posé la question ?

[Otto_Grimwald]

As-tu posé la question ?

non, par contre on verra ce que ça donnera quand tout ça sortira de la beta. Tu peux proposer tes services pour mettre ça en ordre si le sujet t’intéresses, vu que tu sembles assez bien le connaître.

[auraes]

@Otto Grimwald

ils ont modifié parserm.h sans incrémenter la version ni la date du fichier, ce qui n’est pas très malin (peut-être ça sera corrigé dans la version finale), mais il y a d’importants ajouts de code et ça provoque des erreurs à la compilation :

Code: Tout sélectionner
« /usr/local/share/inform/6.33b1/module/parserm.h », line 5072: Error: No such constant as « Epilogue »
« /usr/local/share/inform/6.33b1/module/parserm.h », line 6600: Error: No such constant as « UpperCase »
« /usr/local/share/inform/6.33b1/module/parserm.h », line 6601: Error: No such constant as « LowerCase »
« /usr/local/share/inform/6.33b1/module/verblibm.h », line 1019: Error: No such constant as « non_floating »
« /usr/local/share/inform/6.33b1/module/verblibm.h », line 1587: Error: No such constant as « ObjectDoesNotFit »
Compiled with 5 errors and 4 warnings

J’ai passé mes librairies VERB+NOUN en lib 6/12 et en fait, les routines UpperCase et LowerCase se trouvent maintenant dans leur english.h : Tu les récupères dans leur fichier et tu les mets dans ton French.h. Pour les autres, c’est pareils : les déclarations se trouvent, en bas de leur fichier grammar.h : Tu les recopies dans ton FrenchG.h et cela fonctionne ! Je n’est pas eu de problème avec non_floating, je ne sais pas si tu en auras un.

Du coup, plus de problèmes avec un objet « orange » : l’apostrophe est bien collé au mot : http://auraes.free.fr/inform6/orange.z5[code]!% -Cu
!% +language_name=english
Include « Parser »; Include « VerbLib »;
Object room1;

!/* L’orange | l’orange | Une orange | une orange

Object orange « orange » room1
with
name ‹ orange ›,
article « une »,
articles « L’ » « l’ » "une "
has edible female
;
Object oeuf « œuf » room1
with
name ‹ oeuf ›,
article « un »,
articles « L’ » « l’ » "un "
has edible male
;
Object ile « Île » room1
with
name ‹ ile ›,
article « une »,
articles « L’ » « l’ » « une »
has
;
Object sucre « sucre » room1
with
name ‹ sucre ›,
article « du »,
articles "Le " "le " "du "
has edible male
;
Object confiture « confiture » room1
with
name ‹ confiture ›,
article « de la »,
articles "La " "la " "de la "
has edible female
;
[ Initialise i;
for (i = orange : i <= confiture : i++)
print « ^ », (The) i, " | ", (the) i, " | ", (A) i, " | ", (a) i, « ^ »;
new_line;
location = room1;
];
Include « grammar »;
[/code]