Pushed new branch T24439-categorical-imperative.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mar 27 2018
Did a quick grep for StartVS and replaced any reference by telling the reader to open the solution file instead.
Pushed new branch T24351-remove-reference-to-bat.
Basically what you said. We have a number of executables in the /bin/ folder (however many BlueBerryApps and command line applications have been switched on). As we might have either one, several or none of each we need to trigger prerequisite collection for each of them. However for many applications (such as the twenty-odd diffusion command line app activated by a single CMake switch) that resulted in unbearably slow installer builds.
This has been an issue for example in T22794 where the solution for now was to just not add the prerequisite trigger for command line apps.
Mar 26 2018
The provided files significantly speed up the analysis for each individual executable. However, they do need some adaption to our use case, as previously we started a new analysis for each executable and they automatically do the analysis for each executable found in the same folder. No using this automatic feature still results in a long (if now somewhat shorter) package build.
Is there some kind of intended replacement for clang? What is the go-to way for other tools?
@hentsch at least for CEST showing error bars was one of the requirements. So no.
Mar 5 2018
Sorry to be a nitpicker, but regarding 3 (and as I can find no reference to SlicedImage anywhere in the code or phabricator, apart from this task):
Mar 2 2018
Mar 1 2018
Feb 28 2018
I do not really mind either way. Implementation should be pretty straightforward, it does not really save any lines of code. Instead of
mitk::Image::Pointer image = dynamic_cast<mitk::Image*>(node->GetData()); if(image.IsNull()) { //Error handling here }
- How maintenance intensive is the wrapping going to be? The more custom the solution and the more hand-written code it contains the more of a nightmare I assume it to be if the inevitable interface change of some central class arrives.
- Is there a way to automatically test this via a python dart client? Do you already have something like that?
- If I understand correctly we "only" have to wrap parent classes of the classes we want to use in python?
Feb 20 2018
Pushed new branch T24293-locale-switch-in-CEST-2.
Pushed new branch T24293-locale-switch-in-CEST.
Feb 19 2018
Feb 15 2018
@wasserth Could you provide the error logs?
Feb 9 2018
The change to the python use, sytem instead of setup, might require us adding a redistributable/installer to the MITK installer.
See also T24085: MITK make PACKAGE does not work on windows if Python is enabled for windows package errors.
A pull request has been opened with CTK to include the changes necessary to support our switch to python3
Feb 8 2018
Got the build working on windows up to and including the MITK build. There is a CTK change that I will contribute once I have verified Python works fine with MITK and python 3 and CTK still builds with python 2.
Feb 6 2018
I did not manage to get a running windows build with cotire.
Feb 5 2018
I was just pointing out that it goes beyond convenience.
I would prefer offering the option to ensure naming. Partly because a lot of the first extensions will be maintained by us anyway and we currently have a naming convention.
To clarify:
There are three external directories,
A/Modules/Potato B/Modules/Tomato C/Modules/Banana
Even more important than having a default would be consistency. Whether you DEPEND on MITKSegmentation or AwesomeSegmentation should not be determined by the order of external modules.
My suggestion could only enforce org.* if you set the extension names explicitly to "". Would this still be to restrictive for you?
I seem to remember that not working. At least this should make sure there is always a ModulePrefix.
Didn't you have to switch MITK_MODULE_NAME_PREFIX to ""?
Feb 2 2018
Feb 1 2018
This would be a good community day candidate.
So far we have solved this by setting the MITK_MODULE_NAME_PREFIX correspondingly as it will be used to determine what, if anythingm should be used as a prefix.
Links have been removed, the data section had been removed previously. Presumably because the TCGA no longer offers the data itself. instead it can be gotten via https://portal.gdc.cancer.gov/legacy-archive/ . However that tool seems to be inconvenient enough to be not much help.
I would suggest a best practice of one naming scheme per extension directory and adding it to the PluginList.cmake
list(APPEND extensionNames exProject) # Plug-ins must be ordered according to their dependencies set(MITK_PLUGINS org.exProject.gui.qt.testplugin:ON )
I think that is governed by this code, which is then used by CTK
#! #! Extract all library names which are build within this project #! #! \ingroup CMakeUtilities macro(ctkMacroGetAllProjectTargetLibraries all_target_libraries varname) # Allow external projects to override the set of internal targets if(COMMAND GetMyTargetLibraries) GetMyTargetLibraries("${all_target_libraries}" ${varname}) else() set(re_ctklib "^(c|C)(t|T)(k|K)[a-zA-Z0-9]+$") set(re_ctkplugin "^org_commontk_[a-zA-Z0-9_]+$") set(_tmp_list) list(APPEND _tmp_list ${all_target_libraries}) #message("calling ctkMacroListFilter with varname:${varname}") ctkMacroListFilter(_tmp_list re_ctklib re_ctkplugin OUTPUT_VARIABLE ${varname}) #message(STATUS "getallctklibs from ${all_target_libraries}") #message(STATUS varname:${varname}:${${varname}}) endif() endmacro()
Jan 31 2018
As far as I am aware prior behaviour was showing the value of the topmost visible image at a given point. So if you have multiple images at different locations in the world geometry you would not get "No image information at this position" if you happen to set the crosshair at a location which is out of bounds for the topmost image.
Jan 29 2018
Jan 25 2018
Pushed new branch T24085-mitk-python-installer-fix.
Jan 24 2018
Jan 19 2018
Just to clarify, two versions of the plugin means just two different histogram widgets in the statistics view.
Jan 18 2018
Has been fixed.
Pushed new branch T24021-fix-segmentationinterpolationtest.
That seems to be it, my regular build still uses a ITK 4.11 template header instead of the ITK 4.12.2 one.
The cause of the error seems to be in
Modules\Segmentation\Algorithms\mitkShapeBasedInterpolationAlgorithm.cpp
in the following lines (std::cout added for debugging purposes)
isoContourFilter->SetInput(binaryImage); isoContourFilter->SetFarValue(maximumDistance + 1); isoContourFilter->SetLevelSetValue(0.5); std::cout << "LevelSetValue: " << isoContourFilter->GetLevelSetValue() <<std::endl; // Prints // LevelSetValue: 0 - for my regular build // LevelSetValue: 0.50 - for the dart client
Jan 15 2018
Jan 12 2018
Pushed new branch T24021-fix-logo-annotation-test.
Pushed new branch T24021-fix-debug-leaks.
Jan 11 2018
Pushed new branch T24043-fix-dashboard-errors.
Jan 10 2018
Jan 9 2018
Pushed new branch T24021-fix-test.
I believe this has happened at some point.
Tests no longer fail as there is no longer a uid property.