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

[Yves Mettier]

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

Tiens, comme moi.
Merci guillaume :)

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

--with-libmaitretarot=/path/to/maitretarot est fait pour ca :)

> 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?

> 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 !

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.

> 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

Bizarre.
La ligne CPPFLAGS ne devrait pas etre.
Pour LD_LIBRARY_PATH, elle ne devrait pas etre la seulement pour la
compilation mais aussi pour le lancement.

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

A priori, si tu arrives pas a te passer de CPPFLAGS, ca nous interesse
-> y'a un pb. Pour le reste, non, c'est normal, c'est comme ca, c'est
GNU/Linux qui veut ca.

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

Ouaiiiiiiiiiii, c'est le domaine le moins avance.
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 :)

>
>
>> 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" ?

Phase de reflexion.
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.

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

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)

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


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

M'a l'air pas mal du tout dans la forme, ton protocole.
Dans le fond, c'est ce que nous avons actuellement dans les versions 0.1.x

Il ne convient pas du tout a ce que nous allons faire si on singe les RPC.
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) 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:)

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

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

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

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

Yves

-- 
- Homepage - http://ymettier.free.fr - http://www.cmg.com -
- GPG key  - http://ymettier.free.fr/gpg.txt              -
- MyAM     - http://www.freesoftware.fsf.org/myam         -
- GTKtalog - http://www.freesoftware.fsf.org/gtktalog     -