Shuba a écrit 439 commentaires

Par exemple, ceci est cité dans la liste «Desktop Linux Problems and Major Shortcomings»:

Linux has a 255 bytes limitation for file names (this translates to just 63 four bytes characters in UTF-8) - not a great deal but copying or using files or directories with long names from your Windows PC can become a serious challenge.

Surtout qu'en NTFS aussi il y a une limite à 255 caractères (UTF-16, certes, mais en pratique c'est pareil pour beaucoup de noms).

Ce type qui n'a visiblement jamais vécu à la campagne nous inflige son inculture satisfaite. Il ne sait pas qu'il y a 50 ans, et encore plus il y a 80 ans, il y avait du chemin de fer à peu près partout. Dans ma montagne et ses bleds maintenant isolés de quelques centaines d'habitants, il y avait non seulement le train pour venir, mais il y avait également des tramways électriques pour continuer !

Et bien là, tu viens de prouver que tu n'est pas mieux que ceux que tu conchies dans ton vomi littéraire.
J'ai grandi à la cambrousse, dans un bled qui s'appelle Ham, dans la Somme.
Il y a effectivement des trains … qui t'emmène partout SAUF ou tu veux aller.

L'auteur du journal parle de la situation il y a plus 50 ans, pas de l'actuelle.

Heureusement on peut aussi utiliser des touches plus naturelles: HJKL.

Uniquement en debian testing et unstable pour le moment on dirait. J'espère que ça va arriver dans stable (par les backports peut-être?)

Sur l'intuitivité et la qualité, je ne me prononcerai pas, mais l'interface est franchement déroutante quand on a l'expérience d'autres logiciels de montage (eg Premiere), là où kdenlive est plus proche de cette interface "classique".

Les optimisations sont essentiellement celles de LLVM pour le moment, ce qui est pas mal. Après rustc donne une énorme quantité d'IR à LLVM, ce qui lui rend l'optimisation non triviale (et longue). Mais ça marche plutôt bien en pratique.

