Goffi a écrit 1556 commentaires

Super intéressant l'article sur le DIY, de nombreux liens sympa. À compléter via les liens dans les commentaires du journal que j'avais posté sur le sujet: https://linuxfr.org/~Goffi/30127.html . Au passage, il y a aussi le site howstuffworks que j'avais oublié de citer et d'autres équivalents (cf la page wikipedia: http://en.wikipedia.org/wiki/Howstuffworks et en particulier http://en.wikipedia.org/wiki/WikiHow qui semble très intéressant). On en arrive presque à un point où il y aurait trop de sites sur le sujet :) .
D'ailleurs c'est marrant (façon de parler), j'avais connu le DIY du point de vue politique, je me rends compte (surtout depuis que je suis en Australie où on le voit à toutes les sauces) que c'est pas mal utilisé d'un point de vue purement commercial maintenant.

L'article sur la sécurité des sources dans le journaliste est intéressant aussi.

Merci pour ces revues, ça m'a permis plus d'une fois de voir des bons articles que j'aurais raté autrement.

Je re-precise ici parce que c'est peut etre passe inapercu tout en bas des commentaires, mais j'ai publie hier une version mineure (0.1.1) qui corrige les problemes que tu as cite (et quelques autres), avec notamment l'affichage des fichiers qui n'ont pas ete copies a la fin de la copie.

Bon, je viens de publier une version mineur qui corrige les petits problèmes suivants:
- syntaxe gcp FILE FILE_DEST maintenant gérée (cf premiers commentaires)
- erreurs affichées en fin de copie (cf même commentaires)
- mauvaises fermetures des fichiers/du journal en cas de fichier existant corrigée
- erreur lors d'envoi du chemin source via dbus (via une deuxième instance de gcp) corrigée
- et quelques bricoles mineures

Bon maintenant ça vraiment être difficile de bosser dessus dans les semaines à venir, j'espère qu'il n'y a pas de bug majeur... N'hésitez pas à m'envoyer un patch si vous en voyez un ;)

Wow wow, on se calme la...
1) c'est justement taggue 0.1 et non 1.0, c'est precise experimental et tout le tralala
2) j'ai poste un journal et on m'a demande de faire une depeche. J'ai meme mis en commentaire que je n'ai pas fait de depeche pour mes autres projets car pas assez utilisables.
3) ce n'est meme pas un bug dans le sens que n'est indique nulle part que gcp gere cette syntaxe (mais il y a d'autres bugs je te l'accorde)
4) j'ai demande a personne d'utiliser mon truc, je l'ai fait pour moi, et je le mets en ligne *au cas ou ca servirait a d'autres*
5) y'a eu des journaux pour des projets de projets (Diaspora au debut), des depeches pour du cinema, ou des trucs ultra-alpha. Si on n'attend que des trucs bullet-proof, y'aura plus grand chose sur linuxfr
6) quand je pense que je viens de perdre 5 min pour repondre a ce commentaire, je comprends pourquoi des fois je passe des nuits sur le net sans rien faire d'utile...

mais si l'auteur souhaite que son outil termine utilisé par tout le monde en remplaçant de ce bon vieux cp ou scp
Ca tombe bien, ce n'est pas le cas (comme explique dans la depeche d'ailleurs.

C'est un outil fait rapidement pour un besoin perso parce que ca faisait longtemps que ces fonctionnalites me manquaient. Maintenant ca repond (a peu pres, sujet a ameliorations) a mon besoin. Si ca sert a d'autre, tant mieux; sinon ben lancez vous dans le votre les gars...

J'ai fait ca vite, ca fonctionne, et ca tient en peu de lignes. Bref, merci python.

PS: je viens de voir que naha a fait exactement la meme reponse que moi =)
PPS: et dans les rapides tests que j'ai fait, c'un peu plus lent que cp, mais ca se tient. A tester plus en profondeur (et optimiser au besoin)

C-z ;)

Plus serieusement, tout ca est envisageable (mais encore une fois, ce n'est *pas* mon projet principal, donc ca risque de mettre le temps)

Oui je viens de jeter un œil: c'est un cas particulier qui n'est pas (encore) géré.
pour le moment, gcp prend dest toujours pour un répertoire. Or dans ce cas précis (un fichier copié dans un autre avec un nom différent), ça doit être pris pour un fichier. Du coup il essaye de copier dans blah/fr.pa/fr.po au lieu de blah/fr.pa.

Je corrigerai ça, mais pas avant quelques jours, je ne peux pas avant...

cp oui, mais j'ai deja eu le cas de copies interrompues a cause d'une erreur (souvent le pb des noms avec FAT d'ailleurs). La tout de suite je ne sais plus ou et quand, peut etre avec une interface graphique... enfin bref

Hum l'option au milieu des arguments c'est pas tres standard. Jette un oeil a la doc de optparse dans la bibliotheque standard python (meme si tu n'est pas pythonneux), ils expliquent pourquoi ce genre d'option avec importance de la position ca ne va pas.

bon sinon pourquoi pas, l'idee est pas mauvaise.
Le debit et le temps total c'est deja indique.
Les erreur en fin de copie, comme dit dans mon autre commentaire, c'est prevu juste pas encore implemente (j'en suis au publish early, maintenant ca va etre du publish often si possible)

Ah non, ce n'est totalement pas normal. Le probleme c'est que j'ai difficlement access au net et a mon ordi en meme temps (net a la bibliotheque - qwerty, dsl pour les accents -), et je vais bientot reprendre la route - si tout va bien -. Je jetterai un oeil des que je pourrai travailler un peu plus confortablement.
Merci du retour en tout cas, je mettrai un outil de report de bug en ligne des que possible.

PS: le journal se trouve dans ~/.gcp/journal . Il dit quoi ? J'ai prevu d'afficher la liste des fichiers qui ont echoue en fin de copie aussi.
PPS: l'outil graphique avec glisser/deposer arrivera probablement a la fin de l'annee.

Parce que, comme dit en introduction de journal, j'ai perdu ma boite de vitesse, et je suis coince dans le village (et bon Cable beach et les chameaux c'est sympa, mais au bout d'une semaine tu t'en lasses).

Et de toute facon, je suis venu en australie aussi pour coder (comme ca ca fait un peu bizarre, mais il y a de vraies raisons derriere)... mais ne t'inquiete pas, je ne me suis pas prive de paysage et autre animaux extraordinaires, et surtout de rencontres...

Bref, coder et voyager, c'est pas incompatible ;) (et aussi ecrire, discuter, faire la fete, decouvrir, nager, observer, partir en randonnees).

exactement: comme pour lm, c'etait un besoin perso fait en quelques jours, et je propose parce que ca peut servir. mon veritable investissement personnel, c'est dans mon gros projet (sat, client xmpp). Du coup le python ca marche bien, et c'est rapide.

Pour info je code aussi en C (j'ai meme deja developpe un pilote sous pour nux, cf mon site), mais je n'ai juste pas le temps ni les ressources (le net surtout !) suffisantes en ce moment pour contribuer a rsync.

En fait bref, ca fait ce que je veux, et je l'ai fait vite.

j'y ai crame aussi, malgres la creme solaire ;).
La on est au debut du printemps (enfin a la fin de la saison seche), et c'est limite insuportable de rester dehors tellement il fait chaud...

alors dans l'ordre:

Donc dans le cas où tu fais une copie d'un disque A vers A, et une autre d'un
disque B vers B, le problème que tu soulèves n'a pas lieu d'être, mais il n'y
aura qu'une seule copie à la fois ?


- oui pour le moment, mais je peux eventuellement faire une option pour desactiver ce comportement (mais c'est a etudier, parce que du coup cq complique pas mal de choses: l'access en concurence aux fichiers de conf, la gestion de la queue a utiliser, etc.


Et puis même, à supposer que je fasse une grosse copie d'un côté, j'aimerais
pouvoir faire une copie d'un petit fichier de l'autre côté sans attendre que la
première prenne fin.

Utilise cp pour ta deuxieme copie ;)

Enfin, est-ce qu'utiliser Python pour gcp ne risque pas d'avoir un impacte
significatif sur les performances ?
j'ai fait des tests tres rapides, ca a l'air de se tenir avec cp, faut faire des tests plus pousses.

apres le troll du langage ma passe loin au dessus de la tete: j'ai fait ca pour mon besoin, et python m'a permis de faire ca tres rapidement.

D'autant plus que je lis dans les sources que tu récupères le buffer de 4096
bytes dans une chaîne python pour l'écrire dans le fichier cible, et qu'entre
chaque itération tu retourne au watcher glib qui va effectuer à nouveau un appel
à la méthode python. Je pense que ça a un coût non négligeable.

il faut retourner a la glib pour gerer les eventuels appels dbus qu il y a eu entre temps, mais le coup devrait etre negligeable. encore une fois il faut tester, et ajuster les valeurs au besoin.


Et sinon, je m'interrogeais :

except KeyboardInterrupt:
raise KeyboardInterrupt

Pourquoi tu captures l'instance d'une exception pour en raiser la classe
équivalente ? :)

parce que sinon elle sera passe sous silence avec le try except, et que je veux qu'elle soit recupere par le try/except de plus haut niveau. si tu as une meilleure solution je suis ouvert, et les patchs/commentaires sont les bienvenus...

Wow, 42 commentaires (c'est un signe !) en une nuit, je ne pensais pas a une telle reaction.
Oui une depeche pourquoi pas, jusque qu'en general je prefere attendre que ce soit vraiment utilisable (c'est la raison pour laquelle je n'ai pas encore propose de depeche pour mon projet principal, sat).
enfin dans ce cas, c'est deja utilisable en l'etat, du coup je vais proposer si je trouve un moment.

PS: desole pour les accents, je suis sur un clavier qwerty...

Je t'invite à lire le précédent journal que j'ai cité car on y a eu la même conversation.

Amiga, Duke Nukem...

Putain, qui c'est qui a encore fait le con avec la DeLorean ?

Allez, si vous voulez troller, lachez vos jeux préférés... Bon, dans ceux qui me reviennent:

- Wings \o/. Super jeux de simulation de vol, avec la mitraillette qui lachait et tout, absolument énorme. Me souviens de l'intro avec les frères Wright
- Shufflepuck Cafe: un jeu type hockey dans les salles de jeux, qui se jouait à la souris, très bien réalisé, qui avait l'unique défaut de ne pas se jouer à deux. Il existe un remake libre (et abandonné il me semble): tuxpuck
- Marble Madness: un grand classique où il falllait bouger des billes dans un décord 3D. Il a probablement inspiré Neverball, bien que je n'y retrouve personnellement pas tout à fait le même plaisir (le gameplay est différent).
- Croisière pour un cadavre, et l'excellente feu Delphine Software, je me suis passé et repassé l'intro en boucle pendant des lustres
- Powermonger: stratégie temps réel
- Bon, inutile de citer les LucasArt (enfin, LucasFilm Games à l'époque), avec en tête Monkey Island, Loom & co. Scummvm vous permettra d'y rejouer sur pratiquement toutes les plateformes, avec possibilité d'améliorer le rendu graphique (ou de garder le rendu original). Une des superbes réussites du Libre
- North & South: excellente adaptation de la BD en jeu de stratégie, j'avais fait un remake sur TI à l'époque :)
- Another World: encore une superbe réussite de Delphine Software, fait pratiquement entièrement (à la musique près il me semble) par Éric Chahi (une des premières réalisation - avec Prince of Persia - à utiliser une technique proche de la motion capture). Un remake du moteur était en cours, mais malheureusement stoppé à la demande d'Eric Chahi lui-même
- Speedball 2: ceux qui ont connu se souviennent probablement des "Ice cream" dans les spectateurs. Ce classique, produit par les Bitmap Brothers, rappelle l'ambiance du film Rollerball. J'aimerais beaucoup voir un remake libre...
- Battle Chess: un jeu d'échec où les pions se battaient à l'instar du jeu dans La guerre des étoiles (épisode IV)
- Toki: grand classique de l'arcade adapté sur Amiga, un mec changé en gorille doit retrouver sa fiancée
- flashback: un peu une suite spritiuelle de Another World: un mec se réveille après avoir perdu la mémoire.
- Battle Isle: surtout le premier du nom, excellentissime wargame en tour à tour. Il y a un clone libre, Crimson Fields, je n'ai jamais essayé, il vaut quoi ?
- Rick Dangerous: Indiana Jones version jeu de plateforme (il y a eu plusieurs jeux d'aventures Indiane Jones chez LucasFilm games), un autre grand classique. J'avais vu passer une version qui tenait en 64 ko !
- Elf: jeu fait par 2 étudiants à l'époque il me semble, bourré d'humour.

Aller, je vous en laisse un peu :)

Et pour l'émulation, vous utilisez quoi ? E-UAE ?

Rien ne t'empêches de compiler toi même si t'es impatient ;)

Comme je l'avais déjà dit dans un commentaire sur un précédent journal, la reconnaissance automatique de visage est dans les cartons (projet GSoC), mais aussi la retouche d'image non destructive et le marquage géographique inversé (reverse geotagging). Je vous laisse consulter les dernier billets des blogs des auteurs (tous en anglais), avec notamment l'explication de ce qu'est le reverse geotagging:

- reconnaissance de visage, libkface: http://adityabhatt.wordpress.com/2010/06/23/digikam-gsoc-pro(...)

- retouche d'image non destructive: http://www.digikam.org/drupal/node/534

- marquage géographique inversé: http://www.digikam.org/drupal/node/532

Bon je me réponds à moi même puisque je viens de lire la doc (oui oui RTFM)

Pour combiner :g et les macro, il suffit de faire
:g/regex/normal @[registre]
terrible :)


de quoi mettre l'accent sur un autre point excellent de vim: une feature non documentée est une feature qui n'existe pas (et la doc en ligne est excellente).

Donc pour re-répondre, non je ne dépends pas de D-Bus.
Comme expliqué dans le journal, j'utilise un "pont" (une IPC) pour communiquer entre le démon et les frontends.
Pour le moment c'est D-Bus qui est utilisé, mais rien n'empêche d'utiliser autre chose, comme par exemple xml-rpc. Je compte d'ailleurs automatiser la génération du pont, probablement depuis un fichier XML ou équivalent. On peut même envisager d'avoir un pont qui passe un réseau, et ainsi le démon sur un nux, et un frontend sur zin (ce que d'ailleurs D-Bus devrait permettre à terme).

Ouai ouai c'est ça, tout ça parce que j'ai dit que j'utilisais vim, c'est bas, c'est très très bas !

En fait j'ai cru que c'est parce que j'avais écrit \_o<~ COIN, je me suis dit "merde, ils ont vraiment fait pan! pan! ce coup-ci" :)



Bon sérieusement, merci d'avoir restauré rapidement, et pour ce commentaire :)

Persistance de l'historique des commandes pouvant être annulées ;
Alors ça, c'est une killer feature !

Allez quelques astuces en route que tout le monde ne connait par forcément:

