StreakyCobra a écrit 143 commentaires

Merci pour l'info, je n'avais pas été jusque là dans le fonctionnement de git. Par contre ce repository me surprend quand même un peu:

$ cd linux # Linux kernel sources from github, fraichement cloné
$ du -hs .git
1.1G    .git
$ du -hs .
1.7G    .
$ git rev-list --all --count
515454
$ 
$ cd ../gmic # GMIC sources, fraichement cloné
$ du -hs .git
528M    .git
$ du -hs .
659M    .
$ git rev-list --all --count
1518

Linux fait ~600M (1.7G - 1.1G), gmic fait ~130M (659M - 528M), linux a un repository de 1.1G pour 515454 commits, GMIC a un repository qui fait la moitié (528M) pour seulement 1518 commits. La différence me semble énorme non? Est-ce que cela viendrait quand-même la taille des fichiers?

Oui en traitant image par image je sais qu'il y a moyen d'améliorer la décoloration. Simplement je souhaitais automatiser cela pour mes documents en latex afin de proposer une version en niveau de gris optimisée pour l'impression. Je souhaitais en faire l'outil le plus généraliste possible afin qu'il marche avec tout type d'image. Cette conversion là marche bien sur certaines images, mais en supposant que j'aie d'autres couleurs, comme dans l'image suivante, il faut de nouveau changer de méthode.

C'est pourquoi je cherche une méthode telle que color2gray qui semble répondre à ce cas d'utilisation de manière générale.

Effectivement nous n'avons pas la même méthode de travail. En fait je n'ai aucun intérêt à voir la méthode de travail changer, vu que 1) mon niveau de C/C++ ne me permet pas de contribuer, et que 2) le projet fonctionne bien comme ça. Il faut plutôt voir mes remarques comme un retour utilisateur sur l'expérience que peut avoir une personne externe qui souhaite s'intéresser au projet. Si cela peut apporter quelque chose au projet tant mieux, sinon il n'y a qu'à les ignorer!

Merci pour la commande. Juste pour le fun j'ai essayé avec une des images en exemple dans le paper, une qui correspond aux diagrammes que j'ai à imprimer de temps en temps.

Malheureusement les couleurs sont dures à différencier en comparaison de ce que l'algorithme en question dit offrir:

Toutefois merci pour l'aide, et si un jour cet algorithme est porté dans GMIC je me réjouirai de l'utiliser!

Oui j'ai bien imaginé que la question avait déjà du être posée ;-) Il y a effectivement autant de façons de voir les choses que de développeurs. En étant le développeur principal, c'est sûrement ce qui te conviens le mieux et qui te permet de travailler le plus vite, et c'est très bien ainsi.

Je disais ça plutôt d'un point de vue d'un personne externe, telle que le verrai un éventuel développeur intéressé à contribuer. Voilà quelques réflexions en vrac (en pensant bien que je ne connais pas du tout le code), à utiliser si cela peut-être utile:

• Il m'a déjà fallu 20 min avec une bonne connexion internet et un bon ordinateur pour récupérer les sources. Bien que cela ne doive être fait qu'une seule fois, je n'ai pas eu la patience d'attendre que ça se termine la toute première fois que j'ai voulu y accéder, j'ai ctrl+c au milieu.

  $ git clone http://git.code.sf.net/p/gmic/source gmic
  [...]
  git clone http://git.code.sf.net/p/gmic/source gmic  15.81s user 3.66s system 1% cpu 20:00.48 total

• En ouvrant le dossier src après cela, on se retrouve avec 4 énormes fichiers contenant entre 10'000 et 50'000 lignes. Ça ne donne pas beaucoup envie d'entrer dans le code.

  50782 CImg.h
    484 Makefile
  13789 gmic.cpp
    378 gmic.h
  27820 gmic_def.gmic
  41275 gmic_def.h
   3826 gmic_gimp.cpp
     87 gmic_in_script.scm
    139 gmic_use_lib.cpp
 138580 total

• Les gens n'aiment pas spécialement avoir pleins de fichiers pour le principe, mais parce que cela permet d'avoir une carte mentale de ce qui se passe dans le code. Un exemple (totalement hypothétique) serait un dossier io/ avec tous les code gérant la lecture/écriture des images. Cela permettrait de savoir que si on veut ajouter du support pour un nouveau type d'image, c'est là-dedans que cela se passe. En entrant dans ce dossier, il y aurait le support d'un format d'image par fichier. Du coup le développeur n'aurait qu'à copier/coller un de ces fichiers et peut directement commencer à l'adapter au nouveau format de fichier. À l'inverse avec 4 gros fichiers, on ne sait pas ou chercher, comment s'appellent les méthodes, quelles méthodes doivent être fournies pour gérer un nouveau format d'image, etc. Par exemple dans un projet qui a une structure comme ceci:

.
├── commands
│   ├── cmd_debug.ml
│   ├── cmd_init.ml
│   ├── cmd_status.ml
│   ├── cmd_version.ml
│   ├── command.ml
├── core
│   ├── config.ml
│   ├── utils.ml
│   ├── workspace.ml
├── display
│   ├── ansi.ml
│   ├── display.ml
│   ├── render.ml
│   └── symbols.ml
├── main.ml
└── version.ml

On peut tout de suite voir quelle partie est dédiée à l'affichage, ou se trouve la configuration, quelles sont les différentes commandes, quel est le point d'entrée du programme, etc. Si a la place il y avait 2 ou 3 gros fichiers cela aurait été beaucoup plus difficile à comprendre qu'est ce qui se passe et où.

Pour résumer: le découpage du code ralenti un peu les gens qui connaissent le code, mais permet aux gens qui ne le connaissent pas d'y entrer plus facilement. Au final c'est le choix du développeur principal que de préférer la rapidité de développement ou l'accessibilité du code.

• git ne stockant pas les différences entre les versions des fichiers, mais bien le contenu des fichiers eux-mêmes à chaque commit, la taille des fichiers en question fait qu'une modification d'une seule ligne dans CImg.h pour un commit rajoute actuellement 472K au repository. Le découpage en plusieurs fichiers réduirait ce problème, qui est d'ailleurs la cause de la lenteur pour cloner le projet.

  $ echo "added" >> src/CImg.h
  $ git add src/CImg.h
  $ git hash-object src/CImg.h
  f62155609eb83c11ecfcb05107f079e914c62ff9
  $ du -h .git/objects/f6/2155609eb83c11ecfcb05107f079e914c62ff9
  472K  .git/objects/f6/2155609eb83c11ecfcb05107f079e914c62ff9

Voilà mes 2 centimes, en espérant que cela puisse être utile. Mais je tiens à noter que malgré ces quelques remarques, je suis impressionné par le rythme de développement de GMIC, comme quoi tout ça n'est pas si important!

C'est l'inverse, git n'enregistre pas des diffs, il enregistre les différentes versions successives des fichiers modifiés. Pour donner cette taille de 1.2M j'ai d'ailleurs ajouté un mot dans le fichier, fait un commit, et regardé la taille du blob :-)

Git book:

It is important to note that this is very different from most SCM systems that you may be familiar with. Subversion, CVS, Perforce, Mercurial and the like all use Delta Storage systems - they store the differences between one commit and the next. Git does not do this - it stores a snapshot of what all the files in your project look like in this tree structure each time you commit. This is a very important concept to understand when using Git.

La page en question est d'ailleurs une bonne ressource pour comprendre comment marche git en général!

Tout d'abord merci pour ce magnifique outil. J'ai déjà eu l'occasion de l'utiliser à bien des reprises, et certaines fonctionnalités telles que le patch-based inpainting lui sont uniques dans le monde du libre!

