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 ! Le langage de script est un petit langage adapté à la manipulation de graphe.
La définition de variable est assez simple et non typée :
local nombre = 26.7;
local chaine = "vingt six virgule sept";
local booleen = (nombres == chaines);
local dictionnaire;
insert dictionnaire["Requin"] = "Petit poisson marinant dans l'huile";
insert dictionnaire[3.141592] = "Premiers chiffres de Pi";
local jouet;
insert jouet.categorie = "voiture";
insert jouet.alimentation = "piles";
insert jouet.alimentation.quantite = 4;
insert jouet.alimentation.taille = "LR6";
insert jouet.nombrepiece["aileron"] = 1;
La syntaxe, se veut proche des standard C/Java avec une teinte langage de script sans typage.
local especeAnimale;
insert especeAnimale["Mireille"] = "abeille";
insert especeAnimale["Camille"] = "chenille";
function traiteespeceAnimale(esp : node) {
foreach i in esp {
if first(i) {
traceLine("premier élément = '" + i.key() + "'");
} else if last(i) {
traceLine("dernier élément = '" + i.key() + "'");
}
traceLine("clé = '" + key(i) + "' valeur = '" + i + "'");
}
return false;
}
esp : node signifie passage par référence, le comportement par défaut étant de passer par valeur.
Le grand intérêt de ce langage est de permettre de définir une grammaire BNF pour récupérer des données :
nombre ::= #ignore(blanks) flottant | entier;
entier ::= ['-']? ['0'..'9']+;
flottant ::= entier '.' entier ['e' entier]?;
identifiant ::= [lettre | '_'] [lettre | '0'..'9' | '_']*;
lettre ::= 'a'..'z' | 'A'..'Z';
l'intérêt étant ensuite de pouvoir définir des règles de générations :
flottant ::=
#!ignore
entier '.' #continue !'-' entier
[
'e' #continue
entier:iExposant
=> traceLine("valeur de l'exposant = " + iExposant);
]?
Des manipulations beaucoup plus complexes sont décrites dans le tutoriel disponible sur le site Developpez.com
Aller plus loin
- CodeWorker (31 clics)
- Tutoriel complet (140 clics)
- Repository of scripts (13 clics)
- Fiche sur Framasoft (21 clics)
# Parser du C++
Posté par loufoque . Évalué à 8.
Je doute qu'un tel outil en soit capable, étant donné que même le fameux Doxygen n'a qu'un parser C++ approximatif.
[^] # Re: Parser du C++
Posté par tarlack . Évalué à 5.
et doxygen a t'il reellement besoin d'un parser exact ?
[^] # Re: Parser du C++
Posté par Ontologia (site web personnel) . Évalué à 5.
It is relatively difficult to write a good C++ parser with classic parsing algorithms such as LALR(1).[5] This is partly because the C++ grammar is not LALR. Because of this, there are very few tools for analyzing or performing non-trivial transformations (e.g., refactoring) of existing code. One way to handle this difficulty is to choose a different syntax, such as Significantly Prettier and Easier C++ Syntax, which is LALR(1) parsable. More powerful parsers, such as GLR parsers, can be substantially simpler (though slower).
Mais je crois que la parseur est assez flexible, savoir s'il l'est assez je ne sais pas.
Mais il faut noter que ce parseur prend directement une grammaire écrite en BNF, et non une suite de règles à la lex/yacc.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Parser du C++
Posté par kadreg . Évalué à 7.
La seule chose pour laquelle on peut avoir une grammaire fiable, c'est après le passage du préprocesseur. Avant, c'est virtuellement n'importe quoi.
C'est pour cela par exemple que les outils de traitement de source pagayent souvent avec du C++.
[^] # Re: Parser du C++
Posté par loufoque . Évalué à 1.
Prenons l'expression suivante :
A<b> c;
Si A identifie un template, alors c'est une instanciation de template.
Sinon, c'est une comparaison.
# ...
Posté par M . Évalué à 10.
C'est bien beau, mais j'ai du mal à voir des applications pratiques.
L'article aurait pu cité des exemples concret d'utilisation.
[^] # Re: ...
Posté par Antoine . Évalué à 6.
[^] # Re: ...
Posté par papykahan . Évalué à 4.
Cela peut permettre de développer son propre compilateur pour un DSL (Domain Specific Language, exemple de DSL le plus probant est le SQL). Autre exemple la documentation en HTML de codeworker est générer avec Codeworker, de même qu'une grqnde parie de codeworker est coder avec codeworker (Car il dispose aussi d'un langage de script).
Ensuite en sortie d'un BNF tu peut avoir un AST que tu peux manipuler a loisir. Par exemple tu peux parser du C analyser l'arbre pour générer du C optimisé ;).
[^] # Re: ...
Posté par papykahan . Évalué à 0.
s/grqnde/grande/g
Etsans la faute sur le "peut" par peux c'est mieux désolé :s
[^] # Re: ...
Posté par Damien ARISTODEMO (site web personnel) . Évalué à -2.
[^] # Re: ...
Posté par Ontologia (site web personnel) . Évalué à 1.
On peut faire plein de chose, par exemple : http://www.codegeneration.net/tiki-index.php?page=InlineCode(...)
ce qui revient à une super macro
On peut l'utiliser pour faire de la coloration syntaxique pour toute sorte de langage que l'on veut traduire en html coloré, pour des besoins de documentations.
On peut aussi l'utiliser pour faire de la génération de code à partir d'un langage décrivant le modèle de classe.
On peut modifier le modèle de classe en le rafraichissant, tout en respectant le code source contenu à l'intérieur.
Générer une grammaire BNF à partir d'une DTD.
Générer un source pour graphviz à partir d'un source Java/C++/Python, etc...
On peut imaginer plein d'applications avec cette outil, car son langage de script permet de gérer autant d'entrée et de sortie qu'on désir.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: ...
Posté par papykahan . Évalué à 4.
Enfin bon il y a que l'imagination qui peut limiter son utilitée.
[^] # Re: ...
Posté par Antoine . Évalué à 5.
AMHA la plupart des langages objets n'ont que faire du "mangling". Idem pour la notion de "static binding" qui est propre à C++. Bref ça commence plutôt mal pour "le fonctionnement interne d'un langage Objet"...
[^] # Re: ...
Posté par papykahan . Évalué à -2.
[^] # Re: ...
Posté par Damien (site web personnel) . Évalué à 2.
[^] # Re: ...
Posté par papykahan . Évalué à 2.
[^] # Re: ...
Posté par tarlack . Évalué à 2.
[^] # Re: ...
Posté par Antoine . Évalué à 2.
Vu la grammaire je ne suis pas sûr de bien comprendre la phrase, mais pas besoin de mangling pour écrire un interpréteur ou compilateur de langage objet (voir par exemple la VM de CPython). Tu voulais dire probablement faire une traduction en C de concepts objets, ce qui est évidemment une vision très particulière de la question.
[^] # Re: ...
Posté par papykahan . Évalué à 1.
C'est exactement ce que je voulais dire désolé je me suis peut être mal exprimé et un peut trop dans la hâte.
[^] # Re: ...
Posté par Antoine . Évalué à 1.
[^] # Re: ...
Posté par papykahan . Évalué à 1.
[^] # Re: ...
Posté par papykahan . Évalué à 1.
[^] # Re: ...
Posté par barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ...
Posté par papykahan . Évalué à 3.
[^] # Re: ...
Posté par Damien (site web personnel) . Évalué à 3.
Exactement :-)
http://en.wikipedia.org/wiki/Sapir-Whorf_hypothesis
[^] # Re: ...
Posté par papykahan . Évalué à 1.
# Meta-object protocol?
Posté par Damien (site web personnel) . Évalué à 4.
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?
Posté par papykahan . Évalué à 1.
La je comprend pas tout tu peux expliquer un peut?
[^] # Re: Meta-object protocol?
Posté par Anonyme . Évalué à 5.
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?
Posté par Damien (site web personnel) . Évalué à 3.
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?
Posté par Ontologia (site web personnel) . Évalué à 1.
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.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Meta-object protocol?
Posté par Damien (site web personnel) . Évalué à 1.
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?
Posté par papykahan . Évalué à -1.
Ce code "sale" tu en as forcement besoin un moment ou un autre ;)
[^] # Re: Meta-object protocol?
Posté par Damien (site web personnel) . Évalué à 3.
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?
Posté par barmic . Évalué à 1.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Meta-object protocol?
Posté par Damien (site web personnel) . Évalué à 1.
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?
Posté par papykahan . Évalué à 1.
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?
Posté par Damien (site web personnel) . Évalué à 1.
[^] # Re: Meta-object protocol?
Posté par reno . Évalué à 1.
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?
Posté par Damien (site web personnel) . Évalué à 1.
[^] # Re: Meta-object protocol?
Posté par Alex . Évalué à 1.
[^] # Re: Meta-object protocol?
Posté par Damien (site web personnel) . Évalué à 2.
[^] # Re: Meta-object protocol?
Posté par Ontologia (site web personnel) . Évalué à 1.
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...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Meta-object protocol?
Posté par lasher . Évalué à 4.
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?
Posté par Damien (site web personnel) . Évalué à 1.
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?
Posté par Ontologia (site web personnel) . Évalué à 1.
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...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Meta-object protocol?
Posté par Damien (site web personnel) . Évalué à 2.
# Et pour debugger le code généré?
Posté par reno . Évalué à 7.
Non parce que c'est toujours le même problème: la génération de code est toujours vendue comme quoi on va beaucoup plus vite pour produire du code, en oubliant commodément de mentionner qu'on va ensuite beaucoup lentement pour debugger le code généré..
[^] # Re: Et pour debugger le code généré?
Posté par emanjo . Évalué à 0.
Erreur de codage ou de conception ?
S'il s'agit d'erreurs liées à l'utilisation du langage, a priori elles n'existent pas avec un générateur automatique, ou alors le générateur est lui même buggé et c'est un autre problème...
S'il s'agit d'erreurs de conception, alors il existe une faille dans le processus de conception, et il est dommage de les identifier au niveau du codage. Dans ce cas, avec un générateur automatique, le "débuggage" de niveau conception doit se faire par d'autre outils que le débugger classique, essentiellement par exécution du modèle de conception.
En gros avec un générateur automatique, il faut renoncer à exploiter le code en tant que tel. La valeur ajoutée se trouve réellement au niveau de la conception.
[^] # Re: Et pour debugger le code généré?
Posté par M . Évalué à 2.
Tu prie que le générateur n'ai pas de bug (c'est connu le soft 100% bug free ca se trouve partout) ?
[^] # Re: Et pour debugger le code généré?
Posté par Damien (site web personnel) . Évalué à 2.
[^] # Re: Et pour debugger le code généré?
Posté par Antoine . Évalué à 5.
Heu... si c'est que le compilateur n'arrive pas à parser une construction légitime ok. Mais s'il génère du code potentiellement incorrect dans certaines circonstances particulières et plutôt rares, ça peut rester longtemps en l'état.
Le pire, c'est quand tu te retrouves face à un bug pareil : tu peux perdre un bon bout de temps avant d'inspecter le code généré et te rendre compte que c'est le compilateur qui est dans l'erreur (intuitivement on a plutôt tendance à accuser notre propre code).
[^] # Re: Et pour debugger le code généré?
Posté par lasher . Évalué à 2.
Oui enfin, quand on est de bonne foi. :-)
[^] # Re: Et pour debugger le code généré?
Posté par Antoine . Évalué à 2.
Oui, au pays des bisounours il y a un "modèle de conception" qu'on peut exécuter à loisir et qui garantit que tout va bien marcher. Dans le monde réel je ne vois pas trop comment exprimer un algorithme non-trivial dans un "modèle de conception", ou alors le "modèle de conception" est une implémentation à part entière de la solution.
[^] # Re: Et pour debugger le code généré?
Posté par Damien (site web personnel) . Évalué à 4.
Oui, par exemple une implémentation dans un langage de haut niveau, expressif, flexible… Y'en a même des comme ça qui compilent avec des perfs décentes :-]
[^] # Re: Et pour debugger le code généré?
Posté par emanjo . Évalué à 3.
Parceque si au final il faut débugger le code généré ça n'a strictement aucun intérêt.
Personnellement je n'ai jamais réussi à utiliser un générateur de code de façon efficace, et principalement pour les raisons que tu cites. Mais ça n'empêche pas de raisonner sur la méthode. Si l'on envisage jamais d'autres façon de faire il n'y a jamais de progrès. Après il y a des technos qui survivent, d'autres qui restent des vues de l'esprit.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.