From pieper at ibility.net Mon May 7 14:33:17 2012 From: pieper at ibility.net (Steve Pieper) Date: Mon, 7 May 2012 10:33:17 -0400 Subject: [Ctk-developers] July 9-13, 2012 hackfest proposal Message-ID: Hi CTKers - It's time to start planning another hackfest! Ron Kikinis and I can host this one in Boston the week of July 9-13. If that works for enough people we'll plan to go ahead with it. If you've been to a previous hackfest and want to attend this one, please add your name to the attendee list. http://www.commontk.org/index.php/CTK-Hackfest-Jul-2012 If you haven't ever attended before but are interested attending this one, or if you want to invite someone, please contact the organizing committee and we'll discuss the options. Thanks, The Organizing Committee Ivo Wolf i.wolf at hs-mannheim.de Stephen Aylward Stephen.Aylward at Kitware.com Steve Pieper pieper at bwh.harvard.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.finet at kitware.com Thu May 10 21:23:03 2012 From: julien.finet at kitware.com (Julien Finet) Date: Thu, 10 May 2012 17:23:03 -0400 Subject: [Ctk-developers] QtTesting in master Message-ID: Hi CTKers, We have been working toward integrating the QtTesting framework [1] into CTK. Kudos to Benjamin for his hard work ! The Qt testing framework is an effort from the ParaView team which now resides in its own repository [2a][2b]. Our integration work is currently in a QtTesting branch [3] in CTK and is currently in use by Slicer (builds and package fine on all our dashboard machines) It is still work in progress and more work will happen in the coming weeks [4] However we would like to merge the branch into CTK master in order to keep working on other CTK issues for Slicer. Indeed Slicer currently points to the QtTesting head and we'd like to go back to pointing on master. Does anyone think we shouldn't merge or has any comment? Thanks, Julien. [1] http://paraview.org/Wiki/Testing_design [2a] http://paraview.org/gitweb?p=QtTesting.git [2b] https://github.com/commontk/QtTesting [3] https://github.com/commontk/CTK/tree/qttesting [4] https://github.com/commontk/CTK/issues?direction=desc&labels=Testing&page=1&sort=created&state=open -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Thu May 10 21:42:16 2012 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Thu, 10 May 2012 17:42:16 -0400 Subject: [Ctk-developers] QtTesting in master In-Reply-To: References: Message-ID: Hi Julien, That is good news. That said, before integrating into master, let's make sure building CTK with all option enabled works as expected. If CTK builds and test are passing as expected. +1 to merge Thanks Jc On Thu, May 10, 2012 at 5:23 PM, Julien Finet wrote: > Hi CTKers, > > We have been working toward integrating the QtTesting framework [1] into > CTK. Kudos to Benjamin for his hard work ! > > The Qt testing framework is an effort from the ParaView team which now > resides in its own repository [2a][2b]. > Our integration work is currently in a QtTesting branch [3] in CTK and is > currently in use by Slicer (builds and package fine on all our dashboard > machines) > > It is still work in progress and more work will happen in the coming weeks > [4] > However we would like to merge the branch into CTK master in order to keep > working on other CTK issues for Slicer. > Indeed Slicer currently points to the QtTesting head and we'd like to go > back to pointing on master. > > Does anyone think we shouldn't merge or has any comment? > > Thanks, > Julien. > > [1] http://paraview.org/Wiki/Testing_design > [2a] http://paraview.org/gitweb?p=QtTesting.git > [2b] https://github.com/commontk/QtTesting > [3] https://github.com/commontk/CTK/tree/qttesting > [4] > https://github.com/commontk/CTK/issues?direction=desc&labels=Testing&page=1&sort=created&state=open > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.zelzer at dkfz-heidelberg.de Sat May 12 11:36:11 2012 From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer) Date: Sat, 12 May 2012 13:36:11 +0200 Subject: [Ctk-developers] QtTesting in master In-Reply-To: References: Message-ID: <4FAE4B2B.50103@dkfz-heidelberg.de> Hi, +1 one from me (but see my comments below) Thanks for putting so much effort into this, it looks really good! (I just skimmed through the code changes...) There is one small issue though: In the current CTK branch [3] you seem to have some left-overs from the past were you referenced QtTesting as an external project. If I understood the changes correctly, you should probably remove this line: https://github.com/commontk/CTK/compare/master...qttesting#L11L724 and also remove that file: https://github.com/commontk/CTK/compare/master...qttesting#diff-10 Thanks for your work, Sascha On 05/10/2012 11:23 PM, Julien Finet wrote: > Hi CTKers, > > We have been working toward integrating the QtTesting framework [1] > into CTK. Kudos to Benjamin for his hard work ! > > The Qt testing framework is an effort from the ParaView team which now > resides in its own repository [2a][2b]. > Our integration work is currently in a QtTesting branch [3] in CTK and > is currently in use by Slicer (builds and package fine on all our > dashboard machines) > > It is still work in progress and more work will happen in the coming > weeks [4] > However we would like to merge the branch into CTK master in order to > keep working on other CTK issues for Slicer. > Indeed Slicer currently points to the QtTesting head and we'd like to > go back to pointing on master. > > Does anyone think we shouldn't merge or has any comment? > > Thanks, > Julien. > > [1] http://paraview.org/Wiki/Testing_design > [2a]http://paraview.org/gitweb?p=QtTesting.git > [2b] https://github.com/commontk/QtTesting > [3] https://github.com/commontk/CTK/tree/qttesting > [4] > https://github.com/commontk/CTK/issues?direction=desc&labels=Testing&page=1&sort=created&state=open > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.zelzer at dkfz-heidelberg.de Sat May 12 11:46:20 2012 From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer) Date: Sat, 12 May 2012 13:46:20 +0200 Subject: [Ctk-developers] Clang and DCMTK In-Reply-To: References: <4F9D09B0.2090603@dkfz-heidelberg.de> <4F9EC233.9070409@dkfz-heidelberg.de> Message-ID: <4FAE4D8C.4060206@dkfz-heidelberg.de> Hi, just for your information, CTK now (well, since a couple of days) uses the DCMTK 3.6.1 snapshot (22/02/2012). CTK and all its dependencies can now be build with Clang. Additionally, the custom DICOM SCU files have been removed from CTK and the CTK DICOM library now uses the SCU classes from DCMTK. Best, Sascha On 04/30/2012 07:05 PM, Julien Finet wrote: > If you didn't change from Static to Shared, then no worries, it should > be fine with Slicer. > Thanks, > j. > > On Mon, Apr 30, 2012 at 12:47 PM, Sascha Zelzer > > wrote: > > Hi J2, > > I'm not sure I fully understand your question. I did not change > the build type, DCMTK is still build as a static library (I tried > building in shared mode but then some CTK DICOM tests did not run > on Linux because the DCMTK command line tools do not contain rpath > entries and hence the shared libs were not found). > > I didn't touch anything "install" related either, everything is as > it was before concerning the DCMTK build options (except an added > DCMTK_WITH_DOXYGEN:BOOL=OFF and an explicit line for > BUILD_SHARED_LIBS:BOOL=OFF which is the default). > > Thanks for having a look, > > Sascha > > > On 04/30/2012 05:53 PM, Julien Finet wrote: >> Hi Sashcha, >> >> Thanks for taking care of it. I've not tried the "install" rules >> of DCMTK. Do you confirm it works as expected. >> For Slicer, before we can use DCMTK as shared we need to make >> sure the Slicer packaging works fine with DCMTK, especially with >> the Mac fixup :-/ >> >> J. >> >> On Sun, Apr 29, 2012 at 5:28 AM, Sascha Zelzer >> > > wrote: >> >> Hi Folks, >> >> I would look to see proper Clang support in CTK (and hence >> MITK) such that the native build tools on MacOS can be used >> (Clang is the default compiler for XCode). >> >> It looks like the only show-stopper is the DCMTK version we >> are using. This problem has already been identified on the >> the Slicer mailing list [1] and I suggest to move forward >> with Jc's option b) >> >> Update the sha1 ofgit.dcmtk.org/dcmtk.git required to build CTK >> >> >> Using the DCMTK 3.6.1 snapshot [2] would fix the DCMTK Clang >> issues and would also fix a few other issues we had in CTK >> (J2's static initialization problems and the duplicated DICOM >> SCU class). You can have a look at the necessary changes in >> CTK here: >> >> https://github.com/saschazelzer/CTK/compare/master...dcmtk-3.6.1-snapshot-compatibility >> >> Does anybody have any objections to merging the above branch >> into CTK master? >> >> Thanks, >> >> Sascha >> >> >> [1]: >> http://slicer-devel.65872.n3.nabble.com/DCMTK-clang-compiler-errors-td3811531.html >> [2]: http://support.dcmtk.org/wiki/dcmtk/news/start >> >> _______________________________________________ >> 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 ibility.net Sat May 12 12:05:44 2012 From: pieper at ibility.net (Steve Pieper) Date: Sat, 12 May 2012 08:05:44 -0400 Subject: [Ctk-developers] Clang and DCMTK In-Reply-To: <4FAE4D8C.4060206@dkfz-heidelberg.de> References: <4F9D09B0.2090603@dkfz-heidelberg.de> <4F9EC233.9070409@dkfz-heidelberg.de> <4FAE4D8C.4060206@dkfz-heidelberg.de> Message-ID: Big thanks Sascha! On Sat, May 12, 2012 at 7:46 AM, Sascha Zelzer wrote: > Hi, > > just for your information, CTK now (well, since a couple of days) uses the > DCMTK 3.6.1 snapshot (22/02/2012). > > CTK and all its dependencies can now be build with Clang. Additionally, > the custom DICOM SCU files have been removed from CTK and the CTK DICOM > library now uses the SCU classes from DCMTK. > > Best, > Sascha > > > On 04/30/2012 07:05 PM, Julien Finet wrote: > > If you didn't change from Static to Shared, then no worries, it should be > fine with Slicer. > Thanks, > j. > > On Mon, Apr 30, 2012 at 12:47 PM, Sascha Zelzer < > s.zelzer at dkfz-heidelberg.de> wrote: > >> Hi J2, >> >> I'm not sure I fully understand your question. I did not change the build >> type, DCMTK is still build as a static library (I tried building in shared >> mode but then some CTK DICOM tests did not run on Linux because the DCMTK >> command line tools do not contain rpath entries and hence the shared libs >> were not found). >> >> I didn't touch anything "install" related either, everything is as it was >> before concerning the DCMTK build options (except an added >> DCMTK_WITH_DOXYGEN:BOOL=OFF and an explicit line for >> BUILD_SHARED_LIBS:BOOL=OFF which is the default). >> >> Thanks for having a look, >> >> Sascha >> >> >> On 04/30/2012 05:53 PM, Julien Finet wrote: >> >> Hi Sashcha, >> >> Thanks for taking care of it. I've not tried the "install" rules of >> DCMTK. Do you confirm it works as expected. >> For Slicer, before we can use DCMTK as shared we need to make sure the >> Slicer packaging works fine with DCMTK, especially with the Mac fixup :-/ >> >> J. >> >> On Sun, Apr 29, 2012 at 5:28 AM, Sascha Zelzer < >> s.zelzer at dkfz-heidelberg.de> wrote: >> >>> Hi Folks, >>> >>> I would look to see proper Clang support in CTK (and hence MITK) such >>> that the native build tools on MacOS can be used (Clang is the default >>> compiler for XCode). >>> >>> It looks like the only show-stopper is the DCMTK version we are using. >>> This problem has already been identified on the the Slicer mailing list [1] >>> and I suggest to move forward with Jc's option b) >>> >>> Update the sha1 of git.dcmtk.org/dcmtk.git required to build CTK >>> >>> >>> Using the DCMTK 3.6.1 snapshot [2] would fix the DCMTK Clang issues and >>> would also fix a few other issues we had in CTK (J2's static initialization >>> problems and the duplicated DICOM SCU class). You can have a look at the >>> necessary changes in CTK here: >>> >>> >>> https://github.com/saschazelzer/CTK/compare/master...dcmtk-3.6.1-snapshot-compatibility >>> >>> Does anybody have any objections to merging the above branch into CTK >>> master? >>> >>> Thanks, >>> >>> Sascha >>> >>> >>> [1]: >>> http://slicer-devel.65872.n3.nabble.com/DCMTK-clang-compiler-errors-td3811531.html >>> [2]: http://support.dcmtk.org/wiki/dcmtk/news/start >>> >>> _______________________________________________ >>> 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 julien.finet at kitware.com Sat May 12 17:25:55 2012 From: julien.finet at kitware.com (Julien Finet) Date: Sat, 12 May 2012 13:25:55 -0400 Subject: [Ctk-developers] QtTesting in master In-Reply-To: <4FAE4B2B.50103@dkfz-heidelberg.de> References: <4FAE4B2B.50103@dkfz-heidelberg.de> Message-ID: Hi Sascha, Thanks for taking the time to review the branch. Concerning your comments, I think there is a misunderstanding. QtTesting is a library that lives in its own library. In order to work within CTK (external dependency), some CTK widgets have custom recorder and players. So if CTK_USE_QTTESTING is ON the QtTesting project is downloaded and built. Within CTK, the Libs/QtTesting directory contains CTK customization for QtTesting. We will create a wiki documentation page to further detail technicalities. Thanks, Julien. On Sat, May 12, 2012 at 7:36 AM, Sascha Zelzer wrote: > Hi, > > +1 one from me (but see my comments below) > > > Thanks for putting so much effort into this, it looks really good! (I just > skimmed through the code changes...) > > There is one small issue though: In the current CTK branch [3] you seem to > have some left-overs from the past were you referenced QtTesting as an > external project. If I understood the changes correctly, you should > probably remove this line: > > https://github.com/commontk/CTK/compare/master...qttesting#L11L724 > > and also remove that file: > > https://github.com/commontk/CTK/compare/master...qttesting#diff-10 > > > Thanks for your work, > > Sascha > > > > On 05/10/2012 11:23 PM, Julien Finet wrote: > > Hi CTKers, > > We have been working toward integrating the QtTesting framework [1] into > CTK. Kudos to Benjamin for his hard work ! > > The Qt testing framework is an effort from the ParaView team which now > resides in its own repository [2a][2b]. > Our integration work is currently in a QtTesting branch [3] in CTK and is > currently in use by Slicer (builds and package fine on all our dashboard > machines) > > It is still work in progress and more work will happen in the coming > weeks [4] > However we would like to merge the branch into CTK master in order to keep > working on other CTK issues for Slicer. > Indeed Slicer currently points to the QtTesting head and we'd like to go > back to pointing on master. > > Does anyone think we shouldn't merge or has any comment? > > Thanks, > Julien. > > [1] http://paraview.org/Wiki/Testing_design > [2a] http://paraview.org/gitweb?p=QtTesting.git > [2b] https://github.com/commontk/QtTesting > [3] https://github.com/commontk/CTK/tree/qttesting > [4] > https://github.com/commontk/CTK/issues?direction=desc&labels=Testing&page=1&sort=created&state=open > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.zelzer at dkfz-heidelberg.de Sat May 12 17:57:32 2012 From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer) Date: Sat, 12 May 2012 19:57:32 +0200 Subject: [Ctk-developers] QtTesting in master In-Reply-To: References: <4FAE4B2B.50103@dkfz-heidelberg.de> Message-ID: <4FAEA48C.9050007@dkfz-heidelberg.de> Hi, I see, that explains it. Since the names are the same, I thought the code from the external project has been moved into CTK. Maybe we could still find another name for the CTK QtTesting library? Since Qt is not only about widgets, maybe something with "widget" in it...? I also believe that we once agreed to drop the "Qt" string from library names since CTK depends on Qt anyway, but since it is an extension/customization for QtTesting, I guess it could make sense to have it in that case. We could also consider putting the library under Libs/Testing/ (instead of Libs/QtTesting), for example Libs/Testing/QtTestingWidgetExtensions. Just a couple of thoughts. Thanks, Sascha On 05/12/2012 07:25 PM, Julien Finet wrote: > Hi Sascha, > Thanks for taking the time to review the branch. > Concerning your comments, I think there is a misunderstanding. > QtTesting is a library that lives in its own library. In order to work > within CTK (external dependency), some CTK widgets have custom > recorder and players. So if CTK_USE_QTTESTING is ON the QtTesting > project is downloaded and built. Within CTK, the Libs/QtTesting > directory contains CTK customization for QtTesting. > We will create a wiki documentation page to further detail > technicalities. > Thanks, > Julien. > > On Sat, May 12, 2012 at 7:36 AM, Sascha Zelzer > > wrote: > > Hi, > > +1 one from me (but see my comments below) > > > Thanks for putting so much effort into this, it looks really good! > (I just skimmed through the code changes...) > > There is one small issue though: In the current CTK branch [3] you > seem to have some left-overs from the past were you referenced > QtTesting as an external project. If I understood the changes > correctly, you should probably remove this line: > > https://github.com/commontk/CTK/compare/master...qttesting#L11L724 > > and also remove that file: > > https://github.com/commontk/CTK/compare/master...qttesting#diff-10 > > > Thanks for your work, > > Sascha > > > > On 05/10/2012 11:23 PM, Julien Finet wrote: >> Hi CTKers, >> >> We have been working toward integrating the QtTesting framework >> [1] into CTK. Kudos to Benjamin for his hard work ! >> >> The Qt testing framework is an effort from the ParaView team >> which now resides in its own repository [2a][2b]. >> Our integration work is currently in a QtTesting branch [3] in >> CTK and is currently in use by Slicer (builds and package fine on >> all our dashboard machines) >> >> It is still work in progress and more work will happen in the >> coming weeks [4] >> However we would like to merge the branch into CTK master in >> order to keep working on other CTK issues for Slicer. >> Indeed Slicer currently points to the QtTesting head and we'd >> like to go back to pointing on master. >> >> Does anyone think we shouldn't merge or has any comment? >> >> Thanks, >> Julien. >> >> [1] http://paraview.org/Wiki/Testing_design >> [2a]http://paraview.org/gitweb?p=QtTesting.git >> [2b] https://github.com/commontk/QtTesting >> [3] https://github.com/commontk/CTK/tree/qttesting >> [4] >> https://github.com/commontk/CTK/issues?direction=desc&labels=Testing&page=1&sort=created&state=open >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Sat May 12 18:22:54 2012 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Sat, 12 May 2012 14:22:54 -0400 Subject: [Ctk-developers] QtTesting in master In-Reply-To: <4FAEA48C.9050007@dkfz-heidelberg.de> References: <4FAE4B2B.50103@dkfz-heidelberg.de> <4FAEA48C.9050007@dkfz-heidelberg.de> Message-ID: Agree on the fact we could have a better name :) .. we already spend some time brainstorming about it .. and didn't come with a better alternative. The idea with QtTesting is that it doesn't have to be related with "Testing" of CTK. It's a library that can be enabled independently of BUILD_TESTING. It provides functionality to record actions and replay them. Something like "macros". Jc On Sat, May 12, 2012 at 1:57 PM, Sascha Zelzer wrote: > Hi, > > I see, that explains it. Since the names are the same, I thought the code > from the external project has been moved into CTK. > > Maybe we could still find another name for the CTK QtTesting library? > Since Qt is not only about widgets, maybe something with "widget" in it...? > I also believe that we once agreed to drop the "Qt" string from library > names since CTK depends on Qt anyway, but since it is an > extension/customization for QtTesting, I guess it could make sense to have > it in that case. > > We could also consider putting the library under Libs/Testing/ > (instead of Libs/QtTesting), for example > Libs/Testing/QtTestingWidgetExtensions. > > Just a couple of thoughts. > > Thanks, > > Sascha > > > On 05/12/2012 07:25 PM, Julien Finet wrote: > > Hi Sascha, > Thanks for taking the time to review the branch. > Concerning your comments, I think there is a misunderstanding. QtTesting > is a library that lives in its own library. In order to work within CTK > (external dependency), some CTK widgets have custom recorder and players. > So if CTK_USE_QTTESTING is ON the QtTesting project is downloaded and > built. Within CTK, the Libs/QtTesting directory contains CTK customization > for QtTesting. > We will create a wiki documentation page to further detail technicalities. > Thanks, > Julien. > > On Sat, May 12, 2012 at 7:36 AM, Sascha Zelzer < > s.zelzer at dkfz-heidelberg.de> wrote: > >> Hi, >> >> +1 one from me (but see my comments below) >> >> >> Thanks for putting so much effort into this, it looks really good! (I >> just skimmed through the code changes...) >> >> There is one small issue though: In the current CTK branch [3] you seem >> to have some left-overs from the past were you referenced QtTesting as an >> external project. If I understood the changes correctly, you should >> probably remove this line: >> >> https://github.com/commontk/CTK/compare/master...qttesting#L11L724 >> >> and also remove that file: >> >> https://github.com/commontk/CTK/compare/master...qttesting#diff-10 >> >> >> Thanks for your work, >> >> Sascha >> >> >> >> On 05/10/2012 11:23 PM, Julien Finet wrote: >> >> Hi CTKers, >> >> We have been working toward integrating the QtTesting framework [1] >> into CTK. Kudos to Benjamin for his hard work ! >> >> The Qt testing framework is an effort from the ParaView team which now >> resides in its own repository [2a][2b]. >> Our integration work is currently in a QtTesting branch [3] in CTK and is >> currently in use by Slicer (builds and package fine on all our dashboard >> machines) >> >> It is still work in progress and more work will happen in the coming >> weeks [4] >> However we would like to merge the branch into CTK master in order to >> keep working on other CTK issues for Slicer. >> Indeed Slicer currently points to the QtTesting head and we'd like to go >> back to pointing on master. >> >> Does anyone think we shouldn't merge or has any comment? >> >> Thanks, >> Julien. >> >> [1] http://paraview.org/Wiki/Testing_design >> [2a] http://paraview.org/gitweb?p=QtTesting.git >> [2b] https://github.com/commontk/QtTesting >> [3] https://github.com/commontk/CTK/tree/qttesting >> [4] >> https://github.com/commontk/CTK/issues?direction=desc&labels=Testing&page=1&sort=created&state=open >> >> >> > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.nolden at dkfz-heidelberg.de Mon May 14 15:34:06 2012 From: m.nolden at dkfz-heidelberg.de (Marco Nolden) Date: Mon, 14 May 2012 17:34:06 +0200 Subject: [Ctk-developers] July 9-13, 2012 hackfest proposal In-Reply-To: References: Message-ID: <4FB125EE.4000406@dkfz.de> Hi Steve, hi CTKers, thank you! Sascha, Ivo and me are looking forward to come to Boston! Best, Marco On 05/07/2012 04:33 PM, Steve Pieper wrote: > Hi CTKers - > > It's time to start planning another hackfest! Ron Kikinis and I can > host this one in Boston the week of July 9-13. If that works for enough > people we'll plan to go ahead with it. > > If you've been to a previous hackfest and want to attend this one, > please add your name to the attendee list. > > http://www.commontk.org/index.php/CTK-Hackfest-Jul-2012 > > If you haven't ever attended before but are interested attending this > one, or if you want to invite someone, please contact the organizing > committee and we'll discuss the options. > > Thanks, > > The Organizing Committee > Ivo Wolf i.wolf at hs-mannheim.de > Stephen Aylward Stephen.Aylward at Kitware.com > Steve Pieper pieper at bwh.harvard.edu -- ---------------------------------------------------------------------- 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 pieper at ibility.net Thu May 24 13:12:01 2012 From: pieper at ibility.net (Steve Pieper) Date: Thu, 24 May 2012 09:12:01 -0400 Subject: [Ctk-developers] date confirmed - Re: July 9-13, 2012 hackfest proposal Message-ID: Hi again everyone - The hackfest schedule is firming up and we're looking forward to doing the CTK hacking in Boston. If you are planning or thinking about attending, let me, Ivo and Stephen know since we'll soon be making more detailed plans. http://www.commontk.org/index.php/CTK-Hackfest-Jul-2012 Best, Steve On Mon, May 14, 2012 at 11:34 AM, Marco Nolden wrote: > Hi Steve, hi CTKers, > > thank you! Sascha, Ivo and me are looking forward to come to Boston! > > Best, > > Marco > > > On 05/07/2012 04:33 PM, Steve Pieper wrote: > >> Hi CTKers - >> >> It's time to start planning another hackfest! Ron Kikinis and I can >> host this one in Boston the week of July 9-13. If that works for enough >> people we'll plan to go ahead with it. >> >> If you've been to a previous hackfest and want to attend this one, >> please add your name to the attendee list. >> >> http://www.commontk.org/index.php/CTK-Hackthisfest-Jul-2012 >> >> If you haven't ever attended before but are interested attending this >> one, or if you want to invite someone, please contact the organizing >> committee and we'll discuss the options. >> >> Thanks, >> >> The Organizing Committee >> Ivo Wolf i.wolf at hs-mannheim.de >> Stephen Aylward Stephen.Aylward at Kitware.com >> Steve Pieper pieper at bwh.harvard.edu >> > > > -- > ------------------------------**------------------------------**---------- > 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 danielle.pace at kitware.com Fri May 25 17:39:20 2012 From: danielle.pace at kitware.com (Danielle Pace) Date: Fri, 25 May 2012 13:39:20 -0400 Subject: [Ctk-developers] CTK compile errors on Ubuntu 10.04 Message-ID: Hi all, I've just re-built Slicer after updating my source directory from Slicer 4.1.0-rc3 to the current nightly, and get build errors when building CTK that are related to DICOM. I'm on 64-bit Ubuntu 10.04. The CTK source update involves going from CTK git tag cc33baed043a0552fd4c5336e8e1492ec7fe6a5c to 222971ed755c59e52625fe66ee8fb95455d5bf01. When building, I was prompted to use my root password to install dcmtk, which I did. Any suggestions? The fact that function handleFINDResponse is hidden can't be good, regardless of whether it is causing my problem. Thanks, Danielle [ 64%] Building CXX object Libs/DICOM/Core/CMakeFiles/CTKDICOMCore.dir/ctkDICOMQuery.cpp.o /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:67: error: ?QRResponse? has not been declared /home/dpace/Slicer4Trunk/Slicer4-debug/CTK-build/CMakeExternals/Install/include/dcmtk/dcmnet/scu.h:484: warning: ?virtual OFCondition DcmSCU::handleFINDResponse(T_ASC_PresentationContextID, FINDResponse*, bool&)? was hidden [-Woverloaded-virtual] /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:66: warning: by ?virtual OFCondition ctkDICOMQuerySCUPrivate::handleFINDResponse(T_ASC_PresentationContextID, int*, bool&)? [-Woverloaded-virtual] /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp: In member function ?virtual OFCondition ctkDICOMQuerySCUPrivate::handleFINDResponse(T_ASC_PresentationContextID, int*, bool&)?: /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:74: error: no matching function for call to ?ctkDICOMQuerySCUPrivate::handleFINDResponse(const T_ASC_PresentationContextID&, int*&, bool&)? /home/dpace/Slicer4Trunk/Slicer4-debug/CTK-build/CMakeExternals/Install/include/dcmtk/dcmnet/scu.h:484: note: candidates are: virtual OFCondition DcmSCU::handleFINDResponse(T_ASC_PresentationContextID, FINDResponse*, bool&) /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp: In member function ?bool ctkDICOMQuery::query(ctkDICOMDatabase&)?: /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:383: error: ?QRResponse? was not declared in this scope /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:383: error: template argument 1 is invalid /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:383: error: invalid type in declaration before ?;? token /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:401: error: no matching function for call to ?ctkDICOMQuerySCUPrivate::sendFINDRequest(Uint16&, DcmDataset*&, int*)? /home/dpace/Slicer4Trunk/Slicer4-debug/CTK-build/CMakeExternals/Install/include/dcmtk/dcmnet/scu.h:458: note: candidates are: virtual OFCondition DcmSCU::sendFINDRequest(T_ASC_PresentationContextID, DcmDataset*, FINDResponses*) /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:415: error: ?QRResponse? cannot appear in a constant-expression /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:415: error: template argument 1 is invalid /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:415: error: invalid type in declaration before ?=? token /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:415: error: request for member ?begin? in ?responses?, which is of non-class type ?int? /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:415: error: request for member ?end? in ?responses?, which is of non-class type ?int? /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:417: error: invalid type argument of ?unary *? /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:462: error: ?QRResponse? cannot appear in a constant-expression /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:462: error: template argument 1 is invalid /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:462: error: invalid type in declaration before ?;? token /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:463: error: no matching function for call to ?ctkDICOMQuerySCUPrivate::sendFINDRequest(Uint16&, DcmDataset*&, int*)? /home/dpace/Slicer4Trunk/Slicer4-debug/CTK-build/CMakeExternals/Install/include/dcmtk/dcmnet/scu.h:458: note: candidates are: virtual OFCondition DcmSCU::sendFINDRequest(T_ASC_PresentationContextID, DcmDataset*, FINDResponses*) /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:466: error: ?QRResponse? cannot appear in a constant-expression /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:466: error: template argument 1 is invalid /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:466: error: invalid type in declaration before ?=? token /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:466: error: request for member ?begin? in ?responses?, which is of non-class type ?int? /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:466: error: request for member ?end? in ?responses?, which is of non-class type ?int? /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:468: error: invalid type argument of ?unary *? make[5]: *** [Libs/DICOM/Core/CMakeFiles/CTKDICOMCore.dir/ctkDICOMQuery.cpp.o] Error 1 make[4]: *** [Libs/DICOM/Core/CMakeFiles/CTKDICOMCore.dir/all] Error 2 make[3]: *** [all] Error 2 make[2]: *** [CMakeFiles/CTK-build] Error 2 make[1]: *** [CMakeFiles/CTK-build.dir/all] Error 2 make: *** [all] Error 2 -- Danielle Pace, M.ESc. Research and Development Engineer Kitware Inc., North Carolina Office www.kitware.com 919-969-6990 X 319 -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.finet at kitware.com Fri May 25 17:46:35 2012 From: julien.finet at kitware.com (Julien Finet) Date: Fri, 25 May 2012 13:46:35 -0400 Subject: [Ctk-developers] CTK compile errors on Ubuntu 10.04 In-Reply-To: References: Message-ID: http://massmail.spl.harvard.edu/public-archives/slicer-devel/2012/008780.html j. On Fri, May 25, 2012 at 1:39 PM, Danielle Pace wrote: > Hi all, > > I've just re-built Slicer after updating my source directory from Slicer > 4.1.0-rc3 to the current nightly, and get build errors when building CTK > that are related to DICOM. I'm on 64-bit Ubuntu 10.04. > > The CTK source update involves going from CTK git tag > cc33baed043a0552fd4c5336e8e1492ec7fe6a5c > to 222971ed755c59e52625fe66ee8fb95455d5bf01. > > When building, I was prompted to use my root password to install dcmtk, > which I did. > > Any suggestions? The fact that function handleFINDResponse is hidden > can't be good, regardless of whether it is causing my problem. > > Thanks, > > Danielle > > > [ 64%] Building CXX object > Libs/DICOM/Core/CMakeFiles/CTKDICOMCore.dir/ctkDICOMQuery.cpp.o > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:67: > error: ?QRResponse? has not been declared > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK-build/CMakeExternals/Install/include/dcmtk/dcmnet/scu.h:484: > warning: ?virtual OFCondition > DcmSCU::handleFINDResponse(T_ASC_PresentationContextID, FINDResponse*, > bool&)? was hidden [-Woverloaded-virtual] > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:66: > warning: by ?virtual OFCondition > ctkDICOMQuerySCUPrivate::handleFINDResponse(T_ASC_PresentationContextID, > int*, bool&)? [-Woverloaded-virtual] > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp: > In member function ?virtual OFCondition > ctkDICOMQuerySCUPrivate::handleFINDResponse(T_ASC_PresentationContextID, > int*, bool&)?: > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:74: > error: no matching function for call to > ?ctkDICOMQuerySCUPrivate::handleFINDResponse(const > T_ASC_PresentationContextID&, int*&, bool&)? > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK-build/CMakeExternals/Install/include/dcmtk/dcmnet/scu.h:484: > note: candidates are: virtual OFCondition > DcmSCU::handleFINDResponse(T_ASC_PresentationContextID, FINDResponse*, > bool&) > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp: > In member function ?bool ctkDICOMQuery::query(ctkDICOMDatabase&)?: > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:383: > error: ?QRResponse? was not declared in this scope > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:383: > error: template argument 1 is invalid > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:383: > error: invalid type in declaration before ?;? token > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:401: > error: no matching function for call to > ?ctkDICOMQuerySCUPrivate::sendFINDRequest(Uint16&, DcmDataset*&, int*)? > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK-build/CMakeExternals/Install/include/dcmtk/dcmnet/scu.h:458: > note: candidates are: virtual OFCondition > DcmSCU::sendFINDRequest(T_ASC_PresentationContextID, DcmDataset*, > FINDResponses*) > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:415: > error: ?QRResponse? cannot appear in a constant-expression > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:415: > error: template argument 1 is invalid > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:415: > error: invalid type in declaration before ?=? token > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:415: > error: request for member ?begin? in ?responses?, which is of non-class > type ?int? > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:415: > error: request for member ?end? in ?responses?, which is of non-class type > ?int? > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:417: > error: invalid type argument of ?unary *? > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:462: > error: ?QRResponse? cannot appear in a constant-expression > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:462: > error: template argument 1 is invalid > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:462: > error: invalid type in declaration before ?;? token > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:463: > error: no matching function for call to > ?ctkDICOMQuerySCUPrivate::sendFINDRequest(Uint16&, DcmDataset*&, int*)? > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK-build/CMakeExternals/Install/include/dcmtk/dcmnet/scu.h:458: > note: candidates are: virtual OFCondition > DcmSCU::sendFINDRequest(T_ASC_PresentationContextID, DcmDataset*, > FINDResponses*) > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:466: > error: ?QRResponse? cannot appear in a constant-expression > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:466: > error: template argument 1 is invalid > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:466: > error: invalid type in declaration before ?=? token > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:466: > error: request for member ?begin? in ?responses?, which is of non-class > type ?int? > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:466: > error: request for member ?end? in ?responses?, which is of non-class type > ?int? > /home/dpace/Slicer4Trunk/Slicer4-debug/CTK/Libs/DICOM/Core/ctkDICOMQuery.cpp:468: > error: invalid type argument of ?unary *? > make[5]: *** > [Libs/DICOM/Core/CMakeFiles/CTKDICOMCore.dir/ctkDICOMQuery.cpp.o] Error 1 > make[4]: *** [Libs/DICOM/Core/CMakeFiles/CTKDICOMCore.dir/all] Error 2 > make[3]: *** [all] Error 2 > make[2]: *** [CMakeFiles/CTK-build] Error 2 > make[1]: *** [CMakeFiles/CTK-build.dir/all] Error 2 > make: *** [all] Error 2 > > > -- > Danielle Pace, M.ESc. > Research and Development Engineer > Kitware Inc., > North Carolina Office > > www.kitware.com > 919-969-6990 X 319 > > > _______________________________________________ > 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: