Socket qui bloque sur NotReady ! / Problème de paquets...

[Laurent]

Le SIGPIPE est doit être pris plus à la légère, il signifie une déconnexion et non un crash :
https://github.com/SFML/SFML/issues/72

[Crone123]

Donc le bug est connu?
(L'effet est le même qu'un crash avec le débugger par contre...)
La correction est prévue assez rapidement où bien je dois rajouter une de ces lignes de codes pour que ça ne bug plus?
Je suis sous Linux, donc a priori c'est la 2ème ligne, si c'est a moi de la rajouter, je dois la rajouter où dans mon projet et comment?
Si c'est un bug de la SFML, quand pensez-vous qu'il y aura une correction?
Merci

[Laurent]

Donc le bug est connu?

C'est pas un bug, juste que le comportement par défaut de Linux n'est pas ce que SFML veut

L'effet est le même qu'un crash avec le débugger par contre...

Un signal non rattrapé, c'est comme une exception non rattrapée, et le debugger te montre ça de la même manière qu'un crash effectivement. C'est normal.

Je suis sous Linux, donc a priori c'est la 2ème ligne, si c'est a moi de la rajouter, je dois la rajouter où dans mon projet et comment?

Il faut juste ajouter le paramètre MSG_NOSIGNAL aux appels à la fonction send (il doit y avoir un seul appel, dans sf::TcpSocket). Actuellement il doit y avoir un 0 à la place de ce paramètre.
Du coup tu dois modifier SFML. Sinon je pense que tu peux mettre en place un handler pour le signal SIGPIPE, mais il faut chercher comment faire.

Si c'est un bug de la SFML, quand pensez-vous qu'il y aura une correction?

Sûrement dans 2.1, ça n'a pas l'air méchant.

[Crone123]

D'accord, donc en fait c'est une exception non rattrapée sur un comportement par défaut de Linux.
Donc le bug n'est pas sous Windows.
Donc en gros, je télécharges les sources de la SFML, je modifie la ligne qui bug dans les sf::TcpSocket et je la compile?
Bon, j'espère arriver à la compiler, mais je veux bien essayer. (au pire si besoin d'aide pour compiler je poste ici..)
Sinon (sans vouloir être embêtant bien sûr ), avez vous une idée de date approximative pour la SFML 2.1?
Fin du mois? Fin du mois prochain? Un autre moment?
Merci

[Laurent]

avez vous une idée de date approximative pour la SFML 2.1?
Fin du mois? Fin du mois prochain? Un autre moment?

J'ai même pas de date pour 2.0...

[Crone123]

Ah OK, et pour la 2.0 ça ne peut pas être corrigé? (si il suffit de modifier une ligne....)
Sinon, j'ai téléchargé les sources, je vais essayer de compiler la bibliothèque....

[Laurent]

Ah OK, et pour la 2.0 ça ne peut pas être corrigé? (si il suffit de modifier une ligne....)

Non
Il faut faire des tests, vérifier que ça ne casse rien, etc. C'est déjà trop tard pour la 2.0.

[Crone123]

Trop tard
Hé ben, il en faut du temps pour tout ça
(On dirait pas comme ça)

Sinon, j'ai essayé de compiler la SFML, je pense que j'ai réussi, mais elle ne fonctionne pas dans mon projet.

J'ai utilisé cmake comme le montre le tuto, mais je ne sais pas si il m'a compilé une version C ou C++.
En tout cas, j'ai des fichiers .so qui ont une taille très différente de la taille normale.
Et par exemple en compilant mon projet sf::Text::Text(std::string Machin); n'existe pas.
En fait, il ne la trouve pas dans les définitions de fonctions, bien qu'il me le propose.
ça fonctionnait avant.
Je me demande si il ne m'a pas compilé une version C au lieu de C++ puisque CMake a l'air de faire du C.

Pouvez-vous m'aider?
Merci

[Laurent]

Hé ben, il en faut du temps pour tout ça

Il faut le temps que les gens l'utilisent suffisamment et rapportent d'éventuels problèmes. Donc oui, ça prend du temps. Surtout concernant le module réseau, qui n'est pas le plus utilisé. Les choses ne sont pas aussi simples qu'elles y paraissent.

Je me demande si il ne m'a pas compilé une version C au lieu de C++ puisque CMake a l'air de faire du C.

CMake n'est pas un compilateur, il fait ce que tu lui demandes de faire avec le compilo que tu choisis. Donc ça peut être du C++ (et en l'occurence ça l'est). Et je vois mal comment tu pourrais produire une version C de SFML comme ça, le code c'est quand même du C++ hein

En tout cas, j'ai des fichiers .so qui ont une taille très différente de la taille normale.

Et c'est quoi la "taille normale" ? Si tu as compilé en debug, ça peut être plus gros. Par exemple.

Et par exemple en compilant mon projet sf::Text::Text(std::string Machin); n'existe pas.

L'erreur exacte c'est quoi ? Parce que "n'existe pas" ça peut être plein de choses différentes, qui ont chacune une cause bien différente.

[Crone123]

Euh, en fait Firefox s'est fermé, donc j'ai perdu le message que j'étais en train d'écrire.
Donc, pour le message d'erreur ça viens du module graphique qui a un problème a la compilation, il me dit cette fois ci que la fonction sf::Font::getDefaultFont() n'est pas définie.

Avec la version du module réseau utilisant NO_MSG a la place de 0, j'ai eut de meilleures performances qu'avant.
Et si avant la récupération était impossible, maintenant quand ça bloque au bout de quelques secondes le jeu arrive a reprendre le transfert.
Il y a souvent des interruptions par contre, ça serait bien de corriger ça.
Enfin, ne nous plaignons pas, avant je n'arrivais pas a transférer plus de 1% de ma map.
Actuellement alors que j'écris ce message j'ai transféré 61% de la map.
Une belle avancée quoi

Par contre, la map est bien trop grosse, je la découperais en petites zones après...mais avant même les petites maps avaient du mal a passer....

Et sinon, niveau socket: Si je kille un programme, je n'ai aucun problèmes niveau fermeture des socket.
En revanche, si je quitte normalement le programme en fermant proprement les socket, bah, après je ne peux plus lancer le programme pendant une minute (temps que le système supprime lui même l'écoute de port) parce que le port reste considéré comme écouté.
Là dessus, je ne sais pas quoi faire, j'utilise bien les fonctions close/disconnect/unbind suivant le cas et pourtant rien a faire, les socket en écoutent le restent la plupart du temps.

On aurait pu soupçonner le fait que j'utilise Qt a coté et qu’éventuellement il empêcherait la fermeture, mais le serveur (qui a beaucoup de problèmes de ce coté là) n'utilise pas Qt, il a sa propre boucle avec la SFML.
J'avais essayé avec boost d'écouter des ports et je n'ai pas eu ce bug, avec la SFML je l'ai systématiquement, et sur tous les ordis sur lequel j'ai essayé le jeu....et tous les programmes que j'ai crée utilisant la SFML pour le réseau ont ce problème.

(Je le dis et je le répète, je ne suis pas là pour dire qu'il y a des bugs partout hein, je fais une simple constatation sur des problèmes que j'ai avec la SFML afin qu'ils puissent être éventuellement améliorés par la suite)
Merci

[Laurent]

il me dit cette fois ci que la fonction sf::Font::getDefaultFont() n'est pas définie

Ce qui est vrai. Elle a été retirée depuis la RC.

Il y a souvent des interruptions par contre, ça serait bien de corriger ça.

Des interruptions ? C'est-à-dire ?

En revanche, si je quitte normalement le programme en fermant proprement les socket, bah, après je ne peux plus lancer le programme pendant une minute (temps que le système supprime lui même l'écoute de port) parce que le port reste considéré comme écouté.

Il faut vraiment que tu penses à chercher d'abord, lorsque tu tombes sur un os.
https://github.com/SFML/SFML/issues/150

[Crone123]

Ce qui est vrai. Elle a été retirée depuis la RC.

Mais moi je n'utilise pas la fonction, c'est lors d'un appel d'un constructeur de sf::Text avec en paramètre un std::string que j'ai cette erreur.
La SFML ne l'appelle pas en interne?

Des interruptions ? C'est-à-dire ?

Des coupures de 5 a 10s pendant les transferts réseaux.

Il faut vraiment que tu penses à chercher d'abord, lorsque tu tombes sur un os.

Ah, désolé, en fait j'ai toujours du mal pour trouver les endroit de signalement de bug, surtout si c'est en anglais je ne formule pas forcément correctement le bug en anglais.

[Laurent]

Mais moi je n'utilise pas la fonction, c'est lors d'un appel d'un constructeur de sf::Text avec en paramètre un std::string que j'ai cette erreur.
La SFML ne l'appelle pas en interne?

Cette fonction n'existe plus car il n'y a plus de police par défaut, tu es obligé d'en charger une et de la passer à ton sf::Text maintenant.

Des coupures de 5 a 10s pendant les transferts réseaux.

Peut-être une surcharge de la socket, si tu envoies trop de données trop rapidement ?

Ah, désolé, en fait j'ai toujours du mal pour trouver les endroit de signalement de bug, surtout si c'est en anglais je ne formule pas forcément correctement le bug en anglais.

Oui, c'est vrai que celui-ci n'était pas forcément évident à trouver, surtout avec un titre pareil

[Crone123]

Euh, pourquoi plus de police par défaut?
C'est franchement très mauvais comme "amélioration", parce que d'une part il faut avoir des polices, ensuite, c'est moins cool pour créer un sf::Text (on a pas forcément envie de mettre une police autre, celle par défaut va souvent très bien) et pour finir, j'ai un projet qui compte 21163Lignes de code + un SDK de 3000Lignes de codes qui va avec, donc là dedans je vais devoir m'amuser a retrouver tous les sf::Text pour leurs remettre une police par défaut
Là franchement je ne vois pas du tout l’intérêt, c'est mauvais comme changement.

[Laurent]

La police par défaut était un cas particulier qui n'était selon moi pas si justifié que ça. J'ai juste retiré cette "irrégularité", et rendu l'API plus homogène.

La police par défaut c'était bien pour prototyper ou pour faire du debug. Mais dans l'application finale, personne ne va l'utiliser, tu vas forcément charger une police qui va mieux que ce bête Arial.

Et si tu veux tout de même Arial, et bien il n'y a qu'à le copier depuis le répertoire de polices de ton OS vers ton application, et le gérer comme toutes les autres ressources de ton application. Je ne vois pas de gros problème.

Bien sûr, ce n'est pas la raison pour laquelle ça a été retiré, c'est à la base parce que la police par défaut était une instance à portée globale qui causait des crashs à la fermeture, et que la seule façon propre de régler ça était de la supprimer.