By chance (or for other reasons), the resulting code was correct.

Report by willie (cf mail of 8/10/2014 to get the file)

file:/tmp/modes3x2.lus

lus2lic -esa -en -2c /tmp/modes3x2.lus -n modes3x2

But it gives an error of:
Error. in file "/mnt/A/wsept/modes3x2_pre_orig_lus2lic_en_esa/modes3x2.lus",
line 74, col 8 to 8, token '#': only one operator per equation is allowed
(v04_0, v04_1).

Which is the line:
assert #(on_off, toggle);

-----------------------------------------------------------------

Actually, refuse programs that uses "#" or "nor" run with -esa and
-2c|-exec

That means that willie program is now rejected.

Nevertheless, that change migth fix some other programs (that uses
arrays, and used with -esa and -exec or -2c).

Also fix a bug in Lic2soc.make_e2a_elt where some deps and some
actions were lost. Actually, this bug ought to be triggered only with
nested calls. So this affects only programs executed via the
-knc/-keep-nested-calls option. and -2c is not supposed to work in
conjunction with -knc ! Hence this fix does not fix anything. But
still it fixes potentially future code if I (or someone else) decide
to handle nested calls in the lic one day.

that expands the call of the specified node (can be used for several nodes).
Remove the previous --do_not-expand-nodes <string>

Also, the L2lExpandNodes pass now deletes the expanded nodes from the
current LicPrg.t.

Add an option --to-c-dont-inline-predef to get the previous behavior.

where I've removed the handling of polymorphism.

For instance,
  node toto = map<<Lustre::if,  N>>(x, a, b);
is rejected.

The problem with this change is that we now also reject equations such as
   res = map<<+,  N>>(x, a, b);

which could be avoided. Probably L2lRmPoly does its job partially.

The idea is that
- when it is not in the memory, it is considered as true
- it is set to false after each step is executed

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

More specifically, replace @ by rev_append and flatten+map by fold_left.

On a file that has 11000 equations (normal.ec), I win a factor 4: 60s -> 15s

That was quite confusing for rdbg -lurette --*-stdio !!!

nb : I've finaly understood the performance/out of memory problems I
had for that last 6 months !!!!! It was due to the lurette.cov file
that was getting larger and larger.

Timothy Bourke (trigerred where the clock of some args are some other
args and when the names of variables are shared between the caller
and the callee).

The problem is in UnifyClock.f or (in evalClock.ml) ; the current
change in evalClock.ml fixes the pb in Tim's program, but I suspect
it is still buggy.

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

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.

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.

BTW, put everything that concerns node environement into the new
IdSolver module (from the Lic module).

nb : do not work for lv4/ec mode

Also fix some bugs in DumpLic when printing condact in other modes.

nb : I've transformed all the regressions I've seen into todo entries
in todo.org.

nb 2 : I did not mv the newly broken tests into the broken dirs. I'll
do that for those I do not want to fix in the short term.

nb: les tests ne passent toujours bien sur.

* Partie lus -> AST

predef.ml -> srcPredef.ml
syntaxTreeCore.ml -> astCore.ml
syntaxTree.ml     -> astV6.ml
syntaxTreeDump.mli-> astV6Dump.mli

* Partie Ast -> Ast

solveIdent.mli -> astRecognizePredef.mli
syntaxTab.mli -> astTab.mli
symbolTab.mli -> astTabSymbol.mli

* Partie  AST -> lic (static evaluation)

eff.ml  -> lic.ml
getEff.mli -> ast2lic.mli
lazyCompiler.mli -> licTab.mli
builtIn.ml -> licMetaOp.ml
predefEval*.ml -> licEval*.ml
name.mli -> licName.mli

* Partie Lic -> Lic

uniqueOutput.mli      -> l2lCheckOutputs.mli
structArrayExpand.mli -> l2lExpandArrays.mli
nodesExpand.mli       -> l2lExpandNodes.mli
doNoPoly.ml           -> l2lRmPoly.ml
doAliasTypes.ml       -> l2lAliasType.ml
doSplit.ml            -> l2lSplit.ml

+ remise en place du souk qu'il a mis dans le repertoire test.

- il a commencé à rajouter le CondAct (tout est parti de la en fait...)
- il a coupé le LazyCompiler en morceaux

Pour cela, il a créé un nouveau module LicPrg qui définit la
structure de données (SDD) en sortie du LazyCompiler. Ensuite, les
diverses tranformations src2src sont faites à partir de cette SDD.

- il a débranché (temporairement) l'expansion de noeud et de array/structure

- il a débranché ma pseudo inférence de type et a mis à la place une
vérification de types.

- Le traitement du polymorphisme est effectué via une transfo src2src
dans DoNoPoly (que je vais renommer en RmPoly)

--------------------------------------------------------------------------
Par ailleurs,

J'ai créé un todo.org et un README.org que je vais essayer de tenir à jour.

nb: les tests ne passent toujours bien sur.