Today’s nightly windows Slicer starts, but all scripted modules are broken. Today’s nightly on mac works fine for me, as does 4.8.1 on the same windows machine.
The first error message is:
>>> import vtk
Traceback (most recent call last):
File "<console>", line 1, in <module>
ImportError: No module named vtk
probably a vtk9 packaging issue.
Since nothing was expected to change for the current nightly, I suspect r26834 introduced the regression.
Cc: @adamrankin
I had the same issue and could fix it locally by modifying SlicerLauncherSettings.ini. I had to add VTK Python packages location <APPLAUNCHER_DIR>/bin/Lib/site-packages to section [PYTHONPATH]. It would be great if somebody could fix the ini file generation.
This is beyond my level of knowledge. If Andras’ fix is the correct one, I can implement the change.
I’m not sure if the correct solution is to add/change paths in launcher settings (by changing External_VTKv9.cmake) or change VTK configuration to deploy site-packages to a different folder.
@jcfr Could you advise?
I can confirm the fix from Andras works. The SlicerLauncherSettings.ini file is in the bin directory and in addition to adding the line 12\path=<APPLAUNCHER_DIR>/bin/Lib/site-packages you need to increment the last line of the section to size=12.
Other notes: the nightly crashes when started over remote desktop but the 4.8.1 release does not (probably the OpenGL2 issue) and I see the same slowdown in Slice rendering that Andras reported.
@pieper Look like you meant “building the current trunk with Qt5 and VTK9 enabled” ? (there is no bin/Lib/site-packages directory in the current nightly windows package)
@jcfr I just downloaded and installed 4.9.0-2018-01-17 and I have a bin/Lib/site-packages:
9 posts were merged into an existing topic: Reslice performance issues on windows (moved)
@pieper This is very strange, the vtkmodules package is not expected to exist in the current nightly. It also doesn’t exist in the install tree used to create the package:
@pieper I confirm that after installing the nightly package (that was built on the factory), it is different from what you have.
I suspect the factory.perklab site maintained by @lassoan is uploading the installer and that would explain what you observed
factory.perklab has not been uploading packages for a while (temporarily disabled). I (and probably Steve as well) use the local package folder - c:\D\S4R\Slicer-build\_CPack_Packages\win-amd64\NSIS\Slicer-4.9.0-2018-01-17-win-amd64.
Unlikely, creation of the windows installer consist only in packaging of the install tree.
@lassoan It turns out that Slicerbot Perklab is uploading the package. See http://slicer.kitware.com/midas3/item/338765
Import of VTK modules when built against Qt5 and VTK9
This should be fixed by
It is interesting, because the package does not show up in the dashboard (no yellow boxes in perklab.factory lines). Are uploading to the dashboard and to MIDAS controlled by different settings?
Technically, no installer are uploaded to the dashboard. Only a .url file containing a link to the file uploaded on Midas.
I suspect you have the option WITH_PACKAGES enabled (see here). This would explain why the installer is generated and uploaded.
If you want to have the package created by only disable the upload of the package, you could set the option run_ctest_with_upload to 0.
@lassoan Did you have a chance to disable the upload ?
I’ve set WITH_PACKAGES option to FALSE, so from tomorrow it should not upload any package.
Do you know why setting run_ctest_with_upload to FALSE did not disable package upload?
I see on the dashboard that there overload.kitware have not been able to build Slicer successfully in the last couple of days. Could you try to fix that?
Also, the dashboard shows that overload.kitware still tries to build the nightly using VS2013. Is that supposed to work? Haven’t we switched to VS2015 along with Qt5 and VTK9?