C-a incrémente la valeur sous le curseur. Ça peut se configurer pour transformer un True en False et inversement, excellent pour éditer des fichiers de conf
C-x même chose mais décrémente

. (oui juste le point) répète la dernière commande, et c'est probablement une des killer features que j'utilise le plus sous vim, INDISPENSABLE

le undo marche oui, mais vim gère les undo en branche ! Autrement dit, dans un éditeur classique, vous faite une modif sur votre code, vous annulez plusieurs fois (un peu trop), votre chat a le malheur de passer sur le clavier, boom impossible de restorer le code.
Sous vim, vous pouvez annuler et refaire bien sûr (U et C-r), mais vous pouvez aussi utiliser g-/g+ qui remet votre texte à un état antérieur (genre 4 min avant). Ça aussi quand on connait le truc on ne peut plus s'en passer.

vous connaissez tous :s/toto/titi/ qui remplace des mots en suivant des regex, mais peut être ne connaissez vous pas :g/toto/command qui execute une commande sur la ligne quand il trouve la regex .

les macros sont une mine d'or quand on effectue des taches répétitives: tapez q[registre] pour lancer l'enregistrement. Quand vous avez fini, q à nouveau, puis @[registre] va retaper la même liste de séquences. D'ailleurs si vous connaissez un moyen de combiner les macro avec la commande :g précédente, je suis preneur.

une petite dernière pour la route: vous avez ouvert un fichier système mais avec oublier de l'ouvrir en root, et vous voulez l'enregistrer mais impossible. Faites :w ! sudo tee % , tapez le mot de passe, et voilà :). Avant, le seul inconvénient de cette méthode était que vous perdiez l'historique de modification, avec les features de cette version, ça ne devrait plus être le cas.

Si on suit ton raisonnement, les commentaires des scipts perl doivent être écrits en langage des signes... ben ça va pas aider à la compréhension ça !