/* Topic des codeurs [8] */

grim7reaper · Le 14/06/2015, à 18:27

Tiens, pour ceux en manque de bonne lectures, je vous suggères les trois livres suivant (tous accessible gratuitement pour une lecture en ligne ici) :
- The Architecture of Open Source Applications
- The Architecture of Open Source Applications, volume 2
- The Performance of Open Source Applications

Pour les deux premiers, il est même possible de créer un PDF à partir des sources ici.
Pour le troisième j’ai pas encore trouvé (mais j’ai contacté Tavish Armstrong, on va voir si j’ai une réponse).

The Uploader · Le 14/06/2015, à 18:35

grim7reaper a écrit :

Quel de genre de jeux ?

Un truc en 2D sûrement. Je sais pas encore exactement, mais je recherche quelque chose de très simple, pour pas que ça finisse comme mes autres projets. ^^

Peut-être d'ailleurs quelque chose qui fonctionne sous Linux (ou Windows) qu'ensuite j'adapte pour DOS (pour enlever une difficulté).

grim' a écrit :

Tu vas faire ça en C du coup, non ?

Hum, c'est pas possible en C++ ?

grim' a écrit :

T’as pas trop perdu la main avec tout ton C# récemment (Brace Yoursef SEGFAULT is Coming) ?

Non ça va avec tout le caca que j'ai récupéré c'est tellement peu prédictible qu'on dirait du C.

Elzen · Le 14/06/2015, à 21:01

On n'a pas quelques projets de jeux sur le feu, d'ailleurs ?

(Je pense notamment à Hortus Belli et à Arpège)

grim7reaper · Le 14/06/2015, à 21:21

The Uploader a écrit :

Peut-être d'ailleurs quelque chose qui fonctionne sous Linux (ou Windows) qu'ensuite j'adapte pour DOS (pour enlever une difficulté).

Je me demande si c’est pas plus simple dans l’autre sens (plus simple de viser un truc limité puis faire le portage sur une plateforme plus puissante).
Sinon pour le C++, si ça doit être possible (mais faudra probablement se limiter au C++ prè-C++11).

Elzen a écrit :

On n'a pas quelques projets de jeux sur le feu, d'ailleurs ?
(Je pense notamment à Hortus Belli et à Arpège)

Toutafé !
D’ailleurs au sujet d‘Hortus Belli, j’ai toujours le code (comme je le disais récemment).

grim7reaper · Le 15/06/2015, à 18:24

grim7reaper a écrit :

Pour le troisième j’ai pas encore trouvé (mais j’ai contacté Tavish Armstrong, on va voir si j’ai une réponse).

L’aveugle du mois c’est moi \o/
J’ai eu une réponse : c’est dans le même dépot que les autres >_<
Je vais voir si c’est compilable

grim7reaper · Le 29/06/2015, à 15:16

grim7reaper a écrit :

Je vais voir si c’est compilable

En l’occurrence, c’était compilable

Sinon, si quelqu’un veut se mettre à Haskell j’ai trouvé un message qui explique un cheminement possible avec plein de bon liens et de bons conseils
Je dit ça car je me suis remis à Haskell récemment (j'ai fait le CodinGame de ce week-end avec d’ailleurs).

C'était bien sympa (j'avais déjà codé un truc similaire en plus, j'avais dû le poster ici d'ailleurs), même si mon Haskell étant rouillé j’ai un peu galéré avec certains message d’erreurs du compilateur :]

Dernière modification par grim7reaper (Le 29/06/2015, à 15:22)

Elzen · Le 29/06/2015, à 20:23

Il faut toujours que j'me mette à Haskell, moi, oui

Je note, je regarderai ça dès que possible, merci !

grim7reaper · Le 30/06/2015, à 09:42

Tu le regretteras pas, ça t’apprends vraiment une autre façon d’attaquer les problèmes (même dans les autres langages)

Elzen · Le 01/07/2015, à 12:56

Ouaip

Sinon, je n'en ai pas encore parlé là, mais je suis actuellement en train de proof-of-conceptiser un projet de bot collaboratif.
En gros, c'est un bot IRC (en python) couplé à un pad : n'importe qui peut venir modifier le code du pad, demander au bot de le recharger, et la façon de réagir du bot aux différents événements (arrivée/départ du chan ou propos des autres participants) est modifiée en fonction de ce qu'il y a sur le pad.

Ça tourne depuis quelque chose comme deux semaines, et pour le moment, ça a l'air d'aller bien
Le bot a été doté de quelques fonctions plus ou moins utiles, comme un reminder (on indique une heure et un message, et il dira le message à l'heure dite), un convertisseur vers 1337 5p34k, ou un autopan.

Si jamais vous voulez tester ça, c'est sur #illyse-off, sur GeekNode.

grim7reaper · Le 02/07/2015, à 19:48

Elzen a écrit :

Sinon, je n'en ai pas encore parlé là, mais je suis actuellement en train de proof-of-conceptiser un projet de bot collaboratif.
En gros, c'est un bot IRC (en python) couplé à un pad : n'importe qui peut venir modifier le code du pad, demander au bot de le recharger, et la façon de réagir du bot aux différents événements (arrivée/départ du chan ou propos des autres participants) est modifiée en fonction de ce qu'il y a sur le pad.

Je suis pas sur d’avoir bien compris ce que ça fait ^^"

Elzen a écrit :

Ça tourne depuis quelque chose comme deux semaines, et pour le moment, ça a l'air d'aller bien
Le bot a été doté de quelques fonctions plus ou moins utiles, comme un reminder (on indique une heure et un message, et il dira le message à l'heure dite), un convertisseur vers 1337 5p34k, ou un autopan.

Et c’est quoi un « autopan » ?

Sinon moi j’ai un xxHash à finir en Ada (j’ai déjà publié une implémentation de SipHash), une V2 de HAL dont j’aimerais finir le design.
Mais en ce moment, je me remet à Haskell.
Une fois que j’aurais bien repris la main j’aimerai faire un logiciel d‘indexation peut-être.

Elzen · Le 02/07/2015, à 23:33

grim7reaper a écrit :

Et c’est quoi un « autopan » ?

En gros, quand quelqu'un dit « coin », le bot répond « pan ». C'est une des options de base de pas mal de bots IRC, il paraît.

Sinon, le principe du bot collaboratif, c'est que c'est comme un bot IRC classique, à savoir qu'il y a une fonction qui est appelée à chaque fois que quelqu'un cause sur le chan, et que le bot parse ce qu'a dit la personne en question, et réagit en fonction (par exemple, indique comment on est censé l'utiliser si le message était « !help »).
Sauf que là, la fonction qui détermine ce que fait le bot est codée collaborativement sur un pad, et que quand on lui dit « !update » (qui est un truc réglé en dur), le bot va chercher le contenu du pad, recharge le module python correspondant, et continue avec la nouvelle fonction. Donc, ça fait un bot que n'importe quel participant au chan peut modifier comme ça l'arrange

Si tu veux, passe voir sur le chan (et pingue-moi à ce moment-là), ce sera plus simple à comprendre ^^

grim7reaper · Le 03/07/2015, à 12:50

Ok, c’est plus clair.

Donc en gros le code des fonctions du bot est sur le pad et tu fais un import du pad (en gros).
C‘est pas terrible niveau sécurité ça, non? T’utilises un mécanisme de sandbox ou tu fais confiance aux utilisateurs ?

Elzen · Le 03/07/2015, à 13:10

En gros

Et un peu des deux.
À tout hasard, j'ai un compte utilisateur sur mon serveur dédié au bot, et qui n'a accès à rien (à part le contenu du blog en lecture seule). Mais en vrai, il n'y a pas grand monde pour tenter vraiment des attaques comme ça, donc la confiance marche relativement bien

Oni_Shadow · Le 07/07/2015, à 00:09

je suis par ce que vous etescool.

Elzen · Le 16/07/2015, à 12:06

Bon, je sais que technos obsolètes, tout ça ; mais là, je rencontre un soucis assez bizarre avec PyGTK.

J'avais envie de décompresser cinq minutes, alors j'ai commencé à coder un Klondike pour Touhy. Pour gérer le fait que les cartes se superposent, j'ai utilisé un gtk.Table, en faisant en sorte que chaque carte occupe plusieurs lignes, comme ça il y a juste à décaler la ligne de départ pour que ça s'applique bien (ça me semblait beaucoup plus simple à gérer qu'avec un gtk.Fixed).

Le premier truc surprenant, c'est qu'apparemment, un gtk.Table gère les superpositions en mettant les composants ajoutés le plus récemment derrière, et non pas devant. Donc, si j'affiche une colonne dans l'ordre dans lequel on pose les cartes, j'ai la carte face cachée qui sera la dernière atteinte tout au dessus, et la carte face visible que le joueur est censée manipuler partiellement cachée par les autres cartes face cachée. Pas glop.

J'ai donc « rectifié » le truc en faisant en sorte que, chaque fois qu'on pose une nouvelle carte sur le plateau, ça retire toutes les cartes précédentes de la colonne et ça les réaffiche, pour qu'elles soient bien affichées en dessous. Seulement, ce truc semble perturber grandement la façon dont l'application gère le passage de la souris.

Les cartes face cachée encore inaccessibles sont des gtk.Button désactivés (avec set_sensitive(False)), tandis que les cartes face visible sont des gtk.Button activés. Quand une carte est seule en bas de sa pile, tout va bien : j'ai la seule carte face visible qui réagit sur toute sa surface, et toutes les cartes faces cachées qui ne réagissent pas.

En revanche, quand je commence à faire des déplacements, et donc à superposer les cartes face visible, on dirait que le « z-index » s'inverse : la carte la plus en bas n'est sensible que sur la ligne où elle est toute seule ; puis la carte qui est juste au dessous visuellement est sensible sur la ligne où elles sont deux, alors que la souris est visuellement encore au dessus de l'autre, et ainsi de suite.
Chose d'autant plus curieuse : cette fois, les cartes face cachée et donc désactivées semblent être elles aussi prises en compte comme étant au dessus des autres alors qu'elles sont affichées en dessous, ce qui ne se produisait pas sur le cas précédent.

J'avoue que ce truc, en plus de provoquer d'évidents soucis dans le maniement du jeu, me laisse assez perplexe.

Elzen · Le 30/08/2015, à 14:54

Et un petit double-post, vu que ce topic est désert

D'une part, j'ai une idée assez cool pour mon émulateur de terminal, mais qui nécessiterait que je puisse savoir quel processus a actuellement la main dans ledit terminal, ce qui ne semble pas une chose particulièrement évidente à vue de nez (j'utilise un vte.Terminal, qui ne fournit apparemment aucune option susceptible de permettre une investigation de ce côté).
En fouillant un peu, j'ai trouvé dans /proc/PID/task/PID/children la liste des numéros de processus fils du processus de base, ce qui est un début, mais je ne vois pas, à première vue, comment différencier une commande lancée au premier plan d'une commande lancée avec une éperluette. Par ailleurs, je ne suis pas sûr que /proc existe en dehors du noyau Linux, et j'aimerais bien que Touhy soit, autant que possible, compatible *BSD.
Donc, si quelqu'un avait des pistes à ce sujet, je serais preneur.

D'autre part, je bosse sur des formats de conversions (pour un gestionnaire de presse-papier qui commence à devenir assez cool ), et il y a deux trucs dont j'aurais besoin :
– Convertir un gtk.gdk.Pixbuf en texte au format XPM⁽¹⁾
– Sérialiser/désérialiser un gtk.TextBuffer vers/depuis du format RTF.
Je suis certain que ça doit déjà exister, parce que ce sont des formats plutôt courants, mais je n'ai pas encore trouvé de trucs tous faits, et faire ça à la main me demanderait sans doute pas mal de temps pour un bénéfice somme toute assez réduit.
Donc, si jamais quelqu'un tombe par hasard sur un bout de code qui fait ça, n'hésitez pas à signaler.

D'une manière plus générale, si vous aimez jouer avec des conversions de formats, des gtk.gdk.Pixbuf et/ou des changements de coordonnées, Touhy pourrait avoir besoin de vous en ce moment

(1) une conversion en ascii art en prime ne serait pas de refus non plus, mais pour ça, je sais qu'il existe déjà des trucs, et ça a de toute façon nettement moins d'intérêt.

grim7reaper · Le 02/09/2015, à 07:21

Elzen a écrit :

D'une part, j'ai une idée assez cool pour mon émulateur de terminal, mais qui nécessiterait que je puisse savoir quel processus a actuellement la main dans ledit terminal, ce qui ne semble pas une chose particulièrement évidente à vue de nez (j'utilise un vte.Terminal, qui ne fournit apparemment aucune option susceptible de permettre une investigation de ce côté).

Tu les lances comment les processus ? Avec `vte_terminal_fork_command_full` ? Si oui, du coup tu peux avoir le PID.
Cela dit, pour les histoires de background & cie c’est le shell qui s’en occupe donc au niveau de l’émulateur tu a pas accès à ce genre d’info je pense.

Elzen a écrit :

Par ailleurs, je ne suis pas sûr que /proc existe en dehors du noyau Linux, et j'aimerais bien que Touhy soit, autant que possible, compatible *BSD.

En général, y’a une couche de compatibilité pour /proc sur les BSD, mais vaut mieux éviter de trop se baser là-dessus en effet (le niveau de compat’ peut varier ou la couche peut être absente).

Elzen a écrit :

– Convertir un gtk.gdk.Pixbuf en texte au format XPM

Y’a bien la conversion dans l’autre sens (mais ça tu le sais déjà je pense ^^), par contre dans ce sens là j’ai rien vu.
Après, je crois que le Pixbuf peut te donner accès à son tableau de pixels, nan ? Partant de là, tu devrais pouvoir générer un XPM à la main (le format semble relativement simple) ou utiliser une bibliothèque pour faire la converion (Pillow, anciennement PIL, fait peut-être ça).

Elzen a écrit :

– Sérialiser/désérialiser un gtk.TextBuffer vers/depuis du format RTF.

Hum, du RTF…
Je sais pas si c’est tant utilisé que ça sur Linux (et donc si y’a beaucoup de bibliothèque pour ça…). Cela dit, même si GTK ne propose pas un truc spécifique RTF il a un mécanisme générique qui pourrait être utilisé moyennant du code si j’en crois ce topic.

Elzen a écrit :

D'une manière plus générale, si vous aimez jouer avec des conversions de formats, des gtk.gdk.Pixbuf et/ou des changements de coordonnées, Touhy pourrait avoir besoin de vous en ce moment

Tu fais quoi sur Touhy en ce moment ?

Elzen · Le 02/09/2015, à 23:43

grim7reaper a écrit :

Tu les lances comment les processus ? Avec `vte_terminal_fork_command_full` ? Si oui, du coup tu peux avoir le PID.
Cela dit, pour les histoires de background & cie c’est le shell qui s’en occupe donc au niveau de l’émulateur tu a pas accès à ce genre d’info je pense.

vte.Terminal.fork_command, ça a l'air d'être la même chose.

On peut effectivement récupérer le PID de la commande lancée ; mais ce que je voudrais, c'est pouvoir récupérer celle qui a la main, donc par exemple, si je fork_command un shell et que je lance l'interpréteur python dans ce shell, c'est python que je voudrais pouvoir identifier. Et oui, ça parait délicat d'y accéder directement, d'où le fait que je tente de faire autrement.

grim7reaper a écrit :

En général, y’a une couche de compatibilité pour /proc sur les BSD, mais vaut mieux éviter de trop se baser là-dessus en effet (le niveau de compat’ peut varier ou la couche peut être absente).

Ouais, je m'en doutais. Donc il faudrait tenter autrement…
Ceci dit, accéder à la liste des processus enfants depuis le PID du parent, c'est faisable directement avec ps, je pense que c'est déjà mieux, pour la compatibilité. Mais ça ne résout pas le problème de savoir lequel a la main.

Tiens, tant qu'on cause de ce qu'on trouve ailleurs, le fichier /etc/mime.types, c'est standard ?

grim7reaper a écrit :

Y’a bien la conversion dans l’autre sens (mais ça tu le sais déjà je pense ^^), par contre dans ce sens là j’ai rien vu.
Après, je crois que le Pixbuf peut te donner accès à son tableau de pixels, nan ? Partant de là, tu devrais pouvoir générer un XPM à la main (le format semble relativement simple) ou utiliser une bibliothèque pour faire la converion (Pillow, anciennement PIL, fait peut-être ça).

Ouaip, dans l'autre sens, ça gère ^^

Le format a effectivement l'air assez simple pour que ce soit tout à fait envisageable ; mais dans le doute, je réinvente déjà assez de roues comme ça, donc si je peux reprendre quelques briques, ça limite les risques.

grim7reaper a écrit :

Hum, du RTF…
Je sais pas si c’est tant utilisé que ça sur Linux (et donc si y’a beaucoup de bibliothèque pour ça…). Cela dit, même si GTK ne propose pas un truc spécifique RTF il a un mécanisme générique qui pourrait être utilisé moyennant du code si j’en crois ce topic.

Ouaip, le gtk.TextBuffer gère le formatage avec des tags, il « suffit » en théorie de faire une fonction qui convertit le contenu du buffer vers du texte balisé, et réciproquement. Encore faut-il savoir la faire, et comme j'n'ai pas trop l'habitude de ce format…

Sinon, ce n'est pas si utilisé que ça, mais c'est quand même un format qu'on croise de temps à autres. Par exemple, j'ai remarqué récemment qu'Eclipse copiait le code seul en text/plain, et le code avec coloration syntaxique en RTF, et j'aimerais bien savoir récupérer ça comme il faut de mon côté.

grim7reaper a écrit :

Tu fais quoi sur Touhy en ce moment ?

Là tout de suite maintenant, une pause pour faire avancer ma thèse ^^

Mais sinon, j'suis en train de faire quelques composants internes pour enfin transférer les applis de l'ancien dépôt vers le nouveau (ça fait longtemps que ça traîne), en les améliorant un peu au passage.
En l'occurrence, les histoires de recalages, c'est parce que je suis en train de travailler sur un widget de dessin : une zone de travail étirable des deux côtés, avec l'image précédemment tracée qui reste au centre, et qui permet de faire des coups de crayon à main levée, aussi bien en matriciel qu'en vectoriel. Ça servira pour l'outil de dessin, mais je me suis dit que ça pouvait aussi être intégré au gestionnaire de presse-papier.

grim7reaper · Le 07/09/2015, à 07:43

Elzen a écrit :

Et oui, ça parait délicat d'y accéder directement, d'où le fait que je tente de faire autrement.

Je ne pense pas que ça soit possible, le job control est fait par le shell et je ne pense pas qu’il exporte ce genre d’info.

Elzen a écrit :

Ouais, je m'en doutais. Donc il faudrait tenter autrement…
Ceci dit, accéder à la liste des processus enfants depuis le PID du parent, c'est faisable directement avec ps, je pense que c'est déjà mieux, pour la compatibilité. Mais ça ne résout pas le problème de savoir lequel a la main.

Et puis je ne sais pas à quelle fréquence tu veux faire ça, mais faire de l’exec’ de processus externe (ici ps) à répétition c’est pas tip-top.

Elzen a écrit :

Tiens, tant qu'on cause de ce qu'on trouve ailleurs, le fichier /etc/mime.types, c'est standard ?

Tu veux dire quoi par standard ?
En tout cas il est pas présent par défaut sous Archlinux au moins (il faut installer le paquet mime-types).

Elzen a écrit :

Par exemple, j'ai remarqué récemment qu'Eclipse copiait le code seul en text/plain, et le code avec coloration syntaxique en RTF, et j'aimerais bien savoir récupérer ça comme il faut de mon côté.

Si c’est pour avoir la couleur, une conversion en HTML ferait pas aussi bien l’affaire ?

Elzen a écrit :

Là tout de suite maintenant, une pause pour faire avancer ma thèse ^^

Bon courage !

Elzen a écrit :

mais je me suis dit que ça pouvait aussi être intégré au gestionnaire de presse-papier.

C’est quoi le cas d’usage dans le presse-papier ?

Sur un autre sujet, Andrei Alexandrescu (une pointure dans le monde du C++ et co-auteur de D) a quitté son boulot à Facebook pour se concentrer sur le D. Je pense que c’est une bonne nouvelle pour ce langage (The Uploader, tu faisais pas du D à un moment ?).

The Uploader · Le 07/09/2015, à 11:37

Je me suis mis à un moment, mais devant le peu de d'utilisation du D / les histoires de compilateur / autres problèmes, j'ai pas fait grand chose à part des intros.

En tout cas c'est intéressant, mais je pense qu'avec les dernières évolutions du C++ et son usage massif, C++ est un meilleur choix quand on commence un projet pour lequel on veut faire du natif et qu'on veut des perfs mais un langage moderne.

Mais je souhaite à D de réussir !

Dernière modification par The Uploader (Le 07/09/2015, à 11:39)

Elzen · Le 07/09/2015, à 12:13

grim7reaper a écrit :

Et puis je ne sais pas à quelle fréquence tu veux faire ça, mais faire de l’exec’ de processus externe (ici ps) à répétition c’est pas tip-top.

D'où le fait que je me sois penché sur la lecture de /proc, qui me semblait potentiellement plus économique.

Mais sinon, je pensais basiquement surveiller le texte entré dans le terminal (signal « contents-changed »). Ça repère tout texte inséré plutôt que seulement les retours à la ligne, mais bon, ça permet au moins de laisser le truc au repos quand l'utilisateur ne tape rien. Avec un petit mécanisme de délai pour ne pas lancer la vérif' à chaque touche…

L'idée, grosso-modo, serait d'avoir un terminal qui peut visuellement se modifier en fonction du processus actif (par exemple, le texte qui devient rouge dès qu'on est root). À la limite, ça doit pouvoir se faire en observant tous les fils et avec quelques règles simples (exclure gksudo et compagnie ; prendre le privilège le plus élevé parmi ce qui reste, ce genre de choses).

grim7reaper a écrit :

Tu veux dire quoi par standard ?
En tout cas il est pas présent par défaut sous Archlinux au moins (il faut installer le paquet mime-types).

J'voulais dire le même genre de choses que pour /proc : est-ce que c'est spécifique à certains systèmes, ou est-ce qu'on a de bonnes chances de trouver ça sur tous les Unix.
À vue de nez, sous Debian, ça dépend du paquet « mime-support », que j'ai (me semble-t-il) toujours vu installé, même sur une install minimale.

J'hésite entre préciser ça en dépendance, ou tenter de faire un fallback si le fichier n'est pas trouvé (les deux ne sont pas incompatibles, d'ailleurs).

grim7reaper a écrit :

Si c’est pour avoir la couleur, une conversion en HTML ferait pas aussi bien l’affaire ?

Ça pourrait ; mais ça ne fait que décaler le problème (il faut convertir le RDF de toute façon, que ce soit en HTML ou en autre chose). D'ailleurs, il faudra que j'ajoute le support du HTML aussi, mais on verra ça plus tard.

grim7reaper a écrit :

Bon courage !

Merci

grim7reaper a écrit :

C’est quoi le cas d’usage dans le presse-papier ?

Pouvoir faire des modifs rapides sur une image entre le moment où on la copie et celui où on la colle, sans avoir à lancer un logiciel de traitement d'images. Par exemple, pour faire de la doc' : faire une capture d'écran envoyée vers le presse-papier, entourer le bouton sur lequel il faut cliquer, et coller directement dans un traitement de texte.
Ç'n'est pas forcément un usage hyper-fréquent, mais ça peut potentiellement servir de temps en temps, et ça n'est pas tellement compliqué à faire (une fois que le widget fonctionne correctement, s'entend), donc autant le faire

grim7reaper a écrit :

Sur un autre sujet, Andrei Alexandrescu (une pointure dans le monde du C++ et co-auteur de D) a quitté son boulot à Facebook pour se concentrer sur le D. Je pense que c’est une bonne nouvelle pour ce langage (The Uploader, tu faisais pas du D à un moment ?).

J'avais tenté de regarder vite-fait à quoi ça ressemblait, mais sans plus⁽¹⁾. Ça a effectivement l'air d'être une bonne nouvelle pour le langage À voir comment ça évolue.

(1) En fait, depuis que j'ai trouvé comment compiler quelques trucs avec Cython⁽²⁾, j'trouve que Python me va vraiment bien pour la plupart de ce que j'ai à faire. Le gros truc qui m'embête (et qui n'est pas lié au langage, en fait), c'est pour la partie graphique : je suis très peu enthousiaste au sujet de GTK3, et pas sûr d'accrocher à la logique Qt Donc pour l'instant, je reste bloqué sur PyGTK, mais ç'pas glop niveau pérennité.

(2) D'ailleurs, à partir du prochain commit, Touhy pourra être en grande partie compilé. Du moins, les exécutables de base pouvaient déjà l'être, et la plupart des fichiers de module pourront l'être désormais aussi. Seuls les __init__.py et __main__.py doivent rester sous cette forme, sinon la gestion des packages ne fonctionne pas.

grim7reaper · Le 09/09/2015, à 12:26

The Uploader a écrit :

les histoires de compilateur

Y'a pas le problème qu’ils ont deux lib‘ standard aussi ?

The Uploader a écrit :

En tout cas c'est intéressant, mais je pense qu'avec les dernières évolutions du C++ et son usage massif, C++ est un meilleur choix quand on commence un projet pour lequel on veut faire du natif et qu'on veut des perfs mais un langage moderne.

Niveau usage massif, oui le C++ est devant.
Après, plus ça va moins j'ai envie de toucher au C++ quand y'a un langage plus adapté (Rust, Ada, D peut-être, …).

Elzen a écrit :

L'idée, grosso-modo, serait d'avoir un terminal qui peut visuellement se modifier en fonction du processus actif (par exemple, le texte qui devient rouge dès qu'on est root). À la limite, ça doit pouvoir se faire en observant tous les fils et avec quelques règles simples (exclure gksudo et compagnie ; prendre le privilège le plus élevé parmi ce qui reste, ce genre de choses).

Ça me semble être beaucoup de travail pour un gain minimal, non?
En plus, ça ne résouds pas ton souci de faire la différence entre processus en background et processus en foreground.

Elzen a écrit :

J'voulais dire le même genre de choses que pour /proc : est-ce que c'est spécifique à certains systèmes, ou est-ce qu'on a de bonnes chances de trouver ça sur tous les Unix.

On dirait que t'as de bonnes chances de le trouver (peut-être pas installé par défaut, mais installable en tout cas).
Et /proc n'est pas spécifique Linux, c'est de l'UNIX aussi. La différence de Linux c'est qu'il met beaucoup d'informations dans /proc, pas seulement des infos sur les processus.

Elzen a écrit :

À vue de nez, sous Debian, ça dépend du paquet « mime-support », que j'ai (me semble-t-il) toujours vu installé, même sur une install minimale.

Sous Arch c'est dans "extra", pas dans "base" donc c'est pas présent par défaut il me semble.

Elzen a écrit :

mais ça ne fait que décaler le problème

En effet

Ha, tu as réecrit Touhy en Cython ? Pour quelles raisons ?
C'est pas pour les perf' j'imagine. Pour le typage?

Dernière modification par grim7reaper (Le 09/09/2015, à 12:28)

Elzen · Le 09/09/2015, à 15:12

grim7reaper a écrit :

Ça me semble être beaucoup de travail pour un gain minimal, non?
En plus, ça ne résouds pas ton souci de faire la différence entre processus en background et processus en foreground.

En effet.

Donc bon, on verra quand on y sera.

grim7reaper a écrit :

On dirait que t'as de bonnes chances de le trouver (peut-être pas installé par défaut, mais installable en tout cas).

Ouaip, je pense que je vais rajouter ça dans la liste des dépendances. Je peux mettre les valeurs classiques en fallback, mais j'en oublierai toujours un paquet…

grim7reaper a écrit :

Et /proc n'est pas spécifique Linux, c'est de l'UNIX aussi. La différence de Linux c'est qu'il met beaucoup d'informations dans /proc, pas seulement des infos sur les processus.

D'acc. Je ne connais pas assez les autres Unix…

grim7reaper a écrit :

Ha, tu as réecrit Touhy en Cython ? Pour quelles raisons ?
C'est pas pour les perf' j'imagine. Pour le typage?

En fait, je n'ai rien réécrit : le code de base tel que je le faisais jusque là passe très bien à la compilation tout seul.
À la base, je compilais uniquement les exécutables, parce que c'est plus pratique pour les killer s'il y a un truc qui plante (ce que je n'ai pas eu besoin de faire depuis un bail, tiens d'ailleurs). Puis je me suis dit que tant qu'à utiliser des exécutables compilés, ça pourrait éventuellement servir à quelque chose de compiler le plus possible du reste avec, au cas où.
De mon point de vue, la compilation sert surtout à repérer plus facilement certains soucis de prog (genre fautes de frappe sur les noms de variables). Mais comme ça peut être compilé, et que j'ai un script pour le faire, autant mettre ça dans le dépôt aussi, des fois que d'autres gens y trouveraient une autre utilité.

vv221 · Le 04/10/2015, à 19:29

Salut camarades codeurs !

Je viens vous voir aujourd’hui pour vous parler de mon projet du moment, celui qui me fait passer des nuits blanches et m’arracher des cheveux, mais qui m’a appris à aimer ça :
./play.it

Vous trouverez une description plus complète en suivant le lien, mais pour résumer en quelques mots il s’agit d’une collection de scripts shell construisant à partir de sources diverses des paquets .deb prêts à l’installation, avec pour but de faciliter l’installation de jeux propriétaires (commerciaux ou gratuits sans distinction) sous n’importe quelle distribution basée sur APT.
J’écris et teste ces scripts sur une Debian Sid mais mes utilisateurs m’ont confirmé leur efficacité sur différentes versions d’Ubuntu et Linux Mint.

Vous vous demandez maintenant sûrement pourquoi je viens vous embêter avec ça ?
C’est simple : une ré-écriture totale est en projet et devrait débuter dans 2~3 mois, mais avant de m’y lancer je cherche à recevoir quelques conseils de codeurs plus "calés" que moi.

En effet, j’ai monté ce projet en autodidacte ; je n’ai jamais suivi de formation en programmation et ce que je publie aujourd’hui a été écrit uniquement à la lumière de 'man dash'. Donc j’imagine que c’est pour l’instant truffé de mauvaises habitudes et de formes inappropriées.
Je viens donc ici à la recherche de conseils de style, de suggestions d’améliorations et de "bonnes pratiques" à suivre lors de ma ré-écriture à venir.

Je ne suis pas facilement vexable, alors n’hésitez pas à y aller franchement si certaines portions du code tiennent de l’hérésie pour qui utilise le shell de manière plus "sérieuse" que moi

Mesdames et messieurs les juges, j’attends votre verdict !

grim7reaper · Le 05/10/2015, à 12:39

@vv221 : tu as un dépôt (git, mercurial, …) avec tout tes scripts (ou au pire, une archive) ou faut les regarders un à un via cette page ?
Sinon je ne sais pas si beaucoup de spécialiste shellscript passe ici, mais tu auras peut-être quelques retours quand même
Moi-même je fais pas trop de script shell mais si j'ai un peu de temps j’essayerais de jeter un œil

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#2301 Le 14/06/2015, à 18:27

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

#2302 Le 14/06/2015, à 18:35

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

#2303 Le 14/06/2015, à 21:01

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

#2304 Le 14/06/2015, à 21:21

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

#2305 Le 15/06/2015, à 18:24

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

#2306 Le 29/06/2015, à 15:16

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

#2307 Le 29/06/2015, à 20:23

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

#2308 Le 30/06/2015, à 09:42

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

#2309 Le 01/07/2015, à 12:56

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

#2310 Le 02/07/2015, à 19:48

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

#2311 Le 02/07/2015, à 23:33

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

#2312 Le 03/07/2015, à 12:50

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

#2313 Le 03/07/2015, à 13:10

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

#2314 Le 07/07/2015, à 00:09

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

#2315 Le 16/07/2015, à 12:06

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

#2316 Le 30/08/2015, à 14:54

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

#2317 Le 02/09/2015, à 07:21

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

#2318 Le 02/09/2015, à 23:43

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

#2319 Le 07/09/2015, à 07:43

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

#2320 Le 07/09/2015, à 11:37

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

#2321 Le 07/09/2015, à 12:13

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

#2322 Le 09/09/2015, à 12:26

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

#2323 Le 09/09/2015, à 15:12

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

#2324 Le 04/10/2015, à 19:29

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

#2325 Le 05/10/2015, à 12:39

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

Pied de page des forums