lepieru a écrit 24 commentaires

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).

Si un admin pouvait corriger le titre et supprimer ce commentaire, merci d'avance ;)

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 :

JSON.parse(ARGF.read, max_nesting: false)

Voir la documentation de la fonction JSON.parse.

PS: si la profondeur maximum (max_nesting) est dépassée, la bibliothèque JSON ne « plante » pas, elle soulève une exception :)

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 function
  coll.map(&f)           # using Enumerable#map…
}

inc = proc { |x| x + 1 } # proc that adds 1 to input
nums = [2, 3, 4]         # data for us to map over
map.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 currying
add.(2, 3)           # returns 5
inc = add.(1)        # returns an add function with first argument pre-set as 1
inc.(2)              # returns 3
map.(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 function
add2 = add.(2)             # a dec function
add3 = compose.(inc, add2) # returns a composition of inc and dec
add3.(4)                   # returns 7, equivalent to `add2(inc(4))`

# Personal bonus, or how to be more Haskel friendly

class Proc         # Proc class monkey patched, MER IL ET FOU
  def >>(f)
    return proc { |*args|
      f.(self.(*args))
    }
  end
end

inc = add.(1)      # an inc function
add2 = add.(2)     # a dec function
add3 = inc >> add2 # Haskel friendly composition ;D
add3.(4)           # returns 7, equivalent to `add2(inc(4))`

Qu'est-ce qui vous manque dans Ruby au niveau de la programmation fonctionnelle ? Et pourquoi plutôt se diriger vers Elixir/Phoenix ?

git clone https://github.com/plantuml/plantuml et bon courage ! :)

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.

La news officielle vient de tomber : http://pharo.org/news/pharo-5.0-released

À 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.

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.

Tout est dans le titre. Ou presque…

• le site du Comptoir Sécu : http://www.comptoirsecu.fr/category/menu/
• le flux du Comptoir Sécu : http://www.comptoirsecu.fr/category/menu/feed/

Pour sortir du flou risible de ce commentaire, je me permets de préciser.

“Free software” is a matter of liberty, not price. To understand the concept, you should think of “free” as in “free speech,” not as in “free beer”.

Source : https://www.gnu.org/philosophy/free-sw.html

Pas mal ! Mais j'ai une petite préférence pour les raccourcis trackball ;)

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.

Tu es passé sur quel éditeur du coup ?

Ahah… Emacs :)

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.

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.

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.

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 :)

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 ;)

Se serait intéressant de filmer la conférence. C'est prévu ?