Re: Rep:Re: [Maitretarot-devel-fr] le client fonctionne :)

[address@hidden]

> "address@hidden"<address@hidden> writes:
>
> > > "address@hidden"<address@hidden>
writes:
> > >
> > > > > "address@hidden"<address@hidden>
> > > > writes:
> > > > >
> > > > > > >
"address@hidden"<address@hidden>
> > > > > > writes:
> > > > > > >
> > > > > > > > En gros, c'est ca.
> > > > > > > > man select
> > > > > > > > man poll
> > > > > > > >
> > > > > > > > Moi, je suis pour select. Poll est sympa
aussi
> > > > mais
> > > > > > est
> > > > > > > > moins portable (ca march sur solaris quand
meme).
> > > > > > select
> > > > > > > > est pas posix mais est super portable.
pselect
> > > > est
> > > > > > posix,
> > > > > > > > mais c'est pas sur solaris2.6.
> > > > > > > > Bref, je prefere select.
> > > > > > > >
> > > > > > > > A moins qu'on n'utilise le read non bloquand?
> > > > > > > >
> > > > > > > >
> > > > > > > le principe (si j'ai bien compris) de select
c'est
> > > > de
> > > > > > regarder
> > > > > > > une entree pendant n secondes et au bout de se
> > > > temps de
> > > > > > dire
> > > > > > > s'il y a des donnees sur l'entree ou non.
> > > > > > > => ca permet de faire une boucle en
attendant qu'il
> > > > y
> > > > > > ait des
> > > > > > > donnees et de les traiter en fonction du canal.
> > > > > >
> > > > > > Exact!
> > > > > >
> > > > > > >
> > > > > > > Pour poll, ca me semble un peu plus
compliquer (je
> > > > n'y
> > > > > > ai pas
> > > > > > > trop regarde).
> > > > > >
> > > > > > Poll semble un peu plus complique, mais ca
n'est pas
> > > > plus
> > > > > > complique. Simplement, faut faire le malloc du
> > > > tableau a
> > > > > > fournir en argument a poll. C'est ce malloc qui
> > > > semble
> > > > > > plus complique.
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Donc, moi ca me va. A moins qu'il y est des
> > > > arguments
> > > > > > plus
> > > > > > > convainquant pour le read non bloquant.
> > > > > >
> > > > > > read non bloquant: plus simple a faire, et ca
bouffe
> > > > pas
> > > > > > de memoire ni de cpu. Bref, mieux: on a besoin
d'une
> > > > > > seule ligne de code pour ca.
> > > > > >
> > > > > > A mon avis, faut voir le besoin reel, et coder en
> > > > > > fonction quand on en aura besoin.
> > > > > >
> > > > > Ok, enfin pour l'instant ce qui serai bien c'est
qu'on
> > > > fasse
> > > > > une partie complete (blindage su serveur, fin du
client)
> > > > > Et on pourra voir ce qu'on fait apres (IA, chat...)
> > > > >
> > > > > D'ailleurs, le chat on peut le mettre dans la
version 2
> > > > plutot
> > > > > que dans la 1 non ?
> > > >
> > > > Non, enfin pas tout a fait.
> > > > Le protocole doit etre pret pour le chat, meme si
le chat
> > > > lui-meme n'est pas implemente. Sinon, on va se
retrouver
> > > > avec des versions incompatibles de maitretarot et de
> > > > clients!
> > > >
> > > bon, et bien alors on peut modifier le protocle en
disant
> > > que, chaque fois qu'on envoie un ou une serie de
gint, avant
> > > on rajoute un gint (le canal) pour savoir a qui
s'adresse
> > > les gint (jeu ou chat).
> >
> > Oui.
> >
> > >
> > > Puis on modifie les fonctions read_data/write_data pour
> > quelles
> > > lisent/envoient un gint (le canal) avant de lire/envoyer
> > la serie
> > > de gint (le jeu).
> > > Ces nouvelles fonctions read_data et write_data
peuvent etre
> > > des intermediaires:
> > > On peut avoir un truc du style:
> > >
> > > read/write => lit/ecrit des gint
> > >                 (tres general: read_data/write_data
actuel)
> > >
> > > read_data/write_data => read/write ([canal+data],
> > size(canal+data))
> > >
> > > utilisation_des_donnes => canal=-1: pas de donnee
> > >                           canal=0: le jeu -> data=les
> > cartes, le chien...
> > >                           canal=1: le chat -> data=la
> > chaine du chat
> > >
> > >
> > > le fonctions read/write corresponde aux fonctions
read_data
> > > et write_data actuelles mais en non bloquantes.
> > >
> > > l'utilisation des donnees (pour la lecture) fait une
boucle
> > > tant que canal=-1 (pas de donnes), affiche le chat
quand
> > > canal=1 ou sort quand canal=0 (le jeu) et traite les
datas
> > > comme le protocole actuel.
> >
> > Deja, on ne touche pas a read_data et write_data.
> > On fait d'autres fonctions. Ca revient a ce que tu disais,
> > sauf qu'il faudra trouver d'autres noms. C'est juste de la
> > semantique.
> > read_data et write_data seront donc nos fonctions de plus
> > bas niveau. Il faudra juste les modifier pour les sockets
> > non bloquantes: verifier que ca ne plante pas.
> >
> > Ensuite, je suis d'avis qu'on fasse nos trucs dans nos
> > coin, tout en nous concertant. Ainsi, on aura des
> > fonctions qui correspondent a nos besoins. Et un jour (le
> > plus tot possible quand meme), on met les trucs communs
> > dans libmaitretarot. Exactement ce qu'on a fait avec
> > read_data.
> >
> tout a fait, je n'avai pas trop d'inspiration pour les
> fonctions (read et write c'est deja pris, mais ca montre
> le bas niveau). un truc du genre: read_data/write_data,
> read_canal_data/write_canal_data ca va ? (ou chanel pour
> la convention anglaise).
>

chanel_read_data?

Bah on va prendre un truc comme ca. De toute facon, apres,
y'a encore le prototype a decider.
Cree ta fonction comme bon te semble.
Je ferai la mienne. Et bien evidemment, autorisation de se
pomper l'un l'autre!
Et quand on aura un truc qui marche, on regardera nos
prototypes et on en prendra un bien. Pense juste a
utiliser GError pour la gestion des erreurs si l'erreur ne
se limite pas a "ca a marche/ca n'a pas marche".

> > >
> > >
> > > voila, je crois que c'est une solution possible.
> >
> > Oui.
> >
> > De mon cote, j'ai un week-end a rien faire (juste passer
> > chez le coiffeur et faire les courses).
> >
> > Vu le temps, je pense que je vais faire 50% de
> > maitretarot, 50% a me faire une distrib sur disquette
> > (c'est mon nouveau data) et 50% a rien faire. Plus 50% a
> > mater l'un ou l'autre dvd.
> > Donc des qu'il y a de l'activite sur la ml de maitretarot,
> > je fais du maitretarot.
> >
> Ouais, moi j'ai des paquets de copies a corriger (pt1 de
> devoir commun), mais sinon je pense que je trouverai le
> temps de finir le client (faire une partie complete).
>
> Ensuite j'aimerai bien mettre en place la partie commune
> pour la communication client/serveur et faire l'IA de
> base (qui dependra de la partie commune).
> Ensuite passer a glib-2.0, faire le chat...
> (ca ressemble a un TODO ca !)

Oui.
Bah moi, je verrai ma motivation. Peut-etre que je ferai
un fork de maitretarot pour ajouter le gint et changer le
protcole comme on a dit. Et aussi ajouter les encheres.
Ce sera un fork, donc je ne ferai pas de commit sur le cvs
actuel. Au pire, je creerai une nouvelle branche.

>
>
> > Au fait, on n'a plus de nouvelles de Guillaume?
> >
> oui, c'est vrai ca, Guillaume t'es OU ???

Guillooooooooooooooooooooooooooooooooooaume!

Yves
--
homepage - http://ymettier.free.fr                   -
gtktalog - http://www.freesoftware.fsf.org/gtktalog  -
cardpics - http://www.freesoftware.fsf.org/cardpics/ -

--------------
Profitez des 2 offres exceptionnelles Tiscali !
"Internet Gratuit le Jour" et "Modem ADSL remboursé"
Cliquez ici, http://register.tiscali.fr/forfaits_ls/
Offres soumises à conditions.