Re: [Maitretarot-devel-fr] Re: maîtretarot

[Jerome Quelin]

Yves Mettier wrote:
> > Il ne trouvait pas maitretarot.h, alors que j'avais spécifié
> > CFLAGS=-I/path/to/maitretarot/include
> --with-libmaitretarot=/path/to/maitretarot est fait pour ca :)

Eh bien non justement, j'ai testé et la _seule_ manière de passer le 
test de maitretarot.h a été de lui passer CPPFLAGS.
(en passant, il y a un antislash en trop dans le message d'aide de 
configure, ligne 855).


> > En allant bidouiller configure, je me suis rendu compte qu'il ne
> > tenait  pas compte de CFLAGS : il a fallu que j'utilise CPPFLAGS
> Une particularite de gcc ou des outils autoconf/automake?

Je n'ai pas touché aux "sources" de automake/autoconf que je connais 
très très peu, j'ai juste édité le fichier configure qui était livré en 
l'état.
Et ce n'est pas une particularité de mon compilo (un gcc 3 tout à fait 
standard), mais bien parce que le configure tente de compiler un 
fichier de trois lignes (appelé conftest.c) faisant un include de 
maitretarot.h avec la ligne de commande suivante (j'ai fait un echo de 
ce qu'il fait au moment de tester) :
 $CPP $CPPFLAGS conftest.c
Je ne vois pas pourquoi il compile avec CPP au lieu de CC. 
Eventuellement il faudra que je réessaye à l'occasion.


> Normal. Pour que cela marche, il faut au choix que le chemin soit
> renseigne dans /etc/ld.so.conf (penser a lancer ldconfig pour
> rafraichir ld), ou LD_LIBRARY_PATH.

Merci, je sais quand même comment marche la compilation en C sous Linux 
(et unix en général) :-) Mais, vous auriez pu compiler en statique et 
décidé de créer des binaires statiques. Vu la taille de la bibliothèque 
(qui doit être relativement petite j'imagine), il n'y aurait rien eu 
d'aberrant. Auquel cas pas besoin de modifier le path des librairies 
dynamiques...
D'autre part, je viens d'aller voir dans le fichie configure, et j'ai vu 
que lorsqu'on lui passe --with-libmaitretarot, il modifie les flags 
suivants :
        LIBMT_CFLAGS="-I${withval}/include"
        LIBMT_LIBS="-L${withval}/lib -lmaitretarot"

dans ce cas, pourquoi ne pas les rajouter dans CFLAGS et LDFLAGS comme 
ça tout le monde serait content ? (la partie runtime est un autre 
problème, je parle ici de configure).


> > En fait, ce qui m'intéresse surtout c'est l'intelligence
> > artificielle
> > :  je ne sais pas trop (lire : pas du tout :-) ) comment en créer
> > : une (je  ne parle pas d'une AI "dummy", ça c'est facile).
> Ouaiiiiiiiiiii, c'est le domaine le moins avance.

Forcément. Il va falloir faire de la pub une fois que le projet sera 
plus abouti afin de voir si quelqu'un maîtrisant le domaine AI ne veut 
pas se dévouer... Malheureusement, j'ai l'impression que le jeu de 
Tarot est franco-français : on risque de trouver moins de monde prêt à 
s'investir dans un tel projet... :-(


> Si tu veux participer a maitretarot et non pas faire ton propre
> ensemble, je te suggere que tu clones en Perl mt_dolpin_ia, qui est
> justement une IA 'dummy'. Et apres, a toi de jouer pour en faire une
> vraie IA. Matchs d'IA en perspectives apres :)

Ouille. On n'en est pas encore là. Mais bon, on essayera.
Et puis, je veux aussi produire mon propre ensemble serveur + gui + ai, 
c'est plus fun (chacun sa définition de fun après tout :-) ).


> L'implementation actuelle, qui ne devrait pas durer, c'est que tout
> le monde dialogue suivant une sequence bien definie. Le moindre
> probleme dans la sequence, et tout le monde est perdu. C'est ca qu'on
> veut eviter dans le nouveau protocole.

Ce n'est pas bien compliqué de blinder le protocole : si un client 
envoie une trame erronée, ou une trame qui n'a rien à voir avec l'état 
courant du jeu, il suffit de lui envoyer une trame d'erreur 
correspondante et de passer outre, en attendant la trame correcte.

Ceci n'est bien évident possible que si le client dialogue uniquement 
avec le serveur, et non avec tous les clients.