Il y a du travail en cours pour réduire la quantité de LLVM IR émise (et ainsi avoir certaines passes d'optimisation plus haut dans la chaine de compilation). Mais ça va prendre du temps à arriver.

D'après https://fr.wikipedia.org/wiki/Niveau_de_vie#Mesure_et_d.C3.A9finition la mesure du niveau de vie prend en compte l'inflation.

Qu'entends-tu par union sécurisée? Une union avec de la "RTTI"?

Je pense qu'il veut dire une union taggée où tu n'as pas la possibilité de mal interpréter le tag en restant dans le subset safe du langage. Par exemple, en rust, le type option permet de représenter un résultat ou son absence, et le langage t'oblige à faire du pattern matching pour savoir quel cas tu as eu. C'est impossible à utiliser de manière incorrecte sans faire appel à unsafe.

Au passage ce type a une optimisation assez puissante lorsqu'il est instancié sur des pointeurs: dans ce cas, il ne rajoute pas de champ à l'objet pour tagger, il va tester directement si le pointeur est nul ou non. C'est aussi performant que de gérer le pointeur à la main, mais tout aussi sûr.

J'ai souvent vu la variante de semver où, pour les versions inférieurs à 1.0.0, seuls les changements cassant la compatibilité mandataient un incrément du deuxième nombre. Ce qui revient à avoir une politique de semver sans identifiant pour les correctifs de bug.

Personellement je préfère cette variante, qui permet de mieux prévoir la stabilité d'un composant avant que son API soit vraiment considérée stable (1.0). Par contre le risque est de ne jamais passer en 1.0…

La notion de "propriété" n'existe que dans le cadre de l'état, donc l'état me semble assez légitime pour redistribuer derrière.

• traitement du signal n'implique pas EDP
• plus spécifiquement, transformée en cosinus discret, quantisation, vecteurs de prédiction, choix de I vs P vs B frame, ça ne me semble pas relié aux EDP, ou de loin
• la phrase originale parle du comportement global du logiciel.

Je vois pas où on parle d'équations aux dérivées partielles.

Contrairement à ce que tu écris

Mozilla indique vouloir discuter et modifier l'API de WebExtension (pas encore officiellement publiée, par ailleurs) dans la prochaine année, alors que le retrait de l'ancienne API XUL/XPCOM se fera d'ici 12 à 18 mois!

Mon interprétation de

We don’t have a specific timeline for deprecation, but most likely it will take place within 12 to 18 months from now

est que la déprécation de XUL pour les modules commence dans 12 à 18 mois, avec aucune date fixée pour le retrait. Donc il devrait quand même y avoir un certain temps d'adaptation.

Ok je suis un peu perdu sur quelle source est sous quelle license là.

De ce que j'avais compris, il y a des fichiers audio non mixés A qui sont sous CC-By-ND, et un fichier final B créé à partir de ces sources, mais sous license CC-By. Pour le possesseur du copyright sur les sources audio A, il n'y a aucun problème à donner une license moins restrictive sur le fichier final B, il fait à peu près ce qu'il veut.

Si tu extrais la piste audio du film B, elle est bien sous license CC-By. Si tu arrives à en extraire les différentes sources dans un process au cours duquel tu n'as aucune connaissance des sources originales A (eg en clean room), tu auras un résultat C sous license CC-By, quelle que soit la license des sources originales A.

Si par contre tu as connaissance des sources originales A, rien n'est clair et on pourrait dire que tu crées une oeuvre dérivée D de ces sources A.

Après peut-être que j'ai mal compris la situation et que mon raisonnement ne s'applique pas.

Si je comprends bien, si tu utilises les autres sources pour appliquer ton inverse tu en deviens un dérivé et donc tu ne respectes pas le -ND. Donc tu ne peux pas obtenir ces sources en CC-By sauf à avoir un algo qui sépare les sources sans connaissance extérieure (ce qui est potentiellement faisable, mais pas de manière exacte).

C'est dans le rust-book mais ça a été ajouté récemment il me semble:

There’s one more restriction on implementing traits. Either the trait or the type you’re writing the impl for must be defined by you. So, we could implement the HasArea type for i32, because HasArea is in our code. But if we tried to implement Float, a trait provided by Rust, for i32, we could not, because neither the trait nor the type are in our code.

Une RFC récente qui traite du sujet: https://github.com/rust-lang/rfcs/blob/master/text/1023-rebalancing-coherence.md
(mais je ne l'ai pas lue en détail donc je suis pas sûr que ce soit elle qui ajoute ces règles).

En revanche, les traits permettent aussi de faire la chose suivante :
si un code tiers définit le trait WordCount (ayant une méthode wordCount()), ainsi que des fonctions manipulant des objets implémentant ce trait, je peux dans mon propre code dire que les String (définies dans la bibliothèque standard que je ne peux/veux pas modifier) implémentent ce trait, et donc appeler les fonctions de ce code en lui passant directement des String. Ce n'est pas possible en C# de dire que maintenant String implémente l'interface IWordCount.

Il me semble que seules la crate définissant WordCount et la crate définissant String pouvaient implémenter le trait pour String, tout autre crate n'en a pas le droit. Par contre tu peux bien implémenter WordCount pour un type défini dans ton propre code.

¹ et faire un Troll sur Qt c'est carrément trollesque

Je l'aurais bien faite si tu ne l'avais pas digia fait.

Je pourrais parler du constructeur par copie implicite où, si on fait un code isomorphe à celui de Rust, on utilise unique_ptr ou shared_ptr et pas besoin d'implémenter quoi que ce soit hormis le constructeur, tous les trucs par défaut fonctionneront sans problème, avec une sémantique claire. Parce que là, le code en Rust, on a du mal à voir sa sémantique : ça compile, ça fonctionne sans erreur, mais qu'y a-t-il dans a et dans _b à la sortie, je ne saurais le dire.

En gros tout est unique_ptr par défaut dans rust, donc a n'est plus une variable valide (le compilateur ne laissera plus y accéder) et b contiendra la valeur d'origine.
Si on veut effectuer une copie rust il faut appeler .clone().

Trop gros, passera pas…

http://reflets.info/elections-ump-et-le-gagnant-est-bozo-le-clown/

We reserve the right to fix compiler bugs, patch safety holes, and change type inference in ways that may occasionally require new type annotations. We do not expect any of these changes to cause headaches when upgrading Rust.

Devoir éventuellement rajouter une annotation de type pour que ça compile à nouveau ça ne m'a pas l'air si terrible que ça.

(sauf avec une auto-complete potable, mais celle de vim étant ce qu'elle est…)

As tu testé YouComplteMe ? C'est un autocompléteur qui fait de la recherche dans les sous-séquences, et utilise clang pour la complétion sémantique.

Je sais pas pour les autres conteneurs STL mais Qt Creator s'en sort très bien avec les std::vector et les std::string, probablement parce qu'il inclut de base des scripts gdb pour bien les gérer.

A te lire je n'ai pas l'impression qu'on ait exactement le même soucis, moi ça posait surtout des problèmes à KDE, dont le sélectionneur de fichiers devenait gelé, là où j'ai l'impression que toi c'est carrément la sorti de veille où le démarrage qui se passe mal.