Cordeworker se matérialise comme un interpréteur d'un langage de script intégrant la possibilité de définir une grammaire BNF du langage à parser ou du source cible dans lequel on veut injecter du code. La génération se décrit à l'aide de modèles de génération (template-based scripts), décrivant le remplissage d'un graphe de parsing pendant l'analyse. Ce graphe pourra ensuite être manipulé.
Sa force réside dans sa souplesse totale : on peut lui faire lire un source en C++ ainsi que des information en XML, pour injecter du code dans du Java. Partant de là, et de grammaire BNF decrivant XML, Java, etc... on peut imaginer toutes sortes d'outils. Notons le mode JEdit prenant en charge la coloration syntaxique pour CodeWorker.
CodeWorker est donc un outil puissant, stable, qui a sûrement besoin de contributions comme des scripts pour analyser toutes sortes de langages et ainsi permettre de nombreuses manipulations !
![[en]](../images/en.png)
CodeWorker (1183 hits)![[fr]](../images/fr.png)
Tutoriel complet (1275 hits)-
Repository of scripts (218 hits)
-
Fiche sur Framasoft (433 hits)
> Lire la dépêche (56 commentaires, moyenne: 2,4).
Vous avez demandé le commentaire #886041.
Run by 
Cette page a été générée par Templeet en 0.0875s (dont 0.008 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Meta-object protocol?
Toute cette machinerie de parsing, de templates et de manipulation d'AST illustre bien que tout ça fonctionne à un mauvais niveau de représentation des données : celui de la syntaxe au lieu du modèle métier. Quelle est l'avantage de CodeWorker par rapport aux parsers habituels (yacc, antlr, packrat…) ?
D'ailleurs il existe un outil de ce genre appelé Ometa, inspiré d'un autre qui date des années 70 : http://www.cs.ucla.edu/~awarth/ometa/
Voir aussi une implémentation de brainf*ck avec Ometa, pour illustrer le bidule : http://www.swa.hpi.uni-potsdam.de/tutorials/cola/index.html
Sinon pour la manipulation de programmes qui semble l'utilité première de CodeWorker, rien ne vaut un langage réflexif. En Smallltalk pour rajouter programmatiquement une variable d'instance à une classe on fait Foo addInstVarName: 'baz'. Pour ajouter une méthode à une classe :
String compile: 'pan ^ self = ''coin'' ifTrue: [''argh''] ifFalse: [''mm po mal'']'
Et baste, le code est visible dans l'IDE, compilé et committable. Si il y a besoin de faire des traitements plus compliqués l'arbre syntaxique abstrait est dispo, et c'est le même que les refactorings et le compilateur manipulent. En Lisp c'est pareil (voire plus puissant) mais je laisse les experts préciser.
[^]Re: Meta-object protocol?
La je comprend pas tout tu peux expliquer un peut?
[^]Re: Meta-object protocol?
Une façon d'illustrer cette phrase est d'essayer de séparer dans sa tête le "que fait t'on?" et le "comment le fait on?". Le modèle métier est le "que fait t'on" et le code (la syntaxe) est le "comment fait on".
Notre boulot d'informaticien est de transformer le "quoi" en "comment", et il en résulte le code, qui tout en représentant le quoi, il ne l'est pas vraiment. Ce qui est un problème, parce que la seule et unique chose qui nous intéresse vraiment c'est le "quoi" : le "comment", finalement n'est qu'une machinerie technique.
Donc ce que Damien veut dire, c'est qu'on essaie d'extraire le quoi du comment (le métier a partir de la syntaxe), et il a parfaitement raison de dire que c'est une approche imparfaite : le code n'est pas fait pour représenter ce qu'on veut faire, mais uniquement comment on le fait.
Le souci est d'essayer d'élever le modèle métier a un niveau d'abstraction au plus près de la conception "humaine", c'est a dire, de l'épurer au maximum du "bruit" causé par les problématiques informatiques : le code, le "comment c'est fait". Le tout doit permettre de transformer ce modèle métier en code, autant que possible. (sinon on fait de l'UML au autre qui sert a rien mis a part faire aide mémoire et joli sur le paper board).
Pour compléter je suis tenté de faire un comparaison avec un code en un langage tel le C (qui serait le métier), et sont "image" assembleur (qui serait donc le code), de ce même code compilé. Les deux font la même chose, le même "comment", pourtant il est très difficile d'extraire le "quoi" du code assembleur, on a perdu de l'information précieuse sur le modèle d'origine, qui est dans la tête du développeur.
[^]Re: Meta-object protocol?
humm… presque ;-)
Modèle métier = les données et ce qu'on en fait, au niveau d'abstraction idéal (un dessin)
Syntaxe = la représentation, l'encodage de ces données sous un format précis, adapté au stockage/transport ou autre mais pas au manipulations "métier" (une suite d'octets en PNG)
Et si, le code est fait pour représenter ce qu'on veut faire. Le tout est d'avoir un langage de prog qui te force pas à explique comment à tout bout de champ. Même en Smalltalk:
"comment"
1 to: collection size do: [ :i | (collection at: i) faisCeciCela ]
"quoi"
collection do: [ :each | each faisCeciCela ]
[^]Re: Meta-object protocol?
Mouais... Le principe de séparer le code en fonctions appelable consiste à rendre le code déclaratif à certain endroits.
Le type Block de smalltalk/ruby/lisaac permet de faire plus de chose, mais il n'en reste pas moins que la sémantique opérationnelle, ie. effet de bord sur des données en mémoire, reste une sémantique du comment faire.
[^]Re: Meta-object protocol?
Oui bien sûr, mais tant que le "comment faire" est rangé dans les bonnes couches d'abstraction c'est pas trop grave.
Je voulais surtout faire remarquer que le code, idéalement, c'est lisible. Ce n'est pas une sorte de produit "sale" pour donner aux machines, comme le binaire :-)
[+] [^]Re: Meta-object protocol?
Ce code "sale" tu en as forcement besoin un moment ou un autre ;)
[^]Re: Meta-object protocol?
Je bosse en Smalltalk depuis deux ans. En Smalltalk, l'un des grands trucs c'est que tous les objets sont persistants par défaut. Donc en général on ne sérialise ni on ne parse jamais rien, et on n'utilise que très rarement des fichiers.
Si tu veux garder des des données il suffit de mettre les objets en question dans une variable, soit globale, soit d'instance de classe (par exemple l'équivalent du database.yml de ruby on rails, c'est un objet "connexionSpec" avec database/host/port/user/password en variables d'instances).
Donc si on a besoin d'accéder à des données, suffit de taper dans l'API des objets en question. Si l'API convient pas ou que pour raisons algorithmiques il faut vraiment réorganiser les données, pas besoin de parser, pas besoin de générer du code, il y a juste à créer la nouvelle structure de données à partir de l'originale.
Avec l'habitude on en vient à trouver ça pénible quand il faut manipuler des fichiers, parce que un fichier c'est comme une chaine, c'est plat, amorphe et ça sait rien faire d'intéressant (alors que mon connectionSpec je peux lui demander de devenir actif et il va me répondre d'autres objets qui représentent les tables etc)
[^]Re: Meta-object protocol?
C'est pas lourd en mémoire ?
Debian Sid
[^]Re: Meta-object protocol?
Pourquoi ça le serait ? Les objets individuels ne prennent pas plus de place que dans les autres langages.
Si tu veux un ordre d'idées, une image Squeak de base prend une vingtaine de Mo. Et là dedans il y a le code de tout l'environnement, compilateur, débogueur, interface graphique, gestionnaire de versions, etc soit un peu plus de 2000 classes, 45000 méthodes, et 670000 objets en tout). Qui est chiche de lancer eclipse et compter ? :-)
[^]Re: Meta-object protocol?
En fait je n'utilise Codeworker que pour faire des compilateurs.
Quoiqu'il arrive quelque soit le langage il faudra un moment ou un autre le parser un flux, vérifier son lexique, vérifier sa syntaxe, vérifier sa sémantique puis soit générer quelque chose soit l'interpréter.
Et je ne vois pas pourquoi dans ce cas précis, on est a un mauvais niveau de représentation de donnée.
[^]Re: Meta-object protocol?
Dans ce cas, non (le compilo Smalltalk lit des chaines et produit du bytecode, tout pareil). C'est le "métier" d'un compilo de transformer du code d'une représentation à une autre.
[^]Re: Meta-object protocol?
Mouai la sérialisation 'par défaut' c'est pas forcément une idée géniale: dans Eros ils avaient ça comme fonctionnalité et ils en sont revenus..
Le problème c'est quand tu fais évoluer ton code, si tu n'as pas conçu les snapshot 'version N' et version 'N+1', passer d'une version à l'autre peut devenir un cauchemar..
[^]Re: Meta-object protocol?
Il n'y a pas de sérialisation, l'image est juste un snapshot de la mémoire après un full GC. Si tu ajoutes une variable d'instance, tous les objets concernés sont mis à jour (évidemment pour les objets qui se font mettre à jour, la nouvelle variable d'instance est vide donc ça peut poser problème is on ne fait rien).
[^]Re: Meta-object protocol?
Rien à voir, mais je peux savoir dans quelle société on a encore la chance de faire du smalltalk ?
[^]Re: Meta-object protocol?
JP Morgan, UBS je crois bien, et sinon SOOPS à Amsterdam. Je cherche pas de taf dans l'industrie, donc c'est celles que je connais par des contacts académiques.
[^]Re: Meta-object protocol?
Un ami travaillant pour MMA Assurances par exemple. J'avais eu comme prof un des principaux chef de projet de cette boite, et ils utilisent smalltalk depuis assez longtemps.
Il nous racontait d'ailleurs que ces développeurs grinçaient des dents lorsqu'il s'agissait de repasser à Java, tellement ils se sentaient étriqués dans ce langage...
[^]Re: Meta-object protocol?
J'ai envie de répondre que c'est un peu le cas de tout le monde ayant touché à Java... :-)
Cela dit, si on sait utiliser l'introspection et la réflexion à bon escient, on peut faire pas mal de choses ... Mais la syntaxe reste assez rigide, elle. :-/
[^]Re: Meta-object protocol?
trop gros :-)
Sinon comme boite il y a Heeg en Allemagne, aussi. Voir les sponsors de ESUG: http://www.esug.org/
Le truc c'est que la plupart des développements sont pour des grosses boites, qui demandent des développements perso et qui n'en font pas la pub puisque c'est des outils internes. Soops par exemple leur truc gère les négociations et échanges d'électricité entre les producteurs européens. Je crois qu'AMD au une usine où les robots de production sont gérés en Smalltalk.
Bref c'est un peu comme Erlang, il y a des millions de lignes de code dans le monde, mais planquées dans des gros systèmes.
[^]Re: Meta-object protocol?
Je suis entièrement d'accord avec toi.
Mais le problème, c'est qu'il y a M. Le client.
M. Le client, il veut du java/J2EE, parce que c'est la mode et qu'il trouvera très facilement un développeur pour reprendre et faire vivre son application.
M. Le client, quand il a une appli en C/C++, il veut pas qu'on la recode en autre chose (trop cher), ou qu'on la mixe avec des bouts codés dans un langage mieux (parce que ça tue la cohérence).
Donc on code avec des langages plus ou moins merdiques...
C'est sur que si on codait dans un langage à la smalltalk/ruby/lisaac, on aurait beaucoup moins de problèmes, mais dans la vrai vie, on n'utilise pas ces langages là.
donc on est obligé d'avoir des outils comme CodeWorker...
[^]Re: Meta-object protocol?
Ah sisi on les utilise, je connais des spécimens de Smalltalk Sapiens Industrialis. C'est rare comme bestiole, certes, mais c'est intéressant à côtoyer :-)