Récemment je cherchais un outil pour transformer une image couleur en niveau de gris, d'une manière à préserver le contraste. C'était pour insérer cette image dans un document à imprimer en niveau de gris, de manière à ce que les graphiques restent lisibles. En gros une implémentation de color2gray telle que présentée dans ce paper. Je n'ai pas trouvé de fonctionnalité s'y rapprochant dans GMIC, l'aurais-je loupée? Et si non est-t'il déjà prévu d'implémenter une fonctionnalité du style dans le futur?

Une question que je me pose en toute modestie et la raison l'organisation du code en 3 gigantesques fichiers? Je me la suis posée en cherchant si il y avait des occurrences de "decolorization" ou de "color2gray" (en rapport avec ma question précédente). Ne venant pas du monde du C/C++ je ne sais pas si il y a des raisons de performances ou autres à ce choix? J'y vois surtout des inconvénients, tels que la taille du repository git qui doit enregistrer un nouveau blob de 1.12M à chaque commit modifiant le fichiers gmic_def.h, ou encore la difficulté à entrer dans le code avec des fichiers de plus de 27'00 et 50'000 lignes. N'y a t'il pas moyen d'organiser la librairie dans différents dossiers/fichiers tout en les compilant en une seule entité? Ou est-ce devenu trop compliqué de le faire à ce point?

Merci d'avoir mis par écrit de manière clair et simple la réflexion que je me fais à chaque fois en lisant ce type d'article!

Si le but et l'utilisation par monsieur et madame tout le monde de Linux, la traduction des logiciels est suffisante. Si le but est de bidouiller, l'anglais est un passage obligé, donc autant s'y mettre. Je ne vois aucun intérêt à une distribution francisée.

Mais bon, au final chacun est libre de faire ce qui lui plaît!

Oui, et je passe mes journées a revérifier mes textes pour rajouter les "s" manquants. Quand ça ne veut pas rentrer, ça ne veut pas…

Sinon la question des fautes d'orthographe a déjà été discutée là et là. Cela sera corrigé dans la prochaine version, la 0.1.6.

Merci pour la notification orthographique ainsi que pour l'encouragement!

Salut,

Oui il y a déjà pleins d'autres gens qui ont listé des projets similaires, il semble y avoir du besoin dans ce domaine :-)

Concernant ton projet, il a effectivement l'air d'être une implémentation de ta manière précise de travailler. Il ne me conviendrai pas je pense. Malgré cela je m'inspirerai de quelques-unes de tes idées — dans l'hypothétique cas où j'écrirai un nouvel outil. Par exemple le fait d'afficher les erreurs à la fin, ou d'utiliser le stash comme sécurité pour des opérations qui modifieraient les repos.

Merci pour la présentation de ton outil!

Oui ça a déjà été mentionné plus haut.

Pour que l'utilisateur comprenne bien et vite que c'est une commande relative à l'outil Git.

Vu comme ça effectivement ça peut faire sens de le lier à git.

Après, rien ne t'empêche aliaser "git gws/git ws/git workspace" en "gws" de ton côté. Un indice : "git workspace" est sans doute la meilleur des trois propositions et éviter les alias barbares permet de « parler » une langue commune :)

J'adhère également sur le fait que "git workspace" serait le meilleur choix. Après il semble que cela soit déjà utilisé. "git ws" existe déjà également. Au passage il y a également "git slave" qui semble faire plus ou moins la même chose.

Si effectivement je fais un nouvel outil, son but sera de s'interfacer avec git/mercurial/darcs/etc. donc la question ne se posera pas vue que ça ne sera pas particulièrement lié à git. Pour ce programme-ci je ne pense pas changer le nom de l'exécutable, vu que quelques personnes l'utilisent déjà et que les noms "ws" et "workspace" de git sont déjà utilisés. Ce que je peux éventuellement faire c'est indiquer dans le README son utilisation via git en renommant ou liant l'exécutable. Je vais quand-même encore y réfléchir.

Félicitation pour ton outil.

Merci.

Plutôt que d'adapter le système de commentaires aux corrections orthographiques, je pencherai plutôt pour la mise en place d'un système à part inspiré des «Pull Requests» à la github:

Les utilisateurs qui voient une faute d'orthographe cliquent sur un lien "Reporter orthographe". Cela a pour effet d'ouvrir le journal/dépêche dans un champ texte comme lors de sa rédaction. Les personnes effectuent les changements orthographiques eux-même, puis cliquent sur "Prévisualiser" (ce qui highlight leurs changements), et ensuite sur "Envoyer" si cela leur convient.

Cela ajoute une demande de changement orthographique visible uniquement par les personnes avec droit de modification sur ledit article. En cliquant dessus, ces derniers voient un word diff coloré des modifications proposées avec 3 boutons: «Accepter», «Refuser» et «Accepter avec modification».

Ce système a plusieurs avantages:

• Fin des commentaires polluants, sans hacker le système de commentaires pour cela
• Les gens qui reportent l'orthographe n'ont pas à retaper une partie du contexte pour situer la faute, ils gagnent du temps
• Les modérateurs n'ont pas besoin de retrouver la faute et de refaire les modifications, ils gagnent du temps.
• Cela ne décourage pas de reporter l'orthographe pour ceux qui ne veulent pas polluer les commentaires.

On peut même imaginer simplifier la vie des gens avec droit de modification:

• Le diff affiché montre les changements entre la correction et l'article dans son état actuel. Cela évite d'afficher des modifications déjà intégrées.
• Si toutes les modifications d'un diff sont déjà incorporées, il est supprimé automatiquement.

Autres idées en vrac:

• On peut aussi afficher la liste des personnes qui ont contribué aux corrections orthographiques, d'où système d'encouragement à la contribution!
• Bonus: on pourra identifier les psychopathes de l'orthographe plus facilement.

Bref tout le monde gagne du temps et le fil de discussion y gagne en clarté. Le seul qui perde du temps et celui qui devra/pourra implémenter ce système.

Liste, pas exhaustive:

Cool merci, je les ai ajoutées dans l'issue #3, je les corrigerai pour la future release.

Heu, c'est loin d'être le seul problème dans le README! :-) Comme c'est court et que je suis content, je te l'ai reécrit viteuf et j'ai fait un PR. :)

Oui ce n'est de loin pas mon seul point faible (même que ce n'était pas mon repo ;-)), mais c'est LA faute que je fais à tous le coups, d'où mon point faible.

Oui je sais que c'est possible, mais je n'y ai pas encore vu l'utilité, à part ajouter 4 caractères à taper en plus chaque fois? Manquerais-je quelque chose?

Le but de peru n'est pas le monitoring d'un workspace, mais d'offrir «un outil pour inclure le code d'autres personnes dans vos projets».

Du coup il n'a pas de fonctionnalité pour suivre l'état des repos, ni de visionner l'état des branches. Il est possible de l'utiliser plus ou moins dans le même but, mais il n'est pas forcément pratique pour ça.

Effectivement ça semble plus ou moins faire le même boulot. Je ne connaissais pas, merci. Il lui manque peut-être juste la notion d'ignore-list pour ne pas manipuler les projets du boulot sur l'ordinateur de la maison, mais sinon il gère bien plus de fonctionnalités.

Je m'inspirerai de quelques unes de ses idées pour l’hypothétique suite de mon projet dans un langage maintenable ;-)

J'avais songé à y passer après avoir lu que Greg Kroah-Hartman l'utilisait (05.12.2014):

Do you still use Terminology?

I still use Terminology every day as my main terminal program. It's a great terminal, and the developers behind it are very active and responsive to bug reports.

Peut-être que j'y passerai quand j'aurais le temps de m'y intéresser:

