Preparations for DAQ Suite v2.x

[bieryAtFnal]

As Alessandro suggested at the end of Pull Request #6, I'm opening this Issue to help us keep track of a few remaining issues with the preparation of a version of this package (listrev) for inclusion in the DAQ SW Suite v2.x (probably v2.0) release.

I'll provide a list of the remaining issues soon. In the meantime, there is a summary of them on slide 3 of this talk,

[bieryAtFnal]

Here is a short summary of the issues:

• delete the old-style JSON file
• store the new-style JSON file in the test/ subdirectory
• update the generate.sh script to match what we observe for the directories of the generated Structs.hpp and Nljs.hpp files
• possibly change do_configure and do_unconfigure in the DAQModules to do_conf and do_scrap
• add some printouts to the RandomDataListGenerator module to show how default values for the configuration parameters are handled.

[bieryAtFnal]

I have created a branch in the listrev repo called feature/kurt_v2.0_additions that has some initial changes.

Specifically, what I've done is to update the generate.sh script as described above, added a scheme/moo_compile.note file that describes how to run the moo compile command that is needed to generate the JSON file, renamed listrev-job.jsonnet as list-reversal-app.jsonnet, and moved/renamed schema/listrev-job.json to test/list-reversal-app.json.

I'm not sure where the "job" nomenclature came from, but my preference is to keep the style of name that we had before (list-reversal-app.json). And, it made sense to me to store that file in the test/ subdirectory so that we can tell users to run the app using a path that includes listrev/test.

I will look into adding some print statements that demonstrate how configuration parameter defaults are handled, now that I have access to moo v0.4.1.

Also, I suspect that there may be some additional minor tweaks to this package based on recent DAQ Suite v2.0 changes. (Actually, I see that listrev/CMakeLists.txt was recently changed, so this may have already been taken care of.)

[brettviren]

Just to say this all sounds good to me. And two responses to what seems like some potential uncertainty:

• there's no semantic meaning (code wise) in how one names the do_*() methods so they can stay or change as desired
• the "job" file nomenclature I guess came from me. If so, it was made up without any real thought behind it. Please rename as you like!

[bieryAtFnal]

Thanks, Brett.

In the end, I don't think that I'm going to change do_configure/unconfigure. (Maybe I'll wait until we have "scrap" command functionality available... Which I'm in no hurry for...)
But, I did tweak some config parameter values and add some TRACE statements to print them out in RandomDataListGenerator.cpp.

I've tested the results with the stdin and REST command facilities, so things look good.