steph1978 a écrit 3405 commentaires

Ok, mea culpa, quand on lit le contenu, ça dit bien ce que tu dis.
N'empêche je trouve la démarche et la forme bizarre.
Monter un blog dédié pour faire deux articles sur ce même sujet avec des titres pas du tout explicite…

Mais en y réfléchissant un peu, je peux comprendre. Le logiciel incriminé fait lui même une bonne propagande sur le web et est d'ailleurs quelques fois dénoncé. Il fallait donc peut être allumer un contre feu. Mais il est à mon avis pas suffisamment percutant.

J'ai l'impression que ça fait partie d'un tout.

https://github.com/indiv0/aoc-fastest

Les 49 problèmes en moins de 1ms, c'est-à-dire en moins de un millions de nanosecondes.

Et le blog : domaine créé il y a un mois seulement. Aucun détail sur l'auteur. Un domaine ovh parce que pas cher. Seulement deux articles, tous sur le même sujet.

Ça pue.

Je fais pas mal de lineageos mais pour mon smartphone actuel, le support est expérimental ; je n'ai pas sauté le pas.

Simplement, je n'ai pas associé de compte google. Puis j'ai désactivé toutes les applications google, samsung et autres.

Ensuite, installation de FDroid.

Puis:

• mail : K9mail
• navigation : OSMAND
• météo : cirrus
• youtube : newpipe
• playstore : aurorastore
• launcher : kiss launcher
• navigateur : firefox
• clavier : simple keyboard puis futo
• chat : element
• vidéo : VLC, off course
• TOTP : Aegis
• news : Feeder
• calendar/contacts : DAVx5 pointant sur un nextcloud
• et plein d'autres petites perles FOSS

Depuis que lemaire a décrété qu'en France on ne savait pas faire de Cloud, les inepties se multiplient. Heureusement que certains ont veillé au grain sur ce dossier et tant pis pour nos données de santé.

C'est une tautologie.

Mes temps n'ont rien de fantaisistes.

Je n'en doute pas, j'ai vu des temps comparable en Rust et en Zig.

Mais comme tu dis il faut mesurer la même chose.

Je propose cinq façons d'aborder le sujet en concluant qu'il n'y a pas vraiment position tranchée.

Toi tu dis :

Plus sérieusement, un langage de scriptage est un langage de programmation interprété…

Et c'est moi qui suis catégorique ? La bonne rigolade.

L’article WP aussi est à mourir de rire. Il part d'une définition péremptoire, la même que toi et finit par toute une liste d’exemples avec autant d'exception.

Alors, Python, langage de script ou pas langage de script ? Lua ? JavaScript ?

très bonne solution aux déploiements complexes, distribués, et avec un fort besoin de changement de mise à l’échelle rapide

Je suis d'accord mais j'ajouterai que Docker marche aussi très bien à petite échelle.

J'ai en prod 3 serveurs et 73 containers pour environ 25 services ; pas de gestion de cluster, tout à la main avec docker compose.

Docker apporte beaucoup à cette échelle :

• builder et tester sur le laptop et être à peu près sûr que ça fonctionne pareil en prod.
• capturer la connaissance du fonctionnement du service dans le repo de source
• isolation des services ; si un service se fait péter, il y a des chances que l'hôte n'y passe pas
• pas de gestion des dépendances logicielles en prod ; tout a été réglé en amont
• facile de trouver des images toutes prêtes
• gestion des dépendances de services, des volumes de stockage, du réseau
• léger ; je n'observe pas de charge lié à docker lui-même

La frontière entre langage de script et langage de programmation est floue et elle n'est clairement pas dans la dichotomie interprété vs compilé.

C peut être interprété, python peut être compilé ; que dire des langages qui ont une implémentation à base de bytecode (java, Csharp, erlang), de jit (javascript), qui sont transpilés (elm) ?

Est ce qu'un langage de script est un langage qui peut être embarqué dans un langage de programmation ?
Lua est un langage de script alors. Python … pas si facile que ça à embarquer.

Est ce qu'un langage de script est un langage syntaxiquement plus léger et avec du sucre syntaxique ? Alors python serait alors bien placé dans cette catégorie, C++ très loin.

Est ce qu'un langage de script est un langage qui permet d'interagir facilement avec le système : spawn de process, capture de l'output, pipes ? C'est Bash. Et dans ce cas Python est mal placé.

Si ce n'est pas une question de langage, cela peut être une question d'usage. Scripter, c'est plus court, voire jetable. Programmer c'est plus élaboré et long terme. Mais à nouveau la frontière va être floue.

Basé sur tous ces critères, en fonction de leur évaluation et de leur pondération, il me semble bien difficile d'être aussi catégorique et l'article que tu cites galère bien pour (se) convaincre…

problème : je veux exécuter un script python dans le répertoire courant.

avec un virtual env

setup

python3 -m venv .venv
. .venv/bin/activate
pip install -r requirements.txt

puis autant de fois que nécessaire

nano mon_script.py
python mon_script.py mon_input > mon_output

avec docker

1. écrire le Dockerfile
   • from python
   • copy requirements.txt mon_script.py .
   • pip install -r requirements.xtx
   • CMD "python mon_script.py mon_input > mon_output"
2. builder l'image qui dl la moitié d'internet
3. lancer le container avec comme point de montage mon répertoire courant (en supposant que mon user a les droits)
4. m'apercevoir que l'output appartient à root et que je ne peux rien en faire : sudo chown user mon_output
5. tout répéter à chaque changement de contenu du script

"En vrai les conteneurs sont une solution universelle" pour bien se faire ch*** pour rien.

Les containers c'est nickel pour packager pour de la prod. Mais pour itérer en dev ….

Je vois bien le côté pratique des coroutines et des pipes.
Cependant, je ne vois pas en quoi cela améliore les performances (par rapport à quoi d'ailleurs?).

Le problème étant très simple aujourd'hui, je me suis permis une résolution en C pour tenter de faire de la perf.

Mais j'arrive péniblement à 2ms.

En même temps pour seulement lire chaque caractère de l'input (inlined), ça prend déjà 520µs ; du coup, je vois pas trop quoi améliorer …

La bonne pratique est de toujours créer un virtualenv pour un projet.
On utilise pas le profile user et surtout pas le profile du système.

En tenant compte de la forme du graphe, j'utilise uniquement la théorie des sets et je descends à 17ms. Et même à 4ms si je coupe à la première occurrence.

import sys
from collections import defaultdict as DD
from itertools import combinations as comb

D = DD(set)
for i in sys.stdin.read().strip().split('\n'):
    a, b = i.split("-")
    D[a].add(b)
    D[b].add(a)

for k, v in D.items():
    for i in v:
        w = v - {i}
        if all(b in D[a] for a,b in comb(w,2)):
            print(",".join(sorted({k}|w)))
            #sys.exit(0)

Je sais il est tard mais bon je pouvais pas rester avec un prod aussi lent.

Je parle pas de la partie 1, plutôt triviale.

Pour la partie 2, j'ai voulu ne pas succomber à la tentation d'utiliser d'une bibliothèque logicielle de graphes, genre Networkx.

J'ai implémenté un truc très peu optimal, rendu possible que par l'ajout d'un cache pour ne par ré-explorer un sous graphe en arrivant par un autre de ses noeuds.

J'ai perdu beaucoup trop de temps à chercher un bug qui n'existait pas car j'avais juste pas fait attention qu'il fallait séparer les noms des neouds par des virgules dans la réponse :/

Au final, 36s en python ; pas vraiment d'amélioration en compilant - 30s ; parce que ce n'est pas très calculatoire, juste très grand à explorer.

En corrigeant une petite bourde et en compilant le code, je descends à 33ms pour les deux parties.
Mais je suis bien tenté d'essayer d'implémenter ton algo …

J étais un peu déçu car je m attendais à une deuxième bien plus complexe

Je me suis fait la même réflexion : est-ce qu'il n'espérait pas que la partie 2 ne soit pas brute forçable mais en fait avec une pc un peut violent et en compilant le code, ça passe.

Cela faisait longtemps que la solution ne tenait plus en quelques lignes, et que la partie 2 ne pétait pas complètement la partie 1.

Aujourd'hui, avec du récursif et du cache, ça tient en 4 lignes.

import sys
from functools import cache
f = cache(lambda s: 1 if len(s)==0 else sum(f(s[len(r):]) for r in R if s.find(r) == 0))
R, I = sys.stdin.read().strip().split("\n\n")
R = R.split(", ")
print(sum(f(i)>0 for i in I.split("\n")))
print(sum(f(i) for i in I.split("\n")))

Il n'y a qu'une seule ligne intéressante : la fonction récursive.
En gros : pour une chaîne, si on trouve un préfixe valide, on refait un appel avec la chaîne amputée du préfixe. Si on arrive à une chaîne vide, on a pu faire le pattern demandé, sinon, non (la somme d'un générateur vide vaut 0).

Pour s'en convaincre, il faut regarder les différents cas.

• si la chaîne est vide, elle peut trivialement être réalisée avec n’importe quelle règle (retourne Vrai ou 1)
• si la chaîne ne commence par aucune des règles, elle ne peut pas être réalisé (retour Faux ou 0)
• si plusieurs règles constituent un préfixe de la chaîne, il faut examiner toutes les pistes pour construire la sous-chaîne et sommer ces possibilités.

La combinatoire explosant très vite, on met les résultats en cache pour pouvoir les réutiliser. Plus la chaîne est petite, plus le cache fera effet, c'est à dire en bout de chaîne ; dans l'exemple "gbr" est réalisé de trois façons différente ("g-b-r","gb-r", "g-br") ; on met en cache "bgbr" -> 3 et on a plus à le recalculer.

Pour "rrbgbr", on sait qu'on peut faire "rrb" de deux façons ("r-rb" ou "r-r-b"), on a donc 3+3=6 façons de faire la chaîne complete. Plus on avance dans l'exercice, plus on a des bouts réutilisables.

Dans mon cas, il y a 841E12 branches valides ce qui serait impossible à explorer ; mais avec le cache, seulement 53E3 appels à f et 18E3 entrées dans le cache.

ça mérite un journal

Un wiki gitlab est un repo git.

git clone git@mongitlab.net:monorg/monprojet.wiki.git

Even after Automattic acquired it, the site continued to lose money at a rate of $30 million each year

3M de blog, 30M$ de perte. 10$/blog/an ; ça me parait vraiment beaucoup.

Surtout que j'imagine qu'ils mettent de la pub et que donc ça peut rapporter.

Et pour se construire un environnement de dev par projet, je conseille asdf, quelque soit le langage. À combiner avec un virtualenv en ce qui concerne python.

Si c'est pour exécuter, il est tout à fait possible (contrairement aux FUD "inexactitudes" régulièrement diffusées par les fanboys utilisateurs d'autres langages) de construire un exécutable python.

Pour ma part, j'utilise PyInstaller. Avec un exemple ici qui construit un exécutable autonome pour visidata.

Si c'est pour intégrer dans un autre projet alors il faut packager pour pypi.org, de manière à ce que les utilisateurs puissent faire un pip install ma_belle_bibliotheque_logicielle. Avec un exemple ici qui est une ligne de commande pour lufi. En particulier regarder le contenu des fichier "setup.py" et "publish.sh".