• Pour avoir les mêmes couleurs qu'actuellement dans mon .Xresources (qui n'est pas supporté, sûrement pour de bonnes raisons mais bon, cela implique des changements quand même).
• Pour versionner les bons fichiers de configuration.
• etc.

Mon point faible, oublier ces ****** de s à la troisième personne. Merci je corrigerai ça pour la prochaine release.

Je n'ai jamais entendu parler de repo avant, peut-être parce que je ne fais pas de dev Android!? Donc je n'ai pas pu penser à me baser dessus.

À vrai dire je n'ai pas vraiment cherché ni vérifié si il existait des alternatives lorsque j'ai commencé à développer ce script. Ça à plutôt commencé par un script bash débile de quelques lignes pour mon usage uniquement, et il a fini par évoluer vers ce qu'il est aujourd'hui. C'est donc fort possible qu'il existe des alternatives qui marchent bien mieux, et il y avait sûrement des manières plus optimales de le faire. Je n'ai aucune prétention sur ce script ;-)

À première vu (après avoir lu la page de doc) je pense que tu peux effectivement faire la même chose avec android-repo. Il me paraît aussi offrir plus de fonctionnalités que mon script, ce qui se fait probablement au détriment de la simplicité.

PS: Ce n'est même pas du ncurses. Pur texte, 100% fait main. Pas de dépendances, rien.

Faut que je pense à faire des screenshots avec un bash pourri la prochaine fois ;-)

• Terminal: rxvt-unicode
• Transparence: compton
• Shell: zsh
• zsh config: oh-my-zsh
• oh-my-zsh theme: agnoster
• Font: inconsolata with powerline (powerline required for git related icons)

Je ne connaissais pas. Je vais le garder dans un coin de ma tête si je m'y mets un jour. Merci

Hum c'était dans le sens où il y a juste un fichier de configuration, un fichier texte, dont la syntaxe est très simple. Mais oui c'est un peu buzzword. Disons que ceux qui aiment les logiciels qui ne font qu'une chose, qui le font bien, et de manière simple, vont tilter que ça pourrait les intéresser.

Il explique que, étant donné sa phobie des nombres qu'il ne peut compter en utilisant ses doigts et ses orteils, il songe à repasser une version majeure du kernel (soit la 4.0)

Et il fera comment quand il n'arrivera plus à compter sur ses doigts le numéro majeur de la version (par exemple la 21.3.17)?

Vous avez 2 heures.

Quand je lis ce bout de phrase:

comme si j'allais avoir une érection de l'avoir fait moi même, le tout plus d'une heure pour avoir une arch configuré avec kde et deux trois programmes que je me sert

Je me dis simplement que tu n'es clairement pas le public cible d'archlinux. Pas besoin de taper du bois dessus parce qu'il ne te convient pas. Moi je suis content de le faire moi-même, que ça me prenne du temps, que ça me pousse à comprendre comment ça marche, d'installer mon environnement en assemblant pleins de petits programmes KISS pour avoir un bureau fonctionnel, d'utiliser AUR qui me pousse à m'intéresser aux PKGBUILDS, etc.

PS: J'ai lut en diagonal uniquement, les gros paragraphes sont indigestes à lire.

(Préambule: je ne connais pas bien le monde de Debian, corrigez moi si je me trompe)

Il faut bien espérer que toutes les distributions corrigent vite le problème vis à vis de la gravité du problème. Je constatais juste qu'avec du rolling release la correction était rapide et transparente pour l'utilisateur. Mais de toute façon ça n'a pas grande importance, qui utiliserai du rolling release sur un serveur ;-) ? (Pchuuut baissez les bras)

Cela semble être à jour dans sid (testing), mais pas dans les plus vieilles versions: par exemple jessie semble vulnérable. Après je ne sais pas si une simple mise à jour des packages sur une jessie corrige la faille ou non. Si c'est le cas, mea culpa.