From arnaudgelas at gmail.com Thu Oct 1 09:39:02 2015 From: arnaudgelas at gmail.com (Arnaud Gelas) Date: Thu, 1 Oct 2015 15:39:02 +0200 Subject: [ITK-dev] ITKExamples OpenCV related link errors Message-ID: Hi all, I have built ITK with BridgeOpenCV turned ON and when I compile ITKExamples, I get the following linking errors: FAILED: : && /usr/lib/ccache/c++ -msse2 -g src/CMakeFiles/ImageCompareCommand.dir/ImageCompareCommand.cxx.o -o bin/ImageCompareCommand -rdynamic /home/arnaud/install/lib/libITKIOBMP-4.9.so.1 -lexpat -lz /home/arnaud/install/lib/libITKIOGDCM-4.9.so.1 /home/arnaud/install/lib/libITKIOGIPL-4.9.so.1 -ljpeg /home/arnaud/install/lib/libITKIOJPEG-4.9.so.1 /home/arnaud/install/lib/libITKIOMeta-4.9.so.1 /home/arnaud/install/lib/libITKIONIFTI-4.9.so.1 /home/arnaud/install/lib/libITKIONRRD-4.9.so.1 -lpng /home/arnaud/install/lib/libITKIOPNG-4.9.so.1 -ltiff /home/arnaud/install/lib/libITKIOVTK-4.9.so.1 /home/arnaud/install/lib/libITKLabelMap-4.9.so.1 /home/arnaud/install/lib/libITKQuadEdgeMesh-4.9.so.1 /home/arnaud/install/lib/libITKPolynomials-4.9.so.1 /home/arnaud/install/lib/libITKBiasCorrection-4.9.so.1 /home/arnaud/install/lib/libITKBioCell-4.9.so.1 /home/arnaud/install/lib/libITKDICOMParser-4.9.so.1 /home/arnaud/install/lib/libITKIOSpatialObjects-4.9.so.1 /home/arnaud/install/lib/libITKFEM-4.9.so.1 /home/arnaud/install/lib/libITKIOMesh-4.9.so.1 /usr/lib/x86_64-linux-gnu/hdf5/serial/lib/libhdf5_cpp.so /usr/lib/x86_64-linux-gnu/hdf5/serial/lib/libhdf5.so -lpthread -ldl -lm /home/arnaud/install/lib/libITKIOBioRad-4.9.so.1 /home/arnaud/install/lib/libITKIOCSV-4.9.so.1 /home/arnaud/install/lib/libITKIOGE-4.9.so.1 /home/arnaud/install/lib/libITKIOSiemens-4.9.so.1 /home/arnaud/install/lib/libITKIOHDF5-4.9.so.1 /home/arnaud/install/lib/libITKIOLSM-4.9.so.1 /home/arnaud/install/lib/libITKIOMRC-4.9.so.1 /home/arnaud/install/lib/libITKIOStimulate-4.9.so.1 /home/arnaud/install/lib/libITKIOTransformHDF5-4.9.so.1 /home/arnaud/install/lib/libITKIOTransformInsightLegacy-4.9.so.1 /home/arnaud/install/lib/libITKIOTransformMatlab-4.9.so.1 /home/arnaud/install/lib/libITKKLMRegionGrowing-4.9.so.1 /home/arnaud/install/lib/libITKWatersheds-4.9.so.1 /home/arnaud/install/lib/libITKOptimizersv4-4.9.so.1 /home/arnaud/install/lib/libITKVideoBridgeOpenCV-4.9.so.1 /home/arnaud/install/lib/libITKVtkGlue-4.9.so.1 /home/arnaud/install/lib/libitkgdcmMSFF-4.9.so.1 /home/arnaud/install/lib/libitkgdcmDICT-4.9.so.1 /home/arnaud/install/lib/libitkgdcmIOD-4.9.so.1 /home/arnaud/install/lib/libitkgdcmDSED-4.9.so.1 /home/arnaud/install/lib/libitkgdcmCommon-4.9.so.1 /home/arnaud/install/lib/libITKNrrdIO-4.9.so.1 /home/arnaud/install/lib/libITKIOXML-4.9.so.1 /home/arnaud/install/lib/libITKMetaIO-4.9.so.1 /home/arnaud/install/lib/libITKgiftiio-4.9.so.1 -lexpat /home/arnaud/install/lib/libITKniftiio-4.9.so.1 /home/arnaud/install/lib/libITKznz-4.9.so.1 /home/arnaud/install/lib/libITKIOIPL-4.9.so.1 /home/arnaud/install/lib/libITKIOTIFF-4.9.so.1 /home/arnaud/install/lib/libITKIOTransformBase-4.9.so.1 /home/arnaud/install/lib/libITKSpatialObjects-4.9.so.1 /home/arnaud/install/lib/libITKMesh-4.9.so.1 /home/arnaud/install/lib/libITKPath-4.9.so.1 /home/arnaud/install/lib/libITKOptimizers-4.9.so.1 /home/arnaud/install/lib/libITKStatistics-4.9.so.1 /home/arnaud/install/lib/libitkNetlibSlatec-4.9.so.1 /home/arnaud/install/lib/libITKVideoIO-4.9.so.1 /home/arnaud/install/lib/libITKIOImageBase-4.9.so.1 /home/arnaud/install/lib/libITKVideoCore-4.9.so.1 -lopencv_videostab -lopencv_video -lopencv_ts -lopencv_superres -lopencv_stitching -lopencv_photo -lopencv_ocl -lopencv_objdetect -lopencv_nonfree -lopencv_ml -lopencv_legacy -lopencv_imgproc -lopencv_highgui -lopencv_gpu -lopencv_flann -lopencv_features2d -lopencv_core -lopencv_contrib -lopencv_calib3d -ljpeg -lpng -ltiff /home/arnaud/install/lib/libITKVTK-4.9.so.1 /home/arnaud/install/lib/libITKCommon-4.9.so.1 /home/arnaud/install/lib/libitkdouble-conversion-4.9.so.1 /home/arnaud/install/lib/libitksys-4.9.so.1 /home/arnaud/install/lib/libITKVNLInstantiation-4.9.so.1 /home/arnaud/install/lib/libitkvnl_algo-4.9.so.1 /home/arnaud/install/lib/libitkv3p_lsqr-4.9.so.1 /home/arnaud/install/lib/libitkvnl-4.9.so.1 /home/arnaud/install/lib/libitkvcl-4.9.so.1 /home/arnaud/install/lib/libitkv3p_netlib-4.9.so.1 -lm -lpthread -lm /home/arnaud/install/lib/libvtkRenderingOpenGL-6.3.so.1 -lGLU -lSM -lICE -lX11 -lXext -lSM -lICE -lX11 -lXext -lXt /home/arnaud/install/lib/libvtkImagingHybrid-6.3.so.1 /home/arnaud/install/lib/libvtkIOImage-6.3.so.1 /home/arnaud/install/lib/libvtkDICOMParser-6.3.so.1 /home/arnaud/install/lib/libvtkIOCore-6.3.so.1 /home/arnaud/install/lib/libvtkmetaio-6.3.so.1 -lz /home/arnaud/install/lib/libvtkRenderingFreeType-6.3.so.1 /home/arnaud/install/lib/libvtkftgl-6.3.so.1 -lfreetype -lGL /home/arnaud/install/lib/libvtkInteractionStyle-6.3.so.1 /home/arnaud/install/lib/libvtkRenderingCore-6.3.so.1 /home/arnaud/install/lib/libvtkCommonColor-6.3.so.1 /home/arnaud/install/lib/libvtkFiltersGeometry-6.3.so.1 /home/arnaud/install/lib/libvtkFiltersExtraction-6.3.so.1 /home/arnaud/install/lib/libvtkFiltersStatistics-6.3.so.1 /home/arnaud/install/lib/libvtkImagingFourier-6.3.so.1 /home/arnaud/install/lib/libvtkalglib-6.3.so.1 /home/arnaud/install/lib/libvtkFiltersSources-6.3.so.1 /home/arnaud/install/lib/libvtkFiltersGeneral-6.3.so.1 /home/arnaud/install/lib/libvtkFiltersCore-6.3.so.1 /home/arnaud/install/lib/libvtkCommonComputationalGeometry-6.3.so.1 /home/arnaud/install/lib/libvtkImagingSources-6.3.so.1 /home/arnaud/install/lib/libvtkImagingCore-6.3.so.1 /home/arnaud/install/lib/libvtkCommonExecutionModel-6.3.so.1 /home/arnaud/install/lib/libvtkCommonDataModel-6.3.so.1 /home/arnaud/install/lib/libvtkCommonMisc-6.3.so.1 /home/arnaud/install/lib/libvtkCommonSystem-6.3.so.1 /home/arnaud/install/lib/libvtksys-6.3.so.1 -ldl /home/arnaud/install/lib/libvtkCommonTransforms-6.3.so.1 /home/arnaud/install/lib/libvtkCommonMath-6.3.so.1 /home/arnaud/install/lib/libvtkCommonCore-6.3.so.1 -Wl,-rpath,/home/arnaud/install/lib:/usr/lib/x86_64-linux-gnu/hdf5/serial/lib -Wl,-rpath-link,/home/arnaud/install/lib && : /usr/bin/ld: cannot find -lopencv_videostab /usr/bin/ld: cannot find -lopencv_video /usr/bin/ld: cannot find -lopencv_ts /usr/bin/ld: cannot find -lopencv_superres /usr/bin/ld: cannot find -lopencv_stitching /usr/bin/ld: cannot find -lopencv_photo /usr/bin/ld: cannot find -lopencv_ocl /usr/bin/ld: cannot find -lopencv_objdetect /usr/bin/ld: cannot find -lopencv_nonfree /usr/bin/ld: cannot find -lopencv_ml /usr/bin/ld: cannot find -lopencv_legacy /usr/bin/ld: cannot find -lopencv_imgproc /usr/bin/ld: cannot find -lopencv_highgui /usr/bin/ld: cannot find -lopencv_gpu /usr/bin/ld: cannot find -lopencv_flann /usr/bin/ld: cannot find -lopencv_features2d /usr/bin/ld: cannot find -lopencv_core /usr/bin/ld: cannot find -lopencv_contrib /usr/bin/ld: cannot find -lopencv_calib3d collect2: error: ld returned 1 exit status [14/255] Building CXX object src/Core/Common/ObserveAnEvent/CMakeFiles/ObserveAnEvent.dir/Code.cxx.o It actually occurs for all executables... ${ITK_LIBRARIES} does not contain ${OpenCV_LIBS}, leading to this error. Correct? What would be the best/correct way to fix this error? -------------- next part -------------- An HTML attachment was scrubbed... URL: From blowekamp at mail.nih.gov Thu Oct 1 14:06:27 2015 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Thu, 1 Oct 2015 14:06:27 -0400 Subject: [ITK-dev] [ANNOUNCE] SimpleITK 0.9.1 Release Message-ID: <2718BB07-776B-40E5-8123-3DC196DC528C@mail.nih.gov> We are pleased to announce the release of SimpleITK 0.9.1! As with all SimpleITK releases, we have a variety of binaries available. This includes fresh Python Wheels and Eggs, along with Java, and CSharp binaries. Additionally, new binaries for Anaconda have been made improving the dependency requirements. This is a patch release and includes an update to the ITK version from 4.7.2+ to 4.8.1. Additional updates include: improved formatting for python documentation, fixes to the transform interfaces, improved ImageIO exceptions and build improvements. Information on how to get started and download the binaries: http://www.itk.org/Wiki/SimpleITK/GettingStarted#Binaries Binary distributions for many platforms and languages are available for downloading: https://sourceforge.net/projects/simpleitk/files/SimpleITK/0.9.1/ Release Doxygen Documentation: http://www.itk.org/SimpleITKDoxygen09/html/index.html Additional Release Notes: http://www.itk.org/Wiki/SimpleITK/ReleaseNotes#SimpleITK_-_Version_0.9.1_Release Enjoy! Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.mccormick at kitware.com Fri Oct 2 15:10:06 2015 From: matt.mccormick at kitware.com (Matt McCormick) Date: Fri, 2 Oct 2015 15:10:06 -0400 Subject: [ITK-dev] ITKExamples OpenCV related link errors In-Reply-To: References: Message-ID: Hi Arnaud, This means that OpenCV's *Targets.cmake file is not read. This file informs CMake of all the imported library targets' full paths. To ensure this file is read, 'find_package(OpenCV)' should be called. This reads in the OpenCVConfig.cmake file, which should read in the OpenCVTargets.cmake file (I have not checked if these files have these exact names, but that is the idea). To make this happen, Modules/Video/BridgeOpenCV/CMakeLists.txt should set ITKVideoBridgeOpenCV_EXPORT_CODE_BUILD and ITKVideoBridgeOpen_EXPORT_CODE_INSTALL to strings that contain set(OpenCV_DIR \"${OpenCV_DIR}\") find_package(OpenCV REQUIRED) The contents of these variable are added to a module's CMake information file, which is loaded when the module is loaded. The file Modules/ThirdParty/DCMTK/CMakeLists.txt serves as a good example. HTH, Matt On Thu, Oct 1, 2015 at 9:39 AM, Arnaud Gelas wrote: > Hi all, > > I have built ITK with BridgeOpenCV turned ON and when I compile ITKExamples, > I get the following linking errors: > > FAILED: : && /usr/lib/ccache/c++ -msse2 -g > src/CMakeFiles/ImageCompareCommand.dir/ImageCompareCommand.cxx.o -o > bin/ImageCompareCommand -rdynamic > /home/arnaud/install/lib/libITKIOBMP-4.9.so.1 -lexpat -lz > /home/arnaud/install/lib/libITKIOGDCM-4.9.so.1 > /home/arnaud/install/lib/libITKIOGIPL-4.9.so.1 -ljpeg > /home/arnaud/install/lib/libITKIOJPEG-4.9.so.1 > /home/arnaud/install/lib/libITKIOMeta-4.9.so.1 > /home/arnaud/install/lib/libITKIONIFTI-4.9.so.1 > /home/arnaud/install/lib/libITKIONRRD-4.9.so.1 -lpng > /home/arnaud/install/lib/libITKIOPNG-4.9.so.1 -ltiff > /home/arnaud/install/lib/libITKIOVTK-4.9.so.1 > /home/arnaud/install/lib/libITKLabelMap-4.9.so.1 > /home/arnaud/install/lib/libITKQuadEdgeMesh-4.9.so.1 > /home/arnaud/install/lib/libITKPolynomials-4.9.so.1 > /home/arnaud/install/lib/libITKBiasCorrection-4.9.so.1 > /home/arnaud/install/lib/libITKBioCell-4.9.so.1 > /home/arnaud/install/lib/libITKDICOMParser-4.9.so.1 > /home/arnaud/install/lib/libITKIOSpatialObjects-4.9.so.1 > /home/arnaud/install/lib/libITKFEM-4.9.so.1 > /home/arnaud/install/lib/libITKIOMesh-4.9.so.1 > /usr/lib/x86_64-linux-gnu/hdf5/serial/lib/libhdf5_cpp.so > /usr/lib/x86_64-linux-gnu/hdf5/serial/lib/libhdf5.so -lpthread -ldl -lm > /home/arnaud/install/lib/libITKIOBioRad-4.9.so.1 > /home/arnaud/install/lib/libITKIOCSV-4.9.so.1 > /home/arnaud/install/lib/libITKIOGE-4.9.so.1 > /home/arnaud/install/lib/libITKIOSiemens-4.9.so.1 > /home/arnaud/install/lib/libITKIOHDF5-4.9.so.1 > /home/arnaud/install/lib/libITKIOLSM-4.9.so.1 > /home/arnaud/install/lib/libITKIOMRC-4.9.so.1 > /home/arnaud/install/lib/libITKIOStimulate-4.9.so.1 > /home/arnaud/install/lib/libITKIOTransformHDF5-4.9.so.1 > /home/arnaud/install/lib/libITKIOTransformInsightLegacy-4.9.so.1 > /home/arnaud/install/lib/libITKIOTransformMatlab-4.9.so.1 > /home/arnaud/install/lib/libITKKLMRegionGrowing-4.9.so.1 > /home/arnaud/install/lib/libITKWatersheds-4.9.so.1 > /home/arnaud/install/lib/libITKOptimizersv4-4.9.so.1 > /home/arnaud/install/lib/libITKVideoBridgeOpenCV-4.9.so.1 > /home/arnaud/install/lib/libITKVtkGlue-4.9.so.1 > /home/arnaud/install/lib/libitkgdcmMSFF-4.9.so.1 > /home/arnaud/install/lib/libitkgdcmDICT-4.9.so.1 > /home/arnaud/install/lib/libitkgdcmIOD-4.9.so.1 > /home/arnaud/install/lib/libitkgdcmDSED-4.9.so.1 > /home/arnaud/install/lib/libitkgdcmCommon-4.9.so.1 > /home/arnaud/install/lib/libITKNrrdIO-4.9.so.1 > /home/arnaud/install/lib/libITKIOXML-4.9.so.1 > /home/arnaud/install/lib/libITKMetaIO-4.9.so.1 > /home/arnaud/install/lib/libITKgiftiio-4.9.so.1 -lexpat > /home/arnaud/install/lib/libITKniftiio-4.9.so.1 > /home/arnaud/install/lib/libITKznz-4.9.so.1 > /home/arnaud/install/lib/libITKIOIPL-4.9.so.1 > /home/arnaud/install/lib/libITKIOTIFF-4.9.so.1 > /home/arnaud/install/lib/libITKIOTransformBase-4.9.so.1 > /home/arnaud/install/lib/libITKSpatialObjects-4.9.so.1 > /home/arnaud/install/lib/libITKMesh-4.9.so.1 > /home/arnaud/install/lib/libITKPath-4.9.so.1 > /home/arnaud/install/lib/libITKOptimizers-4.9.so.1 > /home/arnaud/install/lib/libITKStatistics-4.9.so.1 > /home/arnaud/install/lib/libitkNetlibSlatec-4.9.so.1 > /home/arnaud/install/lib/libITKVideoIO-4.9.so.1 > /home/arnaud/install/lib/libITKIOImageBase-4.9.so.1 > /home/arnaud/install/lib/libITKVideoCore-4.9.so.1 -lopencv_videostab > -lopencv_video -lopencv_ts -lopencv_superres -lopencv_stitching > -lopencv_photo -lopencv_ocl -lopencv_objdetect -lopencv_nonfree -lopencv_ml > -lopencv_legacy -lopencv_imgproc -lopencv_highgui -lopencv_gpu > -lopencv_flann -lopencv_features2d -lopencv_core -lopencv_contrib > -lopencv_calib3d -ljpeg -lpng -ltiff > /home/arnaud/install/lib/libITKVTK-4.9.so.1 > /home/arnaud/install/lib/libITKCommon-4.9.so.1 > /home/arnaud/install/lib/libitkdouble-conversion-4.9.so.1 > /home/arnaud/install/lib/libitksys-4.9.so.1 > /home/arnaud/install/lib/libITKVNLInstantiation-4.9.so.1 > /home/arnaud/install/lib/libitkvnl_algo-4.9.so.1 > /home/arnaud/install/lib/libitkv3p_lsqr-4.9.so.1 > /home/arnaud/install/lib/libitkvnl-4.9.so.1 > /home/arnaud/install/lib/libitkvcl-4.9.so.1 > /home/arnaud/install/lib/libitkv3p_netlib-4.9.so.1 -lm -lpthread -lm > /home/arnaud/install/lib/libvtkRenderingOpenGL-6.3.so.1 -lGLU -lSM -lICE > -lX11 -lXext -lSM -lICE -lX11 -lXext -lXt > /home/arnaud/install/lib/libvtkImagingHybrid-6.3.so.1 > /home/arnaud/install/lib/libvtkIOImage-6.3.so.1 > /home/arnaud/install/lib/libvtkDICOMParser-6.3.so.1 > /home/arnaud/install/lib/libvtkIOCore-6.3.so.1 > /home/arnaud/install/lib/libvtkmetaio-6.3.so.1 -lz > /home/arnaud/install/lib/libvtkRenderingFreeType-6.3.so.1 > /home/arnaud/install/lib/libvtkftgl-6.3.so.1 -lfreetype -lGL > /home/arnaud/install/lib/libvtkInteractionStyle-6.3.so.1 > /home/arnaud/install/lib/libvtkRenderingCore-6.3.so.1 > /home/arnaud/install/lib/libvtkCommonColor-6.3.so.1 > /home/arnaud/install/lib/libvtkFiltersGeometry-6.3.so.1 > /home/arnaud/install/lib/libvtkFiltersExtraction-6.3.so.1 > /home/arnaud/install/lib/libvtkFiltersStatistics-6.3.so.1 > /home/arnaud/install/lib/libvtkImagingFourier-6.3.so.1 > /home/arnaud/install/lib/libvtkalglib-6.3.so.1 > /home/arnaud/install/lib/libvtkFiltersSources-6.3.so.1 > /home/arnaud/install/lib/libvtkFiltersGeneral-6.3.so.1 > /home/arnaud/install/lib/libvtkFiltersCore-6.3.so.1 > /home/arnaud/install/lib/libvtkCommonComputationalGeometry-6.3.so.1 > /home/arnaud/install/lib/libvtkImagingSources-6.3.so.1 > /home/arnaud/install/lib/libvtkImagingCore-6.3.so.1 > /home/arnaud/install/lib/libvtkCommonExecutionModel-6.3.so.1 > /home/arnaud/install/lib/libvtkCommonDataModel-6.3.so.1 > /home/arnaud/install/lib/libvtkCommonMisc-6.3.so.1 > /home/arnaud/install/lib/libvtkCommonSystem-6.3.so.1 > /home/arnaud/install/lib/libvtksys-6.3.so.1 -ldl > /home/arnaud/install/lib/libvtkCommonTransforms-6.3.so.1 > /home/arnaud/install/lib/libvtkCommonMath-6.3.so.1 > /home/arnaud/install/lib/libvtkCommonCore-6.3.so.1 > -Wl,-rpath,/home/arnaud/install/lib:/usr/lib/x86_64-linux-gnu/hdf5/serial/lib > -Wl,-rpath-link,/home/arnaud/install/lib && : > /usr/bin/ld: cannot find -lopencv_videostab > /usr/bin/ld: cannot find -lopencv_video > /usr/bin/ld: cannot find -lopencv_ts > /usr/bin/ld: cannot find -lopencv_superres > /usr/bin/ld: cannot find -lopencv_stitching > /usr/bin/ld: cannot find -lopencv_photo > /usr/bin/ld: cannot find -lopencv_ocl > /usr/bin/ld: cannot find -lopencv_objdetect > /usr/bin/ld: cannot find -lopencv_nonfree > /usr/bin/ld: cannot find -lopencv_ml > /usr/bin/ld: cannot find -lopencv_legacy > /usr/bin/ld: cannot find -lopencv_imgproc > /usr/bin/ld: cannot find -lopencv_highgui > /usr/bin/ld: cannot find -lopencv_gpu > /usr/bin/ld: cannot find -lopencv_flann > /usr/bin/ld: cannot find -lopencv_features2d > /usr/bin/ld: cannot find -lopencv_core > /usr/bin/ld: cannot find -lopencv_contrib > /usr/bin/ld: cannot find -lopencv_calib3d > collect2: error: ld returned 1 exit status > [14/255] Building CXX object > src/Core/Common/ObserveAnEvent/CMakeFiles/ObserveAnEvent.dir/Code.cxx.o > > > It actually occurs for all executables... > > ${ITK_LIBRARIES} does not contain ${OpenCV_LIBS}, leading to this error. > Correct? > > What would be the best/correct way to fix this error? > > From luc.hermitte at c-s.fr Mon Oct 5 10:26:38 2015 From: luc.hermitte at c-s.fr (Luc Hermitte) Date: Mon, 5 Oct 2015 16:26:38 +0200 Subject: [ITK-dev] itkStaticConstMacro definition Message-ID: <5612889E.5000506@c-s.fr> Hi list, I'm currently trying to push code that exploits SFINAE and itk::EnableIf. I have a problem with clang, in C++98 mode, as it barks when we are using an unnamed type as a template parameter -> "note: unnamed type used in template argument was declared here" There is an easy fix for it: drop the compatibility to old compilers like VC++6 when writing metaprograms. In this case, itkStaticConstMAcro shall not generate an enum, enum { variable = value }; // (1) but const static type variable = value; // (2) I've searched google and gerrit to see why definition (2) has been commented out, but I've found nothing. If I understand correctly, in the past, a CMake test was used to choose how the macro shall be written. This is not the case any more. So my questions: Does anybody remember/know why definition (2) has been dropped? Can't we revert to it (or at least to a conditional definition of itkStaticConstMacro) for compilers clang that are pedantically compliant to C++98 standard? (constexpr will of course be required with C++11 compliant compilers used in C++11 (or more) mode) BTW, which is the oldest VC++ compiler officially supported by ITK? Must I understand from this that VC++7.1 support has already been dropped since 2012? (http://www.itk.org/Wiki/ITK_Release_4/Modern_C%2B%2B#Fully_Committed_to_Support) Regards, -- Luc Hermitte CS SI From matt.mccormick at kitware.com Mon Oct 5 12:18:50 2015 From: matt.mccormick at kitware.com (Matt McCormick) Date: Mon, 5 Oct 2015 12:18:50 -0400 Subject: [ITK-dev] itkStaticConstMacro definition In-Reply-To: <5612889E.5000506@c-s.fr> References: <5612889E.5000506@c-s.fr> Message-ID: Hi Luc, > I'm currently trying to push code that exploits SFINAE and itk::EnableIf. Cool :-) > I have a problem with clang, in C++98 mode, as it barks when we are > using an unnamed type as a template parameter > -> "note: unnamed type used in template argument was declared here" > > There is an easy fix for it: drop the compatibility to old compilers > like VC++6 when writing metaprograms. In this case, itkStaticConstMAcro > shall not generate an enum, > enum { variable = value }; // (1) > but > const static type variable = value; // (2) > > I've searched google and gerrit to see why definition (2) has been > commented out, but I've found nothing. If I understand correctly, in the > past, a CMake test was used to choose how the macro shall be written. > This is not the case any more. Yes, that is also my recollection. But, nobody has just bothered to update the definition. > So my questions: > Does anybody remember/know why definition (2) has been dropped? Can't we > revert to it (or at least to a conditional definition of > itkStaticConstMacro) for compilers clang that are pedantically compliant > to C++98 standard? > (constexpr will of course be required with C++11 compliant compilers > used in C++11 (or more) mode) Yes :-) > BTW, which is the oldest VC++ compiler officially supported by ITK? Must > I understand from this that VC++7.1 support has already been dropped > since 2012? > (http://www.itk.org/Wiki/ITK_Release_4/Modern_C%2B%2B#Fully_Committed_to_Support) Correct. The current oldest version of VC++ is 9. Thanks, Matt From blowekamp at mail.nih.gov Wed Oct 7 11:39:13 2015 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Wed, 7 Oct 2015 11:39:13 -0400 Subject: [ITK-dev] Regression from change with WindowConvergenceMonitoringFunction? Message-ID: Hello, I am upgrading SimpleITK's superbuild to the latest ITK. I have encountered an odd regression.. Here is the failing test output [1] and here is the source [2], where the check at line 679 fails, because the optimization didn't move. What is very odd is that after running a git bisect I found that this patch [3] was the root of the change in behavior: commit 51c2ff58e04a25166b6aafc7d7590c2ae74f2ec6 Author: Nick Tustison Date: Tue Jun 30 21:29:07 2015 -0700 BUG: Set a default b-spline epsilon. The B-spline domain is defined on the closed-half interval [a,b) which presents difficulty when we define the image domain to be co-extensive with the B-spline domain. Earlier attempts at calculating the B-spline domain didn't work as this error kept popping up. Therefore we're defining a default B-spline epsilon which the user can change depending on usage. Change-Id: I64605557fc7131e148c725e0d1cce2e5aa84f31f After grepping around I found that the BSplineScatteredDataPointSetToImageFilter is used by the WindowConvergenceMonitoringFunction. Which could cause this early convergence I was seeing. Perhaps this changed epsilon default value does not not make sense for the ConvergenceMonitoringFunctions? Thanks for the additional eyes and opinions on this! Brad [1] https://open.cdash.org/testDetails.php?test=380566217&build=4051508 [2] https://github.com/SimpleITK/SimpleITK/blob/master/Testing/Unit/sitkImageRegistrationMethodTests.cxx#L627-L683 [3] https://github.com/InsightSoftwareConsortium/ITK/commit/51c2ff58e04a25166b6aafc7d7590c2ae74f2ec6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntustison at gmail.com Wed Oct 7 12:01:43 2015 From: ntustison at gmail.com (Nicholas Tustison) Date: Wed, 7 Oct 2015 18:01:43 +0200 Subject: [ITK-dev] Regression from change with WindowConvergenceMonitoringFunction? In-Reply-To: References: Message-ID: Oh, sorry about this Brad. I?m currently on my way out and am still at MICCAI but I will look at this tomorrow and see what I can figure out. Thanks for finding this. Nick > On Oct 7, 2015, at 5:39 PM, Bradley Lowekamp wrote: > > Hello, > > I am upgrading SimpleITK's superbuild to the latest ITK. I have encountered an odd regression.. > > Here is the failing test output [1] and here is the source [2], where the check at line 679 fails, because the optimization didn't move. > > What is very odd is that after running a git bisect I found that this patch [3] was the root of the change in behavior: > > commit 51c2ff58e04a25166b6aafc7d7590c2ae74f2ec6 > Author: Nick Tustison > > Date: Tue Jun 30 21:29:07 2015 -0700 > > BUG: Set a default b-spline epsilon. > > The B-spline domain is defined on the closed-half interval > [a,b) which presents difficulty when we define the image > domain to be co-extensive with the B-spline domain. Earlier > attempts at calculating the B-spline domain didn't work as > this error kept popping up. Therefore we're defining a > default B-spline epsilon which the user can change depending > on usage. > > Change-Id: I64605557fc7131e148c725e0d1cce2e5aa84f31f > > After grepping around I found that the BSplineScatteredDataPointSetToImageFilter is used by the WindowConvergenceMonitoringFunction. Which could cause this early convergence I was seeing. > > Perhaps this changed epsilon default value does not not make sense for the ConvergenceMonitoringFunctions? > > Thanks for the additional eyes and opinions on this! > > Brad > > [1] https://open.cdash.org/testDetails.php?test=380566217&build=4051508 > [2] https://github.com/SimpleITK/SimpleITK/blob/master/Testing/Unit/sitkImageRegistrationMethodTests.cxx#L627-L683 > [3] https://github.com/InsightSoftwareConsortium/ITK/commit/51c2ff58e04a25166b6aafc7d7590c2ae74f2ec6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hobbsk at ohio.edu Mon Oct 12 13:03:20 2015 From: hobbsk at ohio.edu (Kevin H. Hobbs) Date: Mon, 12 Oct 2015 13:03:20 -0400 Subject: [ITK-dev] git cmake fails in NIfTI Message-ID: <561BE7D8.3020205@ohio.edu> Please pardon the cross posting, I got no response on the CMake Dev list. This is what I posted to the CMake Devs, maybe this is an ITK or NIfTI problem, but CMake began development on a new version that day : The ITK dashboard builds on bubbles, murron, and k450e all started failing at the configure step on October 6. These builds all use the development version of CMake. There were no remarkable changes in ITK that night, however there were some interesting updates to CMake. The errors are in the third party library NIfTI and look like this : CMake Error at Modules/ThirdParty/NIFTI/src/nifti/znzlib/CMakeLists.txt:18 (install): install TARGETS given no LIBRARY DESTINATION for shared library target "znz". CMake Error at Modules/ThirdParty/NIFTI/src/nifti/znzlib/CMakeLists.txt:28 (install): install FILES given no DESTINATION! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 173 bytes Desc: OpenPGP digital signature URL: From brad.king at kitware.com Mon Oct 12 13:42:24 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 12 Oct 2015 13:42:24 -0400 Subject: [ITK-dev] git cmake fails in NIfTI In-Reply-To: <561BE7D8.3020205@ohio.edu> References: <561BE7D8.3020205@ohio.edu> Message-ID: <561BF100.5080901@kitware.com> On 10/12/2015 01:03 PM, Kevin H. Hobbs wrote: > Please pardon the cross posting, I got no response on the CMake Dev list. It's only been 1 work day since that was posted. It took some time to track down the problem. See response on cmake dev list: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14683/focus=14702 -Brad From hobbsk at ohio.edu Mon Oct 12 15:57:20 2015 From: hobbsk at ohio.edu (Kevin H. Hobbs) Date: Mon, 12 Oct 2015 15:57:20 -0400 Subject: [ITK-dev] git cmake fails in NIfTI In-Reply-To: <561BF100.5080901@kitware.com> References: <561BE7D8.3020205@ohio.edu> <561BF100.5080901@kitware.com> Message-ID: <561C10A0.4030802@ohio.edu> On 10/12/2015 01:42 PM, Brad King wrote: > On 10/12/2015 01:03 PM, Kevin H. Hobbs wrote: >> Please pardon the cross posting, I got no response on the CMake Dev list. > > It's only been 1 work day since that was posted. It took some time to > track down the problem. See response on cmake dev list: > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14683/focus=14702 Again, I'm sorry. I got impatient. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 173 bytes Desc: OpenPGP digital signature URL: From matt.mccormick at kitware.com Thu Oct 15 12:49:50 2015 From: matt.mccormick at kitware.com (Matt McCormick) Date: Thu, 15 Oct 2015 12:49:50 -0400 Subject: [ITK-dev] CDash is currently Message-ID: Hello, CDash is currently down due to an issue with the database. Work is on-going to address the issue. Matt From david.mo.burns at gmail.com Thu Oct 15 14:48:20 2015 From: david.mo.burns at gmail.com (David Burns) Date: Thu, 15 Oct 2015 14:48:20 -0400 Subject: [ITK-dev] New Image Filter for Submission Message-ID: <561FF4F4.9060809@gmail.com> Dear Insight Developers, I have developed an image filter that may be useful to the community. Please let me know if you think this is the case, and I will submit it to the Journal. The filter produces a subsampled version of the input image, where the output image has the same output dimensions (Size[i]*Spacing[i]) but with the number of pixels (Size[i]) scaled down by a factor (factor[i]) across the dimensions. The pixels of the output image are an average over the input pixels they overlap. The filter verifies/ensures that factor[i] is an exact factor of the input image Size[i], so that the image properties remain unchanged by the filter. I found this to be useful for my registration task to produce a lower resolution image very quickly, without needing to use itk:: ResampleImageFilter, interpolation or smoothing. I've attached a screenshot of an xray, subsampled / averaged by a factor of 4 in x and y. Let me know your thoughts? Thanks David Burns -------------- next part -------------- A non-text attachment was scrubbed... Name: AvgSubsampleFilter.png Type: image/png Size: 147057 bytes Desc: not available URL: From matt.mccormick at kitware.com Thu Oct 15 15:17:27 2015 From: matt.mccormick at kitware.com (Matt McCormick) Date: Thu, 15 Oct 2015 15:17:27 -0400 Subject: [ITK-dev] New Image Filter for Submission In-Reply-To: <561FF4F4.9060809@gmail.com> References: <561FF4F4.9060809@gmail.com> Message-ID: Hi David, Thanks for contributing to ITK. It sounds like this filter does the same as the BinShrinkImageFilter?: http://www.insight-journal.org/browse/publication/912 Matt On Thu, Oct 15, 2015 at 2:48 PM, David Burns wrote: > Dear Insight Developers, > > I have developed an image filter that may be useful to the community. Please > let me know if you think this is the case, and I will submit it to the > Journal. > > The filter produces a subsampled version of the input image, where the > output image has the same output dimensions (Size[i]*Spacing[i]) but with > the number of pixels (Size[i]) scaled down by a factor (factor[i]) across > the dimensions. The pixels of the output image are an average over the input > pixels they overlap. The filter verifies/ensures that factor[i] is an exact > factor of the input image Size[i], so that the image properties remain > unchanged by the filter. > > I found this to be useful for my registration task to produce a lower > resolution image very quickly, without needing to use itk:: > ResampleImageFilter, interpolation or smoothing. > > I've attached a screenshot of an xray, subsampled / averaged by a factor of > 4 in x and y. Let me know your thoughts? > > Thanks > David Burns > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Kitware offers ITK Training Courses, for more information visit: > http://kitware.com/products/protraining.php > > Please keep messages on-topic and check the ITK FAQ at: > http://www.itk.org/Wiki/ITK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/insight-developers > From david.mo.burns at gmail.com Thu Oct 15 15:35:00 2015 From: david.mo.burns at gmail.com (David Burns) Date: Thu, 15 Oct 2015 15:35:00 -0400 Subject: [ITK-dev] New Image Filter for Submission In-Reply-To: References: <561FF4F4.9060809@gmail.com> Message-ID: <561FFFE4.2090501@gmail.com> Thanks Matt - You are correct. Very similar. I will not post mine in that case. Best David On 10/15/2015 03:17 PM, Matt McCormick wrote: > Hi David, > > Thanks for contributing to ITK. > > It sounds like this filter does the same as the BinShrinkImageFilter?: > > http://www.insight-journal.org/browse/publication/912 > > Matt > > On Thu, Oct 15, 2015 at 2:48 PM, David Burns wrote: >> Dear Insight Developers, >> >> I have developed an image filter that may be useful to the community. Please >> let me know if you think this is the case, and I will submit it to the >> Journal. >> >> The filter produces a subsampled version of the input image, where the >> output image has the same output dimensions (Size[i]*Spacing[i]) but with >> the number of pixels (Size[i]) scaled down by a factor (factor[i]) across >> the dimensions. The pixels of the output image are an average over the input >> pixels they overlap. The filter verifies/ensures that factor[i] is an exact >> factor of the input image Size[i], so that the image properties remain >> unchanged by the filter. >> >> I found this to be useful for my registration task to produce a lower >> resolution image very quickly, without needing to use itk:: >> ResampleImageFilter, interpolation or smoothing. >> >> I've attached a screenshot of an xray, subsampled / averaged by a factor of >> 4 in x and y. Let me know your thoughts? >> >> Thanks >> David Burns >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Kitware offers ITK Training Courses, for more information visit: >> http://kitware.com/products/protraining.php >> >> Please keep messages on-topic and check the ITK FAQ at: >> http://www.itk.org/Wiki/ITK_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/insight-developers >> From blowekamp at mail.nih.gov Fri Oct 16 10:34:19 2015 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Fri, 16 Oct 2015 10:34:19 -0400 Subject: [ITK-dev] New Image Filter for Submission In-Reply-To: <561FFFE4.2090501@gmail.com> References: <561FF4F4.9060809@gmail.com> <561FFFE4.2090501@gmail.com> Message-ID: <33299BF6-4399-42F7-9A7A-60E9400C665B@mail.nih.gov> David, This filter was integrated in to ITK [1]. It handles the case where the image size is not a factor of the shrinkFactor, by truncating, and changing the image's physical extent. The doxygen page illustrates how this occurs. Are you using the ITKv4 registration framework? I am curious how you are integrating this multi-scale feature into the framework. [1] http://www.itk.org/Doxygen/html/classitk_1_1BinShrinkImageFilter.html On Oct 15, 2015, at 3:35 PM, David Burns wrote: > Thanks Matt - > > You are correct. Very similar. I will not post mine in that case. > > Best > David > > On 10/15/2015 03:17 PM, Matt McCormick wrote: >> Hi David, >> >> Thanks for contributing to ITK. >> >> It sounds like this filter does the same as the BinShrinkImageFilter?: >> >> http://www.insight-journal.org/browse/publication/912 >> >> Matt >> >> On Thu, Oct 15, 2015 at 2:48 PM, David Burns wrote: >>> Dear Insight Developers, >>> >>> I have developed an image filter that may be useful to the community. Please >>> let me know if you think this is the case, and I will submit it to the >>> Journal. >>> >>> The filter produces a subsampled version of the input image, where the >>> output image has the same output dimensions (Size[i]*Spacing[i]) but with >>> the number of pixels (Size[i]) scaled down by a factor (factor[i]) across >>> the dimensions. The pixels of the output image are an average over the input >>> pixels they overlap. The filter verifies/ensures that factor[i] is an exact >>> factor of the input image Size[i], so that the image properties remain >>> unchanged by the filter. >>> >>> I found this to be useful for my registration task to produce a lower >>> resolution image very quickly, without needing to use itk:: >>> ResampleImageFilter, interpolation or smoothing. >>> >>> I've attached a screenshot of an xray, subsampled / averaged by a factor of >>> 4 in x and y. Let me know your thoughts? >>> >>> Thanks >>> David Burns >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Kitware offers ITK Training Courses, for more information visit: >>> http://kitware.com/products/protraining.php >>> >>> Please keep messages on-topic and check the ITK FAQ at: >>> http://www.itk.org/Wiki/ITK_FAQ >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/insight-developers >>> > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Kitware offers ITK Training Courses, for more information visit: > http://kitware.com/products/protraining.php > > Please keep messages on-topic and check the ITK FAQ at: > http://www.itk.org/Wiki/ITK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/insight-developers From matt.mccormick at kitware.com Fri Oct 16 12:06:22 2015 From: matt.mccormick at kitware.com (Matt McCormick) Date: Fri, 16 Oct 2015 12:06:22 -0400 Subject: [ITK-dev] CDash is currently down Message-ID: Followup: CDash is back up, but we lost some recent records. If you find a Gerrit build of interest is gone, they can be re-run by adding request build: all in a review comment. Matt On Thu, Oct 15, 2015 at 12:49 PM, Matt McCormick wrote: > Hello, > > CDash is currently down due to an issue with the database. Work is > on-going to address the issue. > > Matt From david.mo.burns at gmail.com Fri Oct 16 12:59:13 2015 From: david.mo.burns at gmail.com (David Burns) Date: Fri, 16 Oct 2015 12:59:13 -0400 Subject: [ITK-dev] New Image Filter for Submission In-Reply-To: <33299BF6-4399-42F7-9A7A-60E9400C665B@mail.nih.gov> References: <561FF4F4.9060809@gmail.com> <561FFFE4.2090501@gmail.com> <33299BF6-4399-42F7-9A7A-60E9400C665B@mail.nih.gov> Message-ID: <56212CE1.8060807@gmail.com> Thanks for you interest in my work Bradley, So far, I have not used the ITKv4 registration framework (or previous versions) for my project. If I were to use the filter I coded within the framework, my approach would be to use it to pre-process the fixed and/or moving images. I am at this point trying to decide whether or not to use the framework - my registration task involves 2 moving image volumes, DRR generation, and 1 fixed 2D image. I've seen that the framework can be modified to use multiple fixed images [1], but have not seen anything yet that would meet my needs. If you have any suggestions, they would be welcome. If I do end up modifying the framework to meet my needs, I will share my work with the community. [1] https://ibia.umit.at/ResearchGroup/Phil/web/Simple2D3DRegistrationFramework.html Best regards, David On 10/16/2015 10:34 AM, Bradley Lowekamp wrote: > David, > > This filter was integrated in to ITK [1]. > > It handles the case where the image size is not a factor of the shrinkFactor, by truncating, and changing the image's physical extent. The doxygen page illustrates how this occurs. > > Are you using the ITKv4 registration framework? I am curious how you are integrating this multi-scale feature into the framework. > > [1] http://www.itk.org/Doxygen/html/classitk_1_1BinShrinkImageFilter.html > > On Oct 15, 2015, at 3:35 PM, David Burns wrote: > >> Thanks Matt - >> >> You are correct. Very similar. I will not post mine in that case. >> >> Best >> David >> >> On 10/15/2015 03:17 PM, Matt McCormick wrote: >>> Hi David, >>> >>> Thanks for contributing to ITK. >>> >>> It sounds like this filter does the same as the BinShrinkImageFilter?: >>> >>> http://www.insight-journal.org/browse/publication/912 >>> >>> Matt >>> >>> On Thu, Oct 15, 2015 at 2:48 PM, David Burns wrote: >>>> Dear Insight Developers, >>>> >>>> I have developed an image filter that may be useful to the community. Please >>>> let me know if you think this is the case, and I will submit it to the >>>> Journal. >>>> >>>> The filter produces a subsampled version of the input image, where the >>>> output image has the same output dimensions (Size[i]*Spacing[i]) but with >>>> the number of pixels (Size[i]) scaled down by a factor (factor[i]) across >>>> the dimensions. The pixels of the output image are an average over the input >>>> pixels they overlap. The filter verifies/ensures that factor[i] is an exact >>>> factor of the input image Size[i], so that the image properties remain >>>> unchanged by the filter. >>>> >>>> I found this to be useful for my registration task to produce a lower >>>> resolution image very quickly, without needing to use itk:: >>>> ResampleImageFilter, interpolation or smoothing. >>>> >>>> I've attached a screenshot of an xray, subsampled / averaged by a factor of >>>> 4 in x and y. Let me know your thoughts? >>>> >>>> Thanks >>>> David Burns >>>> >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Kitware offers ITK Training Courses, for more information visit: >>>> http://kitware.com/products/protraining.php >>>> >>>> Please keep messages on-topic and check the ITK FAQ at: >>>> http://www.itk.org/Wiki/ITK_FAQ >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/insight-developers >>>> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Kitware offers ITK Training Courses, for more information visit: >> http://kitware.com/products/protraining.php >> >> Please keep messages on-topic and check the ITK FAQ at: >> http://www.itk.org/Wiki/ITK_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/insight-developers From bill.lorensen at gmail.com Tue Oct 20 10:54:40 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 20 Oct 2015 10:54:40 -0400 Subject: [ITK-dev] Cuberille Remote Module Message-ID: Folks, The new Cuberille Remote Module code has embedded ctrl-M's. Bill -- Unpaid intern in BillsBasement at noware dot com From matt.mccormick at kitware.com Tue Oct 20 11:01:09 2015 From: matt.mccormick at kitware.com (Matt McCormick) Date: Tue, 20 Oct 2015 11:01:09 -0400 Subject: [ITK-dev] Cuberille Remote Module In-Reply-To: References: Message-ID: Hi Bill, Thanks for the note. I will removed them: https://github.com/InsightSoftwareConsortium/ITKCuberille/pull/12 Matt On Tue, Oct 20, 2015 at 10:54 AM, Bill Lorensen wrote: > Folks, > > The new Cuberille Remote Module code has embedded ctrl-M's. > > Bill > > > -- > Unpaid intern in BillsBasement at noware dot com > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Kitware offers ITK Training Courses, for more information visit: > http://kitware.com/products/protraining.php > > Please keep messages on-topic and check the ITK FAQ at: > http://www.itk.org/Wiki/ITK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/insight-developers From bill.lorensen at gmail.com Tue Oct 20 11:28:43 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 20 Oct 2015 11:28:43 -0400 Subject: [ITK-dev] Cuberille Remote Module In-Reply-To: References: Message-ID: Thanks, I tested the patch. Looks great. On Tue, Oct 20, 2015 at 11:01 AM, Matt McCormick wrote: > Hi Bill, > > Thanks for the note. I will removed them: > > https://github.com/InsightSoftwareConsortium/ITKCuberille/pull/12 > > Matt > > On Tue, Oct 20, 2015 at 10:54 AM, Bill Lorensen wrote: >> Folks, >> >> The new Cuberille Remote Module code has embedded ctrl-M's. >> >> Bill >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Kitware offers ITK Training Courses, for more information visit: >> http://kitware.com/products/protraining.php >> >> Please keep messages on-topic and check the ITK FAQ at: >> http://www.itk.org/Wiki/ITK_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/insight-developers -- Unpaid intern in BillsBasement at noware dot com From lydiang at gmail.com Wed Oct 21 11:40:59 2015 From: lydiang at gmail.com (Lydia Ng) Date: Wed, 21 Oct 2015 08:40:59 -0700 Subject: [ITK-dev] Image Stitching/Registration position at the Allen Institute Message-ID: Interesting in working at the Allen Institute for Brain Science? We are building out a high throughput electron microscopy (EM) processing and we are looking for an expert algorithm developer/engineer to implement the stitching and alignment components. Apply for the Software Engineer III - Image Stitching/Registration position http://www.alleninstitute.org/careers/career-opportunities/ Start here to learn more about us and what we do http://www.alleninstitute.org/our-research/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Fri Oct 23 12:43:32 2015 From: DLRdave at aol.com (David Cole) Date: Fri, 23 Oct 2015 12:43:32 -0400 Subject: [ITK-dev] Bug in the library, or just in the test..? Message-ID: The itkTransformTest is the only test failing on my Visual Studio 2013 Debug dashboard because of this code: virtual OutputVectorPixelType TransformVector(const InputVectorPixelType & itkNotUsed(inputVector) ) const ITK_OVERRIDE { OutputVectorPixelType outVector; outVector.Fill( 88.8 ); return outVector; } The problem is in the Fill implementation: template< typename TValue > void VariableLengthVector< TValue > ::Fill(TValue const & v) ITK_NOEXCEPT { std::fill_n(&this->m_Data[0], m_NumElements, v); } In this test call, m_Data is nullptr, and m_NumElements is 0, so clearly,&m_Data[0] is not a useful pointer, and with 0 elements, there is nothing to fill. So.... should the implementation of Fill be changed to be conditional on the pointer being non-nullptr, or the number of elements being non-zero, or both? (Are other Fill implementations protected like so?) Or should the test be changed to avoid calling Fill when there are no elements...? Thanks, David C. From luc.hermitte at c-s.fr Fri Oct 23 13:33:45 2015 From: luc.hermitte at c-s.fr (Luc Hermitte) Date: Fri, 23 Oct 2015 19:33:45 +0200 Subject: [ITK-dev] Bug in the library, or just in the test..? In-Reply-To: References: Message-ID: <562A6F79.2060105@c-s.fr> Hi, Le 23/10/2015 18:43, David Cole via Insight-developers a ?crit : > The itkTransformTest is the only test failing on my Visual Studio 2013 > Debug dashboard because of this code: What is the exact error produced when your run the test in verbose mode? > The problem is in the Fill implementation: > > template< typename TValue > > void VariableLengthVector< TValue > > ::Fill(TValue const & v) ITK_NOEXCEPT > { > std::fill_n(&this->m_Data[0], m_NumElements, v); > } > > In this test call, m_Data is nullptr, and m_NumElements is 0, so > clearly,&m_Data[0] is not a useful pointer, and with 0 elements, there > is nothing to fill. > > So.... should the implementation of Fill be changed to be conditional > on the pointer being non-nullptr, or the number of elements being > non-zero, or both? (Are other Fill implementations protected like so?) > > Or should the test be changed to avoid calling Fill when there are no > elements...? I'd say that this is a bug in std::fill_n (or something related to the STL being in CHECKED MODE) and that we should fall back into a plain loop. We should avoid adding such defensive tests (if (!empty) fill_n()). I can take care of this issue (only on Monday). If you don't mind, I'd rather avoid rebasing yet another time and first go through http://review.source.kitware.com/#/c/20253/10 (I could also fix the issue I've introduced in my first patch on VLV in this patch, but this is not the usual patching policy if I understand correctly) Regards, -- Luc Hermitte From DLRdave at aol.com Fri Oct 23 13:47:10 2015 From: DLRdave at aol.com (David Cole) Date: Fri, 23 Oct 2015 13:47:10 -0400 Subject: [ITK-dev] Bug in the library, or just in the test..? In-Reply-To: <562A6F79.2060105@c-s.fr> References: <562A6F79.2060105@c-s.fr> Message-ID: It is definitely related to STL being checked in a Debug Visual Studio build... I get a bunch of ASSERT dialogs that pop up, so the test times out and hangs there with the dialog up until I kill it manually. If I ignore through all the dialogs that pop up (click ignore on each of them, there are exactly 12 in total), then the test output is normal, and it reports that it has PASSED. I can wait for a fix. I was just asking to see if it was a known thing, and find out if anybody was working on it, or if there was a general recommendation about what the right fix for it is before I attempt to fix it myself. I'm curious, though, why is using "&this->m_Data[0]" acceptable if m_Data is nullptr ...? Why doesn't valgrind pick this up as a problem? D On Fri, Oct 23, 2015 at 1:33 PM, Luc Hermitte wrote: > Hi, > > Le 23/10/2015 18:43, David Cole via Insight-developers a ?crit : >> The itkTransformTest is the only test failing on my Visual Studio 2013 >> Debug dashboard because of this code: > > What is the exact error produced when your run the test in verbose mode? > > >> The problem is in the Fill implementation: >> >> template< typename TValue > >> void VariableLengthVector< TValue > >> ::Fill(TValue const & v) ITK_NOEXCEPT >> { >> std::fill_n(&this->m_Data[0], m_NumElements, v); >> } >> >> In this test call, m_Data is nullptr, and m_NumElements is 0, so >> clearly,&m_Data[0] is not a useful pointer, and with 0 elements, there >> is nothing to fill. >> >> So.... should the implementation of Fill be changed to be conditional >> on the pointer being non-nullptr, or the number of elements being >> non-zero, or both? (Are other Fill implementations protected like so?) >> >> Or should the test be changed to avoid calling Fill when there are no >> elements...? > > I'd say that this is a bug in std::fill_n (or something related to the > STL being in CHECKED MODE) and that we should fall back into a plain > loop. We should avoid adding such defensive tests (if (!empty) fill_n()). > > I can take care of this issue (only on Monday). If you don't mind, I'd > rather avoid rebasing yet another time and first go through > http://review.source.kitware.com/#/c/20253/10 (I could also fix the > issue I've introduced in my first patch on VLV in this patch, but this > is not the usual patching policy if I understand correctly) > > > Regards, > -- > Luc Hermitte From gcasey at gmail.com Fri Oct 23 13:59:08 2015 From: gcasey at gmail.com (Casey Goodlett) Date: Fri, 23 Oct 2015 13:59:08 -0400 Subject: [ITK-dev] Bug in the library, or just in the test..? In-Reply-To: References: <562A6F79.2060105@c-s.fr> Message-ID: Hi David, I'm not sure that m_Data is nullptr. I assume its an alias for std::vector of size zero. I've hit this bug a couple of times. In visual studio debug mode &std::vector[0] raises an error for vectors of size zero even if that address is never used for anything. The bug is not in fill_n because the error is raised before fill_n is called. Calling fill_n with a bogus pointer and size zero is valid. On linux the system is happy to generate a bogus pointer thats never used for anything so no valgrind errors are ever generated. I recommend checking an if(m_NumElements >0) in pre c++-11. In c++11 I recommend using the data() method which was added for precisely this reason. Hope that helps. Casey Goodlett On Fri, Oct 23, 2015 at 1:47 PM, David Cole via Insight-developers < insight-developers at itk.org> wrote: > It is definitely related to STL being checked in a Debug Visual Studio > build... I get a bunch of ASSERT dialogs that pop up, so the test > times out and hangs there with the dialog up until I kill it manually. > > If I ignore through all the dialogs that pop up (click ignore on each > of them, there are exactly 12 in total), then the test output is > normal, and it reports that it has PASSED. > > I can wait for a fix. I was just asking to see if it was a known > thing, and find out if anybody was working on it, or if there was a > general recommendation about what the right fix for it is before I > attempt to fix it myself. > > I'm curious, though, why is using "&this->m_Data[0]" acceptable if > m_Data is nullptr ...? Why doesn't valgrind pick this up as a problem? > > > D > > > > > On Fri, Oct 23, 2015 at 1:33 PM, Luc Hermitte wrote: > > Hi, > > > > Le 23/10/2015 18:43, David Cole via Insight-developers a ?crit : > >> The itkTransformTest is the only test failing on my Visual Studio 2013 > >> Debug dashboard because of this code: > > > > What is the exact error produced when your run the test in verbose mode? > > > > > >> The problem is in the Fill implementation: > >> > >> template< typename TValue > > >> void VariableLengthVector< TValue > > >> ::Fill(TValue const & v) ITK_NOEXCEPT > >> { > >> std::fill_n(&this->m_Data[0], m_NumElements, v); > >> } > >> > >> In this test call, m_Data is nullptr, and m_NumElements is 0, so > >> clearly,&m_Data[0] is not a useful pointer, and with 0 elements, there > >> is nothing to fill. > >> > >> So.... should the implementation of Fill be changed to be conditional > >> on the pointer being non-nullptr, or the number of elements being > >> non-zero, or both? (Are other Fill implementations protected like so?) > >> > >> Or should the test be changed to avoid calling Fill when there are no > >> elements...? > > > > I'd say that this is a bug in std::fill_n (or something related to the > > STL being in CHECKED MODE) and that we should fall back into a plain > > loop. We should avoid adding such defensive tests (if (!empty) fill_n()). > > > > I can take care of this issue (only on Monday). If you don't mind, I'd > > rather avoid rebasing yet another time and first go through > > http://review.source.kitware.com/#/c/20253/10 (I could also fix the > > issue I've introduced in my first patch on VLV in this patch, but this > > is not the usual patching policy if I understand correctly) > > > > > > Regards, > > -- > > Luc Hermitte > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Kitware offers ITK Training Courses, for more information visit: > http://kitware.com/products/protraining.php > > Please keep messages on-topic and check the ITK FAQ at: > http://www.itk.org/Wiki/ITK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/insight-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Fri Oct 23 14:10:07 2015 From: DLRdave at aol.com (David Cole) Date: Fri, 23 Oct 2015 14:10:07 -0400 Subject: [ITK-dev] Bug in the library, or just in the test..? In-Reply-To: References: <562A6F79.2060105@c-s.fr> Message-ID: I am sure m_Data is nullptr. In the debugger, it says so. The value of "this" is a valid pointer, and the value of m_Data is 0x00000000. The assert is coming from squarely inside a call to std::fill_n with the text: Debug Assertion Failed! Program: C:\WINDOWS\SYSTEM32\MSVCP120D.dll File: C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\INCLUDE\xutility Line: 2713 Expression: invalid null pointer That line is inside std::fill_n, so ... pretty sure m_Data is nullptr. D On Fri, Oct 23, 2015 at 1:59 PM, Casey Goodlett wrote: > Hi David, > > I'm not sure that m_Data is nullptr. I assume its an alias for std::vector > of size zero. > > I've hit this bug a couple of times. In visual studio debug mode > &std::vector[0] raises an error for vectors of size zero even if that > address is never used for anything. The bug is not in fill_n because the > error is raised before fill_n is called. Calling fill_n with a bogus > pointer and size zero is valid. > > On linux the system is happy to generate a bogus pointer thats never used > for anything so no valgrind errors are ever generated. > > I recommend checking an if(m_NumElements >0) in pre c++-11. In c++11 I > recommend using the data() method which was added for precisely this reason. > > Hope that helps. > > > Casey Goodlett > > On Fri, Oct 23, 2015 at 1:47 PM, David Cole via Insight-developers > wrote: >> >> It is definitely related to STL being checked in a Debug Visual Studio >> build... I get a bunch of ASSERT dialogs that pop up, so the test >> times out and hangs there with the dialog up until I kill it manually. >> >> If I ignore through all the dialogs that pop up (click ignore on each >> of them, there are exactly 12 in total), then the test output is >> normal, and it reports that it has PASSED. >> >> I can wait for a fix. I was just asking to see if it was a known >> thing, and find out if anybody was working on it, or if there was a >> general recommendation about what the right fix for it is before I >> attempt to fix it myself. >> >> I'm curious, though, why is using "&this->m_Data[0]" acceptable if >> m_Data is nullptr ...? Why doesn't valgrind pick this up as a problem? >> >> >> D >> >> >> >> >> On Fri, Oct 23, 2015 at 1:33 PM, Luc Hermitte wrote: >> > Hi, >> > >> > Le 23/10/2015 18:43, David Cole via Insight-developers a ?crit : >> >> The itkTransformTest is the only test failing on my Visual Studio 2013 >> >> Debug dashboard because of this code: >> > >> > What is the exact error produced when your run the test in verbose mode? >> > >> > >> >> The problem is in the Fill implementation: >> >> >> >> template< typename TValue > >> >> void VariableLengthVector< TValue > >> >> ::Fill(TValue const & v) ITK_NOEXCEPT >> >> { >> >> std::fill_n(&this->m_Data[0], m_NumElements, v); >> >> } >> >> >> >> In this test call, m_Data is nullptr, and m_NumElements is 0, so >> >> clearly,&m_Data[0] is not a useful pointer, and with 0 elements, there >> >> is nothing to fill. >> >> >> >> So.... should the implementation of Fill be changed to be conditional >> >> on the pointer being non-nullptr, or the number of elements being >> >> non-zero, or both? (Are other Fill implementations protected like so?) >> >> >> >> Or should the test be changed to avoid calling Fill when there are no >> >> elements...? >> > >> > I'd say that this is a bug in std::fill_n (or something related to the >> > STL being in CHECKED MODE) and that we should fall back into a plain >> > loop. We should avoid adding such defensive tests (if (!empty) >> > fill_n()). >> > >> > I can take care of this issue (only on Monday). If you don't mind, I'd >> > rather avoid rebasing yet another time and first go through >> > http://review.source.kitware.com/#/c/20253/10 (I could also fix the >> > issue I've introduced in my first patch on VLV in this patch, but this >> > is not the usual patching policy if I understand correctly) >> > >> > >> > Regards, >> > -- >> > Luc Hermitte >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Kitware offers ITK Training Courses, for more information visit: >> http://kitware.com/products/protraining.php >> >> Please keep messages on-topic and check the ITK FAQ at: >> http://www.itk.org/Wiki/ITK_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/insight-developers > > From hans-johnson at uiowa.edu Fri Oct 23 14:13:06 2015 From: hans-johnson at uiowa.edu (Johnson, Hans J) Date: Fri, 23 Oct 2015 18:13:06 +0000 Subject: [ITK-dev] Bug in the library, or just in the test..? In-Reply-To: <562A6F79.2060105@c-s.fr> References: <562A6F79.2060105@c-s.fr> Message-ID: <4825C0B9-A21C-487F-9A03-4D4D996D30EB@uiowa.edu> This is not a bug in std::fill_n The bug is ?&this->m_Data[0]?. I think that we need to check for this degenerate case. I pushed an initial patch to review: http://review.source.kitware.com/#/c/20307/ Hans On 10/23/15, 12:33 PM, "Insight-developers on behalf of Luc Hermitte" wrote: >Hi, > >Le 23/10/2015 18:43, David Cole via Insight-developers a ?crit : >> The itkTransformTest is the only test failing on my Visual Studio 2013 >> Debug dashboard because of this code: > >What is the exact error produced when your run the test in verbose mode? > > >> The problem is in the Fill implementation: >> >> template< typename TValue > >> void VariableLengthVector< TValue > >> ::Fill(TValue const & v) ITK_NOEXCEPT >> { >> std::fill_n(&this->m_Data[0], m_NumElements, v); >> } >> >> In this test call, m_Data is nullptr, and m_NumElements is 0, so >> clearly,&m_Data[0] is not a useful pointer, and with 0 elements, there >> is nothing to fill. >> >> So.... should the implementation of Fill be changed to be conditional >> on the pointer being non-nullptr, or the number of elements being >> non-zero, or both? (Are other Fill implementations protected like so?) >> >> Or should the test be changed to avoid calling Fill when there are no >> elements...? > >I'd say that this is a bug in std::fill_n (or something related to the >STL being in CHECKED MODE) and that we should fall back into a plain >loop. We should avoid adding such defensive tests (if (!empty) fill_n()). > >I can take care of this issue (only on Monday). If you don't mind, I'd >rather avoid rebasing yet another time and first go through >http://review.source.kitware.com/#/c/20253/10 (I could also fix the >issue I've introduced in my first patch on VLV in this patch, but this >is not the usual patching policy if I understand correctly) > > >Regards, >-- >Luc Hermitte >_______________________________________________ >Powered by www.kitware.com > >Visit other Kitware open-source projects at >http://www.kitware.com/opensource/opensource.html > >Kitware offers ITK Training Courses, for more information visit: >http://kitware.com/products/protraining.php > >Please keep messages on-topic and check the ITK FAQ at: >http://www.itk.org/Wiki/ITK_FAQ > >Follow this link to subscribe/unsubscribe: >http://public.kitware.com/mailman/listinfo/insight-developers ________________________________ Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. ________________________________ From blowekamp at mail.nih.gov Fri Oct 23 14:17:42 2015 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Fri, 23 Oct 2015 14:17:42 -0400 Subject: [ITK-dev] Bug in the library, or just in the test..? In-Reply-To: References: <562A6F79.2060105@c-s.fr> Message-ID: <99A8D0FB-89B3-44B9-9839-FEBFE1709953@mail.nih.gov> We have seen this a couple times before [1]. Unfortunately the windows debug testing takes too long and times out in many cases so we don't have it on the dashboard for many versions. I would add the if statement as Casey suggests. Brad [1] https://github.com/InsightSoftwareConsortium/ITK/commit/d21f4a64c3c04a83d38324316e7e2bffa7c14d14 On Oct 23, 2015, at 2:10 PM, David Cole via Insight-developers wrote: > I am sure m_Data is nullptr. In the debugger, it says so. The value of > "this" is a valid pointer, and the value of m_Data is 0x00000000. > > The assert is coming from squarely inside a call to std::fill_n with the text: > > Debug Assertion Failed! > > Program: C:\WINDOWS\SYSTEM32\MSVCP120D.dll > File: C:\Program Files (x86)\Microsoft Visual Studio > 12.0\VC\INCLUDE\xutility > Line: 2713 > > Expression: invalid null pointer > > That line is inside std::fill_n, so ... pretty sure m_Data is nullptr. > > > D > > > > > On Fri, Oct 23, 2015 at 1:59 PM, Casey Goodlett wrote: >> Hi David, >> >> I'm not sure that m_Data is nullptr. I assume its an alias for std::vector >> of size zero. >> >> I've hit this bug a couple of times. In visual studio debug mode >> &std::vector[0] raises an error for vectors of size zero even if that >> address is never used for anything. The bug is not in fill_n because the >> error is raised before fill_n is called. Calling fill_n with a bogus >> pointer and size zero is valid. >> >> On linux the system is happy to generate a bogus pointer thats never used >> for anything so no valgrind errors are ever generated. >> >> I recommend checking an if(m_NumElements >0) in pre c++-11. In c++11 I >> recommend using the data() method which was added for precisely this reason. >> >> Hope that helps. >> >> >> Casey Goodlett >> >> On Fri, Oct 23, 2015 at 1:47 PM, David Cole via Insight-developers >> wrote: >>> >>> It is definitely related to STL being checked in a Debug Visual Studio >>> build... I get a bunch of ASSERT dialogs that pop up, so the test >>> times out and hangs there with the dialog up until I kill it manually. >>> >>> If I ignore through all the dialogs that pop up (click ignore on each >>> of them, there are exactly 12 in total), then the test output is >>> normal, and it reports that it has PASSED. >>> >>> I can wait for a fix. I was just asking to see if it was a known >>> thing, and find out if anybody was working on it, or if there was a >>> general recommendation about what the right fix for it is before I >>> attempt to fix it myself. >>> >>> I'm curious, though, why is using "&this->m_Data[0]" acceptable if >>> m_Data is nullptr ...? Why doesn't valgrind pick this up as a problem? >>> >>> >>> D >>> >>> >>> >>> >>> On Fri, Oct 23, 2015 at 1:33 PM, Luc Hermitte wrote: >>>> Hi, >>>> >>>> Le 23/10/2015 18:43, David Cole via Insight-developers a ?crit : >>>>> The itkTransformTest is the only test failing on my Visual Studio 2013 >>>>> Debug dashboard because of this code: >>>> >>>> What is the exact error produced when your run the test in verbose mode? >>>> >>>> >>>>> The problem is in the Fill implementation: >>>>> >>>>> template< typename TValue > >>>>> void VariableLengthVector< TValue > >>>>> ::Fill(TValue const & v) ITK_NOEXCEPT >>>>> { >>>>> std::fill_n(&this->m_Data[0], m_NumElements, v); >>>>> } >>>>> >>>>> In this test call, m_Data is nullptr, and m_NumElements is 0, so >>>>> clearly,&m_Data[0] is not a useful pointer, and with 0 elements, there >>>>> is nothing to fill. >>>>> >>>>> So.... should the implementation of Fill be changed to be conditional >>>>> on the pointer being non-nullptr, or the number of elements being >>>>> non-zero, or both? (Are other Fill implementations protected like so?) >>>>> >>>>> Or should the test be changed to avoid calling Fill when there are no >>>>> elements...? >>>> >>>> I'd say that this is a bug in std::fill_n (or something related to the >>>> STL being in CHECKED MODE) and that we should fall back into a plain >>>> loop. We should avoid adding such defensive tests (if (!empty) >>>> fill_n()). >>>> >>>> I can take care of this issue (only on Monday). If you don't mind, I'd >>>> rather avoid rebasing yet another time and first go through >>>> http://review.source.kitware.com/#/c/20253/10 (I could also fix the >>>> issue I've introduced in my first patch on VLV in this patch, but this >>>> is not the usual patching policy if I understand correctly) >>>> >>>> >>>> Regards, >>>> -- >>>> Luc Hermitte >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Kitware offers ITK Training Courses, for more information visit: >>> http://kitware.com/products/protraining.php >>> >>> Please keep messages on-topic and check the ITK FAQ at: >>> http://www.itk.org/Wiki/ITK_FAQ >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/insight-developers >> >> > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Kitware offers ITK Training Courses, for more information visit: > http://kitware.com/products/protraining.php > > Please keep messages on-topic and check the ITK FAQ at: > http://www.itk.org/Wiki/ITK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/insight-developers From luc.hermitte at c-s.fr Sat Oct 24 08:36:40 2015 From: luc.hermitte at c-s.fr (HERMITTE Luc) Date: Sat, 24 Oct 2015 14:36:40 +0200 Subject: [ITK-dev] Bug in the library, or just in the test..? In-Reply-To: <4825C0B9-A21C-487F-9A03-4D4D996D30EB@uiowa.edu> References: <562A6F79.2060105@c-s.fr> <4825C0B9-A21C-487F-9A03-4D4D996D30EB@uiowa.edu> Message-ID: <20151024143640.Horde.ThnMxW0sY16pYO69sKjxNw4@messagerie.si.c-s.fr> Hi, "Johnson, Hans J" a ?crit?: > This is not a bug in std::fill_n > > The bug is ?&this->m_Data[0]?. That's what I was thinking as well since last night. How is VC++ responding to just "this->m_Data" ? (and this->m_Data + this->GetSize() where needed) > I think that we need to check for this degenerate case. Useless tests are one of the things I trying to get rid of in my series of patches for better performances with VariableLengthVectors. If VC++ crashes with this simplified syntax, then the best solution is to fall back to simple loop, or may be an itk::fill_n, and itk::copy that doesn't check for the non-nullity of the input pointer. Regards, -- Luc Hermitte From DLRdave at aol.com Mon Oct 26 11:41:57 2015 From: DLRdave at aol.com (David Cole) Date: Mon, 26 Oct 2015 11:41:57 -0400 Subject: [ITK-dev] Fwd: Change in ITK[master]: BUG: Make valid calling with m_NumElements == 0 In-Reply-To: References: <20151025134930.18143656005B@source.kitware.com> <2F4A6833-B27D-4F5C-A4C3-EA2D428842F8@uiowa.edu> <562DDE62.6060508@c-s.fr> <562E3D4A.2030103@c-s.fr> Message-ID: FYI -- ongoing discussion related to Debug Visual Studio builds and nullptr checks (or lack thereof) ---------- Forwarded message ---------- From: David Cole Date: Mon, Oct 26, 2015 at 11:24 AM Subject: Re: Change in ITK[master]: BUG: Make valid calling with m_NumElements == 0 To: Luc Hermitte Cc: "Johnson, Hans J" , David Cole (cc-ing myself with my ITK dev mailing list email so I can loop in the ITK dev list so others may participate in the discussion if they feel so inclined) I think you must mean: std::fill(m_Data, m_NumElements, val) ...because if you really do mean m_Data->m_NumElements, you still have a problem when m_Data is nullptr. Same with: std::copy(&v.m_Data[0], &v.m_Data[N], &this->m_Data[0]); If m_Data can possibly be nullptr in either "v" or "this" then I do not see how this is a useful call to std::copy without checking for nullptr. If m_Data is nullptr, m_Data[0] and m_Data[N] are meaningless expressions. I would really really really like to see some evidence from you that adding nullptr checks is materially harmful to performance in some real world fill/copy scenario before agreeing to any patch which does not include nullptr checks. Thanks, David C. On Mon, Oct 26, 2015 at 10:48 AM, Luc Hermitte wrote: > > After further investigations. > > VC++'s fill() requires: > - the output range to be valid (i.e., in our case, if first!=last, first > and last must be non null pointers, and first must be < last) > > VC++'s fill_n() requires > - the output iterator to be valid, i.e. not null in case of a pointer > > This means that by using std::fill(m_Data, m_Data->m_NumElements, val) > we should fix the bug observed. > > I've embedded the fix in my latest patch set > (http://review.source.kitware.com/#/c/20253/) > > > Regarding std::copy(). > VC++'s copy() requires : > - the input range to be valid (if first!=last, first and last shall not > be null pointers, and first shall be < last) > - the output iterator to be valid (!=0 in case of a pointer) > > There is a still bug with VC++ copy() implementation in the following > use case: > VariableLengthVector v1, v2; > v1 = v2; // should fail as well with VC++ > > > Indeed, first SetSize(0, DontShrinkToFit(), DumpOldValue()) is called > -> no copy is done, but this->m_Data is left null. > Then, std::copy(&v.m_Data[0], &v.m_Data[N], &this->m_Data[0]); > Unfortunately, &this->m_Data[0] is left unchanged and null, and VC++ > will complain :( > > > This means, either : > - we provide an itk::copy() that does not require outIt to be non null > when the input range is empty > - or we write the loop manually > - or we add another test in operator=(Self) -- thing that'll really like > to avoid > > Finally, note as well odd situations in the current implementation -- my > fault I guess. > A newly default-constructed VLV will have a null m_Data pointer. > However, a VLV constructed with VariableLengthVector v(0) will > have a non null m_Data pointer. > > Regards > --Luc Hermitte > > Le 26/10/2015 09:03, Luc Hermitte a ?crit : > > Hi, > > > > Le 25/10/2015 18:37, Johnson, Hans J a ?crit : > >> Should we simply add documentation that states: "Behavior is undefined when length of vector is zero?, add an assertion when compiled in debug mode, and then remove the degenerate case in the test suite? > > > > > > This could be enough regarding Fill(). I'd say it's up to you. IMO, it > > could be simply fixed with an loop or an alternative of fill_n that > > states as precondition that "The range [outIt, outIt+n) shall be valid ; > > and n shall be >= 0", instead of "The iterator outIt shall be valid ; > > and n >= 0". > > This way the end-user won't have to check he doesn't call Fill() on > > empty VariableLengthVectors -- it would be considered as a no-op exactly > > as "delete nullptr". > > > > However, we need to be sure that the copy constructor of empty > > VariableLengthVector has no side effect. > > > > Regards, > > --Luc Hermitte > > > >> > >> > >> > >> > >> > >> On 10/25/15, 8:49 AM, "Luc Hermitte (Code Review)" wrote: > >> > >>> Luc Hermitte has posted comments on this change. > >>> > >>> Change subject: BUG: Make valid calling with m_NumElements == 0 > >>> ...................................................................... > >>> > >>> > >>> Patch Set 2: > >>> > >>>> You cannot call std::fill_n with a nullptr for Debug VS 2013. > >>>> > >>>> The implementation of fill_n looks like this: > >>>> > >>>> template >>>> class _Diff, > >>>> class _Ty> inline > >>>> _OutIt fill_n(_OutIt _Dest, _Diff _Count, const _Ty& _Val) > >>>> { // copy _Val _Count times through [_Dest, ...) > >>>> _DEBUG_POINTER(_Dest); > >>>> return (_Fill_n(_Dest, _Count, _Val, > >>>> _Is_checked(_Dest))); > >>>> } > >>>> > >>>> The _DEBUG_POINTER line is called unconditionally, and will throw > >>>> this assert if the pointer is nullptr. > >>> > >>> That's odd. I don't read such a precondition in the standard. > >>> Is it the same with std::copy()? > >>> > >>> > >>>> Why are you against doing a nullptr check or a check on the number > >>>> of elements prior to calling fill_n? > >>>> > >>>> If you are calling fill_n so frequently that you're concerned about > >>>> adding a micro-smidge of time to each call, perhaps you're calling > >>>> it too frequently... > >>> > >>> I totally agree that such algorithms are often called to many times. and yet, when they are, they are called on pixels. This means they are sometimes called billion times. We don't need to add a test that we could easily avoid and still stay robust. > >>> > >>> What we need is a fill_n implementation that have as a precondition: "ptr!=nullptr || size==0", and not "ptr!=nullptr". > >>> > >>> > >>> > >>>> If you want the fastest code possible, without doing the > >>>> appropriate nullptr safety checks, then you must guarantee that the > >>>> entire test suite never tries to execute a test case with a > >>>> nullptr. So another solution would be simply NOT to execute tests > >>>> that result in these calls for Debug Microsoft builds. > >>> > >>> We simply need algorithms with less restrictive preconditions. > >>> For instance > >>> > >>> // untested code > >>> template > >>> OutIt itk::fill_n(OutIt start, Size size, T const& value) { > >>> assert(start ||size == 0); // the test is not correct, just to give an idea of what it should look like > >>> for ( ; size != 0 ; --size, ++start) > >>> *start = value; > >>> return start; > >>> } > >>> > >>> > >>>> It is my contention that **if** there is a performance problem with > >>>> code after simply adding "if (this->m_Data)" checks before fill and > >>>> copy calls, that the performance problem is with the **callers** of > >>>> these things. > >>> > >>> Somehow I agree. Unfortunately, we tend to call these functions too many times, i.e. once per pixel if not more. We have a lot of pixels. > >>> > >>> Here it's easy to have a correct code (that'll pass tests with VC++ in Debug Mode) without this redundant branching. Why pay for this branching? > >>> > >>> > >>>> Fill and copy effectively perform N assignment operations. If you > >>>> cannot afford a single nullptr check when you are doing N > >>>> assignment operations then you should write special case code to > >>>> avoid the safety checks. > >>> > >>> N is often small (< 16) > >>> > >>>> The rest of us would like to be alerted ASAP when we accidentally > >>>> try to "fill" or "copy into" an empty container. > >>> > >>> We don't need to here. > >>> However, if you consider that filling or copying an empty vector is a programming error, then we should document it and formalize the related precondition (assertion, or C++17 [[expect: size != 0]]). > >>> > >>> -- > >>> To view, visit http://review.source.kitware.com/20307 > >>> > >>> > >>> To unsubscribe, visit http://review.source.kitware.com/settings > >>> > >>> Gerrit-MessageType: comment > >>> Gerrit-Change-Id: I6b9ba9d6ddf05450485a88ffbff4f14568205f26 > >>> Gerrit-PatchSet: 2 > >>> Gerrit-Project: ITK > >>> Gerrit-Branch: master > >>> Gerrit-Owner: Hans J. Johnson > >>> Gerrit-Reviewer: David Cole > >>> Gerrit-Reviewer: Hans J. Johnson > >>> Gerrit-Reviewer: Kitware Build Robot > >>> Gerrit-Reviewer: Luc Hermitte > >>> Gerrit-HasComments: No > >> > >> > >> ________________________________ > >> Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. > >> ________________________________ > >> > > > From luc.hermitte at c-s.fr Mon Oct 26 12:18:50 2015 From: luc.hermitte at c-s.fr (Luc Hermitte) Date: Mon, 26 Oct 2015 17:18:50 +0100 Subject: [ITK-dev] Fwd: Change in ITK[master]: BUG: Make valid calling with m_NumElements == 0 In-Reply-To: References: <20151025134930.18143656005B@source.kitware.com> <2F4A6833-B27D-4F5C-A4C3-EA2D428842F8@uiowa.edu> <562DDE62.6060508@c-s.fr> <562E3D4A.2030103@c-s.fr> Message-ID: <562E526A.2020606@c-s.fr> Le 26/10/2015 16:24, David Cole a ?crit : > (cc-ing myself with my ITK dev mailing list email so I can loop in the > ITK dev list so others may participate in the discussion if they feel so > inclined) > > > I think you must mean: > std::fill(m_Data, m_NumElements, val) > > ...because if you really do mean m_Data->m_NumElements, you > still have a problem when m_Data is nullptr. Yes indeed, you're right. (It won't compile anyway. ^^') > Same with: > std::copy(&v.m_Data[0], &v.m_Data[N], &this->m_Data[0]); > > If m_Data can possibly be nullptr in either "v" or "this" then I do not > see how this is a useful call to std::copy without checking for nullptr. > If m_Data is nullptr, m_Data[0] and m_Data[N] are meaningless expressions. They still mean m_Data+0 and m_Data+N. If N == 0, this is, IMO, somehow a valid range, even is trivially empty. And copy() knows how to copy empty ranges. We should not have to test whether the range is empty or not. > I would really really really like to see some evidence from you that > adding nullptr checks is materially harmful to performance in some real > world fill/copy scenario before agreeing to any patch which does not > include nullptr checks. fill_n case should have already been fixed: I've used fill() instead to force VC++ STL use preconditions expressed with a range instead of an iterator. Regarding the last case: copy(). I could return the question. What's wrong with replacing the last and only invalid call to std::copy (according to VC++ excessive checks) with: for (size_t i = 0; i != m_NumElements ; ++i) this->m_Data[i] = v.m_Data[i]; ? I agree that premature optimisation is a waste of time. Here, several of you are suggesting the opposite: a premature pessimization, i.e. to do a test that shall not be required if VC++ std::copy() preconditions were correct. Note BTW that I'm just suggesting to revert one change that I've introduced in a previous patch (http://review.source.kitware.com/#/c/19962/7/Modules/Core/Common/include/itkVariableLengthVector.hxx) On a side note, I've submitted a bug report to VC++ tracker (https://connect.microsoft.com/VisualStudio/feedback/details/1947236). Regards --Luc H. > > > Thanks, > David C. > > > > On Mon, Oct 26, 2015 at 10:48 AM, Luc Hermitte > wrote: > > After further investigations. > > VC++'s fill() requires: > - the output range to be valid (i.e., in our case, if first!=last, first > and last must be non null pointers, and first must be < last) > > VC++'s fill_n() requires > - the output iterator to be valid, i.e. not null in case of a pointer > > This means that by using std::fill(m_Data, m_Data->m_NumElements, val) > we should fix the bug observed. > > I've embedded the fix in my latest patch set > (http://review.source.kitware.com/#/c/20253/) > > > Regarding std::copy(). > VC++'s copy() requires : > - the input range to be valid (if first!=last, first and last shall not > be null pointers, and first shall be < last) > - the output iterator to be valid (!=0 in case of a pointer) > > There is a still bug with VC++ copy() implementation in the following > use case: > VariableLengthVector v1, v2; > v1 = v2; // should fail as well with VC++ > > > Indeed, first SetSize(0, DontShrinkToFit(), DumpOldValue()) is called > -> no copy is done, but this->m_Data is left null. > Then, std::copy(&v.m_Data[0], &v.m_Data[N], &this->m_Data[0]); > Unfortunately, &this->m_Data[0] is left unchanged and null, and VC++ > will complain :( > > > This means, either : > - we provide an itk::copy() that does not require outIt to be non null > when the input range is empty > - or we write the loop manually > - or we add another test in operator=(Self) -- thing that'll really like > to avoid > > Finally, note as well odd situations in the current implementation -- my > fault I guess. > A newly default-constructed VLV will have a null m_Data pointer. > However, a VLV constructed with VariableLengthVector v(0) will > have a non null m_Data pointer. > > Regards > --Luc Hermitte > > Le 26/10/2015 09:03, Luc Hermitte a ?crit : > > Hi, > > > > Le 25/10/2015 18:37, Johnson, Hans J a ?crit : > >> Should we simply add documentation that states: "Behavior is > undefined when length of vector is zero?, add an assertion when > compiled in debug mode, and then remove the degenerate case in the > test suite? > > > > > > This could be enough regarding Fill(). I'd say it's up to you. IMO, it > > could be simply fixed with an loop or an alternative of fill_n that > > states as precondition that "The range [outIt, outIt+n) shall be > valid ; > > and n shall be >= 0", instead of "The iterator outIt shall be valid ; > > and n >= 0". > > This way the end-user won't have to check he doesn't call Fill() on > > empty VariableLengthVectors -- it would be considered as a no-op > exactly > > as "delete nullptr". > > > > However, we need to be sure that the copy constructor of empty > > VariableLengthVector has no side effect. > > > > Regards, > > --Luc Hermitte > > > >> > >> > >> > >> > >> > >> On 10/25/15, 8:49 AM, "Luc Hermitte (Code Review)" > > wrote: > >> > >>> Luc Hermitte has posted comments on this change. > >>> > >>> Change subject: BUG: Make valid calling with m_NumElements == 0 > >>> > ...................................................................... > >>> > >>> > >>> Patch Set 2: > >>> > >>>> You cannot call std::fill_n with a nullptr for Debug VS 2013. > >>>> > >>>> The implementation of fill_n looks like this: > >>>> > >>>> template >>>> class _Diff, > >>>> class _Ty> inline > >>>> _OutIt fill_n(_OutIt _Dest, _Diff _Count, const _Ty& _Val) > >>>> { // copy _Val _Count times through [_Dest, ...) > >>>> _DEBUG_POINTER(_Dest); > >>>> return (_Fill_n(_Dest, _Count, _Val, > >>>> _Is_checked(_Dest))); > >>>> } > >>>> > >>>> The _DEBUG_POINTER line is called unconditionally, and will throw > >>>> this assert if the pointer is nullptr. > >>> > >>> That's odd. I don't read such a precondition in the standard. > >>> Is it the same with std::copy()? > >>> > >>> > >>>> Why are you against doing a nullptr check or a check on the number > >>>> of elements prior to calling fill_n? > >>>> > >>>> If you are calling fill_n so frequently that you're concerned about > >>>> adding a micro-smidge of time to each call, perhaps you're calling > >>>> it too frequently... > >>> > >>> I totally agree that such algorithms are often called to many > times. and yet, when they are, they are called on pixels. This means > they are sometimes called billion times. We don't need to add a test > that we could easily avoid and still stay robust. > >>> > >>> What we need is a fill_n implementation that have as a > precondition: "ptr!=nullptr || size==0", and not "ptr!=nullptr". > >>> > >>> > >>> > >>>> If you want the fastest code possible, without doing the > >>>> appropriate nullptr safety checks, then you must guarantee that the > >>>> entire test suite never tries to execute a test case with a > >>>> nullptr. So another solution would be simply NOT to execute tests > >>>> that result in these calls for Debug Microsoft builds. > >>> > >>> We simply need algorithms with less restrictive preconditions. > >>> For instance > >>> > >>> // untested code > >>> template > >>> OutIt itk::fill_n(OutIt start, Size size, T const& value) { > >>> assert(start ||size == 0); // the test is not correct, > just to give an idea of what it should look like > >>> for ( ; size != 0 ; --size, ++start) > >>> *start = value; > >>> return start; > >>> } > >>> > >>> > >>>> It is my contention that **if** there is a performance problem with > >>>> code after simply adding "if (this->m_Data)" checks before fill and > >>>> copy calls, that the performance problem is with the **callers** of > >>>> these things. > >>> > >>> Somehow I agree. Unfortunately, we tend to call these functions > too many times, i.e. once per pixel if not more. We have a lot of > pixels. > >>> > >>> Here it's easy to have a correct code (that'll pass tests with > VC++ in Debug Mode) without this redundant branching. Why pay for > this branching? > >>> > >>> > >>>> Fill and copy effectively perform N assignment operations. If you > >>>> cannot afford a single nullptr check when you are doing N > >>>> assignment operations then you should write special case code to > >>>> avoid the safety checks. > >>> > >>> N is often small (< 16) > >>> > >>>> The rest of us would like to be alerted ASAP when we accidentally > >>>> try to "fill" or "copy into" an empty container. > >>> > >>> We don't need to here. > >>> However, if you consider that filling or copying an empty vector > is a programming error, then we should document it and formalize the > related precondition (assertion, or C++17 [[expect: size != 0]]). From luc.hermitte at c-s.fr Tue Oct 27 08:11:20 2015 From: luc.hermitte at c-s.fr (Luc Hermitte) Date: Tue, 27 Oct 2015 13:11:20 +0100 Subject: [ITK-dev] Fwd: Change in ITK[master]: BUG: Make valid calling with m_NumElements == 0 In-Reply-To: References: <20151025134930.18143656005B@source.kitware.com> <2F4A6833-B27D-4F5C-A4C3-EA2D428842F8@uiowa.edu> <562DDE62.6060508@c-s.fr> <562E3D4A.2030103@c-s.fr> Message-ID: <562F69E8.2000304@c-s.fr> Hi, Le 26/10/2015 16:41, David Cole via Insight-developers a ?crit : > I would really really really like to see some evidence from you that > adding nullptr checks is materially harmful to performance in some > real world fill/copy scenario before agreeing to any patch which does > not include nullptr checks. Here are some micro-benchmarks (done with google-benchmark framework): https://gist.github.com/LucHermitte/7f1b8d5dd61c861e6ef9 Adding the test around std::copy in the assignment operator doesn't change anything. Nor the manual implementation. (These are not real world scenarios, however the result would be the same : no observable difference). I still find that adding a redundant test, just to workaround the implementation of a function in Debug mode and with a single family of compiler, is a clumsy solution. What the manual implementation does is as good as the defensive one. However, we could loose potential optimizations (like memcpy being used with POD types) when the size of the vector is big enough if the STL implementation tries to do it. BTW, memcpy(0,0,x) is officially an UB. And the more I read, the less I'm convinced that func(nullptr, null_size) is officially defined behaviour. So, if you prefer a test, let's go for a test -- which should be required only in the assignment operator. Regards, -- Luc Hermitte From julien.michel at cnes.fr Tue Oct 27 10:04:32 2015 From: julien.michel at cnes.fr (Julien Michel) Date: Tue, 27 Oct 2015 15:04:32 +0100 Subject: [ITK-dev] Fail to use http push to gerrit -> pull request Message-ID: <562F8470.8040402@cnes.fr> Dear ITK developers, I have a gerrit patch to submit behind my company firewall. I tried to use the http way (through our company proxy) by carefully following [1]. This used to work in the past, but it seems to be broken now : $ git gerrit-push Fetching gerrit master Pushing to gerrit Password for 'http://jmichel-otb at review.source.kitware.com': remote: Unauthorized fatal: Authentication failed for 'http://jmichel-otb at review.source.kitware.com/p/ITK/' I therefore created a pull request corresponding to this patch on github [2]. Nevertheless, I would rather use gerrit because of automated dashboard build and co., if only I could get it working again ... Regards, Julien Michel [1] http://www.itk.org/Wiki/ITK/Git/Account#Gerrit [2] https://github.com/InsightSoftwareConsortium/ITK/pull/8 -- Julien MICHEL CNES - DCT/SI/AP From matt.mccormick at kitware.com Tue Oct 27 10:51:52 2015 From: matt.mccormick at kitware.com (Matt McCormick) Date: Tue, 27 Oct 2015 10:51:52 -0400 Subject: [ITK-dev] Fail to use http push to gerrit -> pull request In-Reply-To: <562F8470.8040402@cnes.fr> References: <562F8470.8040402@cnes.fr> Message-ID: Hi Julien, Thanks for the patch and note about HTTP pushes. We will look further into the issue. In the meantime, I uploaded your patch here: http://review.source.kitware.com/#/c/20310/ Matt On Tue, Oct 27, 2015 at 10:04 AM, Julien Michel wrote: > Dear ITK developers, > > I have a gerrit patch to submit behind my company firewall. I tried to use > the http way (through our company proxy) by carefully following [1]. This > used to work in the past, but it seems to be broken now : > > $ git gerrit-push > Fetching gerrit master > Pushing to gerrit > Password for 'http://jmichel-otb at review.source.kitware.com': > remote: Unauthorized > fatal: Authentication failed for > 'http://jmichel-otb at review.source.kitware.com/p/ITK/' > > I therefore created a pull request corresponding to this patch on github > [2]. Nevertheless, I would rather use gerrit because of automated dashboard > build and co., if only I could get it working again ... > > Regards, > > Julien Michel > > > [1] http://www.itk.org/Wiki/ITK/Git/Account#Gerrit > [2] https://github.com/InsightSoftwareConsortium/ITK/pull/8 > > -- > Julien MICHEL > CNES - DCT/SI/AP > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Kitware offers ITK Training Courses, for more information visit: > http://kitware.com/products/protraining.php > > Please keep messages on-topic and check the ITK FAQ at: > http://www.itk.org/Wiki/ITK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/insight-developers From DLRdave at aol.com Tue Oct 27 12:04:48 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 27 Oct 2015 12:04:48 -0400 Subject: [ITK-dev] Fwd: Change in ITK[master]: BUG: Make valid calling with m_NumElements == 0 In-Reply-To: <562F69E8.2000304@c-s.fr> References: <20151025134930.18143656005B@source.kitware.com> <2F4A6833-B27D-4F5C-A4C3-EA2D428842F8@uiowa.edu> <562DDE62.6060508@c-s.fr> <562E3D4A.2030103@c-s.fr> <562F69E8.2000304@c-s.fr> Message-ID: I do prefer a test. This is C++. You should always check for nullptr if it is possible to get nullptr, and something bad could happen if you don't check. If you could prove to me that there is never a nullptr in this context, I would not care. But there is. The failing test proves it. Rather than thinking of this as "just to workaround the implementation of a function in Debug mode and with a single family of compiler," perhaps you should instead think of it as defensive programming. The fact is, these debug checks from Microsoft have helped and assisted me over the years FAR MORE than they have hurt. They help to detect problems early on, as soon as incorrect code is introduced and run. Yes, they're painful, and yes, sometimes slightly too aggressive. But they're worth it. Let me know if you would like me to build/run your patch set after you think you have it to the point where the Debug MS build should run without raising these assert dialogs. Thanks, David C. On Tue, Oct 27, 2015 at 8:11 AM, Luc Hermitte wrote: > Hi, > > Le 26/10/2015 16:41, David Cole via Insight-developers a ?crit : >> I would really really really like to see some evidence from you that >> adding nullptr checks is materially harmful to performance in some >> real world fill/copy scenario before agreeing to any patch which does >> not include nullptr checks. > > Here are some micro-benchmarks (done with google-benchmark framework): > > https://gist.github.com/LucHermitte/7f1b8d5dd61c861e6ef9 > > Adding the test around std::copy in the assignment operator doesn't > change anything. Nor the manual implementation. > (These are not real world scenarios, however the result would be the > same : no observable difference). > > I still find that adding a redundant test, just to workaround the > implementation of a function in Debug mode and with a single family of > compiler, is a clumsy solution. > > What the manual implementation does is as good as the defensive one. > However, we could loose potential optimizations (like memcpy being used > with POD types) when the size of the vector is big enough if the STL > implementation tries to do it. > > BTW, memcpy(0,0,x) is officially an UB. And the more I read, the less > I'm convinced that func(nullptr, null_size) is officially defined > behaviour. > > So, if you prefer a test, let's go for a test -- which should be > required only in the assignment operator. > > Regards, > > -- > Luc Hermitte From luc.hermitte at c-s.fr Tue Oct 27 15:20:01 2015 From: luc.hermitte at c-s.fr (Luc Hermitte) Date: Tue, 27 Oct 2015 20:20:01 +0100 Subject: [ITK-dev] Fwd: Change in ITK[master]: BUG: Make valid calling with m_NumElements == 0 In-Reply-To: References: <20151025134930.18143656005B@source.kitware.com> <2F4A6833-B27D-4F5C-A4C3-EA2D428842F8@uiowa.edu> <562DDE62.6060508@c-s.fr> <562E3D4A.2030103@c-s.fr> <562F69E8.2000304@c-s.fr> Message-ID: <562FCE61.1010506@c-s.fr> Le 27/10/2015 17:04, David Cole a ?crit : > I do prefer a test. The alternatives are not just test+std::copy VS no-test+std::copy. But test and std::copy VS manual loop where the test is pointless as it's already part of for() invariant. > This is C++. You should always check for nullptr > if it is possible to get nullptr, and something bad could happen if > you don't check. It's the "something bad could happen if you don't check" that makes all the difference here and that explain my reluctance. i.e. nothing bad should happen with usual/naive implementations of std::copy with std::copy(p,p, nullptr) -- if memcpy is triggered, I must admit my ignorance, and as others have said, it would be very surprising: http://stackoverflow.com/questions/5243012/is-it-guaranteed-to-be-safe-to-perform-memcpy0-0-0 [On a side note, it's up to the client code to check for nullity if nullity is rejected by the contract. Within the service code, we could wait for C++17, or more likely use assertions.] > If you could prove to me that there is never a > nullptr in this context, I would not care. But there is. The failing > test proves it. > Rather than thinking of this as "just to workaround the implementation > of a function in Debug mode and with a single family of compiler," > perhaps you should instead think of it as defensive programming. That's my problem. I see it exactly as defensive programming. Unlike (narrow) Design By Contract, the (wide) defensive programming approach adds tests that make no sense (in context were the contract is respected), and complicate the nominal code. > The fact is, these debug checks from Microsoft have helped and > assisted me over the years FAR MORE than they have hurt. They help to > detect problems early on, as soon as incorrect code is introduced and > run. Yes, they're painful, and yes, sometimes slightly too aggressive. > But they're worth it. I completely agree they are worth it. This time, the test (on copy -- as I've workaround the one on fill) is as you said : too aggressive. > Let me know if you would like me to build/run your patch set after you > think you have it to the point where the Debug MS build should run > without raising these assert dialogs. Yes please, I'd like to. Here is a patched (I hope -- memset and memcpy may trigger assertions, I don't know) version of the code. http://review.source.kitware.com/#/c/20313/ (I didn't know if, and how, I could take over the previous patch set on the subject. Sorry for the inconvenience) On the way, I've added missing documentation regarding invariants, preconditions and postconditions, plus the related assertions. This is a first draft. It's likely to contains English errors. I hope, however I did not assert incorrect contracts in the documentation. I'll read it again more carefully later. I've also added code to test operations on empty VLV. Thank you. -- Luc Hermitte From andinet.enqu at kitware.com Wed Oct 28 08:31:44 2015 From: andinet.enqu at kitware.com (Andinet Enquobahrie) Date: Wed, 28 Oct 2015 08:31:44 -0400 Subject: [ITK-dev] ANNOUNCE: Kitware is hiring technical project leads for the medical computing group Message-ID: Apologies for duplicate postings. =================== Hi folks, We are looking to hire technical project leads in our Medical Computing group. If you are a talented medical image analysis and visualization expert with strong project management skills, please consider applying. For the full posting see: http://tinyurl.com/qal35fp JOB DESCRIPTION ================ Kitware is actively seeking talented individuals to contribute to the creation, development and improvement of leading edge medical computing software solutions in the following ways: *Lead a team of computer scientists and developers in biomedical image analysis , visualization and end-user GUI application projects. *Develop and maintain client/sponsor relationships and participate in business development. *Initiate, build and maintain business and research relationships with commercial customers and external collaborators; and *Develop and write grant proposals to government funding agencies such as NIH, DOD and NSF. Qualifications *Masters or PhD in computer science, biomedical engineering, or a related field that has emphasis in medical image analysis and visualization *Concrete experience implementing biomedical analysis solutions such as: image registration, segmentation, volume rendering, statistical computing, visualization, end-user application etc.; with related open-source toolkits and applications such as ITK, VTK, Slicer and Qt. *Proven track record of leading projects through design, development, release, and maintenance phases *Proven track record of identifying funding sources, contributing to successful proposals and SOWs, and securing government and/or commercial contracts and *Excellent communication and writing skills Additional Information Kitware team members enjoy a small company environment, flexibility in work assignments, and high levels of independence and responsibility. Besides a great work environment, our comprehensive benefits package includes a generous compensation plan, flexible working hours, six weeks paid time off, 401(k), health insurance, life insurance, short- and long-term disability insurance, bonus plan, and free coffee, drinks and snacks. Applicants are currently being accepted for our Carrboro, NC location. Carrboro, North Carolina is located near Chapel Hill and the University of North Carolina, and is part of the larger Research Triangle Park region. This area is widely-noted for rapid growth of high-technology focused firms, and for being home to several excellent universities, including UNC, Duke, and NC State. The vibrancy in the area makes it a great place to live and Carrboro is also known for being a cultural hub full of award-winning restaurants and a vivid scene of music, theatre, and art. ==================== For other job openings at Kitware, please check http://jobs.kitware.com/opportunities.html -- Andinet Enquobahrie, Ph.D., MBA Assistant Director of Medical Computing Kitware, Inc. http://www.kitware.com (919) 969-6990 x311 -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Thu Oct 29 08:42:36 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 29 Oct 2015 08:42:36 -0400 Subject: [ITK-dev] Change in ITK[master]: BUG: Make valid calling with m_NumElements == 0 In-Reply-To: <562FCE61.1010506@c-s.fr> References: <20151025134930.18143656005B@source.kitware.com> <2F4A6833-B27D-4F5C-A4C3-EA2D428842F8@uiowa.edu> <562DDE62.6060508@c-s.fr> <562E3D4A.2030103@c-s.fr> <562F69E8.2000304@c-s.fr> <562FCE61.1010506@c-s.fr> Message-ID: Thanks for your work so far on all this. I really appreciate the effort, and it has already paid off: the test passed yesterday and today on my Debug VS dashboard. I will give a try to your latest patch set with the added assert calls later today. Thanks, David On Tuesday, October 27, 2015, Luc Hermitte wrote: > Le 27/10/2015 17:04, David Cole a ?crit : > > I do prefer a test. > > The alternatives are not just test+std::copy VS no-test+std::copy. But > test and std::copy VS manual loop where the test is pointless as it's > already part of for() invariant. > > > This is C++. You should always check for nullptr > > if it is possible to get nullptr, and something bad could happen if > > you don't check. > > It's the "something bad could happen if you don't check" that makes all > the difference here and that explain my reluctance. > > i.e. nothing bad should happen with usual/naive implementations of > std::copy with std::copy(p,p, nullptr) -- if memcpy is triggered, I must > admit my ignorance, and as others have said, it would be very > surprising: > > http://stackoverflow.com/questions/5243012/is-it-guaranteed-to-be-safe-to-perform-memcpy0-0-0 > > [On a side note, it's up to the client code to check for nullity if > nullity is rejected by the contract. Within the service code, we could > wait for C++17, or more likely use assertions.] > > > If you could prove to me that there is never a > > nullptr in this context, I would not care. But there is. The failing > > test proves it. > > > > Rather than thinking of this as "just to workaround the implementation > > of a function in Debug mode and with a single family of compiler," > > perhaps you should instead think of it as defensive programming. > > That's my problem. I see it exactly as defensive programming. Unlike > (narrow) Design By Contract, the (wide) defensive programming approach > adds tests that make no sense (in context were the contract is > respected), and complicate the nominal code. > > > > The fact is, these debug checks from Microsoft have helped and > > assisted me over the years FAR MORE than they have hurt. They help to > > detect problems early on, as soon as incorrect code is introduced and > > run. Yes, they're painful, and yes, sometimes slightly too aggressive. > > But they're worth it. > > I completely agree they are worth it. This time, the test (on copy -- as > I've workaround the one on fill) is as you said : too aggressive. > > > > Let me know if you would like me to build/run your patch set after you > > think you have it to the point where the Debug MS build should run > > without raising these assert dialogs. > > Yes please, I'd like to. > > Here is a patched (I hope -- memset and memcpy may trigger assertions, I > don't know) version of the code. > > http://review.source.kitware.com/#/c/20313/ (I didn't know if, and how, > I could take over the previous patch set on the subject. Sorry for the > inconvenience) > > On the way, I've added missing documentation regarding invariants, > preconditions and postconditions, plus the related assertions. This is a > first draft. It's likely to contains English errors. I hope, however I > did not assert incorrect contracts in the documentation. I'll read it > again more carefully later. > > I've also added code to test operations on empty VLV. > > > Thank you. > > -- > Luc Hermitte > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luc.hermitte at c-s.fr Thu Oct 29 09:11:04 2015 From: luc.hermitte at c-s.fr (Luc Hermitte) Date: Thu, 29 Oct 2015 14:11:04 +0100 Subject: [ITK-dev] Change in ITK[master]: BUG: Make valid calling with m_NumElements == 0 In-Reply-To: References: <20151025134930.18143656005B@source.kitware.com> <2F4A6833-B27D-4F5C-A4C3-EA2D428842F8@uiowa.edu> <562DDE62.6060508@c-s.fr> <562E3D4A.2030103@c-s.fr> <562F69E8.2000304@c-s.fr> <562FCE61.1010506@c-s.fr> Message-ID: <56321AE8.6050808@c-s.fr> Le 29/10/2015 13:42, David Cole a ?crit : > Thanks for your work so far on all this. You're welcome. > I really appreciate the effort, > and it has already paid off: the test passed yesterday and today on my > Debug VS dashboard. Wonderful! > I will give a try to your latest patch set with the added assert calls > later today. OK. Thank you. --Luc > > Thanks, > David > > > On Tuesday, October 27, 2015, Luc Hermitte > wrote: > > Le 27/10/2015 17:04, David Cole a ?crit : > > I do prefer a test. > > The alternatives are not just test+std::copy VS no-test+std::copy. But > test and std::copy VS manual loop where the test is pointless as it's > already part of for() invariant. > > > This is C++. You should always check for nullptr > > if it is possible to get nullptr, and something bad could happen if > > you don't check. > > It's the "something bad could happen if you don't check" that makes all > the difference here and that explain my reluctance. > > i.e. nothing bad should happen with usual/naive implementations of > std::copy with std::copy(p,p, nullptr) -- if memcpy is triggered, I must > admit my ignorance, and as others have said, it would be very > surprising: > http://stackoverflow.com/questions/5243012/is-it-guaranteed-to-be-safe-to-perform-memcpy0-0-0 > > [On a side note, it's up to the client code to check for nullity if > nullity is rejected by the contract. Within the service code, we could > wait for C++17, or more likely use assertions.] > > > If you could prove to me that there is never a > > nullptr in this context, I would not care. But there is. The failing > > test proves it. > > > > Rather than thinking of this as "just to workaround the implementation > > of a function in Debug mode and with a single family of compiler," > > perhaps you should instead think of it as defensive programming. > > That's my problem. I see it exactly as defensive programming. Unlike > (narrow) Design By Contract, the (wide) defensive programming approach > adds tests that make no sense (in context were the contract is > respected), and complicate the nominal code. > > > > The fact is, these debug checks from Microsoft have helped and > > assisted me over the years FAR MORE than they have hurt. They help to > > detect problems early on, as soon as incorrect code is introduced and > > run. Yes, they're painful, and yes, sometimes slightly too aggressive. > > But they're worth it. > > I completely agree they are worth it. This time, the test (on copy -- as > I've workaround the one on fill) is as you said : too aggressive. > > > > Let me know if you would like me to build/run your patch set after you > > think you have it to the point where the Debug MS build should run > > without raising these assert dialogs. > > Yes please, I'd like to. > > Here is a patched (I hope -- memset and memcpy may trigger assertions, I > don't know) version of the code. > > http://review.source.kitware.com/#/c/20313/ (I didn't know if, and how, > I could take over the previous patch set on the subject. Sorry for the > inconvenience) > > On the way, I've added missing documentation regarding invariants, > preconditions and postconditions, plus the related assertions. This is a > first draft. It's likely to contains English errors. I hope, however I > did not assert incorrect contracts in the documentation. I'll read it > again more carefully later. > > I've also added code to test operations on empty VLV. > > > Thank you. > > -- > Luc Hermitte > From matt.mccormick at kitware.com Thu Oct 29 14:18:18 2015 From: matt.mccormick at kitware.com (Matt McCormick) Date: Thu, 29 Oct 2015 14:18:18 -0400 Subject: [ITK-dev] Gerrit temporarily down for maintenance Message-ID: Hi folks, A heads up: Gerrit will temporarily be down for maintenance in periods over the next hour. Thanks, Matt From blowekamp at mail.nih.gov Fri Oct 30 08:47:31 2015 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Fri, 30 Oct 2015 08:47:31 -0400 Subject: [ITK-dev] SimpleITK Improvement Proposal - Refactor Superbuild for More External Projects Message-ID: Hello, To engage the SimpleITK user community in improving, guiding and evolving SimpleITK important changes will be proposed on the mailing list and on the Wiki for feedback. The first one has already begun, which is refactoring Superbuild structure of SimpleITK. http://www.itk.org/Wiki/SimpleITK/Design_And_Proposals/SIP_001 = SIP 001 - Refactor Superbuild for More External Projects = == Introduction == We wish to add additional external projects to the SimpleITK Superbuild to reduce inclusion of third party packages in the source tree, as well as to improve the build time and build configuration flexibility. This is based on the requests of system packagers to utilize the system packages and reduce the third-party libraries included in SimpleITK's source code. Additionally, we wish to build the SimpleITK common libraries once and then wrapping them multiple times. Specifically, we want to be able to wrap for multiple versions of Python without having to do a "dirty" build in the same build directory. == Remove Third-Parties Libraries == The third-party libraries of Lua and GTest are currently included in the SimpleITK source tree and distribution. These libraries shall be removed from the repository and become a dependency for the actual ( not Superbuild ) SimpleITK project. The requirements for Lua may come as a surprise to users who are currently not using the Superbuild. These users need to be encouraged to switch to using the SimpleITK Superbuild to provide the required dependencies. The Slicer 3D external project [https://github.com/Slicer/Slicer/blob/master/SuperBuild/External_SimpleITK.cmake script] for SimpleITK should serve as an example of how a build can be updated to use the Superbuild. Note: This item is already completed. JIRA Issue: [https://issues.itk.org/jira/browse/SIMPLEITK-652 SIMPLEITK-652] == Refactoring Wrapping for Modularity == The goal is to refactor the SWIG wrapping so that each wrapped language can be an independent project built against the SimpleITK project. Doing so will enable the Swig wrapping to occur either in the Superbuild level or in an additional project dependent on SimpleITK common libraries. This would enable wrapping for multiple versions of a language. The current CMake options for the wrapped languages will be maintained as part of the SimpleITK project, but it will not be enabled by default when the Superbuild is used. Instead they will be separate Superbuild projects. This new layout matches the installation and packaging pieces needed for system packagers because it has a clear separation of the SimpleITK common libraries and the wrapped languages. This separation enables the use of CMake/CPack install facility to install and package the SimpleITK common libraries and headers. The wrappings will have to be install and packaged according to the language conventions. Another benefit of this separation is that it should make work on a specific language more efficient. The SimpleITK common libraries will not need to be rebuilt at the wrapping level. This work be done in three phases: # Refractor the current ''Wrapping'' directory so that each language is in a separate sub-directory. # Revise each language so that it is a CMake "Project" which will depend on and ''use'' SimpleITK. # Refactor the code generation of the SimpleITK tests so that it can be used by the Wrapped language projects. # Update the Superbuild to disable wrapping in the SimpleITK project but create additional external projects for each wrapped language. From bill.lorensen at gmail.com Fri Oct 30 16:00:06 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 30 Oct 2015 16:00:06 -0400 Subject: [ITK-dev] ITKPerformanceBenchmarks Message-ID: I'm curious about the motivation for the subject work. I'll admit I have not reviewed all of the commits. How does this work differ from the existing timing support in ITK? https://github.com/InsightSoftwareConsortium/ITKPerformanceBenchmarks/pull/1 Do we need another way to measure timing or should we improve what we already have? Bill From matt.mccormick at kitware.com Fri Oct 30 16:30:20 2015 From: matt.mccormick at kitware.com (Matt McCormick) Date: Fri, 30 Oct 2015 16:30:20 -0400 Subject: [ITK-dev] ITKPerformanceBenchmarks In-Reply-To: References: Message-ID: Hi Bill, This work is based off work of Stephen and Sebastien as described here: http://www.na-mic.org/Wiki/index.php/User:Barre/ITK_Registration_Optimization Essentially, we get more accurate timing results when bumping up the operating system threads' and process' priority. Hyun Jae Kang is working on this, and we were discussing it this afternoon. The current plan for next steps is to refactor the generally re-usable support code, like the high-priority time probes, as an ITK External module while as it is being actively developed. Once the dust has settled, the path forward will be more clear. Maybe the improvements should be integrated into existing classes or maybe they should be made available in a Remote module. Thanks, Matt On Fri, Oct 30, 2015 at 4:00 PM, Bill Lorensen wrote: > I'm curious about the motivation for the subject work. I'll admit I > have not reviewed all of the commits. How does this work differ from > the existing timing support in ITK? > > https://github.com/InsightSoftwareConsortium/ITKPerformanceBenchmarks/pull/1 > > Do we need another way to measure timing or should we improve what we > already have? > > Bill > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Kitware offers ITK Training Courses, for more information visit: > http://kitware.com/products/protraining.php > > Please keep messages on-topic and check the ITK FAQ at: > http://www.itk.org/Wiki/ITK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/insight-developers From bill.lorensen at gmail.com Fri Oct 30 16:51:35 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 30 Oct 2015 16:51:35 -0400 Subject: [ITK-dev] ITKPerformanceBenchmarks In-Reply-To: References: Message-ID: Why can't these changes be made to our existing timing classes? On Fri, Oct 30, 2015 at 4:30 PM, Matt McCormick wrote: > Hi Bill, > > This work is based off work of Stephen and Sebastien as described here: > > http://www.na-mic.org/Wiki/index.php/User:Barre/ITK_Registration_Optimization > > Essentially, we get more accurate timing results when bumping up the > operating system threads' and process' priority. > > Hyun Jae Kang is working on this, and we were discussing it this > afternoon. The current plan for next steps is to refactor the > generally re-usable support code, like the high-priority time probes, > as an ITK External module while as it is being actively developed. > Once the dust has settled, the path forward will be more clear. Maybe > the improvements should be integrated into existing classes or maybe > they should be made available in a Remote module. > > Thanks, > Matt > > On Fri, Oct 30, 2015 at 4:00 PM, Bill Lorensen wrote: >> I'm curious about the motivation for the subject work. I'll admit I >> have not reviewed all of the commits. How does this work differ from >> the existing timing support in ITK? >> >> https://github.com/InsightSoftwareConsortium/ITKPerformanceBenchmarks/pull/1 >> >> Do we need another way to measure timing or should we improve what we >> already have? >> >> Bill >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Kitware offers ITK Training Courses, for more information visit: >> http://kitware.com/products/protraining.php >> >> Please keep messages on-topic and check the ITK FAQ at: >> http://www.itk.org/Wiki/ITK_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/insight-developers -- Unpaid intern in BillsBasement at noware dot com From matt.mccormick at kitware.com Fri Oct 30 16:54:12 2015 From: matt.mccormick at kitware.com (Matt McCormick) Date: Fri, 30 Oct 2015 16:54:12 -0400 Subject: [ITK-dev] ITKPerformanceBenchmarks In-Reply-To: References: Message-ID: The changes may be added to our existing classes after further development and testing. On Fri, Oct 30, 2015 at 4:51 PM, Bill Lorensen wrote: > Why can't these changes be made to our existing timing classes? > > > On Fri, Oct 30, 2015 at 4:30 PM, Matt McCormick > wrote: >> Hi Bill, >> >> This work is based off work of Stephen and Sebastien as described here: >> >> http://www.na-mic.org/Wiki/index.php/User:Barre/ITK_Registration_Optimization >> >> Essentially, we get more accurate timing results when bumping up the >> operating system threads' and process' priority. >> >> Hyun Jae Kang is working on this, and we were discussing it this >> afternoon. The current plan for next steps is to refactor the >> generally re-usable support code, like the high-priority time probes, >> as an ITK External module while as it is being actively developed. >> Once the dust has settled, the path forward will be more clear. Maybe >> the improvements should be integrated into existing classes or maybe >> they should be made available in a Remote module. >> >> Thanks, >> Matt >> >> On Fri, Oct 30, 2015 at 4:00 PM, Bill Lorensen wrote: >>> I'm curious about the motivation for the subject work. I'll admit I >>> have not reviewed all of the commits. How does this work differ from >>> the existing timing support in ITK? >>> >>> https://github.com/InsightSoftwareConsortium/ITKPerformanceBenchmarks/pull/1 >>> >>> Do we need another way to measure timing or should we improve what we >>> already have? >>> >>> Bill >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Kitware offers ITK Training Courses, for more information visit: >>> http://kitware.com/products/protraining.php >>> >>> Please keep messages on-topic and check the ITK FAQ at: >>> http://www.itk.org/Wiki/ITK_FAQ >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/insight-developers > > > > -- > Unpaid intern in BillsBasement at noware dot com From bill.lorensen at gmail.com Fri Oct 30 16:56:14 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 30 Oct 2015 16:56:14 -0400 Subject: [ITK-dev] ITKPerformanceBenchmarks In-Reply-To: References: Message-ID: Makes sense, Thanks On Fri, Oct 30, 2015 at 4:54 PM, Matt McCormick wrote: > The changes may be added to our existing classes after further > development and testing. > > On Fri, Oct 30, 2015 at 4:51 PM, Bill Lorensen wrote: >> Why can't these changes be made to our existing timing classes? >> >> >> On Fri, Oct 30, 2015 at 4:30 PM, Matt McCormick >> wrote: >>> Hi Bill, >>> >>> This work is based off work of Stephen and Sebastien as described here: >>> >>> http://www.na-mic.org/Wiki/index.php/User:Barre/ITK_Registration_Optimization >>> >>> Essentially, we get more accurate timing results when bumping up the >>> operating system threads' and process' priority. >>> >>> Hyun Jae Kang is working on this, and we were discussing it this >>> afternoon. The current plan for next steps is to refactor the >>> generally re-usable support code, like the high-priority time probes, >>> as an ITK External module while as it is being actively developed. >>> Once the dust has settled, the path forward will be more clear. Maybe >>> the improvements should be integrated into existing classes or maybe >>> they should be made available in a Remote module. >>> >>> Thanks, >>> Matt >>> >>> On Fri, Oct 30, 2015 at 4:00 PM, Bill Lorensen wrote: >>>> I'm curious about the motivation for the subject work. I'll admit I >>>> have not reviewed all of the commits. How does this work differ from >>>> the existing timing support in ITK? >>>> >>>> https://github.com/InsightSoftwareConsortium/ITKPerformanceBenchmarks/pull/1 >>>> >>>> Do we need another way to measure timing or should we improve what we >>>> already have? >>>> >>>> Bill >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Kitware offers ITK Training Courses, for more information visit: >>>> http://kitware.com/products/protraining.php >>>> >>>> Please keep messages on-topic and check the ITK FAQ at: >>>> http://www.itk.org/Wiki/ITK_FAQ >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/insight-developers >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com -- Unpaid intern in BillsBasement at noware dot com From bill.lorensen at gmail.com Sat Oct 31 12:47:27 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sat, 31 Oct 2015 12:47:27 -0400 Subject: [ITK-dev] CDash dashboards are messed up Message-ID: Take a look: https://open.cdash.org/index.php?project=VTK From bill.lorensen at gmail.com Sat Oct 31 12:59:16 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sat, 31 Oct 2015 12:59:16 -0400 Subject: [ITK-dev] CDash dashboards are messed up In-Reply-To: References: Message-ID: The messed up dashboards are using my Chrome browser. Firefox is OK. On Sat, Oct 31, 2015 at 12:47 PM, Bill Lorensen wrote: > Take a look: > https://open.cdash.org/index.php?project=VTK -- Unpaid intern in BillsBasement at noware dot com From zack.galbreath at kitware.com Sat Oct 31 13:10:15 2015 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Sat, 31 Oct 2015 13:10:15 -0400 Subject: [ITK-dev] CDash dashboards are messed up In-Reply-To: References: Message-ID: I was hoping to sneak in a CDash upgrade this morning while nobody was paying attention, but I guess I was only partially successful. I see that some fields aren't being properly colored, I'll work on fixing this soon. If the page isn't rendering for you at all, please refresh your cache and let me know if that doesn't fix things for you. We upgraded some Javascript files that your browser may have cached. I did my best to force clients to re-download these files, but I'm not sure if this trick will work for all possible browser/OS combinations. On Sat, Oct 31, 2015 at 12:59 PM, Bill Lorensen wrote: > The messed up dashboards are using my Chrome browser. > > Firefox is OK. > > > On Sat, Oct 31, 2015 at 12:47 PM, Bill Lorensen > wrote: > > Take a look: > > https://open.cdash.org/index.php?project=VTK > > > > -- > Unpaid intern in BillsBasement at noware dot com > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Kitware offers ITK Training Courses, for more information visit: > http://kitware.com/products/protraining.php > > Please keep messages on-topic and check the ITK FAQ at: > http://www.itk.org/Wiki/ITK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/insight-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Sat Oct 31 13:22:21 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sat, 31 Oct 2015 13:22:21 -0400 Subject: [ITK-dev] CDash dashboards are messed up In-Reply-To: References: Message-ID: I cleared my chrome cache and it is OK now, Except that it seems really slow... On Sat, Oct 31, 2015 at 1:10 PM, Zack Galbreath wrote: > I was hoping to sneak in a CDash upgrade this morning while nobody was > paying attention, but I guess I was only partially successful. I see that > some fields aren't being properly colored, I'll work on fixing this soon. > > If the page isn't rendering for you at all, please refresh your cache and > let me know if that doesn't fix things for you. We upgraded some Javascript > files that your browser may have cached. I did my best to force clients to > re-download these files, but I'm not sure if this trick will work for all > possible browser/OS combinations. > > > On Sat, Oct 31, 2015 at 12:59 PM, Bill Lorensen > wrote: >> >> The messed up dashboards are using my Chrome browser. >> >> Firefox is OK. >> >> >> On Sat, Oct 31, 2015 at 12:47 PM, Bill Lorensen >> wrote: >> > Take a look: >> > https://open.cdash.org/index.php?project=VTK >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Kitware offers ITK Training Courses, for more information visit: >> http://kitware.com/products/protraining.php >> >> Please keep messages on-topic and check the ITK FAQ at: >> http://www.itk.org/Wiki/ITK_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/insight-developers > > -- Unpaid intern in BillsBasement at noware dot com