One of my favourite graphs of all time.
— Top Hat Developer (@indiealexh) August 26, 2016
Swear words per language subreddit. pic.twitter.com/4Vjbt5D3Nw
Kevin Kofler (./1946) :On va dire une dizaine.
Il y a aussi des commentaires formulés différemment, par exemple:
# WARNING: Do not start the trap code with a newline, due to a FreeBSD 4.0 bug.
CMake est en C++, pas en Python.Je sais
sma() Done
Déjà, comme il n'y a pas de macro standard pour trouver les kdelibs avec les autotools (normal, les autotools sont dépréciés dans KDE depuis des années, il faut utiliser CMake), les projets ont tous leurs propres bidouilles, et la plupart ne prend aucune option. Et ensuite, passer une telle option à chaque configure nécessiterait quand-même de modifier tous les specfiles; avec CMake, c'est un seul (le paquetage qui contient FindKDE4Internal.cmake, installé dans le système).Donc si on a installé un autre ensemble de libs KDE4 dans le système, et qu'on veut les utiliser, çà à l'air bien sympa de les utiliser avec CMake.
Certains paquetages utilisent effectivement ça (c'est la solution la plus propre), mais ça a d'autres inconvénients (par exemple, le risque de se taper une incompatibilité entre versions), et donc certains packagers préfèrent utiliser des workarounds beaucoup plus sales dans leurs paquetages.Le risque est normalement mineur.
Et puis, à quoi bon livrer les fichiers prégénérés si on doit de toute façon les regénérer?C'est dans le cas où le libtool livré est trop vieux... et pour les packageurs...
Le bordel infâme que génère automake n'est pas mieux.J'arrive à les comprendre et à les hacker pour faire ce que je veux, au moins.
Sauf s'il doit regénérer les fichiers, soit pour corriger un bogue des générateurs (ou des fichiers copiés tels quels) (comme le cas de libtool ci-dessus), soit parce qu'il veut exercer son droit de modification sur le logiciel libre.Et bien il le fait. Cela ne pose en général vraiment pas de problème sauf si on a pas installé les autotools.
Tu peux redéfinir pratiquement tous les chemins détectés par Find*.cmake si ceux qu'il te trouve ne te conviennent pas.Sûrement.
Folco (./1961) :Il est évident que modifier des champs techniques comme cela, c'est pas une bonne idée et ça n'a pas le moindre intérêt pratique. Persone n'utiliserait ça dans un vrai programme.
C'est dingue d'avoir des programmes comme ça. A plusieurs niveaux je trouve, fiabilité, maintenabilité, réutilisabilité, mais même au niveau des contributions dans un projet, trois lignes à la con qqpart et tout part en vrille. M'enfin, si "c'est bien", c'est que je dois pas comprendre les choses...
PpHd (./1963) :C'est un des fâcheuses conséquences de l'auto-boxing qui permet de convertir automatiquement les types primitif (byte,short, int, ...) dans leur représentation équivalente sous forme d'objet (Byte,Short, Integer, ...). Pour éviter de ré-allouer systématiquement un objet pour chaque nombre, les objets correspondant aux nombres de -128 à 127 sont mis en cache.
Déjà je ne comprends pas pourquoi java fournit un cache pour les entiers ?
joe@nuc:~$ python Python 2.7.5+ (default, Sep 17 2013, 15:31:50) [GCC 4.8.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> >>> def deref(addr, typ): ... return ctypes.cast(addr, ctypes.POINTER(typ)) ... >>> deref(id(4), ctypes.c_int)[4] = 5 >>> 2+2 5 >>> exit()
Uther (./1968) :Le tout parce que le Java n'a pas de vrai type Variant (genre QVariant, mais même le vieux VB avec tous ses défauts avait un type Variant!) et abuse du type Object pour tout. Le tout encore empiré par l'absence de génériques type-safe (ce qui fait qu'on se trimballe des Object de partout en interne au lieu d'avoir du code automatiquement optimisé pour les types primitifs).PpHd (./1963) :C'est un des faucheuses conséquences de l'auto-boxing qui permet de convertir automatiquement les types primitif (byte,short, int, ...) dans leur représentation équivalente sous forme d'objet (Byte,Short, Integer, ...). Pour éviter de ré-allouer systématiquement un objet pour chaque nombre, les objets correspondant aux nombres de -128 à 127 sont mis en cache.
Déjà je ne comprends pas pourquoi java fournit un cache pour les entiers ?
squalyl (./1969) :joe@nuc:~$ python Python 2.7.5+ (default, Sep 17 2013, 15:31:50) [GCC 4.8.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> >>> def deref(addr, typ): ... return ctypes.cast(addr, ctypes.POINTER(typ)) ... >>> deref(id(4), ctypes.c_int)[4] = 5 >>> 2+2 5 >>> exit()
bon, hein, pouet-pouet...
et on peut écrire bien d'autres horreurs...
https://www.reddit.com/r/Python/comments/2441cv/can_you_change_the_value_of_1/
Kevin Kofler (./1970) :Alors autant le fait qu'il n'y ait pas de génériques forts est un soucis, autant je suis très content que Java n'ait pas de Variant à la VB, c'est une saloperie dont je me passe très bien.
Le tout parce que le Java n'a pas de vrai type Variant (genre QVariant, mais même le vieux VB avec tous ses défauts avait un type Variant!) et abuse du type Object pour tout. Le tout encore empiré par l'absence de génériques type-safe (ce qui fait qu'on se trimballe des Object de partout en interne au lieu d'avoir du code automatiquement optimisé pour les types primitifs).
Folco (./1974) :Le problème du VB est surtout que, pour permettre aux programmeurs paresseux de ne pas déclarer leurs variables, tout est Variant par défaut, ce qui donne du code qui marche, mais rame à fond.
Un Variant, c'est en général un void*, et le type exact est même vérifiable à la compilation, du moins avec Qt. Je ne vois pas ce qu'il y a de si dégueulasse là-dedans
Folco (./1974) :Je parlais du variant VB.
Un Variant, c'est en général un void*, et le type exact est même vérifiable à la compilation, du moins avec Qt. Je ne vois pas ce qu'il y a de si dégueulasse là-dedans
