steph1978 a écrit 3287 commentaires

Des gens de races et de cultures différentes vont vivre ensemble, se disputer, s'aimer, se reproduire, se mélanger, etc.

Tu y va fort, notre pauvre ami fasciste va avoir une syncope à cette pensée :D

Tu juxtapose des phrases, ça n'en fait pas un quelconque argument.

Je supposes que c'est une question de tournure d'esprit

Non, c'est la malhonnête intellectuelle. Tu utilises une tournure de phrase qui force à accepter la première partie si on accepte la seconde partie alors qu'elles n'ont strictement aucun lien.

Je pourrais dire : "Comme si la pensée fasciste n'était pas le cancer de notre société, que la pluie ne mouillait pas".

Remarque que les deux parties sont vraies mais n'ont aucun lien.

La dilution des peuples

Le fantasme de tout partisan de l’extrême droite.

Comme si les peuples ne s'étaient pas de tout temps mélangé. Et quand bien même ce serait nouveau, c'est quoi le problème?

La lecture du titre me suffit à me réjouir de cette ironie délicieuse.

Mais je lirai l'article.

Il y a peu j'ai installé Gerbera - successeur de Mediatomb que j'utilisais sur un NAS - sur un PC et minidlna sur un autre. Pas sur d'avoir une préférence pour l'un ou l'autre ; ils sont très simples à installer et configurer.

C'est pratique d'avoir accès à ses vidéos/musique de partout dans la maison.

il y a d'autres chatons actifs.

Si ça se fait sur insta, fb, yt, snap, totok et autres, pourquoi pas sur GH ?

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 …