Marotte ⛧ a écrit 8739 commentaires

Le proxy voit toutes les urls demandées pas les contenu, mais l'url va être écrite dans les logs du proxy !

Non. Pas avec HTTPS. Dans les logs on verra juste qu’une connexion SSL a été établi entre une adresse donnée et ton poste. On pourra relier cette adresse au nom de domaine, d’une part parce que c’est une information publique et d’autre part car ton poste, avant que ton navigateur affiche la page, aura déjà demandé de résoudre le nom de domaine machin.com au serveur DNS de ta boîte :) S’il y a un proxy pour la navigation il y a de forte chance que tu ne puisses pas utiliser les serveurs DNS publics de Google ou autre (et de toute façon c’est public…).

L’URL dans son ensemble est, elle, chiffrée.

Tout ceci étant dit, une autre chose est possible. C’est que le réseau sur lequel tu te trouves fasse du DPI en s’imposant comme intermédiaire (on parle de "man-in-the-middle") pour la connexion HTTPS, là on saura tout du contenu auquel tu accèdes. Dans une entreprise, où l’OS voire le navigateur est généralement imposé, c’est assez facile à mettre en place. Par contre c’est coûteux (mais au prix de la donnée de nos jours…), puisqu’il faut déchiffrer pour rechiffrer derrière.

Le fait d’utiliser Qwant c’est pas pour protéger ta vie privée quand tu accèdes à internet à partir de la connexion de quelqu’un d’autre… Le concept c’est de ne pas enregistrer et exploiter ensuite les données, pour eux, en les revendant ou d’une quelconque autre manière. Ce qui est, au contraire, la base du business de Google.

Désolé

C’est pas grave, pas la peine de demander ou exiger des excuses pour ça.

C’est une très bonne chose que les messages « restent », tels qu’ils ont été écrits. Je ne sais pas si tu te rends bien compte des manifestations de mauvaise foi auxquelles nous assisterions sur tel ou tel commentaire si ce n’était pas le cas :) Après… c’est peut-être moi qui voit le mal partout…

Quel est le contenu de liste_mail.txt ?

:)

Important de le rappeler !

Toujours mettre des guillemets autour des variables censé contenir une chaîne de caractère, même si celle-ci ne.doit.jamais.au.grand.jamais.avoir.despace… ça permet déjà pour commencer de les différencier visuellement des variables censées contenir des entiers.

Je suis pas fan de "déquoter" sciemment une chaîne pour la passer comme un tableau… je pense que c’est une mauvaise pratique… et vous ?

Le problème de cette approche, or le fait, comme le dit freem, de devoir parser le fichier deux fois (à la rigueur s’il n’y a pas trop de lignes ça peut aller), c’est surtout au niveau des expressions régulières que je sens venir le piège… Il faut que je détermine ma regex ainsi que sa complémentaire. Là je dois pouvoir encore le faire sans me gourrer, mais si la regex doit être rendue plus complexe, je vais pouvoir me retrouver avec des lignes dans les deux fichiers ou des lignes nulle part…

Je commence à m’en vouloir un peu de ne pas avoir pensé moi-même au bête mot-clé else… J’ai probablement pas une assez bonne maîtrise de awk (ou sed) pour les considérer à juste titre comme des langages de programmation complets.

Merci pour ton commentaire je connaissais pas cette commande donc +1 pour ça.

Ça doit être possible de s’en sortir avec diff aussi. C’est un peu con que tu te fasses moinsser parce que tu n’as pas pris le soin de préciser que ça ne répondait pas à ma demande (j’avais bien spécifié de si possible avoir à appeler un seul binaire)… Mais bon, tu connais le site il me semble :)

J’ai pas encore eu le temps de me remettre à travailler sur le script en question mais j’essaierai de faire un retour sur la solution choisie.

https://linuxfr.org/wiki/aide-edition

ça n'empêcherait pas le problème d'exister, dans avec d'autres nombres, mais c'est moins visible pour l'utilisateur.

C’est bien là un des gros avantages du calcul en virgule flottante : c’est « bête », du coup les erreurs sont (pré)visibles.

Merci c'est un bon argument pour justifier que Python pourrait utiliser Decimal au lieu de float par défaut pour les litéraux :)

Et bien justement, bien au contraire j’ai envie de dire… Pour les quelques pourcent du code qui nécessitent de la performance il s’agit très souvent de calcul « littéral » (puisque tu emploies ce terme…), précisément !

Donc si Python utilisait Fraction() ou Decimal() par défaut il faudrait sortir cython pour faire le moindre truc un peu calculatoire… Je crois que tu connais maintenant l’avis des utilisateurs du site sur le sujet !

Le code qui ne nécessite pas de bourriner, c’est notamment tout ce qui est interaction humain-machine. De manière générale, tout ce qui ne nécessite pas d’avoir des perfs de ouf doit plutôt privilégier la maintenabilité du code et son exploitabilité, ou que sais-je encore.

Enfin bon. Tu lâcheras rien je vois ça :) Maintenant, sachant que Perl6 répond à ton besoin tu devrais t’y mettre ! … À moins que… en fait, même toi… n’est absolument pas dérangé par les erreurs d’arrondi dues à l’utilisation des floats, et que c’est pas ce qui te fait choisir le langage que tu utilises ;)

Les claques elles devraient aller droit dans la chetron de celui qui dénigre un langage sans aucun argument, sans aucun lien pour étayer son assertion. Le premier lien que je google me trouve, date certes de 2010, et montre de bonnes performances pour Python par rapport à PHP ou Perl. Ruby mieux mais pas chut pas troller.

Tu voulais peut-être faire remarquer le simple fait qu’un langage interprété se fait enterrer par n’importe quel code issu d’une compilation ? Mais dans tous les cas, vraiment, je te dis ça pour toi et ton karma, il va falloir que tu argumentes un minimum quand tu sors des propos pareils.

Pour les parties d’un programme réclamant réellement du CPU, comme de gros calculs de brute en virgule flottante sur 256 bits, Python, et en particulier Cython permet, en quelque sorte, de « compiler du Python ». Donc… bon… Tu as perdu une occasion de te taire, à mon humble avis.

Pour 99,9% du code sur cette planète (chiffre de mon doigt mouillé), qu’une boucle s’exécute en 1ms au lieu de 10ms n’est absolument pas un critère qui pèse dans le choix du langage…

Le langage le plus lent de la création. Plus lent que ça tu pars à reculons.

J’aime bien la formule ! C’est le seul truc agréable de ton commentaire.

Et ça voudrait dire quoi ?

Que le service en question ne repose que sur des logiciels libres (n’ayant pas été modifiés localement), que tous les détails de l’infra sont publics et libres : infrastructure matérielle, scripts techniques, mais aussi infrastructure humaine : combien d’employés dans l’entreprise qui fournit le service ? CA ?

Note que ce sont de vraies questions. Pour moi « service libre/basé sur du LL » ne veut rien dire (car l’entreprise qui fournit le service peut bien te raconter ce qu’elle veut…), mais je suis prêt à changer d’avis si on me donne une définition qui puisse être acceptée par le plus grand monde.

Je crois que c’est Faya qui a fait le commentaire le plus pertinent : Perl6 fonctionne comme tu penses qu’un langage généraliste devrait fonctionner au 21e siècle : il utilise des fractions par défaut. Il te faut donc abandonner Python pour te mettre à Perl 6, tu ne peux pas continuer à utiliser un langage pré-historique qui utilise des floats pour tout calcul sur des décimaux quand même ?!

et tant pis pour les soustractions à 1 chiffre après la virgule, du moment qu'on peut calculer une fonction de Bessel ou une fonction gamma d'Euler rapidement

Bah oui. OSEF des soustractions à 1 chiffre après la virgule. On privilégie ce qui est utile.

nous démontrons facilement que Python a décidé de privilégier la rapidité des calculs des fonctions de Bessel (ou des fonctions gamma d'Euler) plutôt que la justesse des soustractions à un chiffre après la virgule

Python et beaucoup d’autres… Je ne savais pas pour Perl6, l’avenir nous dira si les autres langages finissent par adopter ce comportement déviant original.

Je pense que c’est ce que je vais faire (il faut aussi que je regarde sed, comme a suggéré Cyril).

J’avais pensé à un truc de ce genre mais en utilisant deux motifs distincts, j’avais pas pensé à utiliser "else"…

Encore un grand merci à tous. Vous assurez.

Ah enfin ! tu te ranges du côté de la raison. C’est pas trop tôt ! ;)

Pourquoi cette « fausse » barre de progression ?

Ce ne serait pas plus pratique de ne pas utiliser le '\r', pour avoir tous les messages d’info ou d’erreur affichés, les uns en dessous des autres ?

Tu peux aussi afficher les messages d’erreur sur la sortie d’erreur (en ajoutant '>&2' à la fin de la ligne) et laisser seulement les infos sur la sortie standard. Si tu ne veux pas avoir deux flux de log, tu peux au moins préfixer différemment messages d’erreurs et d’information.

Pas l’occasion de tester mais le script a l’air bien.

mysql ou mysqldump permet de sortir le resultat en csv

TSV plutôt si je ne dis pas de bêtise. Je l’ai utilisé hier, mais sur une version de MySQL assez datée. Cela dit je ne pense pas que ça ait pu changer récemment, parce que prendre une tabulation (qui est l’un des caractères de séparation par défaut des arguments en shell) plutôt qu’un point virgule (un caractère de ponctuation banal) ça évite un tas de problèmes. Il y a peut-être une option maintenant mais sinon il faut passer par tr si tu veux du CSV à partir d’une requête MySQL. En shell bien sûr, sinon les différents outils (myphpadmin, MySQL Workbench, …) qui permettent de faire des exports proposent le CSV.

le resultat en csv ou dans un fichier .sql qui sera reinnjectable pour recreer la base de données

Attention : ça ne fait pas du tout la même chose. Dans le deuxième cas, un export SQL, tu peux effectivement recréer ta base en exécutant simplement ce fichier. Par contre dans le premier cas, un export csv/tsv, déjà il s’agit d’un fichier par table, pas de la base dans son ensemble, et pour pouvoir exploiter ces fichiers, les importer, il faudra que tu aies recréé au préalable l’ensemble des tables, et bien à l’identique si tu veux pas que ça te pète potentiellement à la gueule six mois plus tard, à cause d’une légère différence qui n’aura pas empêché l’import mais fout le souk quand même…

La question d’OP est tellement mal posée que c’est pas simple d’essayer de se mettre au même niveau, bravo à toi, mais j’ai trouvé que tu allais un peu vite en raccourcis. C’est sûrement ce que tu voulais dire mais dans ce cas c’est juste assez mal écrit (àmha).

Clair et limpide. Mais juste pour pinailler :

Le contenu de la commande est utilisé comme entrée de la commande2

Je pense qu’il vaut mieux dire « Le résultat/la sortie standard de command est utilisé comme entrée (standard elle aussi…) de command2

Pour moi, le « contenu d’une commande » c’est la ligne de commande elle-même.

Si dans le prochain Python v4, v5 ou v12 on peut écrire "2-0 - 1.8 - 0.2 == 0.0 => True", tu penseras que ça va casser de la compatiblité ? Voire que ce sera une régression ?

Ça cassera des programmes, mal écrits certes, mais ça cassera…

Il me semble que PHP a bien joué à changer le comportement de ses opérateurs d’égalité de version en version et les gens étaient pas très contents…

Une régression ? Une belle connerie surtout ! On a expliqué en long et en large pourquoi le comportement actuel était mieux… J’espère que maintenant ça va mieux pour toi et tes interrogations.

Oui mais au moins ce sera juste avec des pb de CE2, contrairement à la situation actuelle ou c'est faux pour les pb de CE2 et les pb supérieurs.

Python n’est pas fait pour apprendre les maths aux CE2. Pour les problèmes supérieurs ce n’est pas « faux » mathématiquement, c’est au contraire mathématiquement exact en virgule flottante…

Le fait que tu ne comprennes pas pourquoi le fait que la grande majorité des langages, à commencer par ceux qui se réclament généralistes, utilisent la virgule flottante de manière stricte est assez inquiétant, il faut bien le dire. C’est bien parce que ça marche mieux comme ça (le résultat final est juste dans la précision demandée, et on est sûr que les « erreurs » d’arrondi ont eu lieu, donc sûr de la précision…) que l’on procède ainsi.

