Looks like more py3 stuff not tested on py2.
Sooner or later you have to switch to a py3 build because py2 officially expires in less than three months.
Again this highlights the need for basic testing on a python2 build. Folks messing with code using only python3 are breaking stuff.
I guess most developers have moved to the Py3/Qt5 combination on their systems which is good. And it's recommended that they should no longer worry about Py2 or Qt4 because it is and always was a nightmare to maintain all the combinations Py2/Qt4, Py2/Qt5 or Py3/Qt5 (Py3/Qt4 was never officially supported).
Nevertheless, if someone runs into a Py2 or Qt4 problem that can be easily fixed I am still open to make a fix for it. As DeepSOIC already said there are systems where Qt5 causes quite some problems whereas Qt4 worked perfectly well.
thanks for the replies. If that is the state for python2 then the default build should be python3. I never had any need or reason to prefer py2, I just used the default build.
The problem is that the executable "python" on most systems still points to python2. You have to manually change this entry to python3.
Program received signal SIGSEGV, Segmentation fault.
#0 /lib64/libc.so.6(+0x38600) [0x7f6a6db43600]
#1 /lib64/libpython2.7.so.1.0(Py_InitModule4_64+0x42) [0x7f6a6a69ce42]
#2 /usr/lib64/python3.7/site-packages/PySide/QtCore.so(PyInit_QtCore+0x4f) [0x7f6a5a8b2ddf]
#3 /lib64/libpython3.7m.so.1.0(_PyImport_LoadDynamicModuleWithSpec+0x182) [0x7f6a7244e382]
Look at your call stack. You have a mix-up of Py2 and Py3 which is not going to work. Apparently the problem is the existence of PySide which is built for Py2. You have to un-install it completely and instead install PySide2.
TypeError: cannot return std::string from Unicode object
This error is raised by PyCXX. For Py2 it does check if the object behind the scene is of type unicode and if yes it raises that error.
ust in case this is clue, it seems I get a spurious extra new on the penultimate line of user.cfg at each run of FC. Also note the lack of newline after the last paramGroup entry. I do not know whether this apparently minor bug has any knock on effects, perhaps when re-reading the file later. I'm guessing the newline is being written at the wrong time inside a loop.
For reading or writing the user.cfg we use the xerces library and for some reason it (sometimes) adds these extra newlines. However, this is not a problem at all because if they are there or not it has no impact on the actual content because they appear between two tags.
Are there any interim releases of 0.19 or does " stable" mean 0.18 ?
The v0.19 at the moment cannot be considered stable at all. Many things have been merged in the recent weeks and it will take several weeks or months to find and fix all the regressions. The last official release is v0.18 and this is can be considered as stable.
Is it hard to back port this to 0.18?