jeberger a écrit 140 commentaires

Note qu'attesoro n'est pas un éditeur de .properties mais un éditeur de traductions. Le fait que les traductions soient stockées dans des fichiers .properties et qu'il faille mettre des codes \uxxxx est un détail d'implémentation et ce n'est pas là que réside son intérêt. L'utilité d'attesoro tient en ce qu'il manipule l'ensemble des fichiers de traduction d'un coup.

Je ne t'apprend sans doute rien si je te dis que les traductions sont faites avec un fichier toto.properties pour la langue par défaut et des fichiers toto_xx.properties pour chaque langue (par ex. un fichier toto_fr.properties pour le français). Dans attesoro, il suffit d'ouvrir toto.properties pour qu'il ouvre aussi les autres langues. Ensuite il vérifie que tu as bien les mêmes entrées dans tous les fichiers et il te signale les incohérences. Quand tu sélectionnes un identifiant de message, il te permet d'éditer la traduction et le commentaire pour la langue en cours, mais il t'affiche aussi le message original et le commentaire associé. Il permet aussi de passer rapidement d'une langue à l'autre en restant sur le même message.

En contrepartie, il n'est pas adapté pour éditer un fichier de propriétés génériques : il n'offre aucune facilité pour gérer la hiérarchie des propriétés, ou pour sélectionner un fichier ou une image et mettre le chemin correspondant dans une propriété par exemple (aucune idée si Eclipse ou Netbeans le font, mais ça me paraît des fonctions de base pour un éditeur de propriétés).

Le pb ne vient pas de Scala, mais des fichiers .properties de Java : ceux-ci ne peuvent contenir que des caractères ASCII, et si tu veux mettre autre chose, il faut entrer le code Unicode \uxxxx. Pour simplifier la traduction, je te recommande attesoro qui gère ces problèmes de conversion pour toi.

Cet univers est bien desservi en jeu avec des graphismes, et des musiques, de belles qualités.

J'imagine que tu voulais dire : « Cet univers est bien servi en jeu… » ? Dans ce contexte, « desservir » signifie « nuire à » et n'est pas très cohérent avec la fin de la phrase. D'ailleurs, si c'est bien ce que tu voulais dire, je ne suis pas d'accord : moi je les trouve très sympas les graphiques ;)

Sinon, belle dépêche bien complète, bravo !

Pourquoi est-ce que l'article Wikipédia de Rust indique "Appeared in : 2012" ?

Probablement à cause de la première version alpha numérotée du compilateur actuel (basé sur llvm et écrit en Rust alors que le précédent était écrit en OCaml). Cette version a été publiée en janvier 2012, soit 3 mois avant la première version numérotée de go (avril 2012 d'après l'archive des anciennes versions).

C'est sans doute lié au fait que Go est apparu 3 ans avant Rust

En fait, non: Rust a commencé à être développé un an avant Go (2006 pour Rust et 2007 pour Go) et a été annoncé officiellement un peu plus de 6 mois après (novembre 2009 pour Go et juillet 2010 pour Rust).

Sources Wikipedia Go et Rust (plus Mozilla pour le mois de 2010 durant lequel s'est tenue la conférence où Rust a été annoncé).

Grrr, j'avais essayé de rajouter un espace à la fin de la ligne précédente, je croyais qu'en markdown ça revenait au même qu'une ligne vide…

def foo(
  bar
):
  this.is_.a.very \
  (
   long, line,
   which,
   only,
   serves,
   as_, a, dumb,
   example
  )

Note que les seuls trucs moches dans l'histoire n'ont rien à voir avec l'indentation:
* Le \ est à cause des ; optionnels: si je ne mets pas le \ il croit que this.is.a.very représente une instruction complète et que le truc entre parenthèses est un tuple. Une autre option serait de mettre la parenthèse ouvrante sur la même ligne que this.is.a.very.
* Le as_ et le is_, c'est parce que as et is sont des mots-clefs (c'est pareil en C: tu ne peux pas avoir de variable appelée while).

PS: pkoi la liste à puces ne marche pas?

Peut-on leur mettre des calculatrices qui ne comprennent pas "2 + 2" mais sur lesquelles ils faut taper "+ 2 2" ? Parce que quand même, c'est vraiment plus joli "+ 2 2"

Perso, j'ai appris à utiliser une calculatrice sur une HP-12C, donc "2 2 +", et ça ne m'a posé aucun problème.

Ça te permet d'héberger ton seafile sur un serveur cloud public (Amazon par ex.) sans que l'hébergeur puisse accéder à tes fichiers (puisqu'il ne les voit jamais en clair).

Personnellement, mon joystick (*) n'est pas à retour de force. J'ai lu plusieurs commentaires qui disaient que le retour de force sert juste à donner des effets spectaculaires, mais ne sert à rien vis à vis du réalisme. Cependant le commentaire d'Obsidian ci-dessus concorde avec les différences que j'ai observées entre le T-Flight et un vrai manche (en même temps, mon expérience du vrai manche se limite à 2h de planeur, et j'ai zéro expérience du joystick à retour de force…)

(*) T-Flight Hotas X

Oui, c'est ce qu'on lit à plein d'endroits, mais :
- Le DHC6 (bimoteur) le fait un peu.
- Le Mirage 2000 (monoréacteur) le fait aussi franchement.

Les plus violents que j'ai essayés sont les mono-moteurs de la 2eme guerre mondiale (Spitfire par exemple), et ça semble correspondre à ce que disent ceux qui ont eu l'occasion d'en piloter en vrai (et ça se contrôle en suivant les indications qu'ils donnent).

AMA pour Flightgear :

1. Procure toi un joystick (le premier prix est à 15€ chez grosbill). Ça fait vraiment un énorme différence.
2. Utilise un lanceur graphique comme fgrun, sinon il faut déjà se taper la page man pour les options de la ligne de commande ;)
3. Commence avec le Piper Cub. C'est un avion très simple : il y a juste 3 cadrants (régime moteur, vitesse et altitude) et pas de commandes particulières (à part le compensateur). Note que l'avion par défaut est le Cessna 172 ; c'est un avion « facile » pour un débutant, mais comme le modèle FG est très complet tu risques de te retrouver noyé dans le tableau de bord et les commandes…
4. C'est pas grave si tu décolles en dehors de la piste (les avions FG ont tendance à partir à gauche au décollage, mais au pire tu décolleras dans l'herbe à côté).
5. Deux exercices de base pour débuter :
   • Survoler la piste bien dans l'axe sans te poser.
   • Poser l'avion en douceur n'importe où. Il sera toujours temps de poser l'avion sur la piste une fois que tu maîtriseras ces deux points.

Et surtout le plus important : fais-toi plaisir et amuse-toi ;)

Bon vol, et à bientôt peut-être en multijoueurs.

Note pour compléter que Python a un module multiprocessing, qui permet de faire du vrai multi tâches (i.e. sans GIL) de manière simple en gérant plusieurs processus un peu comme s'ils étaient des threads. Pour autant que je sache, Ruby n'a pas d'équivalent pour l'instant bien que certains considèrent que ce serait quelque chose d'intéressant à avoir…

Je vois au moins un logiciel de montage vidéo linéaire: avidemux. Tout ce qu'il permet de faire en terme de montage, c'est de couper une partie d'une vidéo ou de concaténer deux vidéos. Les logiciels de montage non linéaire permettent beaucoup plus que cela (remplacer une partie d'une vidéo par une autre, insérer une vidéo au milieu d'une autre, ajouter des effets de transition entre deux vidéos, créer des titres, etc.)

Euh, tu n'aurais pas inversé la description des principes de localité pour la mémoire cache ? Normalement :
- La localité spatiale signifie que l'on travaille généralement sur des données groupées en mémoire, donc si on a accédé à une adresse, on va probablement accéder juste après aux adresses proches. Ceci correspond à ton exemple de boucle où tu accèdes successivement à des indices différents du tableau a[i].
- La localité temporelle signifie que quand on travaille sur une donnée, on effectue généralement plusieurs opérations dessus, donc on accède plusieurs fois à la même donnée à des intervalles de temps rapprochés. Ceci correspondrait à utiliser plusieurs fois le même a[i].

Dans ton article, tu dis le contraire alors que Wikipedia dit la même chose.

J'imagine que maintenant tu peux mettre Chuck Norris et John Doe dans le même li.

Bin avant tu pouvais aussi, il suffisait de les mettre dans des <span data-value="foo">…

Oui, mais cela n'empêche pas que les deux sont des codes de type VLC. Cf. par exemple ce cours de théorie de l'information : le chapitre 5 est intitulé « Variable-length coding » et la section 5.3 est « Arithmetic Codes » (j'avais commencé par citer Wikipedia mais vu que cette page considère LZ comme un code VLC, j'ai trouvé que ça ne faisait pas très crédible…)

Ce qui définit un code de type VLC, c'est que chaque symboles source est représenté par un nombre de bits différent après compression. Dans le cas du code de Huffman, ce nombre de bits est entier et la séquence qui représente un symbole donné est toujours la même. Dans le cas du code arithmétique, ce nombre de bits est fractionnaire et la séquence qui représente un symbole donné varie en fonction des symboles voisins. Dans les deux cas, chaque symbole source correspond à un nombre de bits variable après compression.

Par opposition, un codage de type LZ77 n'est pas un code VLC puisque les symboles codés ont tous la même taille indépendamment des symboles source.

PS: Je sais que les normes MPEG (et JPEG) utilisent le terme « VLC » pour désigner un code de Huffman. Ceci est principalement dû à des raisons historiques puisqu'à l'origine Huffman était le seul code VLC utilisé. Quand H264/JPEG2000 ont introduit le codage arithmétique, ils ont préféré garder l'appellation « VLC » pour la méthode historique afin de rester cohérent avec les normes existantes.

Introduit par H264 et réservé aux profils les plus élevés, le codage arithmétique CABAC est désormais systématique pour remplacer les codages de type Variable Length Coding.
…
On considère le gain du CABAC par rapport au VLC de l'ordre de 10%.

Le codage CABAC est aussi un codage de type VLC. La nouveauté, c'est que les normes précédentes utilisaient un codage de Huffman, ou un codage arithmétique simple comme code VLC.

L'intérêt du codage CABAC c'est qu'il dépend du contexte, c'est à dire qu'il ajuste automatiquement ses paramètres en fonction du contenu de l'image alors que le code de Huffman ou le codage arithmétique simple utilisent des paramètres constants (voire fixés une fois pour toute par la norme).

A noter que quand Noteedit a disparu du net, j'avais fait un miroir du code source ici. Je n'ai pas fait grand chose de plus avec si ce n'est faire en sorte qu'il compile sur une Arch récente. Comme je n'ai rien documenté, ce n'est pas forcément facile à reprendre pour quelqu'un d'autre, mais s'il y a un intérêt je peux faire un PKGBUILD et le mettre sur AUR…

À noter que le jeu est aussi disponible pour Android.

IMMS a aussi une approche intéressante de la gestion de la playlist: il étudie comment tu écoutes ta musique (quels morceaux tu sautes, lesquels tu écoutes en entier et sur lesquels tu reprends après avoir sauté) et il en déduit tes préférences et ton humeur. À partir de là il choisit aléatoirement les morceaux de ta playlist qui devraient le plus te plaire à un instant donné.

Bof, en Europe tu ne peux pas breveter « un programme qui fait… » mais tu peux breveter « un programme tournant sur une machine, lequel programme fait… ». Du moins, c'est ce que le responsable des brevets de ma boite m'a dit (et il le tenait d'un officiel de l'OEB). Les juristes sont vraiment champions du coupage de cheveu en quatre.

Alors, la différence entre l'Europe et les US sur la question du brevet logiciel…

Il y a OpenRisc aussi…

C :) https://bitbucket.org/jmb/cseh (désolé pour la pub).

Le lien devrait être : http://doc.qt.digia.com/4.0/qt3support.html