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

[Jerome Quelin]

Yves Mettier wrote:
> Je renvoie le message, CC la mailing list.

Je me suis abonné, ce sera plus simple.


> Je coordonne aussi le projet cardpics, pour si t'as besoin d'images
> pour les cartes. Les atouts sont a ameliorer, mais sont deja tout a
> fait utilisables.

J'ai déjà vu, récupéré, et apprécié à sa juste valeur, car ce genre de 
choses est largement au-dessus de mes capacités, mes dons artistiques 
étant proches de zéro. :-)


> A mon avis, c'est plutot que tu n'as pas installe libxml2-devel
> libglib2-devel ou un truc comme ca.

En effet, je n'avais pas libglib2-devel. Mais le message d'erreur 
n'était vraiment pas explicite. Bon enfin, libmaitretarot compile sans 
problème, mais maitretarot a du mal car j'ai installé avec un prefix 
non standard.
Il ne trouvait pas maitretarot.h, alors que j'avais spécifié 
CFLAGS=-I/path/to/maitretarot/include
En allant bidouiller configure, je me suis rendu compte qu'il ne tenait 
pas compte de CFLAGS : il a fallu que j'utilise CPPFLAGS
Bon, avec ça j'ai réussi à passer maitretarot.h, ensuite il tente de 
trouver libmaitretarot. 
LDFLAGS=-L/path/to/maitretarot/lib est ignoré, 
--with-libmaitretarot=/path/to/maitretarot (ou /p/t/m/lib) aussi, 
heureusement LD_LIBRARY_PATH est pris en compte ! 
La ligne de commande est donc :
$ ./configure --prefix=/home/jquelin/games/maitretarot-0.1.1 
--with-libmaitretarot=/home/jquelin/games/maitretarot-0.1.1 
CPPFLAGS=-I/home/jquelin/games/maitretarot-0.1.1/include 
LD_LIBRARY_PATH=/home/jquelin/games/maitretarot-0.1.1/lib

Honnêtement, je pense qu'il y a un (plusieurs) problèmes. Mais à la 
rigueur c'est le vôtre ! :-)


> Pour l'instant, tu as la meme demarche de reflexion que nous.

Bien, c'est toujours rassurant de se fondre dans la masse... :o)


> C'est surtout que ca va te permettre de te concentrer sur le serveur
> et utiliser les clients de maitretarot pour tester. Ou l'inverse,
> developper ton client en Perl en utilisant le serveur de maitretarot!
> De notre cote, ca nous permettra de gagner en solidite, tout comme
> toi d'ailleurs!

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).


> On est en train de repartir a zero au niveau du protocole. Donc ca
> tombe a point, ton protocole.
> Pour l'instant, nous sommes parti sur une idee de protocole similaire
> aux RPC (mais on n'utilise pas les RPC). 

Quand tu dis "pour l'instant", c'est "pour l'instant tel que c'est 
implémenté" ou "pour l'instant dans notre nouvelle phase de reflexion 
de protocole" ?


> En d'autres termes, chaque
> client doit mettre des procedures a disposition du serveur, et le
> serveur execute ces procedures a distance. Par exemple, le serveur
> executera jouer_une_carte() sur le client a qui c'est de jouer.

Je ne suis pas sûr que ce soit top comme approche. Et j'argumente :
 * interopérabilité très faible : si tu codes ça en C, alors je vois mal 
d'autres clients utiliser d'autres langages. Je pense en particulier au 
Lisp et autre langages fonctionnels qui peuvent être pressentis par 
d'autres personnes qui auront envie de développer une AI (on peut 
toujours rêver ! :-) ).
 * 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...

Par contre, je suis d'accord que le serveur doit être à la base de toute 
action : un client qui veut jouer la carte "10 de coeur" doit signaler 
au serveur "je veux jouer la carte 10 de coeur" et c'est le serveur qui 
doit signaler aux clients, _y compris le client qui joue la carte_, que 
le client numéro x a joué la carte 10 de coeur.
Le protocole que j'ai pondu est fidèle à cette vision.

Comme ta réponse est arrivée seulement ce soir, j'ai continué de 
développer / implémenter mon protocole aujourd'hui. Le protocole (et le 
module serveur) supporte(nt) à présent tout ce qui va de la connexion 
aux annonces et à la confection du chien. Et surtout, il est 
ultra-simple à implémenter pour les clients : une simple connexion tcp 
et zou. D'ailleurs, le débugage de mon serveur a été facile, vu qu'un 
simple client telnet me permettait de tester la chose en passant mes 
commandes live.

En fait, je me suis basé sur le protocole SMTP, qui a des commandes en 4 
lettres et renvoie des codes selon les commandes et leur résultat. Sauf 
qu'ici, j'ai pris des commandes de 5 lettres, et les codes sont aussi 
des identifiants de 5 lettres.
Du fait de la simplicité du protocole (et de la puissance de Perl - pub 
gratuite :-) ), j'ai donc pu coder le serveur jusqu'au début du jeu de 
la carte. Je tiens le début du module Perl à votre disposition si vous 
êtes intéressés, de même que la version modifiée du protocole (en 
implémentant les commandes, j'ai vu qu'il fallait rajouter des messages 
d'erreur afin que les clients ne foutent pas la grouille dans le 
serveur, et puis j'ai modifié une ou deux réponses à des commandes).


> Et on a tout interet a avoir un protocole commun, je le repete, pour
> t'eviter d'avoir a developper en meme temps le serveur et les clients
> (graphique et IA), et pour tout le monde pour une meilleure
> robustesse de l'ensemble.

Je suis d'accord, mais je tiens à répéter : le protocole le plus simple 
possible. Et permettant l'interopérabilité avec des clients (ou des 
serveurs) écrits dans d'autres langages. Et je tiens vraiment à pouvoir 
débugger avec un simple client telnet (car c'est difficile de faire 
plus simple) !


> Et nous, on a #maitretarot sur freenode.net (paske openprojects.net
> est devenu freenode.net :)
> Viens plutot sur le chan dedie :)

C'est fait, j'y suis dorénavant.


> Par contre, comme je l'ai dit avant, attend la fin des vacances de
> Noel, qu'on soient tous revenus chez nous.

Ah bon. Moi après les vacances j'aurais moins de temps. Bon, j'aurais 
toujours les soirs et week-ends... En attendant, je vais voir si je 
continue à développer mon serveur...


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