Re: [Maitretarot-devel-fr] glib2; fichier de configuration; autoconf-2.5 et maitretarot

[philippe brochard]

Yves Mettier <address@hidden> writes:

> > > [...]
> > > 
> > > > > > 
> > > > > > Une question, la 2.13 et la 2.5 sont vraiment incompatible ?
> > > > > 
> > > > > La meilleure comparaison que je puisse faire est celle avec MS Word, 
> > > > > versions 95 et 97 (je les connais un peu, mais pas beaucoup).
> > > > > C'est compatible, mais quand on cherche a passer de l'un a l'autre, 
> > > > > on se rend compte a quel point c'est pas tout a fait compatible.
> > > > > Bref, le choix de Mandrake est pas mal: ils gardent les deux.
> > > > > 
> > > > Ouais, ça c'est un truc qui m'enerve prodigieusement, le fait de 
> > > > programmer
> > > > sans pouvoir garder la compatibilité avec les anciennes versions. Ca 
> > > > pousse
> > > > tout le monde à une course à l'échalote qui n'est pas toujours 
> > > > (rarement)
> > > > justifiée.
> > > 
> > > Faut que ca se justifie.
> > > habituellement passer d'une version d'un soft a une version superieure se 
> > > justifie par le fait que la precedente version est rendue obsolete par la 
> > > nouvelle. Et la compatibilite ascendente facilite un passage massif des 
> > > applis vers le nouveau systeme. Pour glib-2.0, c'est a mon avis le cas.
> > > La ou ca se corse, c'est quand il n'y a pas une vraie compatibilite 
> > > ascendente, ou quand la migration est compliquee, ou encore quand la 
> > > migration necessite de nouveaux outils. Avec autoconf, c'est le cas.
> > > 
> > > Enfin c'est mon avis, et rien n'empeche qu'on l'affine si on en discute 
> > > ;-)
> > > 
> > Ben, ce qui m'embête en general quand on perd la compatibilite c'est que le
> > nouveau soft est peut être très bien mais c'est dommage de laisser sur le
> > carreau un certain nombre d'utilisateurs / de machines. Bon, ils peuvent
> > faires l'efforts de passer à la version suivante, ici pour la glib ça ne
> > coute rien et ça devrai marcher partout. Mais si on est obligé de casser
> > tout le systeme ou d'en changer carrement juste pour 2/3 fonctionnalités
> > en plus, je trouve ça dommage.
> > Enfin bon, le pire dans le genre, c'est Microsoft (et certains autres) avec
> > leurs programmes de plus en plus lourd, où si tu veux les faires tourner ils
> > faut des machines de plus en plus puissantes et bien evidement les nouvelles
> > versions ne sont pas compatibles avec les anciennes -> pour être à jour il
> > faut changer de machine. Et ce principe marketing à tendance à fortement
> > m'enerver :)
> 
> 
> Par experience, je sais que quand c'est des libs uniques, y'a habituellement 
> pas de probleme a forcer l'utilisateur a upgrader. glib est dans ce cas parce 
> que glib n'a pas de dependances.
> Citons quelques cas ou c'est pas aussi simple:
> gnome
> glibc (qui se souvient du passage de libc5 a glibc?)
> le format de binaires (a.out vers elf)
> 
> Dans les cas precedents, la periode de transition a toujours ete longue et 
> embetante. Pourtant, on y gagne plutot beaucoup au changement!
> Bref, pour des changements majeurs et lourds, il faut quand meme les faire, 
> mais bien y reflechir avant.
> 
> Et puis y'a toujours des changements majeurs de libs ou progs mineurs, qui 
> ennuient beaucoup quelques utilisateurs pour pas grand chose. La, bof. C'est 
> nul. Et c'est d'ailleurs pour ca que tant que maitretarot est en 
> developpement, utilisons les libs qu'on utilisera encore quand maitretarot 
> sera dispo pour les utilisateurs (ou comment je me justifie de vouloir 
> glib-2.0 alors que je me suis deja justifie n fois ;-)
> 
Oui, ici ça ce justifie effectivement, quand maitretarot sera sortie les
anciennes glibs seront sans doute vraiment obsolete (cf t'as justification
precedente).

En plus, je vient de tester un peu, la glib ne depend d'aucune autre lib 
(comme tu le dis) et s'installe sans problème avec un utilisateur lambda.
Donc le changement transitoir n'est pas trop génant et quand elle sera
à jour dans toutes les distribs, il n'y aura plus de problèmes.

Donc, plus la peine de justification, on passe a la glib-2.0.
A moins que tu es encore un argument en sa faveur ;-)

> 
> > 
> > > > 
> > > > > > 
> > > > > > > - La bibliotheque de fonctions de maitretarot: on aura 
> > > > > > > config_utils.* et net.* dedans, et maitretarot.h pour le fichier 
> > > > > > > d'en-tete. Je pense que personne n'y verra d'inconvenient. Par 
> > > > > > > contre, au niveau des fonctions, il est imperatif de mettre un 
> > > > > > > prefix devant chaque fonction. Je propose "mt_". Mais je ne sais 
> > > > > > > pas si ce prefixe a deja ete utilise dans mt_ncurses_client ou 
> > > > > > > mt_dolphin_ia. Est_ce que je peux utilise "mt_" ou dois-je 
> > > > > > > prendre autre chose? Ainsi, "read_data()" deviendrait 
> > > > > > > "mt_read_data".
> > > > > > > 
> > > > > > Oui, très bonne idée le mt_, mt_ncurses_client et mt_dolphin_ia ne 
> > > > > > l'utilise pas.
> > > > > > A vrai dire, il n'y a pas de prefixes du tout, il faut en mettre 
> > > > > > même si ce
> > > > > > sont des fonctions "locales à mt_dolphin_ia et mt_ncurses_client" ?
> > > > > 
> > > > > Pour les fonctions locales, y'a a mon avis deux cas: soit elles sont 
> > > > > vraiment locales, et dans ce cas, pas besoin d'en mettre. Soit elles 
> > > > > sont locales mais susceptibles d'etre reutilisees ailleurs, alors il 
> > > > > vaut mieux mettre un prefixe.
> > > > > 
> > > > > D'ailleurs, je viens de changer d'avis. Pour la lib, ce ne sera pas 
> > > > > mt_, mais libmt_ ou mtlib_.
> > > > > Je prefere libmt_. Qui vote pour quoi?
> > > > > 
> > > > ouais, libmt_ c'est mieux (respect du standard des notations (cf 
> > > > /usr/lib)).
> > > 
> > > Arf, aucun rapport avec /usr/lib.
> > > La lib s'appellera libmaitretarot.so a moins que quelqu'un ait une 
> > > meilleure idee.
> > > Ce sont les fonctions qui s'apppelleront libmt_trucmuche().
> > > Et la, c'est pour que quand on appelle une fonction qui commence par 
> > > libmt_, on sache d'ou elle vient. Tout comme les fonction commencant par 
> > > gtk_ viennent de libgtk, ou celles commencant par g_ viennent de glib.
> > > Et ca me lourde d'ecrire libmaitretarot_trucmuche a chaque fois, alors je 
> > > prefere libmt_trucmuche a la place.
> > > 
> > ah ! ben alors pourquoi ne pas l'appeler mt_ tout cours comme gtk_.
> > Se sont les fonctions de maitretarot (-> mt_) qui sont dans la lib
> > libmaitretarot. D'ailleurs si on utilise les fonctions de maitretarot
> > dans un autre code sans les mettre en librairie, ça va faire bizzard
> > d'appeler des libmt_qq_chose alors qu'il n'y a pas de lib.
> 
> He he, c'est rigolo ce que tu dis, parce que je vais te contredire, mais je 
> vais utiliser ton explication ;-)
> 
> j'utilise libmt_ pour les fonctions de la lib. on utilisera si on veut mt_ 
> pour les fonctions de maitretarot qui ne sont pas dans la lib. Et il ne reste 
> qu'a relire ce que tu m'as ecrit et ca colle ;-)
> 
> Au passage, toute fonction qui irait dans la lib serait renommee en mettant 
> un prefixe libmt_
> 
ok, ça colle avec mon explication :)

> > 
> > > 
> > > > > > > Derniere chose: je n'ai pas fait evoluer le protocole ni sa 
> > > > > > > gestion depuis notre derniere coding-party.
> > > > > > > 
> > > > > > Ok, de toutes façons, il vaut mieux le tester avant de voir si il 
> > > > > > faut modifier
> > > > > > quelque chose -> je m'y met :)
> > > > > 
> > > > > Youpiiiiiiiiiiiiii!
> > > > > 
> > > > :)
> > > 
> > > 
> > > Yahaaaaaaaaaaaaaa!
> > > Vouiiiiiiiiiiiiiiiiiii!
> > > Yepeeeeeeeeeeeeeeeeeeeeeee!
> > > Heum ;-)
> > > 
> > Voui, voila j'm'y met :)
> 
> Supeeeeeeeeeeeeeeeeeeer!
> Choueeeeeeeeeeeeeeeeeeeeeeeeette!
> Geniaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaal!
> Coooooooooooooooooooooooooooooooooooooooooooooooooool!
> P[extinction de voix]..................................!
> ...........................................................!
> 

:) 

