Un ptit bug dans les biblis d'I6 ?

[auraes]

C'est bien un problème avec Bocfel.

[auraes]

Il y a un problème avec la directive 'Message' qu'il faudrait faire corriger. Le message, qui s'affiche lors de la compilation, n'est pas correcte s'il comporte des accents. Même si le fichier english.h(ou French.h) est en ISO-8859-1; ce qu'il est sensé être avant la possibilité de compiler en UTF-8. Sous console Windows ou linux, le problème est le même.
Ça doit être facile à corriger.

fichier French.h :
Message "[Compilé avec la version 2.4dev de la bibliothèque francophone.]";

[auraes]

Il y a un gros bogue avec les librairies 6/12. Il est possible de rentrer et de sortir d'un objet fermé !?

Code: Tout sélectionner

Include "Parser";
Include "VerbLib";

Object room "ROOM"
   with description "room"
   has light;

Object box "BOX" room
   with name 'box',
   has enterable container openable ~open
;

[ Initialise; location = room; ];

Include "grammar";


Librairies 6/11 :

Release 1 / Serial number 131226 / Inform v6.33 Library 6/11 S
ROOM
room
You can see a BOX (which is closed) here.
> enter box
You can’t get into the closed BOX.

Librairies 6/12 :

Release 1 / Serial number 131226 / Inform v6.33 Library 6/12pre S
ROOM
room
You can see a BOX (which is closed) here.
> enter box
You get into the BOX.
> exit box
You get out of the BOX.
ROOM
room
You can see a BOX (which is empty) here.

[auraes]

