Shuba a écrit 439 commentaires

Le rentier, il donne trois mois de préavis à son locataire, il met son fils/son copain/lui-même dans l'appart 5 minutes et il reloue au prix qui prend en compte l'inflation dans 6 mois

Je suis curieux de savoir où tu vois qu'il faut trois mois de préavis. Les textes c'est 6 mois. C'est le locataire qui a un préavis de 3 mois. De plus si l'ex-locataire fait constater que la personne occupant les lieux n'est pas le proche du propriétaire mentionné dans la lettre de préavis, il peut se retourner contre le propriétaire et réclamer des dommages et intérêts.

X utilise evdev pour l'input, et wayland fera de même. Donc si la tablette est supportée par evdev ça devrait être bon.

Ah c'est très intéressant cette approche paresseuse en effet.

j’utilise pas mal Haskell pour faire du calcul multi-dimensionnel sur des données volumineuses

Le truc qui me fait peur avec un langage qui gère automatiquement la mémoire c'est la tendance à créer des intermédiaires pour les calculs sans qu'on puisse l'empêcher. Et ça peut vraiment faire la différence en termes de performances, en tout cas c'est ce que j'observe entre faire du python/numpy et du C++.

Donc je me demandais si haskell permettait d'avoir le contrôle là dessus si désiré?

l'étudiant était certain de ne jamais réutiliser le langage appris

Honnêtement, on s'en fiche! Un élève qui sort de prépa n'arrive pas directement sur le marché du travail, il arrive en école d'ingé ou à l'université, et s'il avait choisi l'option MP-Info il est probable qu'il continue à faire de l'informatique. Ce sera dans un langage différent, mais c'est tant mieux, ça permet d'appréhender le fait qu'il n'y a pas qu'un seul paradigme de programmation. Ça permet aussi de ne pas considérer les idiosyncrasies du langage qu'on a appris comme étant un comportement normal.

même ceux qui ont fait l'X peuvent rembourser l'état quand ils vont dans le privé ou à l'étranger (oui, ils "doivent" 10 ans à l'état pour leurs études, peu sont vraiment gênés)

Ce n'est pas tout à fait exact, en tout cas ça ne l'est plus depuis les années 2000, seuls ceux qui font des corps de l'état doivent rembourser les frais de scolarité s'ils démissionnent du corps. Pour les autres, plus rien à rembourser (pour être précis, la solde perçue au cours des études a été réduite pour compenser).

Cependant il semblerait que le remboursement pour ceux qui ne travailleront pas pour l'état reviendra bientôt.

Ça doit venir de l'interprétation des liens Wikipédia qui fait pointer vers le Wikipédia français.
Ça marchait il y a quelques jours, c'est peut-être un bug du site.

Quand je vois des performances pareilles pour très peu d'intervention manuelle, je dis bravo, surtout par rapport à cython qui nécessite de typer à peu près tout et donc de casser la compatibilité source.

Tu dis que le support de numpy est loin d'être total, que manque-t-il actuellement?

Tu vas pas y arriver pour toutes les suites, parce qu'il existe des suites de bits aléatoires au sens de Levin-Chaitin pour lesquelles la complexité de Kolmogorov des n premiers termes de la suite moins n tend vers l'infini. La complexité de Kolmogorov d'une chaine c'est la taille de la plus petite description algorithmique de la chaine. Je pense qu'en fixant à un algo particulier on arrive à trouver une séquence qui n'est pas compressée strictement.

C'est pas "strictement".
De plus pour détecter dans ton algo de décompression les cas où tu n'as pas compressé, tu dois utiliser un bit au moins. Donc tu as un output de n+1.

Faut dire que je m'étais déjà pris la tête avec quand il nous avait certifié que la compression sans-perte n'existait pas.

Peut-être qu'il voulait dire qu'il n'existe pas d'algorithme de compression sans perte qui fasse effectivement une réduction de taille stricte quel que soit l'input?

Parce que ça ça se démontre : considère tous les inputs possibles de taille n ou moins. Si un tel algo existait, ça impliquerait une bijection d'un ensemble de cardinal 2ⁿ dans un ensemble de cardinal 2^n-1, ce qui n'est pas possible.

Donc tu ne peux pas avoir un algorithme lossless qui arrive à effectivement compresser tous les inputs.

Après on peut par contre faire des algos lossless qui pour tout input de longueur au plus n, te fournissent un input de longeur au plus n+k pour k>0 donné à l'avance, et donc cet algo compressera effectivement quasiment tous les input.

Asm.js est performant, partout, tout le temps, qu'il vente, qu'il pleuve ou qu'il neige.

D'un point de vue CPU peut-être, mais est-ce que ça n'implique pas des temps de chargement des pages plus longs pour cause de code javascript plus volumineux (a priori faut plus de code pour exprimer la même chose en prenant un langage de moins haut niveau)?

C'est plus ou moins ce qu'essaye de faire google avec son native client dans chrome.

Donc oui, le Javascript, le language, est extrêmement performant

Faut pas exagérer, ok le JIT permet d'avoir des perfs correctes, mais le langage en lui même ne permet pas le même genre de performances qu'en C, intrinsèquement, simplement parce qu'il n'expose pas assez l'allocation mémoire. L'un des dev de pypy explique cela assez bien.

Justement, non, la gestion de la memoire d'ios est basee autour du concept de "libere les vues qui ne sont pas a l'écran pour liberer de la RAM".

Effectivement c'est problématique, j'avais oublié que les mobiles avaient des low memory killer..

Apres, ya moyen de faire un rendu initialement, au moment de l'installation et de cacher ca sur le disque.

Ça c'est peut-être le mieux à faire

devoir descendre dans le GPU et le reveiller pour le mettre en mode "mouline comme un bourrin"

Le rendu svg sur GPU est pas vraiment bourrin, t'as un faible nombre de triangles à envoyer (proportionnel au nombre de points de contrôle), pas de vertex shader, et un fragment shader qui comporte grosso modo 5 instructions. Par contre réveiller le GPU c'est peut-être couteux, donc peut-être problématique.

Bref comme tu dis ça se discute, je pense qu'il faudrait vraiment voir des benchmarks pour savoir. C'est d'ailleurs peut-être ce que les ingés d'Apple ont fait.

D'autre part, on parle du rendu de la "page d'accueil" de l'iphone, en terme de perf (comprendre consommation batterie), c'est assez critique, et je serais pas surpris que ca soit prohibitif

De la même manière que le rendu de la page d'accueil ne passe pas son temps à aller lire les fichiers des icônes, il n'y a pas de raison pour que des icônes vectorielles ne soient pas rendues une fois pour toute à la bonne résolution, et on aurait ensuite le même type de performance.

Si ce rendu initial semble prohibitif (ça augmenterait le temps de démarrage par exemple), on trouve maintenant des algos de rendus vectoriel qui tournent essentiellement sur GPU et sont très rapides.

Je ne comprend pas du tout ce que tu racontes sur le fait que que OpenCL permet d'optimiser les transformée de fourier contrairement à pthreads ou openMP.
OpenCL n'a rien de magique. Tout ce que tu peux faire avec OpenCL peut être fait avec n'importe quel api à base de thread sur CPU (TBB, openMP, pthread).

Souvent les GPUs exposent des instructions hardware permettant d'optimiser les rendus graphiques, il est peut-être possible d'en tirer parti pour faire une transformée de Fourier accélérée. Après je connais pas assez quelles instructions hardware sont disponibles pour pouvoir dire si c'est effectivement le cas, mais en tout cas on peut faire des choses différemment sur le GPU.

Et tout ce que tu peux faire sur GPU se fait avec une autre API comme OpenGL ou DirectX. C'est juste une façon de programmer différente.

C'est sûr, mais pour y avoir goûté ça pique vraiment, donc ça se comprend qu'on ait envie d'avoir un driver OpenCL plutôt que de devoir jouer avec des framebuffer objects, des textures, du glsl…

Le monstre poilu? C'était un de mes livres préférés quand j'étais petit, et je n'y avais effectivement jamais vu la moindre allusion…

pas de qmake

Déja c'est pas qmake le préprocesseur de Qt, c'est moc. qmake est un système de build, qui a l'intérêt d'être assez simple pour de petits projets, mais qui n'est pas super drôle à utiliser pour de plus gros projets. Et surtout, il permet d'appeler moc tout seul.

API C

Certainement un très bon point pour GTK+, même si Qt fait pas mal de choses pour garder une ABI la plus stable possible (idiome PIMPL, plus sans doute d'autres astuces que je ne prétends pas connaitre).

Après la popularité de Qt fait qu'il a des bindings dans de très nombreux languages, ce qui réduit le désavantage versus l'API C de GTK+. Cependant il est sûr que sur des langages de niche on trouvera plus souvent GTK+

Probablement pas, parce qu'un quick tiling est a priori beaucoup plus simple à implémenter, il suffit juste de changer les dimensions d'une fenêtre, sans prêter d'attention aux autres. Dans le cas d'un gestionnaire pavant a contrario, il faut calculer un pavage prenant en compte toutes les fenêtres à afficher, avec des contraintes à prendre en compte… Bref c'est sans doute uniquement ça qui disparaît.

Dans la vidéo, lorsqu'il parle de cron, Lennart précise bien qu'il considère qu'il n'est pas entièrement rendu obsolète par systemd. systemd serait plus expressif et plus simple, mais cron garde l'avantage de permettre un crontab par utilisateur.

Quoiqu'un effet de feu doit être assez compliqué!

Une des manières de faire un effet de feu peut-être en utilisant de la génération procédurale. Dans mes souvenirs, tu pars d'une fractale bien choisie, avec de la randomisation pour ne pas obtenir quelque chose d'uniforme, et tu te sers des valeurs de cette fractale pour contrôler une densité de points et la couleur de ces points, et en jouant sur les paramètres tu peux obtenir quelque chose de joli. Il existe des livres listant quel type de fractale convient à quel effet.

Voilà ça c'est la théorie, du moins ce dont je me souviens de mes cours, après pour l'implémentation ce serait une autre histoire.

Pour l'utilisation de QML avec C++ il y a ça par exemple :

• http://doc-snapshot.qt-project.org/4.8/qtbinding.html
• http://qt-project.org/doc/qt-4.8/src-imports-folderlistmodel.html

Moi j'aurais peur de faire bruler le papier avec ça. Bon c'est sûrement irrationnel..

Les chinois sont plus doués que les bots pour résoudre les captchas.