> 
> 
> 
> 
> 
> > > > > > Une autre chose, par la suite, j'ai toujours envie de coder mon IA 
> > > > > > en scheme,
> > > > > > et ce que ça serait possible de recuperer mt_dolphin_ia pour 
> > > > > > l'ettendre ou il
> > > > > > faut que je me créé une nouvelle IA et qu'on developpe 
> > > > > > mt_dolphin_ia en C ?
> > > > > 
> > > > > Alors la, ce n'est plus mon rayon. Nicoooooo!
> > > > > 
> > > > > Bah juste un petit truc quand meme. Il faut une IA de base qu'on peut 
> > > > > etendre. Seulement, les deux doivent porter un nom different, et 
> > > > > l'une doit avoir ses fonctionnalites figees, c'est-a-dire qu'elle ne 
> > > > > soit pas etre etendue. A vous de choisir si mt_dolphin_ia est 
> > > > > celle-ci, et dans ce cas, tu la recuperes mais tu mets un nouveau 
> > > > > nom, ou si mt_dolphin_ia est une future "bonne" IA. Dans ce cas, il 
> > > > > faut faire une autre IA simple pour servir d'exemple.
> > > > > 
> > > > ben, moi j'aimerai bien recuperer ma mt_dolphin_ia pour bidouiller qq 
> > > > chose
> > > > en scheme (j'ai plein de trucs à tester :)
> > > > 
> > > > Donc ce que je propose :
> > > > - on créer une IA de base : par exemple mt_base_ia
> > > 
> > > Ca, c'est un joli nom. Je vote pour!
> > > Arf, non, je vote pas encore.
> > > J'ai un autre candidat: mt_example_ia.
> > > 
> > > J'attends d'avoir des sondages et des commentaires avant de voter.
> > > Mais l'idee est la.
> > > 
> > > > - je recupere mt_dolphin_ia
> > > 
> > > Oui.
> > > 
> > > > 
> > > > - Nico, si tu veux develloper des trucs bien à part sans les mettrent
> > > > dans l'IA de base, tu peut t'en créer une en repompant le code de
> > > > mt_dolphin_ia (qui va être celui de mt_base_ia)
> > > > 
> > > > 
> > > > s'en pensez quoi ?
> > > 
> > > cp mt_dolphin_ia mt_example_ia (ou mt_base_ia comme t'as propose)
> > > 
> > > Ensuite, Philippe, tu continues mt_dolphin_ia comme tu veux.
> > > Nico, a toi de voir si tu bosses avec Philippe sur mt_dolphin_ia, si tu 
> > > forkes mt_dolphin_ia, ou si tu repars sur mt_example_ia.
> > > Je crois que j'ai rien dit de nouveau en fait (j'aurais du me taire?), a 
> > > part qu'il faut choisir entre mt_example_ia et mt_base_ia pour le nom de 
> > > l'ia qui ne doit pas evoluer afin d'etre un exemple simple.
> > > 
> > Euh, je ne sais pas trop, les 2 sont bien à mon avis :
> > 
> >         mt_base_ia : c'est l'IA de base, on part de ça pour coder une
> >                         nouvelle IA.
> > 
> >         mt_example_ia : c'est une IA d'exemple, on peut la nettoyer
> >                         pour creer une nouvelle IA.
> > 
> 
> Mmmmmh, j'avais pas pense a ces deux roles.
> Pour moi, l'IA d'exemple sert de base. Mais avec ce que tu me dis, ma 
> reflexion avance:
> - on a besoin d'une base
> - on a besoin d'un exemple
> - l'exemple doit-il etre un exemple 100% fonctionnel, ou comme tu dis une 
> base: "on peut la nettoyer pour creer une nouvelle IA"?
> 
> Je reste sur ma position pour avoir un seul code qui serve a la fois de base 
> et d'exemple, mais je ne m'oppose pas a ce qu'on fasse les deux. Seulement 
> dans ce cas, est-ce que c'est pas un surplus inutile de boulot?
> 
> > bon, ben on tire a pile ou face parce que moi j'ai pas dis grand
> > chose de constructif :)
> 
> Si, c'etait constructif: on peut pas encore tirer a pile ou face.
> Il faut repondre a ma question: un exemple et une base distincts, ou un code 
> qui fasse les deux?
> 

euh, moi je pensais à l'un ou l'autre (mais pas les 2) avec les 
fonctions decrite pour chaque noms, maintenant il faut choisir.

D'un autre cote, si on met les 2 :
        on laisse l'IA de base avec les randoms (et les trucs les
plus simple) -> on peut demarrer une nouvelle IA sans avoir a
faire de menage et le code est simple pour qq1 qui veut commencer,
il suffit de remplir quelques fonctions.

        on developpe l'IA d'exemple pour montrer ce que peut faire
maitretarot avec une IA un peu plus devellopée.

        chacun code ses IA dans des modules differents (mt_dolphin_ia...)
=> pour faire des competition d'IA.


Sinon, on peut faire qu'un seul code :

        l'IA d'exemple contient seulement les randoms et les trucs simples.
(ce sera l'IA de base :) mais ont la développe quasiment pas.


eh! eh! plus qu'a choisir :)



Philippe


-- 
,-------------------.         ,---------------,----------------------.
| Philippe Brochard |   ...   | address@hidden | http://hocwp.free.fr |
`------------------(_  (. .)  `---------------'----------------------'
-------------------ooO--(_)--Ooo--------------------------------------