manawy a écrit 76 commentaires

L'avantage est que le plus souvent, le vice est poussé au maximum, et la boucle peut-être supprimé totalement :

Vector a, c;
Matrix b;
Vector d = a + b*c;

Si tu veux voir la différence, compare l'API d'Eigen (http://eigen.tuxfamily.org/dox/group__QuickRefPage.html) avec celle de BLAS (http://www.netlib.org/blas/blasqr.pdf). Les expressions templates permet d'adapter les calculs effectués au mieux.

Il y a plusieurs raisons (pas forcément excellentes ou bonnes, juste raisons…)

• Ce n'est pas un programme mais un ensemble de bibliothèques, dépendantes les unes des autres. J'ai en gros un test pour chaque unité logique. ('misc', base de données, solveur chimique, ….). Si je casse quelque chose dans une des bibliothèques, cela me permet de réparer les autres unes a unes. Si je n'avais qu'un seul test cela nécessiterait que tout compile avant que je puisse lancer les tests et vérifier que cela fonctionne comme je le veux.

• L'ensemble (bibliothèques, exécutables, exemples, tests) prend environ 5 minutes a compiler. Je ne suis pas a 10s prés (hourra pour la pause café…).

• Catch n'est pas ce qui prend le plus de temps a compiler…. J'utilise Eigen, et je rajoute une couche de templates… c'est pas toujours utile mais c'est marrant (example ). Le temps de compilation de ce genre de trucs est juste affreux, mais ça fonctionne plutôt bien.

• je suis un doctorant en science des matériaux, je n'ai jamais eu de "vrai" cours de programmation et je teste et réalise les choses au fur et a mesure… beaucoup de choses laissent a désirer j'en suis conscient, mais globalement ça marche et je ne sais pas forcement comment faire mieux. Je n'ai jamais trouve de ressources expliquant comment organiser son projet, je récupéré juste des idées ici ou la… Si vous avez des références, n’hésitez pas a me les faire connaître.

Je suis totalement d'accord. C'est bien mon point dans ce journal. J'ai découvert des features de CMake qui font ce que je faisais, mais bien mieux. Du coup hop, je change. Il y a moins de bidouille au final.

Mais j'ai toujours besoin de flexibilité. J'ai quelque besoin particulier. Par exemple, voici ce que j'utilise pour la pgo ou pour les tests. C'est rien de bien méchant. Mais pour pouvoir faire ça, cela veut aussi dire qu'on peut faire n'importe quoi. C'est au développeur de faire attention.

Ma source, c'est mon expérience, mais j'avoue qu'elle est minime.

C'est le docker file que j'ai utilisé pendant un moment. Si je ne forçais pas gcc-4.9 et g++-4.9 je me retrouvais avec un "vieux" gcc. (a noter que selon le commentaire plus haut, il ne devrait plus fonctionner…). Mais peut-être que c'est moi qui est mal compris comment cela fonctionne ? Ou ils ont mis a jour ce paquet ? Il y a toujours des bugs un peu étrange dans 4.7 et 4.8 (par example https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41933 )

1) Un système de build se doit être par définition très flexible, i.e. on peut faire n'importe quoi avec…. c'est pourquoi le packaging est une tache si difficile… L'idee de GNUInstallDIrs, c'est juste de fournir les noms standards, les exécutables vont dans bin, les libraries dans libxx, les données dans share. Avant je le faisait a la main, maintenant, j'ai un module qui le fait pour moi. C'est plus robuste et ça juste marche, c'est tout. Le fait que je puisse faire n'importe quoi serait vrai avec les autotools, SCons ou mon propre makefile.

Regarde juste ce commit. Pas de grosse différence. Mais la version utilisant GNUInstallDirs est juste plus simple et robuste. Un gnu, cela peut aussi servir parfois :)

2) Si c’était a ce point dépendant, je pense qu'il serait temps d’étriper une bonne dizaine de juristes en place publiques, juste pour l'exemple. C'est un système de building, il ne fait rien de plus qu'un shell pourrait. Une fois son travail terminée, c'est comme si il n'avait jamais existé. Si le système de build introduisait des dépendances fortes a son runtime dans les binaires qu'ils génère, ce serait un système complètement foireux.

Merci :)

Le "très mal documenté" est un euphémisme….

Le plus gros manque de la doc est la date d'apparition des nouvelles features, du coup je ne savais pas pour Debian.

C'est en effet dommage pour Debian stable, mais en même temps, c++11 sur debian stable c'est pas forcement le meilleur choix… Avant GCC 4.9 il y a toujours des petits ennuis. (Même si je me souviens que GCC 4.9.2 est installable sur debian stable, mais n'est pas le défaut).

Cela n'a aucune importance je dirais. Le "GNU" dans "GNUInstallDirs" veut dire que l'on va respecter les standards GNU. A mon avis c'est ce qu'autotools utilise aussi par defaut. Donc ça devrait marchait dans 99.99% des cas sur une plateforme POSIX. Pour windows chaque logiciel est installé dans son propre dossier, donc on peut choisir sa propre hiérarchie locale (? il me semble ?).
Et j'utilise une variable de cache, donc l'utilisateur mécontent, i.e. le packageur, peut indiquer ses propres chemins si il le souhaite.

Et on parle juste de ou mettre tout son bazar une fois la compilation terminée. Les licences n'ont absolument rien a voir dans tout ça.

GCC 5.1 supporte OpenMP4 qui apportes pas mal de nouveauté

Il y a aussi un support experimental de OpenACC, l'OpenMP pour GPU

Dans ce domaine, GCC à une longueur d'avance sur LLVM.

C'est avec l'attribut optimize

Vu la doc, je suppose que ça s'utilise comme ça :

int __attribute__ ((optimize(2))) my_func_optimized_at_level_2(int arg);
int __attribute__ ((optimize("O3"))) my_func_optimized_at_level_3(int arg);


Le type représente la sémantique des paramètres, et le compilateur vérifie cette sémantique !

c'est vrai pour du c, pas pour du python
En python la convention c'est le duck-typing, ou la sémantique c'est les attributs/méthodes offerts par la classe au moment de son utilisation.
Python est dynamique, le nombre de méthodes/d'attributs peut changer au cours de l'utilisation d'un objet (volontairement, ou non). C'est pourquoi si on veut vraiment être sur que tout se passe bien, il faut tester l'existence de la méthode/l'attribut au moment de son utilisation.

c'est ça la définition du duck-typing, c'est tès flexible, mais aussi très dangereux, et c'est à l'utilisateur de vérifier que ces types dérivées, ou crées de toutes pièces sont conformes aux attentes.

si ça ne te plait pas (et moi-même je vois quelques raisons pour quoi) et bien python n'est pas fait pour toi. Et ce type de librairie ne fera que rajouter des problèmes.

Je parle d'expérience, le duck-typing il faut l'embrasser complétement ou pas du tout. Sinon ça donne du code forcément bancal et vraiment dangereux (parce que plus personne ne sait son rôle et ce qu'il doit vérifier)

Et les problèmes sont mitigées par le fait qu'aucune erreur n'est silencieuse en Python et une erreur 'AttributeError' sera levé et remonté si l'attribut n'existe pas mais est quand même appelé, cela laisse une chance à l'utilisateur de traiter correctement le problème et/ou de corriger son code.

isinstance n'est pas la fonction qui devrait être utilisée pour ce genre de chose. Un problème immédiat est l'inhéritance

La méthode élégante et sûre et de tester l'existence de l'attribut/la méthode dont on a besoin avec la fonction hasattr .

En testant uniquement l'existence des méthodes que l'on utilise on autorise tous les types dérivées ainsi que les types crées de toutes pièces par l'utilisateur mais équivalent du point de vue de la fonction.

J'ai lu l'article en diagonale (comprendre j'ai regardé les dessins :))

Dans l'article tous les liens sont considérés égaux (i.e. toutes les contributions seront regardés de la même manières)
Mais dans un vrai projet, les choix politiques font que certaines contributions seront plus importantes que d'autres, et du coup favoriseront certaines personnes (et donc on s'éloignera encore plus de la méritocratie)

Cependant cette situation peut se modéliser par le nombre de noeuds sortant du "rockstar" (noeud emettant la contribution). Je n'ai pas suffisament de connaissances pour savoir si ce modèle représente vraiment ce qu'il est censé représenter. Mais il me semble que la conclusion est relativement intuitive, pour qu'un système soit méritocratique il faut que tout le monde ait une chance de contribuer de la même façon…

C'est une collaboration ESA-NASA

NASA provided three of the 16 instruments on board the Rosetta orbiter. The NASA instruments are: the Microwave Instrument for Rosetta Orbiter (MIRO); Alice, an ultraviolet spectrometer; and the Ion and Electron Sensor (IES), which is part of a suite of five instruments. For more information on the U.S. instruments aboard Rosetta, visit:

http://rosetta.jpl.nasa.gov/

Les gens de l'ESA sont désignés pas "Mission Control", mais ce ne sont pas juste les scientifiques européens ou états-unis qui profiteront des données, et de savoir que c'est possible de faire ce genre de chose.

L'intêret principal que j'y vois est l'interface unifié pour accéder aux différents protocoles. Un développeur d'application peut aller chercher toutes les informations relatives aux réseaux à un seul endroit, et n'a pas à faire 10000 tests pour être sur que 10000 utilitaires différents sont bien accessibles.

Par exemple si on doit faire une synchronisation avec un serveur distant, on peut vouloir vérifier que le réseau est bien disponible, que le proxy est correctement configuré, que la date/heure est correcte, que le dns est fonctionnel, … Pouvoir réaliser toute ces opérations avec une seule interface est relativement importante, et semble être le moteur principale de ces développements.

Une fois ces changements fait on pourra configurer NTP depuis NetworkManager, du point de vue utilisateur ça simplifie la vie (c'est sans doute possible dés maintenant de modifier NM pour configurer NTP, c'est juste beaucoup plus compliqué sans une interface unique). Cela risque d'imposer l'API de systemd dans beaucoup d'applications, mais c'est sans doute un mal pour un bien, l'année du desktop linux va bientôt arriver :) .

Mon expérience avec NFS et debian date de quelques années et il est bon de voir que les choses ce sont améliorées. Mais les choses en générales se compliquent lorsque l'on commence à mixer les distributions (surtout si on choisit stabilité (obsolescence) pour le serveur et cutting-edge pour les clients). Mais il y certainement du travail à faire du côté de Gentoo (ne serait-ce que sur la doc).

C'est vrai, j'ai galéré un peu avec NFS dernièrement. Le problème avec NFS vient du fait qu'ils existent plusieurs versions du serveur NFS et que chaque version à des dépendances un peu différentes…
Il semblerait que les dépendances systemd de Gentoo soit configuré pour être utiliser avec la version 3, mais que d'autres distribution, (par ex. Centos 7) utilise par défaut la version 4 (qui si elle est compilé dans Gentoo sera utilisé mais ne fonctionnera pas si les dépendances systemd ne sont pas correctement initialisées). Forcer l'utilisation de la version 3 met tout le monde d'accord (c'est la solution que j'ai adoptée)…
Le problème est un peu partagé entre systemd et le joyeux bordel qu'est NFS. Mais de mémoire, faire fonctionner NFSv4 a toujours été plus compliqué, même quand tout était mieux et plus simple…

Sinon, je tenais à remercier les personnes qui ont fini la dépêche ! Pris dans l'engrenage infernal d'autres projets, j'avais un peu oublié qu'elle était dans les tuyaux et je ne jetais un oeil à linuxfr qu'en diagonal. donc : Merci :)

http://ci.debian.net/#package/apt

Test direct calling is okay for apt-internal-solver … /tmp/adt-run.yIwZUA/apt0-build/apt-1.0.4/test/integration/test-external-dependency-solver-protocol: 108: /tmp/adt-run.yIwZUA/apt0-build/apt-1.0.4/test/integration/test-external-dependency-solver-protocol: /usr/bin/apt-internal-solver: not found
FAIL
Test for failure in execution of apt-get install --solver apt awesomecoolstuff:i386 -s … PASS
test-external-dependency-solver-protocol ... FAIL
Run Testcase (99/139) test-failing-maintainer-scripts
dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is not NFS-safe

bon… ça va je suppose…
Superbe idée mais maintenant il faut que les mainteneurs/développeurs jouent le jeu

j'ai jamais dis le contraire, j'ai juste dis que j'ai l'impression que pour les devs de systemd, être rapide c'est un gage de qualité.

C'est un esprit qu'on retrouve dans beaucoup d'écrits des devs de systemd pour le justifier :
1) il n'y a aucun mal a être rapide
2) c'est la preuve que le code s'adapte au-mieux à son environnement (d'où les features linux-only) et au hardware
3) c'est aussi la preuve que les features sont implémentés correctement, on perd pas son temps à faire des choses inutiles…

ça c'est leurs point de vue… c'est justifié sous certain aspect, un peu moins sous d'autre (quid de la sécurité)

Et si la rapidité était l'unique avantage de systemd alors oui, ils ne serait pas utilisé. Le fait est qu'il a beaucoup d'autre avantages (je ne ferais pas une n-ieme list ici).

(Pour info je n'utilise pas sytemd, je suis sous gentoo et perso je n'ai pas vraiment de préférence openrc/systemd, juste que le démarrage est effectivement lent sous openrc…)

En même temps, sysinit fait deux choses à la fois dans les scripts init; c'est à la fois des scripts de configuration et des exécutables.

Systemd respecte mieux "l'esprit unix" parce que les fichiers de configuration sont juste des fichiers de configuration.
Cela accroît la sécurité, la lisibilité, la robustesse de l'ensemble, …

je pense que l'idée principale est que les devs de systemd assument que si on fait les choses correctement alors le système est rapide.
Et donc la rapidité de systemd est juste une preuve que toutes les features sont implémentées correctement.

Après est-ce que cette hypothèse est vrai ou pas… de plus "rapidité" c'est tellement large.
C'est sans doute vrai dans la mesure où, si l'on est rapide, on a utiliser au mieux les ressources du système.
Et tout dépend de la définition de "faire les choses correctement" (par exemple comment définit-on le compromis robustesse-sécurité-rapidité-…)

Une implémentation de référence, c'est bien quand ça suit exactement la norme et quand ça n'expose aucun particularité.

ben python n'est pas défini par ses extensions… c'est un peu la définition d'une extension
Python est défini par la grammaire et la bibliothèque standard. N'importe quelle implémentation doit juste implémenter ça, et cela peut-être fait indépendamment du GC ou autre choix. (C'est peut-être juste plus facile

Après, ils s'est avéré que la bibliothèque standard n'était pas suffisant pour certains cas. Une des extensions la plus connus est sans doute numpy pour le calcul scientifique. Cela ne fait pas partie de la bibliothèque standard et les auteurs du projet ont choisi une approche implémentation dépendante, pour être efficace. Du coup les autres implémentations se trouvent défavorisés… Mais ce n'est pas la bibliothèque standard, ni la grammaire du langage donc ça ne fait pas partie du langage vraiment, c'est juste extrêmement dommage de ne pas pouvoir l'utiliser.

La solution serait d'inclure ces extensions dans la bibliothèque standard; mais ça risque de faire un énorme travail pour les implémentations alternatives…
L'autre solution étant d'utiliser les couches intermédiaires, comme expliquer dans les commentaires, mais cela suppose de changer la base de code existante… et vu la rapidité du passage à Python 3 (pourquoi Pyston ne commence pas directement par là ?) ben ça ne risque pas d'arriver bientôt…

En gros c'est bien dommage, mais c'est un peu difficile de changer les choses. Néanmoins, c'est un problème que les devs python ont l'air d'avoir bien en-tête et la situation va peut-être se décanter petit à petit.
Cela se passe déjà par un effort d'homogéneisation des extensions (voir les modules cffi et autres ou par exemple la PEP 465 sur un opérateur dédié pour la multiplication de matrix)

En générale, les modules d'extension ne sont pas écrits en C juste pour le plaisir mais bien pour contourner les limitations de python (en général pour être plus efficace). Donc la non-portabilité est en général plus une feature qu'un bug. Les extensions exploitent directement les caractéristiques de l'implémentation (comme le comptage de référence à la main). C'est notamment pour simplifier l'écriture de ces extensions que des langages comme cython ont été inventés.

Pour avoir des extensions portables, il faudrait aussi fixer les méchanismes internes de l'implémentation, ce qui a mon avis réduit l'intérêt d'avoir plusieurs implémentation.

Sinon, une autre implémentation non citée par la dépêche : Pynie une implémentation pour Parrot

pour moi la condition de dépendance suivante était implicite :

exactly-one-of (gentoo ? "je n'ai aucune idée du système utilisé" ?)

ma remarque, était que sur beaucoup de distribution, PA est installé par défaut, et quand le travail d'intégration est bien fait, ça juste marche pour 99.9999% des usages. Sans que personne n'est besoin de se soucier de quoique ce soit.

ben ça, ça s'appelle pulseaudio, quoiqu'on en dise :)