Unable to follow example in readme.md

[AdamBanham]

Hi Burke,

I believe I have installed everything and have a working haskell installation, as both gradlew tests and stack tests passed. However, when I run the following commands mentioned in the readme (below), I do not get any output into ./var. I also don't see any folder called data nor data/exercise1.xes in the checkout, is this xes meant to be generated on the fly?

scripts/red.sh data/exercise1.xes invokes the Toothpaste Miner prototype, outputting var/exercise1.png and various intermediates.

I get the following error (below) from xesdcdt.py, which seems to be looking for the xes file. Can I throw any standard xes in and get a result? I have tried the sepsis event log, it seemed to work. However, there was a lot of IO spam about leafs and nodes, is this intended? (no result after 5 minutes of running).

C:\Users\adam\AppData\Roaming\Python\Python39\site-packages\pm4py\objects\log\log.py:19: UserWarning: pm4py.objects.log.log is deprecated. please use the class pm4py.objects.log.obj instead
  warnings.warn("pm4py.objects.log.log is deprecated. please use the class pm4py.objects.log.obj instead")
Traceback (most recent call last):
  File "F:\Projects\toothpaste\scripts\xesdcdt.py", line 116, in <module>
    main()
  File "F:\Projects\toothpaste\scripts\xesdcdt.py", line 111, in main
    log = xes_importer.apply(args.xesfile)
  File "C:\Users\adam\AppData\Roaming\Python\Python39\site-packages\pm4py\objects\log\importer\xes\importer.py", line 69, in apply
    return variant.value.apply(path, parameters=parameters)
  File "C:\Users\adam\AppData\Roaming\Python\Python39\site-packages\pm4py\objects\log\importer\xes\variants\iterparse.py", line 300, in apply
    return import_log(filename, parameters)
  File "C:\Users\adam\AppData\Roaming\Python\Python39\site-packages\pm4py\objects\log\importer\xes\variants\iterparse.py", line 338, in import_log
    f = open(filename, "rb")
FileNotFoundError: [Errno 2] No such file or directory: 'data/exercise1.py'

[adamburkegh]

Hi, noted on the missing example log.

Yes, the input XES is just a standard event log. It's pre-processed by the python script and then mined by Haskell.

Yes, you are probably right that the logging is too verbose by default.

It does work on sepsis, but it's a challenging log. For proof-of-installation, try something smaller and with less activities.

[adamburkegh]

I have pushed the (tiny) example log data/exercise1.pnml

[AdamBanham]

Can confirm that the exercise1.xes works a lot quicker than the sepsis event log. Is there a chance that you can handle errors or hold the command prompt at the end of the script? On Windows, the script creates another prompt and will close as soon as the script errors out or completes. Or is the intention that the output should be piped to a debug file and not read the output in the additional prompt?

I can see the following pieces of output produced:

exercise1.dcdt exercise1.pnml exercise1.ptree

However, the gradle build is not working anymore. Double-checked the tests and found that it was expecting 0.8.2 prom-helpers instead of the installed 0.8.7. So I updated the version in the gradle build and it now cannot compile (.\gradle test). I have included the error below. I checked out the tagged 0.8.2 in prom-helpers, but the error remains. The Haskell component seems to be fine.

> Task :compileJava F:\Projects\toothpaste\src\main\java\qut\pm\spm\conformance\EarthMoversCalculator.java:25: error: constructor EMSCParametersLogModelAbstract in class EMSCParametersLogModelAbstract cannot be applied to given types; super(EMSCParametersDefault.defaultDistanceMatrix, ^ required: DistanceMatrix<TotalOrder,TotalOrder>,XEventClassifier,LanguageGenerationStrategyFromModelImpl,boolean,boolean,int found: DistanceMatrix<TotalOrder,TotalOrder>,XEventClassifier,LanguageGenerationStrategyFromModelImpl,boolean,boolean reason: actual and formal argument lists differ in length F:\Projects\toothpaste\src\main\java\qut\pm\spm\conformance\EarthMoversTunedCalculator.java:30: error: constructor LanguageGenerationStrategyFromModelImpl in class LanguageGenerationStrategyFromModelImpl cannot be applied to given types; new LanguageGenerationStrategyFromModelImpl(1000 60 20, MASS_COVERAGE), ^ required: long,double,long found: int,double reason: actual and formal argument lists differ in length 2 errors

> Task :compileJava FAILED

FAILURE: Build failed with an exception.

• What went wrong: Execution failed for task ':compileJava'. > Compilation failed; see the compiler error output for details.

• Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

• Get more help at https://help.gradle.org

Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0. Use '--warning-mode all' to show the individual deprecation warnings. See https://docs.gradle.org/6.6.1/userguide/command_line_interface.html#sec:command_line_warnings

BUILD FAILED in 5s

[adamburkegh]

On the output behaviour - I was assuming people would just be running it from a command line. In fact, red.sh is a bash script, how are you running it at all without using git bash or something?

On the gradle part, I had a look and the culprit is not actually prom-helpers, it's the EarthMoversStochasticConformance plugin. Looks like it changed again in June, and because ProM plugin minor versioning leaves something to be desired, this code broke.

Actually the final Java part is just to generate the DOT file from PNML. If you have code to do that in python, I'd happily take it off the path for discovery. Then the Java code would just be for the experimental conformance, which most people aren't going to use.

[adamburkegh]

I've checked in a fix, can you take a look?

[AdamBanham]

Output from red.sh:

The recent changes seem to fix the issue. Got to love the lack of versioning in ProM packaging.

On the output behaviour - I was assuming people would just be running it from a command line. In fact, red.sh is a bash script, how are you running it at all without using git bash or something?

No I am running it from command line (or powershell), the script always seem to make a new process and closes the process when it finishes (or a call errors out). Which makes capturing the stdout a bit hard, but maybe its on me.

Actually the final Java part is just to generate the DOT file from PNML. If you have code to do that in python, I'd happily take it off the path for discovery. Then the Java code would just be for the experimental conformance, which most people aren't going to use.

It's not hard to convert pnml to dot, its just an xml standard, doing it deterministically requires a walk of the model though. Styling the dot graph nicely is a bit harder, but not impossible. I don't have code ready to go, but I could get something together pretty quickly if you wanted. I think I may have done it in python once before.

[adamburkegh]

Great, glad it's working again. Yep, that image is the expected output. You don't need the last step at all if feeding the Petri net to something else, just the PNML file. The tpminer scripts do that by default.

Going to close this issue. I think you have convinced me to replace the Java step with Python or Haskell though.

[AdamBanham]

Going to close this issue. I think you have convinced me to replace the Java step with Python or Haskell though.

Probably not a bad idea, given the heartache that java has been giving you.

[adamburkegh]

It's just a bit overcomplicated at the moment. Too many language environments makes it fragile.