Tests on Debian hang about finalcif HOT 9 CLOSED

No worries, thanks a lot for finding it out. I suspect the line numbered code editor for displaying the saved CIF as guilty. I should investigate if there is a less memory-wasting solution.

from finalcif.

Hi, I thought the tests are failing because of gemmi changed the return type of find_pair() -> tuple instead of int.

I am referring to the error message

self = <tests.test_text.TestText testMethod=test_set_pair_delimited_empty>

    def test_set_pair_delimited_empty(self):
        self.block.set_pair('_foobar', delimit_string(''))
>       self.assertEqual(['_foobar', ''], self.block.find_pair('_foobar'))
E       AssertionError: ['_foobar', ''] != ('_foobar', '')

etc.

I did a fix in 34006bc, the commit after the version-113 tag.
Does it work with that commit?

from finalcif.

Thanks for the fix for gemmi incompatibility, however, this does not seem to change anything. Test runner just hangs at some point and has to be terminated manually. I recall there was similar problem before, maybe having something to do with GUI (which is not visible during Debian tests) or user interaction (which is also not possible during Debian tests).

from finalcif.

I can only guess.
There is one file that is downloaded to the home directory during a html checkcif. But that is never done inside tests.
I made a commit b51d44e to even remove the pathlib.Path instance to that file.

from finalcif.

Uups, accidentally closed the issue. It was meant to stay open.

from finalcif.

I made a commit b51d44e to even remove the pathlib.Path instance to that file.

Alas, this did not work. Maybe this has something to do with the fact that a display is not connected during tests. Interestingly, no such problem existed in v108. I can check whether it was v109 where the problem started appearing.

from finalcif.

Indeed the problem started appearing in v109. I ran the tests twice killing them when they hang. At both times call stack shows that the interrupt happened while in setUp() of tests/test_workfolder.py, somewhere in setText() of finalcif/gui/custom_classes.py. Is it possible that infinite loop/recursion happens there under certain conditions?

from finalcif.

Hm, strange. I can't see a possibility for an infinite loop.
Does it work if you disable test_edit_values_and_save() of tests/test_workfolder.py?

from finalcif.

Turns out tests do not hang, they merely require more RAM. I was working on a VM with 2 GB of RAM which sufficed before, but now tests/test_workfolder.py seems to require 2.8 GB RAM to run. Increasing RAM size to 4 GB did the trick. Sorry for the noise.

The last commit to "pass" the tests was 2bd28ff, thus the RAM-intensive code/test seems to have happened in ab118a2.

from finalcif.