liberforce a écrit 4744 commentaires

Ça pourrait être utile pour ceux qui viennent acheter la nouvelle version de leur iBidule quand ils voient les prix.

C'est surtout qu'on écrit "Spider-Man", en deux mots avec un tiret. Stan Lee a délibérément utilisé un tiret pour éviter la confusion avec Superman.

Ah, vu ton historique, c'est effectivment tapé sur le ton de l'humour. Ah ah. Sinon, ouvrir un blog, c'est bien aussi. Parce qu'une keynote Apple c'est pas un événement, et parce qu'au fond, on s'en bat un peu les steaks.

Entre le sujet, le ton et les fautes, j'hésite...

Et sinon tu vas à chaque keynote nous faire un journal avant et après ? L'hibernation c'est bien aussi.

Salut, c'est quoi comme robot qui embarque du Rust, si c'est pas trop indiscret ?

• DiskUsage pour savoir où part mon espace disque
• AntennaPod pour gérer mes podcasts
• OsmAnd pour remplacer Google Maps
• DAVDroid pour synchroniser mes contacts et todo-list avec mon compte Nextcloud sur l'instance framadrive
• Nextcloud pour un accès rapide à mes fichiers
• Tusky pour faire des pouets sur Mastodon
• MTG Familiar pour faire des recherches de cartes Magic The Gathering
• Giggity pour les plannings de conférences sur le libre
• Document Viewer comme visionneuse de documents

Le monde a changé. La sécurité informatique prend de plus en plus d'importance. La semaine dernière au JT de France 2 on parlait de sécurité informatique dans les appareils médicaux type pacemakers, d'hôpitaux piratés avec demande rançon pour ne pas dérégler les pompes à morphine, etc. On parle de multiplication d'objets connectés, on ne peut plus fier aux données qui rentrent dans un système (par exemple pour un parser), les vecteurs d'attaque se multiplient, et les failles de sécurité avec.

Ensuite, le matériel a changé: tu as plus de coeurs, il faut réussir à paralléliser les traitements pour tirer le maximum de performances du matériel utilisé, tout cela sans provoquer de fuite mémoire, de deadlock, d'écrasement de tampon, etc. En C tu peux tout faire, mais tu peux aussi coder comme un goret, et ignorer les valeurs de retour.

Alors bien sûr, tu peux faire du fuzzing, de l'analyse statique de code, passer du valgrind, du ASAN sur ton code C... Mais ça prend du temps, des ressources (que les projets libres souvent n'ont pas). Alors si un langage te promet d'attraper les erreurs les plus communes à la compilation plutôt qu'à l'exécution ou pendant d'hypothétiques phases de check que tous les développeurs sont loin de mettre en place, bin personnellement je pense que C a du soucis à se faire. Certes, on fera encore du C pendant longtemps, mais se dire que parce qu'il est établi, il ne craint rien, c'est se bercer d'illusions à mon avis.

On pourrait dire que ce qui va freiner, c'est la migration, parce qu'il faut tout réécrire d'un coup, mais même pas. Librsvg est migrée de C à Rust petit bout par petit bout depuis quelques mois. Une partie est en C, une autre en Rust, pas besoin de tout réécrire en une seule fois. Je lisais encore ce matin un article d'un gars qui se met à écrire mtpng, un encodeur png plus parallèle. Entre C, C++ et Rust... Bin il a choisi Rust.

Bref, que ce soit Rust, go ou autre chose, il y a un vrai besoin d'un langage qui permette de relever les défis des décennies à venir. Le C te permet de tout faire, y des atrocités, volontaires ou pas. Et je pense qu'il y a pas mal de gens qui attendent la relève.

Ce n'est peut être pas ça qui va sauver la planète, mais je pense au contraire que tout effort est bon à prendre. L'éteindre 14h30 par jour, c'est quasiment 60% d'économie sur la comsommation totale du système (Pi + écran).

Un Pi en veille consomme entre 0,1W et 0,31W → entre 1,45Wh et 4,5Wh en 14h30 → entre 529Wh à 1640Wh en une année (14h30 par jour).

Titre de l'image

Un écran en veille consomme d'après toi entre 0,3W et 0,7W → entre 4,35Wh et 10,15Wh en 14h30 → entre 1588Wh et 3705Wh en une année (14h30 par jour).

On peut donc économiser entre 2117Wh et 5345Wh en un an. Certes ça représente environ 80 centimes d'euros, certes c'est négligeable par rapport à ce qu'on peut gagner en économisant sur d'autres équipements, mais ça représente entre 1h et 2h30 de consommation d'un radiateur électrique 2000W, réglé à fond et inutilement. Donc je pense que la démarche n'est pas inutile non plus. Ce sont les petites rivières qui font les gros fleuves...

