Schnouki a écrit 92 commentaires

Gros +1 pour eglot. Par contre oui il faut des services qui tournent en tâche de fond, même si eglot gère ça de manière transparente.

Si tu veux quelque chose de plus simple pour gérer la navigation entre définition et déclaration, je suggère dumb-jump, qui utilise rg (ou ag, ou grep) pour trouver la cible. C'est moins précis qu'eglot si tu as plusieurs fonctions/méthodes avec le même nom, mais en général ça marche quand même très bien :)

Ça a l'air vraiment cool, je note l'idée pour faire la même chose chez mes parents :D

Par contre dans ton script je crois qu'il y a un problème d'indentation au niveau du if REGULAR=='Junk', qu'il manque quelques bouts de code :

• d'où vient serial_line au début de la boucle ?
• où est le code qui décroche et raccroche ?

Merci !

Félicitations pour votre travail sur WeasyPrint ! Ça fait un moment que j'en ai une utilisation occasionnelle. Récemment je l'ai utilisé un peu plus via django-weasyprint et c'est vraiment très agréable. Mes utilisateurs sont contents d'avoir facilement des PDF dans leur navigateur, et pour moi c'est le même code avec juste un CSS un peu différent (@media print…).

Bref, bravo pour WeasyPrint, et merci !

Ah oui, leurs tarifs EU sont plus bas que les tarifs US… Mais pour une marketplace ou du crowdfunding il y a les tarifs de Stripe Connect à ajouter. Donc à mon avis c'est plus cher quand même.

Mais avec des frais beaucoup plus importants que Mangopay (à peu près le double si je me souviens bien), et encore plus si tu veux un fonctionnement avec des comptes de cantonnement (Stripe Connect), indispensable pour du crowdfunding ou une marketplace… Faudrait plutôt quelque chose du type LemonWay du coup.

(Je précise que je n'ai d'intérêts chez aucunes de ces sociétés, et que professionnellement j'ai travaillé avec Stripe il y a quelques années et Mangopay en ce moment.)

Par pur soucis de transparence, tu devrais ajouter un petit disclaimer précisant que tu bosses pour Elastic quand tu postes ce genre de commentaire.

avec DHL c'est plus pro

Le mec de DHL qui m'a livré un colis "contre signature" en le mettant dans ma boîte aux lettres et en signant lui-même (sans sonner), c'était pas super pro pourtant. Heureusement pour moi que le paquet était en bon état, j'imagine pas la galère que ça aurait pu être si le machin était abîmé.

Y'a aucun transporteur qui est pro. FedEx, UPS, DHL, Colissimo, même combat.

Et en plus il y a une version Android qui marche bien sur F-Droid.

Ou Gitea (ou Gogs), qui a l'avantage d'être bien plus léger que Gitlab…

En fait le nom correct est PubSubHubbub (pas de B majuscule), et c'est généralement abrégé en PuSH.

[X] buddycloud, parce qu'il y a un super client en console (que j'ai écrit).

Oups, apparemment pour le redimensionnement c'est normal, le programme compte le nombre de pixels affiché en utilisant une taille de fenêtre fixe et prédéfinie à 1000x1000. Haha.

Par contre parfois Shader2 a les mêmes performances que les autres, parfois 2 fois moins… Et d'après le code les 2 sont équivalents mais Shader2 rajoute juste des no-ops qui sont peut-être supprimés par l'optimiseur du compilateur de shaders…

Avec le driver propriétaire (304.64) et fill compilé à la main parce qu'il n'est pas dans le paquet mesa-demos d'Arch Linux :

 Simple fill: 11.1 billion pixels/second
 Blended fill: 11.1 billion pixels/second
 Textured fill: 11.1 billion pixels/second
 Shader1 fill: 11.2 billion pixels/second
 Shader2 fill: 5.6 billion pixels/second

Si je redimensionne la fenêtre ça modifie les résultats. Avec une fenêtre plus petite j'ai eu 12.8 Gpixels/s partout.

Quel est l'intérêt d'un tel "benchmark" ? Dans le monde réel il y a bien d'autres facteurs de performances que le nombre de pixels/seconde… Et là d'après nvidia-smi ce test n'a fait qu'utiliser 2% de la mémoire dispo sur ma carte (1 Go) et n'a pas fait augmenter sa température d'1°. On est loin d'une utilisation réelle…

Glxgears n'est pas un benchmark.

Heureusement que ce problème des rails sera réglé avec la ligne 2. Eh oui, à Nancy la 2e ligne de tram sera en fait… une ligne de bus ! \o/

À Nancy il est diffusé en VF et VOST au Caméo Commanderie.

Ça m'intéresserait aussi d'en savoir plus. Parce que le développement du projet est loin d'être mort, au contraire.

Haha, UPS. Il y a quelques semaines quelqu'un dans mon immeuble avait mis une affiche pour expliquer que le mec d'UPS avait laissé un mot disant qu'il avait donné son colis à un voisin, mais sans dire quel voisin. Pas pratique dans un immeuble avec une cinquantaine de logements où assez peu de gens se connaissent…

Ahah, j'ai aussi vu ça en œuvre pendant un stage dans une filiale d'entreprise du CAC40.

Et le plus rigolo c'est que ça ne marchait "bien" qu'avec Internet Explorer (6 bien sûr) : quand je lançais mon petit Firefox, le proxy HTTPS me demandait de m'authentifier (avec des identifiants que bien sûr je n'avais pas) pour environ la moitié des sites, ce qui revenait en gros à les bloquer.

Bon en fait c'est peut-être pas si rigolo que ça...

Je récupère mes mails avec OfflineIMAP et je les indexe avec notmuch, pour finalement les afficher/gérer/écrire/etc. dans Emacs.

notmuch utilise des tags plutôt que des dossiers. Dans ma config, les nouveaux mails ont automatiquement les tags "inbox" et "new". Après avoir téléchargé les nouveaux mails et les avoir indexé avec notmuch, j'ai un script (Python) qui va filtrer les messages ayant le tag "new" :

• mailing-list --> tag "ml" et tag spécifique à la liste, et on enlève "inbox"
• bugtracker --> tag "bug" et tag spécifique au projet
• banque --> tag "banque", potes de prépa --> tag "prépa", etc.
• mails dont je suis l'auteur --> tag "sent", mails dont je suis le destinataire --> tag "to-me"

Il y a aussi les tags "unread", "flagged", "replied" etc. qui sont synchronisés avec leurs équivalents sur le serveur IMAP grâce à notmuch et OfflineIMAP.

Ensuite dans Emacs j'ai des "saved searches": "tag:inbox", "tag:unread", "tag:todo", "from:lwn.net", "tag:sent", etc. Un peu comme des dossiers quoi.

Si je veux faire une recherche complexe, il y a une interface vers "notmuch search" directement dans Emacs. J'ai donc juste à taper "from:Machin subject:blabla". Bien sûr notmuch gère la recherche plein-texte. Sur mon PC ça prend quelques dizièmes de secondes pour faire une recherche plein-texte sur 130 000 mails.

J'utilise ça depuis plus de 6 mois et pour moi c'est beaucoup plus agréable que Thunderbird, Evolution & cie.

notmuch + Emacs, parce que je le vaux bien.

Faut croire que Microsoft aime faire des gâteaux...

Je m'interroge sur le "bien plus de fonctionnalités".

Dropbox a pas mal de fonctionnalités sympas, comme le fait de pouvoir rendre des fichiers publics (et zouu la jolie URL qu'on peut envoyer à ses amis), de pouvoir partager des dossiers avec le compte de quelqu'un d'autre, de pouvoir faire d'un dossier de photos une galerie web simple et fonctionnelle... (Je ne parlerai même pas de la possibilité d'avoir un client sur smartphone & cie, ça a déjà été dit, ni que le client Linux, natif, évite tout le bloat de la JVM : troller sur Java, c'est vraiment trop simple.)

À part la tétrachiée de supports de stockages supportés (ce qui est très sympa, il faut bien l'avouer), quelles sont donc les "bien plus de fonctionnalités" de Syncany par rapport à Dropbox ou SparkleShare ?

http://lmgtfy.com/?q=openldap+windows, 1er lien.
Testé par des étudiants en TP, ça a l'air de bien marcher.

C'est amusant comme le scheme est souvent enseigne en fac mais absolument jamais en ecole de prepa...

Peut-être parce qu'en prépa il y a un programme fixé à respecter et qui ne donne le choix qu'entre 2 langages : Pascal et Caml Light. Et Maple ou un truc du genre en cours de maths, mais de là à appeler ça de la programmation...

Et de toute façon, l'informatique en prépa, c'est pas des cours de programmation. C'est des cours d'algorithmique.