djano a écrit 1147 commentaires

Et oui… sniff!

Ouah merci pour toutes ces infos! Je vois que tu suis bien le travail fait dans ce domaine.

 

reasonator est impressionnant quand on connait l'onterface par defaut de wikidata qui est austere.

wikidata games est un outil bien fait. L'interface permet de rapidement contribuer sur des taches simples mais tres precises. Ca facilite la contribution en minimisant le temps passe a le faire, et ca reduit les erreurs puisqu'il y a un but unique a atteindre sans aucune distraction. Chapeau bas!

 

Je suis un peu decu du vote contre les modifications automatiques par des robots :( Je suppose qu'il y a eu quelques robots fous qui ont modifies les articles n'importe comment? Ce serait surement mieux d'avoir des interfaces qui permettent de modifier les articles en masse, mais qui laissent un humain valider les modifications avant de les committer a la base de donnees.

Vu la masse de donnees a manipuler dans tous les projets wikipedia, pour moi, la seule maniere de maintenir les articles/donnees et de le faire automatiquement. Ce n'est pas faisable pour un humain de tout modifier a la main.
Je suis un fervent partisan de cette approche: http://autoRefactor.org , mais en contrepartie, ceux faisant l'automatisation doivent etre tres meticuleux et averse au risque pour eviter de faire plus de bien que de mal.

Si je n'avais pas deja un projet sur lequel je travaille, je serai tres tente pour automatiser des taches sur les projets wikimedia.

 

Wikidata est un projet vraiment excitant quand je pense a l'impact qu'il pourrait avoir.

Le module "course cyclistes" est vraiment un exemple de la force de wikidata a mon sens.
On edite dans un lieu unique (wikidata) et tous les wikis peuvent beneficier automatiquement des nouvelles donnees!

Je trouve l'adoption de wikidata un peu lente quand je pense a ces benefices que tous les wikis pourraient en retirer. Ceci dit je pense que les resistances vont s'estomper avec le temps et ces decisions seront reconsiderees lorsque l'on se rendra compte de l'interet de passer par wikidata. Ca permet de reduire la charge de travail pour les humains sur des sujets fastidieux, et de leur permettre de travailler sur des choses plus interessantes.

Bonjour, merci pour ce rapide aperçu de wikidata. Je ne savais pas que c'était stocké en RDF et que l'on pouvait faire des requêtes avec SPARQL!

Quelle est le degré d'adoption de wikidata par les différentes langues de wikipedia? Quelles langues l'ont le plus adopté et que font-elles avec? Y-a-t-il des rétrospectives annuelles sur l'avancement du projet?

En quoi consiste exactement les chantiers sur le wiktionnaire et wikimedia commons? Avez-vous plus de détails?

De nos jours, il est bien moins cher d'investir dans un matériel plus performant que d'investir dans des gens qui vont améliorer les performances du logiciel.

C'était l'inverse dans les années 70 ou même avant.

L'inlining arrive beaucoup plus souvent qu'on ne le croit. Si une classe n'a pas de descendantes (beaucoup de classes sont dans ce cas) alors toutes les méthodes qu'elle définit peuvent être inlinées. C'est la CHA (Class Hierarchy Analysis) qui regarde quelles classes sont chargées au runtime. Cela permet beaucoup d'optimisations spéculatives.

Au début, ils ont fait le minimum pour eux effectivement. Depuis le passage en open source, je suis sûr que la communauté a porté Swift sur d'autres plateformes. C'était un des buts d'ailleurs: améliorer la diffusion de ce langage.

Bref, le vrai projet soutenu par Apple, c'est LLVM. Clang/Clang++ sont quasiment finances par effet de bord (de ce que j'ai compris--n'hesitez pas a me corriger si je me trompe).

Je ne suis pas sûr où tu veux en venir?

LLVM a été démarré par Chris Lattner pendant qu'il était prof d'université. Ils utilisaient les frontend de GCC (dragonegg) et LLVM en backend. Puis Apple l'a débauché pour travailler sur les outils xcode. À partir de la ils se sont rendus compte qu'ils voulaient le même frontend pour xcode et le compilateur, d'où l'arrivée de clang.

Lattner (et ses équipes) a ensuite travaillé sur Swift.

Merci pour le lien, je vais regarder ça.

Note que me demande si un telle approche serait approuvée par redoxos vu qu'ils apprécient peu le C.
Si c'est un micro noyau, peut-être qu'ils peuvent pousser ça dans le user mode?

Oui, c'est un projet hyper ambitieux (trop?). Le problème de tout nouveau kernel est la disponibilité de pilotes pour le matériel.

Perso, je serais déjà super content rien qu'avec un userland compatible GNU écrit Rust dans une distribution Linux.

On dirait Docker avec ses layers :)

On en est peut-être pas si loin…