Oui, j'ai pas pu résister sur le moment, mais je te rassure, après je me suis senti un peu sale.

Est-ce qu'un petit marquis qui passerait par là aurait un commentaire à faire sur cette suite à
https://linuxfr.org/users/oulala/liens/winscp-l-outil-ideal-pour-remplacer-vim ?

Bon, je sais qu'on est pas vendredi, mais je prends un peu d'avance.

Une tribune surprenante de Pascal Nègre dans le Monde hier:

Pascal Nègre sur wikipédia:

En mars 2017, le groupe M6 et Pascal Nègre annoncent conjointement un partenariat entre M6 Interactions, filiale du groupe, et le label musical 6&7 créé par Pascal Nègre en avril 2016.

Dingue, quand il était chez les gros (Universal Music) pendant près de 20 ans, il défendait le droit d'auteur. Étrangement maintenant qu'il est à son compte, ça l'emmerde sans doute un peu plus.

Et ssh. Mais il y a des gens qui le trouvent aussi utile sur desktop, que ce soit pour la productivité comme pour le recul du syndrome du canal carpien. Tu peux trouver vim globalement inutile, ça ne veut pas dire qu'il l'est. En revanche, il demande très clairement un investissement.

Argumentum ad antiquitatem

Pfff, bien sûr que Jésus marchait sur l'eau, c'est connu depuis longtemps !

Ah, j'oubliais dans les commentaires le:

C’est juste inutile et stupide d’apprendre vi.

Euh, non.

Et pour la peine je colle quelques liens de ressources pour ceux qui sont aussi stupides que moi:

• https://www.youtube.com/watch?v=XA2WjJbmmoM
• http://vimcasts.org/

Une cheat sheet:

Titre de l'image

Et je conseille surtout la lecture de Practical Vim.

Effectivement, tu ne dis pas que ce sont des cons.

Nous avions surtout en commun d’avoir une profonde détestation pour la complexité inutile de l’éditeur vi, ainsi que pour ces enseignants sadiques qui se pensaient faire partie d’une élite de pacotille du fait de leur maîtrise des raccourcis de ce logiciel archaïque. Ce sentiment d’être au-dessus du lot qui animait les vieux chnoques du monde UNIX s’est aujourd’hui très largement répandu à de jeunes chnoques tyranniques qui aiment à imposer aux autres leur propre habitus numérique. Pour justifier de leur impéritie, ils nous expliquent alors que vim est plus ergonomique que vi , tout en passant des heures à faire leur Jacky Tuning en optimisant leur fichier .vimrc. Quel contre-sens historique !!!

Je dois faire partie de ces ignorants vu que je ne connaissais pas le mot impéritie. Au passage, je me suis vraiment mis à vim après des années d'utilisation très modeste, et j'en suis très content.

Au cas où certains d’entre vous l’auraient oublié, LINUX signifie Linux Is Not UniX.

Alors j'aimerais bien savoir d'où tu tiens ça... GNU's Not UNIX, ok, mais ce n'est pas la même origine pour Linux. L'explication la plus généralement donnée est plutôt "Linus's UNIX" (l'UNIX de Linus) et non Linux Is Not UniX.

Et oui, franchement, le texte est très premier degré, si tu as voulu être ironique, c'est plutôt raté.

>>> main = [(11, 'K'), (8, 'T'), (9, 'P'), (10, 'T'), (7, 'C')]
>>> b = sorted(main)
>>> b
[(7, 'C'), (8, 'T'), (9, 'P'), (10, 'T'), (11, 'K')]
>>> del b['C']
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
TypeError: list indices must be integers, not str

Lis les messages d'erreur, ils sont là te guider. Apprends aussi à décrire ton problème au lien de dire "ça ne marche pas". Bien souvent, mieux formuler ton problème te permettra de le comprendre et souvent de trouver la solution par toi même.

Bon, revenons à nos moutons. Tu as donc dû avoir ce message d'erreur:

TypeError: list indices must be integers, not str

Traduction:

Erreur de type: les index de listes doivent être des entiers, et pas des chaînes de caractères.

C'est parce que dans une liste, les éléments sont ordonnés et accessibles par indice (leur position dans la liste): indice → valeur. Tu peux donc accéder à b[0], mais pas à b['C'].

Exemple: effacer le 3ème élément d'une liste

>>> my_list = [1, 2, 3, 4]
>>> my_list
[1, 2, 3, 4]
>>> del my_list[2]
>>> my_list
[1, 2, 4]

Les indices commencent à 0, donc le 1 se trouve à l'indice 0, le 2 se trouve à l'indice 1, le 3 se trouve à l'indice 2, et le 4 se trouve à l'indice 3. En demandant d'effacer l'élément à l'indice 2 avec del my_list[2], tu supprimes donc la valeur 3 de la liste.

En revanche, dans un tableau associatif, les éléments ne sont pas ordonnés (l'ordre n'est pas conservé), et sont accessibles par une clé. La clé peut être du type que tu veux, et te permet d'accéder à la valeur associée: clé → valeur.

Exemple ici avec un tableau associatif utilisant une chaîne de caractères comme clé. Voici comment supprimer la valeur 'coeur' du tableau.

>>> couleur = {'C': 'coeur', 'K': 'carreau', 'T': 'trèfle', 'P': 'pique'}
>>> couleur
{'K': 'carreau', 'T': 'trèfle', 'C': 'coeur', 'P': 'pique'}
>>> del couleur['C']
>>> couleur
{'K': 'carreau', 'T': 'trèfle', 'P': 'pique'}

Revenons à ton problème. Ce que tu veux faire toi, c'est supprimer la couleur pour chaque carte de la main triée b. del b[0] ne fonctionnera pas, parce que b est une main, pas une carte. del b[0] supprimerait juste la première carte de la main triée.

Je te conseille aussi avant d'aller plus loin de lire des tutoriels python, parce tu ne maîtrises pas les types de base du langage (listes, chaînes, tuples tableaux associatifs, etc.), ce qui te limite forcément. Autre chose, si tu veux voir les opérations possibles sur un objet, fais utilise la commande help. help(b) ou help(list) (puisque b est de type list) te donnera la liste des méthodes de b.
https://docs.python.org/fr/3.5/tutorial/introduction.html

Une nouvelle fois, utilise les options de formattage de code quand tu postes, l'indentation est importante !!!

Bon je ré-explique, l'opérateur in renvoie un booléen (donc True ou False). Du coup ceci n'est pas du tout nécessaire:

if (b in a)==True:
 return 1
else :
 return 0

Tu peux remplacer tout ce bloc par:

return b in a

Bon, ensuite, il semble que tu appelles:

estQUINTE(['7 K', '8 T', '9 P', '10 T', '11 C'])

Donc quand tu es dans estQUINTE, ton paramètre main vaut ['7 K', '8 T', '9 P', '10 T', '11 C'].
Les crochets définissent une liste. Si je tape dans un interpréteur python:

>>> main = ['7 K', '8 T', '9 P', '10 T', '11 C']
>>> type(main)
<type 'list'>
>>> type(main[0])
<type 'str'>

Il me dit que ton objet main est bien une liste, et que le premier élément main[0] est une chaîne de caractères (string).

Si je continue:

>>> b = sorted(main)
>>> b
['10 T', '11 C', '7 K', '8 T', '9 P']

Voilà, tu lui as demandé de trier ta main, il l'a triée... Mais pas comme tu souhaites. Il a fait du tri de chaines de caractères (c'est ce que tu lui donnes). Du coup, 11 C vient avant 7 K parce il compare lettre par lettre, et que le 1 est avant 7. Il ne peut pas comprendre que c'est le nombre 11, puisque tu lui passes une chaîne et pas un nombre.

Maintenant si on séparait les deux information dans un tuple (valeur, couleur) comme j'avais proposé plus haut ? valeur est un entier, et couleur est un caractère parmi ['C', 'K', 'T', 'P'], comme tu fais actuellement.

Là je mets une main dans le désordre (sinon c'est pas drôle)

>>> main = [(11, 'K'), (8, 'T'), (9, 'P'), (10, 'T'), (7, 'C')]
>>> b = sorted(main)
>>> main
[(11, 'K'), (8, 'T'), (9, 'P'), (10, 'T'), (7, 'C')]
>>> b
[(7, 'C'), (8, 'T'), (9, 'P'), (10, 'T'), (11, 'K')]

Et voilà, la main a été triée d'après le premier champ du tuple: valeur. Maintenant ce qui va coincer c'est que tu ne peux pas comparer a et b directement. a ne contient que des valeurs, pas de couleurs. b contient valeurs et couleurs. Donc tu dois transformer b pour n'avoir que des valeurs aussi. Tu pourras ainsi comparer les deux objets en faisant ton b in a.

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.