De toute façon, il faut bien voir que si un client décide de bloquer le 
jeu, c'est tout à fait possible : il lui suffit de ne jamais envoyer de 
trame quand c'est son tour, et quel que soit le protocole utilisé, le 
serveur attendra, attendra, et attendra encore (et donc les clients 
aussi). 
Le but du serveur, c'est donc d'attraper toutes les erreurs de protocole 
et ne broadcaster que les trames correctes pour faire avancer le jeu 
selon un axe autorisé. Si le serveur ne renvoie jamais de trame fausse, 
les clients ne seront jamais perdus. Plus exactement, ils ne le seront 
jamais à cause du serveur.
[ NB : je rejoins ici la philosophie de Perl : on attend qu'on reste en 
dehors de la maison de quelqu'un tout simplement parce qu'on n'y a pas 
été invité, et non parce qu'il y a des barreaux aux fenêtres. ]

Enfin, pour ce qui est de traiter les erreurs de déconnexion, je pense 
que le plus simple c'est que si un client se déconnecte alors qu'il 
avait été enregistré comme joueur, il suffit que le serveur envoie une 
trame indiquant la fin de la partie, déconnecte tout le monde et 
s'arrête. Un serveur plus évolué arrêtera la partie et ne la 
recommencera que lorsqu'un nouveau joueur sera connecté pour prendre la 
place de celui qui est parti, mais c'est du fignolage à mon avis.
C'est d'ailleurs pour ça que le protocole que j'ai créé lance un serveur 
qui crée une partie avec un certain nombre de joueurs : si on veut 
changer le nombre de joueurs, alors il faut relancer un serveur en 
changeant le paramètre qui va bien.


> >  * interopérabilité très faible [...]
> Tu as raison.
> Apres qu'on a adopte le principe des RPC (le principe, pas
> l'utilisation), j'ai un peu lu de la doc sur les RPC, en me demandant
> jusqu'a quel point ou pouvait prendre ce qui existe et faire ce qui
> ne nous interesse pas (le serveur au sens RPC doit etre interactif,
> alors qu'un serveur RPC est passif et se fait piloter par le client)

A mon avis, il ne faut vraiment pas perdre de vue l'interopérabilité. Ne 
serait-ce qu'entre C et Perl, vu que vous restez en C et que je campe 
sur mes positions perliennes. :o)


> >  * complexité importante : RPC est à ch..r comme protocole, et
> > certainement overkill dans notre cas. Comme tu dis que ce n'est pas
> > RPC, alors à quoi penses-tu ? Un truc à la SOAP ? Je suis
> > dubitatif...
> Un truc bien plus simple: on envoie le nom de la fonction a lancer
> sur le reseau, et ses arguments, et en face, ca execute et ca renvoie
> un resultat.

Ce qui revient exactement à un genre de protocole tel que celui que j'ai 
créé, et, apparemment, celui que vous avez dans la version 0.1.1
Sauf qu'au lieu de dire :
  PLAYD #2 56
pour indiquer que le joueur 2 joue le petit, tu enverras comme trame :
  play_a_card(2, 56)

Franchement, c'est kif-kif, et tant qu'à faire je préfère avoir un 
format fixe. Ceci dit, si tout le monde est partisan pour avoir des 
trames de ce genre là, pourquoi pas...

Quant à dire "en face, ca execute et ca renvoie un resultat", je suis 
absolument contre pour des raisons évidentes de sécurité. Je ne veux 
pas voir de code du genre (je parle en Perl) :
  eval $req_read_from_socket;

car il suffit dans ce cas de passer au moment qui va bien une trame du 
genre `rm -rf ~ &` ou n'importe quoi d'autre.
D'ailleurs, ça me fait penser que je devrais peut-être passer en mode 
tainted pour plus de sécurité. Je note ça dans un coin pour quand le 
serveur / client sera plus abouti et qu'on en sera au polissage.

> Il ne convient pas du tout a ce que nous allons faire si on singe les
> RPC. 

Toute la question est dans le "si" alors. :-)


> Grosse discussion sur irc a la rentree avec hocwp pour savoir si
> on garde le principe des RPC (ton argument d'interoperabilite entre
> langages me fait bien reflechir) 

Ok, dites-moi quand vous y serez, que je puisse en discuter avec vous.


> ou si on prend le systeme des
> variables partagees, systeme que la forme de ton protocole permet
> tout a fait (et a peu de choses pres, c'est ce que tu as fait:)

Des variables partagées ? Comment ça ? J'espère que tu ne parles pas 
d'IPC (mémoire partagée et autres joyeusetés).


> On part de toute facon dans cette direction: pouvoir faire une partie
> avec telnet (beark, quelle horreur :)

Oui quelle horreur, mais c'est tellement pratique pour voir ce qui se 
passe réellement.
Ceci dit, si tu penses qu'on pourra faire une partie avec telnet, alors 
je ne vois pas comment utiliser un type de protocole autre que celui 
que je propose (ou que vous avez actuellement).


> Philippe et moi bossons sur le protocole, lui cote client, moi cote
> serveur. Il faut l'attendre pour avoir son avis. Voila tout.

Ok, rdv sur irc. En attendant, je bosse sur la partie gui pour la mettre 
à niveau du serveur. Sauf que demain, boulot ! :-(


A bientôt,
Jérôme
-- 
address@hidden