Peter, Du warst der letzte Aktive ;)

This was resolved by T25983

For the transition process, these bits from the git merge manpage could be useful as well:

I just picked this up in a small experiment:

Nightly CI looks good as well.

As @kalali pointed out there was some previous tooling research done internally: T22218

I will close this task now. There was valuable work done on adding and updating tests, but this will never be finished anyway. New developments in that area will be tracked in T26962.

I will close this task now. There was valuable work done on adding and updating tests, but this will never be finished anyway. New developments in that area will be tracked in T26962.

I can confirm this works. One downside I realized with the current solution is that it only works if the test is executed through ctest, i.e. ctest -R Pytohn , but if you start the driver directly the same problem occurs. I think it is ok for now, but would be some motivation to find a solution that works without a special environment, since for example while debugging you usually start the executable directly.

Thanks for picking up!

Possible fix is a reordering of includes in mitkPythonService.h , I could not find out exactly what's wrong.

Sorry for jumping in late. I'm afraid currently we are anyway not testing any encoding stuff sufficiently.

Pushed new branch T26431-compilation-fixes-gcc9-clang8.

Looks like the Slicer warning is important, but still it succeeds in loading the data. The numerical error is rather low. Found this discussion which also links to the python code Slicer is using and which emits the warning. Could be of some use for further investigations. https://discourse.slicer.org/t/dicom-scalar-volume-load-irregular-geometry-warning-overly-stringent/3761/14

@full @schererj @kislinsk : how did you convert these files exactly? If I load the DICOM with a current MITK Workbench -> no problem, re-init fine. Save as nifti, quit, restart, load nifti, re-init -> no problem as well.

@isensee : what is the source of these images? any chance to get the original DICOM?

Log output with debug version:

Discussed at MITK meeting: workbench should not crash, no matter how we handle 2D segmentations

Discussed in the MITK meeting: actions will be kept, @kalali will split this task further

Discussed this in the MITK meeting, we agreed this would be an improvement

Ok, warning level harmonization for Linux and Windows turns out to be impossible at the moment, we have to wait for MSVC updates. The other ideas have been fixed and merged.

Seems we cannot even turn on unused parameter warnings since to many are triggered by external code. There are workarounds, but the proper solution would be on the MSVC side to handle external include directories different from standard ones. This is ongoing work, and at some point there will be CMake support as well

Latest MSVC update is incompatible with our boost version and leads to compile errors. I will update Boost and add a patch to include the commit mentioned in this thread: https://github.com/boostorg/iostreams/issues/60

Ok, further reading lead to the /permissive- option which actually should detect some of these issues in the latest MSVC 2017 Update 15.8 . But I guess this will detect also a lot of other non-standard stuff. Let's see, could be worth the effort in the long run, I will test and report here
`

In T25469#165910, @floca wrote:

If VS has a warning for these. It would be great to activate them.

First suggestion: /W34100 , make unused parameters a level 3 warning (our warning level)

Compile errors in mitkBaseData.cpp

update: gcc works

In T23343#116298, @floca wrote:

I would have (minor) concerns with directly merging it. The comments raised for the last commit.

Pushed new branch T24628-dcm-toolkit-update.