Bug in newProcess method of jSymbolicRunner class

[codaich]

jSymbolic will never carry out a feature extraction if newProcess is called. This is true for both the GUI and the command line.

This can be observed by putting in a few simple System.out checks in the jSymbolic class to follow execution, and running the code with something like:

java -Xms16m -Xmx64m -jar jSymbolic2.jar ./temp ./feature_values_1.xml ./feature_descriptions_1.xml

If this cannot be fixed to work properly, then we should revert to simply running the code without any of this memory checking; this way the user can manually assign memory if need to be. This is not the best option, but the current implementation effectively does nothing to increase allocated memory automatically, and interferes with manual intervention.

[codaich]

Whatever fix is adopted, this will remain a fidgety issue, so we should include mention of it and how it is addressed in the manual.

[codaich]

If a fix is adopted that causes execution to start through a class other than jSymbolicRunner, then this needs to be adjusted in the project settings used to generate the jar (e.g. the NetBeans Run Project Properties).

[codaich]

Once this is fixed, it is necessary to verify that both the GUI and the command line prominently report out of memory errors (including in connection to which input file) and continue execution even so.

[codaich]

If a fix is adopted that allows more memory to be allocated automatically (as is the intention of the current code), then we could perhaps increase the values of MIN_HEAP_SIZE and RECOMMENDED_HEAP_SIZE.

[codaich]

Once a fix is adopted (and the new features are added) we will need to re-test all MIDI and MEI files for memory errors.

We will also need to verify that the Rodan workflow notes and is able to deal with out-of-memory problems.

[codaich]

Only 2149 out of 2150 files had features sucessfully extracted from MIDI_Malcolm dataset

• Missing one due to running out of memory?
• Check once command line processing properly reports running out of memory error.

[dinamix1]

This issue was fixed by commit 53011156d8debe3248a6e807a3878d03fd267ffb

[codaich]

Fixed in commit 53011156d8debe3248a6e807a3878d03fd267ffb by reverting to needing to specify max heap size at runtime manually when dealing with large files. May eventually wish to revisit this for convenience, but both Tristano and I have tried to do fix it without success, so it may not be possible under current Java.