liberforce a écrit 4750 commentaires

Ok, après avoir consulté ce guide sed:

h va copier la ligne lue dans le hold buffer, pour la mettre de côté
G va ajouter sur une nouvelle ligne le contenu du hold buffer à la fin du pattern space
N ajoute la ligne suivante à la fin du pattern space

Donc h;G va dupliquer la ligne lue, pour avoir:

User1
User1

Puis N va lire la ligne suivante:

User1
User1
Password1

Ensuite le (plus connu) s/\n/;/g va remplacer les retours chariot par des ;, ce qui donne :

User1;User1;Password1

Et ainsi de suite…
Faudrait vraiment que je me penche sur le traitement multi-ligne avec sed…

J'utilise sed à l'occasion, mais là c'est un peu obscur pour moi… Si tu pouvais explique un peu ce serait top.

PS: il doit manquer un < monfichier.txt à la fin aussi…

L'indentation est significative en python, et lire un paté de code mal formatté ça ne donne pas très envie. Je te conseille déjà de lire l'Aide mémoire sur la syntaxe wiki situé sous le champ de rédaction de message. Le dernier exemple indique comment inclure du code (remplace ruby par python pour avoir la coloration syntaxique appropriée).

def QUINTE(main):
    """
    permet de savoir si la main est une quinte ou non
    """
    a=[(7,8,9,10,11),(8, 9, 10, 11, 12),(9, 10, 11, 12, 13),(10, 11, 12, 13, 14)]
    b=sorted(main)
    for k in range (len(a)):
        if b==a[k:k+4]:
            return 1
        else:
            return 0

C'est plus facile à lire, n'est-ce pas ?

Bon, à partir de ça, on voit que tu as tout de même listé les suites possible, que tu tentes de boucler dessus… Sans savoir ce que contient main, c'est difficile de déduire le comportement. Ensuite si tu veux boucler sur les différentes suites possibles contenues dans a, tu peux faire for k in a pour itérer sur tous les n-uplets de la liste a.

La notation la plus lisible et rapide reste néanmoins de te débrouiller pour avoir dans b un n-uplet trié correspondant à ta main, comme (9, 10, 11, 12, 13), puis de remplacer ta boucle par return b in a. L'opérateur in renvoie True si b est inclus dans a (c'est à dire que a contient b), et False sinon. Ainsi tu évites une boucle inutile, et tu utilises des types booléens qui sont faits pour ça plutôt que 0 et 1.

Déjà pour savoir si une main est une suite (aussi appelée ­— plus rarement — quinte), je commencerais par ne pas créer la liste de toutes les quintes possible pour voir si celle-ci est dedans. Ça prend du temps de calcul inutile.

Pour savoir si une main est une quinte, une manière simple est de donner une valeur numérique aux cartes non-numériques (valet, dame, roi, as), puis de les trier par valeur croissante. Si tu as un as dans la main, le traiter de manière spéciale (valeur 1 ou 14). Si toutes tes valeurs se suivent, alors tu as une suite. Si elles sont en plus d'une couleur unique (trèfle, pique, coeur, carreau), alors tu as une quinte flush.

card.suit plutôt que card.color, semble-t-il.

Je ne vois pas trop l'utilité d'un masque de bits pour les couleurs, tu n'as besoin que de 2 bits pour coder 4 couleurs, et 4 bits pour les valeurs soit 6 bits pour une carte. Tu pourrais même coder une main de 5 cartes sur 30 bits et que ça tienne donc sur 4 octets (faut être un peu vicieux à ce stade tout de même, on perd en extensibilité).

Pour ce qui est du python, j'utiliserais plutôt un NamedTuple pour faire des card.color et card.value.

Oui enfin là ce serait coder en python comme en C, l'intérêt est limité.

En même temps au bout de quelques lignes tu vois bien que l'article est un gros troll. Oui il y a des logos moches, m'enfin le pied de GNOME, Wilber la mascotte de GIMP, et le pigeon violet de pidgin me semble des logos reconnaissables et réussis (certes, je ne suis pas graphiste). Ce n'est pas comparable à d'autres logos "moins réussis" montrés dans l'article. Je ne connais pas de projets libre avec un logo tout moche qui refuserait un joli logo soumis par un contributeur. Le problème c'est que les graphistes contributeurs, ça pousse pas sur les arbres.

Bref, circulez, y a rien à voir.

Je pensais au début que NeoVim interprétait différemment certaines commandes pour les rendre asynchrones, merci de m'avoir détrompé ;). Je ne l'ai pas encore utilisé, c'était plus des souvenirs de lectures…

Ah, effectivement, si tu es sûr que le problème vient du plugin qui n'est pas asynchrone… Je prends bonne note de l'existence de ALE, en tout cas, merci :). N'hésite pas à refaire un journal pour un retour d'expérience ;).

Il me semble que NeoVim n'a plus ces problèmes de lancement synchrone, ça a été rendu asynchrone, ça vaut peut être le coup d'essayer si tu veux conserver ton plugin ?