Ça fait plaisir de voir rust utilisé en dehors de Mozilla!

Je suis content de voir que la mayonnaise prend vu les promesses faites par ce langage.

Je me prend même à rêver que le code rust puisse remplacer le C/C++ dans tout le userland.

Je reste raisonnable puisque je ne parle pas encore du noyau ;)

Je vais suivre avec attention la suite de l'oxydation ^{_^}

Merci de ton commentaire. 3 ans minimum c'est mieux et c'est encourageant.

Puisque tu as l'air de suivre plus en détail les changements de GTK, est-ce qu'il prévoient encore de gros changements d'APIs et/ou de comportement pour la suite (GTK4, 5, 6, …) ou bien est-ce que les APIs de base vont tendre vers une stabilisation générale?

Bien sûr je ne prétend pas à une stabilité totale puisqu'on n'est pas à l'abri d'un changement de paradigme comme dans GTK3 (CSS, tablettes, etc.)

Je parlais du fait de passer toute une base de code de Gtk2 à Gtk3. Contrairement à ce que tu prétends, ça ne se résume pas à changer un seul appel de méthode.
De plus les liens inclus dans la dépêche démontrent bien la non stabilité de GTK3 lui-même et les conséquences que cela peut avoir au niveau du développement et du packaging dans les distributions. Ce n'est pas trivial et c'est même décourageant pour les applications utilisatrices.

Je serai plus nuancé sur le « déjà ».

Je comprends mieux le besoin d'itérer rapidement pour l'équipe GTK+ et je trouve que la solution qu'ils proposent et un compromis intéressant. Ça embête un peu toutes les parties prenantes: GTK+ et application utilisatrices, ce qui en fait donc un bon compromis.

Ceci dit je reste persuadé que du point de vue applications utilisatrices, 2 ans c'est trop court.
Si les changements sont très nombreux, les application utilisatrices genre LibreOffice, Firefox ou Eclipse ont besoin de temps pour pouvoir faire les changements nécessaires, et laisser le toolkit graphique se stabiliser. De par leur taille et leur aspet framework, elles touchent beaucoup de corner cases qui ralentissent l'effort de migration.

D'autant qu'après un redémarrage, Firefox ne recharge pas un onglet que l'on ne consulte pas.

Je pense qu'il parle du support C/C++ puisque c'est avec quoi il travaille.

Je n'entend pas que du bien pour visual studio ou Xcode: Stabilité hasardeuse, fonctionnalités baroques.

Ils parlent de toolkit graphique et tu parles de pilotes…

Mais reprocher une version majeur au bout de 6 ans faut pas déconner.

On parle d'un framework ici, pas d'un logiciel standalone.

La stabilité des APIs ça ne se fait pas tout seul. Ou bien tu t'en préoccupes et tu fais attention aux changements d'APIs publiques, ou bien tu ne fais pas attention et tu casses tout.
Il semble que c'est cette dernière option qui ait été choisie. Ils ont sûrement leurs raisons qui sont bonnes dans leur contexte, mais ça ne donne pas une bonne image de GTK+ en tant que framework: on ne peut pas compter dessus pour avoir du code pérenne.

Bah pas tant que ca.
Combien de temps a-t-il fallu avant que GTK+3 ne puisse etre considere comme stable? Plusieurs annees?
Je pense que la base de code d'Eclipse et tres grosse (SWT c'est un framework complet) et que c'est une plateforme elle meme.

Demander 6 ans de stabilite dans les APIs n'est pas non plus dementiel. Java a 20 ans, sans presque casser quoi que ce soit.
Mais c'est peut etre plus delicat pour les toolkits graphiques.
On dirait que la plateform la plus stable pour la UI, ca reste le web…

Si, puisque GTK+ semble décider que c'est ok de demander aux autres de recommencer le travail qu'ils viennent de finir. Et vous savez quoi? Ils pensent même que c'est OK de le refaire tous les deux ans.

Bref, je trouve cette décision décevante.
J'attends de voir l'importance (ou pas) des changements d'APIs. Si ce sont des changements mineurs, l'adaptation est facile et rapide. Si ce sont des changements majeurs tous les 2 ans, c'est un gros problème.

You will be able to have a system that has development headers and libraries installed for each of Gtk 2, 3, 4 and 5, if you want to do that.

Heureusement que l'espace disque coûte de moins en moins cher!

Bon ben vivement la dépêche pour savoir à quelle sauce on va être mangés.

Sérieux? Déjà?
On est encore en train d'essuyer les plâtres, Eclipse est encore en train de fignoler le passage à GTK+3, que déjà ils veulent faire une nouvelle version majeure?

Quelqu'un connaît-il l'étendue des changements? Est-ce que ça va tout casser encore et prendre beaucoup (trop) de temps à se stabiliser?

Chapeau!