Unclear instructions on running tstl

[maxking]

Unclear instructions on running tstl

[pramttl]

Yes, this looks like a lack of instructions.

Also I think this can be solved from the code perspsective, by automatically adding the directory the randomtester.py is being called from to the PYTHONPATH i.e. adding the current working directory to the PYTHONPATH.

I'll send a patch for this.

[agroce]

Yeah, that's a really good idea. I (perhaps bravely) have . in my
PYTHONPATH, but I'm a crazy man like that.

On Wed, Jan 20, 2016 at 10:36 PM, Pranjal Mittal [email protected]
wrote:

Yes, this looks like a lack of instructions.

Also I think this can be solved from the code perspsective, by
automatically adding the directory the randomtester.py is being called from
to the PYTHONPATH i.e. adding the current working directory to the
PYTHONPATH.

I'll send a patch for this.

—
Reply to this email directly or view it on GitHub
#5 (comment).

Alex David Groce
School of Electrical Engineering and Computer Science
Oregon State University

[pramttl]

Solved issue and submitted PR for this. I have tested and python <tstl-root>/generators/randomtester.py does not assume sut.py is on sys.path now. os.getcwd() is added to sys.path explicitly in the generators. More specifically I added the fix for 4 generators.

bfsmodelchecker.py  randombeam.py
dfsmodelchecker.py  randomtester.py

Did not add the fix for these 2 generators as I wasn't sure what these files are doing. Are these also test generators?

experiment.py
pathseq.py

Should we add the fix for these 2 files ^ as well?

[maxking]

Thanks for the fix!
If I may suggest, a better fix would be to take the location of sut.py as an argument and import sut from that location using __import__ (agreed that that is not usually recommended to use this, but in this case I guess it is needed rather than assuming an argument is on $PYTHONPATH or even adding it to $PYTHONPATH) to import the actual module.

Also, if you could please update the README (or even I can send in a request if you wish) to reflect the same, it would be really great for the first time users/contributors of the library.

[pramttl]

@maxking: Good suggestion. I was thinking about same i.e. taking sut.py as an argument. Just implemented what seemed like the best quick fix.

Long term we may also want to have something like: tstl <system.tstl> --apply randomtester

That builds the sut.py and applies the test in one go. Sort of like compile and run. We might want to abstract away the sut.py completely from the user perspective as it is an intermediate test harness. The user is more interested in the test results and the bugs.

But if there are bugs in <system>.tstl file causing the harness maker to fail to generate the sut.py, the user may want to see what errors in the .tstl file are causing this. If the .tstl is free of compilation errors; then the user is mostly interested in seeing the test results (after the generator is applied)