Et pour finir, sur Python et la didactique, ce résultat, qui montre « l’erreur » d‘arrondi, peut aussi être vu comme un bon moyen d’aborder cette notion en mathématiques. L’humain aussi, quand il calcule avec sa petite tête et son stylo, à part des trucs simples comme ton exemple de départ, il va faire des arrondis.

Ah si, bc fait mieux, c'est un fait.

Tu peux utiliser awk, il donne -0 :)

$ echo | awk '{printf "%f\n",(2.0 - 1.8 - 0.2)}'
-0.000000

(si quelqu’un sait comment éviter ce pipe je prends)

Si c’était une question dans un contrôle portant sur la notion de virgule flottante tu aurais bien eu zéro (exactement) :)

Tu utilises un outil qui calcule en virgule flottante, un langage de programmation, Python, pour faire un calcul qui se fait de tête, et le résultat qu’il te donne te chagrine, j’ai bien résumé ?

Nous c’est le pourquoi de cette critique que nous ne comprenons pas. Un ordinateur ne peut pas représenter un ensemble infini avec sa mémoire finie. Pour les entiers, augmenter la mémoire occupée par chaque nombre « à la demande » c’est encore pas trop compliqué. Pour les décimaux, le faire « comme dans la réalité » est beaucoup plus complexe (et coûteux bien entendu), le calcul en virgule flottante est une quasi-obligation pour obtenir des résultats, si on veut plus de précision on augmente simplement l’espace mémoire de chaque nombre, ça reste « faux »… l’ordinateur n’a pas trop le choix. On peut parler d’IA tant qu’on veut, un ordinateur s’apparente à un boulier…

Tu sais tout ça. Donc reconnais que ta remarque est idiote et passe à autre chose, ce sera ma suggestion.

Sauf erreur de ma part .NEt core est open source

Mais pas SQL Server, et à priori il faut Visual Studio (tout aussi non libre) pour compiler le code de .NET core :

Pour générer le code, vous devez disposer d'une installation de Visual Studio 2013.

Ce n’est pas tant le côté non-libre de la solution qui me fait rire mais surtout le fait de sortir la grosse artillerie SQL Server pour une application dont le modèle de données doit pas être hyper-complexe…

2.0 - 1.8 - 0.2 => dire à l'ordinateur de faire une soustraction => il se vautre (puisque le résultat est différent de zéro, c'est lui qui me le dit)

Pour la énième fois : Non ! Tu demande à Python 3 de faire une soustraction. L’outil adapté pour faire ce genre de calcul en shell Unix c’est bc (ou encore dc), tu noteras que les deux donnent bien 0 comme résultat de la soustraction que tu as donnée.

rm -rf /* => dire à l'ordinateur d'effacer tout ce qu'il y a sous / => il le fait

Non plus. Depuis quelques années, toutes les bonnes distributions on un mécanisme en place pour demander une confirmation exceptionnelle pour exécuter cette commande :)

aujourd'hui c'est moi qui sert de défouloir

Tu fais surtout perdre du temps à tout le monde à troller comme un goret.

Oui acceptons que tous que "2.0 - 1.8 - 0.2 != 0.0" et pour ceux qui sont pas d'accords : RTFM.

Comme l’a dit Zenitram, il y a des outils pour faire du calcul formel. Je ne connais pas trop mais je pense que des logiciels/langages comme R ou Matlab permette de faire ça. Mais oui, définitivement, en informatique '1.8' représente généralement un nombre en virgule flottante, donc "2.0 - 1.8 - 0.2 != 0.0" (si on veut… car on a plutôt tendance à considérer que 5.511…e-17 égale zéro… en virgule flottante…)

C’est comme le fait qu’en informatique, contrairement à toute les autres matières, un kilobyte ne vaut pas mille bytes. Je suis au courant pour la norme, récente, de 1kB = 1000B et 1kiB = 1024B, mais le premier informaticien qui utilise la base 10 pour ça je lui mets deux baffes !

pas de la SSII bien au contraire.

C’est quoi le contraire d’une SSII ? Une société qui ne rend pas service à l’informatique ?