Discussion :

[gerald3d]

Bonjour.

Une fois n'est pas coutume je viens vers vous vous exposer un problème. Cela fait plus d'une semaine que je m'y casse les dents .

Je suis en train de reprendre mon interface linechec qui est une IHM pour gnuchess. La dernière modification que j'ai apporté à cette application date de 2009 ! Il était donc temps de la dépoussiérer .

Après un passage par la case GTK+ v3... et une interface géré par Glade je remets en service le code d'appel de gnuchess ainsi que le code de communication. Et là, c'est la cata ! Pour faire simple tout le texte envoyé sur stdout par gnuchess n'est pas récupéré pour mon interface.

Pour que vous puissiez peut-être m'apporter une solution voila quelques lignes de code. Pour lancer gnuchess je lance ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

g_spawn_async_with_pipes(NULL, argv, NULL, G_SPAWN_SEARCH_PATH|G_SPAWN_LEAVE_DESCRIPTORS_OPEN, NULL, NULL, &child_pid, &entree, &sortie, &standard_error, &error);

Aucune erreur n'est générée par cette commande. Je déclare dans la foulée les pointeurs giochannel pour chaque canal :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
MainWindow->channel_write = g_io_channel_unix_new (entree);
MainWindow->channel_read = g_io_channel_unix_new (sortie);
MainWindow->channel_error = g_io_channel_unix_new (standard_error);

Puis j'attache chaque canal au callback associé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
g_io_add_watch ((GIOChannel *) MainWindow->channel_read, G_IO_IN|G_IO_PRI, (GIOFunc) readsocket, MainWindow);
g_io_add_watch ((GIOChannel *) MainWindow->channel_error, G_IO_IN, (GIOFunc) readsocket_error, MainWindow);

Une fois toute cette initialisation je suis prêt "à discuter" avec gnuchess. Je lance ma première commande :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
MainWindow->commande = g_strdup ("protover 2");  // Détruit dans writesocket
g_io_add_watch ((GIOChannel *) MainWindow->channel_write, G_IO_OUT, (GIOFunc) writesocket, MainWindow);

gnuchess recoit correctement la commande et me répond. Tout le texte est ici correctement reçu. Voila le callback associé au stdout :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
gboolean readsocket (GIOChannel * giochan, GIOCondition *giocond, GMainWindow *MainWindow)
{
  GString *buffer = g_string_new (NULL);
  GError *error=NULL;
 
  g_io_channel_read_line_string (giochan, buffer, NULL, &error);
  if (error)
    {
      insertion_texte_fen_etat_connexion (MainWindow, error->message);
      g_error_free (error);
 
      g_string_free (buffer, TRUE);
 
      return TRUE;
    }
 
  // Affichage dans le fenêtre console de la communication gnuchess
  lecture_gnuchess_coup (MainWindow, buffer->str);
 
  g_string_free (buffer, TRUE);
 
   return TRUE;
}

Le hic est que dés que je lui envoie une nouvelle commande, gnuchess la recoit, l'exécute correctement mais sa réponse n'est pas totalement reçu par l'interface et la fonction g_io_channel_read_line_string(); dans le callback readsocket(); est bloquante !

Avez-vous une idée sur la question ?

[liberforce]

Salut Gérald,

je n'ai pas trop compris ton problème... Tu restes bloqué dans g_io_channel_read_line_string, ou bien g_io_channel_read_line_string te rend bien la main, mais avec une réponse incomplète ?
Quelle est la chaîne contenue dans buffer dans la réponse ? Et qu'est tu normalement censé obtenir comme réponse ?

Merci et @+

[gerald3d]

Salut Gérald,

je n'ai pas trop compris ton problème... Tu restes bloqué dans g_io_channel_read_line_string, ou bien g_io_channel_read_line_string te rend bien la main, mais avec une réponse incomplète ?
Quelle est la chaîne contenue dans buffer dans la réponse ? Et qu'est tu normalement censé obtenir comme réponse ?

Merci et @+

Effectivement un peu de précision s'impose .

Je confirme que l'application devient bloquante sur g_io_channel_read_line_string();. Je vais donné un exemple. gnuchess lancé en console demande un premier déplacement. Je lui transmets "e4" par exemple. En retour j'ai ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
1. e4
 
black  KQkq  e3
r n b q k b n r 
p p p p p p p p 
. . . . . . . . 
. . . . . . . . 
. . . . P . . . 
. . . . . . . . 
P P P P . P P P 
R N B Q K B N R 
 
Thinking...
 
white  KQkq
r n b q k b . r 
p p p p p p p p 
. . . . . n . . 
. . . . . . . . 
. . . . P . . . 
. . . . . . . . 
P P P P . P P P 
R N B Q K B N R 
 
 
My move is : Nf6
White (2) :

Si je lance gnuchess via linechec le retour de gnuchess pour la même commande s'arrête à l'avant dernière ligne : My move is : Nf6. Je ne récupère pas la dernière ligne "White (2) :" et l'application est bloquée.

[liberforce]

J'ai essayé de récupérer ton code à partir du dépôt git mais il semble que ces modifications n'y sont pas encore. J'ai déjà eu quelques soucis avant cela:

l'application ne compile pas chez moi, à cause de l'ordre de passage des ldflags. Il faut les passer à la fin, comme indiqué dans la doc GTK (pour des raisons de portabilité notamment) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

gcc `pkg-config --cflags gtk+-3.0` -o example-0 example-0.c `pkg-config --libs gtk+-3.0`

(source: https://developer.gnome.org/gtk3/sta...g-started.html )

Ensuite il ne trouvait pas le fichier glade, parce que tu vas le chercher en dur dans /usr/share alors qu'il faudrait prendre en compte le préfixe d'installation passé avec --prefix . Idem pour les ressources jpg, xpm, png. Je ne vais pas te jeter la pierre, j'ai toujours du mal avec les autotools (perso je préfère CMake), mais tu dois pouvoir facilement trouver une appli sur git.gnome.org qui te montrera comment faire.

Enfin, j'ai des erreurs de ce type:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
(linechec:12274): Gtk-WARNING **: Could not find signal handler 'g_annuler_dernier_coup'.  Did you compile with -rdynamic?
 
(linechec:12274): Gtk-WARNING **: Could not find signal handler 'inversion_echiquier'.  Did you compile with -rdynamic?
 
(linechec:12274): Gtk-WARNING **: Could not find signal handler 'g_enregistrement_partie_pgn'.  Did you compile with -rdynamic?
 
(linechec:12274): Gtk-WARNING **: Could not find signal handler 'g_charger_partie'.  Did you compile with -rdynamic?
 
(linechec:12274): Gtk-WARNING **: Could not find signal handler 'g_nouvelle_partie'.  Did you compile with -rdynamic?

Pour ce qui est de ton problème, tu devrais tester la valeur de retour de g_io_channel_read_line_string, qui peut te donner des indications (à moins que tu ne sois bloqué sur le premier appel ?). Si tu met un printf avant et après l'appel à g_io_channel_read_line_string, tu me confirmes bien que tu ne vois pas celui après ? Parce que je ne comprends pas comment tu pourrais lire la string si tu es bloqué là dedans...

[gerald3d]

J'ai essayé de récupérer ton code à partir du dépôt git mais il semble que ces modifications n'y sont pas encore. J'ai déjà eu quelques soucis avant cela:

l'application ne compile pas chez moi, à cause de l'ordre de passage des ldflags. Il faut les passer à la fin, comme indiqué dans la doc GTK (pour des raisons de portabilité notamment) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

gcc `pkg-config --cflags gtk+-3.0` -o example-0 example-0.c `pkg-config --libs gtk+-3.0`

(source: https://developer.gnome.org/gtk3/sta...g-started.html )

Ensuite il ne trouvait pas le fichier glade, parce que tu vas le chercher en dur dans /usr/share alors qu'il faudrait prendre en compte le préfixe d'installation passé avec --prefix . Idem pour les ressources jpg, xpm, png. Je ne vais pas te jeter la pierre, j'ai toujours du mal avec les autotools (perso je préfère CMake), mais tu dois pouvoir facilement trouver une appli sur git.gnome.org qui te montrera comment faire.

Enfin, j'ai des erreurs de ce type:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
(linechec:12274): Gtk-WARNING **: Could not find signal handler 'g_annuler_dernier_coup'.  Did you compile with -rdynamic?
 
(linechec:12274): Gtk-WARNING **: Could not find signal handler 'inversion_echiquier'.  Did you compile with -rdynamic?
 
(linechec:12274): Gtk-WARNING **: Could not find signal handler 'g_enregistrement_partie_pgn'.  Did you compile with -rdynamic?
 
(linechec:12274): Gtk-WARNING **: Could not find signal handler 'g_charger_partie'.  Did you compile with -rdynamic?
 
(linechec:12274): Gtk-WARNING **: Could not find signal handler 'g_nouvelle_partie'.  Did you compile with -rdynamic?

Pour ce qui est de ton problème, tu devrais tester la valeur de retour de g_io_channel_read_line_string, qui peut te donner des indications (à moins que tu ne sois bloqué sur le premier appel ?). Si tu met un printf avant et après l'appel à g_io_channel_read_line_string, tu me confirmes bien que tu ne vois pas celui après ? Parce que je ne comprends pas comment tu pourrais lire la string si tu es bloqué là dedans...

Merci d'avoir tenté de lancer linechec. Même si tu t'es heurté à des difficultés. Je prends note de tes remarques et je rectifierai tous ca dés que mon problème de communication sera résolu.

Je continue donc sur ma lancée. À force de triturer les giochannels j'en suis venu à me dire qu'il fallait que je descende d'un étage. J'ai donc repris les fonctions de la glibc pour tenter une approche plus "bas niveau".

Cette fois-ci les choses se précisent. La problématique vient de la dernière ligne envoyée par gnuchess. Cette ligne est l'attente d'une nouvelle commande. Et c'est là que, quelque soit la fonction de lecture du stdout de gnuchess, la dite fonction bloque. Elle attend une fin de ligne ou une fin de fichier à lire qui ne vient jamais !

Pour illustrer mes dires voila le code source modifié du callback qui est activé lorsqu'il y a quelque chose à lire depuis gnuchess :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
gboolean
readsocket (GIOChannel * giochan, GIOCondition *giocond, GMainWindow *MainWindow)
{
  gint index = 0;
  gint size = 10000;
  g_printerr ("début\n");
  gchar buf[size];
 
  memset (buf, '\0', size);
  gint fd = g_io_channel_unix_get_fd (giochan);
  FILE *stream = fdopen(fd, "r");
 
  while (1)
    {
      buf[index] = fgetc_unlocked(stream);
      g_printerr ("%c", buf[index]);
      if (feof_unlocked(stream)) g_printerr ("fin de la lecture\n");;
      if (index<size) index++;
    }
 
  g_printerr("terminé\n");
 
  fclose (stream);
 
  // Affichage dans le fenêtre console de la communication gnuchess
  g_printerr ("%s", buf);
 
  return TRUE;
}

Voila le résultat en console :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
début
GNU Chess 6.2.2
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
White (1) :

L'application linechec est bloquée par la suite. Par rapport au code le texte "terminé" n'est jamais affiché. Je vous rassure la boucle infinie while(); a déjà été triturée dans tous les sens. Ce n'est pas elle qui tourne en rond. On ne sort pas de la fonction fgets_unblocked(); ! Ce qui me renvoie à la case départ

[liberforce]

Tu pourrais remplacer ta boucle while par ça et me dire ce que ça donne stp ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
int val;
while ((val = fgetc(stream)) != EOF)
{
    buf[index] = (char) val;
    g_printerr ("%c", buf[index]);
    index++;
}

[gerald3d]

Depuis mon dernier post j'ai aussi avancé un peu.

Mon code actuel concernant la boucle while(); :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
while ((buf[index]=fgetc(stream))!=EOF)
{
  if (index<size-1) index++;
}

On peut guère faire plus court. Ceci étant, fgetc(); est aussi bloquant. Je me suis donc dit que le problème ne vient pas de là.

J'ai ajouté cette directive lors de l'initialisation du IOChannel de lecture sans succès :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

g_io_channel_set_flags (MainWindow->channel_read, G_IO_FLAG_NONBLOCK, NULL);

Une fois encore je suis redescendu d'un étage en ajoutant un drapeau directement au descripteur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
	  int flags;
	  flags = fcntl(sortie, F_GETFL, 0);
	  flags |= O_NONBLOCK;
	  fcntl(sortie, F_SETFL, flags);

sortie est le descripteur renvoyé par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

g_spawn_async_with_pipes(NULL, argv, NULL, G_SPAWN_SEARCH_PATH|G_SPAWN_LEAVE_DESCRIPTORS_OPEN, NULL, NULL, &child_pid, &entree, &sortie, &standard_error, &error);

Et là, MIRACLE , les fonctions de lecture ne sont plus bloquantes. J'en déduis qu'il y a un petit souci du côté de la GLib.

Maintenant, je passe à un deuxième problème. Il manque des morceaux dans le texte reçu. Je travaille encore la question...

[gerald3d]

Finalement, après s'être casser le crâne sur ce problème de communication, j'ai enfin résolu le souci. Pour être tout à fait honnête avec vous, pas tout à fait. J'ai emprunté un chemin de traverse pour arriver à mes fins . Je vous explique.

Si vous voulez interagir avec une application en console et que cette application dispose d'un prompt, alors oui la GLib pose un petit problème. Les différentes fonctions de lecture d'un flux avec les GIOChannel sont bloquantes. Il faut explicitement placer le drapeau O_NONBLOCK sur le descripteur considéré. Je vous redonne le code exemple pour résumer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
g_spawn_async_with_pipes(NULL, argv, NULL, G_SPAWN_SEARCH_PATH|G_SPAWN_LEAVE_DESCRIPTORS_OPEN, NULL, NULL, &child_pid, &entree, &sortie, &standard_error, &error);
 
int flags;
flags = fcntl(sortie, F_GETFL, 0);
flags |= O_NONBLOCK;
fcntl(sortie, F_SETFL, flags);

Ainsi fait, les g_io_channel_read_chars();, g_io_channel_read_line(); et g_io_channel_read_line_string(); ne sont plus bloquantes.

Cependant, les temps d'exécution de la boucle principale de Gtk font qu'il arrive de perdre certaines lignes transmises par l'application console. Je n'ai pas, à cette heure, trouvé la parade. Je pressens qu'il faille passer par des threads. Et là on entre dans un monde problème .

Quelle est donc ma parade ?

Gnuchess dispose d'un mode d'utilisation en tant que moteur de jeu. Il suffit de lui passer la commande "xboard" pour que le prompt disparaisse. À partir de là, j'ai pu utilisé sans aucun problème les GIOChannel dans leur ensemble sans être obligé de programmer dans un plus bas niveau.

En espérant que ce post puisse apporter un peu d'aide à d'autres...

P.S. : merci à toi, Liberforce, pour le temps pris à essayer de m'aider.

[liberforce]

Hello,

bon, je comptais te dire de regarder vers le bloquant/non-bloquant par la suite, mais on en est pas arrivés là :p.

Je voulais avant être sûr que tes test pour vérifier que tu était à la fin du fichier étaient corrects.

Par exemple dans le code que tu donnes, il y a un soucis:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
while ((buf[index]=fgetc(stream))!=EOF)
{
  if (index<size-1) index++;
}

fgetc retourne un int, car il doit renvoyer 256 valeurs (les différentes caractères possibles) + un 257ème caractère pour EOF. EOF vaut -1.
Extrait de stdio.h:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
/* End of file character.
   Some things throughout the library rely on this being -1.  */
#ifndef EOF
# define EOF (-1)
#endif

Si ton caractère lu vaut 255 (0xFF), tu risques de le confondre avec un EOF (0xFFFFFFFF si tu compiles en 32 bits), c'est pour cela qu'il ne faut pas tronquer la valeur renvoyée par fgetc. Là dans ta boucle tu mets la valeur renvoyée dans buf qui est un tableau de char, et tu tronques ainsi la valeur.

Pour l'appel à g_io_channel_set_flags (MainWindow->channel_read, G_IO_FLAG_NONBLOCK, NULL), je pense que c'est la bonne chose à faire. Au lieu de NULL, passe un GError ** pour récupérer un message d'erreur qui te dira pourquoi ça ne marche pas.

@+

[gerald3d]

Très bonne remarque pour le type du buffer qui reçoit l'information . Le problème du contenu pas complet provenait peut être bien de là.

Ceci étant je disposais bien de la première ligne ainsi que de la dernière.

Enfin, depuis que gnuchess ne présente plus le prompt tout est rentré dans l'ordre. Linechec peut maintenant jouer contre gnuchess .

Encore merci pour ton aide.