Antoine a écrit 5722 commentaires

Pour mieux comprendre le phénomène je conseille à tes lecteurs le livre de Jeremy Rifkin Zéro marginal cost society

Le bouquin de Rifkin est proprement démonté ici :
http://michelvolle.blogspot.fr/2014/09/jeremy-rifkin-zero-marginal-cost.html

Par contre là c'est juste une critique du genre « J'aime pas ton style, c'est moche. »

Dans chaque langage il existe des usages et des bonnes pratiques. Les ignorer en prétextant que c'est juste une question de goût et que chacun fait bien ce qu'il veut, c'est infantile.

En fait ce qui serait bien c'est que tu argumentes précisément sur le fond de l'article au lieu d'en reste à quelques généralités dignes d'un Zenitram.

C'est quoi le problème ?
http://www.larousse.fr/dictionnaires/francais/compr%C3%A9hensibilit%C3%A9/17769

"""compréhensibilité

nom féminin

Qualité de ce qui est compréhensible.

"""

Donc sans même entrer dans les détails technique, un économiste qui te dit ce qui va se passer dans les années à venir si l'on fait tel ou tel chose est soit un menteur, soit il se prend un peu pour Dieu.

Bizarrement la planification a plutôt bien marché dans les trente glorieuses.

Le code n'est pas seulement "moche", il pose de vrais problèmes de lisibilité et de compréhensibilité. Va lire le lien en question au lieu parler dans le vide :
http://blog.erratasec.com/2014/09/the-shockingly-bad-code-of-bash.html

Faux: les artistes disent produire du sens. Mais souvent ça n'a aucun sens, et c'est juste de la branlette.
Il y a aussi beaucoup de personnes qui se disent artistes mais ne sont pas plus artistes qu'un gamain de 2 ans.

Conclusion : Zenitram est un artiste (et le post auquel je réponds le prouve).

Oh, non. Pour de l'émotion, un chaton qui meurt sous tes yeux suffit largement.

à quoi ça sert exactement de le critiquer quand il fait un journal qui n'a rien à voir avec Suse

À rigoler un coup, peut-être ?

Il y a plein d'aspects à considérer quand on veut faire des paquets de qualité et c'est un concept subjectif.

Tu as donné plein de critères au-dessus qui montrent que la qualité n'est pas un concept subjectif :-) Il est à géométrie variable, ce qui est légèrement différent.

Techniquement, les paquets sont vérifiés à l'empaquetage et à l'installation (liens symboliques, emplacements, santé des binaires) puis tout le système hôte est scanné pour s'assurer qu'aucun binaire n'est cassé (auquel cas le serveur ordonne la recompilation de chaque paquet concerné), les fichiers de configuration sont préservés, les permissions sur les fichiers services également, un mécanisme reposant sur Busybox permet de prévenir tout cassage sur les paquets critiques (comme glibc, bash ou coreutils) et une documentation sur la santé de chaque paquet (logs de construction, paquets en dépendances, liste des libs partagées) est intégrée à la doc de chaque paquet.

Ok, donc à part les paquets critiques, c'est une vision statique de la qualité basée sur la présence des artefacts d'installation, grosso modo. Après j'imagine que vous avez tellement peu d'utilisateurs que vous recevez rarement des retours sur le fonctionnement réel des logiciels installés.

Je cite :

plus de 1400 paquets
4 personnes contribuent régulièrement au projet (en code ou en hébergement/ressources)

Je me demande quel niveau de qualité est atteint quand 1400 paquets sont maintenus par 4 personnes.

L'intérêt du shell c'est :

J'ajouterais un quatrième point : des implémentations simples et sécurisées.

Parce que Linux est user-friendly.
GNU/Linux, pardon.

C'est quoi cette nouvelle mode de nous servir du Guy Fawkes à toutes les sauces ?

Surtout que ce n'est pas très fin comme méthode de déverminage :

Le complot, imaginé par Robert Catesby, fut une tentative infructueuse de la part d'un groupe de catholiques anglais de tuer Jacques Ier d'Angleterre, sa famille et la plupart des membres de l'aristocratie d'un seul coup, en faisant exploser le bâtiment de la Chambre des Lords (démoli pendant la Seconde Guerre mondiale) au Palais de Westminster pendant la session d'ouverture du Parlement.

(https://fr.wikipedia.org/wiki/Guy_Fawkes)

Plus généralement, le problème que tu pointes n'a encore ici que peu à voir avec Unicode, mais plus avec le support de l'encodage en général

Ben non, raté. Je cite le message auquel tu réponds :

« La commande iconv sert à faire de la transcription tandis qu'une bibliothèque Unicode permet de: [etc.] »

Le consortium Unicode a normalisé les classes de caractères dans les expressions régulières :
http://www.unicode.org/reports/tr18/#Compatibility_Properties

La gestion de l'unicode dans les expressions régulières ne se limite pas aux caractères litéraux, mais impacte les métacaractères type \w.

En effet, c'est mon cas.

ça veut dire que vous « comprenez » l'API de ctypes et que vous arrivez à linker avec la lib native directement ?

Oui. Enfin, on la charge à l'exécution, mais on enlève toute l'intermédiation entre la lib native et CPython.

En approche statique, il y a l'ineffable pythran qui tient la dragée haute à Numba, même s'il ne propose pas de mode dégradé et ne propose pas de backend CUDA. Et l'approche statique est plus lourde à mettre en œuvre qu'un décorateur.

Est-ce que tu as comparé avec Cython (qui a, je crois, un système de typage statique) ?

Son très sympathique et très modeste auteur a fait une présentation généraliste et passera bientôt à Paris !

J'essaierai de faire un tour :)

Personnellement je ne vois pas trop le rapport entre nombre de lignes de code et qualité. Note que Django a son propre ORM, il n'utilise pas SQLAlchemy comme tu sembles le penser. Ensuite, à lire le code d'Odoo son ORM ne fonctionne qu'avec PostgreSQL alors que celui de Django est multi-SGBD. Enfin bref, je suis sûr qu'il y a plein d'exemples où Django fournit plus de fonctionnalités.

Par ailleurs, dans le code il y a aussi les tests. Le ratio lignes de test sur lignes de code (total) peut être une métrique intéressante.

Si Google a toujours un contrat commercial avec Mozilla, c'est parce que d'autres aimeraient bien être à sa place, et seraient prêt à payer beaucoup plus.

Ce n'est pas très logique. Si d'autres seraient prêts à payer beaucoup plus, pourquoi Mozilla reste-t-il donc avec Google ?

Oups ! Je n'avais pas les yeux en face des trous, on dirait, et j'ai écrit "Numba 1.4" dans la dépêche alors que c'est la version 0.14 qui est sortie. Est-ce qu'on modérateur aurait l'amabilité de corriger ?

Merci d'avance !

Si vous voulez vous faire une idée, voilà ce qu'on fait pour les écoles: https://www.ryxeo.com/la-suite-logicielle-abuledu/,

Rien à voir avec Qt mais… ce serait bien de ne pas infliger aux enfants un français massacré.

"Choisis un module en cliquant sur la box du parchemin, les flèches deviendront alors actives pour les exercices proposés". Quel charabia ! À ce niveau, ce serait plus clair en ne donnant aucune indication…

AMHA, cela n'a pas vocation à être intégré, sauf à très long terme. Il y a plusieurs raisons :

• spécialisation dans le calcul scientifique
• changements délibérés de sémantique dans les fonctions compilées
• dépendance à LLVM

J'ai réécrit un peu ta fonction :

def np_mandelbrot(width, height):
    x_min, x_max = -2.0, 1.0
    y_min, y_max = -1.0, 1.0
    stepx = (x_max - x_min) / (width - 1)
    stepy = (y_max - y_min) / (height - 1)
    c = numpy.fromfunction(lambda x,y:
                           (x_min + x * stepx) + (y_min + y * stepy) *1j,
                           (width, height))
    arr = numpy.zeros((width, height), dtype=complex)
    max_iters = 20

    for i in range(max_iters):
        arr = arr**2 + c
    return abs(arr) <= 2

Au final elle reste trois fois plus lente :

>>> timeit.timeit("opt(200, 200)", setup="from __main__ import opt", number=1)
0.0033650129998932243
>>> timeit.timeit("mandel.np_mandelbrot(200, 200)", setup="import mandel", number=1)
0.009533904999443621

NumPy en soi est très rapide, mais faire des calculs matriciels t'empêche de sortir de la boucle plus tôt quand un point donné diverge rapidement. D'ailleurs ça diverge parfois tellement qu'il y a des dépassements de flottants (!) :

/home/antoine/numba/mandel.py:39: RuntimeWarning: overflow encountered in square
/home/antoine/numba/mandel.py:39: RuntimeWarning: invalid value encountered in square
/home/antoine/numba/mandel.py:40: RuntimeWarning: invalid value encountered in less_equal

Par ailleurs, si tu augmentes la taille du résultat souhaité, l'écart s'élargit (peut-être à cause des caches CPU qui deviennent moins efficaces pour la version matricielle) :

>>> timeit.timeit("opt(2000, 2000)", setup="from __main__ import opt", number=1)
0.15761542599921086
>>> timeit.timeit("mandel.np_mandelbrot(2000, 2000)", setup="import mandel", number=1)
1.2320581470003162

Note : on peut faire une version NumPy qui fasse les calculs sur place (sans créer de tableaux intermédiaires). La fin de la fonction s'écrit alors :

[...]
    for i in range(max_iters):
        numpy.multiply(arr, arr, out=arr)
        numpy.add(arr, c, out=arr)
    numpy.abs(arr, out=arr)
    return arr <= 2

Elle réduit un peu l'écart :

>>> timeit.timeit("opt(2000, 2000)", setup="from __main__ import opt", number=1)
0.15364889400007087
>>> timeit.timeit("mandel.np_mandelbrot(2000, 2000)", setup="import mandel", number=1)
0.6474335490001977