En condensé: c'est surtout mieux pour les développeurs, pour le reste Wayland ~= extension DRI2 de X.Org donc perf similaire à X en première approximation(si le toolkit utilise l'extension DRI2) mais il y a quand même quelques différences :
1) serveur Wayland = (serveur d'affichage + compositeur + gestionnaire de fenêtre) donc possibilité d'interagir avec une fenêtre transformée et moins d'IPC donc perf potentiellement légèrement meilleure.
2) l'API de Wayland contient une notification pour prévenir quand l’image fournie a été affichée: possibilité de faire des animations fluides.
3) si la gestion des décorations de fenêtre est faite par le client, le redimensionnement des fenêtres sera 'tear free'/sans cisaillement mais potentiellement saccadé si l'application est lente a répondre.
Pourquoi tu réponds non?
Ce qu'il dit au début est correct (serveur Wayland == serveur d'affichage), donc si tu veux avoir un gestionnaire de fenetre alternatif, il faut en fait créer (par exemple en forkant Weston) un serveur d'affichage complet.
Là ou c'est plus douteux c'est quand il considère que c'est mort puisque KDE et Gnome (etc) bossent pour que leur gestionnaires de fenetres soient des serveur d'affichage Wayland, donc ça me parait bien parti!
scope [coupé] Donc ça ne remplace pas vraiment les exceptions.[coupé]Je ne vois pas non plus comment tu peut gérer certains cas avec.
Oh, ça ne remplace en aucun cas les exceptions, c'est juste une syntaxe en complément bien plus lisible que le try .. finally, qui est beaucoup lisible quand elle est applicable.
Donc on peut dire que c'est juste de la syntaxe et juste pour certains cas, mais de mon point de vue la gestion des ressources lors d'une transaction est un cas assez courant pour mériter un support particulier.
Je pense aussi que le problème serait bien moindre si Ocaml proposait de typer les exceptions pour voir ce qui remonte jusqu'au "main".
Hum, ce que tu propose ressemble fortement à Java qui indique(indiquait?) dans le prototype des fonctions les exceptions potentiellement levée ce qui causé pas mal de protestations car c'est pénible à gérer..
Bref, pour la gestion d'erreur il n'y a pas de solution miracle..
Les 3 points que je trouve intéressant:
- les scopes (*) qui remplacent en mieux le try .. finally
- les références non-nullable par défaut et le type Maybe.
- la gestion d'exception "à la Lisp" qui semble un peu différente des autres, mais je ne comprends pas bien si c'est vraiment un avantage en pratique..
Attaqué le curé au karcher non, mais je trouve aussi qu'il n'y a pas de raison valable pour laquelle les églises sont autorisés à faire du tapage diurne (mis à part pour les mariages et baptêmes qui sont des évènements exceptionnels et pas périodique).
Autrement il faut aussi autoriser les minarets, etc.
Mais patience: dans un premier temps, passage du mariage civil pour tous, ensuite ça serait une bonne idée effectivement.
un système de "traits", qui correspondent en fait assez exactement aux type classes de Haskell, pour transporter les implémentation. L'idée est qu'on définit des interfaces/traits
Euh, tu peux préciser?
Si j'en reviens à la base(C++) de l'héritage multiple, le problème principal est l'héritage en diamant quand les super-classes ont des variables, donc la règle de codage de C++ est de ne pas utiliser de variable dans les classes utilisée pour l'héritage multiple, en Java ils ont "résolu" le problème en faisant des interfaces sans implémentation ce qui est bien pénible car à chaque fois qu'on implémente une interface on doit l'implémentation, donc retour en arrière depuis on implémente avec des tas de noms différent (trait, mixin, etc) la "régle de codage" de C++: une classe ne contenant que des fonctions.
Intéressant comme carte à priori ça a vraiment tout pour faire un mini-serveur, et il y a aussi un projet de rétro-ingénierie sur le GPU Mali400.
Reste à voir le retour utilisateur sur le débit Ethernet, la fiabilité de la carte et du vendeur.
Puisque Scratch et Python ont déjà été évoqué, il y a aussi Grace qui est fait pour des étudiants (mais pas pour des enfants de 11 ans): http://gracelang.org/
Ayant commencé de bonne heure, je pense que l'important est le coté ludique de l'apprentissage: dans mes premiers cours ce qui nous a le plus plut c'était de dessiner une maison avec un programme.
Je ne suis pas un expert en python, mais dans ton cas il y aurait peut-être des parties que tu pourrais modifier dans le code original pour le rendre python3 compatible mais tout en fonctionnant toujours en python2?
Si les développeurs acceptent tes modifications, tu minimiserais les différences entre ton fork et l'original, c'est toujours ça de gagné..
Bon à la réflexion, pas sûr que ça aide vraiment car ils ne testeront leurs modifications à eux qu'avec python2.
Il me semble qu'avec X, il y a le mode 'ligne' ou tu as des lignes d'épaisseur 1 pixel:
avantage: c'est plus rapide.
inconvénient: le rendu peut varier beaucoup d'un écran à l'autre maintenant qu'il y a (enfin) des écran avec un haut DPI.
donc cela ne devrait pas être le mode par défaut, juste une optimisation possible.
Moi je m'en tenais à la manière la plus « logique » de l'écrire pour un être humain.
Je ne sais pas s'il y a une manière plus logique, après tout tu peux passer du relatif à l'absolu en faisant du relatif par rapport à l'origine et de l'absolu au relatif en ajoutant une translation, pour moi c'est plus une question de contexte:
-"à la PDF"/Scribus/DTP: tu veux imprimer sur une page dont tu connais la taille un document dont le rendu est le critère principal: en absolu.
-"à la HTML": l'idée est que ton document soit rendu de manière adapté automatiquement à la taille de l'écran utilisé: des objets en relatifs intégrés dans un document.
J'ai jeté un œil et je me retrouvé pris d'un fou rire en lisant la ref card avec le "tri-state boolean". Je ne suis pas particulièrement attaché au tiers exclus, mais la logique classique en a un besoin vital. http://asymptote.sourceforge.net/asyRefCard.pdf
'default' comme nom de troisième valeur c'est curieux en effet, mais à partir du moment ou tu utilise des float qui peuvent retourner NaN, un Not-a-Boolean me parait bien plus logique que la convention arbitraire actuelle.
Ce qui me parait vraiment le plus logique c'est d'avoir une exception plutôt qu'un NaN, mais bon en C on est coincé..
ton expérience du fonctionnement de la culture chinoise.
Euh pourquoi Chinoise? Il parle de la culture en entreprise, ses exemples n'ont rien de spécifiquement Chinois.
Un cas vécu personnellement: un boss veut utiliser un logiciel externe car il s'entend mal avec les gars qui font en interne un logiciel qui fait la même chose, donc il demande au ingénieurs de dire pourquoi le logiciel en interne ne convient pas.
Je peux te dire que quand on te fait une demande pareille tu te sens très mal à l'aise.
faudra que tu m'expliques pourquoi lorsque je vais à une soirée et qu'il y a des fumeurs de canabis, je sais qu'en rentrant chez moi je ne pourrai ni dormir, ni travailler, pendant quelques heures…
Pas remarqué ce phénomene pour moi, mais avoir du mal a s'endormir après une soirée ce n'est pas si rare..
Je suis content de pouvoir aller dans un café sans devoir supporter la fumée des autres.
100% d'accord, mais personne ne propose de remettre en cause ce point là.
Ce que tu dis confirme mes doutes pour l'utilisation de R Pi comme serveur: pas de port SATA et de l'Ethernet pas terrible, et pour servir de la vidéo le driver propriétaire du GPU est un problème.
Dommage, le prix est vraiment alléchant mais ces "détails" font que j'en vois pas l'utilité, même avec 512Mo de RAM.
Je trouve que les effets psychologiques du cannabis sont très souvent sous-estimés et j'ai vu des personnes, pas forcément socialement bien intégrées comme on dit, pour qui ce refuge est devenu une prison
C'est le cas aussi pour l'alcool!
Est-ce pour qu'il faut pour autant interdire la consommation d'alcool? Non, mais interdire toute forme de publicité pour l'alcool oui.
J'ai fait un sport ou le cannabis circulait pas mal: beaucoup en prenait pour faire la fête le Samedi soir mais pas du tout le reste de la semaine comme l'alcool quoi, par contre il y en avait une minorité qui était accro et en danger de se bousiller, mais ça n'en fait pas une raison pour interdire le cannabis..
Il y a quand même un point a éclaircir en regardant ce qui s'est passé en Hollande ou ailleurs ou c'est légal: que s'est-il passé dans les banlieue ou certains vivent de la vente du cannabis?
Ton post est difficile a lire car tu n'explique pas bien le contexte.
La question est: un script de démarrage lançant des démons doit-il rendre la main immédiatement(1) ou bien rendre la main quand tous les démons sont prêts à fonctionner(2) (par exemple en synchronisant les démons avec un sémaphore comme tu le fais)?
Les deux systèmes ayant leurs avantages et inconvénients, je doute qu'il y ait une réponse qui convienne a tout le monde (1 est plus rapide, 2 est plus 'prévisible' mais pas toujours simple a implémenter).
bah faut par exemple redonner au C ses lettres de noblesses
Pas d'accord, en C tu fais un fois deux en nombre de ligne de code par rapport à un langage comme C#(par exemple).
Après le problème de langages de haut niveau, c'est qu'on n'en a pas vraiment de bon, et même en se contentant des langages correctes existant leurs implémentations sont pas terrible: librairies réduites (le support de Qt particulièrement..), GC pas temps réels, compilateurs avec bug, etc.
Majoritaire on s'en fout ok, mais qu'il y ait suffisamment de gain d'argent sur le desktop pour pouvoir avoir
1) la compatibilité binaire des toolkits
2) une maintenance correcte des couches basses (pilotes, X,..) qui sont en manque chronique de developpeurs
3) des applications un peu plus "finie" (un exemple parmis d'autre: Gimp évolue très,très lentement)
ça ne serait pas du luxe..
Après bien sûr, ça se mord la queue, il faut 1+2+3 pour avoir des gains d'argents sur le desktop..
pour moi, la barre en termes de compatibilité est bien plus haut. Il faut aussi préserver à 100.00% la compatibilité binaire
En théorie, je suis d'accord: le noyau le fait bien, et il n'y a pas de raison que les couches du dessus fassent moins bien, mais en pratique quand tu regardes les efforts/investissements sur Linux par rapport aux couches du dessus, ça n'est pas tellement étonnant que ça ne marche pas..
[^] # Re: wayland
Posté par reno . En réponse à la dépêche X.Org est mort, vive Wayland !. Évalué à 9.
En condensé: c'est surtout mieux pour les développeurs, pour le reste Wayland ~= extension DRI2 de X.Org donc perf similaire à X en première approximation(si le toolkit utilise l'extension DRI2) mais il y a quand même quelques différences :
1) serveur Wayland = (serveur d'affichage + compositeur + gestionnaire de fenêtre) donc possibilité d'interagir avec une fenêtre transformée et moins d'IPC donc perf potentiellement légèrement meilleure.
2) l'API de Wayland contient une notification pour prévenir quand l’image fournie a été affichée: possibilité de faire des animations fluides.
3) si la gestion des décorations de fenêtre est faite par le client, le redimensionnement des fenêtres sera 'tear free'/sans cisaillement mais potentiellement saccadé si l'application est lente a répondre.
[^] # Re: Gestionnaire de fenêtres
Posté par reno . En réponse à la dépêche X.Org est mort, vive Wayland !. Évalué à 5.
Pourquoi tu réponds non?
Ce qu'il dit au début est correct (serveur Wayland == serveur d'affichage), donc si tu veux avoir un gestionnaire de fenetre alternatif, il faut en fait créer (par exemple en forkant Weston) un serveur d'affichage complet.
Là ou c'est plus douteux c'est quand il considère que c'est mort puisque KDE et Gnome (etc) bossent pour que leur gestionnaires de fenetres soient des serveur d'affichage Wayland, donc ça me parait bien parti!
[^] # Re: dommage
Posté par reno . En réponse au journal The Future of Functional Programming Languages. Évalué à 2.
Merci
[^] # Re: dommage
Posté par reno . En réponse au journal The Future of Functional Programming Languages. Évalué à 1.
Merci pour le lien mais lire un gros PDF avec GoogleDoc c'est pour les masochistes!
[^] # Re: dommage
Posté par reno . En réponse au journal The Future of Functional Programming Languages. Évalué à 3.
D: http://dlang.org/
Un langage principalement développé par des "vieux chibab" en C++..
[^] # Re: dommage
Posté par reno . En réponse au journal The Future of Functional Programming Languages. Évalué à 2.
Oh, ça ne remplace en aucun cas les exceptions, c'est juste une syntaxe en complément bien plus lisible que le try .. finally, qui est beaucoup lisible quand elle est applicable.
Donc on peut dire que c'est juste de la syntaxe et juste pour certains cas, mais de mon point de vue la gestion des ressources lors d'une transaction est un cas assez courant pour mériter un support particulier.
[^] # Re: dommage
Posté par reno . En réponse au journal The Future of Functional Programming Languages. Évalué à 3.
Hum, ce que tu propose ressemble fortement à Java qui indique(indiquait?) dans le prototype des fonctions les exceptions potentiellement levée ce qui causé pas mal de protestations car c'est pénible à gérer..
Bref, pour la gestion d'erreur il n'y a pas de solution miracle..
Les 3 points que je trouve intéressant:
- les scopes (*) qui remplacent en mieux le try .. finally
- les références non-nullable par défaut et le type Maybe.
- la gestion d'exception "à la Lisp" qui semble un peu différente des autres, mais je ne comprends pas bien si c'est vraiment un avantage en pratique..
*: http://digitalmars.com/d/1.0/exception-safe.html
[^] # Re: Bruit
Posté par reno . En réponse au journal Rejet du contrôle technique moto par le Parlement français. Évalué à 3.
Attaqué le curé au karcher non, mais je trouve aussi qu'il n'y a pas de raison valable pour laquelle les églises sont autorisés à faire du tapage diurne (mis à part pour les mariages et baptêmes qui sont des évènements exceptionnels et pas périodique).
Autrement il faut aussi autoriser les minarets, etc.
Mais patience: dans un premier temps, passage du mariage civil pour tous, ensuite ça serait une bonne idée effectivement.
[^] # Re: Rust
Posté par reno . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #42. Évalué à 4.
Euh, tu peux préciser?
Si j'en reviens à la base(C++) de l'héritage multiple, le problème principal est l'héritage en diamant quand les super-classes ont des variables, donc la règle de codage de C++ est de ne pas utiliser de variable dans les classes utilisée pour l'héritage multiple, en Java ils ont "résolu" le problème en faisant des interfaces sans implémentation ce qui est bien pénible car à chaque fois qu'on implémente une interface on doit l'implémentation, donc retour en arrière depuis on implémente avec des tas de noms différent (trait, mixin, etc) la "régle de codage" de C++: une classe ne contenant que des fonctions.
J'ai bon? Ou c'est autre chose?
[^] # Re: euh ?
Posté par reno . En réponse au journal Le Raspberry Pi passe à 512 Mio de RAM. Évalué à 2.
Intéressant comme carte à priori ça a vraiment tout pour faire un mini-serveur, et il y a aussi un projet de rétro-ingénierie sur le GPU Mali400.
Reste à voir le retour utilisateur sur le débit Ethernet, la fiabilité de la carte et du vendeur.
# Mes 2cts
Posté par reno . En réponse au message Quel langage pour initier un enfant de 10 ans à la programmation. Évalué à 2.
Puisque Scratch et Python ont déjà été évoqué, il y a aussi Grace qui est fait pour des étudiants (mais pas pour des enfants de 11 ans): http://gracelang.org/
Ayant commencé de bonne heure, je pense que l'important est le coté ludique de l'apprentissage: dans mes premiers cours ce qui nous a le plus plut c'était de dessiner une maison avec un programme.
# Rendre le projet Python3 compatible?
Posté par reno . En réponse au message Forker un projet et le maintenir à jour. Évalué à 6.
Je ne suis pas un expert en python, mais dans ton cas il y aurait peut-être des parties que tu pourrais modifier dans le code original pour le rendre python3 compatible mais tout en fonctionnant toujours en python2?
Si les développeurs acceptent tes modifications, tu minimiserais les différences entre ton fork et l'original, c'est toujours ça de gagné..
Bon à la réflexion, pas sûr que ça aide vraiment car ils ne testeront leurs modifications à eux qu'avec python2.
[^] # Re: le trait
Posté par reno . En réponse au journal Un langage de description de diagramme/figure. Évalué à 2.
Il me semble qu'avec X, il y a le mode 'ligne' ou tu as des lignes d'épaisseur 1 pixel:
avantage: c'est plus rapide.
inconvénient: le rendu peut varier beaucoup d'un écran à l'autre maintenant qu'il y a (enfin) des écran avec un haut DPI.
donc cela ne devrait pas être le mode par défaut, juste une optimisation possible.
[^] # Re: Quelques avis en passant
Posté par reno . En réponse au journal Un langage de description de diagramme/figure. Évalué à 2.
Je ne sais pas s'il y a une manière plus logique, après tout tu peux passer du relatif à l'absolu en faisant du relatif par rapport à l'origine et de l'absolu au relatif en ajoutant une translation, pour moi c'est plus une question de contexte:
-"à la PDF"/Scribus/DTP: tu veux imprimer sur une page dont tu connais la taille un document dont le rendu est le critère principal: en absolu.
-"à la HTML": l'idée est que ton document soit rendu de manière adapté automatiquement à la taille de l'écran utilisé: des objets en relatifs intégrés dans un document.
[^] # Re: Quelques avis en passant
Posté par reno . En réponse au journal Un langage de description de diagramme/figure. Évalué à 2.
'default' comme nom de troisième valeur c'est curieux en effet, mais à partir du moment ou tu utilise des float qui peuvent retourner NaN, un Not-a-Boolean me parait bien plus logique que la convention arbitraire actuelle.
Ce qui me parait vraiment le plus logique c'est d'avoir une exception plutôt qu'un NaN, mais bon en C on est coincé..
[^] # Re: un titre, un sujet, mon commentaire vaut il vraiment cette peine ?
Posté par reno . En réponse au journal Un "Nvidia Fuck You" à 300 Méga $. Évalué à 5.
Euh pourquoi Chinoise? Il parle de la culture en entreprise, ses exemples n'ont rien de spécifiquement Chinois.
Un cas vécu personnellement: un boss veut utiliser un logiciel externe car il s'entend mal avec les gars qui font en interne un logiciel qui fait la même chose, donc il demande au ingénieurs de dire pourquoi le logiciel en interne ne convient pas.
Je peux te dire que quand on te fait une demande pareille tu te sens très mal à l'aise.
[^] # Re: mon avis
Posté par reno . En réponse au journal Dépénalisation du cannabis. Qu'en pensez-vous ?. Évalué à 6.
Pas remarqué ce phénomene pour moi, mais avoir du mal a s'endormir après une soirée ce n'est pas si rare..
100% d'accord, mais personne ne propose de remettre en cause ce point là.
[^] # Re: Bien, mais...
Posté par reno . En réponse au journal Le retour de l’Ubunt‐aïe (chez Asus). Évalué à 4.
Et après on s'étonne que Linux pour le desktop ne progresse pas..
[^] # Re: débat dogmatique
Posté par reno . En réponse au journal Dépénalisation du cannabis. Qu'en pensez-vous ?. Évalué à 6.
Note que les deux sont liés.
[^] # Re: USB/Ethernet
Posté par reno . En réponse au journal Le Raspberry Pi passe à 512 Mio de RAM. Évalué à 5.
Ce que tu dis confirme mes doutes pour l'utilisation de R Pi comme serveur: pas de port SATA et de l'Ethernet pas terrible, et pour servir de la vidéo le driver propriétaire du GPU est un problème.
Dommage, le prix est vraiment alléchant mais ces "détails" font que j'en vois pas l'utilité, même avec 512Mo de RAM.
[^] # Re: re
Posté par reno . En réponse au journal Dépénalisation du cannabis. Qu'en pensez-vous ?. Évalué à 7.
C'est le cas aussi pour l'alcool!
Est-ce pour qu'il faut pour autant interdire la consommation d'alcool? Non, mais interdire toute forme de publicité pour l'alcool oui.
J'ai fait un sport ou le cannabis circulait pas mal: beaucoup en prenait pour faire la fête le Samedi soir mais pas du tout le reste de la semaine comme l'alcool quoi, par contre il y en avait une minorité qui était accro et en danger de se bousiller, mais ça n'en fait pas une raison pour interdire le cannabis..
Il y a quand même un point a éclaircir en regardant ce qui s'est passé en Hollande ou ailleurs ou c'est légal: que s'est-il passé dans les banlieue ou certains vivent de la vente du cannabis?
# Manque de contexte
Posté par reno . En réponse au journal Les sémaphores. Évalué à 7.
Ton post est difficile a lire car tu n'explique pas bien le contexte.
La question est: un script de démarrage lançant des démons doit-il rendre la main immédiatement(1) ou bien rendre la main quand tous les démons sont prêts à fonctionner(2) (par exemple en synchronisant les démons avec un sémaphore comme tu le fais)?
Les deux systèmes ayant leurs avantages et inconvénients, je doute qu'il y ait une réponse qui convienne a tout le monde (1 est plus rapide, 2 est plus 'prévisible' mais pas toujours simple a implémenter).
[^] # Re: firefox et KDE : l'exemple
Posté par reno . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 0.
Pas d'accord, en C tu fais un fois deux en nombre de ligne de code par rapport à un langage comme C#(par exemple).
Après le problème de langages de haut niveau, c'est qu'on n'en a pas vraiment de bon, et même en se contentant des langages correctes existant leurs implémentations sont pas terrible: librairies réduites (le support de Qt particulièrement..), GC pas temps réels, compilateurs avec bug, etc.
[^] # Re: firefox et KDE : l'exemple
Posté par reno . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 3.
Majoritaire on s'en fout ok, mais qu'il y ait suffisamment de gain d'argent sur le desktop pour pouvoir avoir
1) la compatibilité binaire des toolkits
2) une maintenance correcte des couches basses (pilotes, X,..) qui sont en manque chronique de developpeurs
3) des applications un peu plus "finie" (un exemple parmis d'autre: Gimp évolue très,très lentement)
ça ne serait pas du luxe..
Après bien sûr, ça se mord la queue, il faut 1+2+3 pour avoir des gains d'argents sur le desktop..
[^] # Re: Tu critiques Qt ?
Posté par reno . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 2.
En théorie, je suis d'accord: le noyau le fait bien, et il n'y a pas de raison que les couches du dessus fassent moins bien, mais en pratique quand tu regardes les efforts/investissements sur Linux par rapport aux couches du dessus, ça n'est pas tellement étonnant que ça ne marche pas..