Après avoir vu cette vidéo, la réponse pourrait être « pas grand chose » ;)
Dans cette vidéo, on peut voir que Ruby se débrouille plutôt bien en ce qui concerne :
les high-order functions :
map=proc{|f,coll|# definition of a map functioncoll.map(&f)# using Enumerable#map…}inc=proc{|x|x+1}# proc that adds 1 to inputnums=[2,3,4]# data for us to map overmap.call(inc,nums)# returns [3, 4, 5]map.(inc,nums)# syntactic sugar to hide the `call`
le currying :
add=proc{|x,y|x+y}.curry# native curryingadd.(2,3)# returns 5inc=add.(1)# returns an add function with first argument pre-set as 1inc.(2)# returns 3map.(inc,[2,3,4])# returns [3, 4, 5]
la composition (de fonctions bien sûr) :
compose=proc{|x,y|proc{|*args|x.(y.(*args))}}inc=add.(1)# a inc functionadd2=add.(2)# a dec functionadd3=compose.(inc,add2)# returns a composition of inc and decadd3.(4)# returns 7, equivalent to `add2(inc(4))`# Personal bonus, or how to be more Haskel friendlyclassProc# Proc class monkey patched, MER IL ET FOUdef>>(f)returnproc{|*args|f.(self.(*args))}endendinc=add.(1)# an inc functionadd2=add.(2)# a dec functionadd3=inc>>add2# Haskel friendly composition ;Dadd3.(4)# returns 7, equivalent to `add2(inc(4))`
Le choix d'une licence GPL est sans doute plus approprié pour ce projet qu'une licence de type BSD/MIT. Cependant, la GPL n'est pas une protection suffisante pour ce qui concerne les services utilisables via le réseau. Techniquement, l'utilisateur n'exécute pas lui même le code du serveur (ici php). De ce fait, la GPL ne s'applique pas sur cette portion de code. Si je me trompe pas, je crois même que je peux légalement copier la partie serveur du projet, faire des modifications et en faire un site/application close source.
Tout ça pour dire que je recommande au projet L'Air du Bois la licence AGPL. Elle est l'équivalent de la GPL tout en prenant en compte l'utilisation de services sur le réseau.
Pour lancer Pharo, tu dois passer une image Pharo en paramètre de la commande pharo.
Par exemple :
pharo Pharo.image
Si tu cherches à comprendre ce qui se passe, je dirai que la commande pharo est le lanceur et l'image est l'environnement Pharo que tu souhaites démarrer. Après je suis pas très sûr de moi sur ce coup là.
Et surtout, je te conseille de télécharger la toute dernière version de Pharo qui vient d'être publiée sur le site aujourd'hui. Elle commence avec une documentation ouverte, ça aide.
Smalltalk est souvent considéré non pas comme un langage mais comme une famille de langage, comme l'est Lisp. On peut donc dire que Pharo est un dialecte de Smalltalk. Ou bien, pour être plus précis : un dialecte de Smalltalk + une VM + une bibliothèque standard + un environnement de développement.
Si l'on regarde GNU Smalltalk (qui lui ne propose pas d'environnement de développement), on peut remarquer que certaines constructions du langage n'existent pas dans Pharo, notamment pour ce qui est de la déclaration de classe et de méthode.
Le protocole, c'est la façon dont les nœuds communique entre eux. Le logiciel (dans notre cas), c'est une implémentation (serveur ou/et client) qui utilise un protocole.
Par exemple, Movim et SàT sont bien deux logiciels différents. Ils ne proposent pas la même interface, ne proposent pas forcément les mêmes fonctionnalités, évoluent chacun de leur côté indépendamment de l'autre. Cependant, ils utilisent le protocole XMPP et s'y conformes, leur permettant d'interagir sans avoir à faire un développement spécifique.
Il y a sans doute beaucoup d'exemples encore : IP - machines, HTTP - navigateurs, etc.
Ha, pour ça tu as 2 solutions :
1. Tu remappe tous les raccourcis pour tomber sur les même touches physique
2. Tu laisse tel que mais tu perd la logique de certains raccourcis (hjkl par ex)
Pour la solution #1, ne pas oublier que tu perds le sens de ce que tu tapes.
Et c'est bien là le problème : le beurre ou l'argent du beurre ? Je ne vois pas de solution autre que de se taper la crémière ; entendre par là un retour à Qwerty :) En somme, tant pis pour moi.
Pour que l'utilisateur comprenne bien et vite que c'est une commande relative à l'outil Git.
Après, rien ne t'empêche aliaser "git gws/git ws/git workspace" en "gws" de ton côté. Un indice : "git workspace" est sans doute la meilleur des trois propositions et éviter les alias barbares permet de « parler » une langue commune :)
En effet. Niveau décentralisation, c'est le même principe (avec un protocole unique, pas 3).
Mais au niveau des possibilités, on parle plus de la même chose. Le courrier électronique n'est qu'un type de message qui peut être communiqué via XMPP.
Et en fait c'est a peu près la même chose pour tout ce qui est XMPP: il y a un gros effort de fait pour standardiser les pratiques, mais ça prend du temps et on en arrive a avoir besoin une bonne dizaine de XEPs pour des besoins "standards"
Très juste, ça prend beaucoup de temps. Un peu comme designer une nouvelle solution from scratch…
Ben justement, non. Tu peux te créer ton compte sur ton nœud, ou utiliser un identifiant externe qui sera traduit en identifiant utilisable dans matrix, comme ton addresse email actuelle par exemple.
C'est ce que j'appelle créer un compte sur une nouvelle plate-forme :)
Si tu n'as comme besoin en communication que le chat distribué, je comprends que ça te satisfasse. Perso, je mail, je discute en instantané, je suis des flux, etc. Et j'aime pouvoir faire ça avec le même compte. J'espère vraiment que XMPP s'améliore et se démocratise. Quand on voit des projets comme Movim, cela semble être en bonne voie.
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.
XMPP est vraiment construit de manière à être extensible tout en se permettant d'imposer certaines règles.
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.
Si Matrix évolue, les possibles multiples clients et serveurs vont se patcher tout seuls ? :)
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.
Si tout le monde choisit ses divers protocoles pour ses divers besoins de communication, on vit de moins en moins sur le même Internet.
Le site explique bien le principe. Je vois pas trop l’intérêt de décentraliser une chat room, mais supposons ! Le MUC ne fonctionne pas de cette manière, mais rien empêche de créer une nouvelle extension à XMPP. Après, on peut rediscuter de la vitesse de standardisation du bouzin…
Tout ça pour dire que c'est techniquement intéressant, mais très dommage de devoir encore créer un nouveau compte sur une nouvelle plate-forme pour répondre à un nouveau besoin. XMPP est extensible et ce n'est pas « génant ».
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 ;)
[^] # Re: Bébé de RMS ?
Posté par lepieru . En réponse à la dépêche GNU Emacs 26.1. Évalué à 1.
Sans doute.
Je rajouterai même que RMS ne fait plus parti des mainteneurs de GNU Emacs depuis un bon moment (source : https://lists.gnu.org/archive/html/emacs-devel/2008-02/msg02140.html).
# Typo dans le titre : racourcis -> raccourcis
Posté par lepieru . En réponse au journal XFCE/Gtk et raccourcis type Bash/Emacs. Évalué à 0.
Si un admin pouvait corriger le titre et supprimer ce commentaire, merci d'avance ;)
# Dure vie pour Ruby
Posté par lepieru . En réponse au journal Tous les parsers JSON sont mauvais. Évalué à 3.
La bibliothèque
JSON
inclue dans Ruby (MRI) nécessite d'expliciter la désactivation de la vérification de la profondeur comme ci-dessous :Voir la documentation de la fonction
JSON.parse
.PS: si la profondeur maximum (
max_nesting
) est dépassée, la bibliothèqueJSON
ne « plante » pas, elle soulève une exception :)[^] # Re: Ruby <3
Posté par lepieru . En réponse à la dépêche Pendant ce temps, dans l’écosystème Ruby. Évalué à 3.
Après avoir vu cette vidéo, la réponse pourrait être « pas grand chose » ;)
Dans cette vidéo, on peut voir que Ruby se débrouille plutôt bien en ce qui concerne :
[^] # Re: Ruby <3
Posté par lepieru . En réponse à la dépêche Pendant ce temps, dans l’écosystème Ruby. Évalué à 1.
Qu'est-ce qui vous manque dans Ruby au niveau de la programmation fonctionnelle ? Et pourquoi plutôt se diriger vers Elixir/Phoenix ?
[^] # Re: PlantUML
Posté par lepieru . En réponse à la dépêche Écrire des diagrammes de séquences. Évalué à 1.
git clone https://github.com/plantuml/plantuml
et bon courage ! :)# Licence GPL ?
Posté par lepieru . En réponse à la dépêche L'Air du Bois devient Open Source !. Évalué à 4.
Le choix d'une licence GPL est sans doute plus approprié pour ce projet qu'une licence de type BSD/MIT. Cependant, la GPL n'est pas une protection suffisante pour ce qui concerne les services utilisables via le réseau. Techniquement, l'utilisateur n'exécute pas lui même le code du serveur (ici php). De ce fait, la GPL ne s'applique pas sur cette portion de code. Si je me trompe pas, je crois même que je peux légalement copier la partie serveur du projet, faire des modifications et en faire un site/application close source.
Tout ça pour dire que je recommande au projet L'Air du Bois la licence AGPL. Elle est l'équivalent de la GPL tout en prenant en compte l'utilisation de services sur le réseau.
[^] # Re: Tuto ?
Posté par lepieru . En réponse à la dépêche Sortie du langage Pharo et de son environnement de développement en version 5.0. Évalué à 2.
Pour lancer Pharo, tu dois passer une image Pharo en paramètre de la commande
pharo
.Par exemple :
Si tu cherches à comprendre ce qui se passe, je dirai que la commande
pharo
est le lanceur et l'image est l'environnement Pharo que tu souhaites démarrer. Après je suis pas très sûr de moi sur ce coup là.Et surtout, je te conseille de télécharger la toute dernière version de Pharo qui vient d'être publiée sur le site aujourd'hui. Elle commence avec une documentation ouverte, ça aide.
[^] # Re: Description curieuse
Posté par lepieru . En réponse à la dépêche Sortie du langage Pharo et de son environnement de développement en version 5.0. Évalué à 3.
Smalltalk est souvent considéré non pas comme un langage mais comme une famille de langage, comme l'est Lisp. On peut donc dire que Pharo est un dialecte de Smalltalk. Ou bien, pour être plus précis : un dialecte de Smalltalk + une VM + une bibliothèque standard + un environnement de développement.
Si l'on regarde GNU Smalltalk (qui lui ne propose pas d'environnement de développement), on peut remarquer que certaines constructions du langage n'existent pas dans Pharo, notamment pour ce qui est de la déclaration de classe et de méthode.
# News officielle
Posté par lepieru . En réponse à la dépêche Sortie du langage Pharo et de son environnement de développement en version 5.0. Évalué à 1.
La news officielle vient de tomber : http://pharo.org/news/pharo-5.0-released
# Gestionnaire de package : shards
Posté par lepieru . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 2.
À notez que Crystal est livré avec son gestionnaire de package nommé shards. Il n'y a pas de dépôt centralisé comme avec RubyGem ou encore npm.
[^] # Re: ça a l'air super, mais...
Posté par lepieru . En réponse à la dépêche Sortie de Hubzilla 1.1. Évalué à 2.
Le protocole, c'est la façon dont les nœuds communique entre eux. Le logiciel (dans notre cas), c'est une implémentation (serveur ou/et client) qui utilise un protocole.
Par exemple, Movim et SàT sont bien deux logiciels différents. Ils ne proposent pas la même interface, ne proposent pas forcément les mêmes fonctionnalités, évoluent chacun de leur côté indépendamment de l'autre. Cependant, ils utilisent le protocole XMPP et s'y conformes, leur permettant d'interagir sans avoir à faire un développement spécifique.
Il y a sans doute beaucoup d'exemples encore : IP - machines, HTTP - navigateurs, etc.
# Dans le même genre : le Comptoir Sécu
Posté par lepieru . En réponse à la dépêche Podcast francophone dédié à la cybersécurité : No Limit Secu. Évalué à 2.
Tout est dans le titre. Ou presque…
[^] # Re: Offres oss: Bientôt le 1 avril tous les jours.
Posté par lepieru . En réponse au journal Code libre/oss : offre proprio ?. Évalué à 1.
Pour sortir du flou risible de ce commentaire, je me permets de préciser.
Source : https://www.gnu.org/philosophy/free-sw.html
[^] # Re: Raccourcis souris
Posté par lepieru . En réponse au journal Faire de la magie avec son .inputrc. Évalué à 1.
Pas mal ! Mais j'ai une petite préférence pour les raccourcis trackball ;)
[^] # Re: Copaing :-þ
Posté par lepieru . En réponse à la dépêche Seconde session TupperVim le 28 mars 2015 aux JDLL à Lyon. Évalué à 1.
Pour la solution #1, ne pas oublier que tu perds le sens de ce que tu tapes.
Et c'est bien là le problème : le beurre ou l'argent du beurre ? Je ne vois pas de solution autre que de se taper la crémière ; entendre par là un retour à Qwerty :) En somme, tant pis pour moi.
Ahah… Emacs :)
[^] # Re: Copaing :-þ
Posté par lepieru . En réponse à la dépêche Seconde session TupperVim le 28 mars 2015 aux JDLL à Lyon. Évalué à 1.
Dommage qu'un layout autre qu'une variante de Qwerty fasse perdre de l'intérêt à l'utilisation de Vim (et vice versa).
De mon côté, ayant été séduit par un layout alternatif, j'ai (dû?) abandonné Vim pour un autre.
[^] # Re: L’utiliser en tant que sous commande git.
Posté par lepieru . En réponse au journal Gérer son espace de travail git avec "gws". Évalué à 1.
Pour que l'utilisateur comprenne bien et vite que c'est une commande relative à l'outil Git.
Après, rien ne t'empêche aliaser "git gws/git ws/git workspace" en "gws" de ton côté. Un indice : "git workspace" est sans doute la meilleur des trois propositions et éviter les alias barbares permet de « parler » une langue commune :)
Félicitation pour ton outil.
[^] # Re: Cette roue roule vachement plus vite !
Posté par lepieru . En réponse au journal Pas seul dans la matrice. Évalué à 0.
En effet. Niveau décentralisation, c'est le même principe (avec un protocole unique, pas 3).
Mais au niveau des possibilités, on parle plus de la même chose. Le courrier électronique n'est qu'un type de message qui peut être communiqué via XMPP.
[^] # Re: Cette roue roule vachement plus vite !
Posté par lepieru . En réponse au journal Pas seul dans la matrice. Évalué à -3.
Effectivement, il impose ce XMPP !
C'est un protocole de diffusion décentralisé de message. J'aimerai juste ne pas en utiliser 36 qui fasse le même job :)
[^] # Re: Cette roue roule vachement plus vite !
Posté par lepieru . En réponse au journal Pas seul dans la matrice. Évalué à 0.
Très juste, ça prend beaucoup de temps. Un peu comme designer une nouvelle solution from scratch…
C'est ce que j'appelle créer un compte sur une nouvelle plate-forme :)
[^] # Re: Cette roue roule vachement plus vite !
Posté par lepieru . En réponse au journal Pas seul dans la matrice. Évalué à -2.
Si tu n'as comme besoin en communication que le chat distribué, je comprends que ça te satisfasse. Perso, je mail, je discute en instantané, je suis des flux, etc. Et j'aime pouvoir faire ça avec le même compte. J'espère vraiment que XMPP s'améliore et se démocratise. Quand on voit des projets comme Movim, cela semble être en bonne voie.
XMPP est vraiment construit de manière à être extensible tout en se permettant d'imposer certaines règles.
Si Matrix évolue, les possibles multiples clients et serveurs vont se patcher tout seuls ? :)
Si tout le monde choisit ses divers protocoles pour ses divers besoins de communication, on vit de moins en moins sur le même Internet.
# Cette roue roule vachement plus vite !
Posté par lepieru . En réponse au journal Pas seul dans la matrice. Évalué à 6.
Le site explique bien le principe. Je vois pas trop l’intérêt de décentraliser une chat room, mais supposons ! Le MUC ne fonctionne pas de cette manière, mais rien empêche de créer une nouvelle extension à XMPP. Après, on peut rediscuter de la vitesse de standardisation du bouzin…
Tout ça pour dire que c'est techniquement intéressant, mais très dommage de devoir encore créer un nouveau compte sur une nouvelle plate-forme pour répondre à un nouveau besoin. XMPP est extensible et ce n'est pas « génant ».
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 ;)
# Et c'est filmé ?
Posté par lepieru . En réponse au journal Conférence sur la vie privée à l'heure d'Internet. Évalué à 1.
Se serait intéressant de filmer la conférence. C'est prévu ?