From pieper at bwh.harvard.edu Mon Apr 5 14:02:12 2010 From: pieper at bwh.harvard.edu (Steve Pieper) Date: Mon, 05 Apr 2010 10:02:12 -0400 Subject: [Ctk-developers] Fwd: Re: [Nipy-devel] Switching to git; clarifying workflow Message-ID: <4BB9ED64.5090801@bwh.harvard.edu> here's a new feature that may really simplify the git transition for a lot of people... -------- Original Message -------- Subject: Re: [Nipy-devel] Switching to git; clarifying workflow Date: Mon, 5 Apr 2010 14:25:38 +0200 From: Gael Varoquaux Reply-To: nipy-devel at neuroimaging.scipy.org To: nipy-devel at neuroimaging.scipy.org Not really related to the conversation, but this is really cool: http://github.com/blog/626-announcing-svn-support It's not an april's fool joke, I tried it and it really works. It's really only for now, but for people simply used to tracking an SVN project without commit access, this enables the same workflow. Ga?l _______________________________________________ Nipy-devel mailing list Nipy-devel at neuroimaging.scipy.org http://mail.scipy.org/mailman/listinfo/nipy-devel From tarboxl at mir.wustl.edu Mon Apr 5 14:43:12 2010 From: tarboxl at mir.wustl.edu (Tarbox, Lawrence) Date: Mon, 5 Apr 2010 09:43:12 -0500 Subject: [Ctk-developers] Fwd: Re: [Nipy-devel] Switching to git; clarifying workflow In-Reply-To: <4BB9ED64.5090801@bwh.harvard.edu> References: <4BB9ED64.5090801@bwh.harvard.edu> Message-ID: <67B4B5166383D848A0565AA7491841F93082F068D0@RAD-VMSRVEXV2.rad.wustl.edu> Cute. I love the debate 'is it really permanent, or just a one day April Fool's joke.' -----Original Message----- From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Steve Pieper Sent: Monday, April 05, 2010 9:02 AM To: ctk-developers at commontk.org Subject: [Ctk-developers] Fwd: Re: [Nipy-devel] Switching to git; clarifying workflow here's a new feature that may really simplify the git transition for a lot of people... -------- Original Message -------- Subject: Re: [Nipy-devel] Switching to git; clarifying workflow Date: Mon, 5 Apr 2010 14:25:38 +0200 From: Gael Varoquaux Reply-To: nipy-devel at neuroimaging.scipy.org To: nipy-devel at neuroimaging.scipy.org Not really related to the conversation, but this is really cool: http://github.com/blog/626-announcing-svn-support It's not an april's fool joke, I tried it and it really works. It's really only for now, but for people simply used to tracking an SVN project without commit access, this enables the same workflow. Ga?l _______________________________________________ Nipy-devel mailing list Nipy-devel at neuroimaging.scipy.org http://mail.scipy.org/mailman/listinfo/nipy-devel _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers The material in this message is private and may contain Protected Healthcare Information (PHI). If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail. From luis.ibanez at kitware.com Thu Apr 8 14:07:12 2010 From: luis.ibanez at kitware.com (Luis Ibanez) Date: Thu, 8 Apr 2010 10:07:12 -0400 Subject: [Ctk-developers] How to create an accound in Trac ? Message-ID: I'm trying to create my account in Trac: http://www.commontk.org/cgi-bin/trac.cgi but can only find the "login" link and not a "register" link. Could you please let me know how to register ? Thanks Luis From luis.ibanez at kitware.com Thu Apr 8 14:23:56 2010 From: luis.ibanez at kitware.com (Luis Ibanez) Date: Thu, 8 Apr 2010 10:23:56 -0400 Subject: [Ctk-developers] Compilation error on: ui_ctkDICOMListenerWidget.h: No such file or directory Message-ID: I'm starting a build of CTK from scratch and ran into the following compilation below. It looks like a misconfiguration of a file that is supposed to be preprocessed by Qt. I will appreciate any advice on how to fix it, (This can be seen too in the Dashboard on the build from "eldorado.kitware"). Thanks, Luis ------------------------------------------ [ 20%] Built target QtMobility [ 40%] Built target DCMTK [ 60%] Built target CTK-Utilities [ 80%] Built target CTK-Configure [ 80%] Performing build step for 'CTK-build' [ 12%] Built target CTKCore [ 17%] Built target CTKCoreCxxTests [ 25%] Built target CTKWidgets [ 48%] Built target CTKDICOMCore [ 56%] Built target CTKDICOMCoreCxxTests [ 58%] Building CXX object Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/ctkDICOMListenerWidget.cxx.o /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx:4:39: error: ui_ctkDICOMListenerWidget.h: No such file or directory /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx:9: error: expected class-name before ?{? token /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx: In constructor ?ctkDICOMListenerWidget::ctkDICOMListenerWidget(QWidget*)?: /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx:27: error: ?class ctkDICOMListenerWidgetPrivate? has no member named ?setupUi? make[5]: *** [Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/ctkDICOMListenerWidget.cxx.o] Error 1 make[4]: *** [Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/all] Error 2 make[3]: *** [all] Error 2 make[2]: *** [CMakeExternals/Stamp/CTK-build/CTK-build-build] Error 2 make[1]: *** [CMakeFiles/CTK-build.dir/all] Error 2 make: *** [all] Error 2 From luis.ibanez at kitware.com Thu Apr 8 14:35:11 2010 From: luis.ibanez at kitware.com (Luis Ibanez) Date: Thu, 8 Apr 2010 10:35:11 -0400 Subject: [Ctk-developers] Compilation error on: ui_ctkDICOMListenerWidget.h: No such file or directory In-Reply-To: References: Message-ID: More on this, The offending file is actually generated in ./CTK-build/Libs/DICOM/Widgets/Resources/UI/ui_ctkDICOMListenerWidget.h but the directory: ./CTK-build/Libs/DICOM/Widgets/Resources/UI doesn't seem to be added to a CMake command INCLUDE_DIRECTORIES() Any hint on what will be the proper location for adding this command ? Thanks Luis -------------------------------------------------------------- On Thu, Apr 8, 2010 at 10:23 AM, Luis Ibanez wrote: > I'm starting a build of CTK from scratch > and ran into the following compilation below. > > It looks like a misconfiguration of a file that > is supposed to be preprocessed by Qt. > > I will appreciate any advice on how to fix it, > > (This can be seen too in the Dashboard on the > build from "eldorado.kitware"). > > > > ? ? ?Thanks, > > > ? ? ? ? ? Luis > > > ------------------------------------------ > [ 20%] Built target QtMobility > [ 40%] Built target DCMTK > [ 60%] Built target CTK-Utilities > [ 80%] Built target CTK-Configure > [ 80%] Performing build step for 'CTK-build' > [ 12%] Built target CTKCore > [ 17%] Built target CTKCoreCxxTests > [ 25%] Built target CTKWidgets > [ 48%] Built target CTKDICOMCore > [ 56%] Built target CTKDICOMCoreCxxTests > [ 58%] Building CXX object > Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/ctkDICOMListenerWidget.cxx.o > /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx:4:39: > error: ui_ctkDICOMListenerWidget.h: No such file or directory > /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx:9: > error: expected class-name before ?{? token > /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx: In > constructor ?ctkDICOMListenerWidget::ctkDICOMListenerWidget(QWidget*)?: > /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx:27: > error: ?class ctkDICOMListenerWidgetPrivate? has no member named > ?setupUi? > make[5]: *** [Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/ctkDICOMListenerWidget.cxx.o] > Error 1 > make[4]: *** [Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/all] Error 2 > make[3]: *** [all] Error 2 > make[2]: *** [CMakeExternals/Stamp/CTK-build/CTK-build-build] Error 2 > make[1]: *** [CMakeFiles/CTK-build.dir/all] Error 2 > make: *** [all] Error 2 > From luis.ibanez at kitware.com Thu Apr 8 14:38:57 2010 From: luis.ibanez at kitware.com (Luis Ibanez) Date: Thu, 8 Apr 2010 10:38:57 -0400 Subject: [Ctk-developers] Compilation error on: ui_ctkDICOMListenerWidget.h: No such file or directory In-Reply-To: References: Message-ID: The following patch seems to fix the problem: =========================================================== diff --git a/Libs/DICOM/Widgets/CMakeLists.txt b/Libs/DICOM/Widgets/CMakeLists.txt index 4c9670c..82a446e 100644 --- a/Libs/DICOM/Widgets/CMakeLists.txt +++ b/Libs/DICOM/Widgets/CMakeLists.txt @@ -8,6 +8,7 @@ SET(KIT_export_directive "CTK_DICOM_WIDGETS_EXPORT") # Additional directories to include SET(KIT_include_directories + ${CTKDICOMWidgets_BINARY_DIR}/Resources/UI ) # Source files ====================================================== Does anyone has an objection to the patch ? BTW: Any hint of why is that this compilation errors was not reported by other builds in the Dashboard ? Thanks Luis --------------------------------------------------------------- On Thu, Apr 8, 2010 at 10:35 AM, Luis Ibanez wrote: > More on this, > > The offending file is actually generated in > ./CTK-build/Libs/DICOM/Widgets/Resources/UI/ui_ctkDICOMListenerWidget.h > > but the directory: > ./CTK-build/Libs/DICOM/Widgets/Resources/UI > > doesn't seem to be added to a CMake command > > ? INCLUDE_DIRECTORIES() > > Any hint on what will be the proper location for > adding this command ? > > > ? ?Thanks > > > ? ? ? ? Luis > > > -------------------------------------------------------------- > On Thu, Apr 8, 2010 at 10:23 AM, Luis Ibanez wrote: >> I'm starting a build of CTK from scratch >> and ran into the following compilation below. >> >> It looks like a misconfiguration of a file that >> is supposed to be preprocessed by Qt. >> >> I will appreciate any advice on how to fix it, >> >> (This can be seen too in the Dashboard on the >> build from "eldorado.kitware"). >> >> >> >> ? ? ?Thanks, >> >> >> ? ? ? ? ? Luis >> >> >> ------------------------------------------ >> [ 20%] Built target QtMobility >> [ 40%] Built target DCMTK >> [ 60%] Built target CTK-Utilities >> [ 80%] Built target CTK-Configure >> [ 80%] Performing build step for 'CTK-build' >> [ 12%] Built target CTKCore >> [ 17%] Built target CTKCoreCxxTests >> [ 25%] Built target CTKWidgets >> [ 48%] Built target CTKDICOMCore >> [ 56%] Built target CTKDICOMCoreCxxTests >> [ 58%] Building CXX object >> Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/ctkDICOMListenerWidget.cxx.o >> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx:4:39: >> error: ui_ctkDICOMListenerWidget.h: No such file or directory >> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx:9: >> error: expected class-name before ?{? token >> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx: In >> constructor ?ctkDICOMListenerWidget::ctkDICOMListenerWidget(QWidget*)?: >> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx:27: >> error: ?class ctkDICOMListenerWidgetPrivate? has no member named >> ?setupUi? >> make[5]: *** [Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/ctkDICOMListenerWidget.cxx.o] >> Error 1 >> make[4]: *** [Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/all] Error 2 >> make[3]: *** [all] Error 2 >> make[2]: *** [CMakeExternals/Stamp/CTK-build/CTK-build-build] Error 2 >> make[1]: *** [CMakeFiles/CTK-build.dir/all] Error 2 >> make: *** [all] Error 2 >> > From julien.finet at kitware.com Thu Apr 8 14:41:00 2010 From: julien.finet at kitware.com (Julien Finet) Date: Thu, 8 Apr 2010 10:41:00 -0400 Subject: [Ctk-developers] Compilation error on: ui_ctkDICOMListenerWidget.h: No such file or directory In-Reply-To: References: Message-ID: Luis, For information, on my machine, the file ui_ctkDICOMListenerWidget.h is generated in CTKDICOMWidgets_BINARY_DIR and not in CTKDICOMWidgets_BINARY_DIR/Resources/UI Julien. On Thu, Apr 8, 2010 at 10:38 AM, Luis Ibanez wrote: > The following patch seems to fix the problem: > > > =========================================================== > > diff --git a/Libs/DICOM/Widgets/CMakeLists.txt > b/Libs/DICOM/Widgets/CMakeLists.txt > index 4c9670c..82a446e 100644 > --- a/Libs/DICOM/Widgets/CMakeLists.txt > +++ b/Libs/DICOM/Widgets/CMakeLists.txt > @@ -8,6 +8,7 @@ SET(KIT_export_directive "CTK_DICOM_WIDGETS_EXPORT") > > # Additional directories to include > SET(KIT_include_directories > + ${CTKDICOMWidgets_BINARY_DIR}/Resources/UI > ) > > # Source files > > ====================================================== > > > Does anyone has an objection to the patch ? > > > BTW: Any hint of why is that this compilation errors > was not reported by other builds in the Dashboard ? > > > Thanks > > > Luis > > > > --------------------------------------------------------------- > On Thu, Apr 8, 2010 at 10:35 AM, Luis Ibanez > wrote: > > More on this, > > > > The offending file is actually generated in > > ./CTK-build/Libs/DICOM/Widgets/Resources/UI/ui_ctkDICOMListenerWidget.h > > > > but the directory: > > ./CTK-build/Libs/DICOM/Widgets/Resources/UI > > > > doesn't seem to be added to a CMake command > > > > INCLUDE_DIRECTORIES() > > > > Any hint on what will be the proper location for > > adding this command ? > > > > > > Thanks > > > > > > Luis > > > > > > -------------------------------------------------------------- > > On Thu, Apr 8, 2010 at 10:23 AM, Luis Ibanez > wrote: > >> I'm starting a build of CTK from scratch > >> and ran into the following compilation below. > >> > >> It looks like a misconfiguration of a file that > >> is supposed to be preprocessed by Qt. > >> > >> I will appreciate any advice on how to fix it, > >> > >> (This can be seen too in the Dashboard on the > >> build from "eldorado.kitware"). > >> > >> > >> > >> Thanks, > >> > >> > >> Luis > >> > >> > >> ------------------------------------------ > >> [ 20%] Built target QtMobility > >> [ 40%] Built target DCMTK > >> [ 60%] Built target CTK-Utilities > >> [ 80%] Built target CTK-Configure > >> [ 80%] Performing build step for 'CTK-build' > >> [ 12%] Built target CTKCore > >> [ 17%] Built target CTKCoreCxxTests > >> [ 25%] Built target CTKWidgets > >> [ 48%] Built target CTKDICOMCore > >> [ 56%] Built target CTKDICOMCoreCxxTests > >> [ 58%] Building CXX object > >> > Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/ctkDICOMListenerWidget.cxx.o > >> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx:4:39: > >> error: ui_ctkDICOMListenerWidget.h: No such file or directory > >> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx:9: > >> error: expected class-name before ?{? token > >> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx: In > >> constructor ?ctkDICOMListenerWidget::ctkDICOMListenerWidget(QWidget*)?: > >> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx:27: > >> error: ?class ctkDICOMListenerWidgetPrivate? has no member named > >> ?setupUi? > >> make[5]: *** > [Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/ctkDICOMListenerWidget.cxx.o] > >> Error 1 > >> make[4]: *** [Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/all] > Error 2 > >> make[3]: *** [all] Error 2 > >> make[2]: *** [CMakeExternals/Stamp/CTK-build/CTK-build-build] Error 2 > >> make[1]: *** [CMakeFiles/CTK-build.dir/all] Error 2 > >> make: *** [all] Error 2 > >> > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.aylward at kitware.com Thu Apr 8 14:30:40 2010 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Thu, 8 Apr 2010 10:30:40 -0400 Subject: [Ctk-developers] How to create an accound in Trac ? In-Reply-To: References: Message-ID: We need to remove the trac installation and switch to a standard MediaWiki installation. I'll ask Matt to do it. s On Thu, Apr 8, 2010 at 10:07 AM, Luis Ibanez wrote: > I'm trying to create my account in Trac: > http://www.commontk.org/cgi-bin/trac.cgi > > but can only find the "login" link and not a "register" link. > > Could you please let me know how to register ? > > > ? ?Thanks > > > ? ? ? ?Luis > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From arnaud_gelas at hms.harvard.edu Thu Apr 8 15:01:32 2010 From: arnaud_gelas at hms.harvard.edu (Arnaud Gelas) Date: Thu, 8 Apr 2010 11:01:32 -0400 Subject: [Ctk-developers] Compilation error on: ui_ctkDICOMListenerWidget.h: No such file or directory In-Reply-To: References: Message-ID: <5A8D8AC6-E0F6-4F54-9897-67BCDFEFF3BC@hms.harvard.edu> Hi Luis, I had a similar problem some time back. It seemed that I was not using the right cmake version. Which cmake version are you using? Arnaud On Apr 8, 2010, at 10:41 AM, Julien Finet wrote: > Luis, > > For information, on my machine, the file ui_ctkDICOMListenerWidget.h > is generated in CTKDICOMWidgets_BINARY_DIR and not in > CTKDICOMWidgets_BINARY_DIR/Resources/UI > Julien. > > On Thu, Apr 8, 2010 at 10:38 AM, Luis Ibanez > wrote: > The following patch seems to fix the problem: > > > =========================================================== > > diff --git a/Libs/DICOM/Widgets/CMakeLists.txt > b/Libs/DICOM/Widgets/CMakeLists.txt > index 4c9670c..82a446e 100644 > --- a/Libs/DICOM/Widgets/CMakeLists.txt > +++ b/Libs/DICOM/Widgets/CMakeLists.txt > @@ -8,6 +8,7 @@ SET(KIT_export_directive "CTK_DICOM_WIDGETS_EXPORT") > > # Additional directories to include > SET(KIT_include_directories > + ${CTKDICOMWidgets_BINARY_DIR}/Resources/UI > ) > > # Source files > > ====================================================== > > > Does anyone has an objection to the patch ? > > > BTW: Any hint of why is that this compilation errors > was not reported by other builds in the Dashboard ? > > > Thanks > > > Luis > > > > --------------------------------------------------------------- > On Thu, Apr 8, 2010 at 10:35 AM, Luis Ibanez > wrote: > > More on this, > > > > The offending file is actually generated in > > ./CTK-build/Libs/DICOM/Widgets/Resources/UI/ > ui_ctkDICOMListenerWidget.h > > > > but the directory: > > ./CTK-build/Libs/DICOM/Widgets/Resources/UI > > > > doesn't seem to be added to a CMake command > > > > INCLUDE_DIRECTORIES() > > > > Any hint on what will be the proper location for > > adding this command ? > > > > > > Thanks > > > > > > Luis > > > > > > -------------------------------------------------------------- > > On Thu, Apr 8, 2010 at 10:23 AM, Luis Ibanez > wrote: > >> I'm starting a build of CTK from scratch > >> and ran into the following compilation below. > >> > >> It looks like a misconfiguration of a file that > >> is supposed to be preprocessed by Qt. > >> > >> I will appreciate any advice on how to fix it, > >> > >> (This can be seen too in the Dashboard on the > >> build from "eldorado.kitware"). > >> > >> > >> > >> Thanks, > >> > >> > >> Luis > >> > >> > >> ------------------------------------------ > >> [ 20%] Built target QtMobility > >> [ 40%] Built target DCMTK > >> [ 60%] Built target CTK-Utilities > >> [ 80%] Built target CTK-Configure > >> [ 80%] Performing build step for 'CTK-build' > >> [ 12%] Built target CTKCore > >> [ 17%] Built target CTKCoreCxxTests > >> [ 25%] Built target CTKWidgets > >> [ 48%] Built target CTKDICOMCore > >> [ 56%] Built target CTKDICOMCoreCxxTests > >> [ 58%] Building CXX object > >> Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/ > ctkDICOMListenerWidget.cxx.o > >> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ > ctkDICOMListenerWidget.cxx:4:39: > >> error: ui_ctkDICOMListenerWidget.h: No such file or directory > >> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ > ctkDICOMListenerWidget.cxx:9: > >> error: expected class-name before ?{? token > >> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ > ctkDICOMListenerWidget.cxx: In > >> constructor > ?ctkDICOMListenerWidget::ctkDICOMListenerWidget(QWidget*)?: > >> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ > ctkDICOMListenerWidget.cxx:27: > >> error: ?class ctkDICOMListenerWidgetPrivate? has no member named > >> ?setupUi? > >> make[5]: *** [Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/ > ctkDICOMListenerWidget.cxx.o] > >> Error 1 > >> make[4]: *** [Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/ > all] Error 2 > >> make[3]: *** [all] Error 2 > >> make[2]: *** [CMakeExternals/Stamp/CTK-build/CTK-build-build] > Error 2 > >> make[1]: *** [CMakeFiles/CTK-build.dir/all] Error 2 > >> make: *** [all] Error 2 > >> > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luis.ibanez at kitware.com Thu Apr 8 15:09:54 2010 From: luis.ibanez at kitware.com (Luis Ibanez) Date: Thu, 8 Apr 2010 11:09:54 -0400 Subject: [Ctk-developers] Compilation error on: ui_ctkDICOMListenerWidget.h: No such file or directory In-Reply-To: <5A8D8AC6-E0F6-4F54-9897-67BCDFEFF3BC@hms.harvard.edu> References: <5A8D8AC6-E0F6-4F54-9897-67BCDFEFF3BC@hms.harvard.edu> Message-ID: I'm using a CMake built out of the CMake-git repository as it was on March 25th 2010 at 11:01am Eastern. Is that too new ? or too old ? What is the recommended version of CMake to use ? If there is a requirement for a specific version of CMake, we probably should put that in the top CMakeLists.txt file, The current one says: CMAKE_MINIMUM_REQUIRED(VERSION 2.8) It looks like we are missing a Wiki page with build instructions.... Thanks for any hint, Luis --------------------------------------------------- On Thu, Apr 8, 2010 at 11:01 AM, Arnaud Gelas wrote: > Hi Luis, > I had a similar problem some time back. It seemed that I was not using the > right cmake version. > Which cmake version are you using? > Arnaud > On Apr 8, 2010, at 10:41 AM, Julien Finet wrote: > > Luis, > For information, on my machine, the file ui_ctkDICOMListenerWidget.h is > generated in?CTKDICOMWidgets_BINARY_DIR and not > in?CTKDICOMWidgets_BINARY_DIR/Resources/UI > Julien. > > On Thu, Apr 8, 2010 at 10:38 AM, Luis Ibanez > wrote: >> >> The following patch seems to fix the problem: >> >> >> =========================================================== >> >> diff --git a/Libs/DICOM/Widgets/CMakeLists.txt >> b/Libs/DICOM/Widgets/CMakeLists.txt >> index 4c9670c..82a446e 100644 >> --- a/Libs/DICOM/Widgets/CMakeLists.txt >> +++ b/Libs/DICOM/Widgets/CMakeLists.txt >> @@ -8,6 +8,7 @@ SET(KIT_export_directive "CTK_DICOM_WIDGETS_EXPORT") >> >> ?# Additional directories to include >> ?SET(KIT_include_directories >> + ?${CTKDICOMWidgets_BINARY_DIR}/Resources/UI >> ? ) >> >> ?# Source files >> >> ====================================================== >> >> >> Does anyone has an objection to the patch ? >> >> >> BTW: ?Any hint of why is that this compilation errors >> was not reported by other builds in the Dashboard ? >> >> >> ? ? ?Thanks >> >> >> ? ? ? ? ? Luis >> >> >> >> --------------------------------------------------------------- >> On Thu, Apr 8, 2010 at 10:35 AM, Luis Ibanez >> wrote: >> > More on this, >> > >> > The offending file is actually generated in >> > ./CTK-build/Libs/DICOM/Widgets/Resources/UI/ui_ctkDICOMListenerWidget.h >> > >> > but the directory: >> > ./CTK-build/Libs/DICOM/Widgets/Resources/UI >> > >> > doesn't seem to be added to a CMake command >> > >> > ? INCLUDE_DIRECTORIES() >> > >> > Any hint on what will be the proper location for >> > adding this command ? >> > >> > >> > ? ?Thanks >> > >> > >> > ? ? ? ? Luis >> > >> > >> > -------------------------------------------------------------- >> > On Thu, Apr 8, 2010 at 10:23 AM, Luis Ibanez >> > wrote: >> >> I'm starting a build of CTK from scratch >> >> and ran into the following compilation below. >> >> >> >> It looks like a misconfiguration of a file that >> >> is supposed to be preprocessed by Qt. >> >> >> >> I will appreciate any advice on how to fix it, >> >> >> >> (This can be seen too in the Dashboard on the >> >> build from "eldorado.kitware"). >> >> >> >> >> >> >> >> ? ? ?Thanks, >> >> >> >> >> >> ? ? ? ? ? Luis >> >> >> >> >> >> ------------------------------------------ >> >> [ 20%] Built target QtMobility >> >> [ 40%] Built target DCMTK >> >> [ 60%] Built target CTK-Utilities >> >> [ 80%] Built target CTK-Configure >> >> [ 80%] Performing build step for 'CTK-build' >> >> [ 12%] Built target CTKCore >> >> [ 17%] Built target CTKCoreCxxTests >> >> [ 25%] Built target CTKWidgets >> >> [ 48%] Built target CTKDICOMCore >> >> [ 56%] Built target CTKDICOMCoreCxxTests >> >> [ 58%] Building CXX object >> >> >> >> Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/ctkDICOMListenerWidget.cxx.o >> >> >> >> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx:4:39: >> >> error: ui_ctkDICOMListenerWidget.h: No such file or directory >> >> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx:9: >> >> error: expected class-name before ?{? token >> >> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx: In >> >> constructor ?ctkDICOMListenerWidget::ctkDICOMListenerWidget(QWidget*)?: >> >> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx:27: >> >> error: ?class ctkDICOMListenerWidgetPrivate? has no member named >> >> ?setupUi? >> >> make[5]: *** >> >> [Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/ctkDICOMListenerWidget.cxx.o] >> >> Error 1 >> >> make[4]: *** [Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/all] >> >> Error 2 >> >> make[3]: *** [all] Error 2 >> >> make[2]: *** [CMakeExternals/Stamp/CTK-build/CTK-build-build] Error 2 >> >> make[1]: *** [CMakeFiles/CTK-build.dir/all] Error 2 >> >> make: *** [all] Error 2 >> >> >> > >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > > From Arnaud_Gelas at hms.harvard.edu Thu Apr 8 15:14:42 2010 From: Arnaud_Gelas at hms.harvard.edu (Arnaud Gelas) Date: Thu, 8 Apr 2010 11:14:42 -0400 Subject: [Ctk-developers] Compilation error on: ui_ctkDICOMListenerWidget.h: No such file or directory In-Reply-To: References: <5A8D8AC6-E0F6-4F54-9897-67BCDFEFF3BC@hms.harvard.edu> Message-ID: On Apr 8, 2010, at 11:09 AM, Luis Ibanez wrote: > I'm using a CMake built out of the CMake-git repository > as it was on March 25th 2010 at 11:01am Eastern. > > > Is that too new ? or too old ? > > What is the recommended version of CMake to use ? I am not in front of my desktop now to check which version I did end up using (I am in a meeting...) > > > If there is a requirement for a specific version of CMake, > we probably should put that in the top CMakeLists.txt file, > > The current one says: > > CMAKE_MINIMUM_REQUIRED(VERSION 2.8) > > > > It looks like we are missing a Wiki page with build > instructions.... Definitively!!! The trac's one? the github's one? > > > > Thanks for any hint, > > > Luis > > > --------------------------------------------------- > On Thu, Apr 8, 2010 at 11:01 AM, Arnaud Gelas > wrote: >> Hi Luis, >> I had a similar problem some time back. It seemed that I was not >> using the >> right cmake version. >> Which cmake version are you using? >> Arnaud >> On Apr 8, 2010, at 10:41 AM, Julien Finet wrote: >> >> Luis, >> For information, on my machine, the file >> ui_ctkDICOMListenerWidget.h is >> generated in CTKDICOMWidgets_BINARY_DIR and not >> in CTKDICOMWidgets_BINARY_DIR/Resources/UI >> Julien. >> >> On Thu, Apr 8, 2010 at 10:38 AM, Luis Ibanez >> >> wrote: >>> >>> The following patch seems to fix the problem: >>> >>> >>> =========================================================== >>> >>> diff --git a/Libs/DICOM/Widgets/CMakeLists.txt >>> b/Libs/DICOM/Widgets/CMakeLists.txt >>> index 4c9670c..82a446e 100644 >>> --- a/Libs/DICOM/Widgets/CMakeLists.txt >>> +++ b/Libs/DICOM/Widgets/CMakeLists.txt >>> @@ -8,6 +8,7 @@ SET(KIT_export_directive "CTK_DICOM_WIDGETS_EXPORT") >>> >>> # Additional directories to include >>> SET(KIT_include_directories >>> + ${CTKDICOMWidgets_BINARY_DIR}/Resources/UI >>> ) >>> >>> # Source files >>> >>> ====================================================== >>> >>> >>> Does anyone has an objection to the patch ? >>> >>> >>> BTW: Any hint of why is that this compilation errors >>> was not reported by other builds in the Dashboard ? >>> >>> >>> Thanks >>> >>> >>> Luis >>> >>> >>> >>> --------------------------------------------------------------- >>> On Thu, Apr 8, 2010 at 10:35 AM, Luis Ibanez >> > >>> wrote: >>>> More on this, >>>> >>>> The offending file is actually generated in >>>> ./CTK-build/Libs/DICOM/Widgets/Resources/UI/ >>>> ui_ctkDICOMListenerWidget.h >>>> >>>> but the directory: >>>> ./CTK-build/Libs/DICOM/Widgets/Resources/UI >>>> >>>> doesn't seem to be added to a CMake command >>>> >>>> INCLUDE_DIRECTORIES() >>>> >>>> Any hint on what will be the proper location for >>>> adding this command ? >>>> >>>> >>>> Thanks >>>> >>>> >>>> Luis >>>> >>>> >>>> -------------------------------------------------------------- >>>> On Thu, Apr 8, 2010 at 10:23 AM, Luis Ibanez >>> > >>>> wrote: >>>>> I'm starting a build of CTK from scratch >>>>> and ran into the following compilation below. >>>>> >>>>> It looks like a misconfiguration of a file that >>>>> is supposed to be preprocessed by Qt. >>>>> >>>>> I will appreciate any advice on how to fix it, >>>>> >>>>> (This can be seen too in the Dashboard on the >>>>> build from "eldorado.kitware"). >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> >>>>> Luis >>>>> >>>>> >>>>> ------------------------------------------ >>>>> [ 20%] Built target QtMobility >>>>> [ 40%] Built target DCMTK >>>>> [ 60%] Built target CTK-Utilities >>>>> [ 80%] Built target CTK-Configure >>>>> [ 80%] Performing build step for 'CTK-build' >>>>> [ 12%] Built target CTKCore >>>>> [ 17%] Built target CTKCoreCxxTests >>>>> [ 25%] Built target CTKWidgets >>>>> [ 48%] Built target CTKDICOMCore >>>>> [ 56%] Built target CTKDICOMCoreCxxTests >>>>> [ 58%] Building CXX object >>>>> >>>>> Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/ >>>>> ctkDICOMListenerWidget.cxx.o >>>>> >>>>> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ >>>>> ctkDICOMListenerWidget.cxx:4:39: >>>>> error: ui_ctkDICOMListenerWidget.h: No such file or directory >>>>> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ >>>>> ctkDICOMListenerWidget.cxx:9: >>>>> error: expected class-name before ?{? token >>>>> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ >>>>> ctkDICOMListenerWidget.cxx: In >>>>> constructor >>>>> ?ctkDICOMListenerWidget::ctkDICOMListenerWidget(QWidget*)?: >>>>> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ >>>>> ctkDICOMListenerWidget.cxx:27: >>>>> error: ?class ctkDICOMListenerWidgetPrivate? has no member named >>>>> ?setupUi? >>>>> make[5]: *** >>>>> [Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/ >>>>> ctkDICOMListenerWidget.cxx.o] >>>>> Error 1 >>>>> make[4]: *** [Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/ >>>>> all] >>>>> Error 2 >>>>> make[3]: *** [all] Error 2 >>>>> make[2]: *** [CMakeExternals/Stamp/CTK-build/CTK-build-build] >>>>> Error 2 >>>>> make[1]: *** [CMakeFiles/CTK-build.dir/all] Error 2 >>>>> make: *** [all] Error 2 >>>>> >>>> >>> _______________________________________________ >>> Ctk-developers mailing list >>> Ctk-developers at commontk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> >> From julien.finet at kitware.com Thu Apr 8 15:19:32 2010 From: julien.finet at kitware.com (Julien Finet) Date: Thu, 8 Apr 2010 11:19:32 -0400 Subject: [Ctk-developers] Compilation error on: ui_ctkDICOMListenerWidget.h: No such file or directory In-Reply-To: References: <5A8D8AC6-E0F6-4F54-9897-67BCDFEFF3BC@hms.harvard.edu> Message-ID: I'm using CMake 2.8.1... and it works for me... Maybe we should fix the pb for more recent CMake versions. J. On Thu, Apr 8, 2010 at 11:09 AM, Luis Ibanez wrote: > I'm using a CMake built out of the CMake-git repository > as it was on March 25th 2010 at 11:01am Eastern. > > > Is that too new ? or too old ? > > What is the recommended version of CMake to use ? > > > If there is a requirement for a specific version of CMake, > we probably should put that in the top CMakeLists.txt file, > > The current one says: > > CMAKE_MINIMUM_REQUIRED(VERSION 2.8) > > > > It looks like we are missing a Wiki page with build > instructions.... > > > > Thanks for any hint, > > > Luis > > > --------------------------------------------------- > On Thu, Apr 8, 2010 at 11:01 AM, Arnaud Gelas > wrote: > > Hi Luis, > > I had a similar problem some time back. It seemed that I was not using > the > > right cmake version. > > Which cmake version are you using? > > Arnaud > > On Apr 8, 2010, at 10:41 AM, Julien Finet wrote: > > > > Luis, > > For information, on my machine, the file ui_ctkDICOMListenerWidget.h is > > generated in CTKDICOMWidgets_BINARY_DIR and not > > in CTKDICOMWidgets_BINARY_DIR/Resources/UI > > Julien. > > > > On Thu, Apr 8, 2010 at 10:38 AM, Luis Ibanez > > wrote: > >> > >> The following patch seems to fix the problem: > >> > >> > >> =========================================================== > >> > >> diff --git a/Libs/DICOM/Widgets/CMakeLists.txt > >> b/Libs/DICOM/Widgets/CMakeLists.txt > >> index 4c9670c..82a446e 100644 > >> --- a/Libs/DICOM/Widgets/CMakeLists.txt > >> +++ b/Libs/DICOM/Widgets/CMakeLists.txt > >> @@ -8,6 +8,7 @@ SET(KIT_export_directive "CTK_DICOM_WIDGETS_EXPORT") > >> > >> # Additional directories to include > >> SET(KIT_include_directories > >> + ${CTKDICOMWidgets_BINARY_DIR}/Resources/UI > >> ) > >> > >> # Source files > >> > >> ====================================================== > >> > >> > >> Does anyone has an objection to the patch ? > >> > >> > >> BTW: Any hint of why is that this compilation errors > >> was not reported by other builds in the Dashboard ? > >> > >> > >> Thanks > >> > >> > >> Luis > >> > >> > >> > >> --------------------------------------------------------------- > >> On Thu, Apr 8, 2010 at 10:35 AM, Luis Ibanez > >> wrote: > >> > More on this, > >> > > >> > The offending file is actually generated in > >> > > ./CTK-build/Libs/DICOM/Widgets/Resources/UI/ui_ctkDICOMListenerWidget.h > >> > > >> > but the directory: > >> > ./CTK-build/Libs/DICOM/Widgets/Resources/UI > >> > > >> > doesn't seem to be added to a CMake command > >> > > >> > INCLUDE_DIRECTORIES() > >> > > >> > Any hint on what will be the proper location for > >> > adding this command ? > >> > > >> > > >> > Thanks > >> > > >> > > >> > Luis > >> > > >> > > >> > -------------------------------------------------------------- > >> > On Thu, Apr 8, 2010 at 10:23 AM, Luis Ibanez > > >> > wrote: > >> >> I'm starting a build of CTK from scratch > >> >> and ran into the following compilation below. > >> >> > >> >> It looks like a misconfiguration of a file that > >> >> is supposed to be preprocessed by Qt. > >> >> > >> >> I will appreciate any advice on how to fix it, > >> >> > >> >> (This can be seen too in the Dashboard on the > >> >> build from "eldorado.kitware"). > >> >> > >> >> > >> >> > >> >> Thanks, > >> >> > >> >> > >> >> Luis > >> >> > >> >> > >> >> ------------------------------------------ > >> >> [ 20%] Built target QtMobility > >> >> [ 40%] Built target DCMTK > >> >> [ 60%] Built target CTK-Utilities > >> >> [ 80%] Built target CTK-Configure > >> >> [ 80%] Performing build step for 'CTK-build' > >> >> [ 12%] Built target CTKCore > >> >> [ 17%] Built target CTKCoreCxxTests > >> >> [ 25%] Built target CTKWidgets > >> >> [ 48%] Built target CTKDICOMCore > >> >> [ 56%] Built target CTKDICOMCoreCxxTests > >> >> [ 58%] Building CXX object > >> >> > >> >> > Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/ctkDICOMListenerWidget.cxx.o > >> >> > >> >> > /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx:4:39: > >> >> error: ui_ctkDICOMListenerWidget.h: No such file or directory > >> >> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx:9: > >> >> error: expected class-name before ?{? token > >> >> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx: > In > >> >> constructor > ?ctkDICOMListenerWidget::ctkDICOMListenerWidget(QWidget*)?: > >> >> > /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx:27: > >> >> error: ?class ctkDICOMListenerWidgetPrivate? has no member named > >> >> ?setupUi? > >> >> make[5]: *** > >> >> > [Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/ctkDICOMListenerWidget.cxx.o] > >> >> Error 1 > >> >> make[4]: *** [Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/all] > >> >> Error 2 > >> >> make[3]: *** [all] Error 2 > >> >> make[2]: *** [CMakeExternals/Stamp/CTK-build/CTK-build-build] Error 2 > >> >> make[1]: *** [CMakeFiles/CTK-build.dir/all] Error 2 > >> >> make: *** [all] Error 2 > >> >> > >> > > >> _______________________________________________ > >> Ctk-developers mailing list > >> Ctk-developers at commontk.org > >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.finet at kitware.com Thu Apr 8 15:32:31 2010 From: julien.finet at kitware.com (Julien Finet) Date: Thu, 8 Apr 2010 11:32:31 -0400 Subject: [Ctk-developers] Compilation error on: ui_ctkDICOMListenerWidget.h: No such file or directory In-Reply-To: References: <5A8D8AC6-E0F6-4F54-9897-67BCDFEFF3BC@hms.harvard.edu> Message-ID: It depends if it is a bug in CMake or if it's a new feature :-) j. On Thu, Apr 8, 2010 at 11:26 AM, Luis Ibanez wrote: > Thanks Julien, > > so, > > is this something to be fixed in CTK ? > > or > > is this something to be fixed in the development version of CMake ? > > > Thanks > > > Luis > > > > ------------------------------------------------------------------------------- > On Thu, Apr 8, 2010 at 11:19 AM, Julien Finet > wrote: > > I'm using CMake 2.8.1... and it works for me... Maybe we should fix the > pb > > for more recent CMake versions. > > J. > > > > On Thu, Apr 8, 2010 at 11:09 AM, Luis Ibanez > > wrote: > >> > >> I'm using a CMake built out of the CMake-git repository > >> as it was on March 25th 2010 at 11:01am Eastern. > >> > >> > >> Is that too new ? or too old ? > >> > >> What is the recommended version of CMake to use ? > >> > >> > >> If there is a requirement for a specific version of CMake, > >> we probably should put that in the top CMakeLists.txt file, > >> > >> The current one says: > >> > >> CMAKE_MINIMUM_REQUIRED(VERSION 2.8) > >> > >> > >> > >> It looks like we are missing a Wiki page with build > >> instructions.... > >> > >> > >> > >> Thanks for any hint, > >> > >> > >> Luis > >> > >> > >> --------------------------------------------------- > >> On Thu, Apr 8, 2010 at 11:01 AM, Arnaud Gelas > >> wrote: > >> > Hi Luis, > >> > I had a similar problem some time back. It seemed that I was not using > >> > the > >> > right cmake version. > >> > Which cmake version are you using? > >> > Arnaud > >> > On Apr 8, 2010, at 10:41 AM, Julien Finet wrote: > >> > > >> > Luis, > >> > For information, on my machine, the file ui_ctkDICOMListenerWidget.h > is > >> > generated in CTKDICOMWidgets_BINARY_DIR and not > >> > in CTKDICOMWidgets_BINARY_DIR/Resources/UI > >> > Julien. > >> > > >> > On Thu, Apr 8, 2010 at 10:38 AM, Luis Ibanez > > >> > wrote: > >> >> > >> >> The following patch seems to fix the problem: > >> >> > >> >> > >> >> =========================================================== > >> >> > >> >> diff --git a/Libs/DICOM/Widgets/CMakeLists.txt > >> >> b/Libs/DICOM/Widgets/CMakeLists.txt > >> >> index 4c9670c..82a446e 100644 > >> >> --- a/Libs/DICOM/Widgets/CMakeLists.txt > >> >> +++ b/Libs/DICOM/Widgets/CMakeLists.txt > >> >> @@ -8,6 +8,7 @@ SET(KIT_export_directive "CTK_DICOM_WIDGETS_EXPORT") > >> >> > >> >> # Additional directories to include > >> >> SET(KIT_include_directories > >> >> + ${CTKDICOMWidgets_BINARY_DIR}/Resources/UI > >> >> ) > >> >> > >> >> # Source files > >> >> > >> >> ====================================================== > >> >> > >> >> > >> >> Does anyone has an objection to the patch ? > >> >> > >> >> > >> >> BTW: Any hint of why is that this compilation errors > >> >> was not reported by other builds in the Dashboard ? > >> >> > >> >> > >> >> Thanks > >> >> > >> >> > >> >> Luis > >> >> > >> >> > >> >> > >> >> --------------------------------------------------------------- > >> >> On Thu, Apr 8, 2010 at 10:35 AM, Luis Ibanez < > luis.ibanez at kitware.com> > >> >> wrote: > >> >> > More on this, > >> >> > > >> >> > The offending file is actually generated in > >> >> > > >> >> > > ./CTK-build/Libs/DICOM/Widgets/Resources/UI/ui_ctkDICOMListenerWidget.h > >> >> > > >> >> > but the directory: > >> >> > ./CTK-build/Libs/DICOM/Widgets/Resources/UI > >> >> > > >> >> > doesn't seem to be added to a CMake command > >> >> > > >> >> > INCLUDE_DIRECTORIES() > >> >> > > >> >> > Any hint on what will be the proper location for > >> >> > adding this command ? > >> >> > > >> >> > > >> >> > Thanks > >> >> > > >> >> > > >> >> > Luis > >> >> > > >> >> > > >> >> > -------------------------------------------------------------- > >> >> > On Thu, Apr 8, 2010 at 10:23 AM, Luis Ibanez > >> >> > > >> >> > wrote: > >> >> >> I'm starting a build of CTK from scratch > >> >> >> and ran into the following compilation below. > >> >> >> > >> >> >> It looks like a misconfiguration of a file that > >> >> >> is supposed to be preprocessed by Qt. > >> >> >> > >> >> >> I will appreciate any advice on how to fix it, > >> >> >> > >> >> >> (This can be seen too in the Dashboard on the > >> >> >> build from "eldorado.kitware"). > >> >> >> > >> >> >> > >> >> >> > >> >> >> Thanks, > >> >> >> > >> >> >> > >> >> >> Luis > >> >> >> > >> >> >> > >> >> >> ------------------------------------------ > >> >> >> [ 20%] Built target QtMobility > >> >> >> [ 40%] Built target DCMTK > >> >> >> [ 60%] Built target CTK-Utilities > >> >> >> [ 80%] Built target CTK-Configure > >> >> >> [ 80%] Performing build step for 'CTK-build' > >> >> >> [ 12%] Built target CTKCore > >> >> >> [ 17%] Built target CTKCoreCxxTests > >> >> >> [ 25%] Built target CTKWidgets > >> >> >> [ 48%] Built target CTKDICOMCore > >> >> >> [ 56%] Built target CTKDICOMCoreCxxTests > >> >> >> [ 58%] Building CXX object > >> >> >> > >> >> >> > >> >> >> > Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/ctkDICOMListenerWidget.cxx.o > >> >> >> > >> >> >> > >> >> >> > /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx:4:39: > >> >> >> error: ui_ctkDICOMListenerWidget.h: No such file or directory > >> >> >> > >> >> >> > /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx:9: > >> >> >> error: expected class-name before ?{? token > >> >> >> > /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx: > >> >> >> In > >> >> >> constructor > >> >> >> ?ctkDICOMListenerWidget::ctkDICOMListenerWidget(QWidget*)?: > >> >> >> > >> >> >> > /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx:27: > >> >> >> error: ?class ctkDICOMListenerWidgetPrivate? has no member named > >> >> >> ?setupUi? > >> >> >> make[5]: *** > >> >> >> > >> >> >> > [Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/ctkDICOMListenerWidget.cxx.o] > >> >> >> Error 1 > >> >> >> make[4]: *** > [Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/all] > >> >> >> Error 2 > >> >> >> make[3]: *** [all] Error 2 > >> >> >> make[2]: *** [CMakeExternals/Stamp/CTK-build/CTK-build-build] > Error > >> >> >> 2 > >> >> >> make[1]: *** [CMakeFiles/CTK-build.dir/all] Error 2 > >> >> >> make: *** [all] Error 2 > >> >> >> > >> >> > > >> >> _______________________________________________ > >> >> Ctk-developers mailing list > >> >> Ctk-developers at commontk.org > >> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > >> > > >> > > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luis.ibanez at kitware.com Thu Apr 8 15:26:37 2010 From: luis.ibanez at kitware.com (Luis Ibanez) Date: Thu, 8 Apr 2010 11:26:37 -0400 Subject: [Ctk-developers] Compilation error on: ui_ctkDICOMListenerWidget.h: No such file or directory In-Reply-To: References: <5A8D8AC6-E0F6-4F54-9897-67BCDFEFF3BC@hms.harvard.edu> Message-ID: Thanks Julien, so, is this something to be fixed in CTK ? or is this something to be fixed in the development version of CMake ? Thanks Luis ------------------------------------------------------------------------------- On Thu, Apr 8, 2010 at 11:19 AM, Julien Finet wrote: > I'm using CMake 2.8.1... and it works for me... Maybe we should fix the pb > for more recent CMake versions. > J. > > On Thu, Apr 8, 2010 at 11:09 AM, Luis Ibanez > wrote: >> >> I'm using a CMake built out of the CMake-git repository >> as it was on March 25th 2010 at 11:01am Eastern. >> >> >> ? ? ? ? ? ? Is that too new ? or too old ? >> >> What is the recommended version of CMake to use ? >> >> >> If there is a requirement for a specific version of CMake, >> we probably should put that in the top CMakeLists.txt file, >> >> The current one says: >> >> ? ? CMAKE_MINIMUM_REQUIRED(VERSION 2.8) >> >> >> >> It looks like we are missing a Wiki page with build >> instructions.... >> >> >> >> ? ? ?Thanks for any hint, >> >> >> ? ? ? ? ? ?Luis >> >> >> --------------------------------------------------- >> On Thu, Apr 8, 2010 at 11:01 AM, Arnaud Gelas >> wrote: >> > Hi Luis, >> > I had a similar problem some time back. It seemed that I was not using >> > the >> > right cmake version. >> > Which cmake version are you using? >> > Arnaud >> > On Apr 8, 2010, at 10:41 AM, Julien Finet wrote: >> > >> > Luis, >> > For information, on my machine, the file ui_ctkDICOMListenerWidget.h is >> > generated in?CTKDICOMWidgets_BINARY_DIR and not >> > in?CTKDICOMWidgets_BINARY_DIR/Resources/UI >> > Julien. >> > >> > On Thu, Apr 8, 2010 at 10:38 AM, Luis Ibanez >> > wrote: >> >> >> >> The following patch seems to fix the problem: >> >> >> >> >> >> =========================================================== >> >> >> >> diff --git a/Libs/DICOM/Widgets/CMakeLists.txt >> >> b/Libs/DICOM/Widgets/CMakeLists.txt >> >> index 4c9670c..82a446e 100644 >> >> --- a/Libs/DICOM/Widgets/CMakeLists.txt >> >> +++ b/Libs/DICOM/Widgets/CMakeLists.txt >> >> @@ -8,6 +8,7 @@ SET(KIT_export_directive "CTK_DICOM_WIDGETS_EXPORT") >> >> >> >> ?# Additional directories to include >> >> ?SET(KIT_include_directories >> >> + ?${CTKDICOMWidgets_BINARY_DIR}/Resources/UI >> >> ? ) >> >> >> >> ?# Source files >> >> >> >> ====================================================== >> >> >> >> >> >> Does anyone has an objection to the patch ? >> >> >> >> >> >> BTW: ?Any hint of why is that this compilation errors >> >> was not reported by other builds in the Dashboard ? >> >> >> >> >> >> ? ? ?Thanks >> >> >> >> >> >> ? ? ? ? ? Luis >> >> >> >> >> >> >> >> --------------------------------------------------------------- >> >> On Thu, Apr 8, 2010 at 10:35 AM, Luis Ibanez >> >> wrote: >> >> > More on this, >> >> > >> >> > The offending file is actually generated in >> >> > >> >> > ./CTK-build/Libs/DICOM/Widgets/Resources/UI/ui_ctkDICOMListenerWidget.h >> >> > >> >> > but the directory: >> >> > ./CTK-build/Libs/DICOM/Widgets/Resources/UI >> >> > >> >> > doesn't seem to be added to a CMake command >> >> > >> >> > ? INCLUDE_DIRECTORIES() >> >> > >> >> > Any hint on what will be the proper location for >> >> > adding this command ? >> >> > >> >> > >> >> > ? ?Thanks >> >> > >> >> > >> >> > ? ? ? ? Luis >> >> > >> >> > >> >> > -------------------------------------------------------------- >> >> > On Thu, Apr 8, 2010 at 10:23 AM, Luis Ibanez >> >> > >> >> > wrote: >> >> >> I'm starting a build of CTK from scratch >> >> >> and ran into the following compilation below. >> >> >> >> >> >> It looks like a misconfiguration of a file that >> >> >> is supposed to be preprocessed by Qt. >> >> >> >> >> >> I will appreciate any advice on how to fix it, >> >> >> >> >> >> (This can be seen too in the Dashboard on the >> >> >> build from "eldorado.kitware"). >> >> >> >> >> >> >> >> >> >> >> >> ? ? ?Thanks, >> >> >> >> >> >> >> >> >> ? ? ? ? ? Luis >> >> >> >> >> >> >> >> >> ------------------------------------------ >> >> >> [ 20%] Built target QtMobility >> >> >> [ 40%] Built target DCMTK >> >> >> [ 60%] Built target CTK-Utilities >> >> >> [ 80%] Built target CTK-Configure >> >> >> [ 80%] Performing build step for 'CTK-build' >> >> >> [ 12%] Built target CTKCore >> >> >> [ 17%] Built target CTKCoreCxxTests >> >> >> [ 25%] Built target CTKWidgets >> >> >> [ 48%] Built target CTKDICOMCore >> >> >> [ 56%] Built target CTKDICOMCoreCxxTests >> >> >> [ 58%] Building CXX object >> >> >> >> >> >> >> >> >> Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/ctkDICOMListenerWidget.cxx.o >> >> >> >> >> >> >> >> >> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx:4:39: >> >> >> error: ui_ctkDICOMListenerWidget.h: No such file or directory >> >> >> >> >> >> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx:9: >> >> >> error: expected class-name before ?{? token >> >> >> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx: >> >> >> In >> >> >> constructor >> >> >> ?ctkDICOMListenerWidget::ctkDICOMListenerWidget(QWidget*)?: >> >> >> >> >> >> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx:27: >> >> >> error: ?class ctkDICOMListenerWidgetPrivate? has no member named >> >> >> ?setupUi? >> >> >> make[5]: *** >> >> >> >> >> >> [Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/ctkDICOMListenerWidget.cxx.o] >> >> >> Error 1 >> >> >> make[4]: *** [Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/all] >> >> >> Error 2 >> >> >> make[3]: *** [all] Error 2 >> >> >> make[2]: *** [CMakeExternals/Stamp/CTK-build/CTK-build-build] Error >> >> >> 2 >> >> >> make[1]: *** [CMakeFiles/CTK-build.dir/all] Error 2 >> >> >> make: *** [all] Error 2 >> >> >> >> >> > >> >> _______________________________________________ >> >> Ctk-developers mailing list >> >> Ctk-developers at commontk.org >> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> > >> > >> > > > From julien.finet at kitware.com Thu Apr 8 14:44:59 2010 From: julien.finet at kitware.com (Julien Finet) Date: Thu, 8 Apr 2010 10:44:59 -0400 Subject: [Ctk-developers] Compilation error on: ui_ctkDICOMListenerWidget.h: No such file or directory In-Reply-To: References: Message-ID: If you have to modify the build configuration, I guess the best place to do it would be in CTK/CMake/ctkMacroBuildQtLib.cmake Julien On Thu, Apr 8, 2010 at 10:38 AM, Luis Ibanez wrote: > The following patch seems to fix the problem: > > > =========================================================== > > diff --git a/Libs/DICOM/Widgets/CMakeLists.txt > b/Libs/DICOM/Widgets/CMakeLists.txt > index 4c9670c..82a446e 100644 > --- a/Libs/DICOM/Widgets/CMakeLists.txt > +++ b/Libs/DICOM/Widgets/CMakeLists.txt > @@ -8,6 +8,7 @@ SET(KIT_export_directive "CTK_DICOM_WIDGETS_EXPORT") > > # Additional directories to include > SET(KIT_include_directories > + ${CTKDICOMWidgets_BINARY_DIR}/Resources/UI > ) > > # Source files > > ====================================================== > > > Does anyone has an objection to the patch ? > > > BTW: Any hint of why is that this compilation errors > was not reported by other builds in the Dashboard ? > > > Thanks > > > Luis > > > > --------------------------------------------------------------- > On Thu, Apr 8, 2010 at 10:35 AM, Luis Ibanez > wrote: > > More on this, > > > > The offending file is actually generated in > > ./CTK-build/Libs/DICOM/Widgets/Resources/UI/ui_ctkDICOMListenerWidget.h > > > > but the directory: > > ./CTK-build/Libs/DICOM/Widgets/Resources/UI > > > > doesn't seem to be added to a CMake command > > > > INCLUDE_DIRECTORIES() > > > > Any hint on what will be the proper location for > > adding this command ? > > > > > > Thanks > > > > > > Luis > > > > > > -------------------------------------------------------------- > > On Thu, Apr 8, 2010 at 10:23 AM, Luis Ibanez > wrote: > >> I'm starting a build of CTK from scratch > >> and ran into the following compilation below. > >> > >> It looks like a misconfiguration of a file that > >> is supposed to be preprocessed by Qt. > >> > >> I will appreciate any advice on how to fix it, > >> > >> (This can be seen too in the Dashboard on the > >> build from "eldorado.kitware"). > >> > >> > >> > >> Thanks, > >> > >> > >> Luis > >> > >> > >> ------------------------------------------ > >> [ 20%] Built target QtMobility > >> [ 40%] Built target DCMTK > >> [ 60%] Built target CTK-Utilities > >> [ 80%] Built target CTK-Configure > >> [ 80%] Performing build step for 'CTK-build' > >> [ 12%] Built target CTKCore > >> [ 17%] Built target CTKCoreCxxTests > >> [ 25%] Built target CTKWidgets > >> [ 48%] Built target CTKDICOMCore > >> [ 56%] Built target CTKDICOMCoreCxxTests > >> [ 58%] Building CXX object > >> > Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/ctkDICOMListenerWidget.cxx.o > >> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx:4:39: > >> error: ui_ctkDICOMListenerWidget.h: No such file or directory > >> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx:9: > >> error: expected class-name before ?{? token > >> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx: In > >> constructor ?ctkDICOMListenerWidget::ctkDICOMListenerWidget(QWidget*)?: > >> /home/ibanez/src/CTK/Libs/DICOM/Widgets/ctkDICOMListenerWidget.cxx:27: > >> error: ?class ctkDICOMListenerWidgetPrivate? has no member named > >> ?setupUi? > >> make[5]: *** > [Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/ctkDICOMListenerWidget.cxx.o] > >> Error 1 > >> make[4]: *** [Libs/DICOM/Widgets/CMakeFiles/CTKDICOMWidgets.dir/all] > Error 2 > >> make[3]: *** [all] Error 2 > >> make[2]: *** [CMakeExternals/Stamp/CTK-build/CTK-build-build] Error 2 > >> make[1]: *** [CMakeFiles/CTK-build.dir/all] Error 2 > >> make: *** [all] Error 2 > >> > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luis.ibanez at kitware.com Thu Apr 8 17:58:31 2010 From: luis.ibanez at kitware.com (Luis Ibanez) Date: Thu, 8 Apr 2010 13:58:31 -0400 Subject: [Ctk-developers] CTK Dasboard: Low Code Coverage : 42% .and. 608 Valgrind Errors. Message-ID: The CTK Dasboard is in need of some Though Love. A) Code Coverage: 42% http://my.cdash.org/viewCoverage.php?buildid=57880 B) 608 Valgring Errors http://my.cdash.org/viewDynamicAnalysis.php?buildid=57892 We must fix this before the Hackaton. It will be a disaster to have a lot of new code to be put inside a repository with a weak testing infrastructure. Any volunteer for adopting the orphan classes ? ./Libs/Core/ctkDependencyGraph.h ./Libs/DICOM/Core/ctkDICOMIndexer.cxx ./Libs/Core/ctkDependencyGraph.cxx ./Libs/Core/ctkModelTester.cxx Many of the memory leaks seems to come from : ==9718== at 0x4C25153: malloc (vg_replace_malloc.c:195) ==9718== by 0x75331A1: strdup (strdup.c:43) ==9718== by 0x89F0C49: IceRegisterForProtocolSetup (in /usr/lib/libICE.so.6.3.0) Any reason for using the old strdup instead of using "std::string" ? Finally, There are no Windows nor Mac builds in the Dashboard... Any volunteers for setting up additional builds ? Luis From julien.finet at kitware.com Thu Apr 8 18:10:16 2010 From: julien.finet at kitware.com (Julien Finet) Date: Thu, 8 Apr 2010 14:10:16 -0400 Subject: [Ctk-developers] CTK Dasboard: Low Code Coverage : 42% .and. 608 Valgrind Errors. In-Reply-To: References: Message-ID: Agree, let's test it all ! :-) I already have a test ready (in Slicer) for ctkModelTester. I like testing testers. I can also look at ctkDICOMIndexer.cxx, but I'd probably need some help from Marco... Julien. On Thu, Apr 8, 2010 at 1:58 PM, Luis Ibanez wrote: > The CTK Dasboard is in need of some Though Love. > > > A) Code Coverage: 42% > http://my.cdash.org/viewCoverage.php?buildid=57880 > > > B) 608 Valgring Errors > http://my.cdash.org/viewDynamicAnalysis.php?buildid=57892 > > > We must fix this before the Hackaton. > > > It will be a disaster to have a lot of new code to be put > inside a repository with a weak testing infrastructure. > > > Any volunteer for adopting the orphan classes ? > > ./Libs/Core/ctkDependencyGraph.h > ./Libs/DICOM/Core/ctkDICOMIndexer.cxx > ./Libs/Core/ctkDependencyGraph.cxx > ./Libs/Core/ctkModelTester.cxx > > > > Many of the memory leaks seems to come from : > > ==9718== at 0x4C25153: malloc (vg_replace_malloc.c:195) > ==9718== by 0x75331A1: strdup (strdup.c:43) > ==9718== by 0x89F0C49: IceRegisterForProtocolSetup (in > /usr/lib/libICE.so.6.3.0) > > > Any reason for using the old strdup instead > of using "std::string" ? > > > Finally, > > There are no Windows nor Mac builds in the Dashboard... > > Any volunteers for setting up additional builds ? > > > > Luis > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luis.ibanez at kitware.com Thu Apr 8 21:14:34 2010 From: luis.ibanez at kitware.com (Luis Ibanez) Date: Thu, 8 Apr 2010 17:14:34 -0400 Subject: [Ctk-developers] CTK Dashboard: Cleaning up Warnings: DCMTK Message-ID: In the process of cleaning up warnings in the Dashboard, we ran into issues with DCMTK: CMakeExternals/Install/include/dcmtk/oflog/spi/logevent.h warning: declaration of ?message? shadows a member of 'this' warning: declaration of ?ll? shadows a member of 'this' Given that DCMTK is a third party library, our options for fixing this are: A) Post a patch to the DCMTK developers and wait for them to push that into a release B) Host a duplicate repository of DCMTK and make the patches there C) Silence the warning using CTestCustom.cmake (put the problem under the rug..) What are your preferences ? Thanks Luis From luis.ibanez at kitware.com Thu Apr 8 21:24:38 2010 From: luis.ibanez at kitware.com (Luis Ibanez) Date: Thu, 8 Apr 2010 17:24:38 -0400 Subject: [Ctk-developers] CTK Dashboard: Cleaning up Warnings: DCMTK In-Reply-To: References: Message-ID: Excellent, Here they are: /home/ibanez/bin/CTK/Debug/CMakeExternals/Install/include/dcmtk/oflog/spi/logevent.h: In constructor ?log4cplus::spi::InternalLoggingEvent::InternalLoggingEvent(const log4cplus::tstring&, log4cplus::LogLevel, const log4cplus::tstring&, const char*, int)?: /home/ibanez/bin/CTK/Debug/CMakeExternals/Install/include/dcmtk/oflog/spi/logevent.h:56: warning: declaration of ?line? shadows a member of 'this' /home/ibanez/bin/CTK/Debug/CMakeExternals/Install/include/dcmtk/oflog/spi/logevent.h:56: warning: declaration of ?message? shadows a member of 'this' /home/ibanez/bin/CTK/Debug/CMakeExternals/Install/include/dcmtk/oflog/spi/logevent.h:56: warning: declaration of ?ll? shadows a member of 'this' /home/ibanez/bin/CTK/Debug/CMakeExternals/Install/include/dcmtk/oflog/spi/logevent.h: In constructor ?log4cplus::spi::InternalLoggingEvent::InternalLoggingEvent(const log4cplus::tstring&, log4cplus::LogLevel, const log4cplus::tstring&, const log4cplus::tstring&, const log4cplus::tstring&, log4cplus::helpers::Time, const log4cplus::tstring&, int)?: /home/ibanez/bin/CTK/Debug/CMakeExternals/Install/include/dcmtk/oflog/spi/logevent.h:79: warning: declaration of ?line? shadows a member of 'this' /home/ibanez/bin/CTK/Debug/CMakeExternals/Install/include/dcmtk/oflog/spi/logevent.h:79: warning: declaration of ?file? shadows a member of 'this' /home/ibanez/bin/CTK/Debug/CMakeExternals/Install/include/dcmtk/oflog/spi/logevent.h:79: warning: declaration of ?thread? shadows a member of 'this' /home/ibanez/bin/CTK/Debug/CMakeExternals/Install/include/dcmtk/oflog/spi/logevent.h:79: warning: declaration of ?message? shadows a member of 'this' /home/ibanez/bin/CTK/Debug/CMakeExternals/Install/include/dcmtk/oflog/spi/logevent.h:79: warning: declaration of ?ndc? shadows a member of 'this' /home/ibanez/bin/CTK/Debug/CMakeExternals/Install/include/dcmtk/oflog/spi/logevent.h:79: warning: declaration of ?ll? shadows a member of 'this' Luis On Thu, Apr 8, 2010 at 5:22 PM, Stephen Aylward wrote: > The DCMTK folks are key participants in CTK. > > I'm guessing they can fix those... > > s > > On Thu, Apr 8, 2010 at 5:14 PM, Luis Ibanez wrote: >> In the process of cleaning up warnings in the Dashboard, >> we ran into issues with DCMTK: >> >> CMakeExternals/Install/include/dcmtk/oflog/spi/logevent.h >> >> ?warning: declaration of ?message? shadows a member of 'this' >> ?warning: declaration of ?ll? shadows a member of 'this' >> >> >> Given that DCMTK is a third party library, our options for >> fixing this are: >> >> >> A) Post a patch to the DCMTK developers and wait for >> ? ? them to push that into a release >> >> B) Host a duplicate repository of DCMTK and make the >> ? ?patches there >> >> C) Silence the warning using CTestCustom.cmake >> ? ? (put the problem under the rug..) >> >> >> >> ?What are your preferences ? >> >> >> ? ? ?Thanks >> >> >> ? ? ? ? ?Luis >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> > > > > -- > Stephen R. Aylward, Ph.D. > Director of Medical Imaging Research > Kitware, Inc. - North Carolina Office > http://www.kitware.com > stephen.aylward (Skype) > (919) 969-6990 x300 > From stephen.aylward at kitware.com Thu Apr 8 21:22:00 2010 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Thu, 8 Apr 2010 17:22:00 -0400 Subject: [Ctk-developers] CTK Dashboard: Cleaning up Warnings: DCMTK In-Reply-To: References: Message-ID: The DCMTK folks are key participants in CTK. I'm guessing they can fix those... s On Thu, Apr 8, 2010 at 5:14 PM, Luis Ibanez wrote: > In the process of cleaning up warnings in the Dashboard, > we ran into issues with DCMTK: > > CMakeExternals/Install/include/dcmtk/oflog/spi/logevent.h > > ?warning: declaration of ?message? shadows a member of 'this' > ?warning: declaration of ?ll? shadows a member of 'this' > > > Given that DCMTK is a third party library, our options for > fixing this are: > > > A) Post a patch to the DCMTK developers and wait for > ? ? them to push that into a release > > B) Host a duplicate repository of DCMTK and make the > ? ?patches there > > C) Silence the warning using CTestCustom.cmake > ? ? (put the problem under the rug..) > > > > ?What are your preferences ? > > > ? ? ?Thanks > > > ? ? ? ? ?Luis > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From julien.finet at kitware.com Thu Apr 8 21:23:23 2010 From: julien.finet at kitware.com (Julien Finet) Date: Thu, 8 Apr 2010 17:23:23 -0400 Subject: [Ctk-developers] CTK Dashboard: Cleaning up Warnings: DCMTK In-Reply-To: References: Message-ID: Hi Luis, In CTK/Utilities we have a local version of DCMTK that we cmakeified. My vote goes to fix the warnings into directly into the CTK repository. Julien. On Thu, Apr 8, 2010 at 5:14 PM, Luis Ibanez wrote: > In the process of cleaning up warnings in the Dashboard, > we ran into issues with DCMTK: > > CMakeExternals/Install/include/dcmtk/oflog/spi/logevent.h > > warning: declaration of ?message? shadows a member of 'this' > warning: declaration of ?ll? shadows a member of 'this' > > > Given that DCMTK is a third party library, our options for > fixing this are: > > > A) Post a patch to the DCMTK developers and wait for > them to push that into a release > > B) Host a duplicate repository of DCMTK and make the > patches there > > C) Silence the warning using CTestCustom.cmake > (put the problem under the rug..) > > > > What are your preferences ? > > > Thanks > > > Luis > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luis.ibanez at kitware.com Thu Apr 8 21:38:43 2010 From: luis.ibanez at kitware.com (Luis Ibanez) Date: Thu, 8 Apr 2010 17:38:43 -0400 Subject: [Ctk-developers] CTK Dashboard: Cleaning up Warnings: DCMTK In-Reply-To: References: Message-ID: On Thu, Apr 8, 2010 at 5:23 PM, Julien Finet wrote: > Hi Luis, > In CTK/Utilities we have a local version of DCMTK that we cmakeified. > My vote goes to fix the warnings into directly into the CTK repository. > Julien. > ---------------------------------------------------------------------------------------- That works too. I just committed the fixes to: CTK/Utilities/DCMTK/oflog/include/dcmtk/oflog/spi/logevent.h We will avoid many problems if we agree on using a similar collection of Warning flags for the machines that submit to the Dashboard. For GCC we should at least have: -Wall -Wshadow -Wno-uninitialized Luis --------------------------------------------------------------- > On Thu, Apr 8, 2010 at 5:14 PM, Luis Ibanez wrote: >> >> In the process of cleaning up warnings in the Dashboard, >> we ran into issues with DCMTK: >> >> CMakeExternals/Install/include/dcmtk/oflog/spi/logevent.h >> >> ?warning: declaration of ?message? shadows a member of 'this' >> ?warning: declaration of ?ll? shadows a member of 'this' >> >> >> Given that DCMTK is a third party library, our options for >> fixing this are: >> >> >> A) Post a patch to the DCMTK developers and wait for >> ? ? them to push that into a release >> >> B) Host a duplicate repository of DCMTK and make the >> ? ?patches there >> >> C) Silence the warning using CTestCustom.cmake >> ? ? (put the problem under the rug..) >> >> >> >> ?What are your preferences ? >> >> >> ? ? ?Thanks >> >> >> ? ? ? ? ?Luis >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > From luis.ibanez at kitware.com Thu Apr 8 21:50:45 2010 From: luis.ibanez at kitware.com (Luis Ibanez) Date: Thu, 8 Apr 2010 17:50:45 -0400 Subject: [Ctk-developers] Libs/DICOM/Core/ctkDICOMModel.cxx : variables names with same naming as method names Message-ID: I recall that at some point we discussed a naming convention for Qt-like classes, but I'm not sure if we arrived to a consensus. The file: Libs/DICOM/Core/ctkDICOMModel.cxx had an abundant use of local variables with names matching some member variables and member methods. A notable example: "index" I just committed a fix for most of them, but for the long run it will be great if we agree on some naming convention. I would vote against having a method of a C++ class to be called "index()" for example. :-) a more useful name will be "getIndex()", for example, or in this particular case, it looks like what the function is actually doing is generating an index, so good names could be ctkDICOMModel::generatgeIndex ( int row, int column, const QModelIndex & parentValue ) const or ctkDICOMModel::computeIndex ( int row, int column, const QModelIndex & parentValue ) const or ctkDICOMModel::produceIndex ( int row, int column, const QModelIndex & parentValue ) const There is already another createIndex(int, int, Node *) so it will be fine if we use ctkDICOMModel::createIndex ( int row, int column, const QModelIndex & parentValue ) const since the signature will be different. --- Do we have a document on coding style ? if we do, we probably should setup KWStyle testing before things get out of control. Luis From julien.finet at kitware.com Thu Apr 8 22:08:07 2010 From: julien.finet at kitware.com (Julien Finet) Date: Thu, 8 Apr 2010 18:08:07 -0400 Subject: [Ctk-developers] Libs/DICOM/Core/ctkDICOMModel.cxx : variables names with same naming as method names In-Reply-To: References: Message-ID: Hi Luis, I understand your concern. We can't change the name of the method index() as it is a virtual method that has been declared in a Qt subclass. And the problem we face here is that the Qt library doesn't care about shadow variables. (and if I recall, they didn't plan on changing that). We unofficially decided during the CTK Pre Hackfest that a CTK class should follow the naming convention of its derived class, Qt in this example. Is that still OK for everybody ? Setting up KWStyle seems like a good idea. Can we configure it in a way to check a style depending on a filename (ideally the style of the derived class) Julien. On Thu, Apr 8, 2010 at 5:50 PM, Luis Ibanez wrote: > I recall that at some point we discussed a > naming convention for Qt-like classes, but > I'm not sure if we arrived to a consensus. > > > The file: > > Libs/DICOM/Core/ctkDICOMModel.cxx > > had an abundant use of local variables with > names matching some member variables and > member methods. > > A notable example: > > "index" > > I just committed a fix for most of them, > but for the long run it will be great if we > agree on some naming convention. > > I would vote against having a method of a C++ class > to be called "index()" for example. :-) > > a more useful name will be "getIndex()", for example, > or in this particular case, it looks like what the function > is actually doing is generating an index, so good names > could be > > ctkDICOMModel::generatgeIndex ( int row, int column, const QModelIndex > & parentValue ) const > > or > > ctkDICOMModel::computeIndex ( int row, int column, const QModelIndex & > parentValue ) const > > or > > ctkDICOMModel::produceIndex ( int row, int column, const QModelIndex & > parentValue ) const > > > There is already another > > createIndex(int, int, Node *) > > > so it will be fine if we use > > ctkDICOMModel::createIndex ( int row, int column, const QModelIndex & > parentValue ) const > > since the signature will be different. > > > --- > > > Do we have a document on coding style ? > > if we do, > we probably should setup KWStyle testing > before things get out of control. > > > > Luis > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luis.ibanez at kitware.com Thu Apr 8 22:15:43 2010 From: luis.ibanez at kitware.com (Luis Ibanez) Date: Thu, 8 Apr 2010 18:15:43 -0400 Subject: [Ctk-developers] Libs/DICOM/Core/ctkDICOMModel.cxx : variables names with same naming as method names In-Reply-To: References: Message-ID: I see, It is too bad that Qt got satisfied with a lower quality bar. We can still avoid having local variables with the same names as member variables and member methods. For example, many of the offending warnings were fixed by replacing ambiguousvariablename with ambiguousvariablenameValue we could have as well used the more arcane ambiguousvariablename_ Making good choices on names of methods, and variables is a an effective way of documenting the code. Luis ----------------------------------------------------------------------------------- On Thu, Apr 8, 2010 at 6:08 PM, Julien Finet wrote: > Hi Luis, > I understand your concern. > We can't change the name of the method index() as it is a virtual method > that has been declared in a Qt subclass. > And the problem we face here is that the Qt library doesn't care about > shadow variables. (and if I recall, they didn't plan on changing that). > We unofficially decided during the CTK Pre Hackfest that a CTK class should > follow the naming convention of its derived class, Qt in this example. > Is that still OK for everybody ? > Setting up KWStyle seems like a good idea. Can we configure it in a way to > check a style depending on a filename (ideally the style of the derived > class) > Julien. > On Thu, Apr 8, 2010 at 5:50 PM, Luis Ibanez wrote: >> >> I recall that at some point we discussed a >> naming convention for Qt-like classes, but >> I'm not sure if we arrived to a consensus. >> >> >> The file: >> >> ?Libs/DICOM/Core/ctkDICOMModel.cxx >> >> had an abundant use of local variables with >> names matching some member variables and >> member methods. >> >> A notable example: >> >> ? ? ? ? ? ? ? ? ? ? ? "index" >> >> I just committed a fix for most of them, >> but for the long run it will be great if we >> agree on some naming convention. >> >> I would vote against having a method of a C++ class >> to be called "index()" for example. ? ? ? :-) >> >> a more useful name will be "getIndex()", for example, >> or in this particular case, it looks like what the function >> is actually doing is generating an index, so good names >> could be >> >> ctkDICOMModel::generatgeIndex ( int row, int column, const QModelIndex >> & parentValue ) const >> >> or >> >> ctkDICOMModel::computeIndex ( int row, int column, const QModelIndex & >> parentValue ) const >> >> or >> >> ctkDICOMModel::produceIndex ( int row, int column, const QModelIndex & >> parentValue ) const >> >> >> There is already another >> >> ? ? ? ? ? ? ? ?createIndex(int, int, Node *) >> >> >> so it will be fine if we use >> >> ctkDICOMModel::createIndex ( int row, int column, const QModelIndex & >> parentValue ) const >> >> since the signature will be different. >> >> >> --- >> >> >> Do we have a document on coding style ? >> >> if we do, >> we probably should setup KWStyle testing >> before things get out of control. >> >> >> >> ? ? ?Luis > > From julien.finet at kitware.com Thu Apr 8 22:31:39 2010 From: julien.finet at kitware.com (Julien Finet) Date: Thu, 8 Apr 2010 18:31:39 -0400 Subject: [Ctk-developers] Libs/DICOM/Core/ctkDICOMModel.cxx : variables names with same naming as method names In-Reply-To: References: Message-ID: Agree, I'm not a big fan of the 2 solutions you gave though. When I remember to avoid variable shadowing, I have a couple of tricks to rename problematic variables: for example a variable named "row" could be renamed as: - indexRow / itemRow / cellRow / childRow / parentRow ( who owns the variable) - rowToInsert/rowToDelete (action on the variable) - newRow / oldRow / tmpRow ( lifetime of the variable) - .... There is almost always one prefix or suffix that can be added and gives more information about the variable. Julien. On Thu, Apr 8, 2010 at 6:15 PM, Luis Ibanez wrote: > I see, > > It is too bad that Qt got satisfied with a lower quality bar. > > > We can still avoid having local variables with the same > names as member variables and member methods. > > For example, > many of the offending warnings were fixed by replacing > > ambiguousvariablename > > with > > ambiguousvariablenameValue > > we could have as well used the more arcane > > ambiguousvariablename_ > > > Making good choices on names of methods, and variables > is a an effective way of documenting the code. > > > Luis > > > > ----------------------------------------------------------------------------------- > On Thu, Apr 8, 2010 at 6:08 PM, Julien Finet > wrote: > > Hi Luis, > > I understand your concern. > > We can't change the name of the method index() as it is a virtual method > > that has been declared in a Qt subclass. > > And the problem we face here is that the Qt library doesn't care about > > shadow variables. (and if I recall, they didn't plan on changing that). > > We unofficially decided during the CTK Pre Hackfest that a CTK class > should > > follow the naming convention of its derived class, Qt in this example. > > Is that still OK for everybody ? > > Setting up KWStyle seems like a good idea. Can we configure it in a way > to > > check a style depending on a filename (ideally the style of the derived > > class) > > Julien. > > On Thu, Apr 8, 2010 at 5:50 PM, Luis Ibanez > wrote: > >> > >> I recall that at some point we discussed a > >> naming convention for Qt-like classes, but > >> I'm not sure if we arrived to a consensus. > >> > >> > >> The file: > >> > >> Libs/DICOM/Core/ctkDICOMModel.cxx > >> > >> had an abundant use of local variables with > >> names matching some member variables and > >> member methods. > >> > >> A notable example: > >> > >> "index" > >> > >> I just committed a fix for most of them, > >> but for the long run it will be great if we > >> agree on some naming convention. > >> > >> I would vote against having a method of a C++ class > >> to be called "index()" for example. :-) > >> > >> a more useful name will be "getIndex()", for example, > >> or in this particular case, it looks like what the function > >> is actually doing is generating an index, so good names > >> could be > >> > >> ctkDICOMModel::generatgeIndex ( int row, int column, const QModelIndex > >> & parentValue ) const > >> > >> or > >> > >> ctkDICOMModel::computeIndex ( int row, int column, const QModelIndex & > >> parentValue ) const > >> > >> or > >> > >> ctkDICOMModel::produceIndex ( int row, int column, const QModelIndex & > >> parentValue ) const > >> > >> > >> There is already another > >> > >> createIndex(int, int, Node *) > >> > >> > >> so it will be fine if we use > >> > >> ctkDICOMModel::createIndex ( int row, int column, const QModelIndex & > >> parentValue ) const > >> > >> since the signature will be different. > >> > >> > >> --- > >> > >> > >> Do we have a document on coding style ? > >> > >> if we do, > >> we probably should setup KWStyle testing > >> before things get out of control. > >> > >> > >> > >> Luis > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luis.ibanez at kitware.com Thu Apr 8 22:43:39 2010 From: luis.ibanez at kitware.com (Luis Ibanez) Date: Thu, 8 Apr 2010 18:43:39 -0400 Subject: [Ctk-developers] Libs/DICOM/Core/ctkDICOMModel.cxx : variables names with same naming as method names In-Reply-To: References: Message-ID: Julien, I like your suggestion better than mine. The three approaches that you mentioned will make code much readable and maintainable. It will be nice to collect coding style guidelines somewhere... at least in a Wiki,... or in a text file to be included in the git repository. Luis ------------------------------------------------------------------------------- On Thu, Apr 8, 2010 at 6:31 PM, Julien Finet wrote: > Agree,?I'm not a big fan of the 2 solutions you gave though. > When I remember to avoid variable shadowing,?I have a couple of tricks to > rename problematic variables: > for example a variable named "row" could be renamed as: > ?- indexRow / itemRow / cellRow /?childRow / parentRow ?( who owns the > variable) > ?- rowToInsert/rowToDelete (action on the variable) > ?- newRow / oldRow / tmpRow ( lifetime of the variable) > ?- .... > There is almost always one prefix or suffix that can be added and gives more > information about the variable. > Julien. > On Thu, Apr 8, 2010 at 6:15 PM, Luis Ibanez wrote: >> >> I see, >> >> It is too bad that Qt got satisfied with a lower quality bar. >> >> >> We can still avoid having local variables with the same >> names as member variables and member methods. >> >> For example, >> many of the offending warnings were fixed by replacing >> >> ? ? ambiguousvariablename >> >> with >> >> ? ? ambiguousvariablenameValue >> >> we could have as well used the more arcane >> >> ? ? ambiguousvariablename_ >> >> >> Making good choices on names of methods, and variables >> is a an effective way of documenting the code. >> >> >> ? ?Luis >> >> >> >> ----------------------------------------------------------------------------------- >> On Thu, Apr 8, 2010 at 6:08 PM, Julien Finet >> wrote: >> > Hi Luis, >> > I understand your concern. >> > We can't change the name of the method index() as it is a virtual method >> > that has been declared in a Qt subclass. >> > And the problem we face here is that the Qt library doesn't care about >> > shadow variables. (and if I recall, they didn't plan on changing that). >> > We unofficially decided during the CTK Pre Hackfest that a CTK class >> > should >> > follow the naming convention of its derived class, Qt in this example. >> > Is that still OK for everybody ? >> > Setting up KWStyle seems like a good idea. Can we configure it in a way >> > to >> > check a style depending on a filename (ideally the style of the derived >> > class) >> > Julien. >> > On Thu, Apr 8, 2010 at 5:50 PM, Luis Ibanez >> > wrote: >> >> >> >> I recall that at some point we discussed a >> >> naming convention for Qt-like classes, but >> >> I'm not sure if we arrived to a consensus. >> >> >> >> >> >> The file: >> >> >> >> ?Libs/DICOM/Core/ctkDICOMModel.cxx >> >> >> >> had an abundant use of local variables with >> >> names matching some member variables and >> >> member methods. >> >> >> >> A notable example: >> >> >> >> ? ? ? ? ? ? ? ? ? ? ? "index" >> >> >> >> I just committed a fix for most of them, >> >> but for the long run it will be great if we >> >> agree on some naming convention. >> >> >> >> I would vote against having a method of a C++ class >> >> to be called "index()" for example. ? ? ? :-) >> >> >> >> a more useful name will be "getIndex()", for example, >> >> or in this particular case, it looks like what the function >> >> is actually doing is generating an index, so good names >> >> could be >> >> >> >> ctkDICOMModel::generatgeIndex ( int row, int column, const QModelIndex >> >> & parentValue ) const >> >> >> >> or >> >> >> >> ctkDICOMModel::computeIndex ( int row, int column, const QModelIndex & >> >> parentValue ) const >> >> >> >> or >> >> >> >> ctkDICOMModel::produceIndex ( int row, int column, const QModelIndex & >> >> parentValue ) const >> >> >> >> >> >> There is already another >> >> >> >> ? ? ? ? ? ? ? ?createIndex(int, int, Node *) >> >> >> >> >> >> so it will be fine if we use >> >> >> >> ctkDICOMModel::createIndex ( int row, int column, const QModelIndex & >> >> parentValue ) const >> >> >> >> since the signature will be different. >> >> >> >> >> >> --- >> >> >> >> >> >> Do we have a document on coding style ? >> >> >> >> if we do, >> >> we probably should setup KWStyle testing >> >> before things get out of control. >> >> >> >> >> >> >> >> ? ? ?Luis >> > >> > > > From eichelberg at offis.de Fri Apr 9 06:40:48 2010 From: eichelberg at offis.de (Marco Eichelberg) Date: Fri, 09 Apr 2010 08:40:48 +0200 Subject: [Ctk-developers] CTK Dashboard: Cleaning up Warnings: DCMTK In-Reply-To: References: Message-ID: <4BBECBF0.6040505@offis.de> Dear all, Luis Ibanez wrote: > In the process of cleaning up warnings in the Dashboard, > we ran into issues with DCMTK: > > CMakeExternals/Install/include/dcmtk/oflog/spi/logevent.h > > warning: declaration of ?message? shadows a member of 'this' > warning: declaration of ?ll? shadows a member of 'this' These are compiler warnings, not neccessarily issues. We'll look into this, though. Stephen Aylward wrote: > The DCMTK folks are key participants in CTK. > I'm guessing they can fix those... Correct. Julien Finet wrote: >> In CTK/Utilities we have a local version of DCMTK that we cmakeified. >> My vote goes to fix the warnings into directly into the CTK repository. I would think that this is a bad idea. Our team publishes a new snapshot of the DCMTK source code about once a month. If you create a fork, then you will be responsible for merging that with our releases about monthly. Since the DCMTK team is part of CTK, I would suggest that you report problems with DCMTK to us, let us fix them, and avoid any duplication of code or work. With best regards, Dr. Marco Eichelberg -- Dr. Marco Eichelberg Gruppenleiter Integrationstechnik | Manager Integration Technology Group OFFIS FuE Bereich Gesundheit | R&D Division Health Escherweg 2 - 26121 Oldenburg - Germany Phone/Fax.: +49 441 9722-147/111 E-Mail: eichelberg at offis.de URL: http://www.offis.de/ From m.nolden at dkfz-heidelberg.de Fri Apr 9 08:20:16 2010 From: m.nolden at dkfz-heidelberg.de (Marco Nolden) Date: Fri, 09 Apr 2010 10:20:16 +0200 Subject: [Ctk-developers] CTK Dasboard: Low Code Coverage : 42% .and. 608 Valgrind Errors. In-Reply-To: References: Message-ID: <4BBEE340.7030305@dkfz-heidelberg.de> Dear Julien, I will have a look at ctkDICOMIndexer.cxx before the next hackfest. Marco Am 08.04.2010 20:10, schrieb Julien Finet: > Agree, let's test it all ! :-) > > I already have a test ready (in Slicer) for ctkModelTester. I like > testing testers. > > I can also look at ctkDICOMIndexer.cxx, but I'd probably need some > help from Marco... > > Julien. > > On Thu, Apr 8, 2010 at 1:58 PM, Luis Ibanez > wrote: > > The CTK Dasboard is in need of some Though Love. > > > A) Code Coverage: 42% > http://my.cdash.org/viewCoverage.php?buildid=57880 > > > B) 608 Valgring Errors > http://my.cdash.org/viewDynamicAnalysis.php?buildid=57892 > > > We must fix this before the Hackaton. > > > It will be a disaster to have a lot of new code to be put > inside a repository with a weak testing infrastructure. > > > Any volunteer for adopting the orphan classes ? > > ./Libs/Core/ctkDependencyGraph.h > ./Libs/DICOM/Core/ctkDICOMIndexer.cxx > ./Libs/Core/ctkDependencyGraph.cxx > ./Libs/Core/ctkModelTester.cxx > > > > Many of the memory leaks seems to come from : > > ==9718== at 0x4C25153: malloc (vg_replace_malloc.c:195) > ==9718== by 0x75331A1: strdup (strdup.c:43) > ==9718== by 0x89F0C49: IceRegisterForProtocolSetup (in > /usr/lib/libICE.so.6.3.0) > > > Any reason for using the old strdup instead > of using "std::string" ? > > > Finally, > > There are no Windows nor Mac builds in the Dashboard... > > Any volunteers for setting up additional builds ? > > > > Luis > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > -- ---------------------------------------------------------------------- Dipl.-Inform. Med. Marco Nolden Deutsches Krebsforschungszentrum (German Cancer Research Center) Div. Medical& Biological Informatics Tel: (+49) 6221-42 2325 Im Neuenheimer Feld 280 Fax: (+49) 6221-42 2345 D-69120 Heidelberg eMail: M.Nolden at dkfz.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From dicom at offis.de Fri Apr 9 13:23:01 2010 From: dicom at offis.de (OFFIS DICOM Team) Date: Fri, 09 Apr 2010 15:23:01 +0200 Subject: [Ctk-developers] CTK Dashboard: Cleaning up Warnings: DCMTK In-Reply-To: References: Message-ID: <4BBF2A35.5050406@offis.de> Dear all, Am 08.04.2010 23:22, schrieb Stephen Aylward: > The DCMTK folks are key participants in CTK. > > I'm guessing they can fix those... They're now also fixed in our development version and therefore the changes will be part of the next snapshot. By the way, we are thinking about providing a public mirror of our code repository (read-only). We will work on that as soon as time permits. This should make it easier for developers to keep up-to-date, check changes on commit level, include automatic checkouts into their project setups etc. Hope to meet most of you at the hackfest :) Best regards, Michael -- OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany E-Mail: dicom at offis.de, URL: http://dicom.offis.de From luis.ibanez at kitware.com Fri Apr 9 14:21:57 2010 From: luis.ibanez at kitware.com (Luis Ibanez) Date: Fri, 9 Apr 2010 10:21:57 -0400 Subject: [Ctk-developers] CTK Dashboard: WCFOD = Worst Covered File of the Day = ./Libs/Core/ctkDependencyGraph.h Message-ID: The dubious honor of being the WCFOD: Worst Code-Covered File of the Day goes to: ./Libs/Core/ctkDependencyGraph.h and its companion: ./Libs/Core/ctkDependencyGraph.cxx with Code coverage = 0.0% http://my.cdash.org/viewCoverage.php?buildid=58100 Does anyone cares about adopting this file ? Otherwise we will write tests for it today under the code-welfare program. Please let me know, Thanks Luis From m.nolden at dkfz-heidelberg.de Fri Apr 9 14:36:07 2010 From: m.nolden at dkfz-heidelberg.de (Marco Nolden) Date: Fri, 09 Apr 2010 16:36:07 +0200 Subject: [Ctk-developers] CTK Dashboard: WCFOD = Worst Covered File of the Day = ./Libs/Core/ctkDependencyGraph.h In-Reply-To: References: Message-ID: <4BBF3B57.5030005@dkfz-heidelberg.de> On 04/09/2010 04:21 PM, Luis Ibanez wrote: > The dubious honor of being the WCFOD: > > Worst Code-Covered File of the Day > > > >> http://my.cdash.org/viewCoverage.php?buildid=58100 >> >> > Hi, 2nd on that list is * *./Libs/DICOM/Core/ctkDICOMIndexer.cxx, the one I would take care of.. To write a meaningful test the dartclient needs access to a directory containing dicom images from several different patients, studies and series. Any ideas how we could provide that? Could the superbuild download and extract the sample archive before running the tests? Best Marco > Does anyone cares about adopting this file ? > > > Otherwise we will write tests for it today > under the code-welfare program. > > > Please let me know, > > > Thanks > > > Luis > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -- ---------------------------------------------------------------------- Dipl.-Inform. Med. Marco Nolden Deutsches Krebsforschungszentrum (German Cancer Research Center) Div. Medical& Biological Informatics Tel: (+49) 6221-42 2325 Im Neuenheimer Feld 280 Fax: (+49) 6221-42 2345 D-69120 Heidelberg eMail: M.Nolden at dkfz.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From luis.ibanez at kitware.com Fri Apr 9 14:36:40 2010 From: luis.ibanez at kitware.com (Luis Ibanez) Date: Fri, 9 Apr 2010 10:36:40 -0400 Subject: [Ctk-developers] COPYRIGHT & LICENSING Message-ID: Yes, it is not the most amusing conversation to have, but it is better to do this early... 1) Most files in CTK are lacking Copyright notices and an explicit License. 2) There is not LICENCE file at the top of the source tree. I propose that we assign the copyright of the source code to the Insight Software Consortium (ISC), and that we distribute the code under an Apache 2.0 License. http://www.opensource.org/licenses/apache2.0.php The ISC is the organization that holds the copyright of * ITK * CMake (along with Kitware) * IGSTK More information about the ISC at: http://www.insightsoftwareconsortium.org/ It will also be important for your respective organizations to join the ISC, or for you to join as individuals, so you help ensure that the CTK project is managed as you intended. Every day that passes without having a clear License and Copyright statement is a day were we are brewing a recipe for disaster. If someone needs to be persuaded, we can provide details on the horror story of how much trouble we are having in ITK with source code of dubious origin (no copyright notice nor license) that we adopted from www.netlib.org.... Luis From luis.ibanez at kitware.com Fri Apr 9 14:45:15 2010 From: luis.ibanez at kitware.com (Luis Ibanez) Date: Fri, 9 Apr 2010 10:45:15 -0400 Subject: [Ctk-developers] CTK Dashboard: A DICOM data collection for testing ? Message-ID: Hi Marco, Thanks for taking on the task of improving code quality. Here are a couple of ideas: 1) In IGSTK we included a couple of DICOM files in the source code repository itself in order to provide testing of basic functionalities. This is OK for "Unit-Testing". (and has to be limited to a couple of slices, since you don't want a source code repository to carry more than 10% of data. This simple data, however, insufficient for "Acceptance-Tests" (that is, tests that verify the code under realistic conditions from the point of view of a final user). so 2) We could host a set of realistic DICOM series in the MIDAS server, and setup CMake to download them into testing machines as part of the superbuild. It will be important to include in that collection, a set of "bad" datasets that exercise error conditions in the code. That is, we want to include DICOM images that are not compliant, and we want to verify that the code rejects them accordingly. Does DMTK has a data-testing collection that we could use ? and if so, it is redistributable ? Luis --------------------------------------------------------------------------- On Fri, Apr 9, 2010 at 10:36 AM, Marco Nolden wrote: > On 04/09/2010 04:21 PM, Luis Ibanez wrote: > > The dubious honor of being the WCFOD: > > Worst Code-Covered File of the Day > > > > > http://my.cdash.org/viewCoverage.php?buildid=58100 > > > > > > Hi, > > 2nd on that list is ./Libs/DICOM/Core/ctkDICOMIndexer.cxx, the one I would > take care of.. To write a meaningful test the dartclient needs access to a > directory containing dicom images from several different patients, studies > and series. Any ideas how we could provide that? Could the superbuild > download and extract the sample archive before running the tests? > > Best > Marco > > > > > Does anyone cares about adopting this file ? > > > Otherwise we will write tests for it today > under the code-welfare program. > > > Please let me know, > > > Thanks > > > Luis > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > > -- > ---------------------------------------------------------------------- > Dipl.-Inform. Med. Marco Nolden > Deutsches Krebsforschungszentrum (German Cancer Research Center) > Div. Medical & Biological Informatics Tel: (+49) 6221-42 2325 > Im Neuenheimer Feld 280 Fax: (+49) 6221-42 2345 > D-69120 Heidelberg eMail: M.Nolden at dkfz.de > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > From tarboxl at mir.wustl.edu Fri Apr 9 18:51:32 2010 From: tarboxl at mir.wustl.edu (Tarbox, Lawrence) Date: Fri, 9 Apr 2010 13:51:32 -0500 Subject: [Ctk-developers] COPYRIGHT & LICENSING In-Reply-To: References: Message-ID: <67B4B5166383D848A0565AA7491841F93082FAA6EB@RAD-VMSRVEXV2.rad.wustl.edu> The Apache license is fine with me. It is what I would have recommended. As to copyright, certainly one should be in place in the source code. But if the Apache license notice is in place, it should not matter much who holds the copyright, since the Apache license grants anyone the right to do what we are doing. Certain software that might be contributed might already have a copyright and might already be distributed under alternate license terms. As long as the license terms are compatible with Apache, I would not think that there is a need to change the original copyright or license terms. Compatible, for us, implies that we are allowed to redistribute a combined package as a new work with its own licensing terms (e.g. Apache), as long as the licensing terms of the contributed bits can still be fulfilled (e.g. attribution). At least that is my humble opinion. However, I am not a lawyer, hence my opinion has no standing in a court of law. -----Original Message----- From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Luis Ibanez Sent: Friday, April 09, 2010 09:37 AM To: ctk-developers Subject: [Ctk-developers] COPYRIGHT & LICENSING Yes, it is not the most amusing conversation to have, but it is better to do this early... 1) Most files in CTK are lacking Copyright notices and an explicit License. 2) There is not LICENCE file at the top of the source tree. I propose that we assign the copyright of the source code to the Insight Software Consortium (ISC), and that we distribute the code under an Apache 2.0 License. http://www.opensource.org/licenses/apache2.0.php The ISC is the organization that holds the copyright of * ITK * CMake (along with Kitware) * IGSTK More information about the ISC at: http://www.insightsoftwareconsortium.org/ It will also be important for your respective organizations to join the ISC, or for you to join as individuals, so you help ensure that the CTK project is managed as you intended. Every day that passes without having a clear License and Copyright statement is a day were we are brewing a recipe for disaster. If someone needs to be persuaded, we can provide details on the horror story of how much trouble we are having in ITK with source code of dubious origin (no copyright notice nor license) that we adopted from www.netlib.org.... Luis _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers The material in this message is private and may contain Protected Healthcare Information (PHI). If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail. From julien.finet at kitware.com Fri Apr 9 18:59:26 2010 From: julien.finet at kitware.com (Julien Finet) Date: Fri, 9 Apr 2010 14:59:26 -0400 Subject: [Ctk-developers] CTK Dashboard: Cleaning up Warnings: DCMTK In-Reply-To: <4BBF2A35.5050406@offis.de> References: <4BBF2A35.5050406@offis.de> Message-ID: On Fri, Apr 9, 2010 at 9:23 AM, OFFIS DICOM Team wrote: > Dear all, > > They're now also fixed in our development version and therefore the changes > will be part of the next snapshot. > > Nice ! thanks for doing that. How about including the CMake build system into DCMTK ? The work has already been done (not thoroughly tested though) in CTK/Utilities/DCMTK. That way we could get rid of the fork... Regards, Julien. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tarboxl at mir.wustl.edu Fri Apr 9 20:39:10 2010 From: tarboxl at mir.wustl.edu (Tarbox, Lawrence) Date: Fri, 9 Apr 2010 15:39:10 -0500 Subject: [Ctk-developers] CTK Dashboard: Cleaning up Warnings: DCMTK In-Reply-To: References: <4BBF2A35.5050406@offis.de> Message-ID: <67B4B5166383D848A0565AA7491841F93082FAA6ED@RAD-VMSRVEXV2.rad.wustl.edu> If I had a vote at OFFIS, I would vote for this! From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Julien Finet Sent: Friday, April 09, 2010 01:59 PM To: dicom at offis.de Cc: ctk-developers at commontk.org Subject: Re: [Ctk-developers] CTK Dashboard: Cleaning up Warnings: DCMTK On Fri, Apr 9, 2010 at 9:23 AM, OFFIS DICOM Team > wrote: Dear all, They're now also fixed in our development version and therefore the changes will be part of the next snapshot. Nice ! thanks for doing that. How about including the CMake build system into DCMTK ? The work has already been done (not thoroughly tested though) in CTK/Utilities/DCMTK. That way we could get rid of the fork... Regards, Julien. ________________________________ The material in this message is private and may contain Protected Healthcare Information (PHI). If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dicom at offis.de Fri Apr 9 20:56:13 2010 From: dicom at offis.de (OFFIS DICOM Team) Date: Fri, 9 Apr 2010 22:56:13 +0200 Subject: [Ctk-developers] CTK Dashboard: Cleaning up Warnings: DCMTK In-Reply-To: References: <4BBF2A35.5050406@offis.de> Message-ID: <201004092256.14436.dicom@offis.de> Julien, > How about including the CMake build system into DCMTK ? > The work has already been done (not thoroughly tested though) in > CTK/Utilities/DCMTK. in fact, Michael already started with incorporating your CMake files into our current development version. As far as I know, he slightly modified some files. After the work has been finished and thoroughly tested, we will probably make the "new" CMake files available as part of a future DCMTK snapshot. > That way we could get rid of the fork... Full acknowledge. However, we will probably also retain the existing GNU autoconf stuff (aka "configure") - at least for a while :-) Regards from Oldenburg/Germany, J?rg Riesmeier -- OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany E-Mail: dicom at offis.de, URL: http://dicom.offis.de From stephen.aylward at kitware.com Sun Apr 11 19:24:34 2010 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Sun, 11 Apr 2010 15:24:34 -0400 Subject: [Ctk-developers] An interesting article Message-ID: Luis just pointed me towards an interesting article: https://www.theopensourceway.org/wiki/How_to_tell_if_a_FLOSS_project_is_doomed_to_FAIL Something to keep in mind as we move forward... Stephen -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From kikinis at bwh.harvard.edu Mon Apr 12 12:35:54 2010 From: kikinis at bwh.harvard.edu (Ron Kikinis) Date: Mon, 12 Apr 2010 08:35:54 -0400 Subject: [Ctk-developers] COPYRIGHT & LICENSING In-Reply-To: References: Message-ID: <4BC313AA.6050408@bwh.harvard.edu> Luis, The apache license sounds reasonable to me. In terms of making ISC the owner of the copyright: As you know, we have taken a different approach with Slicer in that the contributors keep the copyright and only grant an irrevocable and unlimited license for use in Slicer (I am not a lawyer so this is not legal language). On an other point: ISC was created to hold the copyright for ITK. The website does not really reflect the more recent additions of cmake and IGSTK. The board of directors primarily reflects ITK and would probably require some updates. One question: how "dictator proof" is ISC? Ron On 4/9/10 10:36 AM, Luis Ibanez wrote: > Yes, > it is not the most amusing conversation to have, > but it is better to do this early... > > > 1) Most files in CTK are lacking Copyright > notices and an explicit License. > > 2) There is not LICENCE file at the top of > the source tree. > > > > I propose that we assign the copyright of the source code > to the Insight Software Consortium (ISC), and that we > distribute the code under an Apache 2.0 License. > > http://www.opensource.org/licenses/apache2.0.php > > > > The ISC is the organization that holds the copyright of > > * ITK > * CMake (along with Kitware) > * IGSTK > > > More information about the ISC at: > > http://www.insightsoftwareconsortium.org/ > > > It will also be important for your respective organizations > to join the ISC, or for you to join as individuals, so you > help ensure that the CTK project is managed as you > intended. > > > Every day that passes without having a clear License > and Copyright statement is a day were we are brewing > a recipe for disaster. > > > > If someone needs to be persuaded, we can provide details > on the horror story of how much trouble we are having in ITK > with source code of dubious origin (no copyright notice nor > license) that we adopted from www.netlib.org.... > > > > Luis > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers -- Ron Kikinis, M.D., Robert Greenes Distinguished Director of Biomedical Informatics Professor of Radiology, Harvard Medical School Director, Surgical Planning Laboratory http://www.spl.harvard.edu/~kikinis From kikinis at bwh.harvard.edu Mon Apr 12 12:38:07 2010 From: kikinis at bwh.harvard.edu (Ron Kikinis) Date: Mon, 12 Apr 2010 08:38:07 -0400 Subject: [Ctk-developers] Bylaws of the ISC | The Insight Software Consortium Message-ID: <4BC3142F.1070602@bwh.harvard.edu> http://www.insightsoftwareconsortium.org/node/21 "The Consortium is organized and operated exclusively for the purpose of furthering ITK." -- Ron Kikinis, M.D., Robert Greenes Distinguished Director of Biomedical Informatics Professor of Radiology, Harvard Medical School Director, Surgical Planning Laboratory http://www.spl.harvard.edu/~kikinis From bill.lorensen at gmail.com Mon Apr 12 12:39:05 2010 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 12 Apr 2010 08:39:05 -0400 Subject: [Ctk-developers] COPYRIGHT & LICENSING In-Reply-To: <4BC313AA.6050408@bwh.harvard.edu> References: <4BC313AA.6050408@bwh.harvard.edu> Message-ID: I agree with that license is more important that the copyright holders. In VTK, many files have multiple copyrights, but all share the same license. Bill On Mon, Apr 12, 2010 at 8:35 AM, Ron Kikinis wrote: > Luis, > > The apache license sounds reasonable to me. In terms of making ISC the owner > of the copyright: > As you know, we have taken a different approach with Slicer in that the > contributors keep the copyright and only grant an irrevocable and unlimited > license for use in Slicer (I am not a lawyer so this is not legal language). > > On an other point: ISC was created to hold the copyright for ITK. The > website does not really reflect the more recent additions of cmake and > IGSTK. The board of directors primarily reflects ITK and would probably > require some updates. > > One question: how "dictator proof" is ISC? > > Ron > > > > On 4/9/10 10:36 AM, Luis Ibanez wrote: >> >> Yes, >> it is not the most amusing conversation to have, >> but it is better to do this early... >> >> >> ? ?1) Most files in CTK are lacking Copyright >> ? ? ? ?notices and an explicit License. >> >> ? ?2) There is not LICENCE file at the top of >> ? ? ? ?the source tree. >> >> >> >> I propose that we assign the copyright of the source code >> to the Insight Software Consortium (ISC), and that we >> distribute the code under an Apache 2.0 License. >> >> ? http://www.opensource.org/licenses/apache2.0.php >> >> >> >> The ISC is the organization that holds the copyright of >> >> ? ? ? ? ? * ?ITK >> ? ? ? ? ? * ?CMake (along with Kitware) >> ? ? ? ? ? * IGSTK >> >> >> More information about the ISC at: >> >> ? ? http://www.insightsoftwareconsortium.org/ >> >> >> It will also be important for your respective organizations >> to join the ISC, or for you to join as individuals, so you >> help ensure that the CTK project is managed as you >> intended. >> >> >> Every day that passes without having a clear License >> and Copyright statement is a day were we are brewing >> a recipe for disaster. >> >> >> >> If someone needs to be persuaded, we can provide details >> on the horror story of how much trouble we are having in ITK >> with source code of dubious origin (no copyright notice nor >> license) that we adopted from ? www.netlib.org.... >> >> >> >> ? ? ? Luis >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > -- > Ron Kikinis, M.D., > Robert Greenes Distinguished Director of Biomedical Informatics > Professor of Radiology, Harvard Medical School > Director, Surgical Planning Laboratory > http://www.spl.harvard.edu/~kikinis > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > From dicom at offis.de Mon Apr 12 12:46:39 2010 From: dicom at offis.de (OFFIS DICOM Team) Date: Mon, 12 Apr 2010 14:46:39 +0200 Subject: [Ctk-developers] COPYRIGHT & LICENSING In-Reply-To: References: Message-ID: <4BC3162F.5000108@offis.de> Luis and others, > I propose that we assign the copyright of the source code > to the Insight Software Consortium (ISC), and that we > distribute the code under an Apache 2.0 License. in the CTK wiki, I found the following information: http://www.commontk.org/cgi-bin/trac.cgi/wiki/Whitepaper#BSDstylelicense Btw, DCMTK is also released under a BSD-style license ... Regards, J?rg Riesmeier -- OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany E-Mail: dicom at offis.de, URL: http://dicom.offis.de From luis.ibanez at kitware.com Mon Apr 12 14:23:42 2010 From: luis.ibanez at kitware.com (Luis Ibanez) Date: Mon, 12 Apr 2010 10:23:42 -0400 Subject: [Ctk-developers] COPYRIGHT & LICENSING In-Reply-To: References: <4BC313AA.6050408@bwh.harvard.edu> Message-ID: I agree with Bill, The choice of a good License is more important that who holds the Copyright (and patents, and trademarks) associated with the code. In practice, tracing the Copyright holders of code in an Open Source project is an impossible task. Whoever is contributing code to an Open Source project with the intention of conserving ownership or control over such code has flawed understanding of how software development works in a peer-production environment. Files tend to (and *should*) be modified by many different developers, who are affiliated to different institutions. Every institution will hold the copyright of every modification. You may know "who" is the copyright holder of a file, the first day that file is committed. But after ten years of this file being modified and retouched by twenty other developers from ten other institutions, you have a file where 55% of the lines are copyrighted by institution A 27% by institution B 13% by institution C.. ... and so on. In a well-managed open source project, such modifications of any given file by many different developers *is expected* to happen. When a file has only been touched by a single developer, that's an indication that nobody else in the project cares about such file, and that the project has poor practices of code review and suffers from lack of participation. So, even if any given organization want to conserve "ownership" of the code, that is simply unrealistic in practice. Assigning copyright of the code to a non-for-profit organization is actually a way of protecting the developers (and their institutions). This is discussed in great detail in: "Intellectual Property and Open Source A Practical Guide to Protecting Code" by Van Lindberg http://oreilly.com/catalog/9780596517960 In any case, what is more important is to chose a License, that make irrelevant (and unnecessary) to track ownership of the source code. The MIT, BSD and Apache 2.0 licenses are typical good choices that satisfy such condition. The Apache 2.0 license is particularly attractive in this case because it is the only one from this group, that includes specific clauses about code contributions. Luis ------------------------------------------------------------------------------------------- On Mon, Apr 12, 2010 at 8:39 AM, Bill Lorensen wrote: > I agree with that license is more important that the copyright holders. > > In VTK, many files have multiple copyrights, but all share the same > license. > > Bill > > On Mon, Apr 12, 2010 at 8:35 AM, Ron Kikinis > wrote: > > Luis, > > > > The apache license sounds reasonable to me. In terms of making ISC the > owner > > of the copyright: > > As you know, we have taken a different approach with Slicer in that the > > contributors keep the copyright and only grant an irrevocable and > unlimited > > license for use in Slicer (I am not a lawyer so this is not legal > language). > > > > On an other point: ISC was created to hold the copyright for ITK. The > > website does not really reflect the more recent additions of cmake and > > IGSTK. The board of directors primarily reflects ITK and would probably > > require some updates. > > > > One question: how "dictator proof" is ISC? > > > > Ron > > > > > > > > On 4/9/10 10:36 AM, Luis Ibanez wrote: > >> > >> Yes, > >> it is not the most amusing conversation to have, > >> but it is better to do this early... > >> > >> > >> 1) Most files in CTK are lacking Copyright > >> notices and an explicit License. > >> > >> 2) There is not LICENCE file at the top of > >> the source tree. > >> > >> > >> > >> I propose that we assign the copyright of the source code > >> to the Insight Software Consortium (ISC), and that we > >> distribute the code under an Apache 2.0 License. > >> > >> http://www.opensource.org/licenses/apache2.0.php > >> > >> > >> > >> The ISC is the organization that holds the copyright of > >> > >> * ITK > >> * CMake (along with Kitware) > >> * IGSTK > >> > >> > >> More information about the ISC at: > >> > >> http://www.insightsoftwareconsortium.org/ > >> > >> > >> It will also be important for your respective organizations > >> to join the ISC, or for you to join as individuals, so you > >> help ensure that the CTK project is managed as you > >> intended. > >> > >> > >> Every day that passes without having a clear License > >> and Copyright statement is a day were we are brewing > >> a recipe for disaster. > >> > >> > >> > >> If someone needs to be persuaded, we can provide details > >> on the horror story of how much trouble we are having in ITK > >> with source code of dubious origin (no copyright notice nor > >> license) that we adopted from www.netlib.org.... > >> > >> > >> > >> Luis > >> _______________________________________________ > >> Ctk-developers mailing list > >> Ctk-developers at commontk.org > >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > > > -- > > Ron Kikinis, M.D., > > Robert Greenes Distinguished Director of Biomedical Informatics > > Professor of Radiology, Harvard Medical School > > Director, Surgical Planning Laboratory > > http://www.spl.harvard.edu/~kikinis > > _______________________________________________ > > Ctk-developers mailing list > > Ctk-developers at commontk.org > > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pieper at bwh.harvard.edu Mon Apr 12 14:25:39 2010 From: pieper at bwh.harvard.edu (Steve Pieper) Date: Mon, 12 Apr 2010 10:25:39 -0400 Subject: [Ctk-developers] CTK Dashboard: Cleaning up Warnings: DCMTK In-Reply-To: References: Message-ID: <4BC32D63.9090504@bwh.harvard.edu> Hi Luis - Can you add these directly to the ctk cmake files as the default compile flags? Thanks, Steve p.s. if CTK developers need write access to the github repository just let me know. :) On Apr/8/10 5:38 PM, Luis Ibanez wrote: > On Thu, Apr 8, 2010 at 5:23 PM, Julien Finet wrote: >> Hi Luis, >> In CTK/Utilities we have a local version of DCMTK that we cmakeified. >> My vote goes to fix the warnings into directly into the CTK repository. >> Julien. >> > ---------------------------------------------------------------------------------------- > > That works too. > > I just committed the fixes to: > > CTK/Utilities/DCMTK/oflog/include/dcmtk/oflog/spi/logevent.h > > > We will avoid many problems if we agree on using a similar collection > of Warning flags for the machines that submit to the Dashboard. > > For GCC we should at least have: > > -Wall -Wshadow -Wno-uninitialized > > > > Luis > > > --------------------------------------------------------------- >> On Thu, Apr 8, 2010 at 5:14 PM, Luis Ibanez wrote: >>> >>> In the process of cleaning up warnings in the Dashboard, >>> we ran into issues with DCMTK: >>> >>> CMakeExternals/Install/include/dcmtk/oflog/spi/logevent.h >>> >>> warning: declaration of ?message? shadows a member of 'this' >>> warning: declaration of ?ll? shadows a member of 'this' >>> >>> >>> Given that DCMTK is a third party library, our options for >>> fixing this are: >>> >>> >>> A) Post a patch to the DCMTK developers and wait for >>> them to push that into a release >>> >>> B) Host a duplicate repository of DCMTK and make the >>> patches there >>> >>> C) Silence the warning using CTestCustom.cmake >>> (put the problem under the rug..) >>> >>> >>> >>> What are your preferences ? >>> >>> >>> Thanks >>> >>> >>> Luis >>> _______________________________________________ >>> Ctk-developers mailing list >>> Ctk-developers at commontk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers From pieper at bwh.harvard.edu Mon Apr 12 14:30:57 2010 From: pieper at bwh.harvard.edu (Steve Pieper) Date: Mon, 12 Apr 2010 10:30:57 -0400 Subject: [Ctk-developers] CTK Dashboard: A DICOM data collection for testing ? In-Reply-To: References: Message-ID: <4BC32EA1.5090200@bwh.harvard.edu> Hi Luis - Here are some sharable example dicom files that we have been using to test the indexer: http://www.slicer.org/slicerWiki/index.php/File:Dicom-database-examples-2010-03-09.zip (note this also includes some non-dicom files - but this is good for testing!). It would be great for ctest to automatically grab these files from a URL and put them in a local cache for testing purposes. We could either use the existing wiki URL or move them to midas... -Steve p.s. There's some discussion of the indexer here for background: http://www.slicer.org/slicerWiki/index.php/DICOM:Database p.p.s. thanks, Luis, for being the voice of code quality! On Apr/9/10 10:45 AM, Luis Ibanez wrote: > Hi Marco, > > > Thanks for taking on the task of improving code quality. > > > Here are a couple of ideas: > > 1) In IGSTK we included a couple of DICOM files in the > source code repository itself in order to provide testing > of basic functionalities. This is OK for "Unit-Testing". > (and has to be limited to a couple of slices, since you > don't want a source code repository to carry more than > 10% of data. > > This simple data, however, insufficient for "Acceptance-Tests" > (that is, tests that verify the code under realistic conditions > from the point of view of a final user). > > so > > 2) We could host a set of realistic DICOM series in the MIDAS > server, and setup CMake to download them into testing > machines as part of the superbuild. It will be important to > include in that collection, a set of "bad" datasets that exercise > error conditions in the code. > > That is, we want to include DICOM images that are not compliant, > and we want to verify that the code rejects them accordingly. > > > > Does DMTK has a data-testing collection that we could use ? > > and if so, it is redistributable ? > > > > Luis > > --------------------------------------------------------------------------- > On Fri, Apr 9, 2010 at 10:36 AM, Marco Nolden > wrote: >> On 04/09/2010 04:21 PM, Luis Ibanez wrote: >> >> The dubious honor of being the WCFOD: >> >> Worst Code-Covered File of the Day >> >> >> >> >> http://my.cdash.org/viewCoverage.php?buildid=58100 >> >> >> >> >> >> Hi, >> >> 2nd on that list is ./Libs/DICOM/Core/ctkDICOMIndexer.cxx, the one I would >> take care of.. To write a meaningful test the dartclient needs access to a >> directory containing dicom images from several different patients, studies >> and series. Any ideas how we could provide that? Could the superbuild >> download and extract the sample archive before running the tests? >> >> Best >> Marco >> >> >> >> >> Does anyone cares about adopting this file ? >> >> >> Otherwise we will write tests for it today >> under the code-welfare program. >> >> >> Please let me know, >> >> >> Thanks >> >> >> Luis >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> >> -- >> ---------------------------------------------------------------------- >> Dipl.-Inform. Med. Marco Nolden >> Deutsches Krebsforschungszentrum (German Cancer Research Center) >> Div. Medical& Biological Informatics Tel: (+49) 6221-42 2325 >> Im Neuenheimer Feld 280 Fax: (+49) 6221-42 2345 >> D-69120 Heidelberg eMail: M.Nolden at dkfz.de >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers From pieper at bwh.harvard.edu Mon Apr 12 14:44:37 2010 From: pieper at bwh.harvard.edu (Steve Pieper) Date: Mon, 12 Apr 2010 10:44:37 -0400 Subject: [Ctk-developers] Libs/DICOM/Core/ctkDICOMModel.cxx : variables names with same naming as method names In-Reply-To: References: Message-ID: <4BC331D5.6010607@bwh.harvard.edu> Hi Guys - +1 on good naming conventions for variables (I like Julien's suggestions). I also echo Julien's point that the coding convention should follow the conventions of the parent classes. So code that inherits from vtkObject should be VTK-style, QObject code should be Qt-style, etc. This will follow the 'principle of least surprise' for a developer who picks up a ctk Qt widget and wants to use it in their Qt code. -Steve On Apr/8/10 6:43 PM, Luis Ibanez wrote: > Julien, > > I like your suggestion better than mine. > > The three approaches that you mentioned will > make code much readable and maintainable. > > It will be nice to collect coding style guidelines > somewhere... at least in a Wiki,... or in a text > file to be included in the git repository. > > > Luis > > > ------------------------------------------------------------------------------- > On Thu, Apr 8, 2010 at 6:31 PM, Julien Finet wrote: >> Agree, I'm not a big fan of the 2 solutions you gave though. >> When I remember to avoid variable shadowing, I have a couple of tricks to >> rename problematic variables: >> for example a variable named "row" could be renamed as: >> - indexRow / itemRow / cellRow / childRow / parentRow ( who owns the >> variable) >> - rowToInsert/rowToDelete (action on the variable) >> - newRow / oldRow / tmpRow ( lifetime of the variable) >> - .... >> There is almost always one prefix or suffix that can be added and gives more >> information about the variable. >> Julien. >> On Thu, Apr 8, 2010 at 6:15 PM, Luis Ibanez wrote: >>> >>> I see, >>> >>> It is too bad that Qt got satisfied with a lower quality bar. >>> >>> >>> We can still avoid having local variables with the same >>> names as member variables and member methods. >>> >>> For example, >>> many of the offending warnings were fixed by replacing >>> >>> ambiguousvariablename >>> >>> with >>> >>> ambiguousvariablenameValue >>> >>> we could have as well used the more arcane >>> >>> ambiguousvariablename_ >>> >>> >>> Making good choices on names of methods, and variables >>> is a an effective way of documenting the code. >>> >>> >>> Luis >>> >>> >>> >>> ----------------------------------------------------------------------------------- >>> On Thu, Apr 8, 2010 at 6:08 PM, Julien Finet >>> wrote: >>>> Hi Luis, >>>> I understand your concern. >>>> We can't change the name of the method index() as it is a virtual method >>>> that has been declared in a Qt subclass. >>>> And the problem we face here is that the Qt library doesn't care about >>>> shadow variables. (and if I recall, they didn't plan on changing that). >>>> We unofficially decided during the CTK Pre Hackfest that a CTK class >>>> should >>>> follow the naming convention of its derived class, Qt in this example. >>>> Is that still OK for everybody ? >>>> Setting up KWStyle seems like a good idea. Can we configure it in a way >>>> to >>>> check a style depending on a filename (ideally the style of the derived >>>> class) >>>> Julien. >>>> On Thu, Apr 8, 2010 at 5:50 PM, Luis Ibanez >>>> wrote: >>>>> >>>>> I recall that at some point we discussed a >>>>> naming convention for Qt-like classes, but >>>>> I'm not sure if we arrived to a consensus. >>>>> >>>>> >>>>> The file: >>>>> >>>>> Libs/DICOM/Core/ctkDICOMModel.cxx >>>>> >>>>> had an abundant use of local variables with >>>>> names matching some member variables and >>>>> member methods. >>>>> >>>>> A notable example: >>>>> >>>>> "index" >>>>> >>>>> I just committed a fix for most of them, >>>>> but for the long run it will be great if we >>>>> agree on some naming convention. >>>>> >>>>> I would vote against having a method of a C++ class >>>>> to be called "index()" for example. :-) >>>>> >>>>> a more useful name will be "getIndex()", for example, >>>>> or in this particular case, it looks like what the function >>>>> is actually doing is generating an index, so good names >>>>> could be >>>>> >>>>> ctkDICOMModel::generatgeIndex ( int row, int column, const QModelIndex >>>>> & parentValue ) const >>>>> >>>>> or >>>>> >>>>> ctkDICOMModel::computeIndex ( int row, int column, const QModelIndex& >>>>> parentValue ) const >>>>> >>>>> or >>>>> >>>>> ctkDICOMModel::produceIndex ( int row, int column, const QModelIndex& >>>>> parentValue ) const >>>>> >>>>> >>>>> There is already another >>>>> >>>>> createIndex(int, int, Node *) >>>>> >>>>> >>>>> so it will be fine if we use >>>>> >>>>> ctkDICOMModel::createIndex ( int row, int column, const QModelIndex& >>>>> parentValue ) const >>>>> >>>>> since the signature will be different. >>>>> >>>>> >>>>> --- >>>>> >>>>> >>>>> Do we have a document on coding style ? >>>>> >>>>> if we do, >>>>> we probably should setup KWStyle testing >>>>> before things get out of control. >>>>> >>>>> >>>>> >>>>> Luis >>>> >>>> >> >> > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers From bill.lorensen at gmail.com Mon Apr 12 15:19:57 2010 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 12 Apr 2010 11:19:57 -0400 Subject: [Ctk-developers] CTK Dashboard: A DICOM data collection for testing ? In-Reply-To: <4BC32EA1.5090200@bwh.harvard.edu> References: <4BC32EA1.5090200@bwh.harvard.edu> Message-ID: Folks, I have a set of 6 dicom series that scan the same phantom in six different directions. I'll be happy to contribute these. They were created a few years ago at GE Research as part of our NA-MIC work. They are useful to see if your code properly handles the direction cosines contained in the dicom header. Bill On Mon, Apr 12, 2010 at 10:30 AM, Steve Pieper wrote: > > Hi Luis - > > Here are some sharable example dicom files that we have been using to test > the indexer: > > http://www.slicer.org/slicerWiki/index.php/File:Dicom-database-examples-2010-03-09.zip > > (note this also includes some non-dicom files - but this is good for > testing!). > > It would be great for ctest to automatically grab these files from a URL and > put them in a local cache for testing purposes. ?We could either use the > existing wiki URL or move them to midas... > > -Steve > > > > p.s. > There's some discussion of the indexer here for background: > > http://www.slicer.org/slicerWiki/index.php/DICOM:Database > > > p.p.s. thanks, Luis, for being the voice of code quality! > > > > On Apr/9/10 10:45 AM, Luis Ibanez wrote: >> >> Hi Marco, >> >> >> Thanks for taking on the task of improving code quality. >> >> >> Here are a couple of ideas: >> >> 1) In IGSTK we included a couple of DICOM files in the >> ? ? source code repository itself in order to provide testing >> ? ? of basic functionalities. ?This is ?OK for "Unit-Testing". >> ? ? (and has to be limited to a couple of slices, since you >> ? ? don't want a source code repository to carry more than >> ? ? 10% of data. >> >> ? ? This simple data, however, insufficient for "Acceptance-Tests" >> ? ? (that is, tests that verify the code under realistic conditions >> ? ? from the point of view of a final user). >> >> so >> >> 2) We could host a set of realistic DICOM series in the MIDAS >> ? ? server, and setup CMake to download them into testing >> ? ? machines as part of the superbuild. It will be important to >> ? ? include in that collection, a set of "bad" datasets that exercise >> ? ? error conditions in the code. >> >> ? ? That is, we want to include DICOM images that are not compliant, >> ? ? and we want to verify that the code rejects them accordingly. >> >> >> >> Does DMTK has a data-testing collection that we could use ? >> >> and if so, it is redistributable ? >> >> >> >> ? ? Luis >> >> >> --------------------------------------------------------------------------- >> On Fri, Apr 9, 2010 at 10:36 AM, Marco Nolden >> ?wrote: >>> >>> On 04/09/2010 04:21 PM, Luis Ibanez wrote: >>> >>> The dubious honor of being the WCFOD: >>> >>> ? ? ? ? ? ? ? ?Worst Code-Covered File of the Day >>> >>> >>> >>> >>> http://my.cdash.org/viewCoverage.php?buildid=58100 >>> >>> >>> >>> >>> >>> Hi, >>> >>> 2nd on that list is ./Libs/DICOM/Core/ctkDICOMIndexer.cxx, the one I >>> would >>> take care of.. To write a meaningful test the dartclient needs access to >>> a >>> directory containing dicom images from several different patients, >>> studies >>> and series. Any ideas how we could provide that? Could the superbuild >>> download and extract the sample archive before running the tests? >>> >>> Best >>> Marco >>> >>> >>> >>> >>> Does anyone cares about adopting this file ? >>> >>> >>> Otherwise we will write tests for it today >>> under the code-welfare program. >>> >>> >>> ? ?Please let me know, >>> >>> >>> ? ? ? ? ? Thanks >>> >>> >>> ? ? ? ? ? ? ? ?Luis >>> _______________________________________________ >>> Ctk-developers mailing list >>> Ctk-developers at commontk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>> >>> >>> -- >>> ---------------------------------------------------------------------- >>> Dipl.-Inform. Med. Marco Nolden >>> Deutsches Krebsforschungszentrum ? ? ? (German Cancer Research Center) >>> Div. Medical& ?Biological Informatics ? ? ? ? ?Tel: (+49) 6221-42 2325 >>> Im Neuenheimer Feld 280 ? ? ? ? ? ? ? ? ? ? ? ?Fax: (+49) 6221-42 2345 >>> D-69120 Heidelberg ? ? ? ? ? ? ? ? ? ? ? ? ? ? eMail: M.Nolden at dkfz.de >>> >>> _______________________________________________ >>> Ctk-developers mailing list >>> Ctk-developers at commontk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>> >>> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > From stephen.aylward at kitware.com Mon Apr 12 16:23:14 2010 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Mon, 12 Apr 2010 12:23:14 -0400 Subject: [Ctk-developers] CTK Dashboard: A DICOM data collection for testing ? In-Reply-To: References: <4BC32EA1.5090200@bwh.harvard.edu> Message-ID: Osirix also has a great collection of challenging DICOM images. Not certain of the licensing terms.... s On Mon, Apr 12, 2010 at 11:19 AM, Bill Lorensen wrote: > Folks, > > I have a set of 6 dicom series that scan the same phantom in six > different directions. I'll be happy to contribute these. They were > created a few years ago at GE Research as part of our NA-MIC work. > They are useful to see if your code properly handles the direction > cosines contained in the dicom header. > > Bill > > On Mon, Apr 12, 2010 at 10:30 AM, Steve Pieper wrote: >> >> Hi Luis - >> >> Here are some sharable example dicom files that we have been using to test >> the indexer: >> >> http://www.slicer.org/slicerWiki/index.php/File:Dicom-database-examples-2010-03-09.zip >> >> (note this also includes some non-dicom files - but this is good for >> testing!). >> >> It would be great for ctest to automatically grab these files from a URL and >> put them in a local cache for testing purposes. ?We could either use the >> existing wiki URL or move them to midas... >> >> -Steve >> >> >> >> p.s. >> There's some discussion of the indexer here for background: >> >> http://www.slicer.org/slicerWiki/index.php/DICOM:Database >> >> >> p.p.s. thanks, Luis, for being the voice of code quality! >> >> >> >> On Apr/9/10 10:45 AM, Luis Ibanez wrote: >>> >>> Hi Marco, >>> >>> >>> Thanks for taking on the task of improving code quality. >>> >>> >>> Here are a couple of ideas: >>> >>> 1) In IGSTK we included a couple of DICOM files in the >>> ? ? source code repository itself in order to provide testing >>> ? ? of basic functionalities. ?This is ?OK for "Unit-Testing". >>> ? ? (and has to be limited to a couple of slices, since you >>> ? ? don't want a source code repository to carry more than >>> ? ? 10% of data. >>> >>> ? ? This simple data, however, insufficient for "Acceptance-Tests" >>> ? ? (that is, tests that verify the code under realistic conditions >>> ? ? from the point of view of a final user). >>> >>> so >>> >>> 2) We could host a set of realistic DICOM series in the MIDAS >>> ? ? server, and setup CMake to download them into testing >>> ? ? machines as part of the superbuild. It will be important to >>> ? ? include in that collection, a set of "bad" datasets that exercise >>> ? ? error conditions in the code. >>> >>> ? ? That is, we want to include DICOM images that are not compliant, >>> ? ? and we want to verify that the code rejects them accordingly. >>> >>> >>> >>> Does DMTK has a data-testing collection that we could use ? >>> >>> and if so, it is redistributable ? >>> >>> >>> >>> ? ? Luis >>> >>> >>> --------------------------------------------------------------------------- >>> On Fri, Apr 9, 2010 at 10:36 AM, Marco Nolden >>> ?wrote: >>>> >>>> On 04/09/2010 04:21 PM, Luis Ibanez wrote: >>>> >>>> The dubious honor of being the WCFOD: >>>> >>>> ? ? ? ? ? ? ? ?Worst Code-Covered File of the Day >>>> >>>> >>>> >>>> >>>> http://my.cdash.org/viewCoverage.php?buildid=58100 >>>> >>>> >>>> >>>> >>>> >>>> Hi, >>>> >>>> 2nd on that list is ./Libs/DICOM/Core/ctkDICOMIndexer.cxx, the one I >>>> would >>>> take care of.. To write a meaningful test the dartclient needs access to >>>> a >>>> directory containing dicom images from several different patients, >>>> studies >>>> and series. Any ideas how we could provide that? Could the superbuild >>>> download and extract the sample archive before running the tests? >>>> >>>> Best >>>> Marco >>>> >>>> >>>> >>>> >>>> Does anyone cares about adopting this file ? >>>> >>>> >>>> Otherwise we will write tests for it today >>>> under the code-welfare program. >>>> >>>> >>>> ? ?Please let me know, >>>> >>>> >>>> ? ? ? ? ? Thanks >>>> >>>> >>>> ? ? ? ? ? ? ? ?Luis >>>> _______________________________________________ >>>> Ctk-developers mailing list >>>> Ctk-developers at commontk.org >>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>> >>>> >>>> -- >>>> ---------------------------------------------------------------------- >>>> Dipl.-Inform. Med. Marco Nolden >>>> Deutsches Krebsforschungszentrum ? ? ? (German Cancer Research Center) >>>> Div. Medical& ?Biological Informatics ? ? ? ? ?Tel: (+49) 6221-42 2325 >>>> Im Neuenheimer Feld 280 ? ? ? ? ? ? ? ? ? ? ? ?Fax: (+49) 6221-42 2345 >>>> D-69120 Heidelberg ? ? ? ? ? ? ? ? ? ? ? ? ? ? eMail: M.Nolden at dkfz.de >>>> >>>> _______________________________________________ >>>> Ctk-developers mailing list >>>> Ctk-developers at commontk.org >>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>> >>>> >>> _______________________________________________ >>> Ctk-developers mailing list >>> Ctk-developers at commontk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From tarboxl at mir.wustl.edu Mon Apr 12 17:00:52 2010 From: tarboxl at mir.wustl.edu (Tarbox, Lawrence) Date: Mon, 12 Apr 2010 12:00:52 -0500 Subject: [Ctk-developers] CTK Dashboard: A DICOM data collection for testing ? In-Reply-To: References: <4BC32EA1.5090200@bwh.harvard.edu> Message-ID: <67B4B5166383D848A0565AA7491841F93082FAA6EF@RAD-VMSRVEXV2.rad.wustl.edu> That sound wonderful! Also, experience tell me that having sample images from multiple scanners (different ages or versions) from multiple vendors is useful. Even though everyone uses the DICOM standard, sometimes people utilize different combinations of features from the standard. (This is a nice way of saying not everyone interprets the standard in compatible fashions.) So having lots of variations is helpful in ferreting out potential problems during testing. Does anyone have such a collection? If not, I can ask Steve Moore when he gets back if some of the data collected during the IHE Connectathons could be used. -----Original Message----- From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Bill Lorensen Sent: Monday, April 12, 2010 10:20 AM To: Steve Pieper Cc: ctk-developers at commontk.org Subject: Re: [Ctk-developers] CTK Dashboard: A DICOM data collection for testing ? Folks, I have a set of 6 dicom series that scan the same phantom in six different directions. I'll be happy to contribute these. They were created a few years ago at GE Research as part of our NA-MIC work. They are useful to see if your code properly handles the direction cosines contained in the dicom header. Bill On Mon, Apr 12, 2010 at 10:30 AM, Steve Pieper wrote: > > Hi Luis - > > Here are some sharable example dicom files that we have been using to test > the indexer: > > http://www.slicer.org/slicerWiki/index.php/File:Dicom-database-examples-2010-03-09.zip > > (note this also includes some non-dicom files - but this is good for > testing!). > > It would be great for ctest to automatically grab these files from a URL and > put them in a local cache for testing purposes. We could either use the > existing wiki URL or move them to midas... > > -Steve > > > > p.s. > There's some discussion of the indexer here for background: > > http://www.slicer.org/slicerWiki/index.php/DICOM:Database > > > p.p.s. thanks, Luis, for being the voice of code quality! > > > > On Apr/9/10 10:45 AM, Luis Ibanez wrote: >> >> Hi Marco, >> >> >> Thanks for taking on the task of improving code quality. >> >> >> Here are a couple of ideas: >> >> 1) In IGSTK we included a couple of DICOM files in the >> source code repository itself in order to provide testing >> of basic functionalities. This is OK for "Unit-Testing". >> (and has to be limited to a couple of slices, since you >> don't want a source code repository to carry more than >> 10% of data. >> >> This simple data, however, insufficient for "Acceptance-Tests" >> (that is, tests that verify the code under realistic conditions >> from the point of view of a final user). >> >> so >> >> 2) We could host a set of realistic DICOM series in the MIDAS >> server, and setup CMake to download them into testing >> machines as part of the superbuild. It will be important to >> include in that collection, a set of "bad" datasets that exercise >> error conditions in the code. >> >> That is, we want to include DICOM images that are not compliant, >> and we want to verify that the code rejects them accordingly. >> >> >> >> Does DMTK has a data-testing collection that we could use ? >> >> and if so, it is redistributable ? >> >> >> >> Luis >> >> >> --------------------------------------------------------------------------- >> On Fri, Apr 9, 2010 at 10:36 AM, Marco Nolden >> wrote: >>> >>> On 04/09/2010 04:21 PM, Luis Ibanez wrote: >>> >>> The dubious honor of being the WCFOD: >>> >>> Worst Code-Covered File of the Day >>> >>> >>> >>> >>> http://my.cdash.org/viewCoverage.php?buildid=58100 >>> >>> >>> >>> >>> >>> Hi, >>> >>> 2nd on that list is ./Libs/DICOM/Core/ctkDICOMIndexer.cxx, the one I >>> would >>> take care of.. To write a meaningful test the dartclient needs access to >>> a >>> directory containing dicom images from several different patients, >>> studies >>> and series. Any ideas how we could provide that? Could the superbuild >>> download and extract the sample archive before running the tests? >>> >>> Best >>> Marco >>> >>> >>> >>> >>> Does anyone cares about adopting this file ? >>> >>> >>> Otherwise we will write tests for it today >>> under the code-welfare program. >>> >>> >>> Please let me know, >>> >>> >>> Thanks >>> >>> >>> Luis >>> _______________________________________________ >>> Ctk-developers mailing list >>> Ctk-developers at commontk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>> >>> >>> -- >>> ---------------------------------------------------------------------- >>> Dipl.-Inform. Med. Marco Nolden >>> Deutsches Krebsforschungszentrum (German Cancer Research Center) >>> Div. Medical& Biological Informatics Tel: (+49) 6221-42 2325 >>> Im Neuenheimer Feld 280 Fax: (+49) 6221-42 2345 >>> D-69120 Heidelberg eMail: M.Nolden at dkfz.de >>> >>> _______________________________________________ >>> Ctk-developers mailing list >>> Ctk-developers at commontk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>> >>> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers The material in this message is private and may contain Protected Healthcare Information (PHI). If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail. From julien.finet at kitware.com Mon Apr 12 18:04:23 2010 From: julien.finet at kitware.com (Julien Finet) Date: Mon, 12 Apr 2010 14:04:23 -0400 Subject: [Ctk-developers] CTK Dashboard: A DICOM data collection for testing ? In-Reply-To: <67B4B5166383D848A0565AA7491841F93082FAA6EF@RAD-VMSRVEXV2.rad.wustl.edu> References: <4BC32EA1.5090200@bwh.harvard.edu> <67B4B5166383D848A0565AA7491841F93082FAA6EF@RAD-VMSRVEXV2.rad.wustl.edu> Message-ID: <1271095463.19760.5.camel@Nokia-N900-51-1> We would be happy to host all the data on MIDAS. julien. ----- Original message ----- > That sound wonderful! > > Also, experience tell me that having sample images from multiple scanners > (different ages or versions) from multiple vendors is useful.? Even though > everyone uses the DICOM standard, sometimes people utilize different > combinations of features from the standard.? (This is a nice way of saying not > everyone interprets the standard in compatible fashions.)? So having lots of > variations is helpful in ferreting out potential problems during testing.? Does > anyone have such a collection?? If not, I can ask Steve Moore when he gets back > if some of the data collected during the IHE Connectathons could be used. > > > > -----Original Message----- > From: ctk-developers-bounces at commontk.org > [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Bill Lorensen Sent: > Monday, April 12, 2010 10:20 AM To: Steve Pieper > Cc: ctk-developers at commontk.org > Subject: Re: [Ctk-developers] CTK Dashboard: A DICOM data collection for testing > ? > > Folks, > > I have a set of 6 dicom series that scan the same phantom in six > different directions. I'll be happy to contribute these. They were > created a few years ago at GE Research as part of our NA-MIC work. > They are useful to see if your code properly handles the direction > cosines contained in the dicom header. > > Bill > > On Mon, Apr 12, 2010 at 10:30 AM, Steve Pieper wrote: > > > > Hi Luis - > > > > Here are some sharable example dicom files that we have been using to test > > the indexer: > > > > http://www.slicer.org/slicerWiki/index.php/File:Dicom-database-examples-2010-03-09.zip > > > > (note this also includes some non-dicom files - but this is good for > > testing!). > > > > It would be great for ctest to automatically grab these files from a URL and > > put them in a local cache for testing purposes.? We could either use the > > existing wiki URL or move them to midas... > > > > -Steve > > > > > > > > p.s. > > There's some discussion of the indexer here for background: > > > > http://www.slicer.org/slicerWiki/index.php/DICOM:Database > > > > > > p.p.s. thanks, Luis, for being the voice of code quality! > > > > > > > > On Apr/9/10 10:45 AM, Luis Ibanez wrote: > > > > > > Hi Marco, > > > > > > > > > Thanks for taking on the task of improving code quality. > > > > > > > > > Here are a couple of ideas: > > > > > > 1) In IGSTK we included a couple of DICOM files in the > > >? ? ? ? source code repository itself in order to provide testing > > >? ? ? ? of basic functionalities.? This is? OK for "Unit-Testing". > > >? ? ? ? (and has to be limited to a couple of slices, since you > > >? ? ? ? don't want a source code repository to carry more than > > >? ? ? ? 10% of data. > > > > > >? ? ? ? This simple data, however, insufficient for "Acceptance-Tests" > > >? ? ? ? (that is, tests that verify the code under realistic conditions > > >? ? ? ? from the point of view of a final user). > > > > > > so > > > > > > 2) We could host a set of realistic DICOM series in the MIDAS > > >? ? ? ? server, and setup CMake to download them into testing > > >? ? ? ? machines as part of the superbuild. It will be important to > > >? ? ? ? include in that collection, a set of "bad" datasets that exercise > > >? ? ? ? error conditions in the code. > > > > > >? ? ? ? That is, we want to include DICOM images that are not compliant, > > >? ? ? ? and we want to verify that the code rejects them accordingly. > > > > > > > > > > > > Does DMTK has a data-testing collection that we could use ? > > > > > > and if so, it is redistributable ? > > > > > > > > > > > >? ? ? ? Luis > > > > > > > > > --------------------------------------------------------------------------- > > > On Fri, Apr 9, 2010 at 10:36 AM, Marco Nolden > > > ? wrote: > > > > > > > > On 04/09/2010 04:21 PM, Luis Ibanez wrote: > > > > > > > > The dubious honor of being the WCFOD: > > > > > > > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Worst Code-Covered File of the Day > > > > > > > > > > > > > > > > > > > > http://my.cdash.org/viewCoverage.php?buildid=58100 > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > 2nd on that list is ./Libs/DICOM/Core/ctkDICOMIndexer.cxx, the one I > > > > would > > > > take care of.. To write a meaningful test the dartclient needs access to > > > > a > > > > directory containing dicom images from several different patients, > > > > studies > > > > and series. Any ideas how we could provide that? Could the superbuild > > > > download and extract the sample archive before running the tests? > > > > > > > > Best > > > > Marco > > > > > > > > > > > > > > > > > > > > Does anyone cares about adopting this file ? > > > > > > > > > > > > Otherwise we will write tests for it today > > > > under the code-welfare program. > > > > > > > > > > > >? ? ? Please let me know, > > > > > > > > > > > >? ? ? ? ? ? ? ? ? ? Thanks > > > > > > > > > > > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Luis > > > > _______________________________________________ > > > > Ctk-developers mailing list > > > > Ctk-developers at commontk.org > > > > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > > > > > > > > > > > -- > > > > ---------------------------------------------------------------------- > > > > Dipl.-Inform. Med. Marco Nolden > > > > Deutsches Krebsforschungszentrum? ? ? ? ? ? (German Cancer Research Center) > > > > Div. Medical&? Biological Informatics? ? ? ? ? ? ? ? ? Tel: (+49) 6221-42 2325 > > > > Im Neuenheimer Feld 280? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Fax: (+49) 6221-42 2345 > > > > D-69120 Heidelberg? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? eMail: M.Nolden at dkfz.de > > > > > > > > _______________________________________________ > > > > Ctk-developers mailing list > > > > Ctk-developers at commontk.org > > > > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > > > > > > > > > > _______________________________________________ > > > Ctk-developers mailing list > > > Ctk-developers at commontk.org > > > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > > > _______________________________________________ > > Ctk-developers mailing list > > Ctk-developers at commontk.org > > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > The material in this message is private and may contain Protected Healthcare > Information (PHI).? If you are not the intended recipient, be advised that any > unauthorized use, disclosure, copying or the taking of any action in reliance on > the contents of this information is strictly prohibited.? If you have received > this email in error, please immediately notify the sender via telephone or > return mail. _______________________________________________ Ctk-developers > mailing list Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From viceconti at tecno.ior.it Tue Apr 13 12:42:52 2010 From: viceconti at tecno.ior.it (Marco Viceconti) Date: Tue, 13 Apr 2010 14:42:52 +0200 Subject: [Ctk-developers] EU participation Message-ID: <81EA6BC8-73FB-4249-8A45-66E10EBDAF3E@tecno.ior.it> Hi everybody; a couple of recents email inspired me some comments, which I shall divide on multiple emails to keep the treads separated. First a general note: the EU arm of the CTK community in these days has not been so active because today is the deadline for the largest call for proposals in the VPH domain, so we are all snowed under. The good news is that thanks to the excellent work of many CTK partners, steered by our friends at INRIAS, the eXCITe proposal has been finalised and is now being submitted. If approved this grant will to many of us the resources to extend CTK with some hopefully fancy additions. Cheers Marco -------------------------------------------------- MARCO VICECONTI, PhD (viceconti at tecno.ior.it) Laboratorio di Tecnologia Medica tel. 39-051-6366865 Istituto Ortopedico Rizzoli fax. 39-051-6366863 via di Barbiano 1/10, 40136 - Bologna, Italy Tiger! Tiger! Burning bright in the forest of the night, what immortal hand or eye could frame thy fearful symmetry? -------------------------------------------------- Opinions expressed here do not necessarily reflect those of my employer From stephen.aylward at kitware.com Tue Apr 13 13:03:49 2010 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Tue, 13 Apr 2010 09:03:49 -0400 Subject: [Ctk-developers] EU participation In-Reply-To: <81EA6BC8-73FB-4249-8A45-66E10EBDAF3E@tecno.ior.it> References: <81EA6BC8-73FB-4249-8A45-66E10EBDAF3E@tecno.ior.it> Message-ID: Congratulations on the submission! Such funding would be outstanding for CTK! Would a summary/short version of the proposal be helpful in establishing a roadmap for or in some way advertising CTK? s On Tue, Apr 13, 2010 at 8:42 AM, Marco Viceconti wrote: > Hi everybody; a couple of recents email inspired me some comments, which I > shall divide on multiple emails to keep the treads separated. > > First a general note: the EU arm of the CTK community in these days has not > been so active because today is the deadline for the largest call for > proposals in the VPH domain, so we are all snowed under. > > The good news is that thanks to the excellent work of many CTK partners, > steered by our friends at INRIAS, the eXCITe proposal has been finalised and > is now being submitted. ?If approved this grant will to many of us the > resources to extend CTK with some hopefully fancy additions. > > Cheers > > Marco > > > -------------------------------------------------- > MARCO VICECONTI, PhD ? ? ? ? ? ? ? ? ? ? ? ? ? ? (viceconti at tecno.ior.it) > Laboratorio di Tecnologia Medica ? ? ? ? ? ? ?tel. ? 39-051-6366865 > Istituto Ortopedico Rizzoli ? ? ? ? ? ? ? ? ? ? ? ? ? ?fax. ? 39-051-6366863 > via di Barbiano 1/10, 40136 - Bologna, Italy > > Tiger! Tiger! Burning bright in the forest of the night, > what immortal hand or eye could frame thy fearful symmetry? > -------------------------------------------------- > Opinions expressed here do not necessarily reflect those of my employer > > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From viceconti at tecno.ior.it Tue Apr 13 13:04:26 2010 From: viceconti at tecno.ior.it (Marco Viceconti) Date: Tue, 13 Apr 2010 15:04:26 +0200 Subject: [Ctk-developers] COPYRIGHT & LICENSING In-Reply-To: References: <4BC313AA.6050408@bwh.harvard.edu> Message-ID: If I understand correctly the discussion so far, it seems that under an appropriate FOSS license the tracking of copyright is unnecessary. Still, I disagree that it is irrelevant, as in addition to the personal proudness there is also an institutional proudness, that tracking copyright to the institution that contributed with a portion of code, somehow sustains. Because of this I would suggest that each contributor should have the right to keep the copyright to his-her own institution. For the license, I agree with Luis that the choice is between an handful of options, such as MIT, BSD and Apache 2.0 licenses. Indeed, this point was extensively discussed in one of the first meetings of the CTK Group, as correctly pointed out by J?rg Riesmeier. In that meeting we noticed that a) many of our frameworks and libraries are distributed under BSD, and b) that BSD has all the features we thought the CTK should had. http://www.commontk.org/cgi-bin/trac.cgi/wiki/Whitepaper#BSDstylelicense Of course nothing is carved in stone, but I do not thing we should simply ignore what has been already extensively discussed. Thus, I would suggest to consider the topic in this light: there is decision in favour of BSD. Is there any argument that makes Apache 2.0 preferable over BSD? If we opt for Apache 2.0, is there any problem in re-using inside CTK code licensed under BSD, such as DCMTK? A last comment: while Apache 2.0 is clearly a more modern option, BSD has beauty of being the clearest license you can read. Now if it is true, like many says that in the end you get the same protection with both, I would opt for BSD if nothing else only for this. Cheers Marco Il giorno 12 Apr 2010, alle ore 16:23, Luis Ibanez ha scritto: > > I agree with Bill, > > The choice of a good License is more important that who holds the > Copyright (and patents, and trademarks) associated with the code. > > > In practice, tracing the Copyright holders of code in an Open Source > project is an impossible task. > > > Whoever is contributing code to an Open Source project with the > intention of conserving ownership or control over such code has > flawed understanding of how software development works in a > peer-production environment. > > > Files tend to (and *should*) be modified by many different developers, > who are affiliated to different institutions. Every institution will > hold the > copyright of every modification. > > > You may know "who" is the copyright holder of a file, the first day > that file > is committed. But after ten years of this file being modified and > retouched > by twenty other developers from ten other institutions, you have a > file > where > > > 55% of the lines are copyrighted by institution A > 27% by institution B > 13% by institution C.. > ... and so on. > > > In a well-managed open source project, such modifications of any given > file by many different developers *is expected* to happen. > > When a file has only been touched by a single developer, that's an > indication > that nobody else in the project cares about such file, and that the > project has > poor practices of code review and suffers from lack of participation. > > So, even if any given organization want to conserve "ownership" of the > code, that is simply unrealistic in practice. > > Assigning copyright of the code to a non-for-profit organization is > actually > a way of protecting the developers (and their institutions). > > This is discussed in great detail in: > > "Intellectual Property and Open Source > A Practical Guide to Protecting Code" > by Van Lindberg > http://oreilly.com/catalog/9780596517960 > > > > > In any case, what is more important is to chose a License, that make > irrelevant > (and unnecessary) to track ownership of the source code. The MIT, > BSD and > Apache 2.0 licenses are typical good choices that satisfy such > condition. > > > The Apache 2.0 license is particularly attractive in this case > because it is > the only one from this group, that includes specific clauses about > code > contributions. > > > > Luis > > > > ------------------------------------------------------------------------------------------- > On Mon, Apr 12, 2010 at 8:39 AM, Bill Lorensen > wrote: > I agree with that license is more important that the copyright > holders. > > In VTK, many files have multiple copyrights, but all share the same > license. > > Bill > > On Mon, Apr 12, 2010 at 8:35 AM, Ron Kikinis > wrote: > > Luis, > > > > The apache license sounds reasonable to me. In terms of making ISC > the owner > > of the copyright: > > As you know, we have taken a different approach with Slicer in > that the > > contributors keep the copyright and only grant an irrevocable and > unlimited > > license for use in Slicer (I am not a lawyer so this is not legal > language). > > > > On an other point: ISC was created to hold the copyright for ITK. > The > > website does not really reflect the more recent additions of cmake > and > > IGSTK. The board of directors primarily reflects ITK and would > probably > > require some updates. > > > > One question: how "dictator proof" is ISC? > > > > Ron > > > > > > > > On 4/9/10 10:36 AM, Luis Ibanez wrote: > >> > >> Yes, > >> it is not the most amusing conversation to have, > >> but it is better to do this early... > >> > >> > >> 1) Most files in CTK are lacking Copyright > >> notices and an explicit License. > >> > >> 2) There is not LICENCE file at the top of > >> the source tree. > >> > >> > >> > >> I propose that we assign the copyright of the source code > >> to the Insight Software Consortium (ISC), and that we > >> distribute the code under an Apache 2.0 License. > >> > >> http://www.opensource.org/licenses/apache2.0.php > >> > >> > >> > >> The ISC is the organization that holds the copyright of > >> > >> * ITK > >> * CMake (along with Kitware) > >> * IGSTK > >> > >> > >> More information about the ISC at: > >> > >> http://www.insightsoftwareconsortium.org/ > >> > >> > >> It will also be important for your respective organizations > >> to join the ISC, or for you to join as individuals, so you > >> help ensure that the CTK project is managed as you > >> intended. > >> > >> > >> Every day that passes without having a clear License > >> and Copyright statement is a day were we are brewing > >> a recipe for disaster. > >> > >> > >> > >> If someone needs to be persuaded, we can provide details > >> on the horror story of how much trouble we are having in ITK > >> with source code of dubious origin (no copyright notice nor > >> license) that we adopted from www.netlib.org.... > >> > >> > >> > >> Luis > >> _______________________________________________ > >> Ctk-developers mailing list > >> Ctk-developers at commontk.org > >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > > > -- > > Ron Kikinis, M.D., > > Robert Greenes Distinguished Director of Biomedical Informatics > > Professor of Radiology, Harvard Medical School > > Director, Surgical Planning Laboratory > > http://www.spl.harvard.edu/~kikinis > > _______________________________________________ > > Ctk-developers mailing list > > Ctk-developers at commontk.org > > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers -------------------------------------------------- MARCO VICECONTI, PhD (viceconti at tecno.ior.it) Laboratorio di Tecnologia Medica tel. 39-051-6366865 Istituto Ortopedico Rizzoli fax. 39-051-6366863 via di Barbiano 1/10, 40136 - Bologna, Italy Tiger! Tiger! Burning bright in the forest of the night, what immortal hand or eye could frame thy fearful symmetry? -------------------------------------------------- Opinions expressed here do not necessarily reflect those of my employer From viceconti at tecno.ior.it Tue Apr 13 13:11:52 2010 From: viceconti at tecno.ior.it (Marco Viceconti) Date: Tue, 13 Apr 2010 15:11:52 +0200 Subject: [Ctk-developers] a story of two lists Message-ID: <0147E11D-4420-4A77-B9F2-431A7D7DAFBF@tecno.ior.it> Dear All: I am very happy to see that the CTK community is really starting up. But I see a potential risk in the current communication model. As it is now, we have a single mailing list to discuss everything from the single cmake instruction that breaks the dashboard to the copyright issues. I know some of you have a role in your organisations that cover this entire spectrum, but I also know that in my organisation, and I suspect in other as well, the persons that are interested in some topics are not the same that are interested in others. If this is true for others I would ask we split the list in two, ctk- developers and ctk-governance. In the first we shall continue to discuss all implementation problems, in the second issues such as licensing, copyright, architectural choices, community development, etc. Of course one would be allowed so sign up to both, so that for those who cover all aspects would not change much. But for the others we could partition the communication more effectively, which usually improves the level of participation. Comments are welcome Marco -------------------------------------------------- MARCO VICECONTI, PhD (viceconti at tecno.ior.it) Laboratorio di Tecnologia Medica tel. 39-051-6366865 Istituto Ortopedico Rizzoli fax. 39-051-6366863 via di Barbiano 1/10, 40136 - Bologna, Italy Tiger! Tiger! Burning bright in the forest of the night, what immortal hand or eye could frame thy fearful symmetry? -------------------------------------------------- Opinions expressed here do not necessarily reflect those of my employer From tarboxl at mir.wustl.edu Tue Apr 13 13:49:48 2010 From: tarboxl at mir.wustl.edu (Tarbox, Lawrence) Date: Tue, 13 Apr 2010 08:49:48 -0500 Subject: [Ctk-developers] a story of two lists In-Reply-To: <0147E11D-4420-4A77-B9F2-431A7D7DAFBF@tecno.ior.it> References: <0147E11D-4420-4A77-B9F2-431A7D7DAFBF@tecno.ior.it> Message-ID: <67B4B5166383D848A0565AA7491841F93082F06AC4@RAD-VMSRVEXV2.rad.wustl.edu> Good idea. -----Original Message----- From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Marco Viceconti Sent: Tuesday, April 13, 2010 8:12 AM To: ctk-developers at commontk.org Subject: [Ctk-developers] a story of two lists Dear All: I am very happy to see that the CTK community is really starting up. But I see a potential risk in the current communication model. As it is now, we have a single mailing list to discuss everything from the single cmake instruction that breaks the dashboard to the copyright issues. I know some of you have a role in your organisations that cover this entire spectrum, but I also know that in my organisation, and I suspect in other as well, the persons that are interested in some topics are not the same that are interested in others. If this is true for others I would ask we split the list in two, ctk- developers and ctk-governance. In the first we shall continue to discuss all implementation problems, in the second issues such as licensing, copyright, architectural choices, community development, etc. Of course one would be allowed so sign up to both, so that for those who cover all aspects would not change much. But for the others we could partition the communication more effectively, which usually improves the level of participation. Comments are welcome Marco -------------------------------------------------- MARCO VICECONTI, PhD (viceconti at tecno.ior.it) Laboratorio di Tecnologia Medica tel. 39-051-6366865 Istituto Ortopedico Rizzoli fax. 39-051-6366863 via di Barbiano 1/10, 40136 - Bologna, Italy Tiger! Tiger! Burning bright in the forest of the night, what immortal hand or eye could frame thy fearful symmetry? -------------------------------------------------- Opinions expressed here do not necessarily reflect those of my employer _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers The material in this message is private and may contain Protected Healthcare Information (PHI). If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail. From stephen.aylward at kitware.com Tue Apr 13 13:45:23 2010 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Tue, 13 Apr 2010 09:45:23 -0400 Subject: [Ctk-developers] COPYRIGHT & LICENSING In-Reply-To: References: <4BC313AA.6050408@bwh.harvard.edu> Message-ID: Hi, The Apache 2.0 license is actually a BSD-style license. It is the new-BSD license with two additional paragraphs that are important based on our experiences with ITK. Note that ITK is now released under the Apache 2.0 license. There are some great articles on the benefits of Apache 2.0, such as "Apache?better than GPL for open-source business?" http://news.cnet.com/8301-13505_3-10229817-16.html The full text of the license is available at: http://www.apache.org/licenses/LICENSE-2.0.html A FAQ on the Apache 2.0 license is at: http://www.apache.org/foundation/licence-FAQ.html Below is my interpretation of those two additional paragraphs: First paragraph ============= "Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions." The above says that by contributing changes back to the main repository, you're agreeing to release your changes also under the Apache 2.0 license. Without this additional paragraph we'll need to specify licensing terms for every change to the code made by any contributor - that isn't feasible. Again, this paragraph does not request copyright transfer, just a license to redistribute, use etc. Second paragraph =============== "Grant of Patent License.?Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed." This paragraph says that if you submit code to the repository you're also granting everyone a license to use that code even if you've filed for a patent that the code implements. Consider that if someone adds something to the CTK core that is covered by one of their own patents, then we may end up being sued (it really does happen way too often in America), having to pay them money to use CTK, or having to re-write that code. Hope this helps, Stephen On Tue, Apr 13, 2010 at 9:04 AM, Marco Viceconti wrote: > If I understand correctly the discussion so far, it seems that under an > appropriate FOSS license the tracking of copyright is unnecessary. Still, I > disagree that it is irrelevant, as in addition to the personal proudness > there is also an institutional proudness, that tracking copyright to the > institution that contributed with a portion of code, somehow sustains. > ?Because of this I would suggest that each contributor should have the right > to keep the copyright to his-her own institution. > > For the license, I agree with Luis that the choice is between an handful of > options, such as MIT, BSD and Apache 2.0 licenses. ?Indeed, this point was > extensively discussed in one of the first meetings of the CTK Group, as > correctly pointed out by J?rg Riesmeier. ?In that meeting we noticed that a) > many of our frameworks and libraries are distributed under BSD, and b) that > BSD has all the features we thought the CTK should had. > http://www.commontk.org/cgi-bin/trac.cgi/wiki/Whitepaper#BSDstylelicense > > Of course nothing is carved in stone, but I do not thing we should simply > ignore what has been already extensively discussed. ?Thus, I would suggest > to consider the topic in this light: there is decision in favour of BSD. ?Is > there any argument that makes Apache 2.0 preferable over BSD? If we opt for > Apache 2.0, is there any problem in re-using inside CTK code licensed under > BSD, such as DCMTK? > > A last comment: while Apache 2.0 is clearly a more modern option, BSD has > beauty of being the clearest license you can read. ?Now if it is true, like > many says that in the end you get the same protection with both, I would opt > for BSD if nothing else only for this. > > Cheers > > Marco > > > > Il giorno 12 Apr 2010, alle ore 16:23, Luis Ibanez ha scritto: > >> >> I agree with Bill, >> >> The choice of a good License is more important that who holds the >> Copyright (and patents, and trademarks) associated with the code. >> >> >> In practice, tracing the Copyright holders of code in an Open Source >> project is an impossible task. >> >> >> Whoever is contributing code to an Open Source project with the >> intention of conserving ownership or control over such code has >> flawed understanding of how software development works in a >> peer-production environment. >> >> >> Files tend to (and *should*) be modified by many different developers, >> who are affiliated to different institutions. Every institution will hold >> the >> copyright of every modification. >> >> >> You may know "who" is the copyright holder of a file, the first day that >> file >> is committed. But after ten years of this file being modified and >> retouched >> by twenty other developers from ten other institutions, you have a file >> where >> >> >> 55% of the lines are copyrighted by institution A >> 27% by institution B >> 13% by institution C.. >> ... and so on. >> >> >> In a well-managed open source project, such modifications of any given >> file by many different developers *is expected* to happen. >> >> When a file has only been touched by a single developer, that's an >> indication >> that nobody else in the project cares about such file, and that the >> project has >> poor practices of code review and suffers from lack of participation. >> >> So, even if any given organization want to conserve "ownership" of the >> code, that is simply unrealistic in practice. >> >> Assigning copyright of the code to a non-for-profit organization is >> actually >> a way of protecting the developers (and their institutions). >> >> This is discussed in great detail in: >> >> ?"Intellectual Property and Open Source >> ?A Practical Guide to Protecting Code" >> ?by Van Lindberg >> ?http://oreilly.com/catalog/9780596517960 >> >> >> >> >> In any case, what is more important is to chose a License, that make >> irrelevant >> (and unnecessary) to track ownership of the source code. The MIT, BSD and >> Apache 2.0 licenses are typical good choices that satisfy such condition. >> >> >> The Apache 2.0 license is particularly attractive in this case because it >> is >> the only one from this group, that includes specific clauses about code >> contributions. >> >> >> >> ? ? ? ? Luis >> >> >> >> >> ------------------------------------------------------------------------------------------- >> On Mon, Apr 12, 2010 at 8:39 AM, Bill Lorensen >> wrote: >> I agree with that license is more important that the copyright holders. >> >> In VTK, many files have multiple copyrights, but all share the same >> license. >> >> Bill >> >> On Mon, Apr 12, 2010 at 8:35 AM, Ron Kikinis >> wrote: >> > Luis, >> > >> > The apache license sounds reasonable to me. In terms of making ISC the >> > owner >> > of the copyright: >> > As you know, we have taken a different approach with Slicer in that the >> > contributors keep the copyright and only grant an irrevocable and >> > unlimited >> > license for use in Slicer (I am not a lawyer so this is not legal >> > language). >> > >> > On an other point: ISC was created to hold the copyright for ITK. The >> > website does not really reflect the more recent additions of cmake and >> > IGSTK. The board of directors primarily reflects ITK and would probably >> > require some updates. >> > >> > One question: how "dictator proof" is ISC? >> > >> > Ron >> > >> > >> > >> > On 4/9/10 10:36 AM, Luis Ibanez wrote: >> >> >> >> Yes, >> >> it is not the most amusing conversation to have, >> >> but it is better to do this early... >> >> >> >> >> >> ? ?1) Most files in CTK are lacking Copyright >> >> ? ? ? ?notices and an explicit License. >> >> >> >> ? ?2) There is not LICENCE file at the top of >> >> ? ? ? ?the source tree. >> >> >> >> >> >> >> >> I propose that we assign the copyright of the source code >> >> to the Insight Software Consortium (ISC), and that we >> >> distribute the code under an Apache 2.0 License. >> >> >> >> ? http://www.opensource.org/licenses/apache2.0.php >> >> >> >> >> >> >> >> The ISC is the organization that holds the copyright of >> >> >> >> ? ? ? ? ? * ?ITK >> >> ? ? ? ? ? * ?CMake (along with Kitware) >> >> ? ? ? ? ? * IGSTK >> >> >> >> >> >> More information about the ISC at: >> >> >> >> ? ? http://www.insightsoftwareconsortium.org/ >> >> >> >> >> >> It will also be important for your respective organizations >> >> to join the ISC, or for you to join as individuals, so you >> >> help ensure that the CTK project is managed as you >> >> intended. >> >> >> >> >> >> Every day that passes without having a clear License >> >> and Copyright statement is a day were we are brewing >> >> a recipe for disaster. >> >> >> >> >> >> >> >> If someone needs to be persuaded, we can provide details >> >> on the horror story of how much trouble we are having in ITK >> >> with source code of dubious origin (no copyright notice nor >> >> license) that we adopted from ? www.netlib.org.... >> >> >> >> >> >> >> >> ? ? ? Luis >> >> _______________________________________________ >> >> Ctk-developers mailing list >> >> Ctk-developers at commontk.org >> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> > >> > -- >> > Ron Kikinis, M.D., >> > Robert Greenes Distinguished Director of Biomedical Informatics >> > Professor of Radiology, Harvard Medical School >> > Director, Surgical Planning Laboratory >> > http://www.spl.harvard.edu/~kikinis >> > _______________________________________________ >> > Ctk-developers mailing list >> > Ctk-developers at commontk.org >> > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> > >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > -------------------------------------------------- > MARCO VICECONTI, PhD ? ? ? ? ? ? ? ? ? ? ? ? ? ? (viceconti at tecno.ior.it) > Laboratorio di Tecnologia Medica ? ? ? ? ? ? ?tel. ? 39-051-6366865 > Istituto Ortopedico Rizzoli ? ? ? ? ? ? ? ? ? ? ? ? ? ?fax. ? 39-051-6366863 > via di Barbiano 1/10, 40136 - Bologna, Italy > > Tiger! Tiger! Burning bright in the forest of the night, > what immortal hand or eye could frame thy fearful symmetry? > -------------------------------------------------- > Opinions expressed here do not necessarily reflect those of my employer > > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From tarboxl at mir.wustl.edu Tue Apr 13 15:16:43 2010 From: tarboxl at mir.wustl.edu (Tarbox, Lawrence) Date: Tue, 13 Apr 2010 10:16:43 -0500 Subject: [Ctk-developers] COPYRIGHT & LICENSING In-Reply-To: References: <4BC313AA.6050408@bwh.harvard.edu> Message-ID: <67B4B5166383D848A0565AA7491841F93082F06AD3@RAD-VMSRVEXV2.rad.wustl.edu> I concur with Stephen. The pure BSD license does not address certain key issues, such as patents, trademarks, and contributions, that potentially could be very problematic in an open source project with multiple contributors from multiple organizations. The Apache license closes those holes, while still being essentially a BSD license at its core. (Compare the text of clauses 3, 8, and 9 with the BSD license - they are nearly identical to the BSD license.) As far as I know, there is little problem including BSD code in a project licensed under Apache, as long as there are no problems with patent or trademark infringements in the BSD code. My recollection of the previous discussions was more that we did not want CTK to use a 'copyleft' license, such as GPL, and that we preferred a more commercial friendly license with terms similar to BSD. The discussion brought out that most of the code that we already use has been released under licenses with terms similar to BSD, though not everyone was using a pure BSD license. I believe Apache has terms similar to and compatible with BSD, and would be a better match to our needs than simple BSD. -----Original Message----- From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Stephen Aylward Sent: Tuesday, April 13, 2010 8:45 AM To: Marco Viceconti Cc: ctk-developers at commontk.org Subject: Re: [Ctk-developers] COPYRIGHT & LICENSING Hi, The Apache 2.0 license is actually a BSD-style license. It is the new-BSD license with two additional paragraphs that are important based on our experiences with ITK. Note that ITK is now released under the Apache 2.0 license. There are some great articles on the benefits of Apache 2.0, such as "Apache better than GPL for open-source business?" http://news.cnet.com/8301-13505_3-10229817-16.html The full text of the license is available at: http://www.apache.org/licenses/LICENSE-2.0.html A FAQ on the Apache 2.0 license is at: http://www.apache.org/foundation/licence-FAQ.html Below is my interpretation of those two additional paragraphs: First paragraph ============= "Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions." The above says that by contributing changes back to the main repository, you're agreeing to release your changes also under the Apache 2.0 license. Without this additional paragraph we'll need to specify licensing terms for every change to the code made by any contributor - that isn't feasible. Again, this paragraph does not request copyright transfer, just a license to redistribute, use etc. Second paragraph =============== "Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed." This paragraph says that if you submit code to the repository you're also granting everyone a license to use that code even if you've filed for a patent that the code implements. Consider that if someone adds something to the CTK core that is covered by one of their own patents, then we may end up being sued (it really does happen way too often in America), having to pay them money to use CTK, or having to re-write that code. Hope this helps, Stephen On Tue, Apr 13, 2010 at 9:04 AM, Marco Viceconti wrote: > If I understand correctly the discussion so far, it seems that under an > appropriate FOSS license the tracking of copyright is unnecessary. Still, I > disagree that it is irrelevant, as in addition to the personal proudness > there is also an institutional proudness, that tracking copyright to the > institution that contributed with a portion of code, somehow sustains. > Because of this I would suggest that each contributor should have the right > to keep the copyright to his-her own institution. > > For the license, I agree with Luis that the choice is between an handful of > options, such as MIT, BSD and Apache 2.0 licenses. Indeed, this point was > extensively discussed in one of the first meetings of the CTK Group, as > correctly pointed out by J?rg Riesmeier. In that meeting we noticed that a) > many of our frameworks and libraries are distributed under BSD, and b) that > BSD has all the features we thought the CTK should had. > http://www.commontk.org/cgi-bin/trac.cgi/wiki/Whitepaper#BSDstylelicense > > Of course nothing is carved in stone, but I do not thing we should simply > ignore what has been already extensively discussed. Thus, I would suggest > to consider the topic in this light: there is decision in favour of BSD. Is > there any argument that makes Apache 2.0 preferable over BSD? If we opt for > Apache 2.0, is there any problem in re-using inside CTK code licensed under > BSD, such as DCMTK? > > A last comment: while Apache 2.0 is clearly a more modern option, BSD has > beauty of being the clearest license you can read. Now if it is true, like > many says that in the end you get the same protection with both, I would opt > for BSD if nothing else only for this. > > Cheers > > Marco > > > > Il giorno 12 Apr 2010, alle ore 16:23, Luis Ibanez ha scritto: > >> >> I agree with Bill, >> >> The choice of a good License is more important that who holds the >> Copyright (and patents, and trademarks) associated with the code. >> >> >> In practice, tracing the Copyright holders of code in an Open Source >> project is an impossible task. >> >> >> Whoever is contributing code to an Open Source project with the >> intention of conserving ownership or control over such code has >> flawed understanding of how software development works in a >> peer-production environment. >> >> >> Files tend to (and *should*) be modified by many different developers, >> who are affiliated to different institutions. Every institution will hold >> the >> copyright of every modification. >> >> >> You may know "who" is the copyright holder of a file, the first day that >> file >> is committed. But after ten years of this file being modified and >> retouched >> by twenty other developers from ten other institutions, you have a file >> where >> >> >> 55% of the lines are copyrighted by institution A >> 27% by institution B >> 13% by institution C.. >> ... and so on. >> >> >> In a well-managed open source project, such modifications of any given >> file by many different developers *is expected* to happen. >> >> When a file has only been touched by a single developer, that's an >> indication >> that nobody else in the project cares about such file, and that the >> project has >> poor practices of code review and suffers from lack of participation. >> >> So, even if any given organization want to conserve "ownership" of the >> code, that is simply unrealistic in practice. >> >> Assigning copyright of the code to a non-for-profit organization is >> actually >> a way of protecting the developers (and their institutions). >> >> This is discussed in great detail in: >> >> "Intellectual Property and Open Source >> A Practical Guide to Protecting Code" >> by Van Lindberg >> http://oreilly.com/catalog/9780596517960 >> >> >> >> >> In any case, what is more important is to chose a License, that make >> irrelevant >> (and unnecessary) to track ownership of the source code. The MIT, BSD and >> Apache 2.0 licenses are typical good choices that satisfy such condition. >> >> >> The Apache 2.0 license is particularly attractive in this case because it >> is >> the only one from this group, that includes specific clauses about code >> contributions. >> >> >> >> Luis >> >> >> >> >> ------------------------------------------------------------------------------------------- >> On Mon, Apr 12, 2010 at 8:39 AM, Bill Lorensen >> wrote: >> I agree with that license is more important that the copyright holders. >> >> In VTK, many files have multiple copyrights, but all share the same >> license. >> >> Bill >> >> On Mon, Apr 12, 2010 at 8:35 AM, Ron Kikinis >> wrote: >> > Luis, >> > >> > The apache license sounds reasonable to me. In terms of making ISC the >> > owner >> > of the copyright: >> > As you know, we have taken a different approach with Slicer in that the >> > contributors keep the copyright and only grant an irrevocable and >> > unlimited >> > license for use in Slicer (I am not a lawyer so this is not legal >> > language). >> > >> > On an other point: ISC was created to hold the copyright for ITK. The >> > website does not really reflect the more recent additions of cmake and >> > IGSTK. The board of directors primarily reflects ITK and would probably >> > require some updates. >> > >> > One question: how "dictator proof" is ISC? >> > >> > Ron >> > >> > >> > >> > On 4/9/10 10:36 AM, Luis Ibanez wrote: >> >> >> >> Yes, >> >> it is not the most amusing conversation to have, >> >> but it is better to do this early... >> >> >> >> >> >> 1) Most files in CTK are lacking Copyright >> >> notices and an explicit License. >> >> >> >> 2) There is not LICENCE file at the top of >> >> the source tree. >> >> >> >> >> >> >> >> I propose that we assign the copyright of the source code >> >> to the Insight Software Consortium (ISC), and that we >> >> distribute the code under an Apache 2.0 License. >> >> >> >> http://www.opensource.org/licenses/apache2.0.php >> >> >> >> >> >> >> >> The ISC is the organization that holds the copyright of >> >> >> >> * ITK >> >> * CMake (along with Kitware) >> >> * IGSTK >> >> >> >> >> >> More information about the ISC at: >> >> >> >> http://www.insightsoftwareconsortium.org/ >> >> >> >> >> >> It will also be important for your respective organizations >> >> to join the ISC, or for you to join as individuals, so you >> >> help ensure that the CTK project is managed as you >> >> intended. >> >> >> >> >> >> Every day that passes without having a clear License >> >> and Copyright statement is a day were we are brewing >> >> a recipe for disaster. >> >> >> >> >> >> >> >> If someone needs to be persuaded, we can provide details >> >> on the horror story of how much trouble we are having in ITK >> >> with source code of dubious origin (no copyright notice nor >> >> license) that we adopted from www.netlib.org.... >> >> >> >> >> >> >> >> Luis >> >> _______________________________________________ >> >> Ctk-developers mailing list >> >> Ctk-developers at commontk.org >> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> > >> > -- >> > Ron Kikinis, M.D., >> > Robert Greenes Distinguished Director of Biomedical Informatics >> > Professor of Radiology, Harvard Medical School >> > Director, Surgical Planning Laboratory >> > http://www.spl.harvard.edu/~kikinis >> > _______________________________________________ >> > Ctk-developers mailing list >> > Ctk-developers at commontk.org >> > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> > >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > -------------------------------------------------- > MARCO VICECONTI, PhD (viceconti at tecno.ior.it) > Laboratorio di Tecnologia Medica tel. 39-051-6366865 > Istituto Ortopedico Rizzoli fax. 39-051-6366863 > via di Barbiano 1/10, 40136 - Bologna, Italy > > Tiger! Tiger! Burning bright in the forest of the night, > what immortal hand or eye could frame thy fearful symmetry? > -------------------------------------------------- > Opinions expressed here do not necessarily reflect those of my employer > > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers The material in this message is private and may contain Protected Healthcare Information (PHI). If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail. From stephen.aylward at kitware.com Tue Apr 13 15:52:52 2010 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Tue, 13 Apr 2010 11:52:52 -0400 Subject: [Ctk-developers] a story of two lists In-Reply-To: <67B4B5166383D848A0565AA7491841F93082F06AC4@RAD-VMSRVEXV2.rad.wustl.edu> References: <0147E11D-4420-4A77-B9F2-431A7D7DAFBF@tecno.ior.it> <67B4B5166383D848A0565AA7491841F93082F06AC4@RAD-VMSRVEXV2.rad.wustl.edu> Message-ID: I think having two lists is a good idea. Many people will simply subscribe to both - but different people will have different interests and levels of involvement. My thought is that perhaps the second list would be for people who want to track the community without knowing anything about the code (e.g., program officers at funding agencies, administrators, etc). As such, perhaps we should change the names and purposes of the list slightly: ctk-developers covers all things related to the code: architectural discussions, copyright, licensing, which libraries to include, etc. This is the really active, high-traffic list. ctk-announcements covers all things "public": advertising and organizational matters of the community: meetings, grant proposals, funding opportunities, etc. It is intended for the passive participants. Hence "announcements" It should not receive heavy traffic or people will unsubscribe. I don't feel strongly about this - but I think it might be hard to separate copyright from library inclusion discussions, implementation from architecture discussions, etc., and most of the time people join/leave lists based on traffic/spam. We should make it easy for everyone to track us and yet not involve them in every discussion. Stephen On Tue, Apr 13, 2010 at 9:49 AM, Tarbox, Lawrence wrote: > Good idea. > > -----Original Message----- > From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Marco Viceconti > Sent: Tuesday, April 13, 2010 8:12 AM > To: ctk-developers at commontk.org > Subject: [Ctk-developers] a story of two lists > > Dear All: > ? I am very happy to see that the CTK community is really starting > up. ?But I see a potential risk in the current communication model. > As it is now, we have a single mailing list to discuss everything from > the single cmake instruction that breaks the dashboard to the > copyright issues. ?I know some of you have a role in your > organisations that cover this entire spectrum, but I also know that in > my organisation, and I suspect in other as well, the persons that are > interested in some topics are not the same that are interested in > others. > > If this is true for others I would ask we split the list in two, ctk- > developers and ctk-governance. ?In the first we shall continue to > discuss all implementation problems, in the second issues such as > licensing, copyright, architectural choices, community development, etc. > > Of course one would be allowed so sign up to both, so that for those > who cover all aspects would not change much. But for the others we > could partition the communication more effectively, which usually > improves the level of participation. > > Comments are welcome > > Marco > > > > -------------------------------------------------- > MARCO VICECONTI, PhD > (viceconti at tecno.ior.it) > Laboratorio di Tecnologia Medica ? ? ? ? ? ? ?tel. ? 39-051-6366865 > Istituto Ortopedico Rizzoli ? ? ? ? ? ? ? ? ? ? ? ? ? ?fax. > 39-051-6366863 > via di Barbiano 1/10, 40136 - Bologna, Italy > > Tiger! Tiger! Burning bright in the forest of the night, > what immortal hand or eye could frame thy fearful symmetry? > -------------------------------------------------- > Opinions expressed here do not necessarily reflect those of my employer > > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > The material in this message is private and may contain Protected Healthcare Information (PHI). ?If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. ?If you have received this email in error, please immediately notify the sender via telephone or return mail. > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From viceconti at tecno.ior.it Wed Apr 14 11:53:02 2010 From: viceconti at tecno.ior.it (Marco Viceconti) Date: Wed, 14 Apr 2010 13:53:02 +0200 Subject: [Ctk-developers] COPYRIGHT & LICENSING In-Reply-To: <67B4B5166383D848A0565AA7491841F93082F06AD3@RAD-VMSRVEXV2.rad.wustl.edu> References: <4BC313AA.6050408@bwh.harvard.edu> <67B4B5166383D848A0565AA7491841F93082F06AD3@RAD-VMSRVEXV2.rad.wustl.edu> Message-ID: Lawrence is right to say that no one had strong opinions in favour of BSD as such, and in the end the decision was taken only because most existing codes represented around the table were already BSD. On the contrary there was strong consensus on staying away from copyleft licenses. Stephen point on patents is very relevant, so I recognise that it is probably a good idea to go for Apache 2.0 for CTK. As a side effect, we shall now revise this matter internally to B3C, and we might indeed decide to adopt Apache 2.0 also for MAF3. Cheers Marco Il giorno 13 Apr 2010, alle ore 17:16, Tarbox, Lawrence ha scritto: > I concur with Stephen. > > The pure BSD license does not address certain key issues, such as > patents, trademarks, and contributions, that potentially could be > very problematic in an open source project with multiple > contributors from multiple organizations. The Apache license closes > those holes, while still being essentially a BSD license at its > core. (Compare the text of clauses 3, 8, and 9 with the BSD license > - they are nearly identical to the BSD license.) > > As far as I know, there is little problem including BSD code in a > project licensed under Apache, as long as there are no problems with > patent or trademark infringements in the BSD code. > > My recollection of the previous discussions was more that we did not > want CTK to use a 'copyleft' license, such as GPL, and that we > preferred a more commercial friendly license with terms similar to > BSD. The discussion brought out that most of the code that we > already use has been released under licenses with terms similar to > BSD, though not everyone was using a pure BSD license. I believe > Apache has terms similar to and compatible with BSD, and would be a > better match to our needs than simple BSD. > > > > > > -----Original Message----- > From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org > ] On Behalf Of Stephen Aylward > Sent: Tuesday, April 13, 2010 8:45 AM > To: Marco Viceconti > Cc: ctk-developers at commontk.org > Subject: Re: [Ctk-developers] COPYRIGHT & LICENSING > > Hi, > > The Apache 2.0 license is actually a BSD-style license. It is the > new-BSD license with two additional paragraphs that are important > based on our experiences with ITK. Note that ITK is now released > under the Apache 2.0 license. > > There are some great articles on the benefits of Apache 2.0, such as > "Apache better than GPL for open-source business?" > http://news.cnet.com/8301-13505_3-10229817-16.html > > The full text of the license is available at: > http://www.apache.org/licenses/LICENSE-2.0.html > > A FAQ on the Apache 2.0 license is at: > http://www.apache.org/foundation/licence-FAQ.html > > Below is my interpretation of those two additional paragraphs: > > First paragraph > ============= > "Submission of Contributions. Unless You explicitly state otherwise, > any Contribution intentionally submitted for inclusion in the Work by > You to the Licensor shall be under the terms and conditions of this > License, without any additional terms or conditions. Notwithstanding > the above, nothing herein shall supersede or modify the terms of any > separate license agreement you may have executed with Licensor > regarding such Contributions." > > The above says that by contributing changes back to the main > repository, you're agreeing to release your changes also under the > Apache 2.0 license. Without this additional paragraph we'll need to > specify licensing terms for every change to the code made by any > contributor - that isn't feasible. Again, this paragraph does not > request copyright transfer, just a license to redistribute, use etc. > > Second paragraph > =============== > "Grant of Patent License. Subject to the terms and conditions of this > License, each Contributor hereby grants to You a perpetual, worldwide, > non-exclusive, no-charge, royalty-free, irrevocable (except as stated > in this section) patent license to make, have made, use, offer to > sell, sell, import, and otherwise transfer the Work, where such > license applies only to those patent claims licensable by such > Contributor that are necessarily infringed by their Contribution(s) > alone or by combination of their Contribution(s) with the Work to > which such Contribution(s) was submitted. If You institute patent > litigation against any entity (including a cross-claim or counterclaim > in a lawsuit) alleging that the Work or a Contribution incorporated > within the Work constitutes direct or contributory patent > infringement, then any patent licenses granted to You under this > License for that Work shall terminate as of the date such litigation > is filed." > > This paragraph says that if you submit code to the repository you're > also granting everyone a license to use that code even if you've filed > for a patent that the code implements. Consider that if someone adds > something to the CTK core that is covered by one of their own patents, > then we may end up being sued (it really does happen way too often in > America), having to pay them money to use CTK, or having to re-write > that code. > > Hope this helps, > Stephen > > On Tue, Apr 13, 2010 at 9:04 AM, Marco Viceconti > wrote: >> If I understand correctly the discussion so far, it seems that >> under an >> appropriate FOSS license the tracking of copyright is unnecessary. >> Still, I >> disagree that it is irrelevant, as in addition to the personal >> proudness >> there is also an institutional proudness, that tracking copyright >> to the >> institution that contributed with a portion of code, somehow >> sustains. >> Because of this I would suggest that each contributor should have >> the right >> to keep the copyright to his-her own institution. >> >> For the license, I agree with Luis that the choice is between an >> handful of >> options, such as MIT, BSD and Apache 2.0 licenses. Indeed, this >> point was >> extensively discussed in one of the first meetings of the CTK >> Group, as >> correctly pointed out by J?rg Riesmeier. In that meeting we >> noticed that a) >> many of our frameworks and libraries are distributed under BSD, and >> b) that >> BSD has all the features we thought the CTK should had. >> http://www.commontk.org/cgi-bin/trac.cgi/wiki/Whitepaper#BSDstylelicense >> >> Of course nothing is carved in stone, but I do not thing we should >> simply >> ignore what has been already extensively discussed. Thus, I would >> suggest >> to consider the topic in this light: there is decision in favour of >> BSD. Is >> there any argument that makes Apache 2.0 preferable over BSD? If we >> opt for >> Apache 2.0, is there any problem in re-using inside CTK code >> licensed under >> BSD, such as DCMTK? >> >> A last comment: while Apache 2.0 is clearly a more modern option, >> BSD has >> beauty of being the clearest license you can read. Now if it is >> true, like >> many says that in the end you get the same protection with both, I >> would opt >> for BSD if nothing else only for this. >> >> Cheers >> >> Marco >> >> >> >> Il giorno 12 Apr 2010, alle ore 16:23, Luis Ibanez ha scritto: >> >>> >>> I agree with Bill, >>> >>> The choice of a good License is more important that who holds the >>> Copyright (and patents, and trademarks) associated with the code. >>> >>> >>> In practice, tracing the Copyright holders of code in an Open Source >>> project is an impossible task. >>> >>> >>> Whoever is contributing code to an Open Source project with the >>> intention of conserving ownership or control over such code has >>> flawed understanding of how software development works in a >>> peer-production environment. >>> >>> >>> Files tend to (and *should*) be modified by many different >>> developers, >>> who are affiliated to different institutions. Every institution >>> will hold >>> the >>> copyright of every modification. >>> >>> >>> You may know "who" is the copyright holder of a file, the first >>> day that >>> file >>> is committed. But after ten years of this file being modified and >>> retouched >>> by twenty other developers from ten other institutions, you have a >>> file >>> where >>> >>> >>> 55% of the lines are copyrighted by institution A >>> 27% by institution B >>> 13% by institution C.. >>> ... and so on. >>> >>> >>> In a well-managed open source project, such modifications of any >>> given >>> file by many different developers *is expected* to happen. >>> >>> When a file has only been touched by a single developer, that's an >>> indication >>> that nobody else in the project cares about such file, and that the >>> project has >>> poor practices of code review and suffers from lack of >>> participation. >>> >>> So, even if any given organization want to conserve "ownership" of >>> the >>> code, that is simply unrealistic in practice. >>> >>> Assigning copyright of the code to a non-for-profit organization is >>> actually >>> a way of protecting the developers (and their institutions). >>> >>> This is discussed in great detail in: >>> >>> "Intellectual Property and Open Source >>> A Practical Guide to Protecting Code" >>> by Van Lindberg >>> http://oreilly.com/catalog/9780596517960 >>> >>> >>> >>> >>> In any case, what is more important is to chose a License, that make >>> irrelevant >>> (and unnecessary) to track ownership of the source code. The MIT, >>> BSD and >>> Apache 2.0 licenses are typical good choices that satisfy such >>> condition. >>> >>> >>> The Apache 2.0 license is particularly attractive in this case >>> because it >>> is >>> the only one from this group, that includes specific clauses about >>> code >>> contributions. >>> >>> >>> >>> Luis >>> >>> >>> >>> >>> ------------------------------------------------------------------------------------------- >>> On Mon, Apr 12, 2010 at 8:39 AM, Bill Lorensen >> > >>> wrote: >>> I agree with that license is more important that the copyright >>> holders. >>> >>> In VTK, many files have multiple copyrights, but all share the same >>> license. >>> >>> Bill >>> >>> On Mon, Apr 12, 2010 at 8:35 AM, Ron Kikinis >> > >>> wrote: >>>> Luis, >>>> >>>> The apache license sounds reasonable to me. In terms of making >>>> ISC the >>>> owner >>>> of the copyright: >>>> As you know, we have taken a different approach with Slicer in >>>> that the >>>> contributors keep the copyright and only grant an irrevocable and >>>> unlimited >>>> license for use in Slicer (I am not a lawyer so this is not legal >>>> language). >>>> >>>> On an other point: ISC was created to hold the copyright for ITK. >>>> The >>>> website does not really reflect the more recent additions of >>>> cmake and >>>> IGSTK. The board of directors primarily reflects ITK and would >>>> probably >>>> require some updates. >>>> >>>> One question: how "dictator proof" is ISC? >>>> >>>> Ron >>>> >>>> >>>> >>>> On 4/9/10 10:36 AM, Luis Ibanez wrote: >>>>> >>>>> Yes, >>>>> it is not the most amusing conversation to have, >>>>> but it is better to do this early... >>>>> >>>>> >>>>> 1) Most files in CTK are lacking Copyright >>>>> notices and an explicit License. >>>>> >>>>> 2) There is not LICENCE file at the top of >>>>> the source tree. >>>>> >>>>> >>>>> >>>>> I propose that we assign the copyright of the source code >>>>> to the Insight Software Consortium (ISC), and that we >>>>> distribute the code under an Apache 2.0 License. >>>>> >>>>> http://www.opensource.org/licenses/apache2.0.php >>>>> >>>>> >>>>> >>>>> The ISC is the organization that holds the copyright of >>>>> >>>>> * ITK >>>>> * CMake (along with Kitware) >>>>> * IGSTK >>>>> >>>>> >>>>> More information about the ISC at: >>>>> >>>>> http://www.insightsoftwareconsortium.org/ >>>>> >>>>> >>>>> It will also be important for your respective organizations >>>>> to join the ISC, or for you to join as individuals, so you >>>>> help ensure that the CTK project is managed as you >>>>> intended. >>>>> >>>>> >>>>> Every day that passes without having a clear License >>>>> and Copyright statement is a day were we are brewing >>>>> a recipe for disaster. >>>>> >>>>> >>>>> >>>>> If someone needs to be persuaded, we can provide details >>>>> on the horror story of how much trouble we are having in ITK >>>>> with source code of dubious origin (no copyright notice nor >>>>> license) that we adopted from www.netlib.org.... >>>>> >>>>> >>>>> >>>>> Luis >>>>> _______________________________________________ >>>>> Ctk-developers mailing list >>>>> Ctk-developers at commontk.org >>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>> >>>> -- >>>> Ron Kikinis, M.D., >>>> Robert Greenes Distinguished Director of Biomedical Informatics >>>> Professor of Radiology, Harvard Medical School >>>> Director, Surgical Planning Laboratory >>>> http://www.spl.harvard.edu/~kikinis >>>> _______________________________________________ >>>> Ctk-developers mailing list >>>> Ctk-developers at commontk.org >>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>> >>> _______________________________________________ >>> Ctk-developers mailing list >>> Ctk-developers at commontk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>> >>> _______________________________________________ >>> Ctk-developers mailing list >>> Ctk-developers at commontk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> -------------------------------------------------- >> MARCO VICECONTI, PhD (viceconti at tecno.ior.it >> ) >> Laboratorio di Tecnologia Medica tel. 39-051-6366865 >> Istituto Ortopedico Rizzoli fax. >> 39-051-6366863 >> via di Barbiano 1/10, 40136 - Bologna, Italy >> >> Tiger! Tiger! Burning bright in the forest of the night, >> what immortal hand or eye could frame thy fearful symmetry? >> -------------------------------------------------- >> Opinions expressed here do not necessarily reflect those of my >> employer >> >> >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> > > > > -- > Stephen R. Aylward, Ph.D. > Director of Medical Imaging Research > Kitware, Inc. - North Carolina Office > http://www.kitware.com > stephen.aylward (Skype) > (919) 969-6990 x300 > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > The material in this message is private and may contain Protected > Healthcare Information (PHI). If you are not the intended > recipient, be advised that any unauthorized use, disclosure, copying > or the taking of any action in reliance on the contents of this > information is strictly prohibited. If you have received this email > in error, please immediately notify the sender via telephone or > return mail. > -------------------------------------------------- MARCO VICECONTI, PhD (viceconti at tecno.ior.it) Laboratorio di Tecnologia Medica tel. 39-051-6366865 Istituto Ortopedico Rizzoli fax. 39-051-6366863 via di Barbiano 1/10, 40136 - Bologna, Italy Tiger! Tiger! Burning bright in the forest of the night, what immortal hand or eye could frame thy fearful symmetry? -------------------------------------------------- Opinions expressed here do not necessarily reflect those of my employer From viceconti at tecno.ior.it Wed Apr 14 11:59:17 2010 From: viceconti at tecno.ior.it (Marco Viceconti) Date: Wed, 14 Apr 2010 13:59:17 +0200 Subject: [Ctk-developers] a story of two lists In-Reply-To: References: <0147E11D-4420-4A77-B9F2-431A7D7DAFBF@tecno.ior.it> <67B4B5166383D848A0565AA7491841F93082F06AC4@RAD-VMSRVEXV2.rad.wustl.edu> Message-ID: <77EA0BEA-F9D3-4CA4-A77C-C4A1E37791EA@tecno.ior.it> The idea or creating a public list for "passive" members called announcements is probably a good idea in due time; now it might be a bit too early for that, I do not know. But what I proposed is different. It is quite clear that in Kitware organisation the same person follow the entire life cycle of the software from general strategic issues such as copyright, architecture, etc. to actual hands-on programming. But this is not the case in my organisation, where for example I do play an active role in architectural design, but I do not materially program myself since 19..., well a long while ago. Now if most participating organisations are organised as Kitware, it make more sense to stay all on one list; on the contrary if the majority is organised as B3C, then it is better to split in two, both "active" but focused on different aspects. Cheers Marco Il giorno 13 Apr 2010, alle ore 17:52, Stephen Aylward ha scritto: > I think having two lists is a good idea. > > Many people will simply subscribe to both - but different people will > have different interests and levels of involvement. My thought is > that perhaps the second list would be for people who want to track the > community without knowing anything about the code (e.g., program > officers at funding agencies, administrators, etc). As such, perhaps > we should change the names and purposes of the list slightly: > > ctk-developers covers all things related to the code: architectural > discussions, copyright, licensing, which libraries to include, etc. > This is the really active, high-traffic list. > > ctk-announcements covers all things "public": advertising and > organizational matters of the community: meetings, grant proposals, > funding opportunities, etc. It is intended for the passive > participants. Hence "announcements" It should not receive heavy > traffic or people will unsubscribe. > > I don't feel strongly about this - but I think it might be hard to > separate copyright from library inclusion discussions, implementation > from architecture discussions, etc., and most of the time people > join/leave lists based on traffic/spam. We should make it easy for > everyone to track us and yet not involve them in every discussion. > > Stephen > > > On Tue, Apr 13, 2010 at 9:49 AM, Tarbox, Lawrence > wrote: >> Good idea. >> >> -----Original Message----- >> From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org >> ] On Behalf Of Marco Viceconti >> Sent: Tuesday, April 13, 2010 8:12 AM >> To: ctk-developers at commontk.org >> Subject: [Ctk-developers] a story of two lists >> >> Dear All: >> I am very happy to see that the CTK community is really starting >> up. But I see a potential risk in the current communication model. >> As it is now, we have a single mailing list to discuss everything >> from >> the single cmake instruction that breaks the dashboard to the >> copyright issues. I know some of you have a role in your >> organisations that cover this entire spectrum, but I also know that >> in >> my organisation, and I suspect in other as well, the persons that are >> interested in some topics are not the same that are interested in >> others. >> >> If this is true for others I would ask we split the list in two, ctk- >> developers and ctk-governance. In the first we shall continue to >> discuss all implementation problems, in the second issues such as >> licensing, copyright, architectural choices, community development, >> etc. >> >> Of course one would be allowed so sign up to both, so that for those >> who cover all aspects would not change much. But for the others we >> could partition the communication more effectively, which usually >> improves the level of participation. >> >> Comments are welcome >> >> Marco -------------------------------------------------- MARCO VICECONTI, PhD (viceconti at tecno.ior.it) Laboratorio di Tecnologia Medica tel. 39-051-6366865 Istituto Ortopedico Rizzoli fax. 39-051-6366863 via di Barbiano 1/10, 40136 - Bologna, Italy Tiger! Tiger! Burning bright in the forest of the night, what immortal hand or eye could frame thy fearful symmetry? -------------------------------------------------- Opinions expressed here do not necessarily reflect those of my employer From pieper at bwh.harvard.edu Wed Apr 14 12:52:29 2010 From: pieper at bwh.harvard.edu (Steve Pieper) Date: Wed, 14 Apr 2010 08:52:29 -0400 Subject: [Ctk-developers] COPYRIGHT & LICENSING In-Reply-To: References: <4BC313AA.6050408@bwh.harvard.edu> <67B4B5166383D848A0565AA7491841F93082F06AD3@RAD-VMSRVEXV2.rad.wustl.edu> Message-ID: <4BC5BA8D.8040702@bwh.harvard.edu> Additional considerations regarding Qt: Qt samples and user-contributed widgets are typically licensed under the LGPL or the GPL (depending on history and developer preference - see http://qt-apps.org for examples). My understanding of the Nokia policy is that if we start with /just/ the LGPL'd Qt distribution and write a widget, we can distribute our widgets under any license. However if we *incorporate and modify* existing GPL or LGPL code we need to use the same license for our resulting code (the 'copyleft' requirement). Note that it is probably okay to /use/ an LGPL'd widget set via superbuild without impacting the licensing of CTK widgets themselves (for example, if we wanted to subclass existing widgets from something like Qxt http://www.libqxt.org/). As a practical matter, at the intersection of development and governance, we need to develop a policy about what external code we can incorporate in CTK and we need to be careful to follow that policy. My recommendations based on the current environment are: 1) Qt-based CTK Widgets will need to incorporate LGPL'd example code from the wider developer community and will therefor need to be under the LGPL license (different from the rest of CTK). 2) CTK developers will carefully review any projects from which they wish to draw code and strictly avoid using any GPL'd code. (If the code is particularly unique and valuable, contact the authors and ask if they will consider releasing an LGPL or BSD-style version). I would be very interested in comments from experienced Qt developers on these topics: - does the analysis above match your understanding? - do we need to base our CTK widgets on LGPL'd examples? Or could we accomplish our goals while adhering to a strict Apache/BSD-style licensing approach only? Regards, Steve On Apr/14/10 7:53 AM, Marco Viceconti wrote: > Lawrence is right to say that no one had strong opinions in favour of > BSD as such, and in the end the decision was taken only because most > existing codes represented around the table were already BSD. On the > contrary there was strong consensus on staying away from copyleft licenses. > > Stephen point on patents is very relevant, so I recognise that it is > probably a good idea to go for Apache 2.0 for CTK. As a side effect, we > shall now revise this matter internally to B3C, and we might indeed > decide to adopt Apache 2.0 also for MAF3. > > Cheers > > Marco > > > > > Il giorno 13 Apr 2010, alle ore 17:16, Tarbox, Lawrence ha scritto: > >> I concur with Stephen. >> >> The pure BSD license does not address certain key issues, such as >> patents, trademarks, and contributions, that potentially could be very >> problematic in an open source project with multiple contributors from >> multiple organizations. The Apache license closes those holes, while >> still being essentially a BSD license at its core. (Compare the text >> of clauses 3, 8, and 9 with the BSD license - they are nearly >> identical to the BSD license.) >> >> As far as I know, there is little problem including BSD code in a >> project licensed under Apache, as long as there are no problems with >> patent or trademark infringements in the BSD code. >> >> My recollection of the previous discussions was more that we did not >> want CTK to use a 'copyleft' license, such as GPL, and that we >> preferred a more commercial friendly license with terms similar to >> BSD. The discussion brought out that most of the code that we already >> use has been released under licenses with terms similar to BSD, though >> not everyone was using a pure BSD license. I believe Apache has terms >> similar to and compatible with BSD, and would be a better match to our >> needs than simple BSD. >> >> >> >> >> >> -----Original Message----- >> From: ctk-developers-bounces at commontk.org >> [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Stephen Aylward >> Sent: Tuesday, April 13, 2010 8:45 AM >> To: Marco Viceconti >> Cc: ctk-developers at commontk.org >> Subject: Re: [Ctk-developers] COPYRIGHT & LICENSING >> >> Hi, >> >> The Apache 2.0 license is actually a BSD-style license. It is the >> new-BSD license with two additional paragraphs that are important >> based on our experiences with ITK. Note that ITK is now released >> under the Apache 2.0 license. >> >> There are some great articles on the benefits of Apache 2.0, such as >> "Apache better than GPL for open-source business?" >> http://news.cnet.com/8301-13505_3-10229817-16.html >> >> The full text of the license is available at: >> http://www.apache.org/licenses/LICENSE-2.0.html >> >> A FAQ on the Apache 2.0 license is at: >> http://www.apache.org/foundation/licence-FAQ.html >> >> Below is my interpretation of those two additional paragraphs: >> >> First paragraph >> ============= >> "Submission of Contributions. Unless You explicitly state otherwise, >> any Contribution intentionally submitted for inclusion in the Work by >> You to the Licensor shall be under the terms and conditions of this >> License, without any additional terms or conditions. Notwithstanding >> the above, nothing herein shall supersede or modify the terms of any >> separate license agreement you may have executed with Licensor >> regarding such Contributions." >> >> The above says that by contributing changes back to the main >> repository, you're agreeing to release your changes also under the >> Apache 2.0 license. Without this additional paragraph we'll need to >> specify licensing terms for every change to the code made by any >> contributor - that isn't feasible. Again, this paragraph does not >> request copyright transfer, just a license to redistribute, use etc. >> >> Second paragraph >> =============== >> "Grant of Patent License. Subject to the terms and conditions of this >> License, each Contributor hereby grants to You a perpetual, worldwide, >> non-exclusive, no-charge, royalty-free, irrevocable (except as stated >> in this section) patent license to make, have made, use, offer to >> sell, sell, import, and otherwise transfer the Work, where such >> license applies only to those patent claims licensable by such >> Contributor that are necessarily infringed by their Contribution(s) >> alone or by combination of their Contribution(s) with the Work to >> which such Contribution(s) was submitted. If You institute patent >> litigation against any entity (including a cross-claim or counterclaim >> in a lawsuit) alleging that the Work or a Contribution incorporated >> within the Work constitutes direct or contributory patent >> infringement, then any patent licenses granted to You under this >> License for that Work shall terminate as of the date such litigation >> is filed." >> >> This paragraph says that if you submit code to the repository you're >> also granting everyone a license to use that code even if you've filed >> for a patent that the code implements. Consider that if someone adds >> something to the CTK core that is covered by one of their own patents, >> then we may end up being sued (it really does happen way too often in >> America), having to pay them money to use CTK, or having to re-write >> that code. >> >> Hope this helps, >> Stephen >> >> On Tue, Apr 13, 2010 at 9:04 AM, Marco Viceconti >> wrote: >>> If I understand correctly the discussion so far, it seems that under an >>> appropriate FOSS license the tracking of copyright is unnecessary. >>> Still, I >>> disagree that it is irrelevant, as in addition to the personal proudness >>> there is also an institutional proudness, that tracking copyright to the >>> institution that contributed with a portion of code, somehow sustains. >>> Because of this I would suggest that each contributor should have the >>> right >>> to keep the copyright to his-her own institution. >>> >>> For the license, I agree with Luis that the choice is between an >>> handful of >>> options, such as MIT, BSD and Apache 2.0 licenses. Indeed, this point >>> was >>> extensively discussed in one of the first meetings of the CTK Group, as >>> correctly pointed out by J?rg Riesmeier. In that meeting we noticed >>> that a) >>> many of our frameworks and libraries are distributed under BSD, and >>> b) that >>> BSD has all the features we thought the CTK should had. >>> http://www.commontk.org/cgi-bin/trac.cgi/wiki/Whitepaper#BSDstylelicense >>> >>> Of course nothing is carved in stone, but I do not thing we should >>> simply >>> ignore what has been already extensively discussed. Thus, I would >>> suggest >>> to consider the topic in this light: there is decision in favour of >>> BSD. Is >>> there any argument that makes Apache 2.0 preferable over BSD? If we >>> opt for >>> Apache 2.0, is there any problem in re-using inside CTK code licensed >>> under >>> BSD, such as DCMTK? >>> >>> A last comment: while Apache 2.0 is clearly a more modern option, BSD >>> has >>> beauty of being the clearest license you can read. Now if it is true, >>> like >>> many says that in the end you get the same protection with both, I >>> would opt >>> for BSD if nothing else only for this. >>> >>> Cheers >>> >>> Marco >>> >>> >>> >>> Il giorno 12 Apr 2010, alle ore 16:23, Luis Ibanez ha scritto: >>> >>>> >>>> I agree with Bill, >>>> >>>> The choice of a good License is more important that who holds the >>>> Copyright (and patents, and trademarks) associated with the code. >>>> >>>> >>>> In practice, tracing the Copyright holders of code in an Open Source >>>> project is an impossible task. >>>> >>>> >>>> Whoever is contributing code to an Open Source project with the >>>> intention of conserving ownership or control over such code has >>>> flawed understanding of how software development works in a >>>> peer-production environment. >>>> >>>> >>>> Files tend to (and *should*) be modified by many different developers, >>>> who are affiliated to different institutions. Every institution will >>>> hold >>>> the >>>> copyright of every modification. >>>> >>>> >>>> You may know "who" is the copyright holder of a file, the first day >>>> that >>>> file >>>> is committed. But after ten years of this file being modified and >>>> retouched >>>> by twenty other developers from ten other institutions, you have a file >>>> where >>>> >>>> >>>> 55% of the lines are copyrighted by institution A >>>> 27% by institution B >>>> 13% by institution C.. >>>> ... and so on. >>>> >>>> >>>> In a well-managed open source project, such modifications of any given >>>> file by many different developers *is expected* to happen. >>>> >>>> When a file has only been touched by a single developer, that's an >>>> indication >>>> that nobody else in the project cares about such file, and that the >>>> project has >>>> poor practices of code review and suffers from lack of participation. >>>> >>>> So, even if any given organization want to conserve "ownership" of the >>>> code, that is simply unrealistic in practice. >>>> >>>> Assigning copyright of the code to a non-for-profit organization is >>>> actually >>>> a way of protecting the developers (and their institutions). >>>> >>>> This is discussed in great detail in: >>>> >>>> "Intellectual Property and Open Source >>>> A Practical Guide to Protecting Code" >>>> by Van Lindberg >>>> http://oreilly.com/catalog/9780596517960 >>>> >>>> >>>> >>>> >>>> In any case, what is more important is to chose a License, that make >>>> irrelevant >>>> (and unnecessary) to track ownership of the source code. The MIT, >>>> BSD and >>>> Apache 2.0 licenses are typical good choices that satisfy such >>>> condition. >>>> >>>> >>>> The Apache 2.0 license is particularly attractive in this case >>>> because it >>>> is >>>> the only one from this group, that includes specific clauses about code >>>> contributions. >>>> >>>> >>>> >>>> Luis >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------------------- >>>> >>>> On Mon, Apr 12, 2010 at 8:39 AM, Bill Lorensen >>>> >>>> wrote: >>>> I agree with that license is more important that the copyright holders. >>>> >>>> In VTK, many files have multiple copyrights, but all share the same >>>> license. >>>> >>>> Bill >>>> >>>> On Mon, Apr 12, 2010 at 8:35 AM, Ron Kikinis >>>> wrote: >>>>> Luis, >>>>> >>>>> The apache license sounds reasonable to me. In terms of making ISC the >>>>> owner >>>>> of the copyright: >>>>> As you know, we have taken a different approach with Slicer in that >>>>> the >>>>> contributors keep the copyright and only grant an irrevocable and >>>>> unlimited >>>>> license for use in Slicer (I am not a lawyer so this is not legal >>>>> language). >>>>> >>>>> On an other point: ISC was created to hold the copyright for ITK. The >>>>> website does not really reflect the more recent additions of cmake and >>>>> IGSTK. The board of directors primarily reflects ITK and would >>>>> probably >>>>> require some updates. >>>>> >>>>> One question: how "dictator proof" is ISC? >>>>> >>>>> Ron >>>>> >>>>> >>>>> >>>>> On 4/9/10 10:36 AM, Luis Ibanez wrote: >>>>>> >>>>>> Yes, >>>>>> it is not the most amusing conversation to have, >>>>>> but it is better to do this early... >>>>>> >>>>>> >>>>>> 1) Most files in CTK are lacking Copyright >>>>>> notices and an explicit License. >>>>>> >>>>>> 2) There is not LICENCE file at the top of >>>>>> the source tree. >>>>>> >>>>>> >>>>>> >>>>>> I propose that we assign the copyright of the source code >>>>>> to the Insight Software Consortium (ISC), and that we >>>>>> distribute the code under an Apache 2.0 License. >>>>>> >>>>>> http://www.opensource.org/licenses/apache2.0.php >>>>>> >>>>>> >>>>>> >>>>>> The ISC is the organization that holds the copyright of >>>>>> >>>>>> * ITK >>>>>> * CMake (along with Kitware) >>>>>> * IGSTK >>>>>> >>>>>> >>>>>> More information about the ISC at: >>>>>> >>>>>> http://www.insightsoftwareconsortium.org/ >>>>>> >>>>>> >>>>>> It will also be important for your respective organizations >>>>>> to join the ISC, or for you to join as individuals, so you >>>>>> help ensure that the CTK project is managed as you >>>>>> intended. >>>>>> >>>>>> >>>>>> Every day that passes without having a clear License >>>>>> and Copyright statement is a day were we are brewing >>>>>> a recipe for disaster. >>>>>> >>>>>> >>>>>> >>>>>> If someone needs to be persuaded, we can provide details >>>>>> on the horror story of how much trouble we are having in ITK >>>>>> with source code of dubious origin (no copyright notice nor >>>>>> license) that we adopted from www.netlib.org.... >>>>>> >>>>>> >>>>>> >>>>>> Luis >>>>>> _______________________________________________ >>>>>> Ctk-developers mailing list >>>>>> Ctk-developers at commontk.org >>>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>>> >>>>> -- >>>>> Ron Kikinis, M.D., >>>>> Robert Greenes Distinguished Director of Biomedical Informatics >>>>> Professor of Radiology, Harvard Medical School >>>>> Director, Surgical Planning Laboratory >>>>> http://www.spl.harvard.edu/~kikinis >>>>> _______________________________________________ >>>>> Ctk-developers mailing list >>>>> Ctk-developers at commontk.org >>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>>> >>>> _______________________________________________ >>>> Ctk-developers mailing list >>>> Ctk-developers at commontk.org >>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>> >>>> _______________________________________________ >>>> Ctk-developers mailing list >>>> Ctk-developers at commontk.org >>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>> >>> -------------------------------------------------- >>> MARCO VICECONTI, PhD (viceconti at tecno.ior.it) >>> Laboratorio di Tecnologia Medica tel. 39-051-6366865 >>> Istituto Ortopedico Rizzoli fax. 39-051-6366863 >>> via di Barbiano 1/10, 40136 - Bologna, Italy >>> >>> Tiger! Tiger! Burning bright in the forest of the night, >>> what immortal hand or eye could frame thy fearful symmetry? >>> -------------------------------------------------- >>> Opinions expressed here do not necessarily reflect those of my employer >>> >>> >>> >>> _______________________________________________ >>> Ctk-developers mailing list >>> Ctk-developers at commontk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>> >> >> >> >> -- >> Stephen R. Aylward, Ph.D. >> Director of Medical Imaging Research >> Kitware, Inc. - North Carolina Office >> http://www.kitware.com >> stephen.aylward (Skype) >> (919) 969-6990 x300 >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> The material in this message is private and may contain Protected >> Healthcare Information (PHI). If you are not the intended recipient, >> be advised that any unauthorized use, disclosure, copying or the >> taking of any action in reliance on the contents of this information >> is strictly prohibited. If you have received this email in error, >> please immediately notify the sender via telephone or return mail. >> > > -------------------------------------------------- > MARCO VICECONTI, PhD (viceconti at tecno.ior.it) > Laboratorio di Tecnologia Medica tel. 39-051-6366865 > Istituto Ortopedico Rizzoli fax. 39-051-6366863 > via di Barbiano 1/10, 40136 - Bologna, Italy > > Tiger! Tiger! Burning bright in the forest of the night, > what immortal hand or eye could frame thy fearful symmetry? > -------------------------------------------------- > Opinions expressed here do not necessarily reflect those of my employer > > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers From stephen.aylward at kitware.com Wed Apr 14 13:04:28 2010 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Wed, 14 Apr 2010 09:04:28 -0400 Subject: [Ctk-developers] a story of two lists In-Reply-To: <77EA0BEA-F9D3-4CA4-A77C-C4A1E37791EA@tecno.ior.it> References: <0147E11D-4420-4A77-B9F2-431A7D7DAFBF@tecno.ior.it> <67B4B5166383D848A0565AA7491841F93082F06AC4@RAD-VMSRVEXV2.rad.wustl.edu> <77EA0BEA-F9D3-4CA4-A77C-C4A1E37791EA@tecno.ior.it> Message-ID: I see your point. My view is often extremely one-sided:) Sorry about that. I'm happy to go with the two lists as you originally described. Thanks, Stephen On Wed, Apr 14, 2010 at 7:59 AM, Marco Viceconti wrote: > The idea or creating a public list for "passive" members called > announcements is probably a good idea in due time; now it might be a bit too > early for that, I do not know. > > But what I proposed is different. ?It is quite clear that in Kitware > organisation the same person follow the entire life cycle of the software > from general strategic issues such as copyright, architecture, etc. to > actual hands-on programming. ?But this is not the case in my organisation, > where for example I do play an active role in architectural design, but I do > not materially program myself since 19..., well a long while ago. > > Now if most participating organisations are organised as Kitware, it make > more sense to stay all on one list; on the contrary if the majority is > organised as B3C, then it is better to split in two, both "active" but > focused on different aspects. > > Cheers > > Marco > > > > > Il giorno 13 Apr 2010, alle ore 17:52, Stephen Aylward ha scritto: > >> I think having two lists is a good idea. >> >> Many people will simply subscribe to both - but different people will >> have different interests and levels of involvement. ? My thought is >> that perhaps the second list would be for people who want to track the >> community without knowing anything about the code (e.g., program >> officers at funding agencies, administrators, etc). ? As such, perhaps >> we should change the names and purposes of the list slightly: >> >> ctk-developers covers all things related to the code: architectural >> discussions, copyright, licensing, which libraries to include, etc. >> This is the really active, high-traffic list. >> >> ctk-announcements covers all things "public": advertising and >> organizational matters of the community: meetings, grant proposals, >> funding opportunities, etc. ? It is intended for the passive >> participants. ? Hence "announcements" ? ?It should not receive heavy >> traffic or people will unsubscribe. >> >> I don't feel strongly about this - but I think it might be hard to >> separate copyright from library inclusion discussions, implementation >> from architecture discussions, etc., and most of the time people >> join/leave lists based on traffic/spam. ? We should make it easy for >> everyone to track us and yet not involve them in every discussion. >> >> Stephen >> >> >> On Tue, Apr 13, 2010 at 9:49 AM, Tarbox, Lawrence >> wrote: >>> >>> Good idea. >>> >>> -----Original Message----- >>> From: ctk-developers-bounces at commontk.org >>> [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Marco Viceconti >>> Sent: Tuesday, April 13, 2010 8:12 AM >>> To: ctk-developers at commontk.org >>> Subject: [Ctk-developers] a story of two lists >>> >>> Dear All: >>> ?I am very happy to see that the CTK community is really starting >>> up. ?But I see a potential risk in the current communication model. >>> As it is now, we have a single mailing list to discuss everything from >>> the single cmake instruction that breaks the dashboard to the >>> copyright issues. ?I know some of you have a role in your >>> organisations that cover this entire spectrum, but I also know that in >>> my organisation, and I suspect in other as well, the persons that are >>> interested in some topics are not the same that are interested in >>> others. >>> >>> If this is true for others I would ask we split the list in two, ctk- >>> developers and ctk-governance. ?In the first we shall continue to >>> discuss all implementation problems, in the second issues such as >>> licensing, copyright, architectural choices, community development, etc. >>> >>> Of course one would be allowed so sign up to both, so that for those >>> who cover all aspects would not change much. But for the others we >>> could partition the communication more effectively, which usually >>> improves the level of participation. >>> >>> Comments are welcome >>> >>> Marco > > -------------------------------------------------- > MARCO VICECONTI, PhD ? ? ? ? ? ? ? ? ? ? ? ? ? ? (viceconti at tecno.ior.it) > Laboratorio di Tecnologia Medica ? ? ? ? ? ? ?tel. ? 39-051-6366865 > Istituto Ortopedico Rizzoli ? ? ? ? ? ? ? ? ? ? ? ? ? ?fax. ? 39-051-6366863 > via di Barbiano 1/10, 40136 - Bologna, Italy > > Tiger! Tiger! Burning bright in the forest of the night, > what immortal hand or eye could frame thy fearful symmetry? > -------------------------------------------------- > Opinions expressed here do not necessarily reflect those of my employer > > > > -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From tarboxl at mir.wustl.edu Wed Apr 14 13:23:19 2010 From: tarboxl at mir.wustl.edu (Tarbox, Lawrence) Date: Wed, 14 Apr 2010 08:23:19 -0500 Subject: [Ctk-developers] COPYRIGHT & LICENSING In-Reply-To: <4BC5BA8D.8040702@bwh.harvard.edu> References: <4BC313AA.6050408@bwh.harvard.edu> <67B4B5166383D848A0565AA7491841F93082F06AD3@RAD-VMSRVEXV2.rad.wustl.edu> <4BC5BA8D.8040702@bwh.harvard.edu> Message-ID: <67B4B5166383D848A0565AA7491841F930840FC962@RAD-VMSRVEXV2.rad.wustl.edu> I think your understanding is correct, though I am a newbie to Qt. In the XIP Libraries(tm) we currently utilize the LGPL-licenses Open Inventor(tm) libraries as a basis for interconnecting processing pipelines and scenegraphs. We have taken the positition that any changes to the Open Inventor code itself (i.e. that appears in the Open Inventor shared libraries (.dll or .so files) or that appears in the Open Inventor header (.h) files) must be released under LGPL. But any code that merely links to the Open Inventor code, including derived classes that do not directly modify the base classes, can be released under any license that we choose. Because of contractual obligations to the National Cancer Institute (NCI) caBIG(r) program, XIP(tm) is released under the caBIG Model License. The caBIG model license, which is a BSD-like license, is very similar, almost identical to the Apache license. Lawrence -----Original Message----- From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Steve Pieper Sent: Wednesday, April 14, 2010 7:52 AM To: Marco Viceconti Cc: ctk-developers at commontk.org Subject: Re: [Ctk-developers] COPYRIGHT & LICENSING Additional considerations regarding Qt: Qt samples and user-contributed widgets are typically licensed under the LGPL or the GPL (depending on history and developer preference - see http://qt-apps.org for examples). My understanding of the Nokia policy is that if we start with /just/ the LGPL'd Qt distribution and write a widget, we can distribute our widgets under any license. However if we *incorporate and modify* existing GPL or LGPL code we need to use the same license for our resulting code (the 'copyleft' requirement). Note that it is probably okay to /use/ an LGPL'd widget set via superbuild without impacting the licensing of CTK widgets themselves (for example, if we wanted to subclass existing widgets from something like Qxt http://www.libqxt.org/). As a practical matter, at the intersection of development and governance, we need to develop a policy about what external code we can incorporate in CTK and we need to be careful to follow that policy. My recommendations based on the current environment are: 1) Qt-based CTK Widgets will need to incorporate LGPL'd example code from the wider developer community and will therefor need to be under the LGPL license (different from the rest of CTK). 2) CTK developers will carefully review any projects from which they wish to draw code and strictly avoid using any GPL'd code. (If the code is particularly unique and valuable, contact the authors and ask if they will consider releasing an LGPL or BSD-style version). I would be very interested in comments from experienced Qt developers on these topics: - does the analysis above match your understanding? - do we need to base our CTK widgets on LGPL'd examples? Or could we accomplish our goals while adhering to a strict Apache/BSD-style licensing approach only? Regards, Steve On Apr/14/10 7:53 AM, Marco Viceconti wrote: > Lawrence is right to say that no one had strong opinions in favour of > BSD as such, and in the end the decision was taken only because most > existing codes represented around the table were already BSD. On the > contrary there was strong consensus on staying away from copyleft licenses. > > Stephen point on patents is very relevant, so I recognise that it is > probably a good idea to go for Apache 2.0 for CTK. As a side effect, we > shall now revise this matter internally to B3C, and we might indeed > decide to adopt Apache 2.0 also for MAF3. > > Cheers > > Marco > > > > > Il giorno 13 Apr 2010, alle ore 17:16, Tarbox, Lawrence ha scritto: > >> I concur with Stephen. >> >> The pure BSD license does not address certain key issues, such as >> patents, trademarks, and contributions, that potentially could be very >> problematic in an open source project with multiple contributors from >> multiple organizations. The Apache license closes those holes, while >> still being essentially a BSD license at its core. (Compare the text >> of clauses 3, 8, and 9 with the BSD license - they are nearly >> identical to the BSD license.) >> >> As far as I know, there is little problem including BSD code in a >> project licensed under Apache, as long as there are no problems with >> patent or trademark infringements in the BSD code. >> >> My recollection of the previous discussions was more that we did not >> want CTK to use a 'copyleft' license, such as GPL, and that we >> preferred a more commercial friendly license with terms similar to >> BSD. The discussion brought out that most of the code that we already >> use has been released under licenses with terms similar to BSD, though >> not everyone was using a pure BSD license. I believe Apache has terms >> similar to and compatible with BSD, and would be a better match to our >> needs than simple BSD. >> >> >> >> >> >> -----Original Message----- >> From: ctk-developers-bounces at commontk.org >> [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Stephen Aylward >> Sent: Tuesday, April 13, 2010 8:45 AM >> To: Marco Viceconti >> Cc: ctk-developers at commontk.org >> Subject: Re: [Ctk-developers] COPYRIGHT & LICENSING >> >> Hi, >> >> The Apache 2.0 license is actually a BSD-style license. It is the >> new-BSD license with two additional paragraphs that are important >> based on our experiences with ITK. Note that ITK is now released >> under the Apache 2.0 license. >> >> There are some great articles on the benefits of Apache 2.0, such as >> "Apache better than GPL for open-source business?" >> http://news.cnet.com/8301-13505_3-10229817-16.html >> >> The full text of the license is available at: >> http://www.apache.org/licenses/LICENSE-2.0.html >> >> A FAQ on the Apache 2.0 license is at: >> http://www.apache.org/foundation/licence-FAQ.html >> >> Below is my interpretation of those two additional paragraphs: >> >> First paragraph >> ============= >> "Submission of Contributions. Unless You explicitly state otherwise, >> any Contribution intentionally submitted for inclusion in the Work by >> You to the Licensor shall be under the terms and conditions of this >> License, without any additional terms or conditions. Notwithstanding >> the above, nothing herein shall supersede or modify the terms of any >> separate license agreement you may have executed with Licensor >> regarding such Contributions." >> >> The above says that by contributing changes back to the main >> repository, you're agreeing to release your changes also under the >> Apache 2.0 license. Without this additional paragraph we'll need to >> specify licensing terms for every change to the code made by any >> contributor - that isn't feasible. Again, this paragraph does not >> request copyright transfer, just a license to redistribute, use etc. >> >> Second paragraph >> =============== >> "Grant of Patent License. Subject to the terms and conditions of this >> License, each Contributor hereby grants to You a perpetual, worldwide, >> non-exclusive, no-charge, royalty-free, irrevocable (except as stated >> in this section) patent license to make, have made, use, offer to >> sell, sell, import, and otherwise transfer the Work, where such >> license applies only to those patent claims licensable by such >> Contributor that are necessarily infringed by their Contribution(s) >> alone or by combination of their Contribution(s) with the Work to >> which such Contribution(s) was submitted. If You institute patent >> litigation against any entity (including a cross-claim or counterclaim >> in a lawsuit) alleging that the Work or a Contribution incorporated >> within the Work constitutes direct or contributory patent >> infringement, then any patent licenses granted to You under this >> License for that Work shall terminate as of the date such litigation >> is filed." >> >> This paragraph says that if you submit code to the repository you're >> also granting everyone a license to use that code even if you've filed >> for a patent that the code implements. Consider that if someone adds >> something to the CTK core that is covered by one of their own patents, >> then we may end up being sued (it really does happen way too often in >> America), having to pay them money to use CTK, or having to re-write >> that code. >> >> Hope this helps, >> Stephen >> >> On Tue, Apr 13, 2010 at 9:04 AM, Marco Viceconti >> wrote: >>> If I understand correctly the discussion so far, it seems that under an >>> appropriate FOSS license the tracking of copyright is unnecessary. >>> Still, I >>> disagree that it is irrelevant, as in addition to the personal proudness >>> there is also an institutional proudness, that tracking copyright to the >>> institution that contributed with a portion of code, somehow sustains. >>> Because of this I would suggest that each contributor should have the >>> right >>> to keep the copyright to his-her own institution. >>> >>> For the license, I agree with Luis that the choice is between an >>> handful of >>> options, such as MIT, BSD and Apache 2.0 licenses. Indeed, this point >>> was >>> extensively discussed in one of the first meetings of the CTK Group, as >>> correctly pointed out by J?rg Riesmeier. In that meeting we noticed >>> that a) >>> many of our frameworks and libraries are distributed under BSD, and >>> b) that >>> BSD has all the features we thought the CTK should had. >>> http://www.commontk.org/cgi-bin/trac.cgi/wiki/Whitepaper#BSDstylelicense >>> >>> Of course nothing is carved in stone, but I do not thing we should >>> simply >>> ignore what has been already extensively discussed. Thus, I would >>> suggest >>> to consider the topic in this light: there is decision in favour of >>> BSD. Is >>> there any argument that makes Apache 2.0 preferable over BSD? If we >>> opt for >>> Apache 2.0, is there any problem in re-using inside CTK code licensed >>> under >>> BSD, such as DCMTK? >>> >>> A last comment: while Apache 2.0 is clearly a more modern option, BSD >>> has >>> beauty of being the clearest license you can read. Now if it is true, >>> like >>> many says that in the end you get the same protection with both, I >>> would opt >>> for BSD if nothing else only for this. >>> >>> Cheers >>> >>> Marco >>> >>> >>> >>> Il giorno 12 Apr 2010, alle ore 16:23, Luis Ibanez ha scritto: >>> >>>> >>>> I agree with Bill, >>>> >>>> The choice of a good License is more important that who holds the >>>> Copyright (and patents, and trademarks) associated with the code. >>>> >>>> >>>> In practice, tracing the Copyright holders of code in an Open Source >>>> project is an impossible task. >>>> >>>> >>>> Whoever is contributing code to an Open Source project with the >>>> intention of conserving ownership or control over such code has >>>> flawed understanding of how software development works in a >>>> peer-production environment. >>>> >>>> >>>> Files tend to (and *should*) be modified by many different developers, >>>> who are affiliated to different institutions. Every institution will >>>> hold >>>> the >>>> copyright of every modification. >>>> >>>> >>>> You may know "who" is the copyright holder of a file, the first day >>>> that >>>> file >>>> is committed. But after ten years of this file being modified and >>>> retouched >>>> by twenty other developers from ten other institutions, you have a file >>>> where >>>> >>>> >>>> 55% of the lines are copyrighted by institution A >>>> 27% by institution B >>>> 13% by institution C.. >>>> ... and so on. >>>> >>>> >>>> In a well-managed open source project, such modifications of any given >>>> file by many different developers *is expected* to happen. >>>> >>>> When a file has only been touched by a single developer, that's an >>>> indication >>>> that nobody else in the project cares about such file, and that the >>>> project has >>>> poor practices of code review and suffers from lack of participation. >>>> >>>> So, even if any given organization want to conserve "ownership" of the >>>> code, that is simply unrealistic in practice. >>>> >>>> Assigning copyright of the code to a non-for-profit organization is >>>> actually >>>> a way of protecting the developers (and their institutions). >>>> >>>> This is discussed in great detail in: >>>> >>>> "Intellectual Property and Open Source >>>> A Practical Guide to Protecting Code" >>>> by Van Lindberg >>>> http://oreilly.com/catalog/9780596517960 >>>> >>>> >>>> >>>> >>>> In any case, what is more important is to chose a License, that make >>>> irrelevant >>>> (and unnecessary) to track ownership of the source code. The MIT, >>>> BSD and >>>> Apache 2.0 licenses are typical good choices that satisfy such >>>> condition. >>>> >>>> >>>> The Apache 2.0 license is particularly attractive in this case >>>> because it >>>> is >>>> the only one from this group, that includes specific clauses about code >>>> contributions. >>>> >>>> >>>> >>>> Luis >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------------------- >>>> >>>> On Mon, Apr 12, 2010 at 8:39 AM, Bill Lorensen >>>> >>>> wrote: >>>> I agree with that license is more important that the copyright holders. >>>> >>>> In VTK, many files have multiple copyrights, but all share the same >>>> license. >>>> >>>> Bill >>>> >>>> On Mon, Apr 12, 2010 at 8:35 AM, Ron Kikinis >>>> wrote: >>>>> Luis, >>>>> >>>>> The apache license sounds reasonable to me. In terms of making ISC the >>>>> owner >>>>> of the copyright: >>>>> As you know, we have taken a different approach with Slicer in that >>>>> the >>>>> contributors keep the copyright and only grant an irrevocable and >>>>> unlimited >>>>> license for use in Slicer (I am not a lawyer so this is not legal >>>>> language). >>>>> >>>>> On an other point: ISC was created to hold the copyright for ITK. The >>>>> website does not really reflect the more recent additions of cmake and >>>>> IGSTK. The board of directors primarily reflects ITK and would >>>>> probably >>>>> require some updates. >>>>> >>>>> One question: how "dictator proof" is ISC? >>>>> >>>>> Ron >>>>> >>>>> >>>>> >>>>> On 4/9/10 10:36 AM, Luis Ibanez wrote: >>>>>> >>>>>> Yes, >>>>>> it is not the most amusing conversation to have, >>>>>> but it is better to do this early... >>>>>> >>>>>> >>>>>> 1) Most files in CTK are lacking Copyright >>>>>> notices and an explicit License. >>>>>> >>>>>> 2) There is not LICENCE file at the top of >>>>>> the source tree. >>>>>> >>>>>> >>>>>> >>>>>> I propose that we assign the copyright of the source code >>>>>> to the Insight Software Consortium (ISC), and that we >>>>>> distribute the code under an Apache 2.0 License. >>>>>> >>>>>> http://www.opensource.org/licenses/apache2.0.php >>>>>> >>>>>> >>>>>> >>>>>> The ISC is the organization that holds the copyright of >>>>>> >>>>>> * ITK >>>>>> * CMake (along with Kitware) >>>>>> * IGSTK >>>>>> >>>>>> >>>>>> More information about the ISC at: >>>>>> >>>>>> http://www.insightsoftwareconsortium.org/ >>>>>> >>>>>> >>>>>> It will also be important for your respective organizations >>>>>> to join the ISC, or for you to join as individuals, so you >>>>>> help ensure that the CTK project is managed as you >>>>>> intended. >>>>>> >>>>>> >>>>>> Every day that passes without having a clear License >>>>>> and Copyright statement is a day were we are brewing >>>>>> a recipe for disaster. >>>>>> >>>>>> >>>>>> >>>>>> If someone needs to be persuaded, we can provide details >>>>>> on the horror story of how much trouble we are having in ITK >>>>>> with source code of dubious origin (no copyright notice nor >>>>>> license) that we adopted from www.netlib.org.... >>>>>> >>>>>> >>>>>> >>>>>> Luis >>>>>> _______________________________________________ >>>>>> Ctk-developers mailing list >>>>>> Ctk-developers at commontk.org >>>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>>> >>>>> -- >>>>> Ron Kikinis, M.D., >>>>> Robert Greenes Distinguished Director of Biomedical Informatics >>>>> Professor of Radiology, Harvard Medical School >>>>> Director, Surgical Planning Laboratory >>>>> http://www.spl.harvard.edu/~kikinis >>>>> _______________________________________________ >>>>> Ctk-developers mailing list >>>>> Ctk-developers at commontk.org >>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>>> >>>> _______________________________________________ >>>> Ctk-developers mailing list >>>> Ctk-developers at commontk.org >>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>> >>>> _______________________________________________ >>>> Ctk-developers mailing list >>>> Ctk-developers at commontk.org >>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>> >>> -------------------------------------------------- >>> MARCO VICECONTI, PhD (viceconti at tecno.ior.it) >>> Laboratorio di Tecnologia Medica tel. 39-051-6366865 >>> Istituto Ortopedico Rizzoli fax. 39-051-6366863 >>> via di Barbiano 1/10, 40136 - Bologna, Italy >>> >>> Tiger! Tiger! Burning bright in the forest of the night, >>> what immortal hand or eye could frame thy fearful symmetry? >>> -------------------------------------------------- >>> Opinions expressed here do not necessarily reflect those of my employer >>> >>> >>> >>> _______________________________________________ >>> Ctk-developers mailing list >>> Ctk-developers at commontk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>> >> >> >> >> -- >> Stephen R. Aylward, Ph.D. >> Director of Medical Imaging Research >> Kitware, Inc. - North Carolina Office >> http://www.kitware.com >> stephen.aylward (Skype) >> (919) 969-6990 x300 >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> The material in this message is private and may contain Protected >> Healthcare Information (PHI). If you are not the intended recipient, >> be advised that any unauthorized use, disclosure, copying or the >> taking of any action in reliance on the contents of this information >> is strictly prohibited. If you have received this email in error, >> please immediately notify the sender via telephone or return mail. >> > > -------------------------------------------------- > MARCO VICECONTI, PhD (viceconti at tecno.ior.it) > Laboratorio di Tecnologia Medica tel. 39-051-6366865 > Istituto Ortopedico Rizzoli fax. 39-051-6366863 > via di Barbiano 1/10, 40136 - Bologna, Italy > > Tiger! Tiger! Burning bright in the forest of the night, > what immortal hand or eye could frame thy fearful symmetry? > -------------------------------------------------- > Opinions expressed here do not necessarily reflect those of my employer > > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers The material in this message is private and may contain Protected Healthcare Information (PHI). If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail. From luis.ibanez at kitware.com Wed Apr 14 13:51:52 2010 From: luis.ibanez at kitware.com (Luis Ibanez) Date: Wed, 14 Apr 2010 09:51:52 -0400 Subject: [Ctk-developers] COPYRIGHT & LICENSING In-Reply-To: <4BC5BA8D.8040702@bwh.harvard.edu> References: <4BC313AA.6050408@bwh.harvard.edu> <67B4B5166383D848A0565AA7491841F93082F06AD3@RAD-VMSRVEXV2.rad.wustl.edu> <4BC5BA8D.8040702@bwh.harvard.edu> Message-ID: Just a word of warning: Should CTK include any code that is distributed under the LGPL license, it will be very important for such code to be clearly labeled and to be build only as an option. Ideally it should be put in a separate directory, or even better, in a separate source tree. That is, none of the essential classes should be covered by a LGPL license. The eventual LGPL code should then be compiled and archived into a *shared* library, in order to avoid propagation of the license to the rest of the system. The option of using LGPL code should probably be turned one from the CMake configuration at build time, and should be accompanied by the proper warnings, to make developers aware of the consequences that activating this code will have for the Licensing of the application that they are building at that point. Luis ------------------------------------------------------------------------------------------------------------- On Wed, Apr 14, 2010 at 8:52 AM, Steve Pieper wrote: > Additional considerations regarding Qt: > > Qt samples and user-contributed widgets are typically licensed under the > LGPL or the GPL (depending on history and developer preference - see > http://qt-apps.org for examples). > > My understanding of the Nokia policy is that if we start with /just/ the > LGPL'd Qt distribution and write a widget, we can distribute our widgets > under any license. > > However if we *incorporate and modify* existing GPL or LGPL code we need to > use the same license for our resulting code (the 'copyleft' requirement). > > Note that it is probably okay to /use/ an LGPL'd widget set via superbuild > without impacting the licensing of CTK widgets themselves (for example, if > we wanted to subclass existing widgets from something like Qxt > http://www.libqxt.org/). > > > As a practical matter, at the intersection of development and governance, > we need to develop a policy about what external code we can incorporate in > CTK and we need to be careful to follow that policy. > > My recommendations based on the current environment are: > > 1) Qt-based CTK Widgets will need to incorporate LGPL'd example code from > the wider developer community and will therefor need to be under the LGPL > license (different from the rest of CTK). > > 2) CTK developers will carefully review any projects from which they wish > to draw code and strictly avoid using any GPL'd code. (If the code is > particularly unique and valuable, contact the authors and ask if they will > consider releasing an LGPL or BSD-style version). > > > I would be very interested in comments from experienced Qt developers on > these topics: > > - does the analysis above match your understanding? > > - do we need to base our CTK widgets on LGPL'd examples? Or could we > accomplish our goals while adhering to a strict Apache/BSD-style licensing > approach only? > > > Regards, > Steve > > > > > > > > On Apr/14/10 7:53 AM, Marco Viceconti wrote: > >> Lawrence is right to say that no one had strong opinions in favour of >> BSD as such, and in the end the decision was taken only because most >> existing codes represented around the table were already BSD. On the >> contrary there was strong consensus on staying away from copyleft >> licenses. >> >> Stephen point on patents is very relevant, so I recognise that it is >> probably a good idea to go for Apache 2.0 for CTK. As a side effect, we >> shall now revise this matter internally to B3C, and we might indeed >> decide to adopt Apache 2.0 also for MAF3. >> >> Cheers >> >> Marco >> >> >> >> >> Il giorno 13 Apr 2010, alle ore 17:16, Tarbox, Lawrence ha scritto: >> >> I concur with Stephen. >>> >>> The pure BSD license does not address certain key issues, such as >>> patents, trademarks, and contributions, that potentially could be very >>> problematic in an open source project with multiple contributors from >>> multiple organizations. The Apache license closes those holes, while >>> still being essentially a BSD license at its core. (Compare the text >>> of clauses 3, 8, and 9 with the BSD license - they are nearly >>> identical to the BSD license.) >>> >>> As far as I know, there is little problem including BSD code in a >>> project licensed under Apache, as long as there are no problems with >>> patent or trademark infringements in the BSD code. >>> >>> My recollection of the previous discussions was more that we did not >>> want CTK to use a 'copyleft' license, such as GPL, and that we >>> preferred a more commercial friendly license with terms similar to >>> BSD. The discussion brought out that most of the code that we already >>> use has been released under licenses with terms similar to BSD, though >>> not everyone was using a pure BSD license. I believe Apache has terms >>> similar to and compatible with BSD, and would be a better match to our >>> needs than simple BSD. >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: ctk-developers-bounces at commontk.org >>> [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Stephen >>> Aylward >>> Sent: Tuesday, April 13, 2010 8:45 AM >>> To: Marco Viceconti >>> Cc: ctk-developers at commontk.org >>> Subject: Re: [Ctk-developers] COPYRIGHT & LICENSING >>> >>> Hi, >>> >>> The Apache 2.0 license is actually a BSD-style license. It is the >>> new-BSD license with two additional paragraphs that are important >>> based on our experiences with ITK. Note that ITK is now released >>> under the Apache 2.0 license. >>> >>> There are some great articles on the benefits of Apache 2.0, such as >>> "Apache better than GPL for open-source business?" >>> http://news.cnet.com/8301-13505_3-10229817-16.html >>> >>> The full text of the license is available at: >>> http://www.apache.org/licenses/LICENSE-2.0.html >>> >>> A FAQ on the Apache 2.0 license is at: >>> http://www.apache.org/foundation/licence-FAQ.html >>> >>> Below is my interpretation of those two additional paragraphs: >>> >>> First paragraph >>> ============= >>> "Submission of Contributions. Unless You explicitly state otherwise, >>> any Contribution intentionally submitted for inclusion in the Work by >>> You to the Licensor shall be under the terms and conditions of this >>> License, without any additional terms or conditions. Notwithstanding >>> the above, nothing herein shall supersede or modify the terms of any >>> separate license agreement you may have executed with Licensor >>> regarding such Contributions." >>> >>> The above says that by contributing changes back to the main >>> repository, you're agreeing to release your changes also under the >>> Apache 2.0 license. Without this additional paragraph we'll need to >>> specify licensing terms for every change to the code made by any >>> contributor - that isn't feasible. Again, this paragraph does not >>> request copyright transfer, just a license to redistribute, use etc. >>> >>> Second paragraph >>> =============== >>> "Grant of Patent License. Subject to the terms and conditions of this >>> License, each Contributor hereby grants to You a perpetual, worldwide, >>> non-exclusive, no-charge, royalty-free, irrevocable (except as stated >>> in this section) patent license to make, have made, use, offer to >>> sell, sell, import, and otherwise transfer the Work, where such >>> license applies only to those patent claims licensable by such >>> Contributor that are necessarily infringed by their Contribution(s) >>> alone or by combination of their Contribution(s) with the Work to >>> which such Contribution(s) was submitted. If You institute patent >>> litigation against any entity (including a cross-claim or counterclaim >>> in a lawsuit) alleging that the Work or a Contribution incorporated >>> within the Work constitutes direct or contributory patent >>> infringement, then any patent licenses granted to You under this >>> License for that Work shall terminate as of the date such litigation >>> is filed." >>> >>> This paragraph says that if you submit code to the repository you're >>> also granting everyone a license to use that code even if you've filed >>> for a patent that the code implements. Consider that if someone adds >>> something to the CTK core that is covered by one of their own patents, >>> then we may end up being sued (it really does happen way too often in >>> America), having to pay them money to use CTK, or having to re-write >>> that code. >>> >>> Hope this helps, >>> Stephen >>> >>> On Tue, Apr 13, 2010 at 9:04 AM, Marco Viceconti >>> wrote: >>> >>>> If I understand correctly the discussion so far, it seems that under an >>>> appropriate FOSS license the tracking of copyright is unnecessary. >>>> Still, I >>>> disagree that it is irrelevant, as in addition to the personal proudness >>>> there is also an institutional proudness, that tracking copyright to the >>>> institution that contributed with a portion of code, somehow sustains. >>>> Because of this I would suggest that each contributor should have the >>>> right >>>> to keep the copyright to his-her own institution. >>>> >>>> For the license, I agree with Luis that the choice is between an >>>> handful of >>>> options, such as MIT, BSD and Apache 2.0 licenses. Indeed, this point >>>> was >>>> extensively discussed in one of the first meetings of the CTK Group, as >>>> correctly pointed out by J?rg Riesmeier. In that meeting we noticed >>>> that a) >>>> many of our frameworks and libraries are distributed under BSD, and >>>> b) that >>>> BSD has all the features we thought the CTK should had. >>>> http://www.commontk.org/cgi-bin/trac.cgi/wiki/Whitepaper#BSDstylelicense >>>> >>>> Of course nothing is carved in stone, but I do not thing we should >>>> simply >>>> ignore what has been already extensively discussed. Thus, I would >>>> suggest >>>> to consider the topic in this light: there is decision in favour of >>>> BSD. Is >>>> there any argument that makes Apache 2.0 preferable over BSD? If we >>>> opt for >>>> Apache 2.0, is there any problem in re-using inside CTK code licensed >>>> under >>>> BSD, such as DCMTK? >>>> >>>> A last comment: while Apache 2.0 is clearly a more modern option, BSD >>>> has >>>> beauty of being the clearest license you can read. Now if it is true, >>>> like >>>> many says that in the end you get the same protection with both, I >>>> would opt >>>> for BSD if nothing else only for this. >>>> >>>> Cheers >>>> >>>> Marco >>>> >>>> >>>> >>>> Il giorno 12 Apr 2010, alle ore 16:23, Luis Ibanez ha scritto: >>>> >>>> >>>>> I agree with Bill, >>>>> >>>>> The choice of a good License is more important that who holds the >>>>> Copyright (and patents, and trademarks) associated with the code. >>>>> >>>>> >>>>> In practice, tracing the Copyright holders of code in an Open Source >>>>> project is an impossible task. >>>>> >>>>> >>>>> Whoever is contributing code to an Open Source project with the >>>>> intention of conserving ownership or control over such code has >>>>> flawed understanding of how software development works in a >>>>> peer-production environment. >>>>> >>>>> >>>>> Files tend to (and *should*) be modified by many different developers, >>>>> who are affiliated to different institutions. Every institution will >>>>> hold >>>>> the >>>>> copyright of every modification. >>>>> >>>>> >>>>> You may know "who" is the copyright holder of a file, the first day >>>>> that >>>>> file >>>>> is committed. But after ten years of this file being modified and >>>>> retouched >>>>> by twenty other developers from ten other institutions, you have a file >>>>> where >>>>> >>>>> >>>>> 55% of the lines are copyrighted by institution A >>>>> 27% by institution B >>>>> 13% by institution C.. >>>>> ... and so on. >>>>> >>>>> >>>>> In a well-managed open source project, such modifications of any given >>>>> file by many different developers *is expected* to happen. >>>>> >>>>> When a file has only been touched by a single developer, that's an >>>>> indication >>>>> that nobody else in the project cares about such file, and that the >>>>> project has >>>>> poor practices of code review and suffers from lack of participation. >>>>> >>>>> So, even if any given organization want to conserve "ownership" of the >>>>> code, that is simply unrealistic in practice. >>>>> >>>>> Assigning copyright of the code to a non-for-profit organization is >>>>> actually >>>>> a way of protecting the developers (and their institutions). >>>>> >>>>> This is discussed in great detail in: >>>>> >>>>> "Intellectual Property and Open Source >>>>> A Practical Guide to Protecting Code" >>>>> by Van Lindberg >>>>> http://oreilly.com/catalog/9780596517960 >>>>> >>>>> >>>>> >>>>> >>>>> In any case, what is more important is to chose a License, that make >>>>> irrelevant >>>>> (and unnecessary) to track ownership of the source code. The MIT, >>>>> BSD and >>>>> Apache 2.0 licenses are typical good choices that satisfy such >>>>> condition. >>>>> >>>>> >>>>> The Apache 2.0 license is particularly attractive in this case >>>>> because it >>>>> is >>>>> the only one from this group, that includes specific clauses about code >>>>> contributions. >>>>> >>>>> >>>>> >>>>> Luis >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------------------- >>>>> >>>>> On Mon, Apr 12, 2010 at 8:39 AM, Bill Lorensen >>>>> >>>>> wrote: >>>>> I agree with that license is more important that the copyright holders. >>>>> >>>>> In VTK, many files have multiple copyrights, but all share the same >>>>> license. >>>>> >>>>> Bill >>>>> >>>>> On Mon, Apr 12, 2010 at 8:35 AM, Ron Kikinis >>>>> wrote: >>>>> >>>>>> Luis, >>>>>> >>>>>> The apache license sounds reasonable to me. In terms of making ISC the >>>>>> owner >>>>>> of the copyright: >>>>>> As you know, we have taken a different approach with Slicer in that >>>>>> the >>>>>> contributors keep the copyright and only grant an irrevocable and >>>>>> unlimited >>>>>> license for use in Slicer (I am not a lawyer so this is not legal >>>>>> language). >>>>>> >>>>>> On an other point: ISC was created to hold the copyright for ITK. The >>>>>> website does not really reflect the more recent additions of cmake and >>>>>> IGSTK. The board of directors primarily reflects ITK and would >>>>>> probably >>>>>> require some updates. >>>>>> >>>>>> One question: how "dictator proof" is ISC? >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> >>>>>> On 4/9/10 10:36 AM, Luis Ibanez wrote: >>>>>> >>>>>>> >>>>>>> Yes, >>>>>>> it is not the most amusing conversation to have, >>>>>>> but it is better to do this early... >>>>>>> >>>>>>> >>>>>>> 1) Most files in CTK are lacking Copyright >>>>>>> notices and an explicit License. >>>>>>> >>>>>>> 2) There is not LICENCE file at the top of >>>>>>> the source tree. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I propose that we assign the copyright of the source code >>>>>>> to the Insight Software Consortium (ISC), and that we >>>>>>> distribute the code under an Apache 2.0 License. >>>>>>> >>>>>>> http://www.opensource.org/licenses/apache2.0.php >>>>>>> >>>>>>> >>>>>>> >>>>>>> The ISC is the organization that holds the copyright of >>>>>>> >>>>>>> * ITK >>>>>>> * CMake (along with Kitware) >>>>>>> * IGSTK >>>>>>> >>>>>>> >>>>>>> More information about the ISC at: >>>>>>> >>>>>>> http://www.insightsoftwareconsortium.org/ >>>>>>> >>>>>>> >>>>>>> It will also be important for your respective organizations >>>>>>> to join the ISC, or for you to join as individuals, so you >>>>>>> help ensure that the CTK project is managed as you >>>>>>> intended. >>>>>>> >>>>>>> >>>>>>> Every day that passes without having a clear License >>>>>>> and Copyright statement is a day were we are brewing >>>>>>> a recipe for disaster. >>>>>>> >>>>>>> >>>>>>> >>>>>>> If someone needs to be persuaded, we can provide details >>>>>>> on the horror story of how much trouble we are having in ITK >>>>>>> with source code of dubious origin (no copyright notice nor >>>>>>> license) that we adopted from www.netlib.org.... >>>>>>> >>>>>>> >>>>>>> >>>>>>> Luis >>>>>>> _______________________________________________ >>>>>>> Ctk-developers mailing list >>>>>>> Ctk-developers at commontk.org >>>>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>>>>> >>>>>> >>>>>> -- >>>>>> Ron Kikinis, M.D., >>>>>> Robert Greenes Distinguished Director of Biomedical Informatics >>>>>> Professor of Radiology, Harvard Medical School >>>>>> Director, Surgical Planning Laboratory >>>>>> http://www.spl.harvard.edu/~kikinis >>>>>> _______________________________________________ >>>>>> Ctk-developers mailing list >>>>>> Ctk-developers at commontk.org >>>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>>>> >>>>>> _______________________________________________ >>>>> Ctk-developers mailing list >>>>> Ctk-developers at commontk.org >>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>>> >>>>> _______________________________________________ >>>>> Ctk-developers mailing list >>>>> Ctk-developers at commontk.org >>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>>> >>>> >>>> -------------------------------------------------- >>>> MARCO VICECONTI, PhD (viceconti at tecno.ior.it) >>>> Laboratorio di Tecnologia Medica tel. 39-051-6366865 >>>> Istituto Ortopedico Rizzoli fax. 39-051-6366863 >>>> via di Barbiano 1/10, 40136 - Bologna, Italy >>>> >>>> Tiger! Tiger! Burning bright in the forest of the night, >>>> what immortal hand or eye could frame thy fearful symmetry? >>>> -------------------------------------------------- >>>> Opinions expressed here do not necessarily reflect those of my employer >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ctk-developers mailing list >>>> Ctk-developers at commontk.org >>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>> >>>> >>> >>> >>> -- >>> Stephen R. Aylward, Ph.D. >>> Director of Medical Imaging Research >>> Kitware, Inc. - North Carolina Office >>> http://www.kitware.com >>> stephen.aylward (Skype) >>> (919) 969-6990 x300 >>> _______________________________________________ >>> Ctk-developers mailing list >>> Ctk-developers at commontk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>> >>> The material in this message is private and may contain Protected >>> Healthcare Information (PHI). If you are not the intended recipient, >>> be advised that any unauthorized use, disclosure, copying or the >>> taking of any action in reliance on the contents of this information >>> is strictly prohibited. If you have received this email in error, >>> please immediately notify the sender via telephone or return mail. >>> >>> >> -------------------------------------------------- >> MARCO VICECONTI, PhD (viceconti at tecno.ior.it) >> Laboratorio di Tecnologia Medica tel. 39-051-6366865 >> Istituto Ortopedico Rizzoli fax. 39-051-6366863 >> via di Barbiano 1/10, 40136 - Bologna, Italy >> >> Tiger! Tiger! Burning bright in the forest of the night, >> what immortal hand or eye could frame thy fearful symmetry? >> -------------------------------------------------- >> Opinions expressed here do not necessarily reflect those of my employer >> >> >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pieper at bwh.harvard.edu Wed Apr 14 13:56:44 2010 From: pieper at bwh.harvard.edu (Steve Pieper) Date: Wed, 14 Apr 2010 09:56:44 -0400 Subject: [Ctk-developers] COPYRIGHT & LICENSING In-Reply-To: References: <4BC313AA.6050408@bwh.harvard.edu> <67B4B5166383D848A0565AA7491841F93082F06AD3@RAD-VMSRVEXV2.rad.wustl.edu> <4BC5BA8D.8040702@bwh.harvard.edu> Message-ID: <4BC5C99C.1000505@bwh.harvard.edu> Agreed - I'm reluctant to use LGPL'd code for these reasons. However it may be required in practice by our choice of Qt and the trends for meaningful participation in that development community.... -Steve On Apr/14/10 9:51 AM, Luis Ibanez wrote: > > Just a word of warning: > > Should CTK include any code that is distributed under the LGPL license, > it will be very important for such code to be clearly labeled and to be > build > only as an option. Ideally it should be put in a separate directory, or > even > better, in a separate source tree. > > That is, > none of the essential classes should be covered by a LGPL license. > > > The eventual LGPL code should then be compiled and archived into a > *shared* library, in order to avoid propagation of the license to the rest > of the system. > > > The option of using LGPL code should probably be turned one from the > CMake configuration at build time, and should be accompanied by the > proper warnings, to make developers aware of the consequences that > activating this code will have for the Licensing of the application that > they are building at that point. > > > Luis > > > ------------------------------------------------------------------------------------------------------------- > On Wed, Apr 14, 2010 at 8:52 AM, Steve Pieper > wrote: > > Additional considerations regarding Qt: > > Qt samples and user-contributed widgets are typically licensed under > the LGPL or the GPL (depending on history and developer preference - > see http://qt-apps.org for examples). > > My understanding of the Nokia policy is that if we start with /just/ > the LGPL'd Qt distribution and write a widget, we can distribute our > widgets under any license. > > However if we *incorporate and modify* existing GPL or LGPL code we > need to use the same license for our resulting code (the 'copyleft' > requirement). > > Note that it is probably okay to /use/ an LGPL'd widget set via > superbuild without impacting the licensing of CTK widgets themselves > (for example, if we wanted to subclass existing widgets from > something like Qxt http://www.libqxt.org/). > > > As a practical matter, at the intersection of development and > governance, we need to develop a policy about what external code we > can incorporate in CTK and we need to be careful to follow that policy. > > My recommendations based on the current environment are: > > 1) Qt-based CTK Widgets will need to incorporate LGPL'd example code > from the wider developer community and will therefor need to be > under the LGPL license (different from the rest of CTK). > > 2) CTK developers will carefully review any projects from which they > wish to draw code and strictly avoid using any GPL'd code. (If the > code is particularly unique and valuable, contact the authors and > ask if they will consider releasing an LGPL or BSD-style version). > > > I would be very interested in comments from experienced Qt > developers on these topics: > > - does the analysis above match your understanding? > > - do we need to base our CTK widgets on LGPL'd examples? Or could > we accomplish our goals while adhering to a strict Apache/BSD-style > licensing approach only? > > > Regards, > Steve > > > > From stephen.aylward at kitware.com Wed Apr 14 18:04:25 2010 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Wed, 14 Apr 2010 14:04:25 -0400 Subject: [Ctk-developers] New webpages Message-ID: Hi, We've switched from Trac to MediaWiki for the commontk.org website. You should receive an email with your new account information if you had previously signed up for one. Visit: http://www.commontk.org I've moved the info from the old site to the new one - feel free to fix any errors I made during the cut-n-paste process. Hopefully this more familiar wiki format will encourage the site to be more heavily used - to host meetings notes, design discussions, etc. s -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From p.quadrani at scsolutions.it Thu Apr 15 11:31:22 2010 From: p.quadrani at scsolutions.it (Quadrani Paolo) Date: Thu, 15 Apr 2010 13:31:22 +0200 Subject: [Ctk-developers] New webpages In-Reply-To: References: Message-ID: <3830AEDE-0754-4E0B-A443-CFEC89F45252@scsolutions.it> Hi Stephen, good job. It's nicer now ;) Paolo On 14/apr/10, at 20:04, Stephen Aylward wrote: > Hi, > > We've switched from Trac to MediaWiki for the commontk.org website. > > You should receive an email with your new account information if you > had previously signed up for one. > > Visit: > http://www.commontk.org > > I've moved the info from the old site to the new one - feel free to > fix any errors I made during the cut-n-paste process. > > Hopefully this more familiar wiki format will encourage the site to be > more heavily used - to host meetings notes, design discussions, etc. > > s > > -- > Stephen R. Aylward, Ph.D. > Director of Medical Imaging Research > Kitware, Inc. - North Carolina Office > http://www.kitware.com > stephen.aylward (Skype) > (919) 969-6990 x300 > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers Paolo Quadrani _________________________________ BioComputing Competence Centre SCS s.r.l. Via Magnanelli 6/3, 40033 Casalecchio di Reno Italy http://bit.ly/9pqADE From p.quadrani at scsolutions.it Thu Apr 15 12:24:28 2010 From: p.quadrani at scsolutions.it (Quadrani Paolo) Date: Thu, 15 Apr 2010 14:24:28 +0200 Subject: [Ctk-developers] Coding conventions Message-ID: <371B77E1-03F8-415C-A180-A2D0492C9058@scsolutions.it> Dear CTK developers, as I saw that some code has been written and pushed to the Gti repository made available from Steve Pieper, I would suggest to you all to start thinking also at defining some coding conventions, so our code will looks homogeneous and nice and clear to read / understand. In MAF3 we have defined some simple rules to follow and you can review them at this address: http://bit.ly/95k5rJ If you like, I can propose to adopt them or we can start from them and define the CTK coding conventions. According to those rules, we have already some python scripts that automatically checks that all of those rules are respected in source code written and committed in the repository. Attached you can find a couple of MAF3 classes (as example) that I wrote for the framework. Cheers Paolo Quadrani _________________________________ BioComputing Competence Centre SCS s.r.l. Via Magnanelli 6/3, 40033 Casalecchio di Reno Italy http://bit.ly/9pqADE -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mafMemento.h Type: application/octet-stream Size: 1963 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mafObject.h Type: application/octet-stream Size: 3680 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From pieper at bwh.harvard.edu Thu Apr 15 13:20:47 2010 From: pieper at bwh.harvard.edu (Steve Pieper) Date: Thu, 15 Apr 2010 09:20:47 -0400 Subject: [Ctk-developers] Coding conventions In-Reply-To: <371B77E1-03F8-415C-A180-A2D0492C9058@scsolutions.it> References: <371B77E1-03F8-415C-A180-A2D0492C9058@scsolutions.it> Message-ID: <4BC712AF.60109@bwh.harvard.edu> Hi Paolo - Excellent - thanks. We can also look at the slicer guidelines to get ideas: http://www.slicer.org/slicerWiki/index.php/Slicer3:Style Really the thing I feel strongly about is this statement: > All C++ classes must conform to the style conventions of their parent classes. For pure CTK classes, I like the idea of promoting a 'best of the best' style guideline and the maf one looks good to me. Do other projects (MITK, DTK, etc) have style guideline pages we could look at? -Steve On Apr/15/10 8:24 AM, Quadrani Paolo wrote: > Dear CTK developers, > as I saw that some code has been written and pushed to the Gti > repository made available from Steve Pieper, I would suggest to you all > to start thinking also at defining some *coding conventions*, so our > code will looks homogeneous and nice and clear to read / understand. > > In *MAF3* we have *defined some simple rules* to follow and you can > review them at this address: http://bit.ly/95k5rJ > If you like, I can propose to adopt them or we can start from them and > define the CTK coding conventions. > > According to those rules, we have already some python scripts that > automatically checks that all of those rules are respected in source > code written and committed in the repository. > > Attached you can find a couple of MAF3 classes (as example) that I wrote > for the framework. > > Cheers > > Paolo Quadrani > _________________________________ > BioComputing Competence Centre > SCS s.r.l. > > Via Magnanelli 6/3, 40033 > Casalecchio di Reno > Italy > http://bit.ly/9pqADE > > > > > > > > > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers From d.giunchi at scsolutions.it Thu Apr 15 13:37:09 2010 From: d.giunchi at scsolutions.it (Daniele Giunchi) Date: Thu, 15 Apr 2010 15:37:09 +0200 Subject: [Ctk-developers] Coding conventions In-Reply-To: <4BC712AF.60109@bwh.harvard.edu> References: <371B77E1-03F8-415C-A180-A2D0492C9058@scsolutions.it> <4BC712AF.60109@bwh.harvard.edu> Message-ID: Dear All, in Paolo's mail there is also the suggestion to use this "MAF compact QA kit" written in python (we actually use it in MAF3) which can monitoring file naming convention, class variables/methods naming convention, presence of documentation, comments percentage and so on (it can be extended with new "rules"). Obviously all the results can be published in html, and we'are planning to extend it in order to create diagram of those quantities. I think that it should increase quality and coherence of committed code. best regards, Daniele On Thu, Apr 15, 2010 at 3:20 PM, Steve Pieper wrote: > Hi Paolo - > > Excellent - thanks. > > We can also look at the slicer guidelines to get ideas: > > http://www.slicer.org/slicerWiki/index.php/Slicer3:Style > > Really the thing I feel strongly about is this statement: > >> All C++ classes must conform to the style conventions of their parent >> classes. > > For pure CTK classes, I like the idea of promoting a 'best of the best' > style guideline and the maf one looks good to me. > > Do other projects (MITK, DTK, etc) have style guideline pages we could look > at? > > -Steve > > > > On Apr/15/10 8:24 AM, Quadrani Paolo wrote: >> >> Dear CTK developers, >> as I saw that some code has been written and pushed to the Gti >> repository made available from Steve Pieper, I would suggest to you all >> to start thinking also at defining some *coding conventions*, so our >> code will looks homogeneous and nice and clear to read / understand. >> >> In *MAF3* we have *defined some simple rules* to follow and you can >> review them at this address: http://bit.ly/95k5rJ >> If you like, I can propose to adopt them or we can start from them and >> define the CTK coding conventions. >> >> According to those rules, we have already some python scripts that >> automatically checks that all of those rules are respected in source >> code written and committed in the repository. >> >> Attached you can find a couple of MAF3 classes (as example) that I wrote >> for the framework. >> >> Cheers >> >> Paolo Quadrani >> _________________________________ >> BioComputing Competence Centre >> SCS s.r.l. >> >> Via Magnanelli 6/3, 40033 >> Casalecchio di Reno >> Italy >> http://bit.ly/9pqADE >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > From stephen.aylward at kitware.com Thu Apr 15 13:59:22 2010 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Thu, 15 Apr 2010 09:59:22 -0400 Subject: [Ctk-developers] Coding conventions In-Reply-To: References: <371B77E1-03F8-415C-A180-A2D0492C9058@scsolutions.it> <4BC712AF.60109@bwh.harvard.edu> Message-ID: Note there is also the open-source kwstyle system for this: For example, someone just checked code into one of our projects with style errors. The report is on the web at: https://www.kitware.com/CDash/viewBuildError.php?buildid=74253 KWStyle is integrated with the project's dashboard: https://www.kitware.com/CDash/index.php?project=TubeTK s On Thu, Apr 15, 2010 at 9:37 AM, Daniele Giunchi wrote: > Dear All, > > in Paolo's mail there is also the suggestion to use this "MAF compact > QA kit" written in python (we actually use it in MAF3) which can > monitoring file naming convention, class variables/methods naming > convention, presence of documentation, > comments percentage and so on (it can be extended with new "rules"). > Obviously all the results can be published in html, and we'are > planning to extend it in order to create diagram of those quantities. > I think that it should increase quality and coherence of committed code. > > best regards, > Daniele > > > > > On Thu, Apr 15, 2010 at 3:20 PM, Steve Pieper wrote: >> Hi Paolo - >> >> Excellent - thanks. >> >> We can also look at the slicer guidelines to get ideas: >> >> http://www.slicer.org/slicerWiki/index.php/Slicer3:Style >> >> Really the thing I feel strongly about is this statement: >> >>> All C++ classes must conform to the style conventions of their parent >>> classes. >> >> For pure CTK classes, I like the idea of promoting a 'best of the best' >> style guideline and the maf one looks good to me. >> >> Do other projects (MITK, DTK, etc) have style guideline pages we could look >> at? >> >> -Steve >> >> >> >> On Apr/15/10 8:24 AM, Quadrani Paolo wrote: >>> >>> Dear CTK developers, >>> as I saw that some code has been written and pushed to the Gti >>> repository made available from Steve Pieper, I would suggest to you all >>> to start thinking also at defining some *coding conventions*, so our >>> code will looks homogeneous and nice and clear to read / understand. >>> >>> In *MAF3* we have *defined some simple rules* to follow and you can >>> review them at this address: http://bit.ly/95k5rJ >>> If you like, I can propose to adopt them or we can start from them and >>> define the CTK coding conventions. >>> >>> According to those rules, we have already some python scripts that >>> automatically checks that all of those rules are respected in source >>> code written and committed in the repository. >>> >>> Attached you can find a couple of MAF3 classes (as example) that I wrote >>> for the framework. >>> >>> Cheers >>> >>> Paolo Quadrani >>> _________________________________ >>> BioComputing Competence Centre >>> SCS s.r.l. >>> >>> Via Magnanelli 6/3, 40033 >>> Casalecchio di Reno >>> Italy >>> http://bit.ly/9pqADE >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Ctk-developers mailing list >>> Ctk-developers at commontk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From stephen.aylward at kitware.com Thu Apr 15 14:08:22 2010 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Thu, 15 Apr 2010 10:08:22 -0400 Subject: [Ctk-developers] EU participation In-Reply-To: References: <81EA6BC8-73FB-4249-8A45-66E10EBDAF3E@tecno.ior.it> Message-ID: May I add this as a news item on the ctk wiki? s On Wed, Apr 14, 2010 at 3:21 AM, olivier clatz wrote: > Hello Stephen, > > Sure ! > please find attached the abstract + the first paragraphs I find useful to > understand the proposal. > > Olivier > > > 2010/4/13 Stephen Aylward >> >> Congratulations on the submission! ? Such funding would be outstanding for >> CTK! >> >> Would a summary/short version of the proposal be helpful in >> establishing a roadmap for or in some way advertising CTK? >> >> s >> >> On Tue, Apr 13, 2010 at 8:42 AM, Marco Viceconti >> wrote: >> > Hi everybody; a couple of recents email inspired me some comments, which >> > I >> > shall divide on multiple emails to keep the treads separated. >> > >> > First a general note: the EU arm of the CTK community in these days has >> > not >> > been so active because today is the deadline for the largest call for >> > proposals in the VPH domain, so we are all snowed under. >> > >> > The good news is that thanks to the excellent work of many CTK partners, >> > steered by our friends at INRIAS, the eXCITe proposal has been finalised >> > and >> > is now being submitted. ?If approved this grant will to many of us the >> > resources to extend CTK with some hopefully fancy additions. >> > >> > Cheers >> > >> > Marco >> > >> > >> > -------------------------------------------------- >> > MARCO VICECONTI, PhD >> > (viceconti at tecno.ior.it) >> > Laboratorio di Tecnologia Medica ? ? ? ? ? ? ?tel. ? 39-051-6366865 >> > Istituto Ortopedico Rizzoli ? ? ? ? ? ? ? ? ? ? ? ? ? ?fax. >> > 39-051-6366863 >> > via di Barbiano 1/10, 40136 - Bologna, Italy >> > >> > Tiger! Tiger! Burning bright in the forest of the night, >> > what immortal hand or eye could frame thy fearful symmetry? >> > -------------------------------------------------- >> > Opinions expressed here do not necessarily reflect those of my employer >> > >> > >> > >> > _______________________________________________ >> > Ctk-developers mailing list >> > Ctk-developers at commontk.org >> > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> > >> >> >> >> -- >> Stephen R. Aylward, Ph.D. >> Director of Medical Imaging Research >> Kitware, Inc. - North Carolina Office >> http://www.kitware.com >> stephen.aylward (Skype) >> (919) 969-6990 x300 >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > > > -- > =========================================================== > Olivier Clatz > Research Scientist > INRIA Sophia Antipolis > 2004 route des lucioles > 06902 Sophia Antipolis > France > http://www-sop.inria.fr/members/Olivier.Clatz/ > Tel: +33 4 92 38 71 59 > Fax: +33 4 92 38 76 69 > =========================================================== > -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From stephen.aylward at kitware.com Thu Apr 15 14:22:13 2010 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Thu, 15 Apr 2010 10:22:13 -0400 Subject: [Ctk-developers] EU participation In-Reply-To: References: <81EA6BC8-73FB-4249-8A45-66E10EBDAF3E@tecno.ior.it> Message-ID: I fully understand. Thanks, Stephen On Thu, Apr 15, 2010 at 10:20 AM, olivier clatz wrote: > Hello Stephen, > > I would rather like it to stay in email boxes for the moment. > It is only a proposal so far, and it would be preferable to wait for the > (hopefully positive) outcome before making it "fully" public ... > > Thanks, > > Olivier > > > > 2010/4/15 Stephen Aylward >> >> May I add this as a news item on the ctk wiki? >> >> s >> >> On Wed, Apr 14, 2010 at 3:21 AM, olivier clatz wrote: >> > Hello Stephen, >> > >> > Sure ! >> > please find attached the abstract + the first paragraphs I find useful >> > to >> > understand the proposal. >> > >> > Olivier >> > >> > >> > 2010/4/13 Stephen Aylward >> >> >> >> Congratulations on the submission! ? Such funding would be outstanding >> >> for >> >> CTK! >> >> >> >> Would a summary/short version of the proposal be helpful in >> >> establishing a roadmap for or in some way advertising CTK? >> >> >> >> s >> >> >> >> On Tue, Apr 13, 2010 at 8:42 AM, Marco Viceconti >> >> >> >> wrote: >> >> > Hi everybody; a couple of recents email inspired me some comments, >> >> > which >> >> > I >> >> > shall divide on multiple emails to keep the treads separated. >> >> > >> >> > First a general note: the EU arm of the CTK community in these days >> >> > has >> >> > not >> >> > been so active because today is the deadline for the largest call for >> >> > proposals in the VPH domain, so we are all snowed under. >> >> > >> >> > The good news is that thanks to the excellent work of many CTK >> >> > partners, >> >> > steered by our friends at INRIAS, the eXCITe proposal has been >> >> > finalised >> >> > and >> >> > is now being submitted. ?If approved this grant will to many of us >> >> > the >> >> > resources to extend CTK with some hopefully fancy additions. >> >> > >> >> > Cheers >> >> > >> >> > Marco >> >> > >> >> > >> >> > -------------------------------------------------- >> >> > MARCO VICECONTI, PhD >> >> > (viceconti at tecno.ior.it) >> >> > Laboratorio di Tecnologia Medica ? ? ? ? ? ? ?tel. ? 39-051-6366865 >> >> > Istituto Ortopedico Rizzoli ? ? ? ? ? ? ? ? ? ? ? ? ? ?fax. >> >> > 39-051-6366863 >> >> > via di Barbiano 1/10, 40136 - Bologna, Italy >> >> > >> >> > Tiger! Tiger! Burning bright in the forest of the night, >> >> > what immortal hand or eye could frame thy fearful symmetry? >> >> > -------------------------------------------------- >> >> > Opinions expressed here do not necessarily reflect those of my >> >> > employer >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > Ctk-developers mailing list >> >> > Ctk-developers at commontk.org >> >> > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> > >> >> >> >> >> >> >> >> -- >> >> Stephen R. Aylward, Ph.D. >> >> Director of Medical Imaging Research >> >> Kitware, Inc. - North Carolina Office >> >> http://www.kitware.com >> >> stephen.aylward (Skype) >> >> (919) 969-6990 x300 >> >> _______________________________________________ >> >> Ctk-developers mailing list >> >> Ctk-developers at commontk.org >> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> > >> > >> > >> > -- >> > =========================================================== >> > Olivier Clatz >> > Research Scientist >> > INRIA Sophia Antipolis >> > 2004 route des lucioles >> > 06902 Sophia Antipolis >> > France >> > http://www-sop.inria.fr/members/Olivier.Clatz/ >> > Tel: +33 4 92 38 71 59 >> > Fax: +33 4 92 38 76 69 >> > =========================================================== >> > >> >> >> >> -- >> Stephen R. Aylward, Ph.D. >> Director of Medical Imaging Research >> Kitware, Inc. - North Carolina Office >> http://www.kitware.com >> stephen.aylward (Skype) >> (919) 969-6990 x300 > > > > -- > =========================================================== > Olivier Clatz > Research Scientist > INRIA Sophia Antipolis > 2004 route des lucioles > 06902 Sophia Antipolis > France > http://www-sop.inria.fr/members/Olivier.Clatz/ > Tel: +33 4 92 38 71 59 > Fax: +33 4 92 38 76 69 > =========================================================== > -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From stephen.aylward at kitware.com Thu Apr 15 14:34:15 2010 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Thu, 15 Apr 2010 10:34:15 -0400 Subject: [Ctk-developers] wiki page account Message-ID: The CTK wiki pages are community supported, so please get an account for them and contribute! To get an account, please send an email to: kitware-sysadmin at kitware.com and CC me. Please provide the following info: Desired Login: Real Name: Email Address: You'll then receive a reply with your password. When you first login you'll then be promoted to change you password. Thanks! s -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From pieper at bwh.harvard.edu Thu Apr 15 16:29:02 2010 From: pieper at bwh.harvard.edu (Steve Pieper) Date: Thu, 15 Apr 2010 12:29:02 -0400 Subject: [Ctk-developers] ctk organization and hackfest Message-ID: <4BC73ECE.6000209@bwh.harvard.edu> Hi ctk-developers - It's great to see the activity on the list over the last weeks and the new subscription requests. The CTK idea seems to be popular :) I just wanted to send out a few historical notes about how things are organized for now. As you can see on the wiki, we've had a several face to face meetings of, basically, people we thought would be interested. There's been a lot of enthusiasm and discussion that is reflected in the meeting minutes on the wiki. Now the project is starting to gain momentum - excellent! In May we're planning another face to face meeting and most of the organization has happened off-list, primarily because we were trying to pick a date and location that worked well for the organizers. Now that this is getting settled, we want to move the discussion of the topic and activities to the list and the wiki for greater transparency and community involvement. You'll find preliminary info about the event on the wiki: http://www.commontk.org/index.php/CTK-Hackfest-May-2010 This is essentially a 'by invitation only' event, where the organizing committee has invited a group of developers to get the CTK project started and we've believe we've reached capacity for this event. Future hackfests will be announced in advance and we hope lots of people will be interested in participating. The venue and activities at future hackfests will be determined based on the number of active participants in the project. Thanks, the hackfest organizers (Steve, Ivo & Stephen) From viceconti at tecno.ior.it Fri Apr 16 07:31:13 2010 From: viceconti at tecno.ior.it (Marco Viceconti) Date: Fri, 16 Apr 2010 09:31:13 +0200 Subject: [Ctk-developers] EU participation In-Reply-To: References: <81EA6BC8-73FB-4249-8A45-66E10EBDAF3E@tecno.ior.it> Message-ID: <68659351-8962-48F5-A341-95869775B9FD@tecno.ior.it> Agreed, it is also a good way to call bad luck upon us :-). Marco Il giorno 15 Apr 2010, alle ore 16:20, olivier clatz ha scritto: > Hello Stephen, > > I would rather like it to stay in email boxes for the moment. > It is only a proposal so far, and it would be preferable to wait for > the (hopefully positive) outcome before making it "fully" public ... > > Thanks, > > Olivier > > > > 2010/4/15 Stephen Aylward > May I add this as a news item on the ctk wiki? > > s > > On Wed, Apr 14, 2010 at 3:21 AM, olivier clatz > wrote: > > Hello Stephen, > > > > Sure ! > > please find attached the abstract + the first paragraphs I find > useful to > > understand the proposal. > > > > Olivier > > > > > > 2010/4/13 Stephen Aylward > >> > >> Congratulations on the submission! Such funding would be > outstanding for > >> CTK! > >> > >> Would a summary/short version of the proposal be helpful in > >> establishing a roadmap for or in some way advertising CTK? > >> > >> s > >> > >> On Tue, Apr 13, 2010 at 8:42 AM, Marco Viceconti > > >> wrote: > >> > Hi everybody; a couple of recents email inspired me some > comments, which > >> > I > >> > shall divide on multiple emails to keep the treads separated. > >> > > >> > First a general note: the EU arm of the CTK community in these > days has > >> > not > >> > been so active because today is the deadline for the largest > call for > >> > proposals in the VPH domain, so we are all snowed under. > >> > > >> > The good news is that thanks to the excellent work of many CTK > partners, > >> > steered by our friends at INRIAS, the eXCITe proposal has been > finalised > >> > and > >> > is now being submitted. If approved this grant will to many of > us the > >> > resources to extend CTK with some hopefully fancy additions. > >> > > >> > Cheers > >> > > >> > Marco > >> > > >> > > >> > -------------------------------------------------- > >> > MARCO VICECONTI, PhD > >> > (viceconti at tecno.ior.it) > >> > Laboratorio di Tecnologia Medica tel. > 39-051-6366865 > >> > Istituto Ortopedico Rizzoli fax. > >> > 39-051-6366863 > >> > via di Barbiano 1/10, 40136 - Bologna, Italy > >> > > >> > Tiger! Tiger! Burning bright in the forest of the night, > >> > what immortal hand or eye could frame thy fearful symmetry? > >> > -------------------------------------------------- > >> > Opinions expressed here do not necessarily reflect those of my > employer > >> > > >> > > >> > > >> > _______________________________________________ > >> > Ctk-developers mailing list > >> > Ctk-developers at commontk.org > >> > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > >> > > >> > >> > >> > >> -- > >> Stephen R. Aylward, Ph.D. > >> Director of Medical Imaging Research > >> Kitware, Inc. - North Carolina Office > >> http://www.kitware.com > >> stephen.aylward (Skype) > >> (919) 969-6990 x300 > >> _______________________________________________ > >> Ctk-developers mailing list > >> Ctk-developers at commontk.org > >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > > > > > > > -- > > =========================================================== > > Olivier Clatz > > Research Scientist > > INRIA Sophia Antipolis > > 2004 route des lucioles > > 06902 Sophia Antipolis > > France > > http://www-sop.inria.fr/members/Olivier.Clatz/ > > Tel: +33 4 92 38 71 59 > > Fax: +33 4 92 38 76 69 > > =========================================================== > > > > > > -- > Stephen R. Aylward, Ph.D. > Director of Medical Imaging Research > Kitware, Inc. - North Carolina Office > http://www.kitware.com > stephen.aylward (Skype) > (919) 969-6990 x300 > > > > -- > =========================================================== > Olivier Clatz > Research Scientist > INRIA Sophia Antipolis > 2004 route des lucioles > 06902 Sophia Antipolis > France > http://www-sop.inria.fr/members/Olivier.Clatz/ > Tel: +33 4 92 38 71 59 > Fax: +33 4 92 38 76 69 > =========================================================== -------------------------------------------------- MARCO VICECONTI, PhD (viceconti at tecno.ior.it) Laboratorio di Tecnologia Medica tel. 39-051-6366865 Istituto Ortopedico Rizzoli fax. 39-051-6366863 via di Barbiano 1/10, 40136 - Bologna, Italy Tiger! Tiger! Burning bright in the forest of the night, what immortal hand or eye could frame thy fearful symmetry? -------------------------------------------------- Opinions expressed here do not necessarily reflect those of my employer From luis.ibanez at kitware.com Mon Apr 19 17:45:18 2010 From: luis.ibanez at kitware.com (Luis Ibanez) Date: Mon, 19 Apr 2010 13:45:18 -0400 Subject: [Ctk-developers] ANNOUNCEMENT: ITK 3.18 RELEASED ! Message-ID: We are pleased to announce the release of ITK 3.18 Release notes are available at: http://www.kitware.com/news/home/browse/ITK?2010_04_15&ITK+3.18+Now+Available Source files and download instructions are available at http://itk.org/ITK/resources/software.html The list of new files can be found at: http://www.itk.org/Wiki/ITK_Release_3.18 The list of changed files can be found at: http://www.itk.org/Wiki/ITK_Release_3.18_Changed_From_Previous Please let us know if you find any problems. Thanks Luis -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.nolden at dkfz-heidelberg.de Thu Apr 22 15:21:29 2010 From: m.nolden at dkfz-heidelberg.de (Marco Nolden) Date: Thu, 22 Apr 2010 17:21:29 +0200 Subject: [Ctk-developers] CTK Dashboard: A DICOM data collection for testing ? In-Reply-To: References: Message-ID: <4BD06979.4090205@dkfz-heidelberg.de> Am 09.04.2010 16:45, schrieb Luis Ibanez: > [...] > > 2) We could host a set of realistic DICOM series in the MIDAS > server, and setup CMake to download them into testing > machines as part of the superbuild. It will be important to > include in that collection, a set of "bad" datasets that exercise > error conditions in the code. > > That is, we want to include DICOM images that are not compliant, > and we want to verify that the code rejects them accordingly. > > > That's a good idea. I've seen there is already a CTK repository on MIDAS. How can I download this from CMake? > Does DMTK has a data-testing collection that we could use ? > > and if so, it is redistributable ? > cc Michael Onken , he will be at the hackfest, too. Marco > > > Luis > > --------------------------------------------------------------------------- > On Fri, Apr 9, 2010 at 10:36 AM, Marco Nolden > wrote: > >> On 04/09/2010 04:21 PM, Luis Ibanez wrote: >> >> The dubious honor of being the WCFOD: >> >> Worst Code-Covered File of the Day >> >> >> >> >> http://my.cdash.org/viewCoverage.php?buildid=58100 >> >> >> >> >> >> Hi, >> >> 2nd on that list is ./Libs/DICOM/Core/ctkDICOMIndexer.cxx, the one I would >> take care of.. To write a meaningful test the dartclient needs access to a >> directory containing dicom images from several different patients, studies >> and series. Any ideas how we could provide that? Could the superbuild >> download and extract the sample archive before running the tests? >> >> Best >> Marco >> >> >> >> >> Does anyone cares about adopting this file ? >> >> >> Otherwise we will write tests for it today >> under the code-welfare program. >> >> >> Please let me know, >> >> >> Thanks >> >> >> Luis >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> >> -- >> ---------------------------------------------------------------------- >> Dipl.-Inform. Med. Marco Nolden >> Deutsches Krebsforschungszentrum (German Cancer Research Center) >> Div. Medical& Biological Informatics Tel: (+49) 6221-42 2325 >> Im Neuenheimer Feld 280 Fax: (+49) 6221-42 2345 >> D-69120 Heidelberg eMail: M.Nolden at dkfz.de >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> >> -- ---------------------------------------------------------------------- Dipl.-Inform. Med. Marco Nolden Deutsches Krebsforschungszentrum (German Cancer Research Center) Div. Medical& Biological Informatics Tel: (+49) 6221-42 2325 Im Neuenheimer Feld 280 Fax: (+49) 6221-42 2345 D-69120 Heidelberg eMail: M.Nolden at dkfz.de From arnaud_gelas at hms.harvard.edu Thu Apr 22 18:14:42 2010 From: arnaud_gelas at hms.harvard.edu (Arnaud GELAS) Date: Thu, 22 Apr 2010 14:14:42 -0400 Subject: [Ctk-developers] Q_DISABLE_COPY policy? Message-ID: <4BD09212.1020003@hms.harvard.edu> Hi, I just wanted to know what's the policy for constructor by copy? Do you want to use Q_DISABLE_COPY macro declared in private? Arnaud From julien.finet at kitware.com Thu Apr 22 18:28:16 2010 From: julien.finet at kitware.com (Julien Finet) Date: Thu, 22 Apr 2010 14:28:16 -0400 Subject: [Ctk-developers] Q_DISABLE_COPY policy? In-Reply-To: <4BD09212.1020003@hms.harvard.edu> References: <4BD09212.1020003@hms.harvard.edu> Message-ID: Good idea ! If we have to follow the Qt naming convention for classes that derive from Qt, then we should probably use the same keywords... Julien. On Thu, Apr 22, 2010 at 2:14 PM, Arnaud GELAS wrote: > Hi, > > I just wanted to know what's the policy for constructor by copy? > Do you want to use Q_DISABLE_COPY macro declared in private? > > Arnaud > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud_gelas at hms.harvard.edu Thu Apr 22 19:04:19 2010 From: arnaud_gelas at hms.harvard.edu (Arnaud GELAS) Date: Thu, 22 Apr 2010 15:04:19 -0400 Subject: [Ctk-developers] doxygen documentation Message-ID: <4BD09DB3.3070802@hms.harvard.edu> Hi guys, It is now possible to generate the doxygen documentation if doxygen and dot are installed on your machine. The process can be really optimized (it takes a lot of time to generate). Note that BUILD_DOCUMENTATION is turned OFF by default. Arnaud From s.zelzer at dkfz-heidelberg.de Thu Apr 22 20:26:42 2010 From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer) Date: Thu, 22 Apr 2010 22:26:42 +0200 Subject: [Ctk-developers] doxygen documentation In-Reply-To: <4BD09DB3.3070802@hms.harvard.edu> References: <4BD09DB3.3070802@hms.harvard.edu> Message-ID: <4BD0B102.5080809@dkfz-heidelberg.de> Hi, this is great! I think it would make sense to have a dartclient which generates the documentation and puts it on a public website. This would make it easier to look at the available code and study and discuss the design. I would be willing to set up a dartclient if nobody else volunteers, but we would need a public site. Any suggestions? - Sascha On 04/22/2010 09:04 PM, Arnaud GELAS wrote: > Hi guys, > > It is now possible to generate the doxygen documentation if doxygen and > dot are installed on your machine. > The process can be really optimized (it takes a lot of time to generate). > > Note that BUILD_DOCUMENTATION is turned OFF by default. > > Arnaud > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > From s.zelzer at dkfz-heidelberg.de Thu Apr 22 20:18:44 2010 From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer) Date: Thu, 22 Apr 2010 22:18:44 +0200 Subject: [Ctk-developers] Q_DISABLE_COPY policy? In-Reply-To: References: <4BD09212.1020003@hms.harvard.edu> Message-ID: <4BD0AF24.4040407@dkfz-heidelberg.de> Hi, we also had a short discussion about the Q_DECLARE_PRIVATE macro and friends. JC initially used macros and template classes adapted from Qxt (the CTK_DECLARE_PRIVATE etc. macros and the ctkPrivate template class). I haven't had a look at them in detail yet, so I don't know what their benefits are compared to the Qt "native" way. The only thing about which I am a little bit worried is that Q_DECLARE_PRIVATE, Q_D, Q_P, Q_DISABLE_COPY etc. is not public API (e.g. it is not documented in the official Qt docs). However, I think many people use them and are familiar with them. Shall we use familiar, but non-official features of Qt or roll our own macros? See for example this discussion: http://lists.trolltech.com/qt-interest/2007-09/thread00325-0.html The interesting part is: > On 14.09.07 13:49:48, Thiago Macieira wrote: > > Note of warning: Q_DECLARE_XXXX are not documented. You're not supposed > > to use them. > > Yet they are documented and advertised to be used on > http://techbase.kde.org/Policies/Library_Code_Policy#D-Pointers Let me put my KDE hat. ===> KDE developer speaking<=== I know. I wrote that potion of the policy. KDE is using those macros. KDE is also using other non-documented features and functions in Qt. ========== However, as a Trolltech developer, I have to tell you: those macros are undocumented. Trolltech can change them from one release to the next. What's more, if you have a problem with them and mail qt-bugs at xxxxxxxxxxxxx or support at xxxxxxxxxxxxx, the support engineers will tell it's internal API and they can't help you. (Though, of course, they'll be more polite than me) KDE is at its own risk doing that. And the side-effects of that have shown up recently: take a look at this change in that very same page: http://techbase.kde.org/index.php?title=Policies%2FLibrary_Code_Policy&diff=13707&oldid=13098 I removed the notice about QAtomic. Why? Because QAtomic -- an undocumented class in Qt 4.0 through 4.3 -- has disappeared in Qt 4.4. And KDE is using it. On 04/22/2010 08:28 PM, Julien Finet wrote: > Good idea ! > If we have to follow the Qt naming convention for classes that derive > from Qt, then we should probably use the same keywords... > Julien. > > On Thu, Apr 22, 2010 at 2:14 PM, Arnaud GELAS > > > wrote: > > Hi, > > I just wanted to know what's the policy for constructor by copy? > Do you want to use Q_DISABLE_COPY macro declared in private? > > Arnaud > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.finet at kitware.com Thu Apr 22 20:57:29 2010 From: julien.finet at kitware.com (Julien Finet) Date: Thu, 22 Apr 2010 16:57:29 -0400 Subject: [Ctk-developers] Q_DISABLE_COPY policy? In-Reply-To: <4BD0AF24.4040407@dkfz-heidelberg.de> References: <4BD09212.1020003@hms.harvard.edu> <4BD0AF24.4040407@dkfz-heidelberg.de> Message-ID: Q_DISABLE_COPY is documented (not internal API), so no worries :-) Concerning Q_DECLARE_PRIVATE and others, the current implementation of these macros in CTK works fine but it doesn't allow inheritance of private implementations. This is something quite handy sometimes but not necessary (inheritance of protected methods in the public class can be used instead). However we could probably come up with our own version of these Qt macros, so we won't depend on Qt private API (not only they are not public API but they also are LGPL that prevent us to use them). Whatever we decide, we won't be able to derive from Qt private implementations as they are not public API. Julien. On Thu, Apr 22, 2010 at 4:18 PM, Sascha Zelzer wrote: > Hi, > > we also had a short discussion about the Q_DECLARE_PRIVATE macro and > friends. JC initially used macros and template classes adapted from Qxt (the > CTK_DECLARE_PRIVATE etc. macros and the ctkPrivate template class). I > haven't had a look at them in detail yet, so I don't know what their > benefits are compared to the Qt "native" way. > > The only thing about which I am a little bit worried is that > Q_DECLARE_PRIVATE, Q_D, Q_P, Q_DISABLE_COPY etc. is not public API (e.g. it > is not documented in the official Qt docs). However, I think many people use > them and are familiar with them. Shall we use familiar, but non-official > features of Qt or roll our own macros? > > > See for example this discussion: > > http://lists.trolltech.com/qt-interest/2007-09/thread00325-0.html > > The interesting part is: > > > On 14.09.07 13:49:48, Thiago Macieira wrote: > > > Note of warning: Q_DECLARE_XXXX are not documented. You're not supposed > > > to use them. > > > > Yet they are documented and advertised to be used on > > http://techbase.kde.org/Policies/Library_Code_Policy#D-Pointers > > Let me put my KDE hat. > > ===> KDE developer speaking <=== > I know. I wrote that potion of the policy. > > KDE is using those macros. KDE is also using other non-documented features and > functions in Qt. > ========== > > However, as a Trolltech developer, I have to tell you: those macros are > undocumented. Trolltech can change them from one release to the next. What's > more, if you have a problem with them and mail qt-bugs at xxxxxxxxxxxxx or > support at xxxxxxxxxxxxx, the support engineers will tell it's internal API and > they can't help you. (Though, of course, they'll be more polite than me) > > KDE is at its own risk doing that. And the side-effects of that have shown up > recently: take a look at this change in that very same page:http://techbase.kde.org/index.php?title=Policies%2FLibrary_Code_Policy&diff=13707&oldid=13098 > > I removed the notice about QAtomic. Why? Because QAtomic -- an undocumented > class in Qt 4.0 through 4.3 -- has disappeared in Qt 4.4. And KDE is using > it. > > > > > > On 04/22/2010 08:28 PM, Julien Finet wrote: > > Good idea ! > If we have to follow the Qt naming convention for classes that derive from > Qt, then we should probably use the same keywords... > Julien. > > On Thu, Apr 22, 2010 at 2:14 PM, Arnaud GELAS < > arnaud_gelas at hms.harvard.edu> wrote: > >> Hi, >> >> I just wanted to know what's the policy for constructor by copy? >> Do you want to use Q_DISABLE_COPY macro declared in private? >> >> Arnaud >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> > > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.nolden at dkfz-heidelberg.de Fri Apr 23 12:35:33 2010 From: m.nolden at dkfz-heidelberg.de (Marco Nolden) Date: Fri, 23 Apr 2010 14:35:33 +0200 Subject: [Ctk-developers] CTK GitHub push policy Message-ID: <4BD19415.6060102@dkfz-heidelberg.de> Dear all, we thought it could be a good idea to discuss our push policy on github before we enter the next hackfest. At the moment a lot of things are going on, which is great, but it is not easy to follow for everyone. Since we're already using Git and a social coding platform like GitHub, we should leverage this potential and make more use of features like topic branches and pull requests. This would also allow the community to take more part in what gets into CTK, purpose of changes and things like that. What do you think? Best regards from Heidelberg, Sascha, Ivo & Marco -- ---------------------------------------------------------------------- Dipl.-Inform. Med. Marco Nolden Deutsches Krebsforschungszentrum (German Cancer Research Center) Div. Medical& Biological Informatics Tel: (+49) 6221-42 2325 Im Neuenheimer Feld 280 Fax: (+49) 6221-42 2345 D-69120 Heidelberg eMail: M.Nolden at dkfz.de From dicom at offis.de Fri Apr 23 12:54:36 2010 From: dicom at offis.de (OFFIS DICOM Team) Date: Fri, 23 Apr 2010 14:54:36 +0200 Subject: [Ctk-developers] CTK Dashboard: A DICOM data collection for testing ? In-Reply-To: <4BD06979.4090205@dkfz-heidelberg.de> References: <4BD06979.4090205@dkfz-heidelberg.de> Message-ID: <4BD1988C.5000200@offis.de> Dear all, Am 22.04.2010 17:21, schrieb Marco Nolden: > Am 09.04.2010 16:45, schrieb Luis Ibanez: >> [...] 2) We could host a set of realistic DICOM series in the MIDAS >> server, and setup CMake to download them into testing machines as part >> of the superbuild. It will be important to include in that collection, >> a set of "bad" datasets that exercise error conditions in the code. >> >> That is, we want to include DICOM images that are not compliant, and we >> want to verify that the code rejects them accordingly. >> >> > That's a good idea. I've seen there is already a CTK repository on MIDAS. > How can I download this from CMake? > >> Does DMTK has a data-testing collection that we could use ? and if so, >> it is redistributable ? Unfortunately we don't have a systematic collection of DICOM data which would fit the requirements of CTK which lies especially on working on a set of inter-related images for fancy image processing :-) Of course we have tons of "normal" images but most of them should not be publicly redistributable. Also we have an internal, artificially produced test collection of images which pushes to the limits of the DICOM image model in order to test our 2D image rendering pipeline (with stuff inside like 65535 bits assigned per color channel). We call that the horror cabinet -- I doubt it's worth sharing for CTK but I will discuss wheather this is possible before coming to the hackfest. Few more complex examples (say: inter-related images) can be found at the NEMA and are referenced from David Clunies website http://www.dclunie.com. Scroll down to "images". Besides this some other ressources are listed on our wiki: http://support.dcmtk.org/wiki/dicom/images For pure data parsing tests interesting mostly for DICOM toolkit providers:-) there is a collection of images (correct and incorrect DICOM) from Mathieu Malaterre, the main author of the GDCM DICOM toolkit. The links should be also in the Wiki. The best "nice" DICOM collections I know are indeed the published by the Osirix people. Best regards, Michael -- OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany E-Mail: dicom at offis.de, URL: http://dicom.offis.de From pieper at bwh.harvard.edu Fri Apr 23 13:06:18 2010 From: pieper at bwh.harvard.edu (Steve Pieper) Date: Fri, 23 Apr 2010 09:06:18 -0400 Subject: [Ctk-developers] CTK GitHub push policy In-Reply-To: <4BD19415.6060102@dkfz-heidelberg.de> References: <4BD19415.6060102@dkfz-heidelberg.de> Message-ID: <4BD19B4A.5050206@bwh.harvard.edu> Hello Heidelberg! Good idea - git/github offer great tools for to help us manage all the complexity. The problem (at least for me) is that the specific workflow and related commands aren't obvious. For svn, we put together this little FAQ that give the basic workflow we wanted to support: http://www.na-mic.org/Wiki/index.php/Engineering:Subversion_Repository I'd like to put together a similar one for CTK's git usage. This may be possible in advance, or maybe at the hackfest we can develop the workflow and wikify it... Does anyone have an example of what that workflow should be? -Steve On Apr/23/10 8:35 AM, Marco Nolden wrote: > Dear all, > > we thought it could be a good idea to discuss our push policy on github > before we enter the next hackfest. At the moment a lot of things are > going on, which is great, but it is not easy to follow for everyone. > Since we're already using Git and a social coding platform like GitHub, > we should leverage this potential and make more use of features like > topic branches and pull requests. This would also allow the community to > take more part in what gets into CTK, purpose of changes and things like > that. What do you think? > > Best regards from Heidelberg, > > Sascha, Ivo & Marco > From m.nolden at dkfz-heidelberg.de Fri Apr 23 14:27:32 2010 From: m.nolden at dkfz-heidelberg.de (Marco Nolden) Date: Fri, 23 Apr 2010 16:27:32 +0200 Subject: [Ctk-developers] CTK GitHub push policy In-Reply-To: <4BD19B4A.5050206@bwh.harvard.edu> References: <4BD19415.6060102@dkfz-heidelberg.de> <4BD19B4A.5050206@bwh.harvard.edu> Message-ID: <4BD1AE54.3070206@dkfz-heidelberg.de> Hi Steve, I totally agree that git's tools are very complex and we need some simple howto for that. http://help.github.com/forking/ could be a start, but there are a lot of others out there, too. I think another important question is how code gets into the master on a non-technical base. An example would be: 1. Create a branch or fork of pieper/CTK 2. (Optional) Announce its purpose/topic to ctk-developers 3a: Hack, hack, hack, 3b: Commit to your branch/fork, push it to github 3c: Share results with other people for testing / review: this can be done by mail, direct communication, whatever 3d: repeat a,b,c 4. Before pushing to the master, send mail to ctk-developers and ask people for comments 5. Push to master or send pull request, if you don't have write permissions on master The nice thing in Github is that you can follow the forks and branches you're interested in by just pressing the "Watch" button in the web interface. This is just a very raw sketch but maybe we can use it to start some discussion. -Marco Am 23.04.2010 15:06, schrieb Steve Pieper: > Hello Heidelberg! > > Good idea - git/github offer great tools for to help us manage all the > complexity. The problem (at least for me) is that the specific workflow > and related commands aren't obvious. > > For svn, we put together this little FAQ that give the basic workflow we > wanted to support: > > http://www.na-mic.org/Wiki/index.php/Engineering:Subversion_Repository > > I'd like to put together a similar one for CTK's git usage. This may be > possible in advance, or maybe at the hackfest we can develop the > workflow and wikify it... > > Does anyone have an example of what that workflow should be? > > -Steve > > > On Apr/23/10 8:35 AM, Marco Nolden wrote: > >> Dear all, >> >> we thought it could be a good idea to discuss our push policy on github >> before we enter the next hackfest. At the moment a lot of things are >> going on, which is great, but it is not easy to follow for everyone. >> Since we're already using Git and a social coding platform like GitHub, >> we should leverage this potential and make more use of features like >> topic branches and pull requests. This would also allow the community to >> take more part in what gets into CTK, purpose of changes and things like >> that. What do you think? >> >> Best regards from Heidelberg, >> >> Sascha, Ivo& Marco >> >> -- ---------------------------------------------------------------------- Dipl.-Inform. Med. Marco Nolden Deutsches Krebsforschungszentrum (German Cancer Research Center) Div. Medical& Biological Informatics Tel: (+49) 6221-42 2325 Im Neuenheimer Feld 280 Fax: (+49) 6221-42 2345 D-69120 Heidelberg eMail: M.Nolden at dkfz.de From cheng at isis.georgetown.edu Fri Apr 23 18:24:18 2010 From: cheng at isis.georgetown.edu (Patrick Cheng) Date: Fri, 23 Apr 2010 11:24:18 -0700 Subject: [Ctk-developers] CTK GitHub push policy In-Reply-To: <4BD1AE54.3070206@dkfz-heidelberg.de> References: <4BD19415.6060102@dkfz-heidelberg.de> <4BD19B4A.5050206@bwh.harvard.edu> <4BD1AE54.3070206@dkfz-heidelberg.de> Message-ID: <4BD1E5D2.5030202@isis.georgetown.edu> Hi all, Here are some tutorial information on the CMake wiki page: http://www.cmake.org/Wiki/CMake/Git Git does take sometime to get use to. I would suggest we have a small hands-on session at the start of the next hackfest. I agree that we should also have a simple and easy to follow policy to keep the main branch in good standing. Patrick On 4/23/2010 7:27 AM, Marco Nolden wrote: > Hi Steve, > > I totally agree that git's tools are very complex and we need some > simple howto for that. http://help.github.com/forking/ could be a start, > but there are a lot of others out there, too. > I think another important question is how code gets into the master on a > non-technical base. An example would be: > > 1. Create a branch or fork of pieper/CTK > 2. (Optional) Announce its purpose/topic to ctk-developers > 3a: Hack, hack, hack, > 3b: Commit to your branch/fork, push it to github > 3c: Share results with other people for testing / review: this can be > done by mail, direct communication, whatever > 3d: repeat a,b,c > 4. Before pushing to the master, send mail to ctk-developers and ask > people for comments > 5. Push to master or send pull request, if you don't have write > permissions on master > > The nice thing in Github is that you can follow the forks and branches > you're interested in by just pressing the "Watch" button in the web > interface. > > This is just a very raw sketch but maybe we can use it to start some > discussion. > > -Marco > > Am 23.04.2010 15:06, schrieb Steve Pieper: >> Hello Heidelberg! >> >> Good idea - git/github offer great tools for to help us manage all the >> complexity. The problem (at least for me) is that the specific workflow >> and related commands aren't obvious. >> >> For svn, we put together this little FAQ that give the basic workflow we >> wanted to support: >> >> http://www.na-mic.org/Wiki/index.php/Engineering:Subversion_Repository >> >> I'd like to put together a similar one for CTK's git usage. This may be >> possible in advance, or maybe at the hackfest we can develop the >> workflow and wikify it... >> >> Does anyone have an example of what that workflow should be? >> >> -Steve >> >> >> On Apr/23/10 8:35 AM, Marco Nolden wrote: >>> Dear all, >>> >>> we thought it could be a good idea to discuss our push policy on github >>> before we enter the next hackfest. At the moment a lot of things are >>> going on, which is great, but it is not easy to follow for everyone. >>> Since we're already using Git and a social coding platform like GitHub, >>> we should leverage this potential and make more use of features like >>> topic branches and pull requests. This would also allow the community to >>> take more part in what gets into CTK, purpose of changes and things like >>> that. What do you think? >>> >>> Best regards from Heidelberg, >>> >>> Sascha, Ivo& Marco >>> > > From s.zelzer at dkfz-heidelberg.de Fri Apr 23 16:06:50 2010 From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer) Date: Fri, 23 Apr 2010 18:06:50 +0200 Subject: [Ctk-developers] Q_DISABLE_COPY policy? In-Reply-To: References: <4BD09212.1020003@hms.harvard.edu> <4BD0AF24.4040407@dkfz-heidelberg.de> Message-ID: <4BD1C59A.3000901@dkfz-heidelberg.de> Hi, On 04/22/2010 10:57 PM, Julien Finet wrote: > Q_DISABLE_COPY is documented (not internal API), so no worries :-) Right, I have overlooked this one. > > Concerning Q_DECLARE_PRIVATE and others, the current implementation of > these macros in CTK works fine but it doesn't allow inheritance of > private implementations. This is something quite handy sometimes but > not necessary (inheritance of protected methods in the public class > can be used instead). I see. I already use private inheritance for some classes in the plugin-framework branch (by using Q_DECLARE_PRIVATE etc.), so we would have to work something out in order to have a common code style. Apart from the inheritance issue, the only advantage of the current CTK macros (as far as I can see) is, that they additionally take care of initializing and deleting the d-pointer (and adding a few convenient methods). I would prefer to duplicate the Qt macros and maybe extend them if needed. They seem to get the job done and a lot of people are already familiar with their usage. > However we could probably come up with our own version of these Qt > macros, so we won't depend on Qt private API (not only they are not > public API but they also are LGPL that prevent us to use them). I don't get this point. Are you saying that we cannot use macros from a LGPL library because they expand to LGPL'ed code inside our own? Then what about the "official" macro Q_DISABLE_COPY? > > Whatever we decide, we won't be able to derive from Qt private > implementations as they are not public API. > Yes, that is obvious :-) Best, Sascha From s.zelzer at dkfz-heidelberg.de Fri Apr 23 15:42:22 2010 From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer) Date: Fri, 23 Apr 2010 17:42:22 +0200 Subject: [Ctk-developers] COPYRIGHT & LICENSING In-Reply-To: <4BC5C99C.1000505@bwh.harvard.edu> References: <4BC313AA.6050408@bwh.harvard.edu> <67B4B5166383D848A0565AA7491841F93082F06AD3@RAD-VMSRVEXV2.rad.wustl.edu> <4BC5BA8D.8040702@bwh.harvard.edu> <4BC5C99C.1000505@bwh.harvard.edu> Message-ID: <4BD1BFDE.6080009@dkfz-heidelberg.de> Hi all, I want to add a few new files to the CTK plugin-framework branch and I'd like to use the "correct" copyright / licensing information. Our discussion somehow ended without a clear result and most files in the repository state that they are BSD style licensed and refer to a non-existing LICENSE.txt file. I understand that this decision is not to be treated lightly, but we need to come to a conclusion. Personally, I would vote for Apache 2.0 because of the clear statements concerning patents. Best, Sascha From julien.finet at kitware.com Fri Apr 23 16:37:44 2010 From: julien.finet at kitware.com (Julien Finet) Date: Fri, 23 Apr 2010 12:37:44 -0400 Subject: [Ctk-developers] Q_DISABLE_COPY policy? In-Reply-To: <4BD1C59A.3000901@dkfz-heidelberg.de> References: <4BD09212.1020003@hms.harvard.edu> <4BD0AF24.4040407@dkfz-heidelberg.de> <4BD1C59A.3000901@dkfz-heidelberg.de> Message-ID: My bad, I thought the macros were not accessible from the public API, but they actually are (in qglobal.h), they are "just" not documented/supported. So nothing prevent us from using them. Considering the fact that Qt doesn't seem to be very strict about backward compatibility (i.e. Qt3 to Qt4) anyway (however things could change since the acquisition by Nokia), I would then vote in favor of using these macros. But I guess we are touching here a philosophical question about CTK. Julien. On Fri, Apr 23, 2010 at 12:06 PM, Sascha Zelzer wrote: > Hi, > > > On 04/22/2010 10:57 PM, Julien Finet wrote: > >> Q_DISABLE_COPY is documented (not internal API), so no worries :-) >> > > Right, I have overlooked this one. > > > >> Concerning Q_DECLARE_PRIVATE and others, the current implementation of >> these macros in CTK works fine but it doesn't allow inheritance of private >> implementations. This is something quite handy sometimes but not necessary >> (inheritance of protected methods in the public class can be used instead). >> > > I see. I already use private inheritance for some classes in the > plugin-framework branch (by using Q_DECLARE_PRIVATE etc.), so we would have > to work something out in order to have a common code style. > > Apart from the inheritance issue, the only advantage of the current CTK > macros (as far as I can see) is, that they additionally take care of > initializing and deleting the d-pointer (and adding a few convenient > methods). I would prefer to duplicate the Qt macros and maybe extend them if > needed. They seem to get the job done and a lot of people are already > familiar with their usage. > > > However we could probably come up with our own version of these Qt macros, >> so we won't depend on Qt private API (not only they are not public API but >> they also are LGPL that prevent us to use them). >> > > I don't get this point. Are you saying that we cannot use macros from a > LGPL library because they expand to LGPL'ed code inside our own? Then what > about the "official" macro Q_DISABLE_COPY? > > > >> Whatever we decide, we won't be able to derive from Qt private >> implementations as they are not public API. >> >> > Yes, that is obvious :-) > > Best, > > Sascha > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pieper at bwh.harvard.edu Fri Apr 23 16:44:58 2010 From: pieper at bwh.harvard.edu (Steve Pieper) Date: Fri, 23 Apr 2010 12:44:58 -0400 Subject: [Ctk-developers] COPYRIGHT & LICENSING In-Reply-To: <4BD1BFDE.6080009@dkfz-heidelberg.de> References: <4BC313AA.6050408@bwh.harvard.edu> <67B4B5166383D848A0565AA7491841F93082F06AD3@RAD-VMSRVEXV2.rad.wustl.edu> <4BC5BA8D.8040702@bwh.harvard.edu> <4BC5C99C.1000505@bwh.harvard.edu> <4BD1BFDE.6080009@dkfz-heidelberg.de> Message-ID: <4BD1CE8A.7080701@bwh.harvard.edu> Hi Sascha - Yes, I think Apache 2 is the consensus for most of the code. The only outstanding question is if we will need to have some of the Qt-based in an independent LGPL library. I think that decision could be made at the hackfest when we can all focus and discuss all the issues face to face. -Steve On Apr/23/10 11:42 AM, Sascha Zelzer wrote: > Hi all, > > I want to add a few new files to the CTK plugin-framework branch and I'd > like to use the "correct" copyright / licensing information. Our > discussion somehow ended without a clear result and most files in the > repository state that they are BSD style licensed and refer to a > non-existing LICENSE.txt file. > > I understand that this decision is not to be treated lightly, but we > need to come to a conclusion. Personally, I would vote for Apache 2.0 > because of the clear statements concerning patents. > > Best, > Sascha > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers From mathieu.malaterre at gmail.com Sat Apr 24 21:38:39 2010 From: mathieu.malaterre at gmail.com (Mathieu Malaterre) Date: Sat, 24 Apr 2010 23:38:39 +0200 Subject: [Ctk-developers] CTK Dashboard: A DICOM data collection for testing ? In-Reply-To: <4BD1988C.5000200@offis.de> References: <4BD06979.4090205@dkfz-heidelberg.de> <4BD1988C.5000200@offis.de> Message-ID: Dear all, On Fri, Apr 23, 2010 at 2:54 PM, OFFIS DICOM Team wrote: > Dear all, > > Am 22.04.2010 17:21, schrieb Marco Nolden: >> >> Am 09.04.2010 16:45, schrieb Luis Ibanez: >>> >>> [...] 2) We could host a set of realistic DICOM series in the MIDAS >>> server, and setup CMake to download them into testing machines as part >>> ?of the superbuild. It will be important to include in that collection, >>> ?a set of "bad" datasets that exercise error conditions in the code. >>> >>> That is, we want to include DICOM images that are not compliant, and we >>> want to verify that the code rejects them accordingly. >>> >>> >> That's a good idea. I've seen there is already a CTK repository on MIDAS. >> How can I download this from CMake? >> >>> Does DMTK has a data-testing collection that we could use ? and if so, >>> ?it is redistributable ? > > Unfortunately we don't have a systematic collection of DICOM data which > would fit the requirements of CTK which lies especially on working on a set > of inter-related images for fancy image processing :-) > > Of course we have tons of "normal" images but most of them should not be > publicly redistributable. Also we have an internal, artificially produced > test collection of images which pushes to the limits of the DICOM image > model in order to test our 2D image rendering pipeline (with stuff inside > like 65535 bits assigned per color channel). We call that the horror cabinet > -- I doubt it's worth sharing for CTK but I will discuss wheather this is > possible before coming to the hackfest. > > Few more complex examples (say: inter-related images) can be found at the > NEMA and are referenced from David Clunies website http://www.dclunie.com. > Scroll down to "images". Besides this some other ressources are listed on > our wiki: http://support.dcmtk.org/wiki/dicom/images > > For pure data parsing tests interesting mostly for DICOM toolkit > providers:-) there is a collection of images (correct and incorrect DICOM) > from Mathieu Malaterre, the main author of the GDCM DICOM toolkit. The links > should be also in the Wiki. > > The best "nice" DICOM collections I know are indeed the published by the > Osirix people. Most of the data in gdcmData serve a very special purpose: aggressive testing of GDCM. This is similar to Michael's remark, I doubt this is of any interest to CTK's folks (maybe the j2k compressed ones ?) I would recommend dataset from nema's official website. You'll find there D. Clunie compression dataset, or instances from the new enhanced image storage class. For large series I use dataset from Osirix public dataset. Bill Lorensen's dataset can be of interest for validating the orientation widget. HTH -- Mathieu From pieper at bwh.harvard.edu Mon Apr 26 13:36:56 2010 From: pieper at bwh.harvard.edu (Steve Pieper) Date: Mon, 26 Apr 2010 09:36:56 -0400 Subject: [Ctk-developers] git workflow: Fwd: [Nipy-devel] Gitwash: a git/github workflow document for review Message-ID: <4BD596F8.3010006@bwh.harvard.edu> Hi - As a follow up on the earlier discussion about our rules of the road for git usage, the message below just came from the nipy and ipython lists. Matthew Brett has done a very nice job summarizing the ideas and commands needed for day to day development (in a generic way using the stand-in project 'gitwash'): https://cirl.berkeley.edu/mb312/gitwash/ Can we adopt the same workflow procedures for ctk? Or are there suggestions anyone would make? Best, Steve -------- Original Message -------- Subject: [Nipy-devel] Gitwash: a git/github workflow document for review Date: Sun, 25 Apr 2010 14:33:05 -0700 From: Fernando Perez Reply-To: nipy-devel at neuroimaging.scipy.org To: NIPY Developer's List Hi all, I just sent the message below to IPython-dev, and the same request for feedback/checks/complaints applies here. The ipython-dev link is: http://mail.scipy.org/pipermail/ipython-dev/2010-April/006017.html in case you want to follow any possible replies there. But we can have the discussion here, Matthew and I will integrate any feedback from either list into the document (which we ultimately intend to use as a workflow guide for both nipy and ipython). # Original message: Matthew Brett has just finished writing up a first draft of a simple, *self-contained* description of how to download, contribute to and develop a github-hosted project: - rendered version of the docs: https://cirl.berkeley.edu/mb312/gitwash/ - source repo: http://github.com/matthew-brett/gitwash We expect to use this to help the nipy project transition from bzr to git/github, and also to use it for IPython. So we'd like to submit it for further feedback here, in your minds replace the hypothetical 'gitwash' with 'IPython' and that's what we would ultimately use as our intro document for anyone wanting to work from the sources. This document should: - be easy to read in a short amount of time, without users new to git/github having to read 10 different Git tutorials (which may be very good, but may also overwhelm a newcomer with information that he or she initially doesn't know how to prioritize for relevance). - enable a newcomer to the project to download it with no complications, but to later transition to doing development with a minimal threshold. - enable someone who knows they want to develop (or existing ipython/nipy developers) to get started right away. Obviously once people are comfortable with the basics they will want (and should) read some of the excellent git/gh documentation out there. But at that point they will be in a position to digest it and benefit from it, which may not be true at the raw start. If the document fails in *any* way at this, please let us know. Any lack of clarity, any confusion, any dark spots should be pointed out, we want to make this as painless as possible for everyone involved. Cheers, f _______________________________________________ Nipy-devel mailing list Nipy-devel at neuroimaging.scipy.org http://mail.scipy.org/mailman/listinfo/nipy-devel From stephen.aylward at kitware.com Mon Apr 26 13:42:38 2010 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Mon, 26 Apr 2010 09:42:38 -0400 Subject: [Ctk-developers] git workflow: Fwd: [Nipy-devel] Gitwash: a git/github workflow document for review In-Reply-To: <4BD596F8.3010006@bwh.harvard.edu> References: <4BD596F8.3010006@bwh.harvard.edu> Message-ID: We follow this pattern on our internal projects: http://www.dinnermint.org/tutorial/dead-simple-git-workflow-for-agile-teams/ Makes it so easy that even I can do it :) s On Mon, Apr 26, 2010 at 9:36 AM, Steve Pieper wrote: > Hi - > > As a follow up on the earlier discussion about our rules of the road for git > usage, the message below just came from the nipy and ipython lists. > > Matthew Brett has done a very nice job summarizing the ideas and commands > needed for day to day development (in a generic way using the stand-in > project 'gitwash'): > > https://cirl.berkeley.edu/mb312/gitwash/ > > Can we adopt the same workflow procedures for ctk? ?Or are there suggestions > anyone would make? > > Best, > Steve > > > -------- Original Message -------- > Subject: [Nipy-devel] Gitwash: a git/github workflow document for review > Date: Sun, 25 Apr 2010 14:33:05 -0700 > From: Fernando Perez > Reply-To: nipy-devel at neuroimaging.scipy.org > To: NIPY Developer's List > > Hi all, > > I just sent the message below to IPython-dev, and the same request for > feedback/checks/complaints applies here. ?The ipython-dev link is: > > http://mail.scipy.org/pipermail/ipython-dev/2010-April/006017.html > > in case you want to follow any possible replies there. ?But we can > have the discussion here, Matthew and I will integrate any feedback > from either list into the document (which we ultimately intend to use > as a workflow guide for both nipy and ipython). > > # Original message: > > Matthew Brett has just finished writing up a first draft of a simple, > *self-contained* description of how to download, contribute to and > develop a github-hosted project: > > - rendered version of the docs: https://cirl.berkeley.edu/mb312/gitwash/ > - source repo: http://github.com/matthew-brett/gitwash > > We expect to use this to help the nipy project transition from bzr to > git/github, and also to use it for IPython. ?So we'd like to submit it > for further feedback here, in your minds replace the hypothetical > 'gitwash' with 'IPython' and that's what we would ultimately use as > our intro document for anyone wanting to work from the sources. > > This document should: > > - be easy to read in a short amount of time, without users new to > git/github having to read 10 different Git tutorials (which may be > very good, but may also overwhelm a newcomer with information that he > or she initially doesn't know how to prioritize for relevance). > > - enable a newcomer to the project to download it with no > complications, but to later transition to doing development with a > minimal threshold. > > - enable someone who knows they want to develop (or existing > ipython/nipy developers) to get started right away. > > > Obviously once people are comfortable with the basics they will want > (and should) read some of the excellent git/gh documentation out > there. ?But at that point they will be in a position to digest it and > benefit from it, which may not be true at the raw start. > > If the document fails in *any* way at this, please let us know. ?Any > lack of clarity, any confusion, any dark spots should be pointed out, > we want to make this as painless as possible for everyone involved. > > Cheers, > > f > _______________________________________________ > Nipy-devel mailing list > Nipy-devel at neuroimaging.scipy.org > http://mail.scipy.org/mailman/listinfo/nipy-devel > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From m.nolden at dkfz-heidelberg.de Mon Apr 26 15:07:19 2010 From: m.nolden at dkfz-heidelberg.de (Marco Nolden) Date: Mon, 26 Apr 2010 17:07:19 +0200 Subject: [Ctk-developers] git workflow: Fwd: [Nipy-devel] Gitwash: a git/github workflow document for review In-Reply-To: References: <4BD596F8.3010006@bwh.harvard.edu> Message-ID: <4BD5AC27.10309@dkfz-heidelberg.de> Am 26.04.2010 15:42, schrieb Stephen Aylward: > We follow this pattern on our internal projects: > http://www.dinnermint.org/tutorial/dead-simple-git-workflow-for-agile-teams/ > > These are very nice scripts. But everything is just pushed to master so it's basically a SVN like collaboration with the advantage of local commits. The "what" and "why" something gets into the mainline is still left to other communication means. Maybe my original mail subject was misleading, I thought more about starting a discussion about contribution models before we have 20+ people pushing to the mainline. > ... >> Matthew Brett has done a very nice job summarizing the ideas and commands >> needed for day to day development (in a generic way using the stand-in >> project 'gitwash'): >> >> https://cirl.berkeley.edu/mb312/gitwash/ >> >> Can we adopt the same workflow procedures for ctk? Or are there suggestions >> anyone would make? >> >> This looks very nice. I would suggest people also use branches in their repos so they could give them a name: https://cirl.berkeley.edu/mb312/gitwash/development_workflow.html#making-a-new-local-and-remote-branch Maybe this would become useful then: http://github.com/blog/39-say-hello-to-the-network-graph-visualizer Best, Marco >> Best, >> Steve >> >> >> -------- Original Message -------- >> Subject: [Nipy-devel] Gitwash: a git/github workflow document for review >> Date: Sun, 25 Apr 2010 14:33:05 -0700 >> From: Fernando Perez >> Reply-To: nipy-devel at neuroimaging.scipy.org >> To: NIPY Developer's List >> >> Hi all, >> >> I just sent the message below to IPython-dev, and the same request for >> feedback/checks/complaints applies here. The ipython-dev link is: >> >> http://mail.scipy.org/pipermail/ipython-dev/2010-April/006017.html >> >> in case you want to follow any possible replies there. But we can >> have the discussion here, Matthew and I will integrate any feedback >> from either list into the document (which we ultimately intend to use >> as a workflow guide for both nipy and ipython). >> >> # Original message: >> >> Matthew Brett has just finished writing up a first draft of a simple, >> *self-contained* description of how to download, contribute to and >> develop a github-hosted project: >> >> - rendered version of the docs: https://cirl.berkeley.edu/mb312/gitwash/ >> - source repo: http://github.com/matthew-brett/gitwash >> >> We expect to use this to help the nipy project transition from bzr to >> git/github, and also to use it for IPython. So we'd like to submit it >> for further feedback here, in your minds replace the hypothetical >> 'gitwash' with 'IPython' and that's what we would ultimately use as >> our intro document for anyone wanting to work from the sources. >> >> This document should: >> >> - be easy to read in a short amount of time, without users new to >> git/github having to read 10 different Git tutorials (which may be >> very good, but may also overwhelm a newcomer with information that he >> or she initially doesn't know how to prioritize for relevance). >> >> - enable a newcomer to the project to download it with no >> complications, but to later transition to doing development with a >> minimal threshold. >> >> - enable someone who knows they want to develop (or existing >> ipython/nipy developers) to get started right away. >> >> >> Obviously once people are comfortable with the basics they will want >> (and should) read some of the excellent git/gh documentation out >> there. But at that point they will be in a position to digest it and >> benefit from it, which may not be true at the raw start. >> >> If the document fails in *any* way at this, please let us know. Any >> lack of clarity, any confusion, any dark spots should be pointed out, >> we want to make this as painless as possible for everyone involved. >> >> Cheers, >> >> f >> _______________________________________________ >> Nipy-devel mailing list >> Nipy-devel at neuroimaging.scipy.org >> http://mail.scipy.org/mailman/listinfo/nipy-devel >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> > > > -- ---------------------------------------------------------------------- Dipl.-Inform. Med. Marco Nolden Deutsches Krebsforschungszentrum (German Cancer Research Center) Div. Medical& Biological Informatics Tel: (+49) 6221-42 2325 Im Neuenheimer Feld 280 Fax: (+49) 6221-42 2345 D-69120 Heidelberg eMail: M.Nolden at dkfz.de From bill.lorensen at gmail.com Mon Apr 26 15:12:31 2010 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 26 Apr 2010 11:12:31 -0400 Subject: [Ctk-developers] git workflow: Fwd: [Nipy-devel] Gitwash: a git/github workflow document for review In-Reply-To: <4BD5AC27.10309@dkfz-heidelberg.de> References: <4BD596F8.3010006@bwh.harvard.edu> <4BD5AC27.10309@dkfz-heidelberg.de> Message-ID: FYI: vtk has just switched to git. They are refining a workflow. This will include cmake/ctest/cdash support. Here is the current doc: http://www.vtk.org/Wiki/VTK/Git There is a section on workflow. Bill On Mon, Apr 26, 2010 at 11:07 AM, Marco Nolden wrote: > Am 26.04.2010 15:42, schrieb Stephen Aylward: >> >> We follow this pattern on our internal projects: >> >> http://www.dinnermint.org/tutorial/dead-simple-git-workflow-for-agile-teams/ >> >> > > These are very nice scripts. But everything is just pushed to master so it's > basically a SVN like collaboration with the advantage of local commits. The > "what" and "why" something gets into the mainline is still left to other > communication means. Maybe my original mail subject was misleading, I > thought more about starting a discussion about contribution models before we > have 20+ people pushing to the mainline. > >> ... >>> >>> Matthew Brett has done a very nice job summarizing the ideas and commands >>> needed for day to day development (in a generic way using the stand-in >>> project 'gitwash'): >>> >>> https://cirl.berkeley.edu/mb312/gitwash/ >>> >>> Can we adopt the same workflow procedures for ctk? ?Or are there >>> suggestions >>> anyone would make? >>> >>> > > This looks very nice. I would suggest people also use branches in their > repos so they could give them a name: > https://cirl.berkeley.edu/mb312/gitwash/development_workflow.html#making-a-new-local-and-remote-branch > > Maybe this would become useful then: > http://github.com/blog/39-say-hello-to-the-network-graph-visualizer > > Best, > Marco > > >>> Best, >>> Steve >>> >>> >>> -------- Original Message -------- >>> Subject: [Nipy-devel] Gitwash: a git/github workflow document for review >>> Date: Sun, 25 Apr 2010 14:33:05 -0700 >>> From: Fernando Perez >>> Reply-To: nipy-devel at neuroimaging.scipy.org >>> To: NIPY Developer's List >>> >>> Hi all, >>> >>> I just sent the message below to IPython-dev, and the same request for >>> feedback/checks/complaints applies here. ?The ipython-dev link is: >>> >>> http://mail.scipy.org/pipermail/ipython-dev/2010-April/006017.html >>> >>> in case you want to follow any possible replies there. ?But we can >>> have the discussion here, Matthew and I will integrate any feedback >>> from either list into the document (which we ultimately intend to use >>> as a workflow guide for both nipy and ipython). >>> >>> # Original message: >>> >>> Matthew Brett has just finished writing up a first draft of a simple, >>> *self-contained* description of how to download, contribute to and >>> develop a github-hosted project: >>> >>> - rendered version of the docs: https://cirl.berkeley.edu/mb312/gitwash/ >>> - source repo: http://github.com/matthew-brett/gitwash >>> >>> We expect to use this to help the nipy project transition from bzr to >>> git/github, and also to use it for IPython. ?So we'd like to submit it >>> for further feedback here, in your minds replace the hypothetical >>> 'gitwash' with 'IPython' and that's what we would ultimately use as >>> our intro document for anyone wanting to work from the sources. >>> >>> This document should: >>> >>> - be easy to read in a short amount of time, without users new to >>> git/github having to read 10 different Git tutorials (which may be >>> very good, but may also overwhelm a newcomer with information that he >>> or she initially doesn't know how to prioritize for relevance). >>> >>> - enable a newcomer to the project to download it with no >>> complications, but to later transition to doing development with a >>> minimal threshold. >>> >>> - enable someone who knows they want to develop (or existing >>> ipython/nipy developers) to get started right away. >>> >>> >>> Obviously once people are comfortable with the basics they will want >>> (and should) read some of the excellent git/gh documentation out >>> there. ?But at that point they will be in a position to digest it and >>> benefit from it, which may not be true at the raw start. >>> >>> If the document fails in *any* way at this, please let us know. ?Any >>> lack of clarity, any confusion, any dark spots should be pointed out, >>> we want to make this as painless as possible for everyone involved. >>> >>> Cheers, >>> >>> f >>> _______________________________________________ >>> Nipy-devel mailing list >>> Nipy-devel at neuroimaging.scipy.org >>> http://mail.scipy.org/mailman/listinfo/nipy-devel >>> _______________________________________________ >>> Ctk-developers mailing list >>> Ctk-developers at commontk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>> >>> >> >> >> > > > -- > ---------------------------------------------------------------------- > Dipl.-Inform. Med. Marco Nolden > Deutsches Krebsforschungszentrum ? ? ? (German Cancer Research Center) > Div. Medical& ?Biological Informatics ? ? ? ? ?Tel: (+49) 6221-42 2325 > Im Neuenheimer Feld 280 ? ? ? ? ? ? ? ? ? ? ? ?Fax: (+49) 6221-42 2345 > D-69120 Heidelberg ? ? ? ? ? ? ? ? ? ? ? ? ? ? eMail: M.Nolden at dkfz.de > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >