IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C Discussion :

Projet d'un adaptateur pour les moteurs d'échecs


Sujet :

C

Mode arborescent

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Rédacteur/Modérateur

    Avatar de Roland Chastain
    Homme Profil pro
    Enseignant
    Inscrit en
    Décembre 2011
    Messages
    4 167
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Enseignant

    Informations forums :
    Inscription : Décembre 2011
    Messages : 4 167
    Billets dans le blog
    9
    Par défaut Projet d'un adaptateur pour les moteurs d'échecs
    Bonjour tout le monde !

    J'ai commencé un projet sur lequel j'aimerais bien avoir vos conseils (sachant que j'ai peu de pratique du C).

    C'est un adaptateur pour les moteurs d'échecs, qui permet de changer le protocole d'utilisation.

    Il y a deux principaux protocoles pour les moteurs d'échecs, le protocole CECP (plus communément appelé protocole XBoard/WinBoard) et le protocole UCI.

    Exemple de dialogue avec un moteur XBoard :

    Code X : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    $ ./faile
    xboard ' commande
    protover 2 ' commande
    feature done=0 ' réponse
    feature myname="Faile 0.6 RC230225" ' réponse
    feature sigint=0 sigterm=0 ping=0 setboard=1 memory=0 debug=1 ' réponse
    feature done=1 ' réponse
    quit ' commande
    $

    La même chose avec un moteur UCI :

    Code X : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    $ ./cheng4_linux_x64 
    uci ' commande
    id name Cheng 4.40 ' réponse
    id author Martin Sedlak ' réponse
    option name Hash type spin min 1 max 16384 default 32 ' réponse
    option name Clear Hash type button ' réponse
    uciok ' réponse
    quit ' commande
    $

    L'adaptateur va être utilisé par l'utilisateur comme un moteur UCI. En arrière-plan il lance le moteur XBoard, et transmet les messages, dans les deux sens, en les traduisant.

    Code X : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    $ ./adapter
    uci ' commande
    id name Faile 0.6 RC230225 ' réponse
    id author ? ' réponse
    uciok ' réponse
    quit ' commande
    $

    La partie principale du programme (le fichier bi_popen.c), je l'ai trouvée toute faite ici. Tout ce que j'ai fait, c'est d'ajouter un fil d'exécution séparé pour traiter les réponses du moteur.

    Le programme fonctionne, mais j'aimerais bien avoir votre avis sur la façon dont il est écrit avant de le continuer.

    D'ailleurs, quand je dis qu'il fonctionne, il y a quand même des petites choses que valgrind signale et que je ne sais pas comment résoudre :

    Code X : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    ==462743== Memcheck, a memory error detector
    ==462743== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
    ==462743== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
    ==462743== Command: ./adapter
    ==462743== 
    ==462743== Thread 2:
    ==462743== Conditional jump or move depends on uninitialised value(s)
    ==462743==    at 0x48AE501: pcre_exec (in /usr/lib64/libpcre.so.1.2.12)
    ==462743==    by 0x401C15: get_engine_name (expr.c:34)
    ==462743==    by 0x4016A6: read_process_output (adapter.c:122)
    ==462743==    by 0x4870DEB: start_thread (in /usr/lib64/libpthread-2.32.so)
    ==462743==    by 0x49F7A6E: clone (in /usr/lib64/libc-2.32.so)
    ==462743== 
    ==462743== 
    ==462743== HEAP SUMMARY:
    ==462743==     in use at exit: 291 bytes in 2 blocks
    ==462743==   total heap usage: 33 allocs, 31 frees, 27,051 bytes allocated
    ==462743== 
    ==462743== Thread 1:
    ==462743== 19 bytes in 1 blocks are definitely lost in loss record 1 of 2
    ==462743==    at 0x4836751: malloc (vg_replace_malloc.c:307)
    ==462743==    by 0x48AF0F7: pcre_get_substring (in /usr/lib64/libpcre.so.1.2.12)
    ==462743==    by 0x401C8B: get_engine_name (expr.c:49)
    ==462743==    by 0x4016A6: read_process_output (adapter.c:122)
    ==462743==    by 0x4870DEB: start_thread (in /usr/lib64/libpthread-2.32.so)
    ==462743==    by 0x49F7A6E: clone (in /usr/lib64/libc-2.32.so)
    ==462743== 
    ==462743== 272 bytes in 1 blocks are possibly lost in loss record 2 of 2
    ==462743==    at 0x4838971: calloc (vg_replace_malloc.c:760)
    ==462743==    by 0x4011F47: _dl_allocate_tls (in /usr/lib64/ld-2.32.so)
    ==462743==    by 0x4871983: pthread_create@@GLIBC_2.2.5 (in /usr/lib64/libpthread-2.32.so)
    ==462743==    by 0x401442: main (adapter.c:60)
    ==462743== 
    ==462743== LEAK SUMMARY:
    ==462743==    definitely lost: 19 bytes in 1 blocks
    ==462743==    indirectly lost: 0 bytes in 0 blocks
    ==462743==      possibly lost: 272 bytes in 1 blocks
    ==462743==    still reachable: 0 bytes in 0 blocks
    ==462743==         suppressed: 0 bytes in 0 blocks
    ==462743== 
    ==462743== Use --track-origins=yes to see where uninitialised values come from
    ==462743== For lists of detected and suppressed errors, rerun with: -s
    ==462743== ERROR SUMMARY: 6004 errors from 3 contexts (suppressed: 0 from 0)

    Merci d'avance pour vos remarques.

    P.-S. J'avais l'intention de créer cette discussion dans le forum C. Je n'avais pas vu que le sous-forum Linux était un lien.
    Fichiers attachés Fichiers attachés

Discussions similaires

  1. Méthodes itératives pour les moteurs physiques 3D
    Par PierroVsf dans le forum Développement 2D, 3D et Jeux
    Réponses: 0
    Dernier message: 29/06/2019, 15h40
  2. Interface en Pascal pour le moteur d'échecs Smirf
    Par Roland Chastain dans le forum Delphi
    Réponses: 4
    Dernier message: 11/06/2019, 13h26
  3. La technique des portail pour les moteur 3D
    Par Heptaeon dans le forum Algorithmes et structures de données
    Réponses: 4
    Dernier message: 11/10/2005, 16h57

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo