Contenu | Rechercher | Menus

Annonce

Ubuntu-fr vend de superbes t-shirts et de belles clés USB 32Go
Rendez-vous sur la boutique En Vente Libre

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#176 Le 05/02/2020, à 19:09

Elzen

Re : /* Topic des codeurs [9] */

Dafyd a écrit :

Désolé j’ai pas beaucoup de temps libre en ce moment hmm

Ben pas de souci, c'est surtout pour toi que ce n'est pas chouette.

grim7reaper a écrit :

Alors oui dans l’absolu c’est possible partout.
Après en Python je ne pense pas (sauf bug de l’interpréteur), car il fait beaucoup de chose sur le tas.
un StackOverflow c’est un crash violent comme une segfault quoi.
Autant j’ai déjà vu des MemoryError ou des RecursionError en Python (voire des segfault quand j’appelle du C depuis Python), autant une stack overflow pas encore (d’où ma surprise).

Je m'étais dis que j'allais te filer, à toute fin utile, la trace récupérée dans le terminal pour que tu puisses te faire une idée, sauf que, bien évidemment, je n'en ai gardé aucune des plantages précédents, et ça fait quelques heures que ce message est rédigé par ailleurs et attend d'être envoyé sans qu'il n'y en ait l'ombre d'une qui se produise ^^ Donc bon, j'arrête d'attendre et je te montrerai ça à l'occasion dans un autre post.

Edit : ah, bah, j'ai fini par l'avoir ^^
Donc, si ça t'intéresse :

Fatal Python error: Cannot recover from stack overflow.

Thread 0x00007efe8503c700 (most recent call first):
  File "/opt/touhy/lib/elzlibs/shared.py", line 125 in wait
  File "/usr/lib/python3.7/threading.py", line 870 in run
  File "/usr/lib/python3.7/threading.py", line 926 in _bootstrap_inner
  File "/usr/lib/python3.7/threading.py", line 890 in _bootstrap

Thread 0x00007efe8583d700 (most recent call first):
  File "/opt/touhy/lib/elzlibs/shared.py", line 125 in wait
  File "/usr/lib/python3.7/threading.py", line 870 in run
  File "/usr/lib/python3.7/threading.py", line 926 in _bootstrap_inner
  File "/usr/lib/python3.7/threading.py", line 890 in _bootstrap

Thread 0x00007efe87fff700 (most recent call first):
  File "/opt/touhy/lib/elzlibs/shared.py", line 125 in wait
  File "/usr/lib/python3.7/threading.py", line 870 in run
  File "/usr/lib/python3.7/threading.py", line 926 in _bootstrap_inner
  File "/usr/lib/python3.7/threading.py", line 890 in _bootstrap

Thread 0x00007efea4f5a700 (most recent call first):
  File "/opt/touhy/lib/elzlibs/calls.py", line 184 in wait
  File "/usr/lib/python3.7/threading.py", line 870 in run
  File "/usr/lib/python3.7/threading.py", line 926 in _bootstrap_inner
  File "/usr/lib/python3.7/threading.py", line 890 in _bootstrap

Thread 0x00007efea575b700 (most recent call first):
  File "/opt/touhy/lib/elzlibs/shared.py", line 103 in wait
  File "/usr/lib/python3.7/threading.py", line 870 in run
  File "/usr/lib/python3.7/threading.py", line 926 in _bootstrap_inner
  File "/usr/lib/python3.7/threading.py", line 890 in _bootstrap

Thread 0x00007efea5f5c700 (most recent call first):
  File "/usr/lib/python3.7/socket.py", line 212 in accept
  File "/opt/touhy/lib/elzlibs/shared.py", line 89 in wait
  File "/usr/lib/python3.7/threading.py", line 870 in run
  File "/usr/lib/python3.7/threading.py", line 926 in _bootstrap_inner
  File "/usr/lib/python3.7/threading.py", line 890 in _bootstrap

Thread 0x00007efea675d700 (most recent call first):
  File "/opt/touhy/lib/sencol/joypads/sfml.py", line 61 in mainloop
  File "/usr/lib/python3.7/threading.py", line 870 in run
  File "/usr/lib/python3.7/threading.py", line 926 in _bootstrap_inner
  File "/usr/lib/python3.7/threading.py", line 890 in _bootstrap

Thread 0x00007efea6f5e700 (most recent call first):
  File "/usr/lib/python3.7/socket.py", line 212 in accept
  File "/opt/touhy/lib/elzlibs/shared.py", line 89 in wait
  File "/usr/lib/python3.7/threading.py", line 870 in run
  File "/usr/lib/python3.7/threading.py", line 926 in _bootstrap_inner
  File "/usr/lib/python3.7/threading.py", line 890 in _bootstrap

Current thread 0x00007efec2ffd700 (most recent call first):
  File "/opt/touhy/lib/elzlibs/utils.py", line 131 in keys
  File "/opt/touhy/lib/elzlibs/types/__init__.py", line 25 in __getitem__
  File "/opt/touhy/lib/elzlibs/types/__init__.py", line 22 in __getitem__
  File "/opt/touhy/lib/elzlibs/types/__init__.py", line 18 in __call__
  File "/opt/touhy/lib/elzlibs/types/iter.py", line 12 in check
  File "/opt/touhy/lib/elzlibs/types/iter.py", line 39 in parse
  File "/opt/touhy/lib/elzlibs/types/__init__.py", line 110 in parse
  File "/opt/touhy/lib/elzlibs/types/__init__.py", line 18 in __call__
  File "/opt/touhy/lib/elzlibs/images/gears.py", line 105 in reframe
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 80 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 83 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 103 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 103 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 119 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 103 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 103 in perform
  File "/opt/touhy/lib/elzlibs/images/__init__.py", line 20 in icon
  File "/opt/touhy/lib/sencol/clips/__init__.py", line 21 in update
  File "/opt/touhy/lib/elzlibs/calls.py", line 126 in threaded
  File "/opt/touhy/lib/elzlibs/calls.py", line 199 in safely
  File "/opt/touhy/lib/elzlibs/calls.py", line 29 in __call__
  File "/opt/touhy/lib/elzlibs/calls.py", line 70 in warn
  File "/opt/touhy/lib/elzlibs/entities/clip.py", line 32 in updates
  File "/opt/touhy/lib/_elzlibs_gtk3/entities/clip.py", line 32 in change
  File "/opt/touhy/lib/_elzlibs_gtk3/entities/clip.py", line 41 in read
  File "/opt/touhy/lib/elzlibs/calls.py", line 126 in threaded
  File "/opt/touhy/lib/elzlibs/entities/clip.py", line 114 in read
  File "/opt/touhy/lib/elzlibs/entities/clip.py", line 100 in replacement
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 235 in text
  File "/opt/touhy/lib/elzlibs/images/gears.py", line 220 in clip
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 80 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 103 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 103 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 103 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 121 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 103 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 103 in perform
  File "/opt/touhy/lib/elzlibs/images/__init__.py", line 20 in icon
  File "/opt/touhy/lib/sencol/clips/__init__.py", line 21 in update
  File "/opt/touhy/lib/elzlibs/calls.py", line 126 in threaded
  File "/opt/touhy/lib/elzlibs/calls.py", line 199 in safely
  File "/opt/touhy/lib/elzlibs/calls.py", line 29 in __call__
  File "/opt/touhy/lib/elzlibs/calls.py", line 70 in warn
  File "/opt/touhy/lib/elzlibs/entities/clip.py", line 32 in updates
  File "/opt/touhy/lib/_elzlibs_gtk3/entities/clip.py", line 32 in change
  File "/opt/touhy/lib/_elzlibs_gtk3/entities/clip.py", line 41 in read
  File "/opt/touhy/lib/elzlibs/calls.py", line 126 in threaded
  File "/opt/touhy/lib/elzlibs/entities/clip.py", line 114 in read
  File "/opt/touhy/lib/elzlibs/entities/clip.py", line 100 in replacement
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 235 in text
  File "/opt/touhy/lib/elzlibs/images/gears.py", line 220 in clip
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 80 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 103 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 103 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 103 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 121 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 103 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 103 in perform
  File "/opt/touhy/lib/elzlibs/images/__init__.py", line 20 in icon
  File "/opt/touhy/lib/sencol/clips/__init__.py", line 21 in update
  File "/opt/touhy/lib/elzlibs/calls.py", line 126 in threaded
  File "/opt/touhy/lib/elzlibs/calls.py", line 199 in safely
  File "/opt/touhy/lib/elzlibs/calls.py", line 29 in __call__
  File "/opt/touhy/lib/elzlibs/calls.py", line 70 in warn
  File "/opt/touhy/lib/elzlibs/entities/clip.py", line 32 in updates
  File "/opt/touhy/lib/_elzlibs_gtk3/entities/clip.py", line 32 in change
  File "/opt/touhy/lib/_elzlibs_gtk3/entities/clip.py", line 41 in read
  File "/opt/touhy/lib/elzlibs/calls.py", line 126 in threaded
  File "/opt/touhy/lib/elzlibs/entities/clip.py", line 114 in read
  File "/opt/touhy/lib/elzlibs/entities/clip.py", line 100 in replacement
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 235 in text
  File "/opt/touhy/lib/elzlibs/images/gears.py", line 220 in clip
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 80 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 103 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 103 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 103 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 121 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 103 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 103 in perform
  File "/opt/touhy/lib/elzlibs/images/__init__.py", line 20 in icon
  File "/opt/touhy/lib/sencol/clips/__init__.py", line 21 in update
  File "/opt/touhy/lib/elzlibs/calls.py", line 126 in threaded
  File "/opt/touhy/lib/elzlibs/calls.py", line 199 in safely
  File "/opt/touhy/lib/elzlibs/calls.py", line 29 in __call__
  File "/opt/touhy/lib/elzlibs/calls.py", line 70 in warn
  File "/opt/touhy/lib/elzlibs/entities/clip.py", line 32 in updates
  File "/opt/touhy/lib/_elzlibs_gtk3/entities/clip.py", line 32 in change
  File "/opt/touhy/lib/_elzlibs_gtk3/entities/clip.py", line 41 in read
  File "/opt/touhy/lib/elzlibs/calls.py", line 126 in threaded
  File "/opt/touhy/lib/elzlibs/entities/clip.py", line 114 in read
  File "/opt/touhy/lib/elzlibs/entities/clip.py", line 100 in replacement
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 235 in text
  File "/opt/touhy/lib/elzlibs/images/gears.py", line 220 in clip
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 80 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 103 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 103 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 103 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 121 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 103 in perform
  File "/opt/touhy/lib/elzlibs/images/plans.py", line 103 in perform
  ...

Thread 0x00007efec37fe700 (most recent call first):
  File "/usr/lib/python3.7/socket.py", line 212 in accept
  File "/opt/touhy/lib/elzlibs/shared.py", line 89 in wait
  File "/usr/lib/python3.7/threading.py", line 870 in run
  File "/usr/lib/python3.7/threading.py", line 926 in _bootstrap_inner
  File "/usr/lib/python3.7/threading.py", line 890 in _bootstrap

Thread 0x00007efec3fff700 (most recent call first):
  File "/usr/lib/python3.7/socket.py", line 212 in accept
  File "/opt/touhy/lib/elzlibs/shared.py", line 89 in wait
  File "/usr/lib/python3.7/threading.py", line 870 in run
  File "/usr/lib/python3.7/threading.py", line 926 in _bootstrap_inner
  File "/usr/lib/python3.7/threading.py", line 890 in _bootstrap

Thread 0x00007efee0e3d700 (most recent call first):
  File "/usr/lib/python3.7/socket.py", line 212 in accept
  File "/opt/touhy/lib/elzlibs/shared.py", line 89 in wait
  File "/usr/lib/python3.7/threading.py", line 870 in run
  File "/usr/lib/python3.7/threading.py", line 926 in _bootstrap_inner
  File "/usr/lib/python3.7/threading.py", line 890 in _bootstrap

Thread 0x00007efee163e700 (most recent call first):
  File "/usr/lib/python3.7/socket.py", line 212 in accept
  File "/opt/touhy/lib/elzlibs/shared.py", line 89 in wait
  File "/usr/lib/python3.7/threading.py", line 870 in run
  File "/usr/lib/python3.7/threading.py", line 926 in _bootstrap_inner
  File "/usr/lib/python3.7/threading.py", line 890 in _bootstrap

Thread 0x00007efee1e3f700 (most recent call first):
  File "/usr/lib/python3.7/socket.py", line 212 in accept
  File "/opt/touhy/lib/elzlibs/shared.py", line 89 in wait
  File "/usr/lib/python3.7/threading.py", line 870 in run
  File "/usr/lib/python3.7/threading.py", line 926 in _bootstrap_inner
  File "/usr/lib/python3.7/threading.py", line 890 in _bootstrap

Thread 0x00007efee2640700 (most recent call first):
  File "/opt/touhy/lib/elzlibs/shared.py", line 223 in modchecker
  File "/usr/lib/python3.7/threading.py", line 870 in run
  File "/usr/lib/python3.7/threading.py", line 926 in _bootstrap_inner
  File "/usr/lib/python3.7/threading.py", line 890 in _bootstrap

Thread 0x00007efee2e41700 (most recent call first):
  File "/usr/lib/python3.7/socket.py", line 212 in accept
  File "/opt/touhy/lib/elzlibs/shared.py", line 89 in wait
  File "/usr/lib/python3.7/threading.py", line 870 in run
  File "/usr/lib/python3.7/threading.py", line 926 in _bootstrap_inner
  File "/usr/lib/python3.7/threading.py", line 890 in _bootstrap

Thread 0x00007efee3682700 (most recent call first):
  File "/opt/touhy/lib/elzlibs/calls.py", line 184 in wait
  File "/usr/lib/python3.7/threading.py", line 870 in run
  File "/usr/lib/python3.7/threading.py", line 926 in _bootstrap_inner
  File "/usr/lib/python3.7/threading.py", line 890 in _bootstrap

Thread 0x00007efee3e83700 (most recent call first):
  File "/usr/lib/python3.7/socket.py", line 212 in accept
  File "/opt/touhy/lib/elzlibs/shared.py", line 89 in wait
  File "/usr/lib/python3.7/threading.py", line 870 in run
  File "/usr/lib/python3.7/threading.py", line 926 in _bootstrap_inner
  File "/usr/lib/python3.7/threading.py", line 890 in _bootstrap

Thread 0x00007efee4684700 (most recent call first):
  File "/usr/lib/python3.7/socket.py", line 212 in accept
  File "/opt/touhy/lib/elzlibs/shared.py", line 89 in wait
  File "/usr/lib/python3.7/threading.py", line 870 in run
  File "/usr/lib/python3.7/threading.py", line 926 in _bootstrap_inner
  File "/usr/lib/python3.7/threading.py", line 890 in _bootstrap

Thread 0x00007efee947f740 (most recent call first):
  File "/usr/lib/python3.7/threading.py", line 296 in wait
  File "/usr/lib/python3.7/queue.py", line 170 in get
  File "/opt/touhy/lib/elzlibs/calls.py", line 210 in mainloop
  File "/opt/touhy/lib/elzlibs/utils.py", line 87 in selfdestructing
  File "/opt/touhy/lib/sencol/__main__.py", line 54 in <module>
  File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 728 in exec_module
  File "<frozen importlib._bootstrap>", line 677 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 967 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 983 in _find_and_load
  File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 1035 in _handle_fromlist
Abandon

Re-edit : et du coup, vu que j'étais précisément en train de faire quelques petites retouches sur ce qui semble être le module coupable, j'en profite pour inspecter ça… Ces deux lignes-là en particulier attirent mon attention :

  File "/opt/touhy/lib/_elzlibs_gtk3/entities/clip.py", line 32 in change
  File "/opt/touhy/lib/_elzlibs_gtk3/entities/clip.py", line 41 in read

Elles sont placées successivement, donc un appel suit immédiatement l'autre. Or, la méthode read n'appelle à aucun moment la méthode change. En revanche, à ce qui était jusque là la ligne 41 (c'est en train de changer ^^), on trouve « clip(selection).wait_for_text() », et la méthode change est branchée sur l'événement « owner-change » du presse-papier GTK. Puisque la méthode wait_for_text() peut laisser passer plusieurs itérations de la boucle principale GTK avant de renvoyer son résultat, je suppose donc que ce qui cause le crash doit être la modification du contenu du presse-papier pendant que sencol est en train de générer les images montrant ledit contenu (quand c'est du texte, il fait un petit aperçu où on voit les premiers caractères). Modification du contenu qui déclenche la mise à jour desdites images, et donc une sorte d'appel récursif.
Ceci dit, vu que c'est au niveau de la mécanique interne de GTK (et que tout se passe dans le thread GTK, pas de souci d'accès concurent à ce niveau), à part essayer de débrancher l'écouteur de modifications le temps de finir la lecture, je ne vois pas trop ce qui est faisable…

(En parlant de crash violents : d'après le collègue spécialiste dudit langage avec qui j'ai donné quelques cours au semestre dernier, en C#, il ne serait pas possible de récupérer d'une division par zéro ? yikes)

grim7reaper a écrit :

Là je pensais qu’on était dans un cas où on nous parlera plus jamais.

A priori, c'est bien le cas : ce sont les cas où le fichier qui servait à identifier la socket a été supprimé, donc je ne pense pas qu'il y ait moyen de la récupérer dans ce cas (ceci dit, j'ai tendance dans mon code à utiliser socket.sendto pour communiquer avec les socket DGRAM, donc sans passer par socket.connect, mais, je viens de vérifier, c'est tout à fait possible de connecter la socket d'abord, puis de supprimer le fichier, puis de continuer à envoyer des choses qui sont bien reçues).

Un comportement possiblement intelligent serait, plutôt qu'un message qui termine le thread directement, d'envoyer un message qui fait que le thread vérifie si son fichier existe toujours et se termine si ce n'est pas le cas ? (En utilisant dans ce cas la manip' sus-mentionnées pour que le message arrive après la suppression effective du fichier, tant qu'à faire).

D'ailleurs, ce même message pourrait aussi servir à vérifier que le programme est toujours à l'écoute, au cas où il aurait lamentablement crashé sans nettoyer proprement derrière lui…

grim7reaper a écrit :

Ça serait pas déconnant tongue
J’ai découvert qu’il y avait une espèce de guerre trébuchet vs catapulte similaire à tab vs space ou Vim vs Emacs tongue
Genre ici ^^

Oui, c'est pour ça que je disais ça smile
(Mais on me souffle dans l'oreillette que les gens de LineageOS y ont déjà pensé)

Sinon, on vient de me suggérer de partir plutôt sur les lanceurs de fusée. En anglais, ça s'appelle « Launch Vehicle » (pas forcément très cool à utiliser), mais aussi « Carrier Rocket ». Du coup, je me dit que « crocket » pourrait être un nom sympa, qu'en dites-vous ? ^^

Dernière modification par Elzen (Le 05/02/2020, à 20:16)

Hors ligne

#177 Le 06/02/2020, à 08:16

grim7reaper

Re : /* Topic des codeurs [9] */

Elzen a écrit :

Edit : ah, bah, j'ai fini par l'avoir ^^

Ho, en effet!
C’est bien la première fois que je vois ça ^^

Je pensais que t’aurais toujours une RecursionError propre avant ça.
Mais gars disait

The recursion limit is just a guard to limit the likelihood of a stack overflow, but if you allocate large objects on every stack frame, you can still overflow.

C’est peut-être ton cas ici.
Où alors c’est le code C de GTK qui crash et ça remonte jusqu’a Python (plus probable).

Elzen a écrit :

(En parlant de crash violents : d'après le collègue spécialiste dudit langage avec qui j'ai donné quelques cours au semestre dernier, en C#, il ne serait pas possible de récupérer d'une division par zéro ? yikes)

Bah en C c’est impossible aussi (sur des entiers du moins, encore qu’en POSIX y’a moyen de moyenner mais c’est un terrain miné).
Par contre je ne connais pas du tout C# mais ça semble possible.

Elzen a écrit :

c'est tout à fait possible de connecter la socket d'abord, puis de supprimer le fichier, puis de continuer à envoyer des choses qui sont bien reçues).

Je pense que c’est comme les fichiers, tant qu’il est ouvert il est pas réellement supprimé (même si tu rm, il existe toujours dans le kernel/sur le disque, juste tu ne le vois plus).
Ça peut-être utile des fois (annuler un rm mal placé) et des fois c’est chiant.


Elzen a écrit :

Sinon, on vient de me suggérer de partir plutôt sur les lanceurs de fusée. En anglais, ça s'appelle « Launch Vehicle » (pas forcément très cool à utiliser), mais aussi « Carrier Rocket ». Du coup, je me dit que « crocket » pourrait être un nom sympa, qu'en dites-vous ? ^^

Ouais , «crocket» c’est pas mal (même si je pense pas que beaucoup de gens feront le rapprochement ^^).

Dernière modification par grim7reaper (Le 06/02/2020, à 08:17)

Hors ligne

#178 Le 19/02/2020, à 16:22

Elzen

Re : /* Topic des codeurs [9] */

Allez, quelques nouvelles smile

grim7reaper a écrit :

Où alors c’est le code C de GTK qui crash et ça remonte jusqu’a Python (plus probable).

big_smile

J'ai fini par refaire de très gros bouts de la gestion du presse-papier, et, normalement, le souci ne devrait plus arriver. Je laisse tourner un moment avant de commiter pour être sûr ^^

Edit : commité entre temps, par contre j'ai quand même eu une belle stack overflow quand même hier soir, donc ç't'assez déprimant hmm Je n'ai pas regardé en détail, il reste possible que ça vienne d'un autre bout de code, mais d'un autre côté, c'est arrivé une seule fois depuis la rédaction de ce message, donc au minimum la fréquence d'arrivée a été réduite, c'est déjà ça.

grim7reaper a écrit :

Bah en C c’est impossible aussi (sur des entiers du moins, encore qu’en POSIX y’a moyen de moyenner mais c’est un terrain miné).

Oui, mais, C n'a pas de mécanisme natif de try/catch, à ma connaissance⁽¹⁾.

Autant, une stack overflow, je peux comprendre, mais qu'une division par zéro ne puisse pas être interceptée de cette façon-là, ça me semble étrange. Mais bon smile

grim7reaper a écrit :

Je pense que c’est comme les fichiers, tant qu’il est ouvert il est pas réellement supprimé (même si tu rm, il existe toujours dans le kernel/sur le disque, juste tu ne le vois plus).
Ça peut-être utile des fois (annuler un rm mal placé) et des fois c’est chiant.

Oui, je me souvenais de cet article ^^

Comment on s'y prend, pour l'annulage de rm, tiens ? Ça pourrait m'être utile de temps en temps :-°

Sinon, j'ai donc fait la manip' pour que les socket DGRAM s'arrêtent proprement en cas de suppression (j'envoie un caractère \5 pour dire au programme de vérifier si son fichier est toujours là ou pas, dites si vous voyez plus approprié comme message).
Le problème reste en revanche pour les sockets STREAM : les connexions des clients se ferment sans problème ; mais le thread qui attend les connexions, pour sa part, reste vraisemblablement à attendre éternellement (ce n'est pas un recv() mais un listen(), mais je n'sais pas interrompre ça non plus). Après, dans mon code en tout cas, les sockets STREAM sont très rarement supprimées, donc bon, 'pas très grave.

grim7reaper a écrit :

Ouais , «crocket» c’est pas mal (même si je pense pas que beaucoup de gens feront le rapprochement ^^).

Certes ^^ Il faudrait une jolie petite icône de fusée, pour le fun, mais je n'ai pas le talent pour ça. Il y a quand même « Carrier Rocket » écrit en toutes lettres comme titre de la fenêtre, donc c'est possiblement affiché par le gestionnaire de fenêtres au alt+tab (en tout cas, c'est le cas avec Xfwm).


Sinon, donc, globalement, après plusieurs jours d'utilisation, la nouvelle version me plaît bien smile
Par contre, la motivation manque beaucoup pour finir les trucs qui restent à faire dans SenCol, comme prévu :-° J'ai des entités en état de marche pour l'audio (avec AlsaAudio), le réseau (avec Wicd, d'ailleurs j'en ai profité pour faire du rapport de bugs), les manettes (SFML), le presse-papiers, les tablettes graphiques, la batterie et la température (avec ACPI pour ces deux derniers),  et il me reste à gérer les disques durs, l'écran, la souris d'une manière générale, et le clavier (pour ces deux derniers, j'aimerais que l'entité permette de simuler des déplacements/clics/appuis de touches, c'est tout à fait faisable, mais avec de la Xlib, donc pas enthousiasmant…).

Tiens, d'ailleurs, au sujet du clavier : en Python 2, j'utilisais xklavier pour récupérer la disposition active et des intitulés localisés pour les différentes dispositions disponibles. Sauf que ça passait par un module python-xklavier qui reposait lui-même sur GObject, donc forcément, ça n'a pas été porté. Je ne trouve pas de python3-xklavier à vue de nez, et il n'y a pas l'air non plus d'y avoir ce qui va bien dans GIrepository. Quelqu'un aurait des infos là-dessus ou sur une bibli à utiliser à la place ?

Edit : question subsidiaire, vu que grim a du *BSD sous la main smile Pour les supports de stockage, avec le noyau Linux, on a conventionnellement :

  • /dev/sd* pour les disques durs (c'était /dev/hd*, avant, non ? Pourquoi ça a changé ?),

  • /dev/mmcblk* pour les cartes SD,

  • /dev/sr* pour les CD/DVD,

  • /dev/fd* pour les disquettes (enfin, si ça existe encore, ces machins tongue),

  • /dev/loop* utilisé pour le montage des images disques (il me semble).

Par contre, il me semble (vagues souvenirs de Debian GNU/kFreeBSD ^^) que ça varie selon les noyaux, donc vous sauriez où on peut trouver une liste, ou si non, me dire ce que ça donne chez vous comme noms ?

(Sinon, une fois terminé SenCol, il me restera à faire une appli pour gérer un peu mieux les fenêtres (pour permettre de contrôler à la manette les fenêtres pour lesquelles c'est pertinent, passer des fenêtres en négatif quand c'est possible, ou effectuer des actions arbitraires, par exemple cacher la souris et les notifications quand un lecteur PDF est en plein écran), et quand ça ce sera fait, ce sera normalement fini pour les outils d'arrière-plan de l'environnement, et je pourrai enchaîner sur des applis un peu plus sympas)


(1) Ce qui me fait penser que j'avais à une époque un T-shirt (malheureusement plus utilisable) avec la mention :

while(!succeed=try());

Il y a d'autres langages que le C où ça marche, vu que try est un mot-clef réservé à peu près partout ailleurs ?

Dernière modification par Elzen (Le 21/02/2020, à 11:13)

Hors ligne

#179 Le 04/03/2020, à 12:36

grim7reaper

Re : /* Topic des codeurs [9] */

Elzen a écrit :

Edit : commité entre temps, par contre j'ai quand même eu une belle stack overflow quand même hier soir, donc ç't'assez déprimant hmm Je n'ai pas regardé en détail, il reste possible que ça vienne d'un autre bout de code, mais d'un autre côté, c'est arrivé une seule fois depuis la rédaction de ce message, donc au minimum la fréquence d'arrivée a été réduite, c'est déjà ça.

Ha, chiant.
Mais si c’est plus rare c’est déjà ça de pris.

Elzen a écrit :

Oui, mais, C n'a pas de mécanisme natif de try/catch, à ma connaissance⁽¹⁾.
Autant, une stack overflow, je peux comprendre, mais qu'une division par zéro ne puisse pas être interceptée de cette façon-là, ça me semble étrange. Mais bon smile

Doit y avoir moyen de faire des trucs avec SIGFPE et/ou longjmp, mais je pense que c’est pas fiable du tout.
Mais bon, comme je donnais dans mon lien ça semble gérable en C# en tout cas (le contraire serait surprenant en effet).

Elzen a écrit :

Comment on s'y prend, pour l'annulage de rm, tiens ? Ça pourrait m'être utile de temps en temps :-°

Annuler est peut-être pas le bon mot, mais si le fichier est encore ouvert par un programme, tu vas trouver le fd dans /proc/<PID>/fd/<FD> et tu peux le cat/cp pour récupérer son contenu.

Elzen a écrit :

(j'envoie un caractère \5 pour dire au programme de vérifier si son fichier est toujours là ou pas, dites si vous voyez plus approprié comme message).

EOT: \4

Elzen a écrit :

mais le thread qui attend les connexions, pour sa part, reste vraisemblablement à attendre éternellement (ce n'est pas un recv() mais un listen(), mais je n'sais pas interrompre ça non plus).

C’est bloquant le listen? Me semblait que c’est le accept qui l'était.
shutdown devrait faire le taf pourtant.

Elzen a écrit :

Il y a quand même « Carrier Rocket » écrit en toutes lettres comme titre de la fenêtre, donc c'est possiblement affiché par le gestionnaire de fenêtres

Ouais donc ça aide à la compréhension, en effet ^^

Elzen a écrit :

Quelqu'un aurait des infos là-dessus ou sur une bibli à utiliser à la place ?

Je ne connais pas d’alternative, et une rapide recherche n’a rien donné.
Tu l’utilisais pour faire quoi?

Elzen a écrit :

Edit : question subsidiaire, vu que grim a du *BSD sous la main smile Pour les supports de stockage, avec le noyau Linux, on a conventionnellement :

  • /dev/sd* pour les disques durs (c'était /dev/hd*, avant, non ? Pourquoi ça a changé ?),

  • /dev/mmcblk* pour les cartes SD,

  • /dev/sr* pour les CD/DVD,

  • /dev/fd* pour les disquettes (enfin, si ça existe encore, ces machins tongue),

  • /dev/loop* utilisé pour le montage des images disques (il me semble).

Par contre, il me semble (vagues souvenirs de Debian GNU/kFreeBSD ^^) que ça varie selon les noyaux, donc vous sauriez où on peut trouver une liste, ou si non, me dire ce que ça donne chez vous comme noms ?

Pour le sd vs hd c’est la différence entre SCSI (sd) et IDE (hd) (cf. ici)
Les loop device c’est utilisé pour le montage de disque en effet, mais pas uniquement.

Les *BSD que j’ai sous la main ce sont des serveurs remote donc jpeux pas vraiment vérifier pour lecteur CD ou disquette mais en gros j’ai vu du da* et du ada*.
Ça semble correspondre à ce que je vois .


Elzen a écrit :

(1) Ce qui me fait penser que j'avais à une époque un T-shirt (malheureusement plus utilisable) avec la mention :

while(!succeed=try());

Il y a d'autres langages que le C où ça marche, vu que try est un mot-clef réservé à peu près partout ailleurs ?

Ruby et Perl je pense (pour rester dans de la syntaxe C-like).

Hors ligne