GitLab

Instead, add an integer suffix to the file name, e.g.,

  lutin -rif toto.rif (...)

will generate the file toto-2.rif if toto.rif and toto-1.rif already
exist.

This was done by moving most of the code from checkRif.ml to
lustreRun.ml (new module) and coverage.ml, so that checkRif only
contains administration stuff (dealing with options) plus a simple
top-level loop.

I've added some tests in exemple/lutin/oracle.

Try to push the reusable part of the code in the coverage and
LustreRun modules, so that chekRif.ml only contains administration
stuff (dealing with options) plus a simple top-level loop.

The rationale would be to be able to reuse that stuff from lutin for
instance.

full tail rec algo abandoned (for the time being)

- Add an option to specify the dir where to put generated C files in.
- Propagate all lutin options in the C part that fork the lutin interpreter
(-rif, -precision, -node, -boot)
- use the Sys.argv.(0) as the lutin interpreter to be called (to make sure
the same lutin is used and to be able to specify the full path in the C
file if needed).

- Split check-rif.ml into check-rif.ml and coverage.ml.
- Add a section dedicated to check-rif in the Lutin manual, in the tool section.
- Use the ocaml Arg module to deal with command-line args.
- Take advantage of the fact that an ec file only have one node.
- Store/update the corevage info in a .cov file

was too small.

The idea is that Rif_base does not depend on any other module while
Rif keeps its interface but relies on Rif_base for its implementation.

Propagate some changes in the gnuplot syntax in gnuplot-rif. This will break old version of gnuplot. Sigh. Also, make -wxt the default behavior of gnuplot-rif.

Fix a bug (probably introduced in 0b0203fe) where the path of the env file was not explicit which prevent Makefile.lurette to find it. \n ps : it is no more possible to use a list of file in the env slot ; but who cares now that Lutin is usable from Lurette?

deterministic subset seems to work

Conflicts:
	source/Lutin/Makefile.lutin
	source/Lutin/main.ml

Fix a bug (in LucFGen) where the exception Invalid_argument("Random.int") was raised on some Lutin programs.

It was occuring when all outgoing transitions were labelled by the
null weigth.

instead of lucky.a to launch the lutin interpreter.

I've added a test in the example/lutin/C/ directory.

in order to avoid strange "assert" behavior.
Simu is based on standard AutoGen, thus
the behavior is the same with simu and compiled luc.
Warning: the experience of AutoExplore raised
important problems between Lutin and Lucky semantics:
should be fixed in a later version !

using the RIF format.

Also, add a --2c-4c that does the same job as luc2c without option.

FGen module is made abstract, old one renamed in LucFGen
Bug fixed in Lutin.Expand

Also, make sure that a git clone result in a working (build, test) setup.