Matthieu Moy a écrit 3251 commentaires

on se retrouve avec des sha1 différents

Bah non … je n'ai jamais eu l'occasion de tester en vrai, mais je viens de vérifier, « git clone --depth 1 » me donne bien un repo avec le même sha1 pour HEAD, j'ai pu commiter et pusher (le push n'est pas supporté d'après la doc par contre, ça marche « des fois mais pas toujours »). Bien sûr, un « git log » s'arrête là où l'historique local s'arrête.

Ça n'est pas parce que le commit parent est absent qu'on ne peut pas utiliser son sha1 comme référence. Git sait juste qu'il a une référence qu'il ne peut pas suivre parce qu'il n'a pas l'objet dans sa base locale.

Pour l'instant en tous cas, et à ma connaissance, le MPPA ne vise pas vraiment marché de masse avec des processeurs pas cher. Ça vise surtout les applications (embarquées) spécifiques pour lesquelles l'état de l'art est le FPGA voire ASIC ou le GPU.

Pareil ici. Pour l'instant, je fais du Digikam (et au pire, dans 20 ans j'aurai toujours des JPEG triés par répertoires même si j'ai changé d'OS et d'applications entre temps. Il coulera de l'eau sous les ponts avant que JPEG soit illisible) et j'utilise « Open in DarkTable » pour développer mes RAW (puis export depuis DarkTable vers Digikam pour récupérer le JPEG), mais j'aimerais un workflow mieux intégré. DarkTable a l'air vraiment bien …

Cela se fait soit avec ncurses, soit avec des codes de contrôle ANSI

Euh, un bête \r, ça suffit, hein …

printf 'bonjour'; sleep 1; printf '\rau revoir\n'

Il arrive effectivement que ça ne marche pas, mais si c'est désactivé par défaut (et typiquement activé que quand on écrit sur un tty), je ne vois pas trop le problème. Pleins d'autres outils font ça.

En général, quand on parle de scp, c'est qu'on aurait du parler de rsync (qui fait grosso-modo tout ce que fait scp, et plus). Pour une barre de progression fichier par fichier, il y a ça :

rsync --progress plop1 plop2

Mais effectivement, il faut penser à mettre --progress avant de lancer la commande. Si elle tourne depuis 2h et qu'on se demande quand elle va terminer, cv a l'air très bien.

Il n'y a pas que Windows où l'approche peut s'appliquer. OSMAnd+ coûte 3 € sur le play store (by jove, je me suis fait avoir, j'ai acheté le mien 6 € !), alors que c'est un logiciel libre et gratuit par ailleurs.

La simplicité d'installation en passant par le play store vaut bien les quelques euros, et si on en croit les chiffres sur la page, il y a déjà eu entre 50 000 et 100 000 installations (donc quand même quelques centaines de milliers d'euros, c'est pas du gros business mais c'est plus que de l'argent de poche déjà).

en montant ma main gauche se décale vers la gauche et ma main droite vers la droite, donc le décalage entre les lignes me semble assez naturel

Bah justement, le décalage est vers la gauche, des deux côtés …

Bah, c'est sans doute impossible, mais y'a quand même des gens qui l'ont fait :

https://sonicnotify.com/

Ça n'a pas la prétention d'avoir une grosse bande passante, mais pour transférer quelques octets, ça a l'air de marcher.

Je crois que tu confonds « profil google » et « compte google ».

Bah, si tu veux contrôler comment la photo de ton profil Google+ est affiché, alors que tu n'as pas de profil Google+, je crois quand même que la réponse est dans la question…

Bon, j'ai déjà posté le lien juste au dessus, mais si tu veux savoir ce qu'est une « recommandation partagée », je t'invite à aller le lire ici :

https://support.google.com/plus/answer/3403513?hl=fr&p=plus_sesetting&rd=1

Euh, oui, mais quel est le rapport avec les nouvelles conditions d'utilisation ?

Les nouvelles conditions disent : « Le paramètre "Recommandations partagées" permet de contrôler l'utilisation du nom et de la photo de votre profil dans les annonces associées à des recommandations partagées. », ça ne parle pas d'utiliser ton carnet d'adresses dans le prochain dépliant publicitaire de google, hein …

Pour ceux qui ne savent pas ce qu'est une « recommandation partagée », ils peuvent lire l'article, et cliquer sur le lien qui les amènera là :

https://support.google.com/plus/answer/3403513?hl=fr&p=plus_sesetting&rd=1

Bah, l'option, c'est pour dire si tu veux que ta photo apparaisse sur les trucs sur lesquels tu as fait +1 avec ton compte Google+, donc si t'as pas de compte Google+, la question ne se pose pas, non ?

Ah, OK. La présentation était la soutenance de projet des étudiants, et les choses ont bougé depuis, en effet.

Il y a 6 repositories sur https://github.com/dahuapp et c'est bien

Ceux dont le nom commence par Dummy, comme leur nom l'indique sont des dépôts ne contenant rien d'important (ce sont des petits exemples, qui ont servi à se lancer dans les différentes technos, gardés au cas où). C'est pour ça que les liens que j'ai donné pointent directement sur le dépôt Dahu, d'ailleurs.

(puisque la précision précise que ça ne marche que sur Firefox et Safari pour l'instant).

Euh … j'ai testé sous IE8, Chromium, Firefox, Konqueror, et les animations marchent chez moi. Est-ce que tu pourrais donner plus d'info sur le problème que tu as ?

Comment fais-je concrètement ? C'est un peu obscur pour l'instant.

Le code est dans le dépôt « Dahu », il y a quelques infos en plus sur le wiki : https://github.com/dahuapp/Dahu/wiki/_pages

Pour débugger les problèmes liés à la présentation dans le navigateur, une solution est de débugger dans le code « généré » (dahuapp.viewer.js, qui est en fait recopié depuis Dahu lui-même), et de répercuter sur le dahuapp.viewer.js contenu dans les sources une fois le problème résolu. Ça évite de recompiler Dahu à chaque fois.

(La vidéo à voir sur le sujet : http://www.youtube.com/watch?v=BDtvzCgPlEc )

Pas vraiment « vidéo », mais pour faire ce genre de tuto, il y a maintenant Dahu : http://dahuapp.github.io/ (très inspiré de Wink, pour ceux qui connaissent)

C'est encore très jeune, pas bien fini, mais ça commence à être fonctionnel. À la base c'est un projet que j'ai fait coder par mes étudiants, et je continue à coder un peu dessus.

(Sur cet exemple en particulier, l'approche vidéo est supérieure, pour avoir les belles animations ceci dit).

Ajoute des guillemets (") autour, ça désactive la plupart des trucs intelligents.

Euh, pas dans le cas général. Si le code source a un comportement indéterminé, alors le compilateur peut faire un truc qui marche une fois sur deux.

On parle de bug (pas dans le compilo, mais dans le code à compiler), là, donc supposer qu'il n'y a pas de comportement indéterminé est optimiste.

(pour la prédiction de branchement, c'est presque vrai par contre vu que seules les perfs peuvent changer)

puisque personne ne se dévoue, et qu'il faut quand même bien que quelqu'un cite XKCD …

http://xkcd.com/747/

Vous ne parlez pas de la même chose à mon avis. Il y a la résolution de l'image bitmap (typiquement en 24 bit par pixel), et celle de l'impression (taille des goutes d'encres, la goute est là ou pas donc 4 bit par pixel si on compte le noir)

La mémoire de PC est cohérente de partout normalement.

Ça dépends de ce que tu appelles « cohérente ». Si c'est sequential consistency, alors non, ce n'est pas le cas.

Une fois une données écrite quelques part, elle est visible par tous de la même façon.

Non, même le modèle mémoire x86 ne garantie pas ça. Quand tu fais une écriture, elle passe d'abord par un write buffer, et celui qui a écrit peut relire la nouvelle valeur alors qu'elle n'est pas écrite partout. Par contre, c'est du TSO (total store order), donc les écritures sont vues dans le même ordre par tout le monde, ce qui est déjà une propriété assez forte par rapport à d'autres architectures (et qui permet souvent, mais pas toujours, de se passer d'opérations atomiques pour des lectures/écritures d'entiers). Tu peux regarder ce que GCC génère pour les opérations atomiques de C++11 pour t'en convaincre (de mémoire, toutes sauf le memory_order_seq_cst génèrent des movl).

Ton volatile ne servira pas à grand chose : rien ne garanti que la lecture ne se fera pas dans un cache ou un write buffer pas flushé. cf. le lien "volatile considered harmfull" que j'ai posté dans un autre commentaire.

Tout à fait. Avec un peu de chance, le disque sera monté avec une option genre data=ordered et ça n'arrivera pas, mais c'est difficile de le garantir …

Pour les détails, lire : « Why the "volatile" type class should not be used »
https://www.kernel.org/doc/Documentation/volatile-considered-harmful.txt