[ANN] Release 0.32.0 of Counterclockwise

[Laurent PETIT]

Counterclockwise, the Eclipse Clojure development tool.

Counterclockwise 0.32.0 has been released.

Highlights:

- Clojure 1.7.0 support

- Cider-nrepl support

- Clojurescript support

- macro-expansion via editor hovers

- Embedded User plugins such as : font zoom mode for presentations, ANSI Colors in the REPL

- tons of small enhancements and bugs fixes (total 62 issues closed https://github.com/laurentpetit/ccw/issues?q=milestone%3A0.32.0+is%3Aclosed)

ChangeLog

=========

http://doc.ccw-ide.org/ChangeLog.html#_changes_between_counterclockwise_0_31_1_and_0_32_0

Installation instructions

==================

http://doc.ccw-ide.org/documentation.html#_install_counterclockwise

Cheers,

--

Laurent Petit

[Laurent PETIT]

I have forgotten to thank Andrea Richiardi for his involvement in this release content.

He is the author of many enhancement and fixes, including but not limited to 

- addition of macro-expansion hovers, and a generic hover extension for facilitating the ulterior addition of new kinds of hovers

- better automated UI tests

- integration of SWTBotRecorder to help users report bugs in the future

- making the tracing feature work and be usable from the Preferences UI

- ...

Thank you again, Andrea !

--

Laurent Petit

[Laurent PETIT]

No, just a problem in your syntax analyzer, which does not seem to know that Andrea can also be a surname given to males in Europe.

Same for Cecil, in the opposite direction: in France, Cecile is generally given to females.

Cheers,

2015-07-30 13:02 GMT+02:00 Fluid Dynamics <a209...@trbvm.com>:

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?

--

Laurent Petit

[François]

A premiere vue c'est un tres, tres bon cru cette release, et vraiment bienvenue!

Bravo et (* 1000 merci) pour le zoom, macroexpand, les commandes lein, et surtout le support nickel de cljs!

Juste un bemol sur la doc autour de cljs et cider : un peu complecte, du coup j'ai tente figwheel et ca marche direct, repl inclus ^^

A mesurer sur la distance, particulierement le systeme de plugins qui semble "beautifully simple", mais si la promesse est tenue, ca va etre un sacre hit de l'ete !

Vive ccw!

[Laurent Petit]

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. 

Tldr: les idées ne manquent pas, c'est plus parfois la paralysie face au choix qu'autre chose dans ma tête :-)

D'un point de vue utilisateur, qu'est-ce qui vous exciterait le plus dans la prochaine "grosse" release de ccw ?

—
Envoyé avec Mailbox

[François De Serres]

Reponses la dessous 

vvv

On 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 ^^

[Laurent PETIT]

Salut, 

Merci pour tes réponses directes, ça me relance la boîte à idées :-)

Un nouveau petit tour de réponses dans les réponses, si tu veux bien :-)

Le 31 juillet 2015 15:10, François De Serres <francois....@gmail.com> a écrit :

Reponses la dessous 

vvv

On 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 ?

Tu as raison.

 

 

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 ?

Oui, LOL, je viens de me coltiner un "petit" bug (en apparence) qui m'a pris 2 soirées complètes pour au final 4 lignes de code, mais encore fallait-il les trouver (gargl) !

Je travaille encore à simplifier les entrailles de CCW pour le rendre accessible. J'essaie le plus possible d'imaginer n'importe quel nouveau développement "comme si" je le faisais en "User Plugin" et ça me permet de mieux factoriser entre ce qui "masque les entrailles d'Eclipse" et ce qui est plus du "métier".

Ca avance petit à petit. Mais je pense qu'il faudra encore quelques mois avant que des "low hanging fruits" en apparence le soient vraiment en réalité !

 

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

C'est ce que je fais d'habitude sur la ml ccw, j'ai voulu poser la question ici, pour changer, et puis je t'avais sous la main ;-)

 

- 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 ^^

Oui, c'est moins prioritaire que d'autres choses, certes. Mais ça me gratte, ça me démange, alors je risque d'y aller malgré tout :-)

Je ne pense pas faire en asynchrone la constitution, par ex., de la liste. Effectivement ça il faut que ça reste synchrone.

Ce que je pense faire en asynchrone, c'est la mise à jour du "modèle" interrogé par la liste. Actuellement, la liste interroge en live la REPL. La constitution de la liste est donc dépendante de la charge de la JVM cliente, transporte via les protocoles réseau souvent les mêmes informations ...

Je veux séparer la production du modèle et le requêtage du modèle.

Dans un premier temps, la production du modèle sera juste faite dynamiquement, avec des mises à jour régulières en fonction d'actionneurs divers (interaction avec la REPL).

La bonne nouvelle, c'est que le modèle peut être sauvegardé sur disque, donc par exemple, au redémarrage suivant d'Eclipse, ou s'il n'y a plus de REPL, on pourra continuer à faire de la complétion basée sur la dernière version connue du modèle.

Ce modèle faisant l'interface entre la production et la consommation, il sera plus simple d'ajouter plus tard de nouvelles façons de mettre à jour ce modèle (analyse purement statique, I'm looking at you).

 

Concernant la taille des fichiers, non prioritaire itou. C'est plutot un bon moyen d'inviter au refactoring...

Pareil à terme pour la coloration syntaxique : il vaut mieux avoir des couleurs pas à jour pendant 1/2s mais la vitesse de frappe intacte, plutôt que d'attendre (et ça va vite, sur mon "vieux" Mac Book Air de 2012, sur des fichiers un peu gros de CCW je sens des lags qui me gratouillent).

 

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

Oui, tu as bien raison. Bonne nouvelle : ça ne me gratouille pas plus que ça. Je crois qu'il sera plutôt préférable, comme tu disais, d'ouvrir un blog ou une section dédiée dans la documentation pour expliquer comment utiliser tel ou tel outil avec CCW.

 

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

pas compris ce que tu voulais dire par "naviguer dans le code objet plutôt que le source ... closed-over-values ? egares-toi stp !" => tu peux m'expliquer plus en détails ?

 

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

oui, il y en a qui ont déjà des idées pour faire des packages managers à la Sublime Text. Très bonne idée ... pour dans très longtemps. Entretemps, ceux qui auront le niveau technique pour faire des User Plugins auront aussi le niveau pour faire un git clone, donc absolument pas dans mes priorités.

 

 

- 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 ^^

C'est sûr que ça aiderait s'il y avait du prosélytisme pour CCW qui vient de l'extérieur de l'équipe de développement, et probablement sous forme d'articles en anglais expliquant comment utiliser figwheel avec CCW 0.32, à quoi ressemble le workflow, etc. :-)

--

Laurent Petit