Skip to content
Snippets Groups Projects
Commit ca730174 authored by Erwan Jahier's avatar Erwan Jahier
Browse files

Fix some syntactic problems in test files.

parent 5c83904e
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
test/lus2lic.log.ref
+ 13
− 27
View file @ ca730174
Test Run By jahier on Wed Jan 23 17:51:02 2013
Test Run By jahier on Mon Jan 28 17:15:58 2013
Native configuration is i686-pc-linux-gnu
=== lus2lic tests ===
......@@ -877,6 +877,12 @@ spawn ./lus2lic -ec -o /tmp/cpt.ec should_work/cpt.lus
PASS: ./lus2lic {-ec -o /tmp/cpt.ec should_work/cpt.lus}
spawn ./ec2c -o /tmp/cpt.c /tmp/cpt.ec
PASS: ./ec2c {-o /tmp/cpt.c /tmp/cpt.ec}
spawn ./lus2lic -o /tmp/multipar.lic should_work/multipar.lus
PASS: ./lus2lic {-o /tmp/multipar.lic should_work/multipar.lus}
spawn ./lus2lic -ec -o /tmp/multipar.ec should_work/multipar.lus
PASS: ./lus2lic {-ec -o /tmp/multipar.ec should_work/multipar.lus}
spawn ./ec2c -o /tmp/multipar.c /tmp/multipar.ec
PASS: ./ec2c {-o /tmp/multipar.c /tmp/multipar.ec}
spawn ./lus2lic -o /tmp/activation_ec.lic should_work/activation_ec.lus
PASS: ./lus2lic {-o /tmp/activation_ec.lic should_work/activation_ec.lus}
spawn ./lus2lic -ec -o /tmp/activation_ec.ec should_work/activation_ec.lus
......@@ -1643,7 +1649,7 @@ spawn ./lus2lic -o /tmp/m.lic should_fail/semantics/m.lus
*** syntax error
XFAIL: Test bad programs (semantics): lus2lic {-o /tmp/m.lic should_fail/semantics/m.lus}
testcase ./lus2lic.tests/non-reg.exp completed in 53 seconds
testcase ./lus2lic.tests/non-reg.exp completed in 52 seconds
Running ./lus2lic.tests/progression.exp ...
spawn ./lus2lic -o /tmp/when_enum.out should_work/broken/when_enum.lus
*** Error in file "/home/jahier/lus2lic/test/should_work/broken/when_enum.lus", line 10, col 12 to 15, token 'toto':
......@@ -1690,34 +1696,14 @@ spawn ./lus2lic -ec -o /tmp/when_not.ec should_work/broken/when_not.lus
FAIL: Generate ec code : ./lus2lic {-ec -o /tmp/when_not.ec should_work/broken/when_not.lus}
spawn ./lus2lic -o /tmp/packages.out should_work/broken/packages.lus
*** Error in file "/home/jahier/lus2lic/test/should_work/broken/packages.lus", line 22, col 27 to 29, token 'int':
*** syntax error
FAIL: without any option: ./lus2lic { -o /tmp/packages.out should_work/broken/packages.lus}
PASS: ./lus2lic { -o /tmp/packages.out should_work/broken/packages.lus}
spawn ./lus2lic -ec -o /tmp/packages.ec should_work/broken/packages.lus
*** Error in file "/home/jahier/lus2lic/test/should_work/broken/packages.lus", line 22, col 27 to 29, token 'int':
*** syntax error
FAIL: Generate ec code : ./lus2lic {-ec -o /tmp/packages.ec should_work/broken/packages.lus}
PASS: ./lus2lic {-ec -o /tmp/packages.ec should_work/broken/packages.lus}
spawn ./lus2lic -o /tmp/when_node.out should_work/broken/when_node.lus
PASS: ./lus2lic { -o /tmp/when_node.out should_work/broken/when_node.lus}
spawn ./lus2lic -ec -o /tmp/when_node.ec should_work/broken/when_node.lus
Error. *** Cannot generate V4 style Lustre for programs with enumerated clocks (yet), sorry.
FAIL: Generate ec code : ./lus2lic {-ec -o /tmp/when_node.ec should_work/broken/when_node.lus}
spawn ./lus2lic -o /tmp/multipar.out should_work/broken/multipar.lus
*** Error in file "/home/jahier/lus2lic/test/should_work/broken/multipar.lus", line 20, col 12 to 12, token 'g':
*** unknown node: g
*** known nodes are: sil, bok, gup, lis
FAIL: without any option: ./lus2lic { -o /tmp/multipar.out should_work/broken/multipar.lus}
spawn ./lus2lic -ec -o /tmp/multipar.ec should_work/broken/multipar.lus
*** Error in file "/home/jahier/lus2lic/test/should_work/broken/multipar.lus", line 20, col 12 to 12, token 'g':
*** unknown node: g
*** known nodes are: sil, bok, gup, lis
FAIL: Generate ec code : ./lus2lic {-ec -o /tmp/multipar.ec should_work/broken/multipar.lus}
spawn ./lus2lic -o /tmp/testSystem.out should_work/broken/testSystem.lus
*** Error in file "/home/jahier/lus2lic/test/should_work/broken/testSystem.lus", line 3, col 6 to 9, token 'capt':
*** unknown package
......@@ -1805,9 +1791,9 @@ testcase ./lus2lic.tests/progression.exp completed in 0 seconds
=== lus2lic Summary ===
# of expected passes 718
# of unexpected failures 20
# of expected passes 723
# of unexpected failures 16
# of unexpected successes 10
# of expected failures 31
# of unresolved testcases 2
runtest completed at Wed Jan 23 17:51:55 2013
runtest completed at Mon Jan 28 17:16:50 2013
test/lus2lic.sum
+ 8
− 7
View file @ ca730174
Test Run By jahier on Fri Jan 25 10:29:53 2013
Test Run By jahier on Mon Jan 28 17:15:58 2013
Native configuration is i686-pc-linux-gnu
=== lus2lic tests ===
......@@ -441,6 +441,9 @@ PASS: ./ec2c {-o /tmp/TIME_STABLE.c /tmp/TIME_STABLE.ec}
PASS: ./lus2lic {-o /tmp/cpt.lic should_work/cpt.lus}
PASS: ./lus2lic {-ec -o /tmp/cpt.ec should_work/cpt.lus}
PASS: ./ec2c {-o /tmp/cpt.c /tmp/cpt.ec}
PASS: ./lus2lic {-o /tmp/multipar.lic should_work/multipar.lus}
PASS: ./lus2lic {-ec -o /tmp/multipar.ec should_work/multipar.lus}
PASS: ./ec2c {-o /tmp/multipar.c /tmp/multipar.ec}
PASS: ./lus2lic {-o /tmp/activation_ec.lic should_work/activation_ec.lus}
PASS: ./lus2lic {-ec -o /tmp/activation_ec.ec should_work/activation_ec.lus}
PASS: ./ec2c {-o /tmp/activation_ec.c /tmp/activation_ec.ec}
......@@ -766,12 +769,10 @@ FAIL: without any option: ./lus2lic { -o /tmp/condact2.out should_work/broken
FAIL: Generate ec code : ./lus2lic {-ec -o /tmp/condact2.ec should_work/broken/condact2.lus}
FAIL: without any option: ./lus2lic { -o /tmp/when_not.out should_work/broken/when_not.lus}
FAIL: Generate ec code : ./lus2lic {-ec -o /tmp/when_not.ec should_work/broken/when_not.lus}
FAIL: without any option: ./lus2lic { -o /tmp/packages.out should_work/broken/packages.lus}
FAIL: Generate ec code : ./lus2lic {-ec -o /tmp/packages.ec should_work/broken/packages.lus}
PASS: ./lus2lic { -o /tmp/packages.out should_work/broken/packages.lus}
PASS: ./lus2lic {-ec -o /tmp/packages.ec should_work/broken/packages.lus}
PASS: ./lus2lic { -o /tmp/when_node.out should_work/broken/when_node.lus}
FAIL: Generate ec code : ./lus2lic {-ec -o /tmp/when_node.ec should_work/broken/when_node.lus}
FAIL: without any option: ./lus2lic { -o /tmp/multipar.out should_work/broken/multipar.lus}
FAIL: Generate ec code : ./lus2lic {-ec -o /tmp/multipar.ec should_work/broken/multipar.lus}
FAIL: without any option: ./lus2lic { -o /tmp/testSystem.out should_work/broken/testSystem.lus}
FAIL: Generate ec code : ./lus2lic {-ec -o /tmp/testSystem.ec should_work/broken/testSystem.lus}
FAIL: without any option: ./lus2lic { -o /tmp/car-orig.out should_work/broken/car-orig.lus}
......@@ -793,8 +794,8 @@ XPASS: Test bad programs (semantics): lus2lic {-o /tmp/bug.lic should_fail/seman
=== lus2lic Summary ===
# of expected passes 718
# of unexpected failures 20
# of expected passes 723
# of unexpected failures 16
# of unexpected successes 10
# of expected failures 31
# of unresolved testcases 2
test/should_work/broken/packages.lus
+ 5
− 5
View file @ ca730174
......@@ -19,16 +19,16 @@ end
-----------------------
-- qq instances de modSimple
-----------------------
package pint is modSimple(int);
package pbool is modSimple(bool);
package preal is modSimple(real);
package pint is modSimple(t=int);
package pbool is modSimple(t=bool);
package preal is modSimple(t=real);
--------------------------
-- un package intermediaire
-------------------------
package inter
uses pbool, pint, preal, Lustre;
uses pbool, pint, preal;
provides
node preced(in: selType) returns (out, out2: selType);
const n : int;
......@@ -51,7 +51,7 @@ body
let
out2 = selType { i = 0; b = true; r = 0.}; --pSel::fby1(in);
out.i = 1;
out.b = Lustre::And(in.b, true);
out.b = (in.b and true);
out.r = 1.02;
tel
end
......
test/should_work/broken/multipar.lus → test/should_work/multipar.lus
+ 27
− 0
View file @ ca730174
(* Verif des static args *)
node gup(x: int) returns (y:int);
let
y = 2 * sil<< lis_bok >>(x);
tel
node bok(x:int)returns(y:int);
let
y = (x * (x + 1)) / 2;
tel
node sil<<
node f(x:int)returns(y:int)
>>(x:int)returns(y:int);
node sil<< node f(x:int)returns(y:int) >>(x:int) returns(y:int);
let
y = x + f<<bok>>(x);
y = x + f(x);
tel
node lis<<
node g(x:int)returns(y:int)
>>(x:int)returns(y:int);
node lis<< node g(x:int)returns(y:int) >>(x:int)returns(y:int);
let
y = x * g(x);
tel
node lis_bok = lis <<bok>>;
node gup(x: int) returns (y:int);
let
y = 2 * sil<< lis >>(x);
tel
todo.org
+ 74
− 70
View file @ ca730174
......@@ -2,75 +2,27 @@
#+CATEGORY: lv6
* Types alias
** WAITING Ya un probleme avec ce fichier lustre (compilait avant)
- State "WAITING" from "STARTED" [2013-01-17 Thu 10:48]
- State "STARTED" from "TODO" [2013-01-17 Thu 10:48]
file:test/should_work/call/call04.lus
il semble y avoir une confusion entre parametre et arguments lors
d'appels de noeuds définis vie des itérateurs de tableau
idem pour
file:test/should_work/fab_test/morel2.lus
et pleins d'autres. hm, y'aurait pas d'itérateurs dans celui la.
-> ok : c'était à c'était cause de l2lAliasType qui faisait que les
types lic n'étaient plus uniques et du coups les substitutions dans
l'expansion des noeuds ne se faisaient plus correctement.
je met en attente en attendant de savoir ce qu'on fait de ce module.
moi j'ai bien envie de virer AbstractType de Lic.type_. En effet, j'avais
fait attention à tous les virer pour éviter les soucis, mais le plus
propre c'est d'y virer vraiment.
Pascal lui, s'en est servi pour faire des types alias, alors que ca
n'est pas fait pour. Cela dit, si on créé des types alias, on risque
d'avoir le meme genre de soucis. A quoi ca sert d'avoir de tels types
? pour moi le role de la compil ca serait plutot de les virer que de
les rajouter, mais bon. A discuter. cf point d'apres
** TODO Enlever Abstract_type_eff de Lic.type_ ou vérifier partout que c'est correct.
- State "TODO" from "" [2012-12-20 Thu 17:26]
dans lic.ml, on definit les types compilés ainsi :
and type_ =
| Bool_type_eff
| Int_type_eff
| Real_type_eff
| Abstract_type_eff of Ident.long * type_
| Array_type_eff of type_ * int
...
Mais est-ce vraiment utile de garder le Abstract_type_eff à ce niveau ?
en effet, ca oblige à traiter les 2 cas en permanence (par ex lors des
transfo llic2lic).
Pascal suggerer carrément de
- definir un type type_ref of string
- transformer les expressions lic de telle sorte que il n'y ait plus
de type_ mais juste des type_ref
Car en fait, actuellement, le type Lic.type_ sert à faire la verif de
type et a representer le type des expressions lic. Du coup le type
des expressions est inutilement compliqué; d'ou l'idée d'avoir juste
des "type_ref of string" (Ce qui simplifiera la travail des passes
ultérieures, style lic2c).
Bon, je ferai ca quand tous les tests fonctionneront et pendant que
j'essairais de me passer de ulglyStuff/id_solcer
* Packages, modeles, etc.
** TODO Il ne detecte plus les erreurs d'instanciation de modeles
** STARTED Il ne detecte plus les erreurs de type lors d'instanciation de noeuds
- State "STARTED" from "TODO" [2013-01-28 Mon 17:02]
cf échange de mails avec PAscal le 28/01/2013
- State "TODO" from "" [2012-12-21 Fri 11:08]
#+begin_src sh
cd src; ../objlinux/lus2lic -vl 2 --nonreg-test should_fail/type/parametric_node2.lus
cd test; ./lus2lic -vl 2 --nonreg-test should_fail/type/parametric_node2.lus
#+end_src
file:test/should_fail/type/parametric_node2.lus
Ah bah oui, c'est écrit ici :
file:src/ast2lic.ml::202
(* NOUVELLE VERSION ÉPURÉE :
ON ne fait AUCUNE vérif de cohérence de types pour les param statiques,
on ne vérifie QUE la nature (pour pouvoir résoudre les args qui sont des idents
A FAIRE + TARD ? !!
*)
** TODO mauvais numero de ligne lors d'erreur d'instanciation de parametres de noeud
- State "TODO" from "" [2012-12-21 Fri 10:58]
......@@ -87,15 +39,6 @@ le message serait meilleur s'il indiquait la ligne 17 où l'erreur est effectué
file:src/astInstanciateModel.ml
file:test/should_fail/type/parametric_node.lus
** TODO pb d'instance de package ???
- State "TODO" from "" [2013-01-19 Sat 09:43]
./lus2lic { -o /tmp/packages.out should_work/broken/packages.lus}
./lus2lic -ec -o /tmp/packages.ec should_work/broken/packages.lus
Error in file "/home/jahier/lus2lic/test/should_work/broken/packages.lus", line 22, col 27 to 29, token 'int':
syntax error
file:test/should_work/broken/packages.lus::22
** TODO instanciation de noeuds ne marche pas ?
- State "TODO" from "" [2013-01-19 Sat 10:02]
./lus2lic -o /tmp/multipar.out should_work/broken/multipar.lus
......@@ -263,3 +206,64 @@ chez Cedric Pasteur qui a une implementation pour optimiser la maj
des tableaux
* Types alias
** WAITING Ya un probleme avec ce fichier lustre (compilait avant)
- State "WAITING" from "STARTED" [2013-01-17 Thu 10:48]
- State "STARTED" from "TODO" [2013-01-17 Thu 10:48]
file:test/should_work/call/call04.lus
il semble y avoir une confusion entre parametre et arguments lors
d'appels de noeuds définis vie des itérateurs de tableau
idem pour
file:test/should_work/fab_test/morel2.lus
et pleins d'autres. hm, y'aurait pas d'itérateurs dans celui la.
-> ok : c'était à c'était cause de l2lAliasType qui faisait que les
types lic n'étaient plus uniques et du coups les substitutions dans
l'expansion des noeuds ne se faisaient plus correctement.
je met en attente en attendant de savoir ce qu'on fait de ce module.
moi j'ai bien envie de virer AbstractType de Lic.type_. En effet, j'avais
fait attention à tous les virer pour éviter les soucis, mais le plus
propre c'est d'y virer vraiment.
Pascal lui, s'en est servi pour faire des types alias, alors que ca
n'est pas fait pour. Cela dit, si on créé des types alias, on risque
d'avoir le meme genre de soucis. A quoi ca sert d'avoir de tels types
? pour moi le role de la compil ca serait plutot de les virer que de
les rajouter, mais bon. A discuter. cf point d'apres
** TODO Enlever Abstract_type_eff de Lic.type_ ou vérifier partout que c'est correct.
- State "TODO" from "" [2012-12-20 Thu 17:26]
dans lic.ml, on definit les types compilés ainsi :
and type_ =
| Bool_type_eff
| Int_type_eff
| Real_type_eff
| Abstract_type_eff of Ident.long * type_
| Array_type_eff of type_ * int
...
Mais est-ce vraiment utile de garder le Abstract_type_eff à ce niveau ?
en effet, ca oblige à traiter les 2 cas en permanence (par ex lors des
transfo llic2lic).
Pascal suggere carrément de
- definir un type type_ref of string
- transformer les expressions lic de telle sorte que il n'y ait plus
de type_ mais juste des type_ref
Car en fait, actuellement, le type Lic.type_ sert à faire la verif de
type et a representer le type des expressions lic. Du coup le type
des expressions est inutilement compliqué; d'ou l'idée d'avoir juste
des "type_ref of string" (Ce qui simplifiera la travail des passes
ultérieures, style lic2c).
Bon, je ferai ca quand tous les tests fonctionneront et pendant que
j'essairais de me passer de ulglyStuff/id_solver. A vois aussi ce qui
sera le plus pratique quand je me remettrai à bosser sur le
lic2c/licexe
todo.org_archive
+ 19
− 0
View file @ ca730174
......@@ -277,6 +277,25 @@ quand on genere du ec (car ec2c ne fait pas la verif !)
On pourrait peut-etre le faire en modifiant celui la : file:src/l2lCheckOutputs.ml ?
* TODO pb d'instance de package ???
- State "TODO" from "" [2013-01-19 Sat 09:43]
:PROPERTIES:
:ARCHIVE_TIME: 2013-01-25 Fri 11:25
:ARCHIVE_FILE: ~/lus2lic/todo.org
:ARCHIVE_OLPATH: Packages, modeles, etc.
:ARCHIVE_CATEGORY: lv6
:ARCHIVE_TODO: TODO
:END:
./lus2lic -o /tmp/packages.out should_work/broken/packages.lus
./lus2lic -ec -o /tmp/packages.ec should_work/broken/packages.lus
Error in file "/home/jahier/lus2lic/test/should_work/broken/packages.lus", line 22, col 27 to 29, token 'int':
syntax error
file:test/should_work/broken/packages.lus::22
ok : c'etait juste un pb de syntaxe (depuis toujours vraisemblablement...)
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment