What do you think about require python 3 for donate-cpu.py ? This script is only run by a few people so we don't have to ensure it will work for everybody.
An advantage would be that we can timeout Cppcheck analysis. With Python 3 we can use check_output for that.
daca@home has been too inactive lately. I have seen a couple hangs and guess those are part of the problem. It is possible there is a computer right now that is dedicated for daca@home but it has hanged.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For me it would be absolutely ok to switch to Python 3.
We could target the beginning of 2020 for requiring Python 3. Or do you want to switch faster?
I suggest to add an eye-catching message to the client (if executed with Python 2) with a warning that only Python 3 is supported after a specific date or so.
I do also observe the client to hang for many hours sometimes (10 hours and more). It would be useful to abort analysis after some time to not waste CPU. Some packages seem to be impossible to finish with specific Cppcheck versions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Another advantage is the lzma/.xz support that Python 3.3 has out of the box.
See https://trac.cppcheck.net/ticket/9508
For older versions there are backports, but they have to be installed manually and also explicitly supported by the script I guess.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What do you think about require python 3 for donate-cpu.py ? This script is only run by a few people so we don't have to ensure it will work for everybody.
An advantage would be that we can timeout Cppcheck analysis. With Python 3 we can use
check_output
for that.daca@home has been too inactive lately. I have seen a couple hangs and guess those are part of the problem. It is possible there is a computer right now that is dedicated for daca@home but it has hanged.
For me it would be absolutely ok to switch to Python 3.
We could target the beginning of 2020 for requiring Python 3. Or do you want to switch faster?
I suggest to add an eye-catching message to the client (if executed with Python 2) with a warning that only Python 3 is supported after a specific date or so.
I do also observe the client to hang for many hours sometimes (10 hours and more). It would be useful to abort analysis after some time to not waste CPU. Some packages seem to be impossible to finish with specific Cppcheck versions.
Another advantage is the lzma/.xz support that Python 3.3 has out of the box.
See https://trac.cppcheck.net/ticket/9508
For older versions there are backports, but they have to be installed manually and also explicitly supported by the script I guess.