From zack.galbreath at kitware.com Thu Nov 3 12:09:40 2016 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Thu, 3 Nov 2016 12:09:40 -0400 Subject: [ITK-dev] open.cdash.org upgrade Friday 2016.11.04 12pm EDT Message-ID: I will update open.cdash.org tomorrow, Friday November 4th, at 12pm (noon) EDT. I'll reply to message when I begin the upgrade, and again when it completes. This update involves some changes to CDash's database layout, so I expect it may take an hour or so to complete. The site should still be accessible during this time. Assuming this upgrade doesn't reveal any major new bugs, we plan on releasing CDash v2.4 soon. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zack.galbreath at kitware.com Fri Nov 4 11:59:12 2016 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Fri, 4 Nov 2016 11:59:12 -0400 Subject: [ITK-dev] open.cdash.org upgrade Friday 2016.11.04 12pm EDT In-Reply-To: References: Message-ID: Starting the upgrade now. On Thu, Nov 3, 2016 at 12:09 PM, Zack Galbreath wrote: > I will update open.cdash.org tomorrow, Friday November 4th, at 12pm > (noon) EDT. I'll reply to message when I begin the upgrade, and again when > it completes. > > This update involves some changes to CDash's database layout, so I expect > it may take an hour or so to complete. The site should still be accessible > during this time. > > Assuming this upgrade doesn't reveal any major new bugs, we plan on > releasing CDash v2.4 soon. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zack.galbreath at kitware.com Fri Nov 4 12:27:07 2016 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Fri, 4 Nov 2016 12:27:07 -0400 Subject: [ITK-dev] open.cdash.org upgrade Friday 2016.11.04 12pm EDT In-Reply-To: References: Message-ID: The upgrade is complete. The only issue I've noticed is that old coverage files are not being displayed properly. Newly submitted ones are, though, so I suppose this problem will resolve itself tomorrow. Please do not hesitate to contact me if you notice anything else that seems to be amiss. On Fri, Nov 4, 2016 at 11:59 AM, Zack Galbreath wrote: > Starting the upgrade now. > > On Thu, Nov 3, 2016 at 12:09 PM, Zack Galbreath < > zack.galbreath at kitware.com> wrote: > >> I will update open.cdash.org tomorrow, Friday November 4th, at 12pm >> (noon) EDT. I'll reply to message when I begin the upgrade, and again when >> it completes. >> >> This update involves some changes to CDash's database layout, so I expect >> it may take an hour or so to complete. The site should still be accessible >> during this time. >> >> Assuming this upgrade doesn't reveal any major new bugs, we plan on >> releasing CDash v2.4 soon. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad at lowekamp.net Fri Nov 4 21:02:30 2016 From: brad at lowekamp.net (Bradley Lowekamp) Date: Fri, 4 Nov 2016 21:02:30 -0400 Subject: [ITK-dev] open.cdash.org upgrade Friday 2016.11.04 12pm EDT In-Reply-To: References: Message-ID: <61F71A78-0415-4827-AAE7-D331F5FF09FC@mail.nih.gov> Thanks for the upgrade! All seems ok for my usage today. I also appreciate the separated graphs with the correct axis label. Brad > On Nov 4, 2016, at 12:27 PM, Zack Galbreath wrote: > > The upgrade is complete. > > The only issue I've noticed is that old coverage files are not being displayed properly. Newly submitted ones are, though, so I suppose this problem will resolve itself tomorrow. > > Please do not hesitate to contact me if you notice anything else that seems to be amiss. > > > >> On Fri, Nov 4, 2016 at 11:59 AM, Zack Galbreath wrote: >> Starting the upgrade now. >> >>> On Thu, Nov 3, 2016 at 12:09 PM, Zack Galbreath wrote: >>> I will update open.cdash.org tomorrow, Friday November 4th, at 12pm (noon) EDT. I'll reply to message when I begin the upgrade, and again when it completes. >>> >>> This update involves some changes to CDash's database layout, so I expect it may take an hour or so to complete. The site should still be accessible during this time. >>> >>> Assuming this upgrade doesn't reveal any major new bugs, we plan on releasing CDash v2.4 soon. >> > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Kitware offers ITK Training Courses, for more information visit: > http://kitware.com/products/protraining.php > > Please keep messages on-topic and check the ITK FAQ at: > http://www.itk.org/Wiki/ITK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/insight-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhlegarreta at vicomtech.org Mon Nov 7 02:02:55 2016 From: jhlegarreta at vicomtech.org (Jon Haitz Legarreta) Date: Mon, 7 Nov 2016 08:02:55 +0100 Subject: [ITK-dev] open.cdash.org upgrade Friday 2016.11.04 12pm EDT In-Reply-To: <61F71A78-0415-4827-AAE7-D331F5FF09FC@mail.nih.gov> References: <61F71A78-0415-4827-AAE7-D331F5FF09FC@mail.nih.gov> Message-ID: Hi, thanks for the upgrade Zach. Coverage reports seem not to be working yet. Although the coverage figures seem to be computed/updated, the file reports do not show which lines are being exercised, and just show an empty line. Thanks, JON HAITZ On 5 November 2016 at 02:02, Bradley Lowekamp wrote: > Thanks for the upgrade! All seems ok for my usage today. I also > appreciate the separated graphs with the correct axis label. > > Brad > > On Nov 4, 2016, at 12:27 PM, Zack Galbreath > wrote: > > The upgrade is complete. > > The only issue I've noticed is that old coverage files are not being > displayed properly. Newly submitted ones are, though, so I suppose this > problem will resolve itself tomorrow. > > Please do not hesitate to contact me if you notice anything else that > seems to be amiss. > > > > On Fri, Nov 4, 2016 at 11:59 AM, Zack Galbreath < > zack.galbreath at kitware.com> wrote: > >> Starting the upgrade now. >> >> On Thu, Nov 3, 2016 at 12:09 PM, Zack Galbreath < >> zack.galbreath at kitware.com> wrote: >> >>> I will update open.cdash.org tomorrow, Friday November 4th, at 12pm >>> (noon) EDT. I'll reply to message when I begin the upgrade, and again when >>> it completes. >>> >>> This update involves some changes to CDash's database layout, so I >>> expect it may take an hour or so to complete. The site should still be >>> accessible during this time. >>> >>> Assuming this upgrade doesn't reveal any major new bugs, we plan on >>> releasing CDash v2.4 soon. >>> >> >> > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Kitware offers ITK Training Courses, for more information visit: > http://kitware.com/products/protraining.php > > Please keep messages on-topic and check the ITK FAQ at: > http://www.itk.org/Wiki/ITK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/insight-developers > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Kitware offers ITK Training Courses, for more information visit: > http://kitware.com/products/protraining.php > > Please keep messages on-topic and check the ITK FAQ at: > http://www.itk.org/Wiki/ITK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/insight-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zack.galbreath at kitware.com Mon Nov 7 09:30:06 2016 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Mon, 7 Nov 2016 09:30:06 -0500 Subject: [ITK-dev] open.cdash.org upgrade Friday 2016.11.04 12pm EDT In-Reply-To: References: <61F71A78-0415-4827-AAE7-D331F5FF09FC@mail.nih.gov> Message-ID: Hi Jon, Thanks for noticing that this issue was still not resolved. I just purged the cache of coverage files on open.cdash.org, so line-by-line coverage should be properly displayed once this data is resubmitted tonight. I'll double check this tomorrow morning. On Mon, Nov 7, 2016 at 2:02 AM, Jon Haitz Legarreta < jhlegarreta at vicomtech.org> wrote: > Hi, > thanks for the upgrade Zach. > > Coverage reports seem not to be working yet. Although the coverage figures > seem to be computed/updated, the file reports do not show which lines are > being exercised, and just show an empty line. > > Thanks, > JON HAITZ > > > > > On 5 November 2016 at 02:02, Bradley Lowekamp wrote: > >> Thanks for the upgrade! All seems ok for my usage today. I also >> appreciate the separated graphs with the correct axis label. >> >> Brad >> >> On Nov 4, 2016, at 12:27 PM, Zack Galbreath >> wrote: >> >> The upgrade is complete. >> >> The only issue I've noticed is that old coverage files are not being >> displayed properly. Newly submitted ones are, though, so I suppose this >> problem will resolve itself tomorrow. >> >> Please do not hesitate to contact me if you notice anything else that >> seems to be amiss. >> >> >> >> On Fri, Nov 4, 2016 at 11:59 AM, Zack Galbreath < >> zack.galbreath at kitware.com> wrote: >> >>> Starting the upgrade now. >>> >>> On Thu, Nov 3, 2016 at 12:09 PM, Zack Galbreath < >>> zack.galbreath at kitware.com> wrote: >>> >>>> I will update open.cdash.org tomorrow, Friday November 4th, at 12pm >>>> (noon) EDT. I'll reply to message when I begin the upgrade, and again when >>>> it completes. >>>> >>>> This update involves some changes to CDash's database layout, so I >>>> expect it may take an hour or so to complete. The site should still be >>>> accessible during this time. >>>> >>>> Assuming this upgrade doesn't reveal any major new bugs, we plan on >>>> releasing CDash v2.4 soon. >>>> >>> >>> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Kitware offers ITK Training Courses, for more information visit: >> http://kitware.com/products/protraining.php >> >> Please keep messages on-topic and check the ITK FAQ at: >> http://www.itk.org/Wiki/ITK_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/insight-developers >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Kitware offers ITK Training Courses, for more information visit: >> http://kitware.com/products/protraining.php >> >> Please keep messages on-topic and check the ITK FAQ at: >> http://www.itk.org/Wiki/ITK_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/insight-developers >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zack.galbreath at kitware.com Mon Nov 7 09:34:44 2016 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Mon, 7 Nov 2016 09:34:44 -0500 Subject: [ITK-dev] open.cdash.org upgrade Friday 2016.11.04 12pm EDT In-Reply-To: <61F71A78-0415-4827-AAE7-D331F5FF09FC@mail.nih.gov> References: <61F71A78-0415-4827-AAE7-D331F5FF09FC@mail.nih.gov> Message-ID: On Fri, Nov 4, 2016 at 9:02 PM, Bradley Lowekamp wrote: > Thanks for the upgrade! All seems ok for my usage today. I also > appreciate the separated graphs with the correct axis label. > Glad to you like it! Off the top of my head, another improvement we made is to the "Test Overview" page. Instead of simply showing an alphabetical list of all tests that failed, it now shows you how frequently each test failed or timed out. This is more useful for tracking down unreliable tests. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Mon Nov 7 10:44:58 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 7 Nov 2016 10:44:58 -0500 Subject: [ITK-dev] [vtk-developers] open.cdash.org upgrade Friday 2016.11.04 12pm EDT In-Reply-To: References: <61F71A78-0415-4827-AAE7-D331F5FF09FC@mail.nih.gov> Message-ID: Seems like compile errors are not being listed... https://open.cdash.org/viewBuildError.php?buildid=4630324 On Mon, Nov 7, 2016 at 9:34 AM, Zack Galbreath wrote: > On Fri, Nov 4, 2016 at 9:02 PM, Bradley Lowekamp wrote: >> >> Thanks for the upgrade! All seems ok for my usage today. I also >> appreciate the separated graphs with the correct axis label. > > > Glad to you like it! > > Off the top of my head, another improvement we made is to the "Test > Overview" page. Instead of simply showing an alphabetical list of all tests > that failed, it now shows you how frequently each test failed or timed out. > This is more useful for tracking down unreliable tests. > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Unpaid intern in BillsBasement at noware dot com From zack.galbreath at kitware.com Mon Nov 7 11:10:26 2016 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Mon, 7 Nov 2016 11:10:26 -0500 Subject: [ITK-dev] [vtk-developers] open.cdash.org upgrade Friday 2016.11.04 12pm EDT In-Reply-To: References: <61F71A78-0415-4827-AAE7-D331F5FF09FC@mail.nih.gov> Message-ID: On Mon, Nov 7, 2016 at 10:44 AM, Bill Lorensen wrote: > Seems like compile errors are not being listed... > https://open.cdash.org/viewBuildError.php?buildid=4630324 Looks okay to me. Might be a stale cache on your end? Let me know if I'm missing something. ? > > On Mon, Nov 7, 2016 at 9:34 AM, Zack Galbreath > wrote: > > On Fri, Nov 4, 2016 at 9:02 PM, Bradley Lowekamp > wrote: > >> > >> Thanks for the upgrade! All seems ok for my usage today. I also > >> appreciate the separated graphs with the correct axis label. > > > > > > Glad to you like it! > > > > Off the top of my head, another improvement we made is to the "Test > > Overview" page. Instead of simply showing an alphabetical list of all > tests > > that failed, it now shows you how frequently each test failed or timed > out. > > This is more useful for tracking down unreliable tests. > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: http://markmail.org/search/?q= > vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > > > -- > Unpaid intern in BillsBasement at noware dot com > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: build_errors.png Type: image/png Size: 470063 bytes Desc: not available URL: From bill.lorensen at gmail.com Mon Nov 7 11:29:18 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 7 Nov 2016 11:29:18 -0500 Subject: [ITK-dev] [vtk-developers] open.cdash.org upgrade Friday 2016.11.04 12pm EDT In-Reply-To: References: <61F71A78-0415-4827-AAE7-D331F5FF09FC@mail.nih.gov> Message-ID: On my ubuntu system, works on firefox, not on Chrome On Mon, Nov 7, 2016 at 11:10 AM, Zack Galbreath wrote: > On Mon, Nov 7, 2016 at 10:44 AM, Bill Lorensen > wrote: > >> Seems like compile errors are not being listed... >> https://open.cdash.org/viewBuildError.php?buildid=4630324 > > > Looks okay to me. Might be a stale cache on your end? Let me know if I'm > missing something. > > > > ? > > > > > > > >> >> On Mon, Nov 7, 2016 at 9:34 AM, Zack Galbreath >> wrote: >> > On Fri, Nov 4, 2016 at 9:02 PM, Bradley Lowekamp >> wrote: >> >> >> >> Thanks for the upgrade! All seems ok for my usage today. I also >> >> appreciate the separated graphs with the correct axis label. >> > >> > >> > Glad to you like it! >> > >> > Off the top of my head, another improvement we made is to the "Test >> > Overview" page. Instead of simply showing an alphabetical list of all >> tests >> > that failed, it now shows you how frequently each test failed or timed >> out. >> > This is more useful for tracking down unreliable tests. >> > >> > _______________________________________________ >> > Powered by www.kitware.com >> > >> > Visit other Kitware open-source projects at >> > http://www.kitware.com/opensource/opensource.html >> > >> > Search the list archives at: http://markmail.org/search/?q= >> vtk-developers >> > >> > Follow this link to subscribe/unsubscribe: >> > http://public.kitware.com/mailman/listinfo/vtk-developers >> > >> > >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com >> > > -- Unpaid intern in BillsBasement at noware dot com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: build_errors.png Type: image/png Size: 470063 bytes Desc: not available URL: From matt.mccormick at kitware.com Mon Nov 7 11:37:28 2016 From: matt.mccormick at kitware.com (Matt McCormick) Date: Mon, 7 Nov 2016 11:37:28 -0500 Subject: [ITK-dev] ITK Architectural Patterns & Quality Attributes for Research In-Reply-To: References: Message-ID: Hello Michael et al, Thank you for your interest in ITK. Some follow-up on the patterns and attributes with pointers to additional information and attributes can be found below. On Sat, Oct 15, 2016 at 4:39 PM, Michael Skeen wrote: > Hello ITK Community, > > > I am part of an undergraduate research group focusing on software > architecture patterns and quality attributes at Utah Valley University. We > recently analyzed the work published on ITK in the Architecture of Open > Source Applications (AOSA) and referenced it in a paper we presented at the > 13th Working IEEE/IFIP Conference on Software Architecture (WICSA), as > attached. As a part of our continuing research we wish to validate our > architectural analysis for ITK with the current developers. > > > We would like to know if we are missing any patterns or quality attributes > that may have been included in ITK, or if there are any we listed that > aren?t used. Any additional comment on these topics you might have would > also, of course, be welcome. > > > We believe we found the following software architectural patterns in this > application: > > > Pattern Name | Is This Found in the Architecture? (yes / no / don't know) | > Comments (optional) > > Pipes & Filters Yes. More information can be found in the Data Processing Pipeline section of the ITK Software Guide: https://itk.org/ITKSoftwareGuide/html/Book1/ITKSoftwareGuide-Book1ch3.html#x34-390003.5 > Plugin Yes. See, for example the ImageIO system: https://itk.org/Doxygen/html/classitk_1_1ImageIOBase.html > Other? Yes. See, for example the Architecture section of the ITK Software Guide: https://itk.org/ITKSoftwareGuide/html/Book1/ITKSoftwareGuide-Book1pa2.html#x33-26000II > We also identified the following quality attributes: > > > Attribute Name | Is This Found in the Architecture? | Comments (optional) > > Usability Yes. We work hard on developer usability. See, e.g. https://itk.org/ITK/help/documentation.html > Extensibility Yes. We recently developed an extensible module system for the toolkit. See https://blog.kitware.com/advance-itk-with-modules/ > Flexibility Yes. For example, see the image registration framework, which can be adapted to new problems: http://journal.frontiersin.org/article/10.3389/fninf.2014.00044/full > Maintainability > Testability Yes and yes. For more information, see: http://journal.frontiersin.org/article/10.3389/fninf.2014.00013/full The additional attributes also apply: Scalability. We support image processing through streaming. Performance. ITK is a high performance toolkit that makes an effort to perform well on multi-core, many-core, and GPGPU systems. See, for example: http://www.insight-journal.org/browse/publication/972 Portability. ITK is portable across many platforms, including x86_64 Linux, Windows, Mac OSX, but also ARM architectures, Android, POWER8, and JavaScript. See https://blog.kitware.com/compile-cc-into-javascript-with-emscripten-and-docker/ Modularity. Yes, since ITK version 4, ITK is organized into Groups and Modules. Cost. Legality. ITK has a strong focus on collaborative, open source development to sustainably create one of the most powerful medical image analysis libraries in the world. There is also an explicit attention to legality: ITKv4 is licensed as Apache 2.0, and algorithms with software patents are excluded from the library. Thanks, Matt > For your convenience, we have a complete list below of the patterns and > quality attributes we referred to when conducting our research. To clarify, > we are specifically studying architectural patterns, rather than design > patterns such as the GoF patterns. > > > Architectural Patterns Considered > > > Quality Attributes Considered > > Active Repository > > > Scalability > > Batch > > > Usability > > Blackboard > > > Extensibility > > Broker > > > Performance > > Client Server > > > Portability > > Event System > > > Flexibility > > Explicit Invocation > > > Reliability > > Implicit Invocation > > > Maintainability > > Indirection Layer > > > Security > > Interceptor > > > Testability > > Interpreter > > > Capacity > > Layers > > > Cost > > Master and Commander > > > Legality > > Microkernel > > > Modularity > > Model View Controller > > > Robustness > > Peer to Peer > > > > Pipes and Filters > > > > Plugin > > > > Presentation Abstraction Control > > > > Publish Subscribe > > > > Reflection > > > > Rule-Based System > > > > Shared Repository > > > > Simple Repository > > > > State Based > > > > Virtual Machine > > > > > Please respond by October 25th, if possible. > > Thank you for considering our request, and for your continued work on ITK. > > > Sincerely, > > > Michael Skeen, with > > Erich Gubler, > > Danielle Skinner, > > Brandon Leishman, > > Neil Harrison, Ph.D. (advisor) > > > Reference: Neil B. Harrison, Erich Gubler, Danielle Skinner, "Software > Architecture Pattern Morphology in Open-Source Systems",WICSA, 2016, 2016 > 13th Working IEEE/IFIP Conference on Software Architecture (WICSA), 2016 > 13th Working IEEE/IFIP Conference on Software Architecture (WICSA) 2016, pp. > 91-98, doi:10.1109/WICSA.2016.8 > > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Kitware offers ITK Training Courses, for more information visit: > http://kitware.com/products/protraining.php > > Please keep messages on-topic and check the ITK FAQ at: > http://www.itk.org/Wiki/ITK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/insight-developers > From zack.galbreath at kitware.com Tue Nov 8 09:02:54 2016 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Tue, 8 Nov 2016 09:02:54 -0500 Subject: [ITK-dev] open.cdash.org upgrade Friday 2016.11.04 12pm EDT In-Reply-To: References: <61F71A78-0415-4827-AAE7-D331F5FF09FC@mail.nih.gov> Message-ID: On Mon, Nov 7, 2016 at 9:30 AM, Zack Galbreath wrote: > I just purged the cache of coverage files on open.cdash.org, so > line-by-line coverage should be properly displayed once this data is > resubmitted tonight. I'll double check this tomorrow morning. > It looks like this is fixed now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmskeen at gmail.com Tue Nov 8 10:38:13 2016 From: mmskeen at gmail.com (Michael Skeen) Date: Tue, 8 Nov 2016 08:38:13 -0700 Subject: [ITK-dev] ITK Architectural Patterns & Quality Attributes for Research In-Reply-To: References: Message-ID: Matt, Thank you for the excellent and thorough response! We will use this information in our research. Michael On Mon, Nov 7, 2016 at 9:37 AM, Matt McCormick wrote: > Hello Michael et al, > > Thank you for your interest in ITK. Some follow-up on the patterns and > attributes with pointers to additional information and attributes can > be found below. > > > On Sat, Oct 15, 2016 at 4:39 PM, Michael Skeen wrote: > > Hello ITK Community, > > > > > > I am part of an undergraduate research group focusing on software > > architecture patterns and quality attributes at Utah Valley University. > We > > recently analyzed the work published on ITK in the Architecture of Open > > Source Applications (AOSA) and referenced it in a paper we presented at > the > > 13th Working IEEE/IFIP Conference on Software Architecture (WICSA), as > > attached. As a part of our continuing research we wish to validate our > > architectural analysis for ITK with the current developers. > > > > > > We would like to know if we are missing any patterns or quality > attributes > > that may have been included in ITK, or if there are any we listed that > > aren?t used. Any additional comment on these topics you might have would > > also, of course, be welcome. > > > > > > We believe we found the following software architectural patterns in this > > application: > > > > > > Pattern Name | Is This Found in the Architecture? (yes / no / don't > know) | > > Comments (optional) > > > > Pipes & Filters > > Yes. More information can be found in the Data Processing Pipeline > section of the ITK Software Guide: > > https://itk.org/ITKSoftwareGuide/html/Book1/ITKSoftwareGuide-Book1ch3. > html#x34-390003.5 > > > > > Plugin > > Yes. See, for example the ImageIO system: > > https://itk.org/Doxygen/html/classitk_1_1ImageIOBase.html > > > > > Other? > > Yes. See, for example the Architecture section of the ITK Software Guide: > > https://itk.org/ITKSoftwareGuide/html/Book1/ITKSoftwareGuide-Book1pa2. > html#x33-26000II > > > > > We also identified the following quality attributes: > > > > > > Attribute Name | Is This Found in the Architecture? | Comments (optional) > > > > Usability > > Yes. We work hard on developer usability. See, e.g. > > https://itk.org/ITK/help/documentation.html > > > > Extensibility > > Yes. We recently developed an extensible module system for the toolkit. > See > > https://blog.kitware.com/advance-itk-with-modules/ > > > > Flexibility > > Yes. For example, see the image registration framework, which can be > adapted to new problems: > > http://journal.frontiersin.org/article/10.3389/fninf.2014.00044/full > > > > Maintainability > > Testability > > Yes and yes. For more information, see: > > http://journal.frontiersin.org/article/10.3389/fninf.2014.00013/full > > > > The additional attributes also apply: > > > Scalability. We support image processing through streaming. > > > Performance. ITK is a high performance toolkit that makes an effort to > perform well on multi-core, many-core, and GPGPU systems. See, for > example: > > http://www.insight-journal.org/browse/publication/972 > > > Portability. ITK is portable across many platforms, including x86_64 > Linux, Windows, Mac OSX, but also ARM architectures, Android, POWER8, > and JavaScript. See > > https://blog.kitware.com/compile-cc-into-javascript- > with-emscripten-and-docker/ > > > Modularity. Yes, since ITK version 4, ITK is organized into Groups and > Modules. > > > Cost. Legality. ITK has a strong focus on collaborative, open source > development to sustainably create one of the most powerful medical > image analysis libraries in the world. There is also an explicit > attention to legality: ITKv4 is licensed as Apache 2.0, and algorithms > with software patents are excluded from the library. > > > Thanks, > Matt > > > > > > For your convenience, we have a complete list below of the patterns and > > quality attributes we referred to when conducting our research. To > clarify, > > we are specifically studying architectural patterns, rather than design > > patterns such as the GoF patterns. > > > > > > Architectural Patterns Considered > > > > > > Quality Attributes Considered > > > > Active Repository > > > > > > Scalability > > > > Batch > > > > > > Usability > > > > Blackboard > > > > > > Extensibility > > > > Broker > > > > > > Performance > > > > Client Server > > > > > > Portability > > > > Event System > > > > > > Flexibility > > > > Explicit Invocation > > > > > > Reliability > > > > Implicit Invocation > > > > > > Maintainability > > > > Indirection Layer > > > > > > Security > > > > Interceptor > > > > > > Testability > > > > Interpreter > > > > > > Capacity > > > > Layers > > > > > > Cost > > > > Master and Commander > > > > > > Legality > > > > Microkernel > > > > > > Modularity > > > > Model View Controller > > > > > > Robustness > > > > Peer to Peer > > > > > > > > Pipes and Filters > > > > > > > > Plugin > > > > > > > > Presentation Abstraction Control > > > > > > > > Publish Subscribe > > > > > > > > Reflection > > > > > > > > Rule-Based System > > > > > > > > Shared Repository > > > > > > > > Simple Repository > > > > > > > > State Based > > > > > > > > Virtual Machine > > > > > > > > > > Please respond by October 25th, if possible. > > > > Thank you for considering our request, and for your continued work on > ITK. > > > > > > Sincerely, > > > > > > Michael Skeen, with > > > > Erich Gubler, > > > > Danielle Skinner, > > > > Brandon Leishman, > > > > Neil Harrison, Ph.D. (advisor) > > > > > > Reference: Neil B. Harrison, Erich Gubler, Danielle Skinner, "Software > > Architecture Pattern Morphology in Open-Source Systems",WICSA, 2016, 2016 > > 13th Working IEEE/IFIP Conference on Software Architecture (WICSA), 2016 > > 13th Working IEEE/IFIP Conference on Software Architecture (WICSA) 2016, > pp. > > 91-98, doi:10.1109/WICSA.2016.8 > > > > > > > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Kitware offers ITK Training Courses, for more information visit: > > http://kitware.com/products/protraining.php > > > > Please keep messages on-topic and check the ITK FAQ at: > > http://www.itk.org/Wiki/ITK_FAQ > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/insight-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.mccormick at kitware.com Tue Nov 8 17:01:52 2016 From: matt.mccormick at kitware.com (Matt McCormick) Date: Tue, 8 Nov 2016 17:01:52 -0500 Subject: [ITK-dev] Workaround for dynamic_cast on Mac OSX Message-ID: Hi folks, As we have wrestled with in Slicer, along with other applications where ITK is used in multiple shared libraries, dynamic_cast can fail on Mac OSX. I summarized the cause of the problem and steps for the proposed solution here: https://issues.itk.org/jira/browse/ITK-3490 Feedback is welcome. The effort is targeted for the ITK 4.11.0 release. Thanks, Matt From marcus.hanwell at kitware.com Thu Nov 10 14:11:59 2016 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Thu, 10 Nov 2016 14:11:59 -0500 Subject: [ITK-dev] Workaround for dynamic_cast on Mac OSX In-Reply-To: References: Message-ID: On Tue, Nov 8, 2016 at 5:01 PM, Matt McCormick wrote: > Hi folks, > > As we have wrestled with in Slicer, along with other applications > where ITK is used in multiple shared libraries, dynamic_cast can fail > on Mac OSX. > > I summarized the cause of the problem and steps for the proposed solution here: > > https://issues.itk.org/jira/browse/ITK-3490 > > Feedback is welcome. The effort is targeted for the ITK 4.11.0 release. > >From the issue it is not clear to me why you can't fix the symbol visibility issues, or which of these cases it causing the breakage. Reading the linked blog post it seems like Apple/Clang is doing the right thing, and C++ libraries must be careful to use consistent symbol visibility. I would be interested in further details on which case or cases are causing dynamic_cast to fail, and why using consistent symbol visibility in the interfaces is not feasible/possible. Thanks, Marcus From hans-johnson at uiowa.edu Thu Nov 10 15:21:42 2016 From: hans-johnson at uiowa.edu (Johnson, Hans J) Date: Thu, 10 Nov 2016 20:21:42 +0000 Subject: [ITK-dev] Workaround for dynamic_cast on Mac OSX In-Reply-To: References: Message-ID: <2702DADA-25CD-42D6-9CCE-BA306F400B1C@uiowa.edu> I agree with Marcus. At least until it is very clear that not using dynamic_cast is the only solution to a broken compiler, I am very weary of ?doing what works today?. Hans -- On 11/10/16, 1:11 PM, "Insight-developers on behalf of Marcus D. Hanwell" wrote: On Tue, Nov 8, 2016 at 5:01 PM, Matt McCormick wrote: > Hi folks, > > As we have wrestled with in Slicer, along with other applications > where ITK is used in multiple shared libraries, dynamic_cast can fail > on Mac OSX. > > I summarized the cause of the problem and steps for the proposed solution here: > > https://issues.itk.org/jira/browse/ITK-3490 > > Feedback is welcome. The effort is targeted for the ITK 4.11.0 release. > From the issue it is not clear to me why you can't fix the symbol visibility issues, or which of these cases it causing the breakage. Reading the linked blog post it seems like Apple/Clang is doing the right thing, and C++ libraries must be careful to use consistent symbol visibility. I would be interested in further details on which case or cases are causing dynamic_cast to fail, and why using consistent symbol visibility in the interfaces is not feasible/possible. Thanks, Marcus _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Kitware offers ITK Training Courses, for more information visit: http://kitware.com/products/protraining.php Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/insight-developers From matt.mccormick at kitware.com Fri Nov 11 18:01:05 2016 From: matt.mccormick at kitware.com (Matt McCormick) Date: Fri, 11 Nov 2016 18:01:05 -0500 Subject: [ITK-dev] Workaround for dynamic_cast on Mac OSX In-Reply-To: <2702DADA-25CD-42D6-9CCE-BA306F400B1C@uiowa.edu> References: <2702DADA-25CD-42D6-9CCE-BA306F400B1C@uiowa.edu> Message-ID: Here are the tests: http://review.source.kitware.com/#/c/21755/ where reasonable export specification is added in both ITK and the client libraries. But, dynamic_cast fails on OSX: https://open.cdash.org/testDetails.php?test=499059765&build=4637669 Matt On Thu, Nov 10, 2016 at 3:21 PM, Johnson, Hans J wrote: > I agree with Marcus. At least until it is very clear that not using dynamic_cast is the only solution to a broken compiler, I am very weary of ?doing what works today?. > > Hans > > > -- > > > On 11/10/16, 1:11 PM, "Insight-developers on behalf of Marcus D. Hanwell" wrote: > > On Tue, Nov 8, 2016 at 5:01 PM, Matt McCormick > wrote: > > Hi folks, > > > > As we have wrestled with in Slicer, along with other applications > > where ITK is used in multiple shared libraries, dynamic_cast can fail > > on Mac OSX. > > > > I summarized the cause of the problem and steps for the proposed solution here: > > > > https://issues.itk.org/jira/browse/ITK-3490 > > > > Feedback is welcome. The effort is targeted for the ITK 4.11.0 release. > > > From the issue it is not clear to me why you can't fix the symbol > visibility issues, or which of these cases it causing the breakage. > Reading the linked blog post it seems like Apple/Clang is doing the > right thing, and C++ libraries must be careful to use consistent > symbol visibility. > > I would be interested in further details on which case or cases are > causing dynamic_cast to fail, and why using consistent symbol > visibility in the interfaces is not feasible/possible. > > Thanks, > > Marcus > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Kitware offers ITK Training Courses, for more information visit: > http://kitware.com/products/protraining.php > > Please keep messages on-topic and check the ITK FAQ at: > http://www.itk.org/Wiki/ITK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/insight-developers > > From simon.warfield at childrens.harvard.edu Sat Nov 12 12:22:54 2016 From: simon.warfield at childrens.harvard.edu (Simon Warfield) Date: Sat, 12 Nov 2016 12:22:54 -0500 Subject: [ITK-dev] Insight-developers Digest, Vol 151, Issue 16 In-Reply-To: References: Message-ID: <382501f3-ad7d-143f-3ae5-8c4690706c01@childrens.harvard.edu> On 11/12/16 12:00 PM, insight-developers-request at itk.org wrote: > > Here are the tests: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__review.source.kitware.com_-23_c_21755_&d=DQICAg&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=spboX-Qn5Dn-uyspT__O0BtpSEF5erHIiRAwdzSaa_QAQ58afxHcHSMuB76pSgfl&m=M-IiPEMMeqHF1XHRKIyX7e1SrEaHJUjru2T5LMeNq48&s=e1f60RJqOXt5tQ7np0HYJNJAW7V0q3QiRYCHKw9CV_U&e= > > where reasonable export specification is added in both ITK and the > client libraries. But, dynamic_cast fails on OSX: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__open.cdash.org_testDetails.php-3Ftest-3D499059765-26build-3D4637669&d=DQICAg&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=spboX-Qn5Dn-uyspT__O0BtpSEF5erHIiRAwdzSaa_QAQ58afxHcHSMuB76pSgfl&m=M-IiPEMMeqHF1XHRKIyX7e1SrEaHJUjru2T5LMeNq48&s=Fh8PMzdqTGvkcjXgnHusVcl_L6j6tMu22QGt88eXt6w&e= > > > Matt The document here: http://www.russellmcc.com/posts/2013-08-03-rtti.html , says this should work if all of the classes are appropriately marked as 'default' and that the linker will give a fatal warning if this is not the case. Where does the test code mark the classes shared across the dylib boundaries as 'default' rather than 'hidden' ? What does the OS X linker say about the code when fatal warnings are turned on ? --Simon From blowekamp at mail.nih.gov Mon Nov 14 14:18:55 2016 From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C]) Date: Mon, 14 Nov 2016 19:18:55 +0000 Subject: [ITK-dev] [slicer-devel] Workaround for dynamic_cast on Mac OSX In-Reply-To: <8aa1ac5103314c068ca9c3034159d775@PHSX10HT6.partners.org> References: <2702DADA-25CD-42D6-9CCE-BA306F400B1C@uiowa.edu> <8aa1ac5103314c068ca9c3034159d775@PHSX10HT6.partners.org> Message-ID: Matt, I believe that GCC 4.1 also had a very similar problem to what is occurring in with Apple Clang now. That looks like a good example for the problem. The replacement of all dynamic_casts of all itk::Objects is one approach. Here is a few others: 1) Make an explicit instantiation library with the ITK classes part of the shared libraries' interfaces. 2) Just compile the problematic libraries with default visibility. 3) Restore the functionality of the old ?WrapITK? Explicit language/feature to explicitly instantiate all of ITK. 4) Write an entire library which fully encapsulates the ITK templated interface and used it?s own object for the visibility specified API :) It?s interesting to note that Slicer CLI interface does not contain ITK templated objects. Does Slicer use ITK objects any where in it?s public API?s? HTH, Brad > On Nov 11, 2016, at 6:01 PM, Matt McCormick wrote: > > Here are the tests: > > http://review.source.kitware.com/#/c/21755/ > > where reasonable export specification is added in both ITK and the > client libraries. But, dynamic_cast fails on OSX: > > https://open.cdash.org/testDetails.php?test=499059765&build=4637669 > > > Matt > > On Thu, Nov 10, 2016 at 3:21 PM, Johnson, Hans J wrote: >> I agree with Marcus. At least until it is very clear that not using dynamic_cast is the only solution to a broken compiler, I am very weary of ?doing what works today?. >> >> Hans >> >> >> -- >> >> >> On 11/10/16, 1:11 PM, "Insight-developers on behalf of Marcus D. Hanwell" wrote: >> >> On Tue, Nov 8, 2016 at 5:01 PM, Matt McCormick >> wrote: >>> Hi folks, >>> >>> As we have wrestled with in Slicer, along with other applications >>> where ITK is used in multiple shared libraries, dynamic_cast can fail >>> on Mac OSX. >>> >>> I summarized the cause of the problem and steps for the proposed solution here: >>> >>> https://issues.itk.org/jira/browse/ITK-3490 >>> >>> Feedback is welcome. The effort is targeted for the ITK 4.11.0 release. >>> >> From the issue it is not clear to me why you can't fix the symbol >> visibility issues, or which of these cases it causing the breakage. >> Reading the linked blog post it seems like Apple/Clang is doing the >> right thing, and C++ libraries must be careful to use consistent >> symbol visibility. >> >> I would be interested in further details on which case or cases are >> causing dynamic_cast to fail, and why using consistent symbol >> visibility in the interfaces is not feasible/possible. >> >> Thanks, >> >> Marcus >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Kitware offers ITK Training Courses, for more information visit: >> http://kitware.com/products/protraining.php >> >> Please keep messages on-topic and check the ITK FAQ at: >> http://www.itk.org/Wiki/ITK_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/insight-developers >> >> > _______________________________________________ > slicer-devel mailing list > slicer-devel at bwh.harvard.edu > http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel > To unsubscribe: send email to slicer-devel-request at bwh.harvard.edu with unsubscribe as the subject > http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ From jchris.fillionr at kitware.com Mon Nov 14 14:30:03 2016 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Mon, 14 Nov 2016 14:30:03 -0500 Subject: [ITK-dev] [slicer-devel] Workaround for dynamic_cast on Mac OSX In-Reply-To: References: <2702DADA-25CD-42D6-9CCE-BA306F400B1C@uiowa.edu> <8aa1ac5103314c068ca9c3034159d775@PHSX10HT6.partners.org> Message-ID: Hi Brad, > Make an explicit instantiation library with the ITK classes part of the shared libraries' interfaces. My understanding is that we have been working on this for the past year without much success. Getting this right across compiler is difficult and hard to maintain Does Slicer use ITK objects any where in it?s public API?s? Yes, in few places: Base/CLI/itkPluginUtilities.h Libs/vtkITK/* Libs/MRML/IDImageIO/* Libs/MRML/Core/vtkITKTransformInverse.h Thanks Jc -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Mon Nov 14 14:47:13 2016 From: sean at rogue-research.com (Sean McBride) Date: Mon, 14 Nov 2016 14:47:13 -0500 Subject: [ITK-dev] Workaround for dynamic_cast on Mac OSX In-Reply-To: References: Message-ID: <20161114194713.731719343@mail.rogue-research.com> On Thu, 10 Nov 2016 14:11:59 -0500, Marcus D. Hanwell said: >I would be interested in further details on which case or cases are >causing dynamic_cast to fail, and why using consistent symbol >visibility in the interfaces is not feasible/possible. I'm not really following this issue, but... Is this really a Mac OS X issue, or is it being conflated with clang? That is, does the issue happen with clang on linux for example? Is it only Apple's fork or clang, or the open source one too? Does it happen with gcc on Mac OS X? etc. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From isaiah.norton at gmail.com Mon Nov 14 14:53:44 2016 From: isaiah.norton at gmail.com (Isaiah Norton) Date: Mon, 14 Nov 2016 20:53:44 +0100 Subject: [ITK-dev] Workaround for dynamic_cast on Mac OSX In-Reply-To: References: <2702DADA-25CD-42D6-9CCE-BA306F400B1C@uiowa.edu> Message-ID: Hi Matt, > Here are the tests: > http://review.source.kitware.com/#/c/21755/ where reasonable export specification is added in both ITK and the > client libraries. But, dynamic_cast fails on OSX: The export changes in this merge request don't seem to be related to the casts that are failing. A small change [1] allows all of the tests to pass. Of course, many more export annotations would be required for general applicability. There is a compiler option that could potentially address the issue "-fvisibility-ms-compat" -- see [2]. As mentioned on that page, these RTTI type_info issues *also break exception handling*, so simply changing all of the ITK `dynamic_cast` uses to a custom implementation will not fully address the issue (I have encountered this a number of times in Slicer: ITK exceptions thrown by dynamic libraries are incorrectly identified). Alternatively, if there is concern about symbol bloat (I've seen some threads to that effect related to SimpleITK) then a linker script could be used to export all `_ZTN*` symbols. Best, Isaiah [1] ``` diff --git a/Modules/Core/Common/include/itkImage.h b/Modules/Core/Common/include/itkImage.h index 2e601c2..9592957 100644 --- a/Modules/Core/Common/include/itkImage.h +++ b/Modules/Core/Common/include/itkImage.h @@ -72,7 +72,7 @@ namespace itk * \endwiki */ template< typename TPixel, unsigned int VImageDimension = 2 > -class Image:public ImageBase< VImageDimension > +class ITK_ABI_EXPORT Image:public ImageBase< VImageDimension > { public: /** Standard class typedefs */ ``` [2] https://developer.apple.com/library/content/technotes/tn2185/_index.html#//apple_ref/doc/uid/DTS10004200-CH1-SUBSECTION2 and https://developer.apple.com/library/content/technotes/tn2185/_index.html#//apple_ref/doc/uid/DTS10004200-CH1-SUBSECTION6 On Sat, Nov 12, 2016 at 12:01 AM, Matt McCormick wrote: > Here are the tests: > > http://review.source.kitware.com/#/c/21755/ > > where reasonable export specification is added in both ITK and the > client libraries. But, dynamic_cast fails on OSX: > > https://open.cdash.org/testDetails.php?test=499059765&build=4637669 > > > Matt > > On Thu, Nov 10, 2016 at 3:21 PM, Johnson, Hans J > wrote: > > I agree with Marcus. At least until it is very clear that not using > dynamic_cast is the only solution to a broken compiler, I am very weary of > ?doing what works today?. > > > > Hans > > > > > > -- > > > > > > On 11/10/16, 1:11 PM, "Insight-developers on behalf of Marcus D. > Hanwell" marcus.hanwell at kitware.com> wrote: > > > > On Tue, Nov 8, 2016 at 5:01 PM, Matt McCormick > > wrote: > > > Hi folks, > > > > > > As we have wrestled with in Slicer, along with other applications > > > where ITK is used in multiple shared libraries, dynamic_cast can > fail > > > on Mac OSX. > > > > > > I summarized the cause of the problem and steps for the proposed > solution here: > > > > > > https://issues.itk.org/jira/browse/ITK-3490 > > > > > > Feedback is welcome. The effort is targeted for the ITK 4.11.0 > release. > > > > > From the issue it is not clear to me why you can't fix the symbol > > visibility issues, or which of these cases it causing the breakage. > > Reading the linked blog post it seems like Apple/Clang is doing the > > right thing, and C++ libraries must be careful to use consistent > > symbol visibility. > > > > I would be interested in further details on which case or cases are > > causing dynamic_cast to fail, and why using consistent symbol > > visibility in the interfaces is not feasible/possible. > > > > Thanks, > > > > Marcus > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Kitware offers ITK Training Courses, for more information visit: > > http://kitware.com/products/protraining.php > > > > Please keep messages on-topic and check the ITK FAQ at: > > http://www.itk.org/Wiki/ITK_FAQ > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/insight-developers > > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Kitware offers ITK Training Courses, for more information visit: > http://kitware.com/products/protraining.php > > Please keep messages on-topic and check the ITK FAQ at: > http://www.itk.org/Wiki/ITK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/insight-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From blowekamp at mail.nih.gov Mon Nov 14 15:06:39 2016 From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C]) Date: Mon, 14 Nov 2016 20:06:39 +0000 Subject: [ITK-dev] [slicer-devel] Workaround for dynamic_cast on Mac OSX In-Reply-To: References: <2702DADA-25CD-42D6-9CCE-BA306F400B1C@uiowa.edu> <8aa1ac5103314c068ca9c3034159d775@PHSX10HT6.partners.org> Message-ID: <5C023ABD-2C26-4424-835E-60A603F31880@mail.nih.gov> JC, On Nov 14, 2016, at 2:30 PM, Jean-Christophe Fillion-Robin > wrote: Hi Brad, > Make an explicit instantiation library with the ITK classes part of the shared libraries' interfaces. My understanding is that we have been working on this for the past year without much success. Getting this right across compiler is difficult and hard to maintain It is a potential solutions for smaller projects which have a couple well defined ITK classes in the API. Yes is certainly is hard to maintain. SimpleITK did this and were are seeing some portabilities to this solution today. But SimpleITK?s motivation was for library size reduction and compilation efficiency. This is why there is a additional suggestion of restoring ITK?s wrapping infrastructure to do explicit instantiation. With the terrific advancements of class_xml and the general infrastructure, it would be ideal to enable the option to instantiate the templated itk::Objects based on the CMake parameters used for languages wrapping. On a large scale I don?t see an alternative to automate the explicit instantiation. Does Slicer use ITK objects any where in it?s public API?s? Yes, in few places: Do these really produce itk::Objects? Here is my quick view. Base/CLI/itkPluginUtilities.h I see some template functions and an itk::ProcessObject in the interface. That does not look like the problematic pattern. Libs/vtkITK/* The vtkITK infrastructure is an example of the proposed solution #4 Libs/MRML/IDImageIO/* This appears to be an ITK ImageIO Factory. This pattern should be correctly exports specified and not an issue with the templated ImageFileReader. Libs/MRML/Core/vtkITKTransformInverse.h OK, this one could have issues ITK BSplines with ITK Images. Would need a close look. I was hoping that after the ITK Transform factory most of the dynamic_cast issues would be gone. What is remaining? Thanks Jc -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From isaiah.norton at gmail.com Mon Nov 14 15:08:47 2016 From: isaiah.norton at gmail.com (Isaiah Norton) Date: Mon, 14 Nov 2016 21:08:47 +0100 Subject: [ITK-dev] Workaround for dynamic_cast on Mac OSX In-Reply-To: <20161114194713.731719343@mail.rogue-research.com> References: <20161114194713.731719343@mail.rogue-research.com> Message-ID: On Mon, Nov 14, 2016 at 8:47 PM, Sean McBride wrote: > On Thu, 10 Nov 2016 14:11:59 -0500, Marcus D. Hanwell said: > > >I would be interested in further details on which case or cases are > >causing dynamic_cast to fail, and why using consistent symbol > >visibility in the interfaces is not feasible/possible. > > I'm not really following this issue, but... > > Is this really a Mac OS X issue, or is it being conflated with clang? > That is, does the issue happen with clang on linux for example? Is it only > Apple's fork or clang, or the open source one too? Does it happen with gcc > on Mac OS X? etc. > The compiler ABI rules and behavior have not changed. What has changed is that OS X linker fallbacks have been removed [1], and Slicer (and perhaps ITK itself by default, I haven't spelunked the log) have set the default symbol visibility to hidden, which means that (now-hidden) type_info symbols are not coalesced across compilation unit boundaries. I would recommend this summary of the issue from a libreoffice commit message [2], as well as the summary linked in a previous message [3]. Recent libstdc++ have reinstated a strcmp fallback [4], so the issue is unlikely to be encountered on most Linux distributions. [1] On OS X, my understanding is that libc++ (cxxabi) was compiled with "_LIBCXX_DYNAMIC_FALLBACK" until OS X 10.11, which causes a fallback to strcmp comparison of the type_info name (10.11 still contains a program name-based fallback for two Adobe products that Apple could not reasonably break). [2] https://lists.freedesktop.org/archives/libreoffice-commits/2015-January/091572.html [3] http://www.russellmcc.com/posts/2013-08-03-rtti.html [4] https://gcc.gnu.org/ml/gcc-patches/2009-07/msg01239.html > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Kitware offers ITK Training Courses, for more information visit: > http://kitware.com/products/protraining.php > > Please keep messages on-topic and check the ITK FAQ at: > http://www.itk.org/Wiki/ITK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/insight-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.mccormick at kitware.com Mon Nov 14 18:16:40 2016 From: matt.mccormick at kitware.com (Matt McCormick) Date: Mon, 14 Nov 2016 18:16:40 -0500 Subject: [ITK-dev] Insight-developers Digest, Vol 151, Issue 16 In-Reply-To: <382501f3-ad7d-143f-3ae5-8c4690706c01@childrens.harvard.edu> References: <382501f3-ad7d-143f-3ae5-8c4690706c01@childrens.harvard.edu> Message-ID: On Sat, Nov 12, 2016 at 12:22 PM, Simon Warfield wrote: > On 11/12/16 12:00 PM, insight-developers-request at itk.org wrote: >> >> >> Here are the tests: >> >> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__review.source.kitware.com_-23_c_21755_&d=DQICAg&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=spboX-Qn5Dn-uyspT__O0BtpSEF5erHIiRAwdzSaa_QAQ58afxHcHSMuB76pSgfl&m=M-IiPEMMeqHF1XHRKIyX7e1SrEaHJUjru2T5LMeNq48&s=e1f60RJqOXt5tQ7np0HYJNJAW7V0q3QiRYCHKw9CV_U&e= >> >> where reasonable export specification is added in both ITK and the >> client libraries. But, dynamic_cast fails on OSX: >> >> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__open.cdash.org_testDetails.php-3Ftest-3D499059765-26build-3D4637669&d=DQICAg&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=spboX-Qn5Dn-uyspT__O0BtpSEF5erHIiRAwdzSaa_QAQ58afxHcHSMuB76pSgfl&m=M-IiPEMMeqHF1XHRKIyX7e1SrEaHJUjru2T5LMeNq48&s=Fh8PMzdqTGvkcjXgnHusVcl_L6j6tMu22QGt88eXt6w&e= >> >> >> Matt > > > The document here: http://www.russellmcc.com/posts/2013-08-03-rtti.html , > says this should work if all of the classes are appropriately marked as > 'default' and that the linker will give a fatal warning if this is not the > case. > > Where does the test code mark the classes shared across the dylib boundaries > as 'default' rather than 'hidden' ? The client libraries are marked as default using the _EXPORT macros. For example: class ClientTestLibraryA_EXPORT ITKObjectProducer The ClientTestLibraryA_EXPORT macro is defined in ClientTestLibraryAExport.h: # define ClientTestLibraryA_EXPORT __attribute__((visibility("default"))) However, the issue is with the itk::Image< float, 3 > type, which is implicitly instantiated. > What does the OS X linker say about the code when fatal warnings are turned > on ? The OSX linker does not throw any warnings in the test case provided because of implicit instantiation. OSX is an important platform to support, and we must also support implicit instantiation. Thanks, Matt From matt.mccormick at kitware.com Mon Nov 14 18:18:05 2016 From: matt.mccormick at kitware.com (Matt McCormick) Date: Mon, 14 Nov 2016 18:18:05 -0500 Subject: [ITK-dev] [slicer-devel] Workaround for dynamic_cast on Mac OSX In-Reply-To: References: <2702DADA-25CD-42D6-9CCE-BA306F400B1C@uiowa.edu> <8aa1ac5103314c068ca9c3034159d775@PHSX10HT6.partners.org> Message-ID: On Mon, Nov 14, 2016 at 2:18 PM, Lowekamp, Bradley (NIH/NLM/LHC) [C] wrote: > Matt, > > I believe that GCC 4.1 also had a very similar problem to what is occurring in with Apple Clang now. Thanks to the GCC version dashboard builds that you maintain, we should be able to see if other GCC's have that issue, too :-). > That looks like a good example for the problem. > > The replacement of all dynamic_casts of all itk::Objects is one approach. Here is a few others: > > 1) Make an explicit instantiation library with the ITK classes part of the shared libraries' interfaces. > 2) Just compile the problematic libraries with default visibility. > 3) Restore the functionality of the old ?WrapITK? Explicit language/feature to explicitly instantiate all of ITK. > 4) Write an entire library which fully encapsulates the ITK templated interface and used it?s own object for the visibility specified API :) These may be good solutions for some use cases. However, we still need to support general implicit instantiation. ITK is predominantly used via implicit instantiation. Explicit instantiation results in building libraries with types that are unused and have an associated negative build time, size, and load time. And, it limits the types that can be used relative to implicit instantiation. > It?s interesting to note that Slicer CLI interface does not contain ITK templated objects. Does Slicer use ITK objects any where in it?s public API?s? Note that this issue becomes predominantly problematic when ITK templated objects are not in the ABI but used internally (as in the test case). Thanks, Matt From matt.mccormick at kitware.com Mon Nov 14 18:36:00 2016 From: matt.mccormick at kitware.com (Matt McCormick) Date: Mon, 14 Nov 2016 18:36:00 -0500 Subject: [ITK-dev] Workaround for dynamic_cast on Mac OSX In-Reply-To: References: <2702DADA-25CD-42D6-9CCE-BA306F400B1C@uiowa.edu> Message-ID: On Mon, Nov 14, 2016 at 2:53 PM, Isaiah Norton wrote: > Hi Matt, > >> >> Here are the tests: >> http://review.source.kitware.com/#/c/21755/ >> >> where reasonable export specification is added in both ITK and the >> client libraries. But, dynamic_cast fails on OSX: > > > The export changes in this merge request don't seem to be related to the > casts that are failing. Correct. This patch is intended to just be a self-contained test that demonstrates the issue. > A small change [1] allows all of the tests to pass. > Of course, many more export annotations would be required for general > applicability. Thanks for implementing and testing a possible solution. ITK_API_EXPORT does not work with Windows static builds, but we could try ITKCommon_TEMPLATE_EXPORT, which we developed for explicit template instantiation markup [1]. However, more testing is required to determine if this works for implicit template instantiation on all platforms and does not have other side effects. A statement in one of the links you referenced [2], "there is unfortunately no way to mark only the (implicitly generated) RTTI symbols for default visibility" implies caution. > There is a compiler option that could potentially address the issue > "-fvisibility-ms-compat" -- see [2]. As mentioned on that page, these RTTI > type_info issues *also break exception handling*, so simply changing all of > the ITK `dynamic_cast` uses to a custom implementation will not fully > address the issue (I have encountered this a number of times in Slicer: ITK > exceptions thrown by dynamic libraries are incorrectly identified). > > Alternatively, if there is concern about symbol bloat (I've seen some > threads to that effect related to SimpleITK) then a linker script could be > used to export all `_ZTN*` symbols. Thanks for the pointer. Symbol bloat is a concern. Also, there are potential issues with how symbols are handled with dlopen and RTLD_GLOBAL, along with keeping a GlobalModifiedTime across the process, especially with respect to Python wrapping. This patch remarks on some of the issues we are currently trying to address [3]. We will test further with Python wrapping for OSX with the ITKCommon_TEMPLATE_EXPORT approach, then investigate -fvisibility-ms-compat if that does not prove viable. Thanks, Matt [1] https://github.com/InsightSoftwareConsortium/ITK/commit/d9633b7562c8223bf5ea8e1ee08eaa2e91506e58 [2] https://lists.freedesktop.org/archives/libreoffice-commits/2015-January/091572.html [3] http://review.source.kitware.com/#/c/21361/ From blowekamp at mail.nih.gov Tue Nov 15 10:17:39 2016 From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C]) Date: Tue, 15 Nov 2016 15:17:39 +0000 Subject: [ITK-dev] [slicer-devel] Workaround for dynamic_cast on Mac OSX In-Reply-To: References: <2702DADA-25CD-42D6-9CCE-BA306F400B1C@uiowa.edu> <8aa1ac5103314c068ca9c3034159d775@PHSX10HT6.partners.org> Message-ID: <0106B066-3F3C-4509-9397-BD19EC7C707F@mail.nih.gov> > On Nov 14, 2016, at 6:18 PM, Matt McCormick wrote: > > On Mon, Nov 14, 2016 at 2:18 PM, Lowekamp, Bradley (NIH/NLM/LHC) [C] > wrote: >> Matt, >> >> I believe that GCC 4.1 also had a very similar problem to what is occurring in with Apple Clang now. > > Thanks to the GCC version dashboard builds that you maintain, we > should be able to see if other GCC's have that issue, too :-). > Based on the good information Isaiah has referenced: It may be that the prior gcc 4.1 behavior was due to the version of libstdc++ that was distributed with gcc 4.1, so with the dashboard system using gcc4.1 with libstdc++.so.6.0.19 at runtime may have different behavior. > >> It?s interesting to note that Slicer CLI interface does not contain ITK templated objects. Does Slicer use ITK objects any where in it?s public API?s? > > Note that this issue becomes predominantly problematic when ITK > templated objects are not in the ABI but used internally (as in the > test case). > > > Thanks, > Matt I?m not sure what the right term is. Yes, in the test case the templated object is not explicitly in the ABI/API of the library, but the method exposes private templated objects by producing objects which are intended to be ?cast" to the templated object. So by documentation and behavior instances of private templated object are exposed in the API of the test case? So my point? I think that developing a clean interface without excessive multiple instances as well as not exposing private instance is important and should be the first approach. If there are places remaining in Slicer or ITK which ?expose? private symbols I would like to help to directly address them. I also acknowledge that some interfaces were not designed with this in mind and are limited in their ability to meet these best practices and therefor need the ?SafeDownCast? work around. I think I have gone past my 2 cents on this issue. HTH, Brad From blowekamp at mail.nih.gov Tue Nov 15 10:30:10 2016 From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C]) Date: Tue, 15 Nov 2016 15:30:10 +0000 Subject: [ITK-dev] Installed External Module list Message-ID: <0D7C32B4-D65A-4004-AE74-82A033EDB45A@mail.nih.gov> Hi! I am working on the SimpleITK Superbuid. I have install ITK to a directory, then I build an external ITK module, and install that too. All the headers are happily there and works just fine! However, I would like to verify that the ITK install has the additional external ITK module. I expected it to be listed in ITK_MODULES_ENABLED, but it?s not. How can I detect if an external ITK module is installed? Do we need to update the install behavior to support this? Thanks, Brad From hans-johnson at uiowa.edu Tue Nov 15 10:25:03 2016 From: hans-johnson at uiowa.edu (Johnson, Hans J) Date: Tue, 15 Nov 2016 15:25:03 +0000 Subject: [ITK-dev] [slicer-devel] Workaround for dynamic_cast on Mac OSX In-Reply-To: <0106B066-3F3C-4509-9397-BD19EC7C707F@mail.nih.gov> References: <2702DADA-25CD-42D6-9CCE-BA306F400B1C@uiowa.edu> <8aa1ac5103314c068ca9c3034159d775@PHSX10HT6.partners.org> <0106B066-3F3C-4509-9397-BD19EC7C707F@mail.nih.gov> Message-ID: <670247C4-4B65-4F42-B52C-46B702E43DD5@uiowa.edu> Brad, Nicely put. Thank you everyone for digging into this issues and putting careful consideration into identifying the root of the problem. Hans -- On 11/15/16, 9:17 AM, "Lowekamp, Bradley (NIH/NLM/LHC) [C]" wrote: > On Nov 14, 2016, at 6:18 PM, Matt McCormick wrote: > > On Mon, Nov 14, 2016 at 2:18 PM, Lowekamp, Bradley (NIH/NLM/LHC) [C] > wrote: >> Matt, >> >> I believe that GCC 4.1 also had a very similar problem to what is occurring in with Apple Clang now. > > Thanks to the GCC version dashboard builds that you maintain, we > should be able to see if other GCC's have that issue, too :-). > Based on the good information Isaiah has referenced: It may be that the prior gcc 4.1 behavior was due to the version of libstdc++ that was distributed with gcc 4.1, so with the dashboard system using gcc4.1 with libstdc++.so.6.0.19 at runtime may have different behavior. > >> It?s interesting to note that Slicer CLI interface does not contain ITK templated objects. Does Slicer use ITK objects any where in it?s public API?s? > > Note that this issue becomes predominantly problematic when ITK > templated objects are not in the ABI but used internally (as in the > test case). > > > Thanks, > Matt I?m not sure what the right term is. Yes, in the test case the templated object is not explicitly in the ABI/API of the library, but the method exposes private templated objects by producing objects which are intended to be ?cast" to the templated object. So by documentation and behavior instances of private templated object are exposed in the API of the test case? So my point? I think that developing a clean interface without excessive multiple instances as well as not exposing private instance is important and should be the first approach. If there are places remaining in Slicer or ITK which ?expose? private symbols I would like to help to directly address them. I also acknowledge that some interfaces were not designed with this in mind and are limited in their ability to meet these best practices and therefor need the ?SafeDownCast? work around. I think I have gone past my 2 cents on this issue. HTH, Brad From matt.mccormick at kitware.com Tue Nov 15 13:40:37 2016 From: matt.mccormick at kitware.com (Matt McCormick) Date: Tue, 15 Nov 2016 13:40:37 -0500 Subject: [ITK-dev] Installed External Module list In-Reply-To: <0D7C32B4-D65A-4004-AE74-82A033EDB45A@mail.nih.gov> References: <0D7C32B4-D65A-4004-AE74-82A033EDB45A@mail.nih.gov> Message-ID: Hi, To require an external module, add it to the COMPONENTS argument of find_package(ITK). For example, find_package(ITK REQUIRED COMPONENTS AnExternalModule) HTH, Matt On Tue, Nov 15, 2016 at 10:30 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C] wrote: > Hi! > > I am working on the SimpleITK Superbuid. I have install ITK to a directory, then I build an external ITK module, and install that too. All the headers are happily there and works just fine! > > However, I would like to verify that the ITK install has the additional external ITK module. I expected it to be listed in ITK_MODULES_ENABLED, but it?s not. How can I detect if an external ITK module is installed? > > Do we need to update the install behavior to support this? > > Thanks, > Brad > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Kitware offers ITK Training Courses, for more information visit: > http://kitware.com/products/protraining.php > > Please keep messages on-topic and check the ITK FAQ at: > http://www.itk.org/Wiki/ITK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/insight-developers From blowekamp at mail.nih.gov Tue Nov 15 14:07:05 2016 From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C]) Date: Tue, 15 Nov 2016 19:07:05 +0000 Subject: [ITK-dev] Installed External Module list In-Reply-To: References: <0D7C32B4-D65A-4004-AE74-82A033EDB45A@mail.nih.gov> Message-ID: <59518A9E-8526-437A-BF12-11D3C3FC609B@mail.nih.gov> Matt, Yes, that is the documented usage. I do that for the subdirectories where I am about to use the components [3,4] But at the top-level, I am trying to ask what components are installed [1,2] so I know what options to turn on and how to control some aspects for the build process. How do I get a list of modules available? I am now testing with find_package?s ?OPTIONAL_COMPONENTS? to see what happens. Thanks, Brad [1] https://github.com/SimpleITK/SimpleITK/blob/master/CMakeLists.txt#L61-L83 [2] https://github.com/SimpleITK/SimpleITK/blob/master/CMake/sitkCheckForITKModuleDependencies.cmake [3] https://github.com/SimpleITK/SimpleITK/blob/master/Code/IO/src/CMakeLists.txt#L14-L20 [4] https://github.com/SimpleITK/SimpleITK/blob/master/Code/Common/src/CMakeLists.txt#L32-L34 > On Nov 15, 2016, at 1:40 PM, Matt McCormick wrote: > > Hi, > > To require an external module, add it to the COMPONENTS argument of > find_package(ITK). For example, > > find_package(ITK REQUIRED COMPONENTS AnExternalModule) > > HTH, > Matt > > On Tue, Nov 15, 2016 at 10:30 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C] > wrote: >> Hi! >> >> I am working on the SimpleITK Superbuid. I have install ITK to a directory, then I build an external ITK module, and install that too. All the headers are happily there and works just fine! >> >> However, I would like to verify that the ITK install has the additional external ITK module. I expected it to be listed in ITK_MODULES_ENABLED, but it?s not. How can I detect if an external ITK module is installed? >> >> Do we need to update the install behavior to support this? >> >> Thanks, >> Brad >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Kitware offers ITK Training Courses, for more information visit: >> http://kitware.com/products/protraining.php >> >> Please keep messages on-topic and check the ITK FAQ at: >> http://www.itk.org/Wiki/ITK_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/insight-developers From blowekamp at mail.nih.gov Tue Nov 15 14:42:17 2016 From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C]) Date: Tue, 15 Nov 2016 19:42:17 +0000 Subject: [ITK-dev] [ITK] Installed External Module list In-Reply-To: <59518A9E-8526-437A-BF12-11D3C3FC609B@mail.nih.gov> References: <0D7C32B4-D65A-4004-AE74-82A033EDB45A@mail.nih.gov> <59518A9E-8526-437A-BF12-11D3C3FC609B@mail.nih.gov> Message-ID: OK, Here is my test code: set(op_mod "ITKReview") find_package(ITK REQUIRED OPTIONAL_COMPONENTS ${op_mod}) message("ITK_${op_mod}_FOUND: ${ITK_${op_mod}_FOUND}?) I?m running CMake 3.6.2. According to this documentation [1], I expect the above variable to be set if the component is available or not. Here the output: ITK_ITKReview_FOUND: So it appears these per-component variables are not being set. I thought I?d first test this with an internal module before checking an installed external. How do I optionally use ITK components? How do I know what components are available in an installed ITK? Thanks, Brad [1] https://cmake.org/cmake/help/v3.0/manual/cmake-developer.7.html#module-documentation > On Nov 15, 2016, at 2:07 PM, Lowekamp, Bradley (NIH/NLM/LHC) [C] wrote: > > Matt, > > Yes, that is the documented usage. I do that for the subdirectories where I am about to use the components [3,4] > > But at the top-level, I am trying to ask what components are installed [1,2] so I know what options to turn on and how to control some aspects for the build process. How do I get a list of modules available? > > I am now testing with find_package?s ?OPTIONAL_COMPONENTS? to see what happens. > > Thanks, > Brad > > [1] https://github.com/SimpleITK/SimpleITK/blob/master/CMakeLists.txt#L61-L83 > [2] https://github.com/SimpleITK/SimpleITK/blob/master/CMake/sitkCheckForITKModuleDependencies.cmake > [3] https://github.com/SimpleITK/SimpleITK/blob/master/Code/IO/src/CMakeLists.txt#L14-L20 > [4] https://github.com/SimpleITK/SimpleITK/blob/master/Code/Common/src/CMakeLists.txt#L32-L34 > >> On Nov 15, 2016, at 1:40 PM, Matt McCormick wrote: >> >> Hi, >> >> To require an external module, add it to the COMPONENTS argument of >> find_package(ITK). For example, >> >> find_package(ITK REQUIRED COMPONENTS AnExternalModule) >> >> HTH, >> Matt >> >> On Tue, Nov 15, 2016 at 10:30 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C] >> wrote: >>> Hi! >>> >>> I am working on the SimpleITK Superbuid. I have install ITK to a directory, then I build an external ITK module, and install that too. All the headers are happily there and works just fine! >>> >>> However, I would like to verify that the ITK install has the additional external ITK module. I expected it to be listed in ITK_MODULES_ENABLED, but it?s not. How can I detect if an external ITK module is installed? >>> >>> Do we need to update the install behavior to support this? >>> >>> Thanks, >>> Brad >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Kitware offers ITK Training Courses, for more information visit: >>> http://kitware.com/products/protraining.php >>> >>> Please keep messages on-topic and check the ITK FAQ at: >>> http://www.itk.org/Wiki/ITK_FAQ >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/insight-developers > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Kitware offers ITK Training Courses, for more information visit: > http://kitware.com/products/protraining.php > > Please keep messages on-topic and check the ITK FAQ at: > http://www.itk.org/Wiki/ITK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/insight-developers > _______________________________________________ > Community mailing list > Community at itk.org > http://public.kitware.com/mailman/listinfo/community From matt.mccormick at kitware.com Tue Nov 15 15:16:25 2016 From: matt.mccormick at kitware.com (Matt McCormick) Date: Tue, 15 Nov 2016 15:16:25 -0500 Subject: [ITK-dev] [ITK] Installed External Module list In-Reply-To: References: <0D7C32B4-D65A-4004-AE74-82A033EDB45A@mail.nih.gov> <59518A9E-8526-437A-BF12-11D3C3FC609B@mail.nih.gov> Message-ID: It does not look like that feature is implemented. Here is an issue to track: https://issues.itk.org/jira/browse/ITK-3498 Thanks, Matt On Tue, Nov 15, 2016 at 2:42 PM, Lowekamp, Bradley (NIH/NLM/LHC) [C] wrote: > OK, > > Here is my test code: > > set(op_mod "ITKReview") > find_package(ITK REQUIRED OPTIONAL_COMPONENTS ${op_mod}) > message("ITK_${op_mod}_FOUND: ${ITK_${op_mod}_FOUND}?) > > I?m running CMake 3.6.2. According to this documentation [1], I expect the above variable to be set if the component is available or not. Here the output: > > ITK_ITKReview_FOUND: > > So it appears these per-component variables are not being set. I thought I?d first test this with an internal module before checking an installed external. > > How do I optionally use ITK components? How do I know what components are available in an installed ITK? > > Thanks, > Brad > > > > [1] https://cmake.org/cmake/help/v3.0/manual/cmake-developer.7.html#module-documentation > > >> On Nov 15, 2016, at 2:07 PM, Lowekamp, Bradley (NIH/NLM/LHC) [C] wrote: >> >> Matt, >> >> Yes, that is the documented usage. I do that for the subdirectories where I am about to use the components [3,4] >> >> But at the top-level, I am trying to ask what components are installed [1,2] so I know what options to turn on and how to control some aspects for the build process. How do I get a list of modules available? >> >> I am now testing with find_package?s ?OPTIONAL_COMPONENTS? to see what happens. >> >> Thanks, >> Brad >> >> [1] https://github.com/SimpleITK/SimpleITK/blob/master/CMakeLists.txt#L61-L83 >> [2] https://github.com/SimpleITK/SimpleITK/blob/master/CMake/sitkCheckForITKModuleDependencies.cmake >> [3] https://github.com/SimpleITK/SimpleITK/blob/master/Code/IO/src/CMakeLists.txt#L14-L20 >> [4] https://github.com/SimpleITK/SimpleITK/blob/master/Code/Common/src/CMakeLists.txt#L32-L34 >> >>> On Nov 15, 2016, at 1:40 PM, Matt McCormick wrote: >>> >>> Hi, >>> >>> To require an external module, add it to the COMPONENTS argument of >>> find_package(ITK). For example, >>> >>> find_package(ITK REQUIRED COMPONENTS AnExternalModule) >>> >>> HTH, >>> Matt >>> >>> On Tue, Nov 15, 2016 at 10:30 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C] >>> wrote: >>>> Hi! >>>> >>>> I am working on the SimpleITK Superbuid. I have install ITK to a directory, then I build an external ITK module, and install that too. All the headers are happily there and works just fine! >>>> >>>> However, I would like to verify that the ITK install has the additional external ITK module. I expected it to be listed in ITK_MODULES_ENABLED, but it?s not. How can I detect if an external ITK module is installed? >>>> >>>> Do we need to update the install behavior to support this? >>>> >>>> Thanks, >>>> Brad >>>> >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Kitware offers ITK Training Courses, for more information visit: >>>> http://kitware.com/products/protraining.php >>>> >>>> Please keep messages on-topic and check the ITK FAQ at: >>>> http://www.itk.org/Wiki/ITK_FAQ >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/insight-developers >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Kitware offers ITK Training Courses, for more information visit: >> http://kitware.com/products/protraining.php >> >> Please keep messages on-topic and check the ITK FAQ at: >> http://www.itk.org/Wiki/ITK_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/insight-developers >> _______________________________________________ >> Community mailing list >> Community at itk.org >> http://public.kitware.com/mailman/listinfo/community > From blowekamp at mail.nih.gov Wed Nov 16 08:42:59 2016 From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C]) Date: Wed, 16 Nov 2016 13:42:59 +0000 Subject: [ITK-dev] [ITK] open.cdash.org upgrade Friday 2016.11.04 12pm EDT In-Reply-To: References: <61F71A78-0415-4827-AAE7-D331F5FF09FC@mail.nih.gov> Message-ID: <9C1668AE-7DE4-4980-A62F-D6FFD68F68A3@mail.nih.gov> Hello Zack, I am looking at the SImpleITK dashboard [1]. It appears the hyper links are not being parsed/displayed properly. With the level of nested templates SimpleITK has this would be classified as a torture test for parsing to distinguish HTML tags from C++ templates. Please let me know if this is a known issue and if it can be fixed. Thanks, Brad [1] https://open.cdash.org/viewBuildError.php?type=1&buildid=4642955 On Nov 8, 2016, at 9:02 AM, Zack Galbreath > wrote: On Mon, Nov 7, 2016 at 9:30 AM, Zack Galbreath > wrote: I just purged the cache of coverage files on open.cdash.org, so line-by-line coverage should be properly displayed once this data is resubmitted tonight. I'll double check this tomorrow morning. It looks like this is fixed now. _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Kitware offers ITK Training Courses, for more information visit: http://kitware.com/products/protraining.php Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/insight-developers _______________________________________________ Community mailing list Community at itk.org http://public.kitware.com/mailman/listinfo/community -------------- next part -------------- An HTML attachment was scrubbed... URL: From zack.galbreath at kitware.com Wed Nov 16 11:26:33 2016 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Wed, 16 Nov 2016 11:26:33 -0500 Subject: [ITK-dev] [ITK] open.cdash.org upgrade Friday 2016.11.04 12pm EDT In-Reply-To: <9C1668AE-7DE4-4980-A62F-D6FFD68F68A3@mail.nih.gov> References: <61F71A78-0415-4827-AAE7-D331F5FF09FC@mail.nih.gov> <9C1668AE-7DE4-4980-A62F-D6FFD68F68A3@mail.nih.gov> Message-ID: On Wed, Nov 16, 2016 at 8:42 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C] < blowekamp at mail.nih.gov> wrote: > Hello Zack, > > I am looking at the SImpleITK dashboard [1]. It appears the hyper links > are not being parsed/displayed properly. With the level of nested templates > SimpleITK has this would be classified as a torture test for parsing to > distinguish HTML tags from C++ templates. > > Please let me know if this is a known issue and if it can be fixed. > I see what you mean. I'll report back here when I know more about what's causing this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Wed Nov 16 13:28:09 2016 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Wed, 16 Nov 2016 13:28:09 -0500 Subject: [ITK-dev] [ITK] open.cdash.org upgrade Friday 2016.11.04 12pm EDT In-Reply-To: References: <61F71A78-0415-4827-AAE7-D331F5FF09FC@mail.nih.gov> <9C1668AE-7DE4-4980-A62F-D6FFD68F68A3@mail.nih.gov> Message-ID: Hi Zach, Could you also look into updating trunk.cdash.org (which is the instance behind slicer.cdash.org) ? Thanks Jc On Wed, Nov 16, 2016 at 11:26 AM, Zack Galbreath wrote: > On Wed, Nov 16, 2016 at 8:42 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C] < > blowekamp at mail.nih.gov> wrote: > >> Hello Zack, >> >> I am looking at the SImpleITK dashboard [1]. It appears the hyper links >> are not being parsed/displayed properly. With the level of nested templates >> SimpleITK has this would be classified as a torture test for parsing to >> distinguish HTML tags from C++ templates. >> >> Please let me know if this is a known issue and if it can be fixed. >> > > I see what you mean. I'll report back here when I know more about what's > causing this. > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Kitware offers ITK Training Courses, for more information visit: > http://kitware.com/products/protraining.php > > Please keep messages on-topic and check the ITK FAQ at: > http://www.itk.org/Wiki/ITK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/insight-developers > > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zack.galbreath at kitware.com Fri Nov 18 15:17:28 2016 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Fri, 18 Nov 2016 15:17:28 -0500 Subject: [ITK-dev] [ITK] open.cdash.org upgrade Friday 2016.11.04 12pm EDT In-Reply-To: References: <61F71A78-0415-4827-AAE7-D331F5FF09FC@mail.nih.gov> <9C1668AE-7DE4-4980-A62F-D6FFD68F68A3@mail.nih.gov> Message-ID: On Wed, Nov 16, 2016 at 1:28 PM, Jean-Christophe Fillion-Robin < jchris.fillionr at kitware.com> wrote: > Hi Zach, > > Could you also look into updating trunk.cdash.org (which is the instance > behind slicer.cdash.org) ? > Will do! Just want to get a couple more PRs merged first. I'll reply back when the upgrade is complete. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans-johnson at uiowa.edu Mon Nov 21 10:08:39 2016 From: hans-johnson at uiowa.edu (Johnson, Hans J) Date: Mon, 21 Nov 2016 15:08:39 +0000 Subject: [ITK-dev] NIFTI -- Proposed change to be more compliant Message-ID: <57FC866C-D90B-4C57-963A-F77FC872883C@uiowa.edu> ITK Developers, The following patch provides 100% backwards compatibility and an end-user modifiable interface for setting the intents of the qform & sform. http://review.source.kitware.com/#/c/21795/ The previous configuration for NIFTI files is OK if we only live in an ITK echo-system. In the ITK echo-system we ignore both the sform & qform the intent codes because we only use the values in the qform. These two lines have intent codes that are EXACTLY BACKWARDS from the recommendations https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/IO/NIFTI/src/itkNiftiImageIO.cxx#L1717 https://nifti.nimh.nih.gov/nifti-1/documentation/nifti1fields/nifti1fields_pages/qsform_brief_usage The qform_code should be set to either NIFTI_XFORM_UNKNOWN or NIFTI_XFORM_SCANNER_ANAT. The sform code should be set to either NIFTI_XFORM_UNKNOWN, NIFTI_XFORM_ALIGNED_ANAT, NIFTI_XFORM_TALAIRACH or NIFTI_XFORM_MNI_152. ================= This is a long-standing bug that should be fixed with a new patch set: The sform & qform defaults were EXACTLY BACKWARDS from the recommended uses. ================= QUESTION ========== Please help me determine the balance between backwards compatibility conformance and improved interpretation of these nifi files. Thanks, Hans ======================================================================== | Hans J. Johnson, Ph.D., Associate Professor | | Appointments: | | - Electrical and Computer Engineering (Primary) | | - Biomedical Engineering | | - Psychiatry ,NMMM~ | | - Health Informatics MMMMMMMMMMMMMMN | | - Iowa Institute for Biomedical Imaging MMMMMMMMMMMMMMMMMMM | | - Iowa Informatics Institute MMMMMMMMMMM MMMM MMM | | MMMMMMMMMM I ?MMM MM M | | hans-johnson at uiowa.edu MMMMMMM ,$M, MMMM | | (319) 621 7185 (cell) MMMM~ MMMM MMMMMM | | (319) 384 3538 ECE Phone (Primary) MM 8MMMMMM MM | | M MMMMMMM, ,M~ M | | 4316 Seamans Center MMMMMM MM | | Iowa City, IA 52242 ,? | ======================================================================== http://emailcharter.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From blowekamp at mail.nih.gov Tue Nov 22 09:33:13 2016 From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C]) Date: Tue, 22 Nov 2016 14:33:13 +0000 Subject: [ITK-dev] [slicer-devel] Workaround for dynamic_cast on Mac OSX In-Reply-To: References: <2702DADA-25CD-42D6-9CCE-BA306F400B1C@uiowa.edu> <8aa1ac5103314c068ca9c3034159d775@PHSX10HT6.partners.org> Message-ID: Hello, I had one more thought on this issue as I was reading on other topics. There appears to be ways to pass the linker list of symbols or REGEX of symbols to export (-export-symbols and -export-symbols-regex). Perhaps instead of monkeying too much with the ITK casting and class export specification, maybe a regex for the RTTI or a generated list of symbols could be generated to export for the problematic configuration for WrapITK? Just another thought. Brad > On Nov 15, 2016, at 10:17 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C] wrote: > > >> On Nov 14, 2016, at 6:18 PM, Matt McCormick wrote: >> >> On Mon, Nov 14, 2016 at 2:18 PM, Lowekamp, Bradley (NIH/NLM/LHC) [C] >> wrote: >>> Matt, >>> >>> I believe that GCC 4.1 also had a very similar problem to what is occurring in with Apple Clang now. >> >> Thanks to the GCC version dashboard builds that you maintain, we >> should be able to see if other GCC's have that issue, too :-). >> > > Based on the good information Isaiah has referenced: It may be that the prior gcc 4.1 behavior was due to the version of libstdc++ that was distributed with gcc 4.1, so with the dashboard system using gcc4.1 with libstdc++.so.6.0.19 at runtime may have different behavior. > >> >>> It?s interesting to note that Slicer CLI interface does not contain ITK templated objects. Does Slicer use ITK objects any where in it?s public API?s? >> >> Note that this issue becomes predominantly problematic when ITK >> templated objects are not in the ABI but used internally (as in the >> test case). >> >> >> Thanks, >> Matt > > I?m not sure what the right term is. Yes, in the test case the templated object is not explicitly in the ABI/API of the library, but the method exposes private templated objects by producing objects which are intended to be ?cast" to the templated object. So by documentation and behavior instances of private templated object are exposed in the API of the test case? > > So my point? I think that developing a clean interface without excessive multiple instances as well as not exposing private instance is important and should be the first approach. If there are places remaining in Slicer or ITK which ?expose? private symbols I would like to help to directly address them. > > I also acknowledge that some interfaces were not designed with this in mind and are limited in their ability to meet these best practices and therefor need the ?SafeDownCast? work around. > > I think I have gone past my 2 cents on this issue. > > HTH, > Brad > _______________________________________________ > slicer-devel mailing list > slicer-devel at bwh.harvard.edu > http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel > To unsubscribe: send email to slicer-devel-request at bwh.harvard.edu with unsubscribe as the subject > http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ From isaiah.norton at gmail.com Tue Nov 22 11:22:59 2016 From: isaiah.norton at gmail.com (Isaiah Norton) Date: Tue, 22 Nov 2016 11:22:59 -0500 Subject: [ITK-dev] [slicer-devel] Workaround for dynamic_cast on Mac OSX In-Reply-To: References: <2702DADA-25CD-42D6-9CCE-BA306F400B1C@uiowa.edu> <8aa1ac5103314c068ca9c3034159d775@PHSX10HT6.partners.org> Message-ID: On Tue, Nov 22, 2016 at 9:33 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C] < blowekamp at mail.nih.gov> wrote: > > There appears to be ways to pass the linker list of symbols or REGEX of > symbols to export (-export-symbols and -export-symbols-regex). Perhaps > instead of monkeying too much with the ITK casting and class export > specification, maybe a regex for the RTTI or a generated list of symbols > could be generated to export for the problematic configuration for WrapITK? > These are libtool options, and they aren't supported by the OS X version of libtool. There is a related `-exported_symbols_list` ld option, but the Apple documentation warns that the export list cannot positively override the symbol visibility set by the compiler: https://developer.apple.com/library/content/technotes/ tn2185/_index.html#//apple_ref/doc/uid/DTS10004200-CH1-SUBSECTION5 On a related note, I looked at the implementation of `-fvisibility-ms-compat` in Clang, and it turns out there is a corresponding `__attribute__(type_visibility(...))` annotation which could be used on class declarations. See: http://stackoverflow.com/questions/28437772/what-does- clangs-type-visibility-attribute-do-and-when-should-one-use-it But the annotation is not supported by GCC, so `visibility-ms-compat` is probably still a better option to allow compatibility with both OSX and Linux. Best, Isaiah Just another thought. > Brad > > > On Nov 15, 2016, at 10:17 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C] < > blowekamp at mail.nih.gov> wrote: > > > > > >> On Nov 14, 2016, at 6:18 PM, Matt McCormick > wrote: > >> > >> On Mon, Nov 14, 2016 at 2:18 PM, Lowekamp, Bradley (NIH/NLM/LHC) [C] > >> wrote: > >>> Matt, > >>> > >>> I believe that GCC 4.1 also had a very similar problem to what is > occurring in with Apple Clang now. > >> > >> Thanks to the GCC version dashboard builds that you maintain, we > >> should be able to see if other GCC's have that issue, too :-). > >> > > > > Based on the good information Isaiah has referenced: It may be that the > prior gcc 4.1 behavior was due to the version of libstdc++ that was > distributed with gcc 4.1, so with the dashboard system using gcc4.1 with > libstdc++.so.6.0.19 at runtime may have different behavior. > > > >> > >>> It?s interesting to note that Slicer CLI interface does not contain > ITK templated objects. Does Slicer use ITK objects any where in it?s public > API?s? > >> > >> Note that this issue becomes predominantly problematic when ITK > >> templated objects are not in the ABI but used internally (as in the > >> test case). > >> > >> > >> Thanks, > >> Matt > > > > I?m not sure what the right term is. Yes, in the test case the templated > object is not explicitly in the ABI/API of the library, but the method > exposes private templated objects by producing objects which are intended > to be ?cast" to the templated object. So by documentation and behavior > instances of private templated object are exposed in the API of the test > case? > > > > So my point? I think that developing a clean interface without excessive > multiple instances as well as not exposing private instance is important > and should be the first approach. If there are places remaining in Slicer > or ITK which ?expose? private symbols I would like to help to directly > address them. > > > > I also acknowledge that some interfaces were not designed with this in > mind and are limited in their ability to meet these best practices and > therefor need the ?SafeDownCast? work around. > > > > I think I have gone past my 2 cents on this issue. > > > > HTH, > > Brad > > _______________________________________________ > > slicer-devel mailing list > > slicer-devel at bwh.harvard.edu > > http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel > > To unsubscribe: send email to slicer-devel-request at bwh.harvard.edu with > unsubscribe as the subject > > http://www.slicer.org/slicerWiki/index.php/Documentation/ > Nightly/Developers/FAQ > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Kitware offers ITK Training Courses, for more information visit: > http://kitware.com/products/protraining.php > > Please keep messages on-topic and check the ITK FAQ at: > http://www.itk.org/Wiki/ITK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/insight-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Fri Nov 25 15:47:26 2016 From: sean at rogue-research.com (Sean McBride) Date: Fri, 25 Nov 2016 15:47:26 -0500 Subject: [ITK-dev] -fvisibility=hidden link warnings with GetMetaDataObjectTypeName() Message-ID: <20161125204726.859979322@mail.rogue-research.com> Hi all, I'm trying to rebuild my app and all its C++ libraries with -fvisibility=hidden -fvisibility-inlines-hidden. It all builds, but I get 3 very similar link warnings building my app; the first is: ld: warning: direct access in function 'itk::MetaDataObject >::GetMetaDataObjectTypeName() const' from file 'libITKCommon.a(itkMetaDataObject.cxx.o)' to global weak symbol 'typeinfo for itk::Array' from file 'MyOwnCode.o' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings. I'm using ITK 4.10.1 on OS X 10.11.6 with Xcode 7.3.1 (AppleClang 7.3). I'm hoping one of you C++ wizards could help me decipher the problem. :) It sorta reminds me of the 'dynamic_cast on Mac OSX' thread, is it related? Thanks, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From blowekamp at mail.nih.gov Fri Nov 25 15:55:31 2016 From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C]) Date: Fri, 25 Nov 2016 20:55:31 +0000 Subject: [ITK-dev] -fvisibility=hidden link warnings with GetMetaDataObjectTypeName() In-Reply-To: <20161125204726.859979322@mail.rogue-research.com> References: <20161125204726.859979322@mail.rogue-research.com> Message-ID: <8DB39FAA-F297-4EBB-9560-31C6A97DE43E@mail.nih.gov> Hello, I presume you are compiling ITK with shared libraries? Would you happen to have a minimal example of ?MyOwnCode.cxx? that reproduces this warning? Thanks, Brad > On Nov 25, 2016, at 3:47 PM, Sean McBride wrote: > > Hi all, > > I'm trying to rebuild my app and all its C++ libraries with -fvisibility=hidden -fvisibility-inlines-hidden. It all builds, but I get 3 very similar link warnings building my app; the first is: > > ld: warning: direct access in function 'itk::MetaDataObject >::GetMetaDataObjectTypeName() const' from file 'libITKCommon.a(itkMetaDataObject.cxx.o)' to global weak symbol 'typeinfo for itk::Array' from file 'MyOwnCode.o' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings. > > I'm using ITK 4.10.1 on OS X 10.11.6 with Xcode 7.3.1 (AppleClang 7.3). > > I'm hoping one of you C++ wizards could help me decipher the problem. :) It sorta reminds me of the 'dynamic_cast on Mac OSX' thread, is it related? > > Thanks, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Kitware offers ITK Training Courses, for more information visit: > http://kitware.com/products/protraining.php > > Please keep messages on-topic and check the ITK FAQ at: > http://www.itk.org/Wiki/ITK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/insight-developers From isaiah.norton at gmail.com Mon Nov 28 12:14:31 2016 From: isaiah.norton at gmail.com (Isaiah Norton) Date: Mon, 28 Nov 2016 12:14:31 -0500 Subject: [ITK-dev] -fvisibility=hidden link warnings with GetMetaDataObjectTypeName() In-Reply-To: <20161125204726.859979322@mail.rogue-research.com> References: <20161125204726.859979322@mail.rogue-research.com> Message-ID: > > It sorta reminds me of the 'dynamic_cast on Mac OSX' thread, is it related? Yes. This is a symptom of the same issue: missing export annotations. Hans emailed about the same warnings in April (the mailing list archive is currently down so I can't provide a link, but I can find it in my gmail folder for insight-dev with a search for "global weak symbol"). On Fri, Nov 25, 2016 at 3:47 PM, Sean McBride wrote: > Hi all, > > I'm trying to rebuild my app and all its C++ libraries with > -fvisibility=hidden -fvisibility-inlines-hidden. It all builds, but I get > 3 very similar link warnings building my app; the first is: > > ld: warning: direct access in function 'itk::MetaDataObject > >::GetMetaDataObjectTypeName() const' from file 'libITKCommon.a(itkMetaDataObject.cxx.o)' > to global weak symbol 'typeinfo for itk::Array' from file > 'MyOwnCode.o' means the weak symbol cannot be overridden at runtime. This > was likely caused by different translation units being compiled with > different visibility settings. > > I'm using ITK 4.10.1 on OS X 10.11.6 with Xcode 7.3.1 (AppleClang 7.3). > > I'm hoping one of you C++ wizards could help me decipher the problem. :) > It sorta reminds me of the 'dynamic_cast on Mac OSX' thread, is it related? > > Thanks, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Kitware offers ITK Training Courses, for more information visit: > http://kitware.com/products/protraining.php > > Please keep messages on-topic and check the ITK FAQ at: > http://www.itk.org/Wiki/ITK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/insight-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From blowekamp at mail.nih.gov Mon Nov 28 10:59:41 2016 From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C]) Date: Mon, 28 Nov 2016 15:59:41 +0000 Subject: [ITK-dev] MSVC linking errors down but still problems Message-ID: <7A701955-0708-4A5F-B215-7E92CF133813@mail.nih.gov> Hello, I have recently added needed standard export specification to the explicitly instantiated ParametricPath class [1] to address many compilation errors [2] with standard shared library configuration with MSCV. The linker errors had the following form: ITKPath-4.11.lib(ITKPath-4.11.dll) : error LNK2005: "public: virtual void __cdecl itk::ParametricPath<2>::SetDefaultInputStepSize(double)" (?SetDefaultInputStepSize@?$ParametricPath@$01 at itk@@UEAAXN at Z) already defined in itkPathIteratorTest.obj [C:\d\itk-vs11-64rs\ITK-build\Modules\Filtering\Path\test\ITKPathTestDriver.vcxproj] The patch successfully address the problem with ?normal? shared libraries. Now a new linker error [3] has popped up with the CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS option enabled with just one MSVC compiler vs12: itkPolylineMask2DImageFilterTest.cxx.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) const itk::Path,2>::`vftable'" (__imp_??_7?$Path at NV?$ContinuousIndex at N$01 at itk@@$01 at itk@@6B@) referenced in function "protected: virtual __cdecl itk::PolyLineParametricPath<2>::~PolyLineParametricPath<2>(void)" (??1?$PolyLineParametricPath@$01 at itk@@MEAA at XZ) It is important to note that the missing Path symbol is the parent class of the explicitly instantiated and exported ParametricPath class. So who wants to take up this issue? Thanks, Brad [1] https://github.com/InsightSoftwareConsortium/ITK/compare/7ed1d9b058715f00a08ecac8cbc1498728296d57...0aa2e6fe7411c46ec21c27cbcde8eb42f4cdc4b4 [2] https://open.cdash.org/viewBuildError.php?buildid=4657350 [3] https://open.cdash.org/viewBuildError.php?buildid=4661233 From sean at rogue-research.com Mon Nov 28 16:59:46 2016 From: sean at rogue-research.com (Sean McBride) Date: Mon, 28 Nov 2016 16:59:46 -0500 Subject: [ITK-dev] -fvisibility=hidden link warnings with GetMetaDataObjectTypeName() In-Reply-To: <8DB39FAA-F297-4EBB-9560-31C6A97DE43E@mail.nih.gov> References: <20161125204726.859979322@mail.rogue-research.com> <8DB39FAA-F297-4EBB-9560-31C6A97DE43E@mail.nih.gov> Message-ID: <20161128215946.318358223@mail.rogue-research.com> On Fri, 25 Nov 2016 20:55:31 +0000, Lowekamp, Bradley (NIH/NLM/LHC) [C] said: >I presume you are compiling ITK with shared libraries? No, as static libraries. >Would you happen to have a minimal example of ?MyOwnCode.cxx? that >reproduces this warning? I reduced it to a very small Xcode project with only 1 source file. Then I continued to reduce it to just a command line invocation of clang and it stopped reproducing. :( I soon discovered that between Xcode 6.4 and 7.0 a bug seems to have been introduced where turning on "symbols hidden by default" in the GUI (aka "GCC_SYMBOLS_PRIVATE_EXTERN = YES") doesn't actually pass "-fvisibility=hidden" to clang! So, for my particular case at least, there is no ITK issue here. Sorry for the noise. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From blowekamp at mail.nih.gov Tue Nov 29 09:19:06 2016 From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C]) Date: Tue, 29 Nov 2016 14:19:06 +0000 Subject: [ITK-dev] -fvisibility=hidden link warnings with GetMetaDataObjectTypeName() In-Reply-To: <20161128215946.318358223@mail.rogue-research.com> References: <20161125204726.859979322@mail.rogue-research.com> <8DB39FAA-F297-4EBB-9560-31C6A97DE43E@mail.nih.gov> <20161128215946.318358223@mail.rogue-research.com> Message-ID: <271A2422-E884-47D5-8631-4A90C154975C@mail.nih.gov> Thanks for the update, and the work to narrow your problem down. Just to let you know, another alternative to managing the flags is to use CMake preset property variables. When I build ITK for SimpleITK I apply (depending on the configuration) the following CMake options: -DCMAKE_C_VISIBILITY_PRESET:BOOL=hidden -DCMAKE_CXX_VISIBILITY_PRESET:BOOL=hidden -DCMAKE_VISIBILITY_INLINES_HIDDEN:BOOL=ON This seems to work well now. And CMake appears to append the option after on the programatic manipulation of the standard flag variables. HTH, Brad > On Nov 28, 2016, at 4:59 PM, Sean McBride wrote: > > On Fri, 25 Nov 2016 20:55:31 +0000, Lowekamp, Bradley (NIH/NLM/LHC) [C] said: > >> I presume you are compiling ITK with shared libraries? > > No, as static libraries. > >> Would you happen to have a minimal example of ?MyOwnCode.cxx? that >> reproduces this warning? > > I reduced it to a very small Xcode project with only 1 source file. Then I continued to reduce it to just a command line invocation of clang and it stopped reproducing. :( > > I soon discovered that between Xcode 6.4 and 7.0 a bug seems to have been introduced where turning on "symbols hidden by default" in the GUI (aka "GCC_SYMBOLS_PRIVATE_EXTERN = YES") doesn't actually pass "-fvisibility=hidden" to clang! > > So, for my particular case at least, there is no ITK issue here. Sorry for the noise. > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada From hans-johnson at uiowa.edu Tue Nov 29 10:04:12 2016 From: hans-johnson at uiowa.edu (Johnson, Hans J) Date: Tue, 29 Nov 2016 15:04:12 +0000 Subject: [ITK-dev] -fvisibility=hidden link warnings with GetMetaDataObjectTypeName() In-Reply-To: <271A2422-E884-47D5-8631-4A90C154975C@mail.nih.gov> References: <20161125204726.859979322@mail.rogue-research.com> <8DB39FAA-F297-4EBB-9560-31C6A97DE43E@mail.nih.gov> <20161128215946.318358223@mail.rogue-research.com> <271A2422-E884-47D5-8631-4A90C154975C@mail.nih.gov> Message-ID: Brad, Is that command line correct? :BOOL=hidden ? Is that true, or false, or should it be :STRING=hidden ? Hans -- On 11/29/16, 8:19 AM, "Insight-developers on behalf of Lowekamp, Bradley (NIH/NLM/LHC) [C]" wrote: Thanks for the update, and the work to narrow your problem down. Just to let you know, another alternative to managing the flags is to use CMake preset property variables. When I build ITK for SimpleITK I apply (depending on the configuration) the following CMake options: -DCMAKE_C_VISIBILITY_PRESET:BOOL=hidden -DCMAKE_CXX_VISIBILITY_PRESET:BOOL=hidden -DCMAKE_VISIBILITY_INLINES_HIDDEN:BOOL=ON This seems to work well now. And CMake appears to append the option after on the programatic manipulation of the standard flag variables. HTH, Brad > On Nov 28, 2016, at 4:59 PM, Sean McBride wrote: > > On Fri, 25 Nov 2016 20:55:31 +0000, Lowekamp, Bradley (NIH/NLM/LHC) [C] said: > >> I presume you are compiling ITK with shared libraries? > > No, as static libraries. > >> Would you happen to have a minimal example of ?MyOwnCode.cxx? that >> reproduces this warning? > > I reduced it to a very small Xcode project with only 1 source file. Then I continued to reduce it to just a command line invocation of clang and it stopped reproducing. :( > > I soon discovered that between Xcode 6.4 and 7.0 a bug seems to have been introduced where turning on "symbols hidden by default" in the GUI (aka "GCC_SYMBOLS_PRIVATE_EXTERN = YES") doesn't actually pass "-fvisibility=hidden" to clang! > > So, for my particular case at least, there is no ITK issue here. Sorry for the noise. > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Kitware offers ITK Training Courses, for more information visit: http://kitware.com/products/protraining.php Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/insight-developers From blowekamp at mail.nih.gov Tue Nov 29 10:23:50 2016 From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C]) Date: Tue, 29 Nov 2016 15:23:50 +0000 Subject: [ITK-dev] -fvisibility=hidden link warnings with GetMetaDataObjectTypeName() In-Reply-To: References: <20161125204726.859979322@mail.rogue-research.com> <8DB39FAA-F297-4EBB-9560-31C6A97DE43E@mail.nih.gov> <20161128215946.318358223@mail.rogue-research.com> <271A2422-E884-47D5-8631-4A90C154975C@mail.nih.gov> Message-ID: You are right! I am surprised CMake does not generate warning about that. Thank you for the suggestion: https://github.com/SimpleITK/SimpleITK/pull/76 Brad > On Nov 29, 2016, at 10:04 AM, Johnson, Hans J wrote: > > Brad, > > Is that command line correct? > > :BOOL=hidden ? Is that true, or false, or should it be :STRING=hidden ? > > Hans > > > -- > > > On 11/29/16, 8:19 AM, "Insight-developers on behalf of Lowekamp, Bradley (NIH/NLM/LHC) [C]" wrote: > > Thanks for the update, and the work to narrow your problem down. > > Just to let you know, another alternative to managing the flags is to use CMake preset property variables. When I build ITK for SimpleITK I apply (depending on the configuration) the following CMake options: > > -DCMAKE_C_VISIBILITY_PRESET:BOOL=hidden > -DCMAKE_CXX_VISIBILITY_PRESET:BOOL=hidden > -DCMAKE_VISIBILITY_INLINES_HIDDEN:BOOL=ON > > This seems to work well now. And CMake appears to append the option after on the programatic manipulation of the standard flag variables. > > HTH, > Brad > >> On Nov 28, 2016, at 4:59 PM, Sean McBride wrote: >> >> On Fri, 25 Nov 2016 20:55:31 +0000, Lowekamp, Bradley (NIH/NLM/LHC) [C] said: >> >>> I presume you are compiling ITK with shared libraries? >> >> No, as static libraries. >> >>> Would you happen to have a minimal example of ?MyOwnCode.cxx? that >>> reproduces this warning? >> >> I reduced it to a very small Xcode project with only 1 source file. Then I continued to reduce it to just a command line invocation of clang and it stopped reproducing. :( >> >> I soon discovered that between Xcode 6.4 and 7.0 a bug seems to have been introduced where turning on "symbols hidden by default" in the GUI (aka "GCC_SYMBOLS_PRIVATE_EXTERN = YES") doesn't actually pass "-fvisibility=hidden" to clang! >> >> So, for my particular case at least, there is no ITK issue here. Sorry for the noise. >> >> Cheers, >> >> -- >> ____________________________________________________________ >> Sean McBride, B. Eng sean at rogue-research.com >> Rogue Research www.rogue-research.com >> Mac Software Developer Montr?al, Qu?bec, Canada > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Kitware offers ITK Training Courses, for more information visit: > http://kitware.com/products/protraining.php > > Please keep messages on-topic and check the ITK FAQ at: > http://www.itk.org/Wiki/ITK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/insight-developers > > From matt.mccormick at kitware.com Tue Nov 29 15:53:46 2016 From: matt.mccormick at kitware.com (Matt McCormick) Date: Tue, 29 Nov 2016 15:53:46 -0500 Subject: [ITK-dev] -fvisibility=hidden link warnings with GetMetaDataObjectTypeName() In-Reply-To: References: <20161125204726.859979322@mail.rogue-research.com> Message-ID: On Mon, Nov 28, 2016 at 12:14 PM, Isaiah Norton wrote: >> It sorta reminds me of the 'dynamic_cast on Mac OSX' thread, is it >> related? > > > Yes. This is a symptom of the same issue: missing export annotations. Hans > emailed about the same warnings in April (the mailing list archive is > currently down so I can't provide a link, but I can find it in my gmail > folder for insight-dev with a search for "global weak symbol"). This patch: http://review.source.kitware.com/#/c/21805/2/Modules/Core/Common/include/itkArray.h will address the issue. > > On Fri, Nov 25, 2016 at 3:47 PM, Sean McBride > wrote: >> >> Hi all, >> >> I'm trying to rebuild my app and all its C++ libraries with >> -fvisibility=hidden -fvisibility-inlines-hidden. It all builds, but I get 3 >> very similar link warnings building my app; the first is: >> >> ld: warning: direct access in function >> 'itk::MetaDataObject >::GetMetaDataObjectTypeName() >> const' from file 'libITKCommon.a(itkMetaDataObject.cxx.o)' to global weak >> symbol 'typeinfo for itk::Array' from file 'MyOwnCode.o' means the >> weak symbol cannot be overridden at runtime. This was likely caused by >> different translation units being compiled with different visibility >> settings. >> >> I'm using ITK 4.10.1 on OS X 10.11.6 with Xcode 7.3.1 (AppleClang 7.3). >> >> I'm hoping one of you C++ wizards could help me decipher the problem. :) >> It sorta reminds me of the 'dynamic_cast on Mac OSX' thread, is it related? >> >> Thanks, >> >> -- >> ____________________________________________________________ >> Sean McBride, B. Eng sean at rogue-research.com >> Rogue Research www.rogue-research.com >> Mac Software Developer Montr?al, Qu?bec, Canada >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Kitware offers ITK Training Courses, for more information visit: >> http://kitware.com/products/protraining.php >> >> Please keep messages on-topic and check the ITK FAQ at: >> http://www.itk.org/Wiki/ITK_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/insight-developers > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Kitware offers ITK Training Courses, for more information visit: > http://kitware.com/products/protraining.php > > Please keep messages on-topic and check the ITK FAQ at: > http://www.itk.org/Wiki/ITK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/insight-developers > From blowekamp at mail.nih.gov Tue Nov 29 20:58:38 2016 From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C]) Date: Wed, 30 Nov 2016 01:58:38 +0000 Subject: [ITK-dev] -fvisibility=hidden link warnings with GetMetaDataObjectTypeName() In-Reply-To: <20161128215946.318358223@mail.rogue-research.com> References: <20161125204726.859979322@mail.rogue-research.com> <8DB39FAA-F297-4EBB-9560-31C6A97DE43E@mail.nih.gov>, <20161128215946.318358223@mail.rogue-research.com> Message-ID: Sean, One more question, if you have a moment: What is the purpose or goal of adding the hidden visibility flag when building ITK with static libraries? What API are you trying to expose on your "Application"? Thanks, Brad ________________________________________ From: Sean McBride [sean at rogue-research.com] Sent: Monday, November 28, 2016 4:59 PM To: Lowekamp, Bradley (NIH/NLM/LHC) [C] Cc: insight-developers at itk.org Subject: Re: [ITK-dev] -fvisibility=hidden link warnings with GetMetaDataObjectTypeName() On Fri, 25 Nov 2016 20:55:31 +0000, Lowekamp, Bradley (NIH/NLM/LHC) [C] said: >I presume you are compiling ITK with shared libraries? No, as static libraries. >Would you happen to have a minimal example of ?MyOwnCode.cxx? that >reproduces this warning? I reduced it to a very small Xcode project with only 1 source file. Then I continued to reduce it to just a command line invocation of clang and it stopped reproducing. :( I soon discovered that between Xcode 6.4 and 7.0 a bug seems to have been introduced where turning on "symbols hidden by default" in the GUI (aka "GCC_SYMBOLS_PRIVATE_EXTERN = YES") doesn't actually pass "-fvisibility=hidden" to clang! So, for my particular case at least, there is no ITK issue here. Sorry for the noise. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From sean at rogue-research.com Wed Nov 30 12:39:44 2016 From: sean at rogue-research.com (Sean McBride) Date: Wed, 30 Nov 2016 12:39:44 -0500 Subject: [ITK-dev] -fvisibility=hidden link warnings with GetMetaDataObjectTypeName() In-Reply-To: References: <20161125204726.859979322@mail.rogue-research.com> <8DB39FAA-F297-4EBB-9560-31C6A97DE43E@mail.nih.gov>,<20161128215946.31835822 3@mail.rogue-research.com> Message-ID: <20161130173944.2066079195@mail.rogue-research.com> On Wed, 30 Nov 2016 01:58:38 +0000, Lowekamp, Bradley (NIH/NLM/LHC) [C] said: >One more question, if you have a moment: > >What is the purpose or goal of adding the hidden visibility flag when >building ITK with static libraries? What API are you trying to expose on >your "Application"? Brad, Well, for one, it's just best practice to build anything, especially library code like ITK, with -fvisibility=hidden. But my actual motivation was that I started using OpenCV and its build system forces -fvisibility=hidden. This caused link warnings in my app because indeed I had different code built with different visibility settings. So I figured it was time to rebuild all my 3rd party libs with -fvisibility=hidden. Once I did, I still had the 3 link warnings that started this thread, but in the end those 3 were an Xcode bug. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada