jeberger a écrit 134 commentaires

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

« Médiéval fantastique » in french in ze texte…

Ça marche comme avant : tu commences à taper et ça affiche immédiatement une liste mise à jour en temps réel, et tu appuies sur ↓ pour sélectionner une adresse. Sauf qu'en plus, il ajoute dans la barre d'URL ce qu'il pense être la meilleure solution. Comme ça tu as juste besoin d'appuyer sur « entrée » si tu es d'accord (mais ce qu'il ajoute est sélectionné donc si tu continues de taper ou si tu appuies sur ↓, tu remplaces ce qu'il a complété sans que ça te dérange).

Et il faut flash pour les lire en ligne…

Et il faut désactiver flashblock globalement parce qu'on ne peut pas activer juste le lecteur sur la page…

Et « tab » deux fois ?

Bin heuh, comment dire…

Dans le menu contextuel de la liste des calques et dans le menu « Calques », tu as : « fusionner vers le bas » et « fusionner les calques visibles ». Ça me parait plutôt clair pour fusionner des calques…

Le problème avec les numéros de version de FF, c'est que les extensions ne peuvent plus s'appuyer sur le numéro de version pour dire si elles sont compatibles. Mozilla aurait du choisir une numérotation à deux chiffres: majeur.mineur et n'incrémenter le majeur qu'en cas de perte de la compatibilité ascendante. Tel que c'est fait aujourd'hui, la moitié des extensions cessent d'être « compatibles » à chaque nouvelle version jusqu'à ce que leur développeur sorte une « mise à jour » juste pour changer les infos de compatibilité (l'autre moitié des extensions tombera en panne sans rien dire le jour ou une mise à jour de FF cassera la compatibilité ascendante).

Et oui, je sais qu'il existe des moyens de forcer la compatibilité des extensions, mais ça revient juste à mettre toutes les extensions dans le deuxième cas.