Also, check programs that should fail using lurette instead of just
lus2lic. Indeed, some programs are only suposed to fail at runtime.

Change the main node names of prog in should_fail as it is necessary
for Lurette non-reg scheme

By redirecting the stderr of ecexe onto stdout, ecexe now terminate properly when called from lurette.

Hence, I have no more unresolved test (they are now failures) and the exec
time is now 98s (versus 217!!)

Some failures were actually due to wrong programs (mved to should_fail/semantics)

nb : the change has actually been done in lurette.

when the arity of an alias node was wrong.

  #fail: 83 -> 81

The rationale is to avoid local vars blow-up on some
examples. Indeed, the generated oracle blows-up (e.g., on left.lus)
if we execute it via v4, whereas via v6 it works fine.

This change triggers a couple of bugs that ware easy to fix
(confusion between div and slash) that I've fixed along the way.
For the others, I'll see later.

Overall it's a progress albeit
  #fail: 80 -> 83

indeed:
  #unresolved: 20 -> 12
  #passes		878 -> 883
  time: 335 -> 228

The test now runs in 150s (versus 417s)

[...] for some reasons, i cannot reproduce the 150s !!!

itself calls another node on a non-trivial clock (i.e., using a when)
was not producing correct code.

I've fixed this by performing the fix-point on nodes rather than on
equations. Indeed its more natural and efficient, and it avoid the
problem above. However, I did not really fix the problem, but just
turn around it. All tests seems to work fine though.

nb : #FAILS=81->80 (and -2 unresolved, but because I fixed the prog)

 nb : #FAILS=84->81

Indeed, I've intentionally removed the when statements in clocked local var like this :

 var
    v:int;

because the following was producing a syntax error in ecexe:

 var
    v:int when c;

But Actually, the right thing to do was to generate the following:

 var
    (v:int) when c;

...

nb : #FAILS=90->89

nb : #FAILS=128->90

I though polymorphism was removed by l2lRmPoly.ml, but well, it was easy.

nb : #FAILS=131->128

nb : #FAILS=135->131

where equations such as " ok = (x=x_ref); " are translated into incorrect v' lustre
when x is a structure or an array.

nb : #FAILS=152->135

(to be kind with data plotters).

Actually it does not fix any test, but I feel it is a (slight)
progress, so I commit it... Well, to be fair, one objective progress
is that I can now compile the test suite with the -np option.

(1) equations such as
 (x,y,z)=[0,0,0];
were generated with -en unless -ec was specified.

I've fixed that by always breaking tuples, even when global_opt.ec
is false (this condition was strange anyway).

(2) During node expansion, I create a fresh variable for each local
var in the expanded node, but old var names were still appering in
clock expression

indeed, consider that example :
var
  c:bool;
  x when c :bool;

I was generating something equivalent to

var
  c_fresh:bool;
  x_fresh when c :bool;

bou... Of course, it was working because in -ec mode, I need to
remove clock annotation when declaring local variables, which was
hidding the problem.

nb : because I've change test_lus2lic_no_node to use -lv4 instead of
-ec to generate the lustre oracle, which exposes new pbs (cf above).

(3) When expanding a node on the base clock with arguments on another
clock, I was not propagating that information (let's keep the
finger-crossed and hope the current fix is complete).

nb : the number of failing test cases is the same (5 new pass, but 5
new fail!!), but it actually is a progression. Indeed, the new test
failures ares due to the fact that this current change fixes a
problem that expose yet another one!

Actually, the newly exposed bug is not in the compliler, but in the
oracle I generate via the --auto-test option ; indeed, for testing
nodes which not all interface variables are one the base clock, I
should generate oracle that do take them into account.

112 tests failed, and 127 passed !!

e.g., "uminus" instead of "-"

Add --gen-autotest option that generates  a Lutin file and an oracle Lustre file suitable to compare the result of 2 Lustre compilers

Some work to share the conde that is comon to Lutin/Lurette more properly
via Makefiles and using chmod to avoid editing the wrong files.

+ mv the lus2licRun.ml/mli file to the Lurette git repo.

As far as ldbg is concerned, it only traces the toplevel node, at
call event.

Note that I needed to rename quite a lot of modules to avoid name clashes
between lus2lic.a and ltop.

I've also merged the Verbose module with the one of Lutin so that
they can be shared (there were sharing 95% already).

Symbolic link as as I did are a bad idea. I will synchronise them
using git subtrees or submodules latter, as explained here:

http://www.elegantchaos.com/node/432
http://www.elegantchaos.com/high-level-git-subtree-scripts

Also Merge the Global and the MainArg module as they were
(bizzarely) both handling command args options.

I took the data type definition from SocExecValue to define a Data
module that is a strict extension of the Lutin Data module.

The duplicated Genlex module is now also identical to the one of
Lurette.

Quite boring, but simple thanks to the ocaml type system.

Now the arrow in handled as a predef statement; in order to know
if we are at the first step of a node, we do as for condact and
store the value of the first_step var in the current ctx.

In order to do that, I've generalised the type of merge : now the clock
argument can be any expression. Some assert false still prevent its use,
but it should be easy to get rid of them (I'll do that latter).

In order to do that, I've generalised the type of merge : now the clock
argument can be any expression. Some assert false still prevent its use,
but it should be easy to get rid of them (I'll do that latter).

nb : programs do run, but I did not check that they run correctly...

Also fix a regression introduced in the previous change where
incorrect ec code was generated for diese.

nb: thus it works with red and fill since they are exactly the same !!!

nb: thus it works with red and fill since they are exactly the same !!!