This allows simulation and statistical model checking to be performed on
a wider range of model sources, not just PRISM language models.
SimulatorEngine and associated files have had their dependencies on
ModulesFile removed, now using ModelGenerator and RewardGenerator
instead. SimulatorEngine also no longer uses TransitionList and Updater:
these are internal to the ModulesFileModelGenerator which provides
ModelGenerator access to a PRISM model.
Associated simulator classes have been altered too. Path and Sampler
classes now use a ModelInfo and RewardGenerator, rather than a
ModulesFile and TransitionList. Path classes store an action object and
action string, rather than action info specific to a ModulesFile. This
means that the methods getTransitionModuleOrAction and
getTransitionModuleOrActionIndex disappear from SimulatorEngine,replaced
by getTransitionAction and getTransitionActionString.
Usage of SimulatorEngine changes slightly. There is now a loadModel()
method, after which paths are created or statistical model checking
initiated, rather than a ModulesFile being passed to these latter
methods as done previously. The main function of SimulatorEngine is
manual/automatic path creation and statistical model checking. Exploring
states/transitions of a model is now de-emphasised, since this is
already provided directly by the passed in ModelGenerator. But
SimulatorEngine still provide access to information about transitions
etc. in the model because it allows this to be queried for arbitrary
states along created paths. The method checkModelForSimulation() has
been removed - since these checks now occur earlier at the point of
creating a ModelGenerator - and is now in Prism instead.
In Prism, in line with other recent changes, simulation-based methods
now use the currently loaded model, rather than taking a passed in
ModulesFile. For use within these methods, or from other methods that
want to access SimulatorEngine directly, there is a new method
loadModelIntoSimulator().
Export the values of the following standard compiler and compiler flag
variables in the main makefile, avoiding the need to pass through each
one to child make processes manually:
CC
CXX
LD
JAVAC
JAVACC
Since JAVAC is manually exported as "$(JAVAC) $(JFLAGS)" by the main
makefile, additionally separate JAVAC and JFLAGS into separate variables
from the perspective of child make processes.
Rename the following makefile variables for the sake of clarity in child
makefiles:
SRC_DIR -> PRISM_SRC_DIR
CLASSES_DIR -> PRISM_CLASSES_DIR
OBJ_DIR -> PRISM_OBJ_DIR
LIB_DIR -> PRISM_LIB_DIR
INCLUDE_DIR -> PRISM_INCLUDE_DIR
IMAGES_DIR -> PRISM_IMAGES_DIR
DTDS_DIR -> PRISM_DTDS_DIR
The helper script src/scripts/printversion.sh also makes use of the
value of SRC_DIR exported from the main makefile, so use PRISM_SRC_DIR
in that script too.
As noted in #68, the javah tool has been removed in JDK10. Here, we switch to the new way of generating the JNI .h files, using the -h option of the regular javac compiler.
We have to adapt all Makefiles (not only those in directories that contain classes with native methods), as javac compiles all required classes (and generates their JNI headers) beyond the directory with the Makefile.
The .h files generated by javac -h had a different naming scheme, now there is a prefix for the package name. To avoid having to touch all the #includes, we generate the new .h files in prism/include/jni and provide legacy headers in the old location and with the old name, forwarding the the corresponding new header. In the future, at an appropriate moment, those legacy headers can be removed and replace with direct includes.
Currently, there is a post-processing step on Windows: After the .h file is generated, dos2unix is called to replace the Windows CRLF line endings. Otherwise, the generated headers show up as changed files in version control. As now there are no special targets for the generation of the .h files anymore, we move to a global post-processing step and call dos2unix on prism/include/jni/*.h at the end of building.
Now, all the top-level packages have Makefiles and search for Java files
in subpackages.
If a .java file does not get picked up by the Makefiles, it will
nonetheless be compiled if referenced from somewhere else in the
project, but dependency tracking at the level of 'make' is broken.
Dave Parker