- Nov 28, 2013
-
-
Erwan Jahier authored
-
- Nov 25, 2013
-
-
Erwan Jahier authored
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.
-
- Oct 23, 2013
-
-
Erwan Jahier authored
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.
-
- Jun 06, 2013
-
-
Erwan Jahier authored
ps : the new test pass because the -ei is also buggy (cf a forthcoming change).
-
Erwan Jahier authored
Translate fby into -> pre again, because the current implementation of fby is buggy if the fby is initialised with an input
-
- Jun 05, 2013
-
-
Erwan Jahier authored
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.
-
- Jun 04, 2013
-
-
Erwan Jahier authored
More precisely, it was always returning the default value when the activation condition was false instead of returning "dft_val fby out".
-
Erwan Jahier authored
A few Array.copy were necessary when updating the memory.
-
- Jun 03, 2013
-
-
Erwan Jahier authored
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...
-
Erwan Jahier authored
nb: test run on trieves, not triglav that is down, so the time is meaningless
-
Erwan Jahier authored
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
-
- May 31, 2013
-
-
Erwan Jahier authored
By redirecting the stderr of ecexe onto stdout, ecexe now terminate properly when called from lurette. Hence, I have no more unresolved test (they are now failures) and the exec time is now 98s (versus 217!!) Some failures were actually due to wrong programs (mved to should_fail/semantics) nb : the change has actually been done in lurette.
-
Erwan Jahier authored
when the arity of an alias node was wrong.
-
Erwan Jahier authored
-
Erwan Jahier authored
#fail: 83 -> 81
-
- May 28, 2013
-
-
Erwan Jahier authored
The rationale is to avoid local vars blow-up on some examples. Indeed, the generated oracle blows-up (e.g., on left.lus) if we execute it via v4, whereas via v6 it works fine. This change triggers a couple of bugs that ware easy to fix (confusion between div and slash) that I've fixed along the way. For the others, I'll see later. Overall it's a progress albeit #fail: 80 -> 83 indeed: #unresolved: 20 -> 12 #passes 878 -> 883 time: 335 -> 228
-
Erwan Jahier authored
The test now runs in 150s (versus 417s) [...] for some reasons, i cannot reproduce the 150s !!!
-
- May 22, 2013
-
-
Erwan Jahier authored
itself calls another node on a non-trivial clock (i.e., using a when) was not producing correct code. I've fixed this by performing the fix-point on nodes rather than on equations. Indeed its more natural and efficient, and it avoid the problem above. However, I did not really fix the problem, but just turn around it. All tests seems to work fine though. nb : #FAILS=81->80 (and -2 unresolved, but because I fixed the prog)
-
- May 21, 2013
-
-
Erwan Jahier authored
nb : #FAILS=84->81
-
- May 17, 2013
-
-
Erwan Jahier authored
-
- May 16, 2013
-
-
Erwan Jahier authored
-
- May 15, 2013
-
-
Erwan Jahier authored
Indeed, I've intentionally removed the when statements in clocked local var like this : var v:int; because the following was producing a syntax error in ecexe: var v:int when c; But Actually, the right thing to do was to generate the following: var (v:int) when c; ... nb : #FAILS=90->89
-
- May 13, 2013
-
-
Erwan Jahier authored
nb : #FAILS=128->90
-
- May 10, 2013
-
-
Erwan Jahier authored
I though polymorphism was removed by l2lRmPoly.ml, but well, it was easy. nb : #FAILS=131->128
-
- May 07, 2013
-
-
Erwan Jahier authored
nb : #FAILS=135->131
-
- May 06, 2013
-
-
Erwan Jahier authored
where equations such as " ok = (x=x_ref); " are translated into incorrect v' lustre when x is a structure or an array. nb : #FAILS=152->135
-
- Apr 26, 2013
-
-
Erwan Jahier authored
(to be kind with data plotters).
-
Erwan Jahier authored
-
- Apr 25, 2013
-
-
Erwan Jahier authored
-
Erwan Jahier authored
Actually it does not fix any test, but I feel it is a (slight) progress, so I commit it... Well, to be fair, one objective progress is that I can now compile the test suite with the -np option.
-
- Apr 24, 2013
-
-
Erwan Jahier authored
-
- Apr 23, 2013
-
-
Erwan Jahier authored
(1) equations such as (x,y,z)=[0,0,0]; were generated with -en unless -ec was specified. I've fixed that by always breaking tuples, even when global_opt.ec is false (this condition was strange anyway). (2) During node expansion, I create a fresh variable for each local var in the expanded node, but old var names were still appering in clock expression indeed, consider that example : var c:bool; x when c :bool; I was generating something equivalent to var c_fresh:bool; x_fresh when c :bool; bou... Of course, it was working because in -ec mode, I need to remove clock annotation when declaring local variables, which was hidding the problem. nb : because I've change test_lus2lic_no_node to use -lv4 instead of -ec to generate the lustre oracle, which exposes new pbs (cf above). (3) When expanding a node on the base clock with arguments on another clock, I was not propagating that information (let's keep the finger-crossed and hope the current fix is complete). nb : the number of failing test cases is the same (5 new pass, but 5 new fail!!), but it actually is a progression. Indeed, the new test failures ares due to the fact that this current change fixes a problem that expose yet another one! Actually, the newly exposed bug is not in the compliler, but in the oracle I generate via the --auto-test option ; indeed, for testing nodes which not all interface variables are one the base clock, I should generate oracle that do take them into account.
-
- Apr 22, 2013
-
-
Erwan Jahier authored
112 tests failed, and 127 passed !!
-
- Apr 17, 2013
-
-
Erwan Jahier authored
e.g., "uminus" instead of "-"
-
Erwan Jahier authored
Add --gen-autotest option that generates a Lutin file and an oracle Lustre file suitable to compare the result of 2 Lustre compilers
-
- Apr 12, 2013
-
-
Erwan Jahier authored
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.
-
Erwan Jahier authored
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).
-
- Apr 10, 2013
-
-
Erwan Jahier authored
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
-
Erwan Jahier authored
Also Merge the Global and the MainArg module as they were (bizzarely) both handling command args options.
-
- Apr 08, 2013
-
-
Erwan Jahier authored
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.
-