Gil Cot ✔ a écrit 6264 commentaires

Ils sont tous relativement courts les codes proposés…

Alors, si je comprends bien, tu gagnes 0.08s chez toi en remplaçant

if (!isset($words[$word])) {
    $words[$word] = 0;
}
$words[$word]++;

par (moins propre pour ne pas dire carrément crade)

@$words[$word]++;

? Est-ce isset ou l'affectation qui plombe les performance ?
Parce-que raccourcir pour raccourci abouti au genre de trucs qui font la mauvaise presse de PHP (qui pourtant, malgré la performance qui te déplait, laisse Python sur le carreau)
En tout cas je n'aurais pas viré ce passage, et si c'est juste pour faire moins de ligne

isset($words[$word]) ?: $words[$word]= 0;
$words[$word]++;

ou encore (après c'est une question de goût)

!isset($words[$word]) && $words[$word] = 0;
$words[$word]++;

Et une réduction de 57.9% (de 0.19s à 0.11s) n'est pas vraiment 100% comme tu dis

de toutes petites modifs comme celle que j'ai faites peuvent faire passer le résultat presque du simple au double (ou l'inverse)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

L'un n'a jamais empêché l'autre ; il y a eu plein d'entreprise qui ont utilisé les ordinateurs domestiques à des fins professionnelles. (je ne parle pas que de l'époque Atari, puisqu'on a vu plus tard en entreprise plein de fenêtre xp puis vista qui n'étaient pas estampillées pro s'utiliser comme poste de travail pro… et récemment dans un grand groupe j'ai vu utiliser la version express de sql-server en production)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Pourquoi migrer ? C'est toujours bien d'avoir le choix, et des choix libres.
Et puis les deux ne se se recoupent pas vraiment en terme de fonctionnalités ; on peut trouver un certain nombre de cas où l'un est mieux ou l'autre défaillant, et des cas où utiliser l'un est plus simple que d'utiliser l'autre.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Je viens d'aller voir la page des performances de frawk et j'ai adoré son disclaimer :

The abundance of such claims notwithstanding, I've found it is very hard to precisely state the degree to which an entire programming language implementation is or is not efficient. I have no doubt that there are programs in frawk that are slower than equivalent programs in Rust or C, or even mawk or gawk (indeed, see the "Group By Key" benchmark). In some cases this will be due to bugs or differences in the quality of the language implementations, in others it will be due to bugs or differences in the quality of the programs themselves, while in still others it may be due to the fact that in some nontrivial sense one language allows you to write the program more efficiently than another.

I've found that it can be very hard to distinguish between these three categories of explanations when doing performance analysis. As such, I encourage everyone reading this document to draw at most modest conclusions based on the numbers below. What I do hope this document demonstrates are some of frawk's strengths when it comes to some common scripting tasks on CSV and TSV data

AWK est un DSL prévu pour les fichiers DSV simples de l'époque (le fichier /etc/passwd en est un exemple) alors qu'aujourd'hui le CSV qui s'utilise de plus en plus en plus est loin de cette simplicité+régularité (non seulement, contrairement au sigle, ce n'est pas la virgule qui est forcément utilisée, mais les différents séparateurs peuvent se retrouver dans les champs qui doivent en plus être entourés etc.) À l'inverse, frawk veut adresser d'entrée cette complexité déjà discutée ici. Il est donc bien vu d'avoir xsv et tsv-tools dans le comparatif puisque ceux-ci sont sur le créneau visé. Ceci dit, le CSV utilisé pour ses tests n'est pas des plus complexes, mais nécessite plus de taf (comme je l'ai mentionné dans un autre commentaire, ce sont dans ces cas que xsv et tsv-utils peuvent sembler intéressant, pour ne pas devoir investir plus de temps et d'énergie en développement supplémentaire)

Benchmarks for the TREE_GRM_ESTN dataset are not run on CSV input with mawk or gawk, as it contains quoted fields and these utilities do not handle CSV escaping out of the box. We still run them on the TSV versions of these files using \t as a field separator.

Les awk présentés sont écrits sans hack et donc pourront être utilisés avec d'autres implémentations d'une part, et les performances observées avec les implémentations et versions utilisées n'exploitent pas leurs spécificité (gawk par exemple a quelques ajouts qui font que la réécriture peut donner des résultats plus bluffants mais cela ne sera malheureusement pas portable, contrairement à la forme POSIX) Il y a quand même de petits détails auxquels il faut faire gaffe, comme il est dit

Note: the +0s ensure we are always performing a numeric comparison. In Awk this is unnecessary if all instances of column $4 and column $5 are numeric; in frawk this is required: max will perform a lexicographic comparison instead of a numeric one without the explicit conversion.

La plus grande surprise, pour moi, fut pour le petit test en Python et en Rust

frawk is a good deal faster than the other options, particularly on the newer hardware, or when run in parallel. Now, the Rust script could of course be optimized substantially (frawk is implemented in Rust, after all). But if you need to do exploratory, ad-hoc computations like this, a frawk script is probably going to be faster than the first few Rust programs you write.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

J'aurais dit à première vue que la majorité des utilitaires sont peu utiles (d'ailleurs la documentation de synthèse —le lisez-moi— indique bien ça et là que les utilitaires traditionnels font la même choses) si ce n'est leur gestion des entêtes en plus… Je n'ai pas souvent ce cas, mais quand ça arrive, c'est sûr que j'aurais adoré avoir cette trousse en plus (merci donc pour la découverte …renversante.)

Les trois ou quatre plus utiles de prime abord, àmha, sont :

• tsv-filter bien que j'utilise awk pour la plupart des exemples données (quand on procède par position… avec les entêtes il y a un réel plus ici car ça devient plus complexe-et-chiant de l'autre côté mais reste faisable) et ai expérimenté quelque autre script à l'occasion ;
• tsv-summarize là aussi on peut sortir awk ou un autre langage de scripting comme PERL/PHP/Python/Ruby/etc, voire de passer par R ou du SQL, mais je pense que pour les data-scientists ou des staticians qui ont souvent ce genre de besoin sur ce genre de fichiers c'est du temps de scriptage en moins ;
• dans le même esprit, tsv-sample peut être intéressant pour toute personne amenée à manipuler des échantillons d'un gros fichier (des milliers de lignes) et dans ce cas aurait eu besoin de passer par un script maison vite fait ou un outil pivot ;
• csv2tsv est clairement un truc que j'aurais aimer avoir dans de nombreux cas où on a des exports CSV dégueulasses (avec des champs qui ne sont pas systématiquement "quoté"s et le pire quand on a des champs avec le délimiteur ou s'étendant sur plusieurs lignes) depuis divers outils

En tout cas belle découverte.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

rosté ?

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

N'est-ce pas juste que les personnes qui font les traductions aient fini par s'y perdre ?

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Dans le principe de fonctionnement arborescent, tu as toujours une branche, fut-ce le tronc. La remarque initiale n'allait pas contre ce principe (donc ne demandait pas de créer un dépôt sans branche) ; mais indiquait de ne pas donner de nom par défaut (obligeant donc à en choisir un soi-même et du coup on ne serait pas retrouvé avec un standard que certains pestent à changer.) Typiquement, tu créerais ton dépôt avec une branche principale/courante/maîtresse/ce-qui-te-convient et non master. (ceci dit, c'est toujours possible d'avoir un autre nom pour la branche référence, mais c'est lourd en manipulations avec les forges qui protègent d'office le mestre…)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Merci ; je n'aurais pas mieux dit. Et du coup, je ne vois toujours pas de quelles improvisations il parle mais bon, c'est souvent le cas de ce genre de procès de langages qu'on ne connait pas et qu'on veut absolument comparer dogmatiquement à quelque truc à la mode.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

J'ai oublié en passant, dans la seconde liste :

• mdview écrit en Go et dispo sous forme de snap.
• marked écrit en NodeJS
• GFMS s'appuie sur marked
• vmd en JS aussi et s'intègre à Atom
• showndown en NodeJS

Après, pour cette approche, on peut juste installer la bibliothèque prévue pour son langage de scripting favori et pondre les deux ou trois lignes de script qui vont bien pour générer le fichier HTML

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Oh que si, ils comprennent que tout le monde a forcément un portable et que tu es juste un client chiant :-(

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Il me bsemle que bientôt feu Brakets aussi

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Il manque des noms bien connu (enfin j'aurais cru) comme :

• Remarkable
• ghostwriter

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Bah… t'as commencé en écrivant

Je recherche un éditeur de markdown sous linux (Debian).

Du coup, il y a eu plein de recommandations d'outils éditant et prévisualisant directement (live), même si tu poursuis par :

J'ai déjà des éditeur pour modifier les fichiers mais je n'ai pas de visualiseur (je ne souhaite pas forcément que le visualiseur sois l'éditeur).

Si vous connaissais un bon visualiseur pour faire du markdown j'aimerai bien.

Je me mets donc en porte-à-faux par rapport aux autres réponses en proposant :

• mdless écrit en Ruby
• mdr écrit en NodeJS
• mad écrit en NodeJS
• Mdv un POC en Python
• lowdown écrit en C
• glow écrit en Go (je viens de le découvrir et il remplace actuellement Marked 2 propriétaire et fermé)

Les propositions précédentes font du rendu en console/terminal, comme pour les pages de man. Il y en a d'autres comme ça qui font plutôt du rendu en page web :

• pandoc qu'on ne présente plus (faire par exemple pandoc -s index.md | lynx -stdin ou enregistrer dans un fichier)
• le script de Daring en PERL (faire par exemple Markdown.pl index.md > index.html puis ouvrir ce dernier dans son navigateur)
• le vieux et non maintenu turbo-markdown en Python, sur le port 8888
• le vieux et non maintenu markdown-live en Python, par défaut sur le port 8000 mais configurable
• le plus jeune grip en Python, par défaut sur le port 6419 mais configurable
• etc.

Je ne connais pas les applications purement X sans passer par le navigateur car travaillant essentiellement en CLI. Mais j'ai cru comprendre que Okular a un backend pour ce besoin

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Je ne connaissais ps xsv ; à comparer avec csvkit et csvtool

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

crotte alors, pardon voulais dire flute

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

oui et non… l'esclavage n'a peut-être rien à voir avec les religions (ce n'est pas prouvé) mais les traites négrières si (historiquement prouvé)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

idem, le diff de base ; et parfois vimdiff

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

C'est sympa de passer souvent…
Et quand tu passes, ton tableau de bord te dit ce qu'il est advenu de tes précédentes activités.

C'est sympa de pas se faire spamer…
Même volontairement.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

…de ce qu'est le libre et son esprit, et pourquoi ça marche mieux.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

et donc que chacun d'eux te vaut doublement…

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

en même temps, il écrit bien : j'ai compris son code sans effort et à la première lecture. c'est peut-être pas pour rien que j'ai toujours bien aimé ce langage : je dois être mal câblé :-/

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Les créateurs du langage s'y connaissent bien en compilateurs et en besoin de programmation système ; de plus ils avaient un cahier des charges bien précis, et le résultat a largement répondu aux attentes (au point de devenir le succès actuel) La comparaison actuelle est fort injuste car les auteurs et les objectifs de l'autre langage sont fort loin de celui-ci ; leur positionnement commercial non plus. Tu fais donc, pour moi, un parallèle qui n'a pas lieu d'être si ce n'est un fantasme.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Exactement : le langage n'a pas été conçu pour être fun, mais pensé dès le départ pour le travail en équipe (d'où le fait qu'on ne peut pas organiser son code comme on veut) et pour être pris en main très rapidement (sans retomber dans les travers du C) tout en étant performant.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

où ça un ascenseur horizontal ?

“It is seldom that liberty of any kind is lost all at once.” ― David Hume