Le problème c'est que si deux endroits dans le code déclarent tout les deux une implémentation sur le même type du même trait, alors on ne peut plus compiler car on ne sait pas quelle implem choisir.
Le souci c'est que cela peut être deux personnes complètement différentes, par exemple dans deux bibliothèques sans aucun rapport et ensuite une troisième personne veut utiliser ces deux lib et là paf le chien. C'est un problème bien connu en Haskell (langage d'où provient l'inspiration pour le mécanismes des traits, qui s'appellent "classe de type" là bas), d'où la restriction supplémentaire en Rust pour éviter de ce retrouver dans cette situation (pas très probable mais très emmerdante quand ça arrive).
Oui alors je me restreignais aux langages avec un minimum de diffusion :)
Quitte à en citer un, je citerai Cyclone qui est apparemment celui qui a servi de modèle à Rust pour la partie "borrowing system" (sachant qu'on appelle ça aussi de la "region analysis" ou des affine type). Et sachant aussi qu'ils ont enrichi ce qu'il se faisait.
Après le langage avec des types dépendants, c'est très bien mais ce n'est pas décidable. Donc c'est un "type" dans l'acceptation des système de démonstration formel comme Coq. En programmation on considère plutôt qu'un type doit être pris en charge complètement par le typecheck du compilateur. Donc j'aurai tendance à dire que ce ne sont pas de langage de programmation mais de preuve. Après moi je suis pour qu'on fasse des preuves de programmes :) mais si on pouvait déjà juste dégager les buffer overflow et autres failles de nos programmes en utilisant des langages comme Rust, ça serait déjà pas mal !
C'est vrai que tu restreins (c'est le but en fait), après est-ce que c'est "arbitraire" ? Comme tu le dis toi même dans ton message la simple compatibilité syntaxique ne suffit à savoir si on peut réellement substituer le type. On peut imaginer par exemple un type de liste et un type ensemble qui possèdent la même interface, seulement l'opération ajout n'est pas substituable car si l’élément existe déjà dans le conteneur on l'ajoute quand même dans le cas de la liste mais on ne l'ajoute pas dans le cas de l'ensemble.
La programmation par contrat ne résout pas ce problème (en tout cas dans son acceptation classique) car comparer des contrats (des prédicats mathématiques en fait) n'est pas décidable. De plus les contrats sont en général optionnels et ce n'est pas si simple que cela de formaliser le comportement des fonctions.
De plus tu peux imaginer des trait (des interfaces quoi) qui servent seulement à restreindre sans apporter des méthodes. Par exemple les std::marker dans la lib standard te permettent de specifier ce qu'il est possible de faire avec un type. Par exemple si std::marker::Copy est implémenté cela signifie qu'il est légal de se contenter de faire une copie du type pour obtenir un copie (pas de dépendance à copier en plus), pour autant Copy n'a aucune méthode attachée. On voit bien dans ce cas là que le trait sert à exprimer les intentions des développeur et les informations dénoté ne peuvent pas être reconstruite par ailleurs.
Enfin, c'est principalement l’absence d'un tel mécanisme qui rend les erreurs des templates C++ aussi verbeux. Car le compilateur n'a aucun moyen de faire des vérifications autrement qu'en essayant d'instancier réellement le template et de voir si ça marche. D'ailleurs ils veulent le rajouter dans la prochaine version de C++ sous le nom de "concepts" (j'imagine que c'est dans une version différente de ce qui avait été proposé et refusé pour C++11).
Et regarde par regarde le proposal que tu cite "World’s Dumbest Smart Pointer", en fait c'est clairement un "Immutable borrowed reference" en Rust (voir la typologie des pointeurs. Quand on te dis que le C++ et Rust sont comparable.
Le problème c'est que l'équipe de GCC fait tout ce qu'elle peut pour empêcher la réutilisation du backend. Cela fait partie de la posture philosophique de RMS pour empêcher que des entreprises réutilise le code de GCC pour en faire un compilateur non-libre (comme l'a fait Apple avec Swift et LLVM).
Là ou l'idée fondatrice de LLVM est une séparation du backend et du frontend de compilation en passant par un langage intermédiaire bien défini. C'est pour cela qu'il a beaucoup de langage expérimentaux qui se basent sur LLVM. Cela pose d'ailleurs un problème sur Windows car LLVM n'est pas très mature sur cette plateforme.
Ceci dit, je crois me souvenir qu'il y a eu des ouvertures récente sur ce sujet de l'équipe de GCC.
Ce qui m'énerve, c'est qu'on n'arrête pas de comparer Rust à C/C++ alors que ça n'a à peu près rien à voir. Qu'on compare Rust à Go, par exemple, me semble bien plus pertinent.
C'est là qu'on voit que tu n'a pas du beaucoup te renseigner sur la question.
La plupart des idiomes de programmation (moderne) de C++ (RAII par exemple) se retrouvent tel quel dans les idiomes de Rust avec un plus un support du compilateur.
Java n'est pas du tout sur le même segment que C/C++. Il y avait un manque qui a été comblé. Rust comble quel manque en terme de marché ? Aucun.
Faux, on a clairement un trou dans le segment de marché correspondant à un langage de programmation avec des garanties de sureté (permettant de garantir l’absence de faille de sécurité type buffer-overflow et autre), orienté système (compilation native, runtime petit et pas de garbage-collector) et permettant de faire des abstractions "zero-cost" (voir la définition de Bjarne Stroustrup).
En client de ce segment de marché on peut facilement trouver pas mal de monde, qui d'ailleurs utilisent majoritairement et actuellement C++. Par exemple, l'écriture de moteur de jeux video, les appli grand publique genre navigateur web, tout ceux qui font de l'embarqué (d'autant plus avec des contraintes temps réel).
Et il n'y a aucun langage existant (à ma connaissance) qui permette de garantir la sureté de l'utilisation mémoire en présence d'allocation sur le tas (sans garbage collector, évidement). Par exemple, ni C++, ni Ada, ni D, ni Go ne le permettent (dans le cas de figure général évidement).
L'autre propriété innovante de Rust, c'est de garantir l’absence de data-race dans la programmation multi-threadé. Les seuls autres langages permettant de faire (à ma connaissance) sont dans le genre de Erlang ou Haskell et pour le coup ce sont des langages avec un gros runtime (voir une machine virtuelle) et laissant très peu de contrôle sur le programme compilé.
C'est clairement faux, il y a des contributions vraiment externes qui sont accepté. Et d’ailleurs il y a des personnes non-Mozilla et non-Samsung dans la core team. Par exemple Huon Wilson.
Rust n'est pas dans un mode de fonctionnement à la C++ ou le comité de normalisation est un "vrai" comité au sens ISO ou autre où là effectivement il y a une lourdeur importante à la participation. C'est plutôt comparable au mode de fonctionnement des PIP des Python (voir à L'IETF).
Ça c'est une question très facile : un compilateur Rust peut te garantir des propriété de sureté (bon usage de la mémoire et absence de data-race) grâce à ce que permet et ne permet pas le langage Rust. Un compilateur C++ ne peut pas faire cela car le langage C++ te permet d'exprimer des programmes non analysable. Et les évolutions de C++ ont toujours conservé les compatibilité du code source (cela fait partit des objectifs déclarés des comité de normalisation C++), ce qu'il fait que cette situation ne changera pas.
D'où l’intérêt de passer de passer à Rust si tu veux pouvoir garantir, par exemple, l’absence de failles de sécurité de tes programmes (c'est là un des objectif fondateur de Rust).
Je promet pas de faire une vidée si ça m'arrive au milieu de l'open-space :)
Par contre je ne comprend pas pourquoi, sur ce genre de vidéo, ils utilisent la presse à l'envers pour la remplir. Ça me parait forcement moins stable, vue qu'elle est pas sur son pied.
Tout à fait c'est le même principe, sauf que le café coule en dessous et non pas au travers du piston. Du coup c'est plus facile à nettoyer, c'est important pour moi car on n'a pas grand chose à part un lavabo assez loin du coin café.
De plus le filtre est en papier, ce qui fait qu'on peut utiliser du café avec un mouture plus fine (je réutilise le même café que celui de ma machine expresso). Normalement il faut une mouture un peu plus grosse pour une cafetière à piston.
En fait on pourrait réutiliser exactement la même argumentation en te faisant remarquer que finalement XMPP réinvente le job des email qui est exactement un protocole de diffusion décentralisé de message.
Ben j'ai vraiment du mal avec cette notion d'extensibilité. Imagine tu prend les principes de Matrix pour en faire une extension du protocole, appelons là XMPP/DistriMUC. Pour autant chacun devra mettre à jour son serveur et activer le sous-protocole XMPP/DistriMUC, fondamentalement c'est quoi la différence avec ajouter un service Matrix sur ton serveur et l'activer ? Si un logiciel client voit passer un message XMPP/DistriMUC et qu'il n'est pas programmé pour l'interpréter c'est exactement comme si il voyait passer un paquet TCP/IP sans savoir l'interpréter. Imaginons que tu ne soit intéressé que par la partie XMPP/DistriMUC, que gagne tu à t'être intégré à XMPP ? Si tu veux utiliser XMPP/DistriMUC tu ne pourrait pas envoyer des messages (sans utiliser de passerelle) dans les salons XMPP/MUC. Après si tu veux bien utiliser une passerelle alors tu peux aussi faire une passerelle avec n'importe quoi d'autre, XMPP ou pas.
PS: C'est tellement respectueux des standards qu'ils ont changé la manière d'écrire une adresse : @user:machine.net. Bien joué les gars ;)
Ça a l'air d'être dans l'esprit du standard IRC : dans IRC un login c'est @user donc ca devient @user:machine.net
En fait, on peut toujours dire : oui XMPP c'est extensible donc tu peux faire ce que tu veux avec. Mais ça c'est vrai avec n'importe quel protocole, même si il n'y a pas marqué extensible dans le nom. Il faudra dans tous les cas programmer et distribuer tout les serveur et les client si tu veux que ton extension fonctionne, XMPP ne résout rien à ça. Et le problème c'est bien ça, suffit de regarder une grille de compatibilité d'extension des serveur et client XMPP pour s'en convaincre.
En plus je trouve que la grande question c'est de trouver un protocole qui résout efficacement nos besoin, une fois qu'on pense qu'on a trouvé ce protocole il faut abandonner les protocoles qu'on juge moins bien. Avec un mode de fonctionnement comme XMPP on est condamner à garder le choix initiaux dans le protocole, plus tout un tas d'extension intermédiaire utiles ou pas. Je pense qu'il vaut mieux fonctionner avec un modèle de couche comme dans le modèle OSI ou le modèle TCP/IP car tu peux effectivement remplacer un protocole par un autre.
Sinon il y a le classique Real World Haskell. Il est plus classique dans sa présentation que "Learn You a Haskell" (perso j'ai eu du mal avec). Comme il est plus vieux, il y a quelques chapitres plus trop à jour (des bibliothèques qui ont un peu évolué) mais bon c'est surtout la forme, le fond reste valable.
On peut le lire en ligne ou s'acheter une version papier.
8pen j'ai pas mal testé et j'ai trouvé qu'en pratique on faisait beaucoup de mouvement pour saisir les lettres (il faut beaucoup tourner pour la plupart des lettres).
J'ai trouvé le concept de MessagEase plus efficace. Je l'utilise depuis maintenant 2 ans je crois. C'est devenu très naturel et surtout je fais peu d'erreur de "frappe" (si on peut dire) même sur un petit écran et même perturbé par des déplacements (métro, bus, …). Et j'apprécie beaucoup le fait qu'il n'a pas besoin de prédiction pour être efficace (contrairement à la plupart des autres solutions).
Hmm le problème du C++ de ce coté là c'est avant tout le fait que c'est un patchwork d'ajouts au fils des années sans jamais remettre en cause l'existant. Alors forcement il ne peut pas être simple si l'ambition est de laisser les gens choisir entre les possibilités ajoutées au fils du temps.
Concernant Rust, on peut noter le travail de simplification et de généralisation autour des types de pointeurs. Il y a carrément eu un type de pointeur (celui qui était sensé déclencher un système de ramasse miettes) qui a disparu car ils se sont rendu compte qu'on pouvait réaliser la même chose sans construction syntaxique dédié.
Après, tu parlais de simplicité du langage dans ton premier post, il faut pas oublier le but premier de Rust est d'obtenir un langage "système". C'est à dire qu'on doit pouvoir contrôler précisément le comportement et les performances des programmes (notamment d'un point de vue gestion mémoire). Étant donné cela le langage sera forcement plus compliqué à utiliser que les langages promouvant l'utilisation d'un ramasse miette. Mais on ne peut pas avoir le beurre et l'argent du beurre. Bien que je trouve qu'ils aient fait un super travail avec le système d'analyse des lifetime des variables (et donc des fragments de mémoires alloués dynamiquement qui peuvent y être associé).
Posté par outs .
En réponse au journal Modifications de Nightgrey.
Évalué à 0.
Dernière modification le 03 janvier 2012 à 21:04.
Effectivement lorsque je suis déjà en -42 avant d'arriver sur la page tout s'affiche déplié.
Si on change le seuil, les commentaires se replient comme ils faut par contre ils ne se déplient plus. C'était déjà comme ça avec la css par défaut ? Faut que je regarde
EDIT : effectivement ça ne marche pas non plus avec un autre style. Désolé pour le dérangement ;)
Par contre, j'ai remarqué que le niveau de seuil pour afficher/cacher les commentaires ne fonctionne plus correctement. Chez moi j'utilise souvent le niveau -42 pour tout faire apparaître et là les commentaire restent cachés.
Bon c'est pas la sécurité absolue, mais mes fichiers ne bougent pas tant que ça non plus. Ce qui m'ennuie le plus ça serait le cas d'incendie ou de vol...
Mmmh Haskell n'est pas un ML (comme par exemple StandardML et OCaml). La grosse différence coté fonctionnel est que les ML sont à évaluation stricte et Haskell à évaluation paresseuse. Sinon les ML ont toujours eu une partie impérative (encore plus poussé dans OCaml pour intégrer les objets et modules) alors que Haskell est pur. Si ton but est de découvrir le fonctionnel je vois pas bien l'intérêt de prendre un langage impur, à cet égard OCaml est un gros langage juste à cause de ça. L'approche d'haskell me semble plus élégante avec les monades.
Perso j'ai toujours regretté que dans OCaml il soit impossible de définir des classes de types. Par exemple il y a une addition + pour les entiers et une addition +. pour les flottants, mais ce n'est pas limité à ca le code Caml est rempli de fonction qui font le même type d'opération avec des nom légèrement différent à cause de cette limitation.
Sinon Haskell est un standard avec plusieurs compilo dispo, ce qui assure une certaine stabilité. Alors que Ocaml est géré par une équipe de l'INRIA dans un but de recherche.
Les deux langages possèdes des compilo très efficaces, avec de bonnes optimisations et génération de code natif. Ce qui est important pour contrebalancer la lenteur potentielle de la prog fonc.
[^] # Re: Améliorations
Posté par outs . En réponse au journal bookmark - manifeste cyber. Évalué à 1.
Oups désolé ! J'ai trituré la phrase plusieurs fois et ensuite mon cerveau a du occulter pendant la relecture…
[^] # Re: Premières impressions
Posté par outs . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 8.
En fait c'est lié à la règle "Orphan rules".
Le problème c'est que si deux endroits dans le code déclarent tout les deux une implémentation sur le même type du même trait, alors on ne peut plus compiler car on ne sait pas quelle implem choisir.
Le souci c'est que cela peut être deux personnes complètement différentes, par exemple dans deux bibliothèques sans aucun rapport et ensuite une troisième personne veut utiliser ces deux lib et là paf le chien. C'est un problème bien connu en Haskell (langage d'où provient l'inspiration pour le mécanismes des traits, qui s'appellent "classe de type" là bas), d'où la restriction supplémentaire en Rust pour éviter de ce retrouver dans cette situation (pas très probable mais très emmerdante quand ça arrive).
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par outs . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 5.
Oui alors je me restreignais aux langages avec un minimum de diffusion :)
Quitte à en citer un, je citerai Cyclone qui est apparemment celui qui a servi de modèle à Rust pour la partie "borrowing system" (sachant qu'on appelle ça aussi de la "region analysis" ou des affine type). Et sachant aussi qu'ils ont enrichi ce qu'il se faisait.
Après le langage avec des types dépendants, c'est très bien mais ce n'est pas décidable. Donc c'est un "type" dans l'acceptation des système de démonstration formel comme Coq. En programmation on considère plutôt qu'un type doit être pris en charge complètement par le typecheck du compilateur. Donc j'aurai tendance à dire que ce ne sont pas de langage de programmation mais de preuve. Après moi je suis pour qu'on fasse des preuves de programmes :) mais si on pouvait déjà juste dégager les buffer overflow et autres failles de nos programmes en utilisant des langages comme Rust, ça serait déjà pas mal !
[^] # Re: Premières impressions
Posté par outs . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 2.
C'est vrai que tu restreins (c'est le but en fait), après est-ce que c'est "arbitraire" ? Comme tu le dis toi même dans ton message la simple compatibilité syntaxique ne suffit à savoir si on peut réellement substituer le type. On peut imaginer par exemple un type de liste et un type ensemble qui possèdent la même interface, seulement l'opération ajout n'est pas substituable car si l’élément existe déjà dans le conteneur on l'ajoute quand même dans le cas de la liste mais on ne l'ajoute pas dans le cas de l'ensemble.
La programmation par contrat ne résout pas ce problème (en tout cas dans son acceptation classique) car comparer des contrats (des prédicats mathématiques en fait) n'est pas décidable. De plus les contrats sont en général optionnels et ce n'est pas si simple que cela de formaliser le comportement des fonctions.
De plus tu peux imaginer des trait (des interfaces quoi) qui servent seulement à restreindre sans apporter des méthodes. Par exemple les std::marker dans la lib standard te permettent de specifier ce qu'il est possible de faire avec un type. Par exemple si std::marker::Copy est implémenté cela signifie qu'il est légal de se contenter de faire une copie du type pour obtenir un copie (pas de dépendance à copier en plus), pour autant Copy n'a aucune méthode attachée. On voit bien dans ce cas là que le trait sert à exprimer les intentions des développeur et les informations dénoté ne peuvent pas être reconstruite par ailleurs.
Enfin, c'est principalement l’absence d'un tel mécanisme qui rend les erreurs des templates C++ aussi verbeux. Car le compilateur n'a aucun moyen de faire des vérifications autrement qu'en essayant d'instancier réellement le template et de voir si ça marche. D'ailleurs ils veulent le rajouter dans la prochaine version de C++ sous le nom de "concepts" (j'imagine que c'est dans une version différente de ce qui avait été proposé et refusé pour C++11).
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par outs . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 4.
Et ben très bien :)
Et regarde par regarde le proposal que tu cite "World’s Dumbest Smart Pointer", en fait c'est clairement un "Immutable borrowed reference" en Rust (voir la typologie des pointeurs. Quand on te dis que le C++ et Rust sont comparable.
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par outs . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 6.
Tu te trompe : voici le ticket pour introduire les allocateurs personnalisé dans Rust.
Il est vrai qu'il n'a pas été possible de la faire pour la v1. Mais c'est typiquement le genre de chose qui a du sens dans Rust.
[^] # Re: Rust over GCC
Posté par outs . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 3.
Le problème c'est que l'équipe de GCC fait tout ce qu'elle peut pour empêcher la réutilisation du backend. Cela fait partie de la posture philosophique de RMS pour empêcher que des entreprises réutilise le code de GCC pour en faire un compilateur non-libre (comme l'a fait Apple avec Swift et LLVM).
Là ou l'idée fondatrice de LLVM est une séparation du backend et du frontend de compilation en passant par un langage intermédiaire bien défini. C'est pour cela qu'il a beaucoup de langage expérimentaux qui se basent sur LLVM. Cela pose d'ailleurs un problème sur Windows car LLVM n'est pas très mature sur cette plateforme.
Ceci dit, je crois me souvenir qu'il y a eu des ouvertures récente sur ce sujet de l'équipe de GCC.
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par outs . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 5.
C'est là qu'on voit que tu n'a pas du beaucoup te renseigner sur la question.
La plupart des idiomes de programmation (moderne) de C++ (RAII par exemple) se retrouvent tel quel dans les idiomes de Rust avec un plus un support du compilateur.
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par outs . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 1.
oui merci :)
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par outs . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 5.
Faux, on a clairement un trou dans le segment de marché correspondant à un langage de programmation avec des garanties de sureté (permettant de garantir l’absence de faille de sécurité type buffer-overflow et autre), orienté système (compilation native, runtime petit et pas de garbage-collector) et permettant de faire des abstractions "zero-cost" (voir la définition de Bjarne Stroustrup).
En client de ce segment de marché on peut facilement trouver pas mal de monde, qui d'ailleurs utilisent majoritairement et actuellement C++. Par exemple, l'écriture de moteur de jeux video, les appli grand publique genre navigateur web, tout ceux qui font de l'embarqué (d'autant plus avec des contraintes temps réel).
Et il n'y a aucun langage existant (à ma connaissance) qui permette de garantir la sureté de l'utilisation mémoire en présence d'allocation sur le tas (sans garbage collector, évidement). Par exemple, ni C++, ni Ada, ni D, ni Go ne le permettent (dans le cas de figure général évidement).
L'autre propriété innovante de Rust, c'est de garantir l’absence de data-race dans la programmation multi-threadé. Les seuls autres langages permettant de faire (à ma connaissance) sont dans le genre de Erlang ou Haskell et pour le coup ce sont des langages avec un gros runtime (voir une machine virtuelle) et laissant très peu de contrôle sur le programme compilé.
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par outs . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 5.
C'est clairement faux, il y a des contributions vraiment externes qui sont accepté. Et d’ailleurs il y a des personnes non-Mozilla et non-Samsung dans la core team. Par exemple Huon Wilson.
Rust n'est pas dans un mode de fonctionnement à la C++ ou le comité de normalisation est un "vrai" comité au sens ISO ou autre où là effectivement il y a une lourdeur importante à la participation. C'est plutôt comparable au mode de fonctionnement des PIP des Python (voir à L'IETF).
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par outs . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 7.
Ça c'est une question très facile : un compilateur Rust peut te garantir des propriété de sureté (bon usage de la mémoire et absence de data-race) grâce à ce que permet et ne permet pas le langage Rust. Un compilateur C++ ne peut pas faire cela car le langage C++ te permet d'exprimer des programmes non analysable. Et les évolutions de C++ ont toujours conservé les compatibilité du code source (cela fait partit des objectifs déclarés des comité de normalisation C++), ce qu'il fait que cette situation ne changera pas.
D'où l’intérêt de passer de passer à Rust si tu veux pouvoir garantir, par exemple, l’absence de failles de sécurité de tes programmes (c'est là un des objectif fondateur de Rust).
[^] # Re: Cafetière à piston ?
Posté par outs . En réponse au journal Enfin une solution pour du café libre au boulot.. Évalué à 2.
Je promet pas de faire une vidée si ça m'arrive au milieu de l'open-space :)
Par contre je ne comprend pas pourquoi, sur ce genre de vidéo, ils utilisent la presse à l'envers pour la remplir. Ça me parait forcement moins stable, vue qu'elle est pas sur son pied.
[^] # Re: Cafetière à piston ?
Posté par outs . En réponse au journal Enfin une solution pour du café libre au boulot.. Évalué à 2.
Tout à fait c'est le même principe, sauf que le café coule en dessous et non pas au travers du piston. Du coup c'est plus facile à nettoyer, c'est important pour moi car on n'a pas grand chose à part un lavabo assez loin du coin café.
De plus le filtre est en papier, ce qui fait qu'on peut utiliser du café avec un mouture plus fine (je réutilise le même café que celui de ma machine expresso). Normalement il faut une mouture un peu plus grosse pour une cafetière à piston.
[^] # Re: Cette roue roule vachement plus vite !
Posté par outs . En réponse au journal Pas seul dans la matrice. Évalué à 3.
En fait on pourrait réutiliser exactement la même argumentation en te faisant remarquer que finalement XMPP réinvente le job des email qui est exactement un protocole de diffusion décentralisé de message.
[^] # Re: Cette roue roule vachement plus vite !
Posté par outs . En réponse au journal Pas seul dans la matrice. Évalué à 3.
Ben j'ai vraiment du mal avec cette notion d'extensibilité. Imagine tu prend les principes de Matrix pour en faire une extension du protocole, appelons là XMPP/DistriMUC. Pour autant chacun devra mettre à jour son serveur et activer le sous-protocole XMPP/DistriMUC, fondamentalement c'est quoi la différence avec ajouter un service Matrix sur ton serveur et l'activer ? Si un logiciel client voit passer un message XMPP/DistriMUC et qu'il n'est pas programmé pour l'interpréter c'est exactement comme si il voyait passer un paquet TCP/IP sans savoir l'interpréter. Imaginons que tu ne soit intéressé que par la partie XMPP/DistriMUC, que gagne tu à t'être intégré à XMPP ? Si tu veux utiliser XMPP/DistriMUC tu ne pourrait pas envoyer des messages (sans utiliser de passerelle) dans les salons XMPP/MUC. Après si tu veux bien utiliser une passerelle alors tu peux aussi faire une passerelle avec n'importe quoi d'autre, XMPP ou pas.
Ça a l'air d'être dans l'esprit du standard IRC : dans IRC un login c'est @user donc ca devient @user:machine.net
En fait, on peut toujours dire : oui XMPP c'est extensible donc tu peux faire ce que tu veux avec. Mais ça c'est vrai avec n'importe quel protocole, même si il n'y a pas marqué extensible dans le nom. Il faudra dans tous les cas programmer et distribuer tout les serveur et les client si tu veux que ton extension fonctionne, XMPP ne résout rien à ça. Et le problème c'est bien ça, suffit de regarder une grille de compatibilité d'extension des serveur et client XMPP pour s'en convaincre.
En plus je trouve que la grande question c'est de trouver un protocole qui résout efficacement nos besoin, une fois qu'on pense qu'on a trouvé ce protocole il faut abandonner les protocoles qu'on juge moins bien. Avec un mode de fonctionnement comme XMPP on est condamner à garder le choix initiaux dans le protocole, plus tout un tas d'extension intermédiaire utiles ou pas. Je pense qu'il vaut mieux fonctionner avec un modèle de couche comme dans le modèle OSI ou le modèle TCP/IP car tu peux effectivement remplacer un protocole par un autre.
[^] # Re: Plus d'infos si possible
Posté par outs . En réponse au journal Récent livre pour apprendre Haskell et la programmation fonctionnelle. Évalué à 1.
Sinon il y a le classique Real World Haskell. Il est plus classique dans sa présentation que "Learn You a Haskell" (perso j'ai eu du mal avec). Comme il est plus vieux, il y a quelques chapitres plus trop à jour (des bibliothèques qui ont un peu évolué) mais bon c'est surtout la forme, le fond reste valable.
On peut le lire en ligne ou s'acheter une version papier.
[^] # Re: Utilité du bépo sur tactile.
Posté par outs . En réponse au journal Appels à testeurs: bépo sur Android 1.0. Évalué à 1. Dernière modification le 06 janvier 2015 à 17:34.
8pen j'ai pas mal testé et j'ai trouvé qu'en pratique on faisait beaucoup de mouvement pour saisir les lettres (il faut beaucoup tourner pour la plupart des lettres).
J'ai trouvé le concept de MessagEase plus efficace. Je l'utilise depuis maintenant 2 ans je crois. C'est devenu très naturel et surtout je fais peu d'erreur de "frappe" (si on peut dire) même sur un petit écran et même perturbé par des déplacements (métro, bus, …). Et j'apprécie beaucoup le fait qu'il n'a pas besoin de prédiction pour être efficace (contrairement à la plupart des autres solutions).
[^] # Re: simple ?
Posté par outs . En réponse au journal Rust en version 0.12. Évalué à 4.
Hmm le problème du C++ de ce coté là c'est avant tout le fait que c'est un patchwork d'ajouts au fils des années sans jamais remettre en cause l'existant. Alors forcement il ne peut pas être simple si l'ambition est de laisser les gens choisir entre les possibilités ajoutées au fils du temps.
Concernant Rust, on peut noter le travail de simplification et de généralisation autour des types de pointeurs. Il y a carrément eu un type de pointeur (celui qui était sensé déclencher un système de ramasse miettes) qui a disparu car ils se sont rendu compte qu'on pouvait réaliser la même chose sans construction syntaxique dédié.
Après, tu parlais de simplicité du langage dans ton premier post, il faut pas oublier le but premier de Rust est d'obtenir un langage "système". C'est à dire qu'on doit pouvoir contrôler précisément le comportement et les performances des programmes (notamment d'un point de vue gestion mémoire). Étant donné cela le langage sera forcement plus compliqué à utiliser que les langages promouvant l'utilisation d'un ramasse miette. Mais on ne peut pas avoir le beurre et l'argent du beurre. Bien que je trouve qu'ils aient fait un super travail avec le système d'analyse des lifetime des variables (et donc des fragments de mémoires alloués dynamiquement qui peuvent y être associé).
[^] # Re: niveau de seuil cassé
Posté par outs . En réponse au journal Modifications de Nightgrey. Évalué à 0. Dernière modification le 03 janvier 2012 à 21:04.
Effectivement lorsque je suis déjà en -42 avant d'arriver sur la page tout s'affiche déplié.
Si on change le seuil, les commentaires se replient comme ils faut par contre ils ne se déplient plus. C'était déjà comme ça avec la css par défaut ? Faut que je regarde
EDIT : effectivement ça ne marche pas non plus avec un autre style. Désolé pour le dérangement ;)
# niveau de seuil cassé
Posté par outs . En réponse au journal Modifications de Nightgrey. Évalué à 0.
salut, merci pour la css ;)
Par contre, j'ai remarqué que le niveau de seuil pour afficher/cacher les commentaires ne fonctionne plus correctement. Chez moi j'utilise souvent le niveau -42 pour tout faire apparaître et là les commentaire restent cachés.
[^] # Re: Robot après tout
Posté par outs . En réponse au journal CAPTCHA. Évalué à 7.
C'est n'importe quoi robocop il a un cerveau humain (on voit même un bout de visage).
---> s/robocop/terminator/
# hd chiffré + rsync
Posté par outs . En réponse au journal Et vous, quelle sécurité pour vos sauvegardes?. Évalué à 2.
C'est assez simple j'ai un disque usb chiffré. Pour le chiffrer, j'ai juste utilisé l'outil de gestion de disque d'ubuntu avec l'option idoine.
Après tous les mois (en théorie), je le branche et un petit coup de rsync :
Bon c'est pas la sécurité absolue, mais mes fichiers ne bougent pas tant que ça non plus. Ce qui m'ennuie le plus ça serait le cas d'incendie ou de vol...
[^] # Re: Langage Google: non merci !
Posté par outs . En réponse à la dépêche Quelques nouvelles rapides du langage Go. Évalué à 7.
Syntax error: French language implies space before "?"
Syntax error: Agreement between verb "aime" and noun "développeurs" does not fit
^_^
[^] # Re: Et pis .....thon
Posté par outs . En réponse au journal Lamentations ou les remords d'un geek. Évalué à 3.
Perso j'ai toujours regretté que dans OCaml il soit impossible de définir des classes de types. Par exemple il y a une addition + pour les entiers et une addition +. pour les flottants, mais ce n'est pas limité à ca le code Caml est rempli de fonction qui font le même type d'opération avec des nom légèrement différent à cause de cette limitation.
Sinon Haskell est un standard avec plusieurs compilo dispo, ce qui assure une certaine stabilité. Alors que Ocaml est géré par une équipe de l'INRIA dans un but de recherche.
Les deux langages possèdes des compilo très efficaces, avec de bonnes optimisations et génération de code natif. Ce qui est important pour contrebalancer la lenteur potentielle de la prog fonc.