Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

/* Topic des codeurs [9] */

Elzen

Ben, un des objectifs que j'avais en tête en commençant à casser un peu tout pour finir par arriver sur la structure que je vous ai décrit ci-dessus, c'est de permettre de changer de bibliothèque graphique sans trop que ça revienne à tout réécrire complètement.
Le truc chouette avec cette structure-là, c'est que (sous réserve que Qt5 fournisse un équivalent des GtkSocket/GtkPlug pour supporter le XEmbed, ce qui est probable mais je n'ai pas vérifié), ce sera tout à fait possible de commencer une version Qt5 par petits bouts, en gardant GTK en fallback pour tout ce qui n'est pas encore prêt.

Pour le déploiement, ça dépend ce que tu entends par là. Si c'est juste tester les applis une à une, il suffit de cloner leur dépôt, mais ça, je suppose que tu savais déjà 🙂
Pour cloner l'ensemble du projet d'un coup, comme je disais, il y a un dépôt « principal » qui contient les bibliothèques et quelques scripts en plus :
– check.py récupère ou met à jour les dépôts de toutes les autres applis d'un coup, en recréant les liens physiques entre les fichiers communs si besoin,
– build.py permet de créer à l'endroit indiqué un répertoire contenant trois répertoires bin/, lib/ et share/ contenant tout le nécessaire pour que tout marche correctement ensemble (il suffit donc d'ajouter le bin/ à $PATH et le lib/ à $PYTHONPATH).
– workenv.sh lance build.py vers un répertoire indiqué, et te lance un autre shell dans lequel tu as un Makefile et les bonnes variables d'environnement bien réglées. Je m'en sers pour bosser dans un tmpfs pendant que je casse des trucs sans toucher à la version « installée ».
A priori, c'est ce que tu veux. Il me reste un paquet de trucs à nettoyer dans ce dépôt principal, je tâche de faire ça d'ici à ce week-end et je vous poserai le lien là.

Par contre, si par « déploiement » tu veux dire faire en sorte d'avoir une session complète directement utilisable, ça n'existe pas pour l'instant, chez moi je passe par un ~/.xsession fait à la main (d'un autre côté, je n'ai pas d'outils pour tout dans Touhy. Typiquement, je n'ai pas poussé le vice jusqu'à développer mon propre gestionnaire de fenêtres, pour le moment j'utilise celui d'Xfce 🙂)

grim7reaper

Dafyd a écrit@Grim
Je vais me renseigner sur la méthode que tu mentionnes, je ne la connais pas. Est-ce portable ?

Ni plus ni moins que les thread je dirais (encore que, depuis C11 y’a les threads dans la stdlib, mais bon la dernière fois que j’ai regardé Windows ils supportaient pas C99, donc C11…).
poll et select c’est du POSIX 2001 il me semble, mais après chaque OS à son mecanisme plus efficace (mais sur le même principe) : epoll pour Linux, kqueue pour BSD, …

Elzen a écrit(Et désolé Grim, j'te rajoute encore un pavé de plus à lire :-°)

:p

J’avance, j’avance.

Voilà quelques remarques sur ce que j’ai lu pour l’instant :

Elzen a écrit J'envisagerais bien d'en ajouter un de plus qui permette d'afficher sur la sortie standard si le nombre de lignes est inférieur à la taille du terminal et de passer sur less dans le cas contraire, mais ça m'embête un peu parce que l'action attendue pour passer d'un fichier à l'autre ne serait du coup pas forcément toujours la même, donc pas glop niveau cohérence…

Comme "less --quit-if-one-screen"?

Elzen a écrit(Notez que, en vrai, vous pouvez mettre autant de - que vous voulez, zéro compris, pour les options, mon parseur commence par les virer).

Tu veux dire que je peux écrire "midote single"? Comment il sait que "single" c’est une option et non pas un nom de fichier à ajouter à la playlist?

Elzen a écritLe daemon a besoin de python3-psutil pour lire les arguments des autres commandes (requis).

Si tu as seulement besoin de ça, il suffit pas de lire "/proc/PID/cmdline"?
Ça éviterai une dépendance pour si peu.

Elzen

grim7reaper a écritComme "less --quit-if-one-screen"?

Tiens, je ne connaissais pas…

Ceci dit, à vue de nez, ce n'est pas exactement ce que j'essayais de décrire, il faudra que j'y reréfléchisse pour préciser ça 🙂

grim7reaper a écritTu veux dire que je peux écrire "midote single"? Comment il sait que "single" c’est une option et non pas un nom de fichier à ajouter à la playlist?

C'est ça.

Le comportement par défaut, c'est que tout ce qui ressemble à « machin=truc » ou qui a été défini comme étant un paramètre n'attendant pas nécessairement de valeur (comme « single », donc) est considéré comme une option⁽¹⁾, et tout le reste comme possiblement un fichier (encore que je pourrais assez facilement restreindre à ce qui se trouve effectivement sur le disque, en fait, pour le coup, vu qu'un lecteur média va rarement créer des fichiers lui-même ^^)

C'est en partie pour ça que j'ai mis une option « then=FILE », qui permet d'échapper un nom de fichier qui aurait sinon été reconnu comme une option.

Après, il y a sans doute des tas de trucs à revoir dans ma gestion des options, je tâcherai de creuser le sujet un jour. En attendant, je mets des -- dans mon code (quand ça forke pour lancer le daemon, par exemple), et je n'en mets pas quand je lance des trucs moi-même dans le terminal.

grim7reaper a écritSi tu as seulement besoin de ça, il suffit pas de lire "/proc/PID/cmdline"?
Ça éviterai une dépendance pour si peu.

Ah beh oui, ça a l'air tout à fait faisable, il faut juste que je trouve le caractère séparateur pour parser ça comme il faut. Je me suis davantage servi de psutil, à une époque, mais je crois qu'en l'état, je n'utilise que ça (je devais m'en servir, avant d'utiliser des sockets, pour chercher parmi la liste des processus actif si je trouvais un daemon en train de tourner ou pas, mais du coup ce bout-là a sauté).

D'un autre côté, /proc est spécifique au noyau Linux, non ? psutil est aussi compatible BSD, paraît-il, et j'ambitionne que Touhy puisse tourner au moins sous Debian GNU/kFreeBSD un jour (si ce truc existe encore quand je sortira une version présentable :-°) (mais d'un autre côté, la dernière fois que j'ai regardé, le paquet python(3)-psutil n'était pas porté dans les dépôts, donc de toute façon…)

(1) Edit : en fait, pour être un peu plus précis : j'ai un parseur d'arguments dont le comportement est le suivant :
– Virer tous les - au début pour voir et chercher s'il y a un = dans l'argument ou pas.
– S'il y en a un, on va considérer que c'est clef=valeur, et on regarde si on a des instructions pour parser la valeur en fonction de la clef (par exemple, c'est référencé que la valeur de --jump doit être un entier, donc si la clef est « jump », on parse la valeur comme entier), et on renvoie { clef, valeur }.
– S'il n'y en a pas, on regarde si cet argument correspond à une clef connue ou pas, et si oui, on prend sa valeur par défaut, et on renvoie aussi { clef, valeur }.
– Si ça ne correspond pas à une clef connu, mais que ça ressemble à « nomachin » ou « no-machin » où « machin » est une clef connue dont la valeur par défaut est un booléen, on renvoie { machin, non valeur }.
– Si aucun de ces cas n'a été rencontré, je reprends l'argument d'origine inchangé (avec ses - s'il y en avait), et on renvoie { None, argument }.
Et le programme doit ensuite se dépatouiller avec ça.

J'hésite à changer un peu ce comportement, par exemple en renvoyant { None, argument } en cas d'argument de la forme « machin=truc » si « machin » ne correspond à aucune clef connue… Toute suggestion bienvenue, pour ça aussi 🙂

grim7reaper

Elzen a écritC'est en partie pour ça que j'ai mis une option « then=FILE », qui permet d'échapper un nom de fichier qui aurait sinon été reconnu comme une option.

Ha, oui le --then sert à ça, bien vu.

Tiens d’ailleurs vu la description que tu en fais, j’ai l’impression que tu as fait un parser maison.
argparse te convenait pas?

Elzen a écritAh beh oui, ça a l'air tout à fait faisable, il faut juste que je trouve le caractère séparateur pour parser ça comme il faut.

un NUL ASCII, \0

man 5 proc a écrit /proc/[pid]/cmdline
This read-only file holds the complete command line for the process, unless the process is a zombie. In the latter case, there is nothing in this file: that is, a read on this file will return 0 characters. The command-line arguments appear in this file as a set of strings separated by null bytes ('\0'), with a further null byte after the last string.

Elzen a écritD'un autre côté, /proc est spécifique au noyau Linux, non ?

Oui et non, y’a énormément de trucs dans /proc sous Linux et y’a pas tout sur BSD, mais y’a quand même un minimum de compat’ il me semble (je viens de tester rapidos sur un FreeBSD et un DragonFly BSD là et j’ai bien cmdline)
Donc tant que les besoins reste basique comme ça, ça devrait aller.

Elzen

grim7reaper a écritTiens d’ailleurs vu la description que tu en fais, j’ai l’impression que tu as fait un parser maison.
argparse te convenait pas?

J'ai effectivement un parseur maison. Je me souviens que j'utilisais argparse fut une époque, je ne sais plus trop pourquoi j'ai changé (sans doute pour avoir plus souple/moins strict), mais disons que le gros avantage d'argparse, de mémoire, c'est de gérer facilement les combinaisons d'options courtes, du style « -argb » au lieu de « --alpha --red --green --blue ». Comme je n'ai pas l'intention d'utiliser des trucs de ce style-là, c'est typiquement un cas où refaire un parseur était aussi, voire plus simple que d'en utiliser un existant :-°

grim7reaper a écritOui et non, y’a énormément de trucs dans /proc sous Linux et y’a pas tout sur BSD, mais y’a quand même un minimum de compat’ il me semble (je viens de tester rapidos sur un FreeBSD et un DragonFly BSD là et j’ai bien cmdline)
Donc tant que les besoins reste basique comme ça, ça devrait aller.

Merci pour les précisions 🙂

Après vérif, je n'utilise pas que les arguments de la commande : j'utilise aussi le cwd (typiquement, quand tu demandes à midote d'ouvrir un fichier, il faut avoir son adresse à partir de l'endroit d'où lance la commande, pas à partir de là où tourne le daemon), et potentiellement aussi l'environnement. Mais à vue de nez, ça a l'air dans /proc aussi (je te laisse me confirmer la compatibilité si tu as du *BSD sous la main, ce qui n'est présentement pas mon cas), donc, a priori, pas spécialement de problème pour virer la dépendance.

Après, je me dis que parser systématiquement l'environnement, alors qu'en pratique je ne m'en sers jamais (du moins pour l'instant), ce n'est pas forcément très utile… Je vais peut-être, soit le virer, soit remplacer le dictionnaire par une fonction qui ne le parse et le renvoie que si on l'appelle. Après, je doute que ça change grand chose, mais bon.

Sinon, je viens de pousser quelques petites améliorations sur les fenêtres que je devais faire pour Gemetic (étant donné que la fenêtre du bureau reprend pas mal de code des fenêtres classiques, ça simplifie beaucoup ^^), et j'en ai profité pour faire en sorte que, si c'est la même appli qui gère la fenêtre et le composant qui va dedans, ça s'ajoute directement plutôt que de passer par XEmbed, c'est quand même plus simple comme ça. Et du coup j'en ai profité pour vérifier que le clignotement bizarre qui avait lieu au scroll venait vraisemblablement de ça, il n'a plus lieu maintenant.

Par contre, Midote continue de temps en temps de me planter entre les mains avec ce magnifique retour :

Gdk-Message: 19:20:37.820: midote: Fatal IO error 0 (Succès) on X server :0.0.

Je n'ai pas encore identifié d'où ça venait.

Dafyd

Accès concurrents à la socket de X11 ?

Elzen

Normalement, tout ce qui est graphique se fait dans le même thread… j'ai pu louper un truc, mais si c'est le cas, je n'ai pas encore trouvé où.
Mais j'aime toujours quand le message d'erreur est « Succès » 😃

Bon, sinon, voilà, j'ai fini de nettoyer le dépôt principal. Donc si quelqu'un a envie de tester tout d'un coup, c'est là :

git clone git://fadrienn.irlnc.org/elzapps/touhy

Actuellement, ce dépôt permet de récupérer :
– show, qui est toujours dans le même état que lors du dernier post où on en a parlé⁽¹⁾,
– une très vague ébauche de clfb,
– sencol, qui actuellement sait fournir des entités pour la batterie, les capteurs de températures, les manettes et les presses-papiers,
– midote, qui à part cette erreur cryptique sus-mentionnée marche plutôt bien, même s'il reste des trucs à améliorer ça et là,
– un début de gemetic, encore pas mal incomplet pour l'instant, mais qui commence à ressembler à quelque chose si on fait sa conf' à la main.
Je relisterai les dépôts pour les autres applis quand elles seront dans un état vaguement utilisable 🙂

Dafyd, si tu veux éventuellement pouvoir contribuer, envoie-moi une clef SSh et dis-moi si tu préfères un compte sur mon serveur ou simplement un accès au compte guest 🙂

@Grim : du coup, modif faite. Je n'ai pas complètement retiré psutil : s'il est présent, il est utilisé (ça me paraît plus sûr au cas où), sinon, ça parse manuellement depuis /proc. À vue de nez, ça marche bien 🙂

(1) À un détail près : j'ai viré la partie Xlib de ce dépôt directement. Maintenant, pour lire le contenu du presse-papier via show, il faut soit que sencol soit lancé et fournisse les entités adéquates, soit installer tout au même endroit pour que show bénéficie de _elzlibs_gtk3 ou _elzlibs_xlib. Ça me paraissait plus simple comme ça.

grim7reaper

Bon j’ai fini de tout lire \o/

Sacré boulot, ça semble bien complet (et complexe par endroits ^^")

Elzen a écritEn même temps, c'est le seul bout de doc digne de ce nom existant sur ce que je fais actuellement, donc ce n'est carrément pas assez, mais bon.

Ça mériterait même de devenir une vraie doc, dans le repo Git et/ou dans la section Touhy de ton site 🙂

Elzen a écritÀ vue de nez, j'ai une source de segfault dans le module image (ça n'a pas l'air systématique, mais comme sencol fait pas mal de traitement d'image (pour les icônes liées au presse-papier ou aux capteurs de température, par exemple), le plantage finit par être quasi-systématique), et je n'arrive pas encore à identifier où précisément pour l'instant. Si quelqu'un veut aider à ça, n'hésitez surtout pas…

Bah si t’a une image/script avec lequel t’arrives à reproduire fréquemment, je veux bien jeter un œil 🙂

Pour les submodules Git en effet, ça répond pas à ton besoin (vu que tu veux prendre des bouts de repo), pour ça faudrait que tu découpes le repo communs en repo plus petits.

Pour les venv Python, en effet ça ne gère que les deps Python. Ça peut éventuellement compiler des bouts de C mais ce n’est pas un package manager système (et ce n’est pas son but).

Le gros avantage c’est que ça permet d’avoir plusieurs versions d’une même bibliothèque Python en parallèle.
Typiquement, je crois que tu développes sur Debian, donc tes versions packagées sont «vieilles» et si j’installe les paquets équivalent sur mon Archlinux y’a une chance non-nulle que ça ne fonctionne pas avec ton code 🙁
La solution c’est que je sache quelle version tu utilises, et que je l’installe dans un venv (comme ça, ça ne conflicte pas avec la version packagée par ma distrib’).
Du coup, un requirements.txt ça te serais pas forcément utile (vu que tu développes contre ce qui est packagé chez toi), mais ça peut aider les autres à savoir quoi installer (au lieu de deviner ta version Debian, chercher quelle version est packagée chez toi, …) rapidement 🙂

Elzen a écritEn fait, si tu n'as pas de boucle principale GTK démarrée, mon truc avait l'air de marcher nickel, d'où la difficulté à trouver l'origine précise du souci dans mes tests… par contre, si la boucle principale GTK tourne dans un thread et que j'appelle certaines fonctions de traitement d'images (je n'ai pas poussé jusqu'à identifier lesquelles précisément) depuis un autre, segfault immédiate sur mon jeu de test.

Ha, plus besoin d’aide donc.

Ouais, en général les bibliothèques graphiques aiment bien que leur tambouille restent dans leur thread principal.

Elzen a écritTiens, d'ailleurs, l'un des inconvénient de la dernière version de ma bibliothèque qui utilise des socket dans tous les sens pour faire communiquer les applis entre elles, c'est que j'ouvre des tas de threads, maintenant… Et que je ne les referme pas toujours, d'ailleurs : si par exemple j'ai ouvert une socket DGRAM et que j'ai un thread qui attend des messages dessus, puis que pour une raison ou pour une autre, il m'arrive de devoir effacer le fichier, le thread reste en attente d'un message qui du coup n'arrivera plus jamais…
Toute suggestion pour améliorer ça sera la bienvenue.

Bah le souci c’est que tu fermes pas la socket non?
IIRC, si tu as un processus bloqué en lecture sur une socket et que l’autre bout (qui écrit) appel close, bah celui qui attends des données va être notifié.

Ça marche comme ça en C il me semble (pas de raison que ça diffère en Python) :

man 3 recv a écrit RETURN VALUE
Upon successful completion, recv() shall return the length of the message in bytes. If no messages are available to be received and the peer has performed an orderly shutdown, recv() shall return 0. Otherwise, −1 shall be returned and errno set to indicate the error.

Elzen a écrit Sauf que, comme souvent avec la XLib, ça a l'air compliqué, et je peine à trouver de la doc' compréhensible (voire de la doc' tout court). Donc, si quelqu'un a des pistes, je prends smile

Le gros de la doc’ ce sont les pages de man, sinon y’a des vieux bouquins sur la Xlib (je dois avoir quelques un en PDF qui traîne sur mon disque).
Y’a ce site aussi (je me souviens l’avoir utilisé pendant mes TP de Xlib ^^).

Elzen a écrit c'est typiquement un cas où refaire un parseur était aussi, voire plus simple que d'en utiliser un existant :-°

Je peux comprendre si le truc supporte pas ce que tu veux faire.
Mais sinon c’est plus pratique d’utiliser un truc standard (surtout si tu veux des regards/contributions externes, ça diminue le coût d’entrée).

Elzen a écrit(je te laisse me confirmer la compatibilité si tu as du *BSD sous la main, ce qui n'est présentement pas mon cas)

Nope, y’a pas ça sous BSD.

FreeBSD :

% ls /proc/curproc/
cmdline ctl     dbregs  etype   file    fpregs  map     mem     note    notepg  osrel   regs    rlimit  status

DragonFly BSD :

% ls /proc/curproc/
cmdline ctl     dbregs  etype   file    fpregs  map     mem     note    notepg  regs    rlimit  status

Elzen

grim7reaper a écritBon j’ai fini de tout lire \o/

Sacré boulot, ça semble bien complet (et complexe par endroits ^^")

Bravo et merci 😃

grim7reaper a écritÇa mériterait même de devenir une vraie doc, dans le repo Git et/ou dans la section Touhy de ton site 🙂

Ouaip.

D'un autre côté, mon site entier mériterait que je me remette à taffer dessus, et le reste du serveur avec (il est toujours sous Jessie, je crois bien :-°)
Il faudra que je me trouve de la motiv' un jour. En attendant, je suis déjà content d'avoir écrit ça là, d'autant que l'essentiel des gens que c'est susceptible d'intéresser dans l'immédiat connaissent ce sujet, à ma connaissance.

grim7reaper a écritBah si t’a une image/script avec lequel t’arrives à reproduire fréquemment, je veux bien jeter un œil 🙂

Comme tu l'as remarqué plus bas, c'est a priori réglé pour ce souci-là. Par contre, si tu veux m'aider à trouver l'origine d'erreurs cryptiques, il y a le souci de midote sus-mentionné. Mais je n'ai pas encore identifié de moyen de le déclencher à coup sûr, donc bon.

grim7reaper a écritTypiquement, je crois que tu développes sur Debian, donc tes versions packagées sont «vieilles» et si j’installe les paquets équivalent sur mon Archlinux y’a une chance non-nulle que ça ne fonctionne pas avec ton code 🙁

Déjà, je suis sous Sid, donc pas si vieilles que ça 😛

Et puis, a priori, les trucs que j'utilise sont plutôt stables… en tout cas, je ne me souviens pas de masse de trucs qui ont changé de fonctionnement depuis que je taffe là-dessus. Mais si tu repères des incompatibilités, signale-les moi, je tâcherai de commencer à tenir une liste à jour 🙂

grim7reaper a écritBah le souci c’est que tu fermes pas la socket non?
IIRC, si tu as un processus bloqué en lecture sur une socket et que l’autre bout (qui écrit) appel close, bah celui qui attends des données va être notifié.

Pour les SOCK_STREAM, oui, a priori, s'il y a un client connecté et que je ferme un bout, l'autre est notifié.

En revanche, pour les SOCK_DGRAM pour lesquels il n'y a pas de client à l'autre bout (il n'y a que le prog qui ouvre la socket qui attend des messages), et pour le thread qui attend la connexion de clients sur une SOCK_STREAM, soit il n'y a rien, soit je ne sais pas comment on vérifie ça.

grim7reaper a écritLe gros de la doc’ ce sont les pages de man, sinon y’a des vieux bouquins sur la Xlib (je dois avoir quelques un en PDF qui traîne sur mon disque).
Y’a ce site aussi (je me souviens l’avoir utilisé pendant mes TP de Xlib ^^).

Merci, je m'y plongerai quand j'aurai le courage 🙂

grim7reaper a écritNope, y’a pas ça sous BSD.

Arf… pour l'environnement, je m'en fiche un peu, je ne m'en sers pas pour l'instant. Par contre, pour le cwd, tu sais s'il y a un autre moyen de le récupérer ?

Sinon, mon Gemetic commence vaguement à ressembler à ce à quoi il devrait, ce qui veut dire que je ne devrais plus trop trop tarder à virer ma version intermédiaire cassée (mais qui est encore en avance de quelques trucs utiles que je n'ai pas encore refait, comme la gestion du réseau par sencol) pour utiliser la nouvelle version comme environnement principale 🙂

grim7reaper

Elzen a écritPar contre, si tu veux m'aider à trouver l'origine d'erreurs cryptiques, il y a le souci de midote sus-mentionné. Mais je n'ai pas encore identifié de moyen de le déclencher à coup sûr, donc bon.

Ouais, ce genre d’erreur est très chiant à comprendre, surtout si t’arrives pas à le reproduire :/

Elzen a écritEt puis, a priori, les trucs que j'utilise sont plutôt stables… en tout cas, je ne me souviens pas de masse de trucs qui ont changé de fonctionnement depuis que je taffe là-dessus. Mais si tu repères des incompatibilités, signale-les moi, je tâcherai de commencer à tenir une liste à jour 🙂

Ok, je te dirais si j’ai des soucis en testant.

Elzen a écritEn revanche, pour les SOCK_DGRAM pour lesquels il n'y a pas de client à l'autre bout (il n'y a que le prog qui ouvre la socket qui attend des messages), et pour le thread qui attend la connexion de clients sur une SOCK_STREAM, soit il n'y a rien, soit je ne sais pas comment on vérifie ça.

Ha oui sur de l’UDP c’est peut-être chiant.
Tu peux pas utiliser du TCP à la place?
Au pire, si tu es coincé avec l’UDP on pourrait imaginer que t’envoie un dernier message "goodbye" quand le thread émetteur se termine.

Elzen a écritArf… pour l'environnement, je m'en fiche un peu, je ne m'en sers pas pour l'instant. Par contre, pour le cwd, tu sais s'il y a un autre moyen de le récupérer ?

J’ai regardé vite fait et soit tu lances une commande via subprocess et tu parses la sortie…, soit c‘est relou (faut taper sur une fonction C depuis Python).
Vaut peut-être mieux rester avec psutils du coup…

Elzen

grim7reaper a écritOuais, ce genre d’erreur est très chiant à comprendre, surtout si t’arrives pas à le reproduire :/

En l'occurrence, j'ai de bonnes raisons de penser que c'est un souci de thread. J'ai dû oublier le décorateur qui force à ce que ce soit dans le thread GTK sur une des fonctions quelque part. Je vais relire attentivement le code et essayer de trouver où…

J'ai trois autres soucis plus ou moins du même genre à résoudre avant que ça ne commence à devenir utilisable au quotidien :
– quand je laisse tourner sencol longtemps (avec tous les capteurs actuels actifs, je n'ai pas encore cherché lequel en particulier causait ça), ça finit au bout d'un temps aléatoire par me faire une stack overflow irrécupérable au chargement d'une image,
– des trucs dans gemetic semblent parfois avoir quelques petits soucis de mise à jour (par exemple, j'affiche une horloge dans un coin, il arrive qu'elle reste coincée sur une heure donnée alors que le reste continue de marcher correctement, de manière aléatoire),
– parfois, sans que je sache si c'est le même souci plus généralisé ou pas, gemetic s'arrête complètement de fonctionner, plus rien ne se met à jour graphiquement et les clics n'ont plus aucun effet.
Je n'ai encore investigué rien de tout ça, ça risque d'être dans mes prochains objectifs.

grim7reaper a écritOk, je te dirais si j’ai des soucis en testant.

Merci 🙂

grim7reaper a écritHa oui sur de l’UDP c’est peut-être chiant.
Tu peux pas utiliser du TCP à la place?
Au pire, si tu es coincé avec l’UDP on pourrait imaginer que t’envoie un dernier message "goodbye" quand le thread émetteur se termine.

Ouaip, mais d'un autre côté, je n'veux pas que n'importe quelle appli extérieure puisse arrêter le thread non plus 🙂

La version UDP me paraissait plus pratique à l'usage, avant de prendre en compte ce problème. Ça peut éventuellement être envisageable de changer. D'un autre côté, comme je le disais précédemment, ça, c'est de l'ordre des tâches de fond, je pourrai corriger ça plus tard sans que ça ne remette en cause la façon de fonctionner des programmes. Donc même s'il faudra que je m'occupe de ça à un moment ou à un autre, pour l'instant, j'ai tendance à procrastiner ça en m'occupant d'ajouter des fonctionnalités un peu partout, c'est plus motivant 🙂

D'ailleurs, à ce sujet, je viens d'ajouter le dépôt pour Catapult (c'est un chouette nom de lanceur, non ? 😛)

En l'état, ce nouveau logiciel affiche un « dock » gérable au clavier (fenêtre épinglée minimisée par défaut et qui se reminimise toute seule quand elle perd le focus ; mais qui peut aussi être affiché en permanence en l'embarquant dans un panel de Gemetic) permettant d'interagir avec les entités. En plus du fonctionnement classique, les icônes du dock peuvent afficher de petites popups dont le contenu est géré par les programmes correspondants, avec du XEmbed.
Chaque icône peut gérer plusieurs entités (on peut passer de l'une à l'autre en scrollant latéralement, ou avec les touches directionnelles au clavier), à condition qu'on interagisse avec toutes de la même manière. Catapult permet d'ailleurs, pour compléter, d'exposer plusieurs lanceurs comme des entités, et de lancer un programme si l'icône ne contient aucune entité pour l'instant. Du coup, j'ai déjà un midote hyper-bien intégré à l'environnement, et je compte faire pareil pour les autres applis ensuite 🙂

(Je prévois quelques fonctionnalités supplémentaires pour Catapult quand j'aurai la motiv' pour, notamment une meilleure gestion des fenêtres dans le dock, et quelques trucs chouettes en tâche de fond, du style, si je repère qu'un autre programme essaye d'accéder à une entité ou à un menu qui n'existe pas (c'est possible, non, avec inotify, de repérer les tentatives d'accès à un fichier ?), lancer automatiquement ledit programme en tâche de fond pour que ça marche de façon transparente. Mais bon, ce que j'ai fait là suffit pour l'instant pour un premier jet).

Quand j'aurai terminé les quelques trucs en cours, il faudra que je pense à faire une petite capture vidéo d'écran pour montrer un peu ce que ça donne en termes de possibilités, je pense que ça peut être assez classe.

grim7reaper a écritVaut peut-être mieux rester avec psutils du coup…

Ben, en l'état, je laisse tel que c'est : utiliser psutil s'il est installé, sinon faire « à la main » depuis /proc. Sous GNU/Linux, ça ne devrait pas poser de problème ; sous *BSD, ça va gêner pour midote, mais pas tant que ça⁽¹⁾, et comme les autres applis n'utilisent pas le cwd dans l'immédiat, ça tournera normalement (et il suffira d'installer psutil pour régler le fonctionnement de midote). Mais je verrai plus tard pour intégrer un contournement quand même, si c'est faisable. Mais ça risque d'attendre longtemps, du coup.

(1) elzlibs.daemon se contente de récupérer le cwd avec un « os.path.realpath(/proc/PID/cwd) » et de le passer à la fonction de lecture des arguments. C'est elle qui, ensuite, a la responsabilité d'os.path.join les arguments qui ont l'air d'être des fichiers s'il y a lieu. Du coup, tout ce que ça va faire en l'état, c'est que les chemins relatifs passés à midote par la ligne de commande seront lus au mauvais endroit. Le truc restera utilisable en lui filant des chemins absolus ou en utilisant l'outil graphique pour ajouter des morceaux à la playlist.

grim7reaper

Elzen a écrit – quand je laisse tourner sencol longtemps (avec tous les capteurs actuels actifs, je n'ai pas encore cherché lequel en particulier causait ça), ça finit au bout d'un temps aléatoire par me faire une stack overflow irrécupérable au chargement d'une image,

Y’a des stack overfow en Python oO?

Elzen a écrit – des trucs dans gemetic semblent parfois avoir quelques petits soucis de mise à jour (par exemple, j'affiche une horloge dans un coin, il arrive qu'elle reste coincée sur une heure donnée alors que le reste continue de marcher correctement, de manière aléatoire),
– parfois, sans que je sache si c'est le même souci plus généralisé ou pas, gemetic s'arrête complètement de fonctionner, plus rien ne se met à jour graphiquement et les clics n'ont plus aucun effet.

Ça ressemble à un thread qui se bloque ça, nan?

Elzen a écritOuaip, mais d'un autre côté, je n'veux pas que n'importe quelle appli extérieure puisse arrêter le thread non plus 🙂

Bah TCP ou UDP, c’est possible hein.
Sauf à faire communiquer tes process avec un protocole authentifié et chiffré, ça me semble définir à empêcher.
Après, je pense que c’est un faux problème, y’a pas de risque que ça arrive par erreur (et si c’est voulu, y’a d’autre moyen de tuer le thread/process de toutes façon :p)

Elzen a écrit D'ailleurs, à ce sujet, je viens d'ajouter le dépôt pour Catapult (c'est un chouette nom de lanceur, non ? 😛)

Ouais, d’ailleur KDE3 avait Katapult 😛

Elzen a écrit(c'est possible, non, avec inotify, de repérer les tentatives d'accès à un fichier ?)

T’entends quoi par là?
Je pense pas que tu puisses être notifier sur un accès de fichier qui n’existe pas (si c’est ça la question).

Elzen

grim7reaper a écritY’a des stack overfow en Python oO?

Beh on dirait. D'un autre côté, il y a des langages où ce n'est pas possible ? Il y a des langages spécialisés pour la récursivité, mais il y a toujours une limite de taille de pile, non ?

grim7reaper a écritÇa ressemble à un thread qui se bloque ça, nan?

Alors, dans le cas de l'horloge, pas du tout, c'est juste moi qui ai été con :-° (oublié de brancher un écouteur, ce qui faisait qu'elle n'était mise à jour qu'en cas de changement de bureau ^^")

Mais sinon, fort possible. J'ai fait quelques petites rectifs de code (notamment, en mettant un RLock automatique sur la fonction qui en avait besoin), et je n'ai pas revu d'erreurs de ce type depuis en cours de fonctionnement de programme (même s'il reste peut-être des GdkError bizarres au démarrage ?). Je laisse tourner un brin pour essayer de voir s'il y a d'autres ajustements à faire, et je commite ça…

grim7reaper a écritBah TCP ou UDP, c’est possible hein.
Sauf à faire communiquer tes process avec un protocole authentifié et chiffré, ça me semble définir à empêcher.
Après, je pense que c’est un faux problème, y’a pas de risque que ça arrive par erreur (et si c’est voulu, y’a d’autre moyen de tuer le thread/process de toutes façon :p)

Oui, pas faux.

D'un autre côté, cette doc a l'air de dire que c'est mieux de laisser un thread attendre un message qui n'arrivera jamais plutôt que de chercher à interrompre ça, non ?

(Ce serait quand même globalement mieux si au lieu de dédier un thread à l'écoute de chaque socket pour cause d'attente bloquante, c'était faisable d'avoir un fonctionnement événementiel…)

grim7reaper a écritOuais, d’ailleur KDE3 avait Katapult 😛

Arf, mince. Je vais devoir renommer ça « trebuchet » pour désambiguer ? 😛

grim7reaper a écritT’entends quoi par là?
Je pense pas que tu puisses être notifier sur un accès de fichier qui n’existe pas (si c’est ça la question).

Ben, il me semblait que c'était possible d'être notifié des accès à un fichier, donc j'espérais naïvement que ça marcherait aussi en cas de fichier inexistant, oui 🙂

Mais je vois d'autres façons de faire ça :
– Faire ce système de fichier FUSE spécifique, ce qui permettrait d'avoir ces notifs quand même en plus d'autres fonctions de confort (par exemple : au moment où un programme demande à lister les entités, vérifier que les processus qui gèrent les entités en question sont bien toujours actifs, et nettoyer si besoin, pour récupérer d'un truc qui a planté sans nettoyer, par exemple).
– Faire en sorte que les éventuels messages soient écrits dans un fichier plat s'il n'y a pas de socket à cet endroit-là, et Catapult se chargera dans ce cas de bouffer le message, de lancer le programme, et d'envoyer le message à la socket dès qu'elle est en place,
– Mettre une autre socket quelque part et reproduire le comportement du point précédent mais en envoyant les messages par là plutôt que de créer cradement le fichier,
– Faire plutôt ça avec un presse-papier dédié comme je faisais à une époque…

Bref, j'y réfléchirai en temps et en heure, ça ne presse pas.

Sinon, vu que la version actuelle devient à peu près utilisable, j'ai enfin remis la vieille version intermédiaire toute cassée que j'utilisais jusque là au placard et j'ai basculé vers la version actuelle que j'utilise désormais au quotidien. Ça me motivera à coder les trucs que je n'ai pas encore remis en place (du style, réglage du volume) quand j'essayerai de m'en servir et que ça ne marchera pas ^^

(Sinon, on a perdu Dafyd ?)

grim7reaper

Elzen a écritBeh on dirait. D'un autre côté, il y a des langages où ce n'est pas possible ? Il y a des langages spécialisés pour la récursivité, mais il y a toujours une limite de taille de pile, non ?

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).

Elzen a écritD'un autre côté, cette doc a l'air de dire que c'est mieux de laisser un thread attendre un message qui n'arrivera jamais plutôt que de chercher à interrompre ça, non ?

Il y a une différence entre interrompre un thread (ce qui me fait penser au "cancel", qui lui est souvent problématique) de l'extérieur et "le thread s'arrête de son plein grè car il a reçu un message 'salut'".
Après effectivement, si y'a des chances que tu reçoivent des données plus tard sur cette socket ça fait sens de le laisser poireauter.
Là je pensais qu’on était dans un cas où on nous parlera plus jamais.

Elzen a écritArf, mince. Je vais devoir renommer ça « trebuchet » pour désambiguer ? 😛

Ça serait pas déconnant :p
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 :p
Genre ici ^^

Dafyd

Elzen a écrit(Sinon, on a perdu Dafyd ?)

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

Elzen

Dafyd a écritDésolé j’ai pas beaucoup de temps libre en ce moment :/

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

grim7reaper a écritAlors 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 ? :o)

grim7reaper a écritLà 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 :p
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 :p
Genre ici ^^

Oui, c'est pour ça que je disais ça 🙂
(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 ? ^^

grim7reaper

Elzen a écritEdit : 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 ? :o)

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 écritSinon, 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 ^^).

Elzen

Allez, quelques nouvelles 🙂

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

😃

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 :/ 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 écritBah 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 🙂

grim7reaper a écritJe 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 écritOuais , «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 🙂
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 🙂 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 😛),
/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 ?

grim7reaper

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 :/ 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 🙂

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 écritComment 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 écritmais 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 écritIl 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 écritQuelqu'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 🙂 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 😛),

/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 là.

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).

Laërte

Bonjour tout le monde, Elzen m’a dit que je pourrais peut-être trouver de l’aide ici donc je tente le coup.

C’est un programme en C qui me pose soucis, plus précisément la valeur de retour de fread. Si je me fie à la doc,

fread(ptr, size, count, file)

me renvoie la quantité de données lues, en bytes (sous réserve que size vaille 1, ce qui est le cas ici). Jusque là pas de soucis, je lis un joli bout de 512000 bytes et un petit

printf("%i", read_data)

m’affiche bien 512000.

C’est quand la bibliothèque zlib rentre en jeu que rien ne va plus.

L’idée c’est que je veux compresser mes données fraîchement lues. Du coup, un petit coup de

compress(dstbuffer, &dstbuffer_size, ptr, read_data)

, et je me retrouve avec mes données compressées dans dstbuffer, et dstbuffer_size a comme valeur la taille compressée des données. Sauf que: read_data vaut désormais 0! Et ça c’est chiant, déjà parce que je lui ai jamais demandé de modifier read_data (ce n’est pas un pointeur que je lui passe), ensuite parce que je me sers de cette variable dans la suite de mon programme et que ça m’arrange pas trop qu’elle soit réinitialisée…

Par contre, je sais que compress modifie ptr: elle le fait avancer d’autant de données compressées avec succès. Donc, si toutes mes données sont compressées, ptr est à la fin de la chaîne, et est donc un pointeur NULL. Je me dis que la réinitialisation de read_data vient peut-être de là, puisque c’est normalement la quantité de données lues, les données en question étant stockées dans ptr. Mais encore une fois, read_data c’est sensé être un gentil size_t callé dans un coin de ma mémoire, et il ne devrait pas bouger quand je touche à ptr.

Je vous mets un bout de code ci-dessous:

    /* Read data from file into buffer */
    read_data = fread(srcbuffer, 1, 512000, infile);
    printf("read_data: %i\n",read_data);
    /* Compress data */
    returnval = compress(dstbuffer, (unsigned long *)&size_compressed, srcbuffer, read_data);
    printf("read_data: %i\n",read_data);

Qui me renvoie:

read_data: 512000
read_data: 0

Est-ce quelqu’un comprend ce qu’il se passe et pourrait m’aider?
Merci!

« Page précédente Page suivante »