Contenu | Rechercher | Menus

Annonce

Ubuntu 16.04 LTS
Commandez vos DVD et clés USB Ubuntu-fr !

Pour en savoir un peu plus sur l'équipe du forum.

Appel à contributeurs pour la doc.

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

#76 Le 08/07/2016, à 09:25

The Uploader

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

Vous en pensez quoi de son "framework" ?

Perso je trouve ça tarabiscoté...


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4200, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster AWE64, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#77 Le 21/07/2016, à 23:42

Elzen

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

J'en pense que je n'ai pas tout compris, mais que ça semble assez complexe pour assez peu.
Après, chacun ses façons de bosser : si lui ça lui va, tant mieux pour lui.

D'ailleurs, à ce sujet (chacun ses façons de bosser), j'envisage (enfin) de passer sérieusement à Python3/GTK3⁽¹⁾, et donc j'aimerais bien en profiter pour me refaire un répertoire de travail propre. Dans l'idéal, j'aimerais bien que le dépôt ressemble à quelque chose comme ça :

seth@fadreils: tmp$ ls -RFi elzapps/
elzapps:
54928 build.sh*
57471 firstapp/
55880 license
54225 readme
56070 secondapp/
55073 thirdapp/

elzapps/firstapp:
58462 elzlibs/
57234 firstapp.py*
55880 license
56169 readme

elzapps/firstapp/elzlibs:
58586 firstlib.py
58522 __init__.py
60832 secondlib.py

elzapps/secondapp:
58093 elzlibs/
55880 license
58069 readme
59911 secondapp/

elzapps/secondapp/elzlibs:
58522 __init__.py
60832 secondlib.py
61722 thirdlib.py

elzapps/secondapp/secondapp:
61050 __init__.py
61018 __main__.py*
61096 specificlib.py

elzapps/thirdapp:
59390 elzlibs/
55880 license
59226 readme
62665 resources/
60066 thirdapp/

elzapps/thirdapp/elzlibs:
58586 firstlib.py
58522 __init__.py
61722 thirdlib.py

elzapps/thirdapp/resources:
63709 somefile

elzapps/thirdapp/thirdapp:
61257 __init__.py
62084 __main__.py*
60184 specificlib.py
seth@fadreils: tmp$ 

