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.
Expressions are now evaluated exactly in parametric / exact model checking mode for:
- state updates
- command guards
- the if part of if-then-else expressions
- reward guards
- reward values
- Boolean expressions in RESULTS in property files
Add various test cases to check that it is now handled properly.
Using the infrastructure from the previous commit, we request exact evaluation
of constants in exact and parametric model checking mode.
Additionally, note where we deliberately choose non-exact evaluation mode.
Add corresponding test cases.
Previously, constants that are defined via an expression
were evaluated using standard (integer or floating point) arithmetic,
even in parametric or exact model checking mode.
This commit provides the infrastructure for requesting that constant
expressions are evaluated using exact arithmetic.
To keep the API backward compatible, we introduce additional methods that
offer an 'exact' flag, but keep the old methods as well. Those default to
normal arithmetic.
TypeDouble constants are kept as rational numbers, while int and boolean
constants are converted to Java data types. For int, an exception is raised
if the value can't be exactly represented by Java int.
Only F/U operators with upper bound have a bounded path length and can
thus skip the maximal path length checks.
Test cases (will continue sampling beyond the default max path length,
appearing to hang):
prism prism-examples/dice/dice.pm -pf 'P=?[ F>2 s=0 ]' -sim
prism prism-examples/dice/dice.pm -pf 'P=?[ F>2 s=0 ]' -sim -ctmc
After this fix, the usual error message for unbounded operators is
generated.
We now explicitly remember if there was an upper bound instead of
relying on an upper bound of Integer.MAX_VALUE in the case of an
absent bound.
Statistical MC, P[F]/P[U] in discrete time setting with time bounds.
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.
Currently, building PRISM with parallel building does not work,
as there are dependencies between targets that are not fully
encoded in the Makefiles. Building with -j n flag would lead to error.
Now, we add the .NOTPARALLEL target to most of the Makefiles,
which tell GNU make to ignore the -j flag. Note that this
only inhibits parallel builds for the current Makefile, we
thus have to specify it for all sub-Makefiles as well
(see https://www.gnu.org/software/make/manual/html_node/Parallel.html)
For the external libraries, CUDD and LPSolve don't seem to mind building
in parallel, so we don't inhibit there and can get some minor compile time
speed-up by using multiple cores if the -j option is specified.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@12202 bbc10eb1-c90d-0410-af57-cb519fbb1720
During reward construction in the explicit engine using the new ModelGenerator
functionality (see SVN 11772), the check for transition rewards was missing
(he explicit engine currently does not support transition rewards for DTMCs and CTMCs).
This commit adds functionality to ModelInfo to determine whether a reward structure
defines transition rewards and adds a corresponding check during reward construction.
Example: prism-examples/dice/dice.pm with R=?[ F s=7 ] and -explicit returns 0 instead
of an error message.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@11802 bbc10eb1-c90d-0410-af57-cb519fbb1720
- Extended functionality available through the prism.Prism API when using ModelGenerators
- Improvements to ModelGenerator interface wrt handling of rewards (and also labels)
- Explicit engine model checkers now build rewards from a ModelGenerator, not a RewardStruct.
This is now (optionally) attached with the setModulesFileAndPropertiesFile method.
- New code to generate symbolic models from ModelGenerators (useful, if not super efficient)
- Move createVarList() method from ModelGenerator up to ModelInfo
- Some code tidying in LabelList
Code was previously at https://github.com/prismmodelchecker/prism-svn/tree/model-generator
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@11772 bbc10eb1-c90d-0410-af57-cb519fbb1720
When a path is loaded in the simulator view of the GUI, selecting any step
but the last step can produce erroneous display of the update in the
"Manual exploration" field. The problem is that the updates are computed for
display relative to the variables values of the last state of the whole path
instead of relative to the state where the step originates.
This fix keeps the information about the correct state available for computing
the update display. This was a regression, introduced in SVN 10939 and should only
affect the GUI display, not computations.
To reproduce, use e.g.:
dtmc
module one
x: [0..3] init 0;
[] true -> (x' = min(3, x+1));
endmodule
Simulate for a few steps. The update information for the non-last steps of the path will
display incorrect values. This also occurs for display of CTL counterexamples.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@11281 bbc10eb1-c90d-0410-af57-cb519fbb1720
When building a model from the GUI with the explicit engine, constant were sometimes not
updated correctly:
(1) Open xprism, switch to explicit engine
(2) Load a model with undefined constants, e.g., brp.pm
(3) Build the model, setting constants (e.g., 2 and 3)
(4) Build the model again, setting *other* constants (e.g., 22 and 3)
In step (4), the log file reflects the changed constants,
but the generated model has the same number of states as
in step (3) and is fact built with the constants of step (3).
The cause:
If the PRISM file is not reloaded, then the currentModelGenerator
remains the same. In ModulesFileModelGenerator.initialise(), called
from setSomeUndefinedConstants() in step (3), the modulesFile is
overwritten with the modulesFile where the constants set in step (3)
have been replaced in the AST with the concrete values.
In step (4), there are no more AST-elements with undefined constants
and hence the modules file does not reflect the changed constants when
the constants in the constant list are changed.
The fix is to keep a copy of the original modules file in the
ModulesFileModelGenerator which is freshly deepCopyied and
processed in the subsequent calls to initialise().
Regression introduced in SVN r10996 when switching to the
ModulesFileModelGenerator infrastructure.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@11159 bbc10eb1-c90d-0410-af57-cb519fbb1720
Joachim Klein