Cf paragraphe Meet Neovim: Plugin Compatibility.

Tu peux retourner le truc pour dire que justement c'est un outil pour remplir facilement ton temps libre, c'est moins prétentieux du coup ;).

Pour le nom en anglais, effectivement ce serait mieux, mais comme vous utilisez l'abréviation EDT qui n'est de toute façon pas en anglais, autant aller au bout et prendre un nom en français. Le logiciel est multi-langue ?

Je propose TempsLibre, ou TempsLibreEDT. Parce que c'est libre, et que ça fait gagner du temps. Les anglophones ont le problème de sens de "free" (libre/gratuit) dans leur langue, d'où leur utilisation d'Open Source. Toutefois, le français n'a pas ce problème, alors autant préférer "libre" si on donne dans le pur francophone.

C'était pas ma guerre mon colonel !

81 pièces, 4 pesées et une balance. Il suffit de diviser les pièces en 3 tas, successivement.

Use pesée se fait donc ainsi:
- On divise les pièces suspectes en 3 tas du même nombre de pièces.
- On met le tas n°1 d'un côté de la balance, le tas n°2 de l'autre côté de la balance, et on ne pèse pas le tas n°3.

Comme il n'y a qu'une seule pièce piégée, un des tas est forcément plus lourd que les autres, c'est celui qui contient la pièce piégée.

Au moment de la pesée, 2 possibilités:
- soit la balance est à l'équilibre, ce qui indique que le tas le plus lourd est celui qui n'a pas été pesé
- soit la balance n'est pas à l'équilibre et indique directement le tas le plus lourd

Une pesée permet donc de diviser par 3 le nombre de pièces suspectes. Effectuer 4 pesées successives va donc les diviser par 3⁴ = 3 × 3 × 3 × 3 = 81. Cela devrait donc effectivement converger:

• Après la première pesée, on se retrouve avec 27 pièces suspectes, les autres n'étant pas piégées.
• Après la deuxième pesée, on se retrouve avec 9 pièces suspectes, les autres n'étant pas piégées.
• Après la troisième pesée, on se retrouve avec 3 pièces suspectes, les autres n'étant pas piégées.
• Après la quatrième pesée, on se retrouve avec 1 pièces suspecte, c'est la pièce piégée.

Mais on peut aussi s'arrêter à la 3ème pesée vu qu'on a déjà mis de côté 97,5% du trésor. Cela donne un peu de temps pour écrire un petit mot au dos de celui d'Eingousef:

« Cher Eingousef,

je te remercie d'avoir laissé cette balance de Roberval, et cet indice sur le poids de la pièce. On fait 50/50 comme d'habitude ? En gage de bonne foi, voici les 2 premières pièces, je te laisse le reste à l'endroit convenu.

Signé: M4rotte.
»

Puis je sors avec les 3 pièces (dont la pièce piégée), les place dans le mot plié, et cache le mot dès ma sortie de la banque dans une ruelle sous les poubelles, et m'en vais tranquillement. Je laisse à Eingousef le soin d'expliquer à la police son implication pendant que je dépense une partie de mes 78 pièces pour partir siroter une pina colada sous les tropiques…

https://fr.sputniknews.com/sci_tech/201807061037085316-chrome-securite-web/

Attention! Les moteurs de recherche Google Chrome et Mozilla Firefox savent espionner en secret leurs utilisateurs, avertit un informaticien américain qui a détecté une extension enregistrant tous les sites visités.

Déjà, l'informaticien qui dit que Chrome et Firefox sont des moteurs de recherches, c'est déjà assez énorme. Je suppose que le malheureux journaliste qui a écrit ça a un peu de mal avec l'informatique. Mais le titre en lui même est vraiment trompeur:

Un informaticien US explique comment Chrome et Firefox vous espionnent en secret

On laisse entendre que ce sont Chrome et Firefox qui font l'espionnage (et donc Google et Mozilla) alors que là c'est une société tierce qui fait une extension. Vu l'autre boulette, ça n'a pas l'air d'être fait pour ternir la réputation des navigateurs, mais ça ressemble plus à de l'incompétence.

Comment ça Sputnik n'était déjà pas crédible ?

et de lesfinances

La prochaine fois, essaie trainline.fr (anciennement capitaine-train). L'interface est simple et c'est difficile de se tromper.

Second degré inside…

Le frigidaire ou le congélateur c'est une technique pour globalement éviter qu'un composant endommagé chauffe trop pour permettre d'avoir le temps de récupérer des données, j'ai déjà entendu ça pour des disques durs mécaniques notamment. Pour le four c'est plutôt pour une carte (carte mère, carte graphique, etc.) qui peut avoir une soudure défaillante. Faire chauffer peut faire fondre la soudure en question qui en changeant de forme peut être réparée une fois refroidie. Mais dans le cas d'une carte mémoire, ça me paraît illusoire, et me semble avoir plus de chances d'achever la carte qu'autre chose. En tout cas ce n'est à tenter que quand tout le reste a échoué. Or j'ai parlé plus haut de recoverfab qui peut potentiellement récupérer les données d'une carte du moment qu'elle n'est pas endommagée physiquement. Ce serait donc dommage de griller définitivement la carte avant d'être passé par un service qui a plus de chances de fonctionner.

https://www.youtube.com/watch?v=y-jrzsaT6ls

Ce qui est marqué c'est que le taux de réussite est de 92%, mais que ce taux ne concerne pas les cartes microsd.
Une ligne au dessus tu as un lien vers leur video qui explique le processus de récupération pour du microsd.
https://www.youtube.com/watch?v=y-jrzsaT6ls

À la centrifugeuse…

Un ami qui fait de la récupération de données sur disques durs m'a conseillé ceci:
http://recoverfab.com/

Il leur sous-traite la récupération de données sur des cartes mémoires, qui demande du matériel différent. Je n'ai aucune idée du tarif en revanche, mais si tu penses sérieusement contacter une société spécialisée, ils ont l'air de confiance, et peuvent récupérer des données même si la carte n'est plus détectée.

$ conan search jsoncpp -r all
Existing package recipes:

Remote 'conan-center':
jsoncpp/1.0.0@theirix/stable
jsoncpp/1.8.4@theirix/stable
jsoncpp/1.8.4@theirix/testing

Je ne connais en revanche pas la situation des libs précompilées pour Android, iOS et OSX, mais un conan install jsoncpp/1.8.4@theirix/stable --build=missing sur les plateformes en question devrait te permettre de les builder. Une fois fait, c'est disponible dans ton dépôt local. Il faut toutefois que celui qui a écrit la recette ait prévu un minimum la gestion ces plateformes, si ce n'est pas le cas, tu risques d'avoir quelques bugs et de devoir patcher la recette.

Mais d'un autre côté, je n'ai pas l'impression que l'on ait à modifier le makefile bien souvent, sinon pour ajouter une dépendance, ce qui prend trois secondes.

Sauf quand on l'écrit pour la première fois. Et tu as beaucoup de chances en cherchant sur le net de tomber sur des Makefiles bogués, et donc d'avoir à modifier autre chose que juste une dépendance.

Sauf que autotools est beaucoup trop Linux only.

Alors là c’est n’importe quoi.

Je ne suis pas d'accord. Autotools sous Windows, ça lance tellement de process que ça rajoute un overhead énorme par rapport à ce que cela fait. Dans le lien donné plus haut sur la migration de GStreamer à Meson, le développeur explique qu'ils ont gagné énormément de temps sur le build Windows (× 10) par rapport à autotools, sans doute pour cette raison là. Bien sûr, sur des gros projets le temps de build sera largement dominé par le compilateur, mais sur des projets plus petits, la lenteur du build system peut avoir un impact non négligeable.

Ensuite autotools c'est aussi différentes versions de autobidule et autotruc à installer en parallèle parce que non compatibles. Alors oui tu peux faire de la cross-compilation de Linux vers Windows, mais dans ce cas il ne faut s'offusquer qu'on dise que c'est trop "Linux only" (par opposition à Windows, pas par rapport aux autres UNIX).

Ensuite, tu ne pourras à ma connaissance pas builder avec le compilateur de Visual Studio si tu es sous Windows. Si on te donne des bibliothèques proprios pour lesquelles on ne te donne que les binaires et que tu dois t'intégrer avec, tu fais quoi ? Idem pour les symboles de debug différents entre gcc et Visual Studio qui font que tu peux avoir envie d'utiliser un compilateur unique pour être capable de déboguer le bouzin.

Enfin, autotools ne fonctionne qu'avec Make, avec tous les reproches qu'on peut faire sur Make, là où CMake et Meson sont compatibles ninja. Ninja a pour objectif de fournir un format très simple et hautement parallélisable, parce que ce sont les besoins de notre l'époque. De son côté, GNU Make va par défaut chercher des fichiers de logiciels de version obsolètes RCS et SCCS parce qu'il a été développé à une autre époque et qu'il a forcément du "bagage". "bagage" qui n'a pas été jeté parce que la compatibilité à tout prix empêche aussi l'évolution. GNU Make est un très bon logiciel, et tout à fait honorable, mais plus forcément une solution optimale au problème.

CMake et Meson (et bien d'autres sans doute), ça produit des projets pour Visual Studio et Xcode, et ça marche aussi sous Linux. Autotools n'a à ma connaissance pas apporté de solutions à ces problèmes (mais je serais ravi qu'on me pointe des solutions qui seraient passées sous mon radar).

Pour finir, voilà deux liens de l'auteur de Meson sur les reproches qu'il a fait à autotools et CMake, ainsi que des anti patterns Meson (parce qu'aucun outil n'est parfais, les soucis sont juste différents):

• http://voices.canonical.com/jussi.pakkanen/2011/09/13/autotools/
• http://voices.canonical.com/jussi.pakkanen/2013/03/26/a-list-of-common-cmake-antipatterns/
• http://nibblestew.blogspot.com/2017/05/a-list-of-common-meson-antipatterns.html