zul a écrit 443 commentaires

Par exemple, j'aimerais bien avoir des onglets dans gvim ou vim, quand j'ai plusieurs fichiers ouverts. Je crois que c'est possible, j'ai essayé une fois sans succès et ça m'a jamais assez manqué pour que j'insiste. Si c'était pas défaut, je m'en servirais.

vim -p list_fichier

:help tabpage

De rien :).

Je ne vois pas en quoi ça change le fait que le programme

None = 0

est valide en python 2.2 et est invalide en python 2.7.

Je n'ai jamais écrit de code en Python 2.2.

Ça ne me choque pas de définir une constante None à 0, et d'utiliser cette constante symbolique plutôt qu'un entier. C'est exactement ce qu'on fait avec NULL.

raise "foo" est valide jusqu'à 2.6 et renvoie un TypeError depuis 2.6. Je ne vais sérieusement pas énuméré tous les "Porting your code to Python 2.x" de la documentation pour prouver que l'assertion "Un script qui fonctionne avec Python 2.2 fonctionnera avec Python 2.7" est fausse. Un contre-exemple suffit.

Python 2 est globalement rétrocompatible.

Globalement, globalement:) Lua est globalement compatible à quelques exceptions près :).

Je maintiens un programme qui tourne sur Python 2.5 à 3.4 toutes versions comprises, avec une seule base de code.

Je ne dis pas que c'est impossible.
Juste le traitement des u"foo" est chiant, vu que c'est valide en 2.{5, 6, 7}, 3.{3, 4}, mais pas en 3.{0, 1, 2}. Mais on peut toujours se débrouiller.
Le nom des imports change, mais on peut se débrouiller aussi (avec des raise / except).
Il ne faut juste pas dire que c'est "out of the box", je ne fais pas attention, et ça marche parfaitement entre 2.5 et 3.4. Là, personnellement, je n'y crois pas.

Je n'en suis pas si sûr. Un script qui fonctionne avec Python 2.2 fonctionnera avec Python 2.7, même si l'inverse n'est pas forcément vrai.

J'aimerai bien voir ça quand même :) J'ai jeté un coup d'oeil aux changelog entre 2.2 et 2.7, et il y'a peut être des programmes avec la même sémantique, mais je suis quasiment sûr qu'il y'en a un paquet d'autres qui ne vont pas du tout fonctionner. Par exemple, None et yield sont des noms de variable valide en Python 2.2.

Bien sûr, on ne parle évidemment pas de Python 3.x, on serait méchant :).

le paradigme de programmation est plutôt original par rapport à ce qu'on connait: pas de classes mais une émulation complexe est possible mais va vite être potentiellement foireuse*

Pas de classes, je suis d'accord. Mais l'émulation ne me semble pas tellement complexe, voir même plutôt relativement simple et claire (et pas de "magie" justement).

pas de compatibilité assurée entre les différentes versions de lua. Et ça, ça fait mal. Il n'est même pas possible d'écrire un programme qui soit à la fois compatible entre lua 5.0 5.1 et 5.2 . Les syntaxes diffèrent de manière incompatibles…

La numérotation Lua est étrange. Si on regarder l'historique:
- 5.0 : 2003
- 5.1 : 2006
- 5.2 : 2011

En référence à ces valeurs, je ne suis pas sûr que lua s'en tire plus mal que d'autres. (2003, c'est Python 2.2 par exemple).

Pour la partie graphique, ils re-développent^Wfactorisent vim en C++ pour prendre en compte Qt ?

Non. Il propose de définir une interface entre "vim-core" et les plugins / gui, en json-rpc / msgpack-rpc. Evidemment, on peut toujours critiquer le fait qu'il n'est fait que dessiner à gros trait et n'a pas explicité cette interface, ni evalué le surcoût par rapport à un lien plus direct.

Ça coute vraiment si cher de lire les liens avant de commenter ? :D

Notons cette année que OpenBSD a décidé de participer au GSoC. Theo se fait vieux. Par contre, NetBSD et DragonFly se sont fait jeter. Tant pis!

En plus, ils s'y connaissent en non-respect de la vie privée chez Google :D

Est-ce vraiment plus clair / extensible que l'utilisation de goto ?

Une solution en C :D (je veux dire standard et portable). À défault, une solution portable (multi-architectures) et compilable avec les deux gros compilos C (gcc et clang) donc (étant donné qu'ils utilisent déjà un paquet d'extension, je pense que C standard c'est mort).

Comme indiqué dans le bug report, il y'a des solutions alternatives. Ils ont préféré travailler un peu moins et casser le truc pour différentes architectures. C'est leur choix. Qu'ils assument (surtout le vendredi!).

http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html /ifunc

De rien. Et je suppose que arm n'est pas la seule victime, même si c'est la plus grosse plateforme impactée.
(On s'en fout des autres plateformes de toute façon).

Ça ne doit pas compiler avec clang non plus (mais on s'en fout de clang aussi de toute façon je suppose aussi)

Il est fort ce GMail ! Il dit quoi à propos de ma timezone ? :D Je suppose que ça ne marche qu'avec ta liste de contact qui eux même utilisent les services Google et/ou qui sont loggués via un Google ID.

Le support des tags pour mutt, c'est via notmuch déjà évoqué plus haut dans ce thread. Il y'a plusieurs approches pour l'intégrer dans mutt (mutt-notmuch, notmuch-fs ou mutt-kz) donc l'interface peut varier. Mais notmuch-query permet de faire des requêtes "complexes". Après, ce sont des extensions que je n'utilise pas donc je ne suis pas expert sur la question, j'avais juste testé rapidement. Un tri un peu intelligent à la source (via procmail / imapfilter) et les filtres mutt me suffisent largement.

Évidemment, il y'a le mot "GMail" dans le fil, mais le sujet c'est OpenSMTPD, la partie qui envoie des mails. Encore la partie IMAP, une question sur "des tags" gérés côté serveur aurait pu avoir un certain sens. Si un fil évoque le mot "Windows" dans un sujet sur le noyau Linux, pense-tu vraiment que le sujet principal est Windows, un système d'exploitation quoi :D

mutt fait ça très bien (à par pour le téléphone mais bon, on peut s'en douter, c'est un client mail :D).
Pour savoir si tu peux téléphoner, essaye date(1) avec la variable TZ qui va bien :). Tu peux même faire un alias dans ton shell préféré.

Sérieusement, la dépêche parle d'un serveur smtp, c'est complètement HS de parler du front-end de la mort qui tue :).

Scélérat, tu ose pointer le fait que peut-être que systemd est vachement complexe et qu'il y'a peut-être même des bugs :). C'est interdit ici, c'est un délit de lèse-majesté vis à vis de Seigneur Lénart :) Amen!

Not invented here (NIH) is the philosophy of social, corporate, or institutional cultures that avoid using or buying already existing products

upstart me semble largement précédé systemd (il est intégré dans ubuntu depuis 6.10 alors que systemd est sorti vers 2010). Bref on peut arrêter le FUD, on dirait des suppôts de chez Microsoft :D

Faut arrêter la parano les gars. Je disais juste qu'on pouvait espérer voir des implémentations alternatives à certains API de systemd, parce que ça risquait de se révéler nécessaires étant donné l'utilisation qui en était faite. Dans ce cas, on peut considérer deux alternatives:
- patcher tous les logiciels qui utilisent ces API et fournir un autre moyen de faire la "même chose", ou au moins un mode dégradé
- tendre vers un "standardisation" de l'API (ce qui me parait l'approche efficace et vertueuse), i.e. une API avec plusieurs implémentations (ou avoir une implémentation portable).

Après, on peut se poser des questions sur la stratégie systemd ? Pourquoi journald et l'API associé sont dans systemd par exemple ? Pourquoi ce n'est pas simplement une bibliothèque et un daemon indépendant qui pourrait être utilisé partout ? Cette politique de centralisation + le non-acceptation de patch pour des systèmes tiers rend l'utilisation de ces API plus difficile qu'elle ne devrait l'être (il me semble).

Concernant KMS, c'est une bonne chose. Le fait que les drivers Xorg nécessitent tous KMS est certainement une chose intéressante, mais elle rend la situation très difficile pour les systèmes non-Linux (même si tous les BSD vont finir par avoir une implémentation de KMS / TTM / GEM). Je ne parle même pas de Wayland, qui va encore être une autre paire de manche :). Bref, la situation n'est pas forcément facile pour les *BSD.

Soyons clair, le système d'init (enfin, ses scripts) n'est pas commun entre les distributions Linux eux mêmes alors la compatibilité avec d'autres UNIX c'est encore pire. Je ne vois pas l'intérêt de garder un semblant de lieu commun alors que dans les faits ça fonctionne déjà différemment.

Je ne parlais pas du système d'init en tant que telle, mais systemd comme dépendance dure dans des logiciels 'tiers'. Par exemple, gdm dépend maintenant de logind pour un certain nombre de choses. Bref, pour l'instant, quelques fonctionnalités de moins dans gnome pour les BSDistes. Quand des applications vont se mettre à utiliser l'API journal pour logger, de facto, ça ne marchera plus que sur les systèmes avec systemd (i.e. plus Solaris, plus *BSD, …). Bref, si il n'y a pas d'implémentation alternative, de plus en plus d'applications seront linux-only.

Je ne sais pas pour OpenEmbedded Raw, mais pour yocto, le défault, ça reste sysvinit (standard). Tu peux facilement remplacer l'implémentation standard par l'implémentation de busybox. Et optionellement, tu peux choisir d'utiliser systemd comme système d'init (qui lui n'a pas d'implémentation alternative).

Compte tenu du champ couvert par systemd (qui ne se limite pas à Udev, contrairement à ce que Pat semble croire à l’époque), il me paraît totalement irréaliste d’imaginer (espérer ?) que Patrick Volkerding pourra maintenir à lui tout seul des remplaçants à toutes les API de systemd. Dès lors que des programmes se mettront à dépendre de ces API, il est plus vraisemblable que la conclusion des développeurs de systemd s’imposera à lui.

On peut espèrer qu'il ne sera pas tout seul. C'est quand même l'aspect problématique majeure pour les systèmes libres non-linux (ou les cas limites des systèmes linux où on voudrait utiliser linux sans devoir utiliser l'artillerie lourde d'init systemd (genre l'embarqué)).

Marrant, je n'ai à aucun moment bashé systemd. Je répondais juste aux assertions de xcomcmdr.

Je n'ai rien contre systemd, je m'en fiche. Je travaille sur des Ubuntu au boulot, et je fais du NetBSD chez moi. Y'a déjà tellement de choses de Gnome qui ne marche pas sur NetBSD qu'un peu plus, un peu moins, ça ne changera pas ma vie. D'autres linuxeries m'embêtent plus que systemd, même si à terme, ça fait peur :D

Pour les logs binaires, je comprend parfaitement les raisons. À mon niveau local, les logs textes sont largement suffisants, mais je comprends que pour des admins systèmes sur des plateformes larges, l'analyse de logs textes doit être rapidement limitante et qu'utiliser un outil spécialisé pour trier / parser des logs binaires est clairement plus efficace. Différents besoins, différents outils.

journald est un sous morceau de systemd avec plein de dépendances qui vont bien. À noter le "Reimplementable Independently" : "maybe" pour journald dans

http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/

Enfin, les promesses n'engagent que ceux qui les croient :)

Oui, encore faut il que ton autre système ait une implémentation de systemd valide (et compatible pour peu qu'ils cassent le format du journal). Alors que tout système doit avoir un truc capable d'afficher un fichier texte.

Le type somme et le filtrage existe dans le nouveau c++ ?

Non, pas en tant que tel. On peut implémenter des choses qui "ressemblent", mais c'est évidemment horriblement verbeux et pas aussi puissant qu'un vrai type somme.
Voir boost::variant par exemple. On utilisera un "visiteur" pour dispatcher selon le type interne (i.e. le constructeur en Ocaml).
Ce genre de chose est un peu plus simple à implémenter en C++11. Mais je ne crois pas qu'il y'ait quelquechose de prévu dans la librairie standard, en tout cas par pour C++14 (on va déjà avoir std::optional, pas trop de révolution à la fois :D).

Je ne fais pas autant d'Ocaml que je le souhaiterai, mais clairement, beaucoup de choses sont exprimable plus facilement en Ocaml qu'en C++ (que ce soit le polymorphisme paramétrique ou les types sommes). Après, je pense qu'on peut faire (mais est-ce qu'on veut vraiment :D) des choses avec les templates qui ne sont pas exprimables directement en OCaml (mais possible en MetaOcaml ou possiblement avec camlp4 / ppx).

Malheuresement, OCaml reste moins bon en terme de taille de communauté, portabilité, librairies disponibles, performance …

La première version a toujours été légale, tu peux binder une référence constante sur un temporaire.
Par contre, avec une référénce non constante, oui, c'est incorrect et le passage par move peut aider.