On Thursday, July 30, 2015 at 5:43:39 AM UTC-4, Laurent PETIT wrote:I have forgotten to thank Andrea Richiardi for his involvement in this release content.
^^^^^^ ^^^
Syntax error, line 1: Clauses do not agree as to grammatical gender.
Typo somewhere?
Salut François,Merci pour ton enthousiasme et tes retours positifs et constructifs!
Tu as raison, figwheel a la cote et je devrai arrêter de le négliger. Comme je ne fais pas de projet cljs moi-même, je connais moins ce monde. Il faudrait, sans que je me disperse top non plus, que j'ajoute à mon arc un petit side-projet cljs :-) (pourquoi pas une version tout html + bootstrapped clojurescript de la vue Repl qui communiquerait via edn ou transit avec ccw? (Hic: plus de test cross-OS à faire car chaque version d'éclipse utilise un moteur un peu différent pour son internal html browser ?). Ça y est, je m'egare déjà :-)
Je profite de cette grosse release, et de l'attente de l'arrivée des bugs au fur et à mesure que les utilisateurs y passent, pour corriger des petits bugs qui ont été rapportés depuis longtemps,
mais aussi réfléchir à mon prochain gros chantier. Il y en a qui me plaisent plus que d'autres comme challenges, mais j'aimerais aussi récolter un feed-back utilisateur pour faire un contre-pouvoir à mes aspirations de dev:
- chantier performance éditeur:il s'ouvre lentement et on sent un lag à la frappe sur de gros fichiers (ccw/core.clj est le test étalon). La complétion aussi peut se mettre à jouer des tours car elle rend la réactivité du thread UI dans éclipse dépendante de la communication à une Repl. Solution = découplage du thread UI des process qui peuvent être coûteux. Réactivité de la frappe avant tout.
- chantier leiningen:mea culpa. Ne jamais dépendre d'un projet plus instable que le sien. C'est pourtant un principe de base, mais la voix des sirènes est si belle ! Je n'aurai pas dû essayer d'embarquer leiningen.core dans la jvm de ccw. Je voulais simplifier la communication en ayant accès direct à ses fonctions. Ça a force à plein de contournements pour isoler des leiningen par projet, hot patcher des endroits de leiningen où il fallait éviter que certains plugins n'appellent du code qui tue la jvm, jongler avec la propriété globale système Java "user.dir", etc. Et maintenant il y a boot qui est le new kid on the block. Avant le suivant dans 1 an. Donc clairement, je veux revenir à un traitement plus simple de ces librairies de build: considérer que leur API, c'est construire des command-line appropriées. Ça simplifiera l'architecture interne de ccw et permettre d'intégrer de nouveaux outils de build plus facilement.
- chantier analyse statique de code:une force de cursive est sa capacité à fournir un Max de services sans qu'une Repl ait besoin d'être allumée. Ce choix n'avait pas été fait immédiatement pour ccw pour des raisons d'ordre pragmatique (au vu des ressources disponibles, plus rapide et efficace de récupérer les infos via un Repl), et aussi des considérations théoriques (j'en suis un peu revenu): une analyse statique ne sera jamais parfaite car il lui manque la possibilité d'exécuter les macros et donc de connaître leurs effets sur l'environnement global et lexical de certaines parties du code. Néanmoins, j'avais l'intuition qu'avec des heuristiques bien calibrées, un peu d'astuce et d'espièglerie, on pouvait faire un truc pas mal. J'en ai rêve, cursive l'a fait. Il est peut être temps de le faire aussi dans ccw. Pas si complique je pense (En mode 80/20), mais il y a encore une partie de moi qui trouve dommage qu'on ne puisse récupérer ce qui est fait dans cursive (l'arlesienne du "une partie de cursive" -laquelle?- sera en open source un de ces 4), de ne pas succomber au NIH (il y a un chantier GSoC sur la documentation des librairies). Alors j'hésite, mais le sujet est intéressant et je plongerai sûrement dedans rien que pour l'intérêt d'essayer ma propre solution :-)
- chantier user plugins : il y a énormement à faire pour que ça soit vraiment utilisable par des utilisateurs. L'api Eclipse est tellement indigeste qu'il faut absolument fournir une api clojure par-dessus, simplifiant les possibilités offertes par Eclipse mais se concentrent sur l'essentiel, et orienté Data !
- communication autour de ccw : un bon produit mal vendu c'est du gâchis. Il fait que je trouve un moyen de faire faire aux autres, ou du temps pour faire, des blogs qui montrent des points de l'utilisation de ccw pour donner envie d'essayer.
Reponses la dessousvvvOn Fri, Jul 31, 2015 at 4:46 AM Laurent Petit <lauren...@gmail.com> wrote:Salut François,Merci pour ton enthousiasme et tes retours positifs et constructifs!C'est la moindre des choses ! Et j'invite tous mes copains a en faire autant ^^Je rappelle juste que Rich himself considere ccw comme une piece strategique pour clojure en general (citation needed).Tu as raison, figwheel a la cote et je devrai arrêter de le négliger. Comme je ne fais pas de projet cljs moi-même, je connais moins ce monde. Il faudrait, sans que je me disperse top non plus, que j'ajoute à mon arc un petit side-projet cljs :-) (pourquoi pas une version tout html + bootstrapped clojurescript de la vue Repl qui communiquerait via edn ou transit avec ccw? (Hic: plus de test cross-OS à faire car chaque version d'éclipse utilise un moteur un peu différent pour son internal html browser ?). Ça y est, je m'egare déjà :-)Si tu ne t'egarais pas de temps en temps ccw existerait-il ? Concernant figwheel, ne touche a rien pour le moment, ca marche tout seul ! ***Dis-le*** et laisse les utilisateurs remonter leurs eventuels soucis ?
Je profite de cette grosse release, et de l'attente de l'arrivée des bugs au fur et à mesure que les utilisateurs y passent, pour corriger des petits bugs qui ont été rapportés depuis longtemps,Laisse les petits bugs aux volontaires ? Par contre il faut leur faciliter la vie au maximum, et la y a du boulot ;o) Vois plutot comment/si tu peux simplifier la version "contribution" et sa doc ? et trier le backlog ! +100 tickets c'est trop ;o) Ou sont les "low hanging fruits" qui te permettraient de deleguer a la communaute, et de pouvoir t'egarer plus souvent ?
mais aussi réfléchir à mon prochain gros chantier. Il y en a qui me plaisent plus que d'autres comme challenges, mais j'aimerais aussi récolter un feed-back utilisateur pour faire un contre-pouvoir à mes aspirations de dev:Pourquoi pas un fil dedie a chaque (un seul) sujet, dans un groupe dedie a ccw ? Tu pourrais mesurer instantanement l'interet et les priorites...
- chantier performance éditeur:il s'ouvre lentement et on sent un lag à la frappe sur de gros fichiers (ccw/core.clj est le test étalon). La complétion aussi peut se mettre à jouer des tours car elle rend la réactivité du thread UI dans éclipse dépendante de la communication à une Repl. Solution = découplage du thread UI des process qui peuvent être coûteux. Réactivité de la frappe avant tout.Le temps au lancement n'est pas une priorite selon moi. Ne pas confondre IDE et editeur, vi se lancera toujours plus vite qu'emacs. Ma session ccw peut durer plusieurs jours, toi tu le sens car tu dois relancer souvent. En plus c'est un probleme herite JVM + Eclipse, donc bon courage !La completion : pareil, je ne m'en sers pas en auto. Si tu as un quick fix vas-y, mais je pense que l'asynchroniser peut etre galere car c'est par constitution une fonctionnalite synchrone (a la frappe / position). Faire un pre-lookup en background fera chauffer un core pour des resultats deja obsoletes au retour dans 99% des cas. Segolene n'aimera pas ca ^^
Concernant la taille des fichiers, non prioritaire itou. C'est plutot un bon moyen d'inviter au refactoring...
- chantier leiningen:mea culpa. Ne jamais dépendre d'un projet plus instable que le sien. C'est pourtant un principe de base, mais la voix des sirènes est si belle ! Je n'aurai pas dû essayer d'embarquer leiningen.core dans la jvm de ccw. Je voulais simplifier la communication en ayant accès direct à ses fonctions. Ça a force à plein de contournements pour isoler des leiningen par projet, hot patcher des endroits de leiningen où il fallait éviter que certains plugins n'appellent du code qui tue la jvm, jongler avec la propriété globale système Java "user.dir", etc. Et maintenant il y a boot qui est le new kid on the block. Avant le suivant dans 1 an. Donc clairement, je veux revenir à un traitement plus simple de ces librairies de build: considérer que leur API, c'est construire des command-line appropriées. Ça simplifiera l'architecture interne de ccw et permettre d'intégrer de nouveaux outils de build plus facilement.Oui ! tu t'en sors bien encore cette fois-ci, mais tu dois y avoir laisse quelques cheveux... ne remets pas ca avec figwheel ou autre :o)
- chantier analyse statique de code:une force de cursive est sa capacité à fournir un Max de services sans qu'une Repl ait besoin d'être allumée. Ce choix n'avait pas été fait immédiatement pour ccw pour des raisons d'ordre pragmatique (au vu des ressources disponibles, plus rapide et efficace de récupérer les infos via un Repl), et aussi des considérations théoriques (j'en suis un peu revenu): une analyse statique ne sera jamais parfaite car il lui manque la possibilité d'exécuter les macros et donc de connaître leurs effets sur l'environnement global et lexical de certaines parties du code. Néanmoins, j'avais l'intuition qu'avec des heuristiques bien calibrées, un peu d'astuce et d'espièglerie, on pouvait faire un truc pas mal. J'en ai rêve, cursive l'a fait. Il est peut être temps de le faire aussi dans ccw. Pas si complique je pense (En mode 80/20), mais il y a encore une partie de moi qui trouve dommage qu'on ne puisse récupérer ce qui est fait dans cursive (l'arlesienne du "une partie de cursive" -laquelle?- sera en open source un de ces 4), de ne pas succomber au NIH (il y a un chantier GSoC sur la documentation des librairies). Alors j'hésite, mais le sujet est intéressant et je plongerai sûrement dedans rien que pour l'intérêt d'essayer ma propre solution :-)Nein. Personne n'ecrit de clojure sans un repl ouvert. C'etait vrai pour clojurescript a cause de la relative complexite de setup d'un repl cljs, y compris avec Cursive. Dieu merci c'est fini avec ccw (justement parcequ'il embarque leiningen ?). Naviguer dans le code objet plutot que le source est un atout dont on n'a pas fini de mesurer la portee (closed-over-values ? egares-toi stp !). Le macroexpand dans ccw est une killer feature qu'une analyse statique aurait bien du mal a fournir de facon correcte.
- chantier user plugins : il y a énormement à faire pour que ça soit vraiment utilisable par des utilisateurs. L'api Eclipse est tellement indigeste qu'il faut absolument fournir une api clojure par-dessus, simplifiant les possibilités offertes par Eclipse mais se concentrent sur l'essentiel, et orienté Data !Clair, peu de gens voudraient se lancer dans osgi + eclipse platform aujourd'hui, vous avez fait le bon choix, reste a voir a l'usage si l'apparente (demente !) simplicite des plugins ccw sera pour le meilleur ou...? A garder sous controle absolument si tu ne veux pas passer ton temps a debugger pour les autres ;o)
- communication autour de ccw : un bon produit mal vendu c'est du gâchis. Il fait que je trouve un moyen de faire faire aux autres, ou du temps pour faire, des blogs qui montrent des points de l'utilisation de ccw pour donner envie d'essayer.Je n'ai pas de blog (il y en a deja tellement a lire, et j'ecris rarement autant que je viens de le faire), mais tu peux compter sur moi pour promouvoir ccw chaque fois que je pourrai ! En plus c'est made in france, trop hype ^^