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 (219 hits)
-
Fiche sur Framasoft (433 hits)
> Lire la dépêche (56 commentaires, moyenne: 2,4).
Vous avez demandé le commentaire #885303.
Run by 
Cette page a été générée par Templeet en 0.0557s (dont 0.005 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Et pour debugger le code généré?
Il y a quelque-chose?
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é?
Oui et non, lorsque tu débugges tu corriges des problèmes de quelle nature ?
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é?
Mais donc concrètement quand le truc que tu as générer marche pas tu fais quoi ?
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é?
En même temps, les bugs de compilateurs ça se fait remarquer assez vite d'habitude…
[^]Re: Et pour debugger le code généré?
En même temps, les bugs de compilateurs ça se fait remarquer assez vite d'habitude…
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é?
intuitivement on a plutôt tendance à accuser notre propre code
Oui enfin, quand on est de bonne foi. :-)
[^]Re: Et pour debugger le code généré?
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
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é?
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é?
C'est effectivement au pays des bisounours, ou du moins dans les livres. Ce que je veux dire c'est que si l'on fait le choix du générateur de code automatique, il faut adapter son processus de développement et les méthode associé.
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.