En fait, il s'agit certainement d'un oubli. Dans verblibm.h de la librairie 6/12 et pour le routine 'EnterSub', il manque :
if (noun has container && noun hasnt open) return L__M(##Enter, 3, noun);

lib 6/11 :

Code: Tout sélectionner

[ EnterSub ancestor j k;
    if (noun has door || noun in compass) <<Go noun>>;
    if (player in noun) return L__M(##Enter, 1, noun);
    if (noun hasnt enterable) return L__M(##Enter, 2, noun);
    if (noun has container && noun hasnt open) return L__M(##Enter, 3, noun);

    if (parent(player) ~= parent(noun)) {
[...]

Lib 6/12 :

Code: Tout sélectionner

[ EnterSub ancestor j ks;
    if (noun has door || noun in compass) <<Go noun, actor>>;
    if (actor in noun) return L__M(##Enter, 1, noun);
    if (noun hasnt enterable) return L__M(##Enter, 2, noun, verb_word);

    if (parent(actor) ~= parent(noun)) {
[...]

[Mule hollandaise]

Il me semble que cette ligne est présente plus tard, par contre avec un ajout (qui est sans doute ce qui fait planter ?)
Ligne 1953 :

Code: Tout sélectionner

if (noun has container && noun hasnt open && ImplicitOpen(noun)) return L__M(##Enter, 3, noun);


[auraes]

Oui, bien vu; c'était trop simple comme solution. La version 6/12 rajoute la constante 'NO_IMPLICIT_ACTIONS', qui permet de désactiver les actions implicites. Donc en effet, c'est possible que l'erreur vienne de là.

If you define a Constant NO_IMPLICIT_ACTIONS, the library will not
attempt to do things that implicitly must be done like taking an object
from a sack before dropping it.

L'erreur vient certainement de ImplicitOpen() ou de CheckImplicitAction().
Dans mon programme, la box a en effet bien été ouverte automatiquement en faisant un : > enter Box.

[Mule hollandaise]

En tout cas, il y a bien un bug, bien joué !

Je ne l'avais jamais remarqué parce que je suis encore en version 6/11. La version 6/12 n'est pas officiellement stable, c'est ça, c'est toujours une version de développement ?

Et je ne me rappelle plus si tu as un compte sur le Mantis ou sur Intfiction.org, mais si tu veux le faire remonter aux gens qui bossent sur Inform c'est sans doute les deux meilleures façons de le faire.

[auraes]

https://github.com/DavidGriffith/inform6lib
Non, je n'ai pas de compte, et mon anglais est médiocre. Fais-le, toi.
Et pour la directive 'Message' qui affiche mal les accents dans la console ?

[Mule hollandaise]

Ok, c'est donc la version de développement. Je vais le signaler sur mantis. Merci!

Pour le truc du message, en fait je n'ai pas compris quel était le problème. Tu dis "le message n'est pas correct", mais que veux-tu dire par là ? Les accents ne s'affichent pas bien dans le terminal, peut-être ? (Mais qu'en est-il si tu rediriges la sortie du programme dans un fichier, du genre "make monjeu >fichier.txt" sur Linux ? Est-ce qu'il y a toujours ce problème d'accent ?)
On peut essayer de régler le problème au niveau des bibliothèques francophones, en écrivant un hack du genre

Code: Tout sélectionner

Message "[Compil@'e avec la version 2.4dev de la biblioth@`eque francophone.]";


Ca devrait (peut-être !) régler le problème. Mais si ça n'est pas ça, soit plus précis et on regardera ça.
[EDIT: j'ai essayé, ça ne marche pas ! Le bug est donc dans I6, je ne sais pas où.]

Mais de la même façon, si tu essaies d'utiliser la commande "Abbreviate" dans un code source et qu'il y a des accents dans les chaînes que tu veux raccourcir, si je me souviens bien les accents ne sont pas bien affichés non plus. J'aurais donc tendance à dire que le bug vient d'I6, et pas des bibliothèques francophones.
Il faut que je le signale aussi ?

[auraes]

Avec le compilateur Inform 6, si la directive 'Message', située dans le fichier english.h(ou French.h), comporte des accents et si ce fichier est sauvegardé en ISO-8859-1, les accents du message 'Message' qui s'affiche dans le terminal, seront erronés.
C'est surtout problématique sous Windows (problématique mais cosmétique !)
Cela concerne bien le compilateur i6 et non pas les librairies. Généralement cela provient de l'utilisation pour la variable, d'un char(signé) au lieu d'un unsigned char, qui lui seul permet de contenir un caractère accentué.
Oui, tu devrais le signaler.

[ Cela n'a rien à voir mais :
Deux petites fautes d'orthographe [x] sur le site et quelques broutilles typographiques que je ne relève pas :
http://ifiction.free.fr/index.php?id=articles_ecriture
Richesse : le monde doit avoir un[e] nombre raisonnable de pièces et d'objets.
Je t'invite à jouer à des jeux d'aventures, et de trouver pourquoi tu adores [c]a

Sinon il faudrait enlever ça (Les liens sont brisés et la référence à mon pseudo me contrarie un peu) :
http://ifiction.free.fr/index.php?id=divers
(Merci à Auraes qui nous propose cela également sur son site : http://auraes.free.fr/inform.lang)
(Merci à Auraes qui nous propose cela également sur son site : http://auraes.free.fr/wide.ini)
http://hlabrande.fr/if/inform6trucs.html
(Merci à Auraes pour m'avoir signalée une erreur dans le code, depuis corrigée.)
mais Auraes m'a fait remarquer sur le forum ]

[Mule hollandaise]

Je viens de mettre les deux sur Mantis. Et pour le reste, c'est juste que tu veux qu'on enlève ton pseudo ?

[auraes]

Oui, et les remerciements sont inutiles; on va pas passer son temps à se congratuler !? (Et les liens sont brisés.)

[Otto Grimwald]

ok j'ai corrigé les trucs sur le site.

[Mule hollandaise]

Zarf vient de répondre en disant que le coup des accents n'était pas un bug, juste un problème d'encodage dans le terminal, donc rien à voir avec I6. C'est vrai, si tu rajoutes ">fichier" à la fin de la ligne de commande (comme je l'avais dit il y a deux messages) et que tu ouvres "fichier", il n'y a pas de problème. Donc il l'enlève de Mantis en le faisant passer à "not a bug".

[auraes]

O.K, mais j'avais bien compris qu'il s'agissait d'un problème d'encodage avec le terminal (surtout sous Windows), mais le rendu ne fait ni très propre ni très sérieux ! Et encore une fois, puisque ce sont eux qui proposent cette directive, cette possibilité d'envoyer un message vers le terminal lors de la compilation, cela devrait fonctionner correctement. Surtout qu'il ne s'agit pas de caractères unicode ésotériques, mais de caractères codables en ISO-8859-1, ce qui, avant l'option -Cu, était le format exigé par défaut.
Mais il a bien raison, il y a d'autres priorités et c'est inutile de se prendre la tête avec un terminal Windows.

Ce que je propose, c'est de formuler autrement le contenu de 'Message' afin qu'il n'y ai plus d'accents, puisque de toute façon dans un source et une console non UTF-8, ils s'affichent mal.

Message "[Compilé avec la version 2.4dev de la bibliothèque francophone.]";

Il faudrait trouver une formule sans accents.

[auraes]

Le patch publié pour 'Entering a closed container ' corrige le problème mais fausse (en inversant) le test de NO_IMPLICIT_ACTIONS : on ne devrait pas pouvoir sortir la pomme du sac et pourtant après le patch c'est possible :

If you define a Constant NO_IMPLICIT_ACTIONS, the library will not attempt to do things that implicitly must be done like taking an object from a sack before dropping it.

Code: Tout sélectionner

Constant NO_IMPLICIT_ACTIONS;
Include "Parser";
Include "VerbLib";

Object room "ROOM"
with description "room" has light;

Object sac "SACK" room
with name 'sack',
has container open;

Object pomme "APPLE" sac
with name 'apple',
has edible;

[ Initialise; location = room; ];
Include "Grammar";


Avant le patch, NO_IMPLICIT_ACTIONS :

Release 1 / Serial number 131228 / Inform v6.33 Library 6/12pre S
ROOM
room
You can see a SACK (in which is an APPLE) here.
> drop apple
Perhaps you should take the APPLE out of the SACK first.

O.K.
Après le patch, NO_IMPLICIT_ACTIONS :

Release 1 / Serial number 131228 / Inform v6.33 Library 6/12pre S
ROOM
room
You can see a SACK (in which is an APPLE) here.
> drop apple
(first taking the APPLE out of the SACK)
Dropped.

Faux.

[auraes]

Avec le nouveau patch cela ne marche toujours pas mais j'ai identifié le problème : c'est l'attribut 'openable' qui pose problème suivant si il est présent ou pas.
Box : avec openable
Box1 : sans openable

Code: Tout sélectionner

!Constant NO_IMPLICIT_ACTIONS;
Include "Parser"; Include "VerbLib"; Include "Grammar";
[ Initialise; location = room; ];

Object room "ROOM" with description "room" has light;

Object box "BOX" room with name 'box',
   has enterable container openable ~open;
   
Object box1 "BOX1" room with name 'box1',
   has enterable container ~open;

Object sac "SACK" room with name 'sack',
   has container open
;

Object pomme "APPLE" sac with name 'apple',
;

Release 1 / Serial number 131229 / Inform v6.33 Library 6/12pre S
! ----------------------------------------------------------------------------
Sans Constant NO_IMPLICIT_ACTIONS && sans patch : WRONG

You can see a BOX (which is closed), a BOX1 (which is closed) and a SACK (in which is an APPLE) here.
> drop apple
(first taking the APPLE out of the SACK)
Dropped.
> enter box1
You can’t get into the closed BOX1.
> enter box
You get into the BOX.

Avec Constant NO_IMPLICIT_ACTIONS && sans patch : O.K.

You can see a BOX (which is closed), a BOX1 (which is closed) and a SACK (in which is an APPLE) here.
> drop apple
Perhaps you should take the APPLE out of the SACK first.
> enter box1
You can’t get into the closed BOX1.
> enter box
You can’t get into the closed BOX.
! ----------------------------------------------------------------------------
Sans Constant NO_IMPLICIT_ACTIONS && avec le dernier patch : WRONG

You can see a BOX (which is closed), a BOX1 (which is closed) and a SACK (in which is an APPLE) here.
> drop apple
(first taking the APPLE out of the SACK)
Dropped.
> enter box1
You get into the BOX1.
It is now pitch dark in here!
> undo
ROOM
[Previous turn undone.]
> enter box
You can’t get into the closed BOX.

Avec Constant NO_IMPLICIT_ACTIONS && avec le dernier patch : WRONG

You can see a BOX (which is closed), a BOX1 (which is closed) and a
SACK (in which is an APPLE) here.
> drop apple
Perhaps you should take the APPLE out of the SACK first.
> enter box1
You get into the BOX1.
It is now pitch dark in here!
> undo
ROOM
[Previous turn undone.]
> enter box
You get into the BOX.
It is now pitch dark in here!

[auraes]

Il manque une espace dans la 6/12 :

Code: Tout sélectionner

Release 1 / Serial number 131229 / Inform v6.33 Library 6/12pre S
Include "Parser"; Include "VerbLib"; Include "Grammar";
[ Initialise; location = room; ];
Object room "ROOM" with description "room" has light;
Object box "BOX" room with name 'box';

ROOM
room
You can see a BOX here.
> exit box
You aren’tin the BOX.

aren’t[]in

[Otto Grimwald]

Je ne sais pas pourquoi ils ont fait ces modifications ni pourquoi ça ne semble pas fonctionner correctement pour vous.

Peut-être que c'est prévu pour fonctionner uniquement avec Inform 7. Il me semble que tous les développements actuellement sont réalisés pour Inform 7, Inform 6 étant utilisé comme outil de transition, uniquement en conjonction avec Inform 7. Donc s'il y a des modifications pour Inform 6, ça sera dans cette optique.

À noter, le déclin d'Inform 6 dans l'ifcomp : http://nitku.net/blog/2012/11/ifdb-stat ... t-systems/

Si vous préférez Inform 6, le mieux serait de rester avec les bibliothèques prévues pour lui, c'est à dire la version 6/11.

Chez moi dans un jeu Inform 7 ça me donne cela :

Code: Tout sélectionner

"test" by "eric"

Hall is a room.

The box is a container in Hall. it is closed. It is enterable.  It is openable.


test
An Interactive Fiction by eric
Release 1 / Serial number 131229 / Inform 7 build 6G60 (I6/v6.32 lib 6/12N) SD

Hall
You can see a box (closed) here.

>enter box
You can't get into the closed box.

>open box
You open the box.

>enter box
You get into the box.

>

Note : je viens d'aller sur le github de David Griffith, je ne sais pas si le but de son travail c'est de fournir des améliorations pour les utilisateurs d'Inform6 ou une base de travail pour Inform 7, en tout cas je vois que c'est encore en développement et qu'il a encore fait des modif il y a 4 heures de ça, donc le mieux c'est de le contacter directement (github propose de faire un clone de la version de dev, de la forker et de proposer ses modifications à l'auteur une fois les corrections faites)

Pour le message de warning de la compilation, effectivement inform6 utilisait encore le vieil encodage iso-8859-1, et maintenant les terminaux utilisent de l'unicode. Si je force mon terminal en iso-8859-1, les accents sont corrects. Si quelqu'un trouve un meilleur message que « Compilé avec la version #### de la bibliothèque francophone. » sans mettre d'accent, on peut le changer, mais ça ne me semble pas très important vu que ça n'impacte pas les joueurs.

[auraes]

En l’occurrence, pour le bogue de l'implicit_taking, si c'est un problème d’algorithme peut importe le langage. D'où l’intérêt de le corriger. Mais là, il patch ! ( Previous fix incorrect. Applied correct fix.) Pas fixé du tout en fait, bien au contraire.
J'ai essayé le coup de la pomme dans le sac sous I7, il se comporte en fait comme avec la librairie 6/11. Ils n'ont pas étendus, pour l'instant, l'implicit_taking. Mais qui c'est si ce n'est pas ce qui est prévu pour la prochaine version d'I7 !

Il manque dans les statistiques, les pays mes surtout les langues des usagés. La langue, c'est quand même là le principale écueil. On verra bien comment se comportera I7.