September 2005 - Transformers

Aaaaaaaaaaaaaarg !
by Akim Demaille 08 Oct '05

08 Oct '05

Il y a deux choses *interdites* qui ont l'air d'être faites très souvent dans Tfers : - Utiliser @ pour cacher les commandes dans un Makefile. C'est une erreur grave ! - Ne pas utiliser argv[0] dans les messages d'erreur. Ne surtout *jamais* coder un nom en dur, du genre SdfChecker, dans les messages d'erreur, les logs, etc., mais bel et bien argv[0]. Sinon, ceux qui debuggent vous maudissent ! Merci d'en tenir compte et de réparer tous les endroits malades de Tfers.

2 1

AC_CONFIG_SUBDIRS
by Akim Demaille 26 Sep '05

26 Sep '05

Je trouve que c'est une erreur d'avoir autant de paquets dans notre arbre. C'est une contrainte, quelque chose qui nuit à la productivité. Si un jour il faut rendre un paquet autonome, ce serait facile de l'arnacher, mais entre temps, je propose la suppression de tous les configure.ac intermédiaires. Seul le bundle compte.

4 7

C'est quoi ce bordel ?!
by Alexandre BORGHI 22 Sep '05

22 Sep '05

Quand je fais un make dans c-condition/src/syn : SdfChecker:warning: unused sort definitions in /tmp/StrategoXT5Sm1zB, line 662, col 8: ExpressionList SdfChecker:warning: unused sort definitions in /tmp/StrategoXT5Sm1zB, line 268, col 8: TypeSpecifierSeq

1 1

Re: [Transformers] AC_CONFIG_SUBDIRS
by Akim Demaille 22 Sep '05

22 Sep '05

>>> "Valentin" == Valentin David <valentin.david(a)gmail.com> writes: > On 9/20/05, Akim Demaille <akim(a)lrde.epita.fr> wrote: >> Je trouve que c'est une erreur d'avoir autant de paquets dans notre >> arbre. C'est une contrainte, quelque chose qui nuit à la >> productivité. Si un jour il faut rendre un paquet autonome, ce serait >> facile de l'arnacher, mais entre temps, je propose la suppression de >> tous les configure.ac intermédiaires. Seul le bundle compte. > Why changing something that works? It was long to set, but now it does > not need so much maintaining. It is good to have a build farm that > check each packages, reading the logs is easier. I'm sorry, but it is not my view that it is working: with Alexandre we lost almost 1 man-day because the C grammar he thought he was using (the one in the src tree) was not the one that was used (the last one to be installed). In addition it is common knowledge that the Autotools are *very* costly to run: any improvement of the working cycle in the Tfers project is an healthy move. I might agree for the removal of *some* indirections instead of all of them, but as is as of today, it is ridiculous --- you can't justify so many packages. I propose 3 sub packages: - StrategoXTensions boxedsdf esdf sdf-astgen sdf-attribute sdf-detgen sdf-option str-lazy - C Grammars c-condition c-grammar - C++ Grammars cxx-basic cxx-grammar specs-grammar

2 2

Questions of style
by Akim Demaille 22 Sep '05

22 Sep '05

I'm reading the module prepost, and there are a few issues I would like to raise. Disclaimer: I have never programmed in Stratego, the code is most certainly wrong. 1. The complete file ==================== For reference. imports liblib ContractC strategies SearchFunDecl = alltd({ ?|InitDeclarator[ ~Declarator: <id>~ ]| ; debug ; oncetd(?|DirectDeclarator[ ~ID: fun_name~ ]|) ; oncetd( ?|DirectDeclarator[ DirectDeclarator(ParameterTypeList) PreCondition-opt PostCondition-opt ]| ; !PreCondition-opt ; if ?|PreCondition?[ ]| then !|Statement[ ; ]| => pre else ?|PreCondition?[ precondition { ~Assertion+: pre~ } ]| end ; !PostCondition-opt ; if ?|PostCondition?[ ]| then !|Statement[ ; ]| => post ; !|ReturnValueDeclaration?[ ]| => ret else ?|PostCondition?[ postcondition ~ReturnValueDeclaration?: ret~ { ~Assertion+: post~ } ]| end ; !|DirectDeclarator[ DirectDeclarator(ParameterTypeList) ]|) ; rules (PrePost : fun_name -> (pre, ret, post)) }) SearchFunDef = alltd({ ?|ExternalDeclaration[ ~FunctionDefinition: <id> ~ ]| ; oncetd(?|DirectDeclarator[ ~ID: fun_name ~ ]| ; where(<PrePost> fun_name => (pre, ret, post)) ; oncetd(?|BlockItemList[ BlockItem-iter ]| ; !|BlockItemList[ ~BlockItem+: <concat> [ [|BlockItem[ ~CompoundStatement: pre ~ ]|, |BlockItem[ ~CompoundStatement: post ~ ]|], BlockItem-iter ]~]| )) }) prepost = io-wrap(SearchFunDecl ; SearchFunDef) 2. The strategies ================= First of all, why the heck should the alltd be in the rules? And BTW, why the rules are strategies here? As a first improvement, I propose to move the alltd down to the prepost strategy. prepost = io-wrap(alltd (FunDecl) ; alltd (FunDef)) Then you see that there are two alltd. Although this allows to have declarations after the implementation (which is indeed a feature) it goes against the spirit of C. Therefore it should read prepost = io-wrap(alltd (FunDecl ; FunDef)) Also, *save the space*! What is this fashion of starting to implement immediately after `='? FunDecl = { ?|InitDeclarator[ ~Declarator: <id>~ ]| ; debug ; oncetd(?|DirectDeclarator[ ~ID: fun_name~ ]|) ; oncetd( ?|DirectDeclarator[ DirectDeclarator(ParameterTypeList) PreCondition-opt PostCondition-opt ]| ; !PreCondition-opt ; if ?|PreCondition?[ ]| then !|Statement[ ; ]| => pre else ?|PreCondition?[ precondition { ~Assertion+: pre~ } ]| end ; !PostCondition-opt ; if ?|PostCondition?[ ]| then !|Statement[ ; ]| => post ; !|ReturnValueDeclaration?[ ]| => ret else ?|PostCondition?[ postcondition ~ReturnValueDeclaration?: ret~ { ~Assertion+: post~ } ]| end ; !|DirectDeclarator[ DirectDeclarator(ParameterTypeList) ]|) ; rules (PrePost : fun_name -> (pre, ret, post)) } FunDef = { ?|ExternalDeclaration[ ~FunctionDefinition: <id> ~ ]| ; oncetd(?|DirectDeclarator[ ~ID: fun_name ~ ]| ; where(<PrePost> fun_name => (pre, ret, post)) ; oncetd(?|BlockItemList[ BlockItem-iter ]| ; !|BlockItemList[ ~BlockItem+: <concat> [ [|BlockItem[ ~CompoundStatement: pre ~ ]|, |BlockItem[ ~CompoundStatement: post ~ ]|], BlockItem-iter ]~]| )) } 3. The rules ============ The rules exist, and that's because they make sense. Why just making strategies? I know, they are equivalent, but so are for and while loops, and you do use both. What is the InitDeclarator that we start by matching? Apparently it is only for debugging, but that's cluttering the code. What are all these oncetd doing here? This is *so wrong*: the code is trying to match various piece instead of just matching what it's looking for. IMNSHO it should look like: FunDecl = ? |Declarator[fn (arg*) pre post]| ; rules (PrePost : fn -> (cs1*, i, cs2*)) where <?|[precondition { cs1* }]|> (pre); <?|[postcondition (i) { cs2* }]|> (post) Is there a nicer way to match pre*, ret and post*? And we'll see for the function with either a pre- xor a postcondition later... The other rule/strategy is also quite not understandable! What is to be done is to create a dynamic rule *that performs the replacement*!!! Not some pseudo table, which completely defeats the whole point of dynamic rules. We want to write something like: where When you put the two together, you have: FunDecl = ? |Declarator[fn (arg*) pre post]| ; rules (InstallContract : |FunctionDefinition[fn (arg*) { stm* }] => !|[fn (arg*) { stm'* }] where <?|[precondition { cs1* }]|> (pre); <?|[postcondition (i) { cs2* }]|> (post); <install-contract (cs1*, i, cs2*)> (stm) => stm'*) And for an experimental start, I propose install-contract (|cs1*, i, cs2*) = !|[ { cs1* } ~id { cs2*} ]| We will see the complications later. I would like to have detailed answers, and particularly from Jesus. I'm quite sure my code is wrong, but it is probably close to correct, my Stratego is far from fluent.

2 2

GCC
by Valentin David 22 Sep '05

22 Sep '05

Hi, I did not understand some behaviors of Gcc. Gcc accepts this: -->8-- class A {}; class B {}; A B; -->8-- I found nothing in the standard that says it is not valid. Ok. According to the standard this one is valid, and Gcc accepts it: -->8-- typedef int T; typedef int T; -->8-- It does not accept this one: -->8-- typedef int T; T T; -->8-- That is ok, T is a typedef-name. But on this one, it fails: -->8-- class A {}; typedef A T; T T; -->8-- But normally, T is class-name. And the same on this one: -->8-- typedef class {} A; A A; -->8-- But here, A is not only a class-name, it is *THE* real name of the class. I do not understand why Gcc does not accept these two last examples. I did not find it in the standard. If someone find it somewhere... -- Valentin David valentin.david(a)gmail.com

2 2

Does not compile
by Akim Demaille 21 Sep '05

21 Sep '05

Help again: make[2]: Entering directory `/work/akim/src/transformers/_build/str-lazy/test' /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -I../src/native -I../src/lib -g -O0 -o lazy-test lazy-test.o -L/home/lrde/admin/lrde/usr/stratego/lib -lstratego-lib -lstratego-lib-native -lm -L/home/lrde/admin/lrde/usr/stratego/lib-lstratego-runtime -lm -L/home/lrde/admin/lrde/usr/stratego/lib -lATerm -lm -L../src/lib -L../src/native -llazy-lib -llazy-lib-native libtool: link: gcc -g -O2 -I../src/native -I../src/lib -g -O0 -o .libs/lazy-test lazy-test.o -L/home/lrde/admin/lrde/usr/stratego/lib -lstratego-lib -lstratego-lib-native -lstratego-runtime -lATerm -lm -L/home/akim/src/transformers/_build/str-lazy/src/lib -L/home/akim/src/transformers/_build/str-lazy/src/native /home/akim/src/transformers/_build/str-lazy/src/lib/.libs/liblazy-lib.so /home/akim/src/transformers/_build/str-lazy/src/native/.libs/liblazy-lib-native.so -Wl,-rpath -Wl,/usr/local/lib/str-lazy /usr/bin/ld: cannot find -lstratego-lib collect2: ld returned 1 exit status Merci d'avance.

1 0