The dependency on the clock was lost when the enum is translated into
an integer (because some expression were still refering to the enum type).

The fix was to index VarMap.t by string instead of Soc.var_expr in ActionsDeps.

Remove a lot of warnings (considered as errors by dune).

BTW, fix iterator handling which was not working from SocExecDbg

+ fix a (invisible) bug in lic2soc: the same action was generated twice.

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

nb : i have changed the var name in the generated nodes, which was a bad idea
(=painful to get it rigth again).

The bug was appearing a node was called on a non base clock that was
existing in the called nodes (name clash). Typically, it occurs on
recursive node called on some non-trivial clocks.

Also, use maps instead of list to hold the substitution between
params and args.

('::' vs '__')

soc2c -2cw7: use mkff+fixffx+arm.looploc to fix extern lib calls.

(which breaks lurettetop)

nb : Mamadou's change broke some tests (18->53). Empty body is
generated for nodes that have one eq.  I'll fix that later.

when calling soc.

Do not work all the times (eg, with arrays it generates C code that
does not compile). cf next changes.

nb : the -exec mode was working because I did not use the generated soc,
which was completely wrong.

Note that to do that, I have modified the CURRENT variant of
Lic.val_exp, to attach it the clock the current holds on. Indeed, the
clock is mandatory to generated correct code...

In an ideal world, this clock information may have explicitely been
set by the user ("current(clk_of_X,X)" instead of "current(X)"), but
for historical reason, it is not the case.

Hence, this information is added as soon as it is available, namely,
during clock checking.

# of unexpected failures	101->109

but actually, some new test passes causes several other failing test
to be tried, so it is not really a regression.

nb:  unexpected failures	144->143

Also do not crash if the soc contains reference to extern types.

of expected passes		1073 -> 1116
of unexpected failures	325 -> 282

Add the modes3x2 exemple of Pascal (its version + a la V6 version).

Fix the doc wrt the merge exemple (the tex was refering to a
non-existant file).

Indeed, the initialisation of the fby was done when the soc was
created.  Hence the first fby that was translated was giving its
initial value to all others forthcoming fby !!!

In order to fix that, I've modified the type of Soc.key so that the
initial value is part of its key.

Note that currently, it does not work if the initial value is an input.

More precisely, it was always returning the default value when the
activation condition was false instead of returning "dft_val fby out".

 nb : #FAILS=84->81

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).

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.

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.

F**k! socExec.ml was not gitted!!!

Can be tried unsing the -exec option.

currently only working with trivial programs manipulating equalities
(wires) and predef operators (no pre, ->, arrays, and node calls).

Indeed, the data structure in output of the lis2loc parser was very
similar to Lic.t/LicPrg.t. Hence, this shunt.

At this stage it compiles, but it's untested and does not work.