Messages

1

Général / Re : CMake Could NOT find SFML (Debian Jessie 3.16.0-4-amd64)

« le: Février 14, 2015, 08:15:19 am »

Bon, j'ai enfin réussi à compiler, il manquait un "#define SFML_VERSION_PATCH" dans le fichier Confic.hpp que j'avais récupérer dans la release 2.1.

2

Général / Re : CMake Could NOT find SFML (Debian Jessie 3.16.0-4-amd64)

« le: Février 14, 2015, 07:57:10 am »

Très étrange… j'ai des .h au lieu de .hpp.

Pourtant d'après SFML/Config.h, j'ai la bonne version de la SFML, qu'est-ce qu'ils ont fait dans les dépôts Debian ??

3

Général / Re : CMake Could NOT find SFML (Debian Jessie 3.16.0-4-amd64)

« le: Février 14, 2015, 07:39:25 am »

Je viens de trouver la solution sous la douche :
Il y a des libsfml-x.so.y mais pas de libsfml-x.so

Un simple ln -s a pu résoudre le problème,
Pourtant j'avais bien installé la SFML à partir des dépôts de Debian 

J'ai encore un petit problème pour le dossier d'inclusion mais je pense que je vais pouvoir m'en sortir.

4

Général / CMake Could NOT find SFML (Debian Jessie 3.16.0-4-amd64)

« le: Février 14, 2015, 07:03:52 am »

Bonjour,

Je tente de compiler un projet utilisant la SFML

find_package(SFML 2.1 REQUIRED system window graphics audio)

Mais j'ai l'erreur suivante avec cmake :

CMake Error at cmake_modules/FindSFML.cmake:312 (message):
  Could NOT find SFML (missing: SFML_SYSTEM_LIBRARY SFML_WINDOW_LIBRARY
  SFML_GRAPHICS_LIBRARY SFML_AUDIO_LIBRARY)
Call Stack (most recent call first):
  CMakeLists.txt:35 (find_package)

Pourtant la SFML est bien installée sur mon poste (Debian Jessie 3.16.0-4-amd64 ) :

~$ ls /usr/lib/x86_64-linux-gnu/libsfml-*
/usr/lib/x86_64-linux-gnu/libsfml-audio.so.2       /usr/lib/x86_64-linux-gnu/libsfml-network.so.2    /usr/lib/x86_64-linux-gnu/libsfml-window.so.2
/usr/lib/x86_64-linux-gnu/libsfml-audio.so.2.1     /usr/lib/x86_64-linux-gnu/libsfml-network.so.2.1  /usr/lib/x86_64-linux-gnu/libsfml-window.so.2.1
/usr/lib/x86_64-linux-gnu/libsfml-graphics.so.2    /usr/lib/x86_64-linux-gnu/libsfml-system.so.2
/usr/lib/x86_64-linux-gnu/libsfml-graphics.so.2.1  /usr/lib/x86_64-linux-gnu/libsfml-system.so.2.1

Les find_library ne me trouvent rien, j'ai essayé de rajouter  /usr/lib/x86_64-linux-gnu dans FIND_SFML_PATHS, j'ai aussi tenté de rajouter lib/x86_64-linux-gnu dans les préfixes des find_library, rien à faire.

Je suis donc allé rechercher la dernière version du findSFML.cmake sur le dépôt de la SFML : https://github.com/SFML/SFML/blob/master/cmake/Modules/FindSFML.cmake
Rien ne change.

Je ne comprends pas du tout ce qui pourrait clocher, auriez-vous une idée ?

Merci d'avance

5

Réseau / Re : Re : [SFML2.0]SocketSelector, comment savoir s'il y a une erreur ?

« le: Juillet 07, 2012, 08:29:13 pm »

Flemme, simplicité et pragmatisme.

Les attributs d'un bon programmeur
Il est vrai que si on doit toujours remettre en cause tout ce que l'on a codé et qu'on cherche à l'améliorer sans cesse, on ne progresse pas.

Le seul problème que je verrais, c'est l'utilisation du sf::SocketSelector avec un seul sf::TcpSocket dedans dans l'objectif d'avoir un timeout grâce à la méthode wait de sf::SocketSelector si jamais un signal est envoyé, on déconnecte le client à tort.


Merci d'avoir répondu à mes questions et toujours aussi rapidement.

6

Réseau / Re : [SFML2.0]SocketSelector, comment savoir s'il y a une erreur ?

« le: Juillet 07, 2012, 06:42:04 pm »

Si je comprend bien, il est inutile de gérer ces erreurs car :

EBADF est dû au fait qu'on ai fait le TcpSocket::disconnect avant le SocketSelector::remove(). C'est donc une faute de l'utilisateur de la SFML.

EINTR est dû au fait qu'on ai réceptionne un signal. Mais comme les SocketSelector::remove() sont placés à l'intérieur d'une boucle, on va juste faire un tour de plus ?
Mais si on ne met qu'un seul TcpSocket dans le SocketSelector pour faire un timeout (comme conseillé dans la doc ou dans le tuto je sais plus), on va déconnecter le TcpSocket prématurément.
Ou alors si on décide que si on a pas de sockets prêt pendant 60 secondes, on déclenche une action particulière ?


ENOMEM est assez rare. Mais ne peut-il pas se produire ? Ne pourrait-on pas gérer cette erreur pour permettre au programmeur de décider quoi faire si jamais cette erreur se produit ?

Ne serait-il même pas plus efficace que SocketSelector::wait() retourne un int (count) et à l'utilisateur de faire le :

if(SocketSelector > 0) ;

Ce qui permettrait par la suite de gérer une éventuelle erreur ?


Non pas que je soit contrariant (bon un petit peu quand même), mais je suis assez curieux de nature et j'aimerais comprendre ce choix et peut être en apprendre quelque chose qui pourrait m'être utile dans mes propres programmes.

7

Réseau / Re : [SFML2.0]SocketSelector, comment savoir s'il y a une erreur ?

« le: Juillet 07, 2012, 09:43:40 am »

Je viens de comprendre.

Le problème vient du select (dans SocketSelector::wait ).

select retourne le nombre de socket près ou 0 si le timeout est expiré.

Donc return cout > 0; retournera true si des sockets sont prêt, false si le time out est expiré.

Sauf qu'il peut aussi retourner - 1 en cas d'erreur !

Trois erreurs pouvant se produire :
EBADF : Un descripteur de fichier (dans l'un des ensembles) est invalide.  (ce qu'il se passe avec moi)
EINTR : Un signal a été intercepté.
ENOMEM : Pas assez de mémoire pour le noyau.

Ne serait-il pas plus sage de d'enregistrer l'erreur si count = -1 et dans le cas où SocketSelector::wait() retourne false on puisse appeler une fonction .getErreur() qui retournera 0 si il n'y a pas d'erreur (timeout écoulé) et une erreur si une erreur c'est produite ?

8

Réseau / Re : [SFML2.0]SocketSelector, comment savoir s'il y a une erreur ?

« le: Juillet 06, 2012, 08:58:23 pm »

J'aimerais savoir s'il existe un autre moyen de différencier si le return false est dû à la fin des 15 secondes ou s'il est dû à une erreur autre que de mettre un sf::Clock;

J'aimerais aussi savoir s'il est utile de mettre un sf::Clock ou s'il ne peut pas y avoir d'erreur dans SocketSelector::wait si on n'essaye pas de déconnecter soi-même les TcpSocket.


EDIT : j'ai compris l'erreur en regardant les sources.
Socket::disconnect() va mettre dans m_socket une valeur pour signifier que le socket est invalide.
Puis il fait appel à close() qui va fermer le socket proprement.
Mais SocketSelector.remove(socket) va lui aussi utiliser m_socket (via getHandle() ) pour l'enlever de la liste à écouter.
Comme je passe une valeur de socket invalide, il y a une erreur lors du FD_CLR d'où les returns false en boucle.

Il faut donc bien appeler socket.disconnect() mais après SocketSelector.remove() ?

J'ai relu la doc de TcpSocket, Socket et SocketSelector plusieurs fois mais je n'ai pas vu d'information à ce propos ce qui me semble assez dommage (à moins que je sois passé à côté).

9

Réseau / Re : [SFML2.0]SocketSelector, comment savoir s'il y a une erreur ?

« le: Juillet 06, 2012, 08:01:04 pm »

sf::SocketSelector selector;
sf::TcpListener listener;
sf::TcpSocket socket;

listener.accept(&socket);
selector.add(socket);


socket.disconnect(); //provoque l'erreur
selector.remove(socket);

while(1)
{
         std::cout << selector.wait(sf::seconds(15))  << std::endl;
}
 

selector::wait va toujours retourner false directement quoi qu'il arrive sans attendre.

Si le socket.disconnect et le selector.remove sont appelé dans un autre thread pendant que le thread principal attend sur selector.wait, il attendra la fin des 15 secondes puis retournera false directement quoi qu'il arrive sans attendre.

10

Réseau / [Résolu][SFML2.0]SocketSelector, comment savoir s'il y a une erreur ?

« le: Juillet 06, 2012, 07:01:06 pm »

Bonjour,

J'ai un socketSelector qui attend de cette manière :

Code: [Sélectionner]

selector.wait(sf::seconds(15)
Dès lors il retourne true si des sockets sont prêt et false au bout de 15 secondes si jamais aucun socket n'est prêt.

Mais j'ai commis l'erreur de faire :

Code: [Sélectionner]

socket.disconnect();
selector.remove(socket);
Dès lors je vais attendre 15 secondes sur la ligne du selector.wait qui va retourner false puis selector.wait retournera directement false sans attendre 15 secondes.
Il me semble évident que j'ai fait planter le socketSelector.

J'ai beau consulter la documentation, je n'ai pas trouvé le moyen de différencier si le false retourné par selector::wait est dû au timeout ou à une erreur.

Faut-il alors que je mette un sf::Clock pour repérer les erreurs ?
Existe-t-il d'autres moyen connu de faire planter le socketSelector? (pour savoir à quoi pourrait être dû l'erreur si jamais elle se reproduit).

11

Système / Re : [résolut]Sémaphore

« le: Juillet 06, 2012, 03:52:15 pm »

Merci pour votre réponse.
J'ai finalement utilisé les semaphores de pthread.

12

Système / Re : [Résolu][SFML2.0]mutex.lock consécutifs, pas de blocage.

« le: Juillet 03, 2012, 02:16:32 pm »

D'accord, merci pour vos réponses.

13

Système / Re : [SFML 1.6] Thread et fluidité

« le: Juillet 03, 2012, 02:15:00 pm »

Peux-tu nous montrer comment tu créé ton thread?

Est-ce tu ne créé pas de thread à chaque "tour" ?

14

Système / Re : [SFML2.0]mutex.lock consécutifs, pas de blocage.

« le: Juillet 03, 2012, 09:08:22 am »

Merci pour vos réponses.

Comme je vais devoir implémenter les wait condition et plus tard les threads pour windows et les unix, est-ce que vous voudriez que je vous donne les sources pour éventuellement les rajouter à la SFML (ou servir de base pour un ajout futur) ?
Dans ce cas là je dois forker le dépôt github et soumettre une "pull request" ?

15

Système / Re : [SFML2.0]mutex.lock consécutifs, pas de blocage.

« le: Juillet 01, 2012, 11:05:48 pm »

J'ai un thread qui se charge de la réception de paquet :

//thread producteur.

//création des threads consommateurs
while(running)
{
          //je construit un TcpListener et un SocketSelector
          while(running && ! bloque)
          {
                     //reception d'un paquet
                     //si nécessaire ajoute le paquet à une file de paquet. Le paquet sera alors traité par un ensemble de thread consommateurs.
           }
           //destruction du TcpListener et tu SocketSelector
           if(bloque)
                      //on bloque le thread jusqu'à ce qu'on décide de rouvrir le serveur aux clients
}
//destruction des threads consommateurs
 

Ainsi si le serveur reçoit plusieurs instructions (reçu par un autre thread avec un listener qui écoute sur un autre port) selon lesquelles il doit bloquer (ou débloquer) le thread producteur, on peut les traiter sans se soucier de l'état du thread producteur.