46 ok, 159 ko...

121 ok, 110 ko. Basically, ko programs contains arrays arrays and
structures.

Define the ctx typedef a good order (w.r.t. typedef dependancies).

- Generate code for most predef operators.
- Generate a loop.c file (in a similar manner as ec2c -loop does)

It generates C code that compile on at least one example.

Merge branch 'master' of git+ssh://scm.forge.imag.fr/var/lib/gforge/chroot/scmrepos/git/lustre/lus2lic

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

Work in progress...

cf rdbg git 66d01f567940e06eab9a49604663d43c29fdfe01

Instead, print a warning and consider the input as unbound.
Is it really the right thing to do?

cf git sha 55d3d77c470f416befd16a1b7d47f751eb2171fc of rdbg

cf git sha 142783a77cad1a0f7ef91972b8376f0b0e44b878 of rdbg

(cf 55d3d77c470f416befd16a1b7d47f751eb2171fc)

Some generated intermediary variables where declared as int instead
of bool.  Funnily, ecexe was ok with that...

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

The main difference is that I use a map instead of list to store
visited nodes.  The compilation time of normal.ec is divided by 2!!
(35s->15s)

We do not really see the difference in the time of the non-reg tests
since the execution of normal.ec still exceeds the 10s timeouts.

Also add support to rdbg to perform nonreg test. I do not plug yet it
as it's twice slower. but most of it seems due patch_ecexe. Indeed,
lus2lic -interface compile the whole program just to print the node
interface.

nb: it has detected a couple of existing bugs.

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

Fix a bug in socExec.ml (strangely untriggered before) along the way.

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.

ps : the new test pass because the -ei is also buggy (cf a forthcoming change).

Translate fby into -> pre again, because the current implementation of fby is buggy if the fby is initialised with an input

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

A few Array.copy were necessary when updating the memory.

Actually, it was a misunderstanding of mine (R1) ; the behavior was consistent
with the lv6 doc, but not with the v4 behavior...

Indeed, # means "at most 1 among n", not "exactly one among n" as I tought...

nb: test run on trieves, not triglav that is down, so the time is meaningless

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