nb: i should really add 'make test' in the git commit hooks!

Remove unused files along the way (myGenlex.ml/mli)

BTW, fix iterator handling which was not working from SocExecDbg

BTW, fonctionalise the corresponding non-debug code.

Basically, I have added the missing fields

I've done the same fix in LicDump actually to be sure (more parenthesis can't hurt).

fix carligths.lus which was badly initialized

And it is now done only by Lic2soc (L2lCheckLoops is not used anymore)

Also, during this change, I was bitten again by the « "__" versus "::" in ident
names » problem again.

The core of this problem is due to the fact that I use LicDump both for
(1) dealing with internal ident names
(2) generating lustre files

Because of (2), ident names may depend on the ec or the v4 option. hence, internal
names were sometimes translated with "__" instead of "::".

To (try to) fix that, I've added a boolean flag to all "to_string" functions that
states whether the function is used for internal purposes, or for generating lustre
files.

It was quite a boring change, that triggered other problems, that I've fixed
in this (too long) commit :
 - -esa should force -en, otherwise bad things happen (-esa is used for -ec anyway)
 - in -esa mode, #/nor inputs tuples of bool, not arrays
 - fix the list of predi op that returns a type different that its arg (SocPredef)

To do that, I have created a new dedicated module L2lExpandEnum, that
actually also deals with -eei (which was probably wrong, even if I
have not counter-exemple).

Use 1-hot encoding instead of log-encoding

I've fixed a bug in L2lExpandArrays that occurs on equation such as
  some_bool = (some_array1 = some_array2);

Also, I've rewritten Lv6Compile for more readability

Remove duplicated code when using SocMap.find and co

I've fixed that using memcmp, which should be fine since compared elements
are of the same types.

+ add a test that reveal a pb in the generated C code in lustre programs
that perform equalities on arrays.

Otherwise, strange things sometimes happen.

Also, use rdbg instead of lurettetop to run the test.

Reference Manual enhancements.

Factorize duplicated code in gen_loop_file and gen_loop_file4ogensim
along the way.

I did a map instead of a fold when checking for the absence of cycle.
On programs with 10 000 of equations, I go from 150s to 5s.

More precisely, issuing an "exit 2" is not enough for the
should_work proc in test/site.exp to state that the test fails.

That fix revealed a certain number of bad programs.
Some were not really wrong ; there were just not respecting the
naming convention used to automated the test (i.e., main node name =
file name).

It also releaved a real bug due to the fact that type
instanciatiation is not propagated during model instanciatiation,
where creates a loop between (Lic2soc.process_node and
Lic2soc.soc_of_node). Indeed it searches in the soc the table for an
abstract profile.

Actually, that was the default behavior. Now the default behavior is
to generate loops for iterators.

nb : with -2ch, loops are still always inlined

Indeed, an iterator is a kind of node.

e.g., for arrays.

No test actually catches this bug.

Now all the tests that were ok in the heap mode are also ok in the
stack mode !

However the code generated for programs that use fillred and co is weird.

For instance, in should_work.pipeline.lus, in
fillred_oneStep_pipe_10_step, accu_in is used both as an input and an
output, which seems wrong in the stack mode as no copy is performed.

Is it working by chance ?

Now all the tests that were ok in the heap mode are also ok in the
stack mode !

However the code generated by fillred and co is weird.

For instance, in should_work.pipeline.lus, in
fillred_oneStep_pipe_10_step, accu_in is used both as an input and an
output, which seems wrong in the stack mode as no copy is performed.

Is it working by chance ?