Donc avec un répertoire principal contenant quelques fichiers méta⁽²⁾, et ensuite, un répertoire par appli, contenant à chaque fois un module/package python contenant le code de l'appli proprement dite, quelques fichiers supplémentaires pour l'appli elle-même, et un package python contenant les bibliothèques communes. Ce dernier ne contiendrait que les bibliothèques utilisées par l'appli en question, avec des liens physiques pour que ce soit le même fichier partout où il y en a besoin.
En gros, les avantages que j'y vois:

  • Ça facilite les MàJ des biblis communes, puisque « ls elzapps/*/elzlibs/machin.py » indique directement quelles applis utilisent une bibli donnée, et en cas de modif impactant plusieurs applis, ça fait un seul commit pour les corrections.

  • Si je veux proposer une appli particulière à quelqu'un, pas besoin de lui faire cloner tout le dépôt dont la grosse majorité ne servira pas, il y a juste à récupérer le répertoire de l'appli en question, et toutes mes dépendances à moi sont dedans.

Vous savez s'il existe un gestionnaire de versions qui permet de bosser facilement de cette manière ? Git a l'air d'avoir un peu de mal avec les liens physiques, et je ne suis pas sûr qu'il soit très permissif sur la partie « récupérer seulement un répertoire du dépôt » (Ça, SVN y arrive, mais SVN, quoi. Même avec mon utilisation on ne peut plus basique du truc, le côté décentralisé de git est largement plus pratique).

Alternativement, si, ce qui est probable, vous voyez des failles majeures dans cette façon de travailler et avez des suggestions pour rendre le tout plus propre, je suis disposé à écouter, hein smile

(1) En lisant le rapport de bug de Clearlooks-Phenix, j'suis tombé vers un lien pour un thème issu de Mate qui est à peu près regardable (ça fera une bonne base de travail pour commencer à me faire un truc correct, dirons-nous). En espérant qu'on ait un peu de temps avant la prochaine MàJ qui cassera tout -_-
(2) Le script build.sh, notamment, sert à compiler si besoin, et à faire une arbo commune pour ne pas avoir quinze tonnes de reps à ajouter dans $PATH et $PYTHONPATH. Sinon, le fichier licence est lui aussi lié physiquement dans tous les répertoires, vu que c'est la GNU GPL v3 dans tous les cas.

Hors ligne

#78 Le 22/07/2016, à 12:49

The Uploader

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

je connais pas trop, mais ça me semble correspondre à git-submodules


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4200, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster AWE64, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#79 Le 23/07/2016, à 13:19

Elzen

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

De ce que j'ai pu en lire, git-submodule, ça a l'air d'être très exactement l'inverse: ça permet d'intégrer dans un dépôt un autre dépôt ayant un historique séparé; quand mon objectif est de faire un seul historique mais de permettre de récupérer chaque répertoire séparément.

Sinon, je viens de (rapidement) tester Fossil, Darcs, Mercurial et Bazaar, à vue de nez, aucun n'a d'opération simple pour gérer les liens physiques entre deux fichiers d'un même dépôt. Y a une raison particulière à ça ?

Pour git, j'ai trouvé cette explication qui semble assez incohérente à vue de nez (ce serait dû au fait que certains systèmes de fichiers ne gèrent pas les liens physiques, or git supporte très bien de gérer plusieurs fichiers ayant le même nom à la casse près, ce que certains systèmes de fichier (les mêmes, à peu de chose près, 'me semble) ne supportent pas non plus, donc pourquoi l'un et pas l'autre ?)

Hors ligne

#80 Le 26/07/2016, à 15:45

grim7reaper

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

Usine à gaz.

Elzen a écrit :

En gros, les avantages que j'y vois:

  • Ça facilite les MàJ des biblis communes, puisque « ls elzapps/*/elzlibs/machin.py » indique directement quelles applis utilisent une bibli donnée, et en cas de modif impactant plusieurs applis, ça fait un seul commit pour les corrections.

  • Si je veux proposer une appli particulière à quelqu'un, pas besoin de lui faire cloner tout le dépôt dont la grosse majorité ne servira pas, il y a juste à récupérer le répertoire de l'appli en question, et toutes mes dépendances à moi sont dedans.

Tu peux avoir ces avantages avec git et les sous-modules. Par contre ça sera pas la même organisation niveau arborescence.
Mais si tu as un (des) dépôt pour les bibliothèques communes et un dépôt par applications ça a les avantages que tu cites :

  • correction en un commit : fix le bug dans le dépôt du package puis met à jour les sous-module de chaque applications qui utilise ce package (bon ça fait plus de un commit du point de vue Git, mais point de vue dev ça te fait qu'un commit je dirais).

  • Si je veux proposer une appli particulière à quelqu'un : clone le dépôt de l’application, avec la bonne option ça va clôner les sous-modules (et donc les dépendances).

Un problème que je vois avec les liens physiques c’est que si à un moment tu as deux applications qui ont besoins de deux versions différentes de ton package commun tu est bloqué, non?
Avec les sous-modules ça se gère facilement.

Mais si tu veux rester avec ton organisation bien précise, je pense pas qu’il y ai de gestionnaires de versions qui gèrent ça (du moins à ma connaissance, mais à part Darcs et Git j’en connais pas beaucoup en détails).

Hors ligne

#81 Le 26/07/2016, à 17:11

Elzen

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

grim7reaper a écrit :

Un problème que je vois avec les liens physiques c’est que si à un moment tu as deux applications qui ont besoins de deux versions différentes de ton package commun tu est bloqué, non?

Si ça arrivait, il «suffirait» de refaire deux fichiers séparés, non? De toute façon, ça a des chances infimes d'arriver, dans la mesure où le principe est justement de gérer le tout comme un seul projet, et que donc, si deux applis se retrouvent à présenter une incompatibilité, c'est qu'il y a un soucis plus général à régler.

Entre temps, j'me suis dit qu'il pouvait y avoir des gens avec des idées ailleurs que dans ce sujet, donc j'ai posté dans la section développement (en tentant de reformuler le problème de façon beaucoup plus ouverte, càd en présentant le problème général plus que la solution que j'envisageais) et sur IRC, et j'ai eu une bonne piste par IRC.

Ça se rapproche sans doute un peu de ce qu'on peut faire avec submodule, mais ça me semble plus simple et plus pratique à vue de nez: garder l'arborescence sus-mentionnée, en faisant de chaque répertoire un projet git séparé; et utiliser un autre outil (mr, qui permet de gérer plusieurs dépôts d'un coup) pour gérer l'ensemble comme étant un unique projet (avec un petit script maison pour refaire proprement les liens physiques après les mises à jour (en vérifiant qu'ils sont toujours identiques, bien sûr)). Comme ça, si d'autres gens veulent contribuer en travaillant plus classiquement, ç'possible aussi smile

Hors ligne

#82 Le 26/07/2016, à 22:05

grim7reaper

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

Elzen a écrit :

Si ça arrivait, il «suffirait» de refaire deux fichiers séparés, non?

Mais tu aurais deux copies quasi identiques qui représentent deux versions du même fichier, c’est de la gestion de version à la CPOLD tongue
Mais oui, dans ton cas ça a peu de chance d‘arriver de toutes façons.

Hors ligne

#83 Le 27/07/2016, à 17:57

Rolinh

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

Elzen a écrit :

De ce que j'ai pu en lire, git-submodule, ça a l'air d'être très exactement l'inverse: ça permet d'intégrer dans un dépôt un autre dépôt ayant un historique séparé; quand mon objectif est de faire un seul historique mais de permettre de récupérer chaque répertoire séparément.

SVN? big_smile

Pourquoi vouloir un seul historique? Ça me semblerait intéressant d'utiliser des sous-modules git pour un projet tel que celui-là. Tu as des projets assez distincts qui mis ensemble forment un tout cohérent. L'avantage avec des sous-modules, comme le dit grim7reaper, c'est que tu peux fixer les versions des sous-modules par exemple à des tags précis. J'avais fait une organisation comme ça pour le projet DevMine qui est composé de plusieurs sous-projets (voir ce dépôt). J'avais un Makefile global qui s'occupait d'invoquer les targets des Makefile de chacun des sous-modules.

Hors ligne

#84 Le 25/08/2016, à 16:18

Slystone

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

Dites, j'ai un script en python qui output du texte. Je voudrais qu'il écrive dans le panel (title bar pour les fenêtres), et qu'il écrase le nom de l'appli pour afficher le texte. C'est possible ? Vous feriez ça comment ?
Note: à la limite, on pourrait même faire 5s pour l'output du script, 5s pour le titre de la fenêtre, et ainsi de suite…


« Rigid, the skeleton of habit alone upholds the human frame. » - Virginia Woolf.

Co-fondateur de GoeLUG, le Gull du Havre

Hors ligne

#85 Le 26/08/2016, à 08:48

grim7reaper

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

Le plus simple, c'est de faire appel à xdotool à partir de ton script.

Si on veut rester dans du 100% python, ça va demander un peu plus de taf :
- utiliser une bibliothèque qui permet d’utiliser la Xlib en Python
- trouver l'ID X de la fenêtre dont tu veux changer le titre
- changer le titre de la fenêtre en changeant la valeur de sa propriété WM_NAME

Et si tu utilises Wayland, je ne sais pas comment ça marche pour changer le titre d’une autre fenêtre.

Hors ligne

#86 Le 29/08/2016, à 00:02

Slystone

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

Merci pour la réponse détaillée. smile Je vais regarder ça.


« Rigid, the skeleton of habit alone upholds the human frame. » - Virginia Woolf.

Co-fondateur de GoeLUG, le Gull du Havre

Hors ligne

#87 Le 29/08/2016, à 11:30

grim7reaper

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

Pour info, la commande xdotool va ressembler à ça :

xdotool search --name "Old name" set_window --name "New name"

Sachant que tu peux chercher par autre chose que le nom (cf. page de man).

Hors ligne

#88 Le 29/09/2016, à 15:19

Elzen

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

Bon, je ne retrouve plus le post, mais dans un précédent troll sur systemd, on avait causé du fait que faire tout faire par le PID 1, c'était un gros soucis. Bah, lu sur IRC (TW: article rédigé dans le ton habituel des trolls à propos de systemd, donc inutilement agressif).

Hors ligne

#89 Le 29/09/2016, à 18:39

Astalios

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

Après je m'intercale au mauvais moment, mais je ne sais pas ou apprendre a coder en autodidacte en ligne OC ma parlé mais je sais pas trop, je suis pas sur, j'ai appris a quoi le code servait sur solo learn, (appli mobile) sinon erci de votre aide :-)

Edit: j'aimerait faire un script qui affiche la température de l'ordinateur plus ou moins toute les heures (réglables) dans une fenêtre du style quand tu monte le son sur Portable, un peut comme VLC pour les utilisateurs, avec un jeu de couleurs qui indique si c'est la température est bonne trop haute, en affchant les dernières températures enregistrées, et surtout un palier (en plusieur niveaux) de température: un palier normal - haut et un palier haut-extrême, et même une extinctons auto pour sauvegarder les pièces du PC. enfin un logiciel type speed-fan super simple d'utilisation et réglable a souhait (dans la limite). Merci de votre attention.

Dernière modification par Astalios (Le 29/09/2016, à 18:50)

Hors ligne

#90 Le 30/09/2016, à 01:15

Slystone

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

Salut Astalios !
Je pense que pour ça le plus simple c'est d'utiliser conky (regarder du côté de sensors et fancontrol). Pour ça il n'y a pas besoin de coder, tout est déjà là (juste un conkyrc à configurer). Le script à faire servirait à demander un shutdown si la température dépasse tel seuil (sachant que microprocesseurs ont déjà cette sécurité). Tu as sans doute d'autres questions, mais je te laisse déjà éplucher un peu la doc et le forum.


« Rigid, the skeleton of habit alone upholds the human frame. » - Virginia Woolf.

Co-fondateur de GoeLUG, le Gull du Havre

Hors ligne

#91 Le 01/10/2016, à 07:19

Astalios

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

Sensors j'ai deja esaayer mais je n'y arrive pas a l'installer, fan control faut voir pas encore essayer de l'installer, je suis encore en 14.04 et sa fait depuis 2014 que je me ballade sur vos forums et du coup j'ai pu rechercher a l'installer, je vais reessayer quand j'aurais les clefs du bios de mon pc par securite.
Merci de ton aide. . :-)

Hors ligne

#92 Le 07/10/2016, à 16:53

grim7reaper

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

Elzen a écrit :

Bon, je ne retrouve plus le post, mais dans un précédent troll sur systemd, on avait causé du fait que faire tout faire par le PID 1, c'était un gros soucis. Bah, lu sur IRC (TW: article rédigé dans le ton habituel des trolls à propos de systemd, donc inutilement agressif).

Le ton est perfectible™ en effet (après, certains core dev’ de systemd en tiennent une couche aussi…, suffit de voir leur réaction sur certains bug), mais ce qu’il dit est pas déconnant.
D’ailleurs il reparle de systemd dans son dernier article.

Je suis tout à fait d’accord avec la citation qu‘il cite :

Jon Evans a écrit :

... as an industry, let's at least set a trajectory. Let's move towards writing system code in better languages, first of all -- this should improve security and speed. Let's move towards formal specifications and verification of mission-critical code.

Il faudra que j’aille lire l’article dont elle est tirée.

Sinon je suis en train de me faire la main sur Rust, et pour le moment je suis plutôt satisfait du langage smile

Hors ligne

#93 Le 06/11/2016, à 14:39

Elzen

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

Bon, j'ai fais une MàJ hier, et depuis un certain nombre des vieilles applis Touhy que j'utilise encore, en particulier mon client mail, segfaultent systématiquement à l'ouverture d'un fichier, ce qui est assez gênant.

Comment on détermine l'origine d'une segfault quand elle ne se produisait pas avant, que le code n'a pas bougé mais que la partie de code commune à ces différentes applis est assez conséquente?

Edit: trouvé \o/ Le coupable était mon usage manuel de la libmagic (à base de «ctypes.CDLL(ctypes.util.find_library('magic'))») pour déterminer l'encodage d'un fichier, que j'utilisais avant que kanor (me semble-t-il, et je crois bien que c'était sur ce topic, d'ailleurs, merci ^^) ne me fasse découvrir le paquet python-magic.

Bon, du coup j'ai simplement désactivé ça pour l'instant, et je tâcherai de comprendre ce qui ne va pas dans cet appel au juste quand je recoderai proprement (étant donné que j'aimerais quand même bien garder ce code en réserve pour le cas où python-magic ne serait pas installé…)

Dernière modification par Elzen (Le 06/11/2016, à 16:24)

Hors ligne

#94 Le 02/12/2016, à 13:21

The Uploader

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

How it feels to learn javascript
lol

(et sinon ça va les codeurs ? smile Perso je code surtout au boulot, et plus tellement perso, à part des petites choses pour Abandonware France, site auquel je participe beaucoup)

D'ailleurs si vous avez des ressources sur le reverse engineering (j'ai fait mon premier no-cd avec OllyDbg il y a quelques jours), je suis preneur. ^^


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4200, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster AWE64, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#95 Le 12/12/2016, à 09:12

grim7reaper

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

The Uploader a écrit :

J’avais lu cet article y’ un mois je crois.
Ça me semble un peu exagéré mais c’est pas totalement déconnecté de la réalité non plus.

The Uploader a écrit :

(et sinon ça va les codeurs ? smile Perso je code surtout au boulot, et plus tellement perso, à part des petites choses pour Abandonware France, site auquel je participe beaucoup)

Moi je fais pas mal de Rust (qui est un super langage, plein d’amour et tout) en ce moment (via Advent of Code).

The Uploader a écrit :

D'ailleurs si vous avez des ressources sur le reverse engineering (j'ai fait mon premier no-cd avec OllyDbg il y a quelques jours), je suis preneur. ^^

Je sais pas si c’est le genre de reverse qui t’intéresse mais y’a ça.

Hors ligne

#96 Le 12/12/2016, à 13:44

Elzen

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

The Uploader a écrit :

et sinon ça va les codeurs ? smile

Bah maintenant, je vais recommencer à avoir du temps pour coder smile

J'ai terminé ma config git bizarre avec le méta-repo et les liens symboliques, maintenant je commence à m'occuper des applis qui vont dedans.

Edit: par rapport à l'article, quand on code le HTML à la main et qu'on n'utilise le JavaScript que pour ce pour quoi c'est fait, à savoir manipuler le DOM du document HTML, ça marche très bien tongue

Dernière modification par Elzen (Le 12/12/2016, à 13:49)

Hors ligne

#97 Le 13/12/2016, à 20:23

Oni_Shadow

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

DrElzen, tu as obtenue ta thèse ?! Félicitation !


Travaux sur Unity 8 abandonné ? Pas par tout le monde !
─▶ Travaux sur les téléphones opéré par Ubport
─▶ Travaux sur le DE opéré par l’équipe de Yunit
N’hésitez pas à contribuer, toute aide est la bienvenue :) Premier objectif : passage de Mir à Wayland.

Hors ligne

#98 Le 14/12/2016, à 02:15

Elzen

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

Ouaip smile

Merci.

D'ailleurs, pour les gens qui n'ont pas peur du Java, mon démonstrateur est sous GNU GPL et je tâcherai de mettre un peu d'infos quelque part pour une release publique prochainement (j'ai fait quelques trucs assez chouettes dedans).

Hors ligne

#99 Le 14/03/2017, à 18:27

Dafyd

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

Bonjour tout le monde,

Ca fait une paye que je ne suis pas venu lire ce qui se dit ici !
Je souhaiterai expérimenter un langage fonctionnel, pour changer un peu de paradigme de programmation.
Auriez-vous de l'expérience dans ce domaine ?

Merci !

Hors ligne

#100 Le 14/03/2017, à 18:53

Elzen

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

J'ai fait un (petit) peu de Lisp.

Plusieurs personnes ici ont tenté le Haskell, il me semble.

Hors ligne