Glandos a écrit 1433 commentaires

Il y a par exemple la lib Rayon pour Rust qui adopte un peu la même approche je crois.

Ah oui, c'est pas mal. Bon, il y a des différences conceptuelles dans le contrat des primitives :

If you do perform I/O, and that I/O should block (e.g., waiting for a network request), the overall performance may be poor.

Donc, c'est un peu l'inverse de Trio sur ce coup-là. Ce qui peut-être vu comme un complément. Rayon a l'air de simplifier les tâches parallélisables en environnement préemptif, alors que Trio (comme asyncio) favorise les tâches en environnement coopératif.

Mais ils ont l'immense honneur de mettre un terme au bordel, en instaurant une hiérarchie, permettant le retour des exceptions et de la bonne lecture du code.

Effectivement, comme déjà dit, foo() est qualifiée par async.

Un bon exemple (avec ipython):

In [1]: async def foo():
   ...:     print('1')
   ...:     

In [2]: def bar():
   ...:     print('2')
   ...:     

In [3]: bar()
2

In [4]: foo()
Out[4]: <coroutine object foo at 0x7fc5c6adae08>

En même temps, j'ai envie de poser la question : est-ce que la communauté « asynchrone » est si grande que ça dans l'écosystème Python ? Et même en général d'ailleurs. Il y a bien Javascript avec Node.js, et l'enfer du rappel que ça engendre (tiens, c'est une traduction rigolote du callback hell).

Mais asyncio en Python est vraiment tout récent, voire carrément « bleeding edge » dans l'industrie. Peu de bibliothèques l'utilisent, j'ai l'impression.

Et enfin, j'aurais envie de m'attarder sur le côté théorique plutôt que pratique. Trio propose un nouveau paradigme de programmation, une évolution. Ce n'est pas lié à Python, même si sa proposition concrète est faite avec. Mais qu'est-ce que ça peut donner dans d'autres langage ? Après tout, certains langages possèdent suffisamment de souplesse pour obtenir peu ou prou le même résultat.

Évidemment, avant de généraliser, il vaut mieux montrer au monde que ça marche avec une implémentation solide et reconnue. En tout cas, c'est comme ça que ça fonctionne aujourd'hui.

Il est têtard. Mais le tout est de faire la correction dans l'étang.

mardi 14 juin 2018

Je confirme, c'est Grammalecte. Sous Firefox, avec la version 0.6.4, le mot est en vert, avec en suggestion « jeudi ». C'est vrai, c'est sympa.

OK, envoie moi un moyen de te contacter, en utilisant mon JabberID, qui est aussi une adresse email valide :)

OK, envoie moi un moyen de me contacter, en utilisant mon JabberID, qui est aussi une adresse email valide :)

Évidemment ça ne sera peut-être pas adapté, mais c'est une idée : le laryngophone. Je vais repomper Wikipédia pour les flemmards :

Il est utilisé :

• dans des environnements très bruyants où la communication serait perturbée avec un microphone acoustique (sur un chantier, à moto, dans un hélicoptère, sur un champ de bataille),
• ou bien pour permettre au locuteur de rester furtif en parlant à un niveau plus faible qu'avec un microphone acoustique (et ainsi ne pas révéler sa position), et en cachant l'appareil sous son col (dans les opérations sous couverture)2.

Après, il faut pouvoir le fixer, ce qui n'est peut-être pas évident avec l'appareil d'assistance respiratoire.

NIH ?

Not Invented Here

C'est parce que ça me semblait être un besoin déjà couvert par des programmes existants. Mais les explications sont beaucoup plus claires comme ça :)

Ah oui, ça fait un peu NIH, mais pourquoi pas.

Et j'ai pas compris la différence avec pipenv. Bon, OK, j'ai pas pris le temps de chercher la différence.

Là pour le coup, ça aurait fait un journal, même succinct. Sur le site, on voit juste une liste de schéma, on comprend pas ce que c'est, encore moins quand on ne sait pas de quoi ça parle, ni à quoi ça sert.

There are some issues specific to Fedora there, but the biggest improvement that we can achieve is shutting down’s GDM’s own gnome-shell instance, for which Hans already has a working patch. This should reduce resource consumption by 280megs of RAM.

Aaaaaaah, ça va faire du bien.

The second biggest target is GNOME Software, which we keep running primarily for the shell provider. Richard Hughes was here yesterday and is already working on a solution for this.

Aaaaaaah, ça va aller mieux.

En attendant, j'ai un portable avec 4Go de RAM. Et une session ouverte après démarrage, il y a déjà 1,2Go d'occupé. Ça laisse étonnamment peu de place pour lancer autre chose :/

Tout est là : https://community.ubuntu.com/t/gs-connect-as-part-of-18-10/5903?anz=show

Encore un autre : https://rdfind.pauldreik.se/

Je l'ai essayé, ça va vite. Très vite. Il y a un petit benchmark à la fin.

https://lists.debian.org/debian-devel/2015/06/msg00173.html

Bon courage pour suivre le débat :)

Il me semble que c'est passé sur debian-devel. Mais je n'ai pas le temps de rechercher, malheureusement.

Ce que j'en ai retenu, c'est que oui, lzip est mieux, xz est pas très robuste. En théorie. En vrai, personne ne constate de problème. Et il y a des sommes de contrôles partout ailleurs (notamment TCP) qui empêchent déjà beaucoup de corruption.

Et je crois bien que les développeurs de Debian reprochaient également un prosélytisme un peu trop subjectif.

Ce que j'ai résumé n'est pas mon avis, mais seulement un condensé de ce que j'ai lu.

Je suis repassé à l'ancienne méthode : https://github.com/Timvde/UserChrome-Tweaks/

Et notamment :

@import url(./UserChrome-Tweaks/tabs/more-compact-tabs.css);
@import url(./UserChrome-Tweaks/toolbars/auto-hide.css);
@import url(./UserChrome-Tweaks/toolbars/compact-toolbars.css);


on parle par exemple de l’utilisation de l’algorithme de compression Zstandard pour tous les paquets afin d’accélérer les temps d’installation.

Oula, alors c'est en discussion chez Debian. Et franchement, je suis pas convaincu par l'intérêt de la chose.

Zstd est un formidable outil de compression, mais l'usage généraliste des paquets, c'est l'installation via le réseau. Et dans la plupart des cas, il vaut mieux du LZMA (xz), qui compresse bien mieux. Le temps de transfert est bien plus long que le temps de décompression. On pourra s'en convaincre sur ce benchmark, en ayant choisi samba comme corpus. Le temps de transfert sur un lien à 7 Mio/s (ce qui est déjà pas mal) prend plus de 90% du temps total.

Par contre, c'est évident que sur un support d'installation, avoir du zstd permet une installation plus rapide. Ou bien si on installe des VMs à tour de bras avec un dépôt local.

Donc ce qui est intéressant, c'est que dpkg supporte zstd. Et on pourra voir ce qui peut en être fait.

Effectivement, je trouve le texte excellent. Par contre, « quelques » années n'est pas tout à fait exacte. On en est presque à deux fois sept ans ;)

Il y a un peu de tout là-dedans : https://framablog.org/2018/04/19/la-reforme-europeenne-du-droit-dauteur-une-menace-pour-le-logiciel-libre-selon-glyn-moody/

Sinon, pour le code propriétaire : https://en.wikipedia.org/wiki/VMware_ESXi#Lawsuit qui n'est qu'un exemple.

Désolé de faire court, ma vie trépidante m'empêche d'être aussi prolixe. Mais j'ai bien apprécié l'effort, que j'ai pris le temps de lire.

Les frappes claviers génèrent des évènements qui sont bien différents d'une opération de collage. Je n'ai jamais eu à gérer ce cas là cependant. J'ai cherché (un peu) dans le code de fish, mais sans succès…

EDIT: En fait, effectivement, c'est probablement ce qu'a expliqué Goffi qui marche. Je ne sais pas si c'est possible de distinguer les deux sinon.

Et bien fish est là pour vous. Quand je colle du texte, les retours chariot ne sont pas interprétés comme un envoi de commande : le texte va à la ligne. Et seulement quand je tape sur la touche Entrée, ça exécute.

J'aime beaucoup.

https://phab.enlightenment.org/diffusion/TRM/browse/master/ChangeLog

Parce que bon, un lien d'archive de binaire, c'est pas super explicite.

Windows Server est installé par défaut avec l'antivirus maison « Windows Defender ». Linux n'a aucun antivirus installé ni activé par défaut (ne serait-ce pas une faille de sécurité ?).

Bon, OK, y a des choses plus pertinentes dans l'article, c'est juste pour rigoler.

Tu veux dire comme ces deux images ? ;)

Pour être constructif : je ne sais pas. Mais je t'invite à lire la spécification.