pulkomandy a écrit 1710 commentaires

Il faut bien comprendre que XML, c'est pas juste des tags et des balises. C'est aussi XML-Schema (qui définit la structure du contenu du fichier), xpath (qui permet de rechercher des infos dans un contenu XML), xslt (qui permet de transformer un XML sans tout casser).

Si tous les outils qui vont avec XML sont bien utilisés, alors oui, il est possible de manipuler un document sans comprendre tout le contenu.

Après, si on se contente du premier niveau (la syntaxe XML avec des nœuds et des attributs), c'est sur que ça va être plus compliqué de faire un truc qui marche.

Je ne suis pas d'accord avec le fait de n'avoir que des +1 (on est pas chez les bisounours).

Il ne faut pas prendre les choses personnellement, les gens votent +1 ou -1 pour n'importe quelles raisons, bonnes ou mauvaises, mais, en général, ce n'est pas contre les gens. Si ça te dérange, il doit bien y avoir un moyen de cacher ces scores?

L'idée d'avoir plus de choix (pertinent, inutile, trollesque, incompréhensible, etc) est intéressante. ça donnerait un peu de nuances. Cependant, c'est aussi moins évident de calculer un score "global" pour le commentaire, ce qui est quand même l'intérêt du truc, au départ. à moins d'avoir plusieurs scores (pertinence, trollitude, clarté, ?) et des seuils réglables pour chaque?

Je n'ai pas l'impression que ça soit forcément critiqué, du moment que c'est écrit "journal bookmark" dessus et qu'on sait à quoi s'attendre?

Ce qui est parfois critiqué, c'est le journal de 12 pages qui en fait n'apporte pas plus d'infos et qui aurait pu être un journal bookmark de 2 lignes.

ça c'est parce que tu n'as jamais utilisé un périphérique de pointage pas précis :)

S'il faut 1 seconde pour arriver à viser un bouton ou sélectionner du texte, ça devient rapidement très pénible. Pour s'en rendre compte, il suffit de prendre n'importe quel smartphone et d'essayer de naviguer sur un site pas conçu pour les mobiles, avec plein de petits boutons. C'est de ce genre de problème qu'on parle.

Pour la souris, les choses sont en général assez bien faites, et c'est plus subtil qu'il n'y paraît (courbes d'accélération, vitesse max, gérées à la fois par le capteur optique et l'électronique de la souris, et par le logiciel sur le pc).

J'arrive très bien à utiliser un trackpoint sans avoir besoin d'une souris. ça demande un peu d'habitude, mais maintenant j'ai beaucoup de mal quand je n'ai droit qu'à un trackpad… (les souris ça va, j'y arrive encore).

Mais dans le cas contraire, t'es bon pour avoir des reproches dans tous les sens.

Y'a que ceux qui font rien qui se trompent jamais /o\

(donc, au lieu de faire des reproches, ils feraient mieux de contribuer aux dépêches avant qu'elles ne soient publiées. Pour les journaux, par contre, on peut pas faire grand chose).

Pour l'USB3, ces machines ont un port ExpressCard, qui permet d'ajouter une carte USB3 connectée directement au bus PCI. Un truc dans ce genre: http://www.ldlc.com/fiche/PB00110523.html (pas testé ce modèle en particulier!). C'est donc aussi bien qu'un contrôleur USB3 intégré sur la carte mère, et surtout c'est réutilisable même si on change l'ordinateur qu'il y a autour (tant qu'il reste des ports ExpressCard, en tout cas…)

ça m'est arrivé quelques fois de devoir suivre ce genre de vidéo, je n'ai pas trouvé ça très pratique. La vidéo va soit trop vite, soit trop lentement, et du coup, il faut mettre en pause ou attendre que ça avance dans la vidéo.

Je préfère largement du texte. Et en plus, pas besoin de sortir les écouteurs pour avoir le son.

Personnellement, je trouve pas ça terrible. On est pas là pour compter les points et savoir qui contribue le plus.

Et puis, pourquoi les dépêches sur le noyau seraient spéciales? Certes, ce sont des dépêches intéressantes et de qualité, mais c'est peut-être juste parce qu'il n'y a pas assez de monde qui contribue aux autres dépêches? (et puis, n'étant pas utilisateur du noyau Linux, ce ne sont pas forcément les plus pertinentes pour moi). Je vais aller voter pour un renommage en LibreFr.org, donc!

Niveau mal au bras après utilisation intensive, je pense que c'est le seul truc avec les écrans tactiles, qui fait pire qu'une souris.
D'ailleurs, même Thomson a fini par proposer une souris sur ses machines un petit peu plus récentes (le TO8 et le TO9).

Tu peux prendre les 4 ou 5 mots du générateur et fabriquer une phrase en français avec, en les mettant dans un ordre qui marche bien, conjuguant les verbes, at ajoutant ponctuations, articles et conjonctions. Je ne pense pas que ça détruise trop l'entropie (on en perd un peu en mettant les mots un peu tout le temps dans le même ordre, mais on doit pouvoir la récupérer en ajoutant les autres trucs)

Seiko-Epson est Japonais, aussi!

Je n'en suis pas forcément surpris. Ceux qui ont essayé de créer leur entreprise et de la faire tourner tous les jours se rendront bien compte que finalement, on ne peut que difficilement faire ça, et à la fois continuer à écrire du code (tant mieux pour ceux qui y arrivent tout de même). Du coup, un entrepreneur du libre, c'est effectivement, d'abord et avant tout, un entrepreneur.

le mangling, c'est juste le premier truc qui se voit et qui empêche que ça marche. Si tes compialteurs ont le même mangling (comme en C, vu que c'est souvent juste "on met le nom de la fonction dans le symbole", avec éventuellement un underscore en préfixe), tu peux avoir aussi des problèmes beaucoup plus chiants à débugger, quelques exemples au hasard:
- Les deux compilateurs ne mettent pas les arguments sur la stack dans le même ordre
- Les long int ne font pas la même taille
- Un des deux compilateurs choisit de passer des paramètres via des registres, l'autre non (ou pas les mêmes paramètres dans les mêmes registres)
- La gestion des varargs est différente
- …

Donc, mélanger les compilateurs, même si on fait du C ou du "struct&pointers", c'est dangereux. Sauf s'il y a une ABI définie pour la plateforme qui précise tout ça (et pas juste le mangling). Et quand il n'y a pas d'ABI standard, finalement, il vaut peut être mieux que le mangling soit différent, au moins, on voit le problème à l'édition de liens (ou lors du chargement du plugin) et pas à l'exécution (on fait pas du Python, ici ;)).

Je ne vois pas bien l'intérêt d'une ABI universelle standardisée. ça n'est d'ailleurs pas le cas pour le C.

L'ABI comprend par exemple:
- La façon dont les noms de fonctions/méthodes sont traduits en noms de symboles (mangling, en C++), et les cas dans lesquels il peut y avoir des conflits,
- La façon dont les paramètres d'une fonction sont passés,
- Les règles d'alignement des membres d'une structure.

Si on peut arriver à utiliser le même mangling partout pour le 1er point, les autres sont très liés à l'architecture matérielle et aux possibilités du CPU utilisé. Les paramètres d'une fonction peuvent être passés dans des registres ou sur la pile. En commençant par celui de droite ou celui de gauche. En faisant éventuellement les choses différemment selon la taille des paramètres, ou même selon leur type (par exemple sur un motorola 68000, il y a des registrer pour stocker des entiers, et d'autres pour stocker des pointeurs).

Donc, on ne peut pas demander mieux que d'avoir une ABI par famille de CPUs. ARM en fournit une, avec des variantes en fonction de l'OS utilisé. Sur x86, il n'y en a pas et c'est laissé au choix de l'OS et du compilateur.

En fait, les problèmes arrivent surtout quand il y a plusieurs ABI "plus ou moins" compatibles. C'est le cas en C++ sous Windows, par exemple, ou on peut lier des dll compilées avec différents compilateurs, et tout marchera bien, sauf les exceptions.

Je trouve ça bizarre qu'on fasse du logiciel libre sans se préoccuper de comment il est distribué (sauf si on utilise la licence WTFPL, bien sûr). C'est quand même la base du logiciel libre, de pouvoir distribuer les choses. Est-ce qu'il est nécessaire/utile/constructif de sous-traiter ça aux responsables de paquets des différentes distributions? C'est un peu la solution de facilité, non?

Merci pour ces exemples.

Je prend le cas du système d'exploitation pour deux raisons, d'abord parce que je le connaît bien, et d'autre part parce que ça couvre déjà pas mal de choses: noyau, drivers, librairies, applications.

Mais on est d'accord, j'ai une vue très "système" sur les choses, et c'est ça qui fait de C++ un bon choix pour moi. Certainement pas un langage universel.

Pour la transpilation, ça ne me paraît pas être un problème (pas plus que la compilation). Mes interrogations portent sur le langage, plutôt que sur la façon dont il est exécuté. Par exemple, pour faire de la programmation système en Java, il y a plein de problèmes lié au langage lui-même. Au hasard, pas de pointeurs et donc pas de moyen d'accéder directement à une adresse mémoire, donc pas possible d'écrire un driver; le langage a besoin d'un garbage collector qui peut difficilement être écrit en Java, etc.

Cela dit, il y a d'autres raisons qui font que la transpilation rend les choses pénibles: c'est chiant à debugger, c'est moins pratique pour développer les choses, etc. Et donc, on a bien besoin d'un ou plusieurs langages complémentaires pour ces cas là, merci pour les exemples!

ça permet tout de même de créer du contenu genre journaux/dépêches qui restent le meilleur moyen de redorer un peu son blason.

Et comme ça on aura du spam en journaux, au lieu d'avoir du spam au fond des commentaires.

Mon test facile pour ça: est-ce qu'on peut écrire un OS entier avec?

Mais j'admet volontier que je fais beaucoup d'informatique embarquée, et moins de certains autres trucs qui sont possibles en Python mais pas en C++ (d'ailleurs je ne vois même pas d'exemple, là comme ça)

Bref, un langage ne peut pas te prémunir contre le fait de coder n'importe comment. Ce qu'on peut reprocher au C++, c'est de ne même pas définir la manière correcte de faire les choses, ce qui fait qu'il n'est jamais clair si on fait les choses correctement ou non.

C'est aussi un avantage de pouvoir faire les choses comme on veut, sans être forcé à suivre les choix des concepteurs du langage. C'est ce qui permet à C++ d'évoluer au cours du temps, en apprenant de ses erreurs.

D'autres langages font des choix plus tranchés et ça les rend moins polyvalents, dans différents domaines d'application ou au cours du temps. Le C++ s'adapte et permet de suivre les tendances (même s'il ne suit que de loin), là ou d'autres langages suivent le concept à la mode, puis finissent par vieillir et disparaître, remplacés par un nouveau langage "moderne", avec le dernier concept à la mode.

Vous êtes un peu pénibles avec votre débat sur le végétarianisme qui est hors sujet dans ce sondage. Vous voulez pas aller discuter ailleurs? Ou alors, arrêter de nourrir le troll?

Je répondais à un commentaire qui proposait d'étendre la modération pour supprimer plus de messages insultants ou agressifs. Il ne s'agit pas de ce qui est déjà traité par l'équipe de modération en place, qui semble faire plutôt bien son travail pour les cas de spam.

Je n'ai pas dit qu'il fallait supprimer les modérateurs, simplement qu'il n'est (peut-être) pas nécessaire de les faire intervenir dans certains cas. En se contentant de signaler aux gens que leur commentaire est déplacé, insultant, etc. Ceci en complément, et non en remplacement de la modération.

Une insulte est méchante, mais de là à effacer les messages,

On peut rappeler à l’ordre déjà, et ensuite bannir temporairement au bout de ~x fois. Y a peut-être d’autres trucs auxquels j’ai pas pensé.

Est-ce qu'on a systématiquement besoin de modérateurs "officiels" pour cela? Simplement dire aux gens (sans s'énerver, c'est la partie difficile) que leur commentaire est insultant et inapproprié, ça peut marcher dans certains cas.

Pas trop le temps, et le Rust reste encore assez illisible pour moi (mais j'ai sûrement trop l'habitude du C++).

Quand je vois des accès au module VBE (pour la gestion des graphismes en VESA) dans le driver de souris PS/2 (https://github.com/redox-os/redox/blob/master/kernel/drivers/ps2.rs), je m'interroge sur la conception objet et l'encapsulation. Mais le projet est tout récent et semble plutôt bien avancer, on verra où ils en sont dans 15 ans (c'est l'âge de Haiku) ou dans 25 (c'est l'âge de Linux).

mais globalement je pense que beaucoup de monde joue avec des sources qui sont en C++03, donc au revoir les smart-pointers.

En tant que contributeur au projet Haiku, qui est écrit en C++98 et compile avec gcc 2.95.3 pour diverses raisons, je ne suis pas d'accord. On a implémenté nos propres smart pointers et on les utilise là ou c'est nécessaire.

Le C++ a cet intérêt pour nous qu'il est un des rares langages avec lesquels on peut écrire un système d'exploitation entier: noyau, drivers, interface graphique, applications, etc. Et pour y arriver, on a besoin de la plupart des fonctionnalités de C++. Certains trucs "pas propres" dans une application sont nécessaires pour la programmation bas niveau (par exemple, on a besoin de pointer sur une adresse mémoire "en dur" pour accéder à du matériel). Donc, il y a des morceaux du C++ qui servent rarement, mais qui sont nécessaires dans quelques cas, et c'est bien qu'elles soient disponibles.

S'il ne devait rester qu'un seul langage, C++ serait le mieux placé. Par contre, si on préfère en avoir 2 ou 3, alors oui, faire du C ou un autre truc spécialisé dans le bas niveau côté noyau, et un langage objet "moderne" pour les applications, ça pourrait marcher.