Hi Kent,
I noticed that the change 966fcb62c859229f9b421403c4faf3e6ef5e2b81 included the
line:
metaDict-Clear();
to the function ReadImageInformation from itkPhilipsRECImageIO.cxx.
This gives a compile error:
Marius,
I also just discovered this on a system I have not build on for a
while. Must be the only system I have with Philips IO turned on.
I'll submit a gerrit patch. Actually, thisDic-Clear() should be
thisDic.Clear().
Bill
On Tue, Dec 18, 2012 at 5:08 AM, m.star...@lumc.nl wrote:
Hi Kent,
Matt,
Marius Staring just reported that PhilipRECImageIO does not compile.
Apparently, none of our dashboards have it enabled. I verified it this
morning on one of my systems. I have fixed the problem and submited a
gerrit patch: http://review.source.kitware.com/#/c/8979/
Once approved, this
Hi Bill, Marius,
Thanks for identifying the error and the patch.
Yes, we should definitely have the code tested on the dashboard if we want
this class to work.
The 4.3.0 tag has already been pushed, and it cannot be changed. I can
make a 4.3.1 release on Friday.
Thanks,
Matt
On Tue, Dec 18,
Hello,
I was looking to pass some CMake variable from my SimpleITK superbuild down to
the ITK external project build. So I assembled a list for cmake varaibles that
began with ITK_:
get_cmake_property( _varNames VARIABLES )
foreach (_varName ${_varNames})
if(_varName MATCHES ^ITK_ )
Mea Maxima Culpa. This was meant to fix a problem where re-use of ImageIO
objects was putting metadata from one file read into the next file read.
I should have caught this but like you I didn't have PHilipsRecImageIO
turned on.
Is there a good reason not to have this ON by default? And I'm
I think it is not on be default because it seems to have limited usage.
On Tue, Dec 18, 2012 at 10:48 AM, Williams, Norman K
norman-k-willi...@uiowa.edu wrote:
Mea Maxima Culpa. This was meant to fix a problem where re-use of ImageIO
objects was putting metadata from one file read into the next
On Tue, 18 Dec 2012 15:48:40 +, Williams, Norman K said:
I should have caught this but like you I didn't have PHilipsRecImageIO
turned on.
Is there a good reason not to have this ON by default? And I'm all for
making all the factory builds turn on everything that's practical to turn
on.
I think you're exactly right. Those variables are named the way they are
because when I chose those names USE_something names were all over the
place. As we've all progressed as developers and refined the conventions
used in ITK, things like that have gone away.
I see no reason not to change
Kent,
I'd also like to point out that we have had two release candidates since this
patch was merged. So the community also was not able to detect this bug since
then either.
Brad
On Dec 18, 2012, at 10:48 AM, Williams, Norman K
norman-k-willi...@uiowa.edu wrote:
Mea Maxima Culpa. This
Sean,
It is not on by default.
Bill
On Tue, Dec 18, 2012 at 11:11 AM, Sean McBride s...@rogue-research.com wrote:
On Tue, 18 Dec 2012 15:48:40 +, Williams, Norman K said:
I should have caught this but like you I didn't have PHilipsRecImageIO
turned on.
Is there a good reason not to have
I agree that they should follow a consistent style, but an attempt at
backwards compatibility should be made. Those variables are hard set in
many people's ExternalProject's, build scripts, etc.
Matt
On Tue, Dec 18, 2012 at 4:25 PM, Williams, Norman K
norman-k-willi...@uiowa.edu wrote:
I
My gerrit patch: http://review.source.kitware.com/#/c/8951/ addresses
prevention of duplicate dynamic libraries. But it need review. I'm not
sure if it merits inclusion in 4.3.1.
On Tue, Dec 18, 2012 at 1:42 PM, Jean-Christophe Fillion-Robin
jchris.filli...@kitware.com wrote:
Hi Matt,
If there
Hi all,
I have created a Google Event within the ITK BarCamp Google+ Community:
https://plus.google.com/u/0/events/cb0tnl4sa36i3jh3ma1imnc922s?authkey=CKK1ktSWua3ZeQ
And a Google Doc:
https://docs.google.com/document/d/1i2ibaZMS_vxzLocGVeElz6t5DVF7CWHfyFrB2WldF1c/edit#heading=h.r7h4uqn8p8ld
Hi Jc, Sascha, Nolden,
Thank you very much for the link and discussion! Very interesting!
The library appears to solve many issues we have been struggling with
or need to solve.
The fact that it is small, C++, Apache 2.0 licensed, compact, tightly
focused, feature-rich, and well vetted are all
You are correct. I thought was the issue we had with Slicer, that each
CLI was loading run-times. What are the duplicates we saw in Slicer
and is there a similar preventive measure we can take.
Bill
On Tue, Dec 18, 2012 at 2:35 PM, Bradley Lowekamp
blowek...@mail.nih.gov wrote:
Bill,
Bill,
Indeed. But what I meant is that the name ITK_BUILD_ALL_MODULES is rather
deceptive (reminds me of -Wall). Perhaps it should be named
ITK_BUILD_MOST_MODULES or ITK_BUILD_COMMON_MODULES is what I was getting at.
Sean
On Tue, 18 Dec 2012 12:02:38 -0500, Bill Lorensen said:
Sean,
It
Maybe it should be BUILD_DEFAULT_MODULES?
I agree that BUILD_ALL_MODULES is deceptive.
On Tue, Dec 18, 2012 at 5:13 PM, Sean McBride s...@rogue-research.com wrote:
Bill,
Indeed. But what I meant is that the name ITK_BUILD_ALL_MODULES is rather
deceptive (reminds me of -Wall). Perhaps it
BUILD_ALL_MODULES really has turned into just the defaults ones and I am not
sure that is should change much.
What is really needed is to turn everything on for dashboards and robots.
I wonder if we could use a new variable... say BUILD_ALL (similar to
BUILD_TESTING, BUILD_EXAMPLES etc..), but
+1 to renaming BUILD_ALL_MODULES to BUILD_DEFAULT_MODULES for clarity.
+1 to an unexposed BUILD_ALL variable that is enabled for all
dashboard builds. I think we should also then turn BUILD_TESTING and
BUILD_EXAMPLES OFF by default. A bad impression is made on many
beginners by the time a stock
Thanks for the feedback, Sascha. Forwarding to insight-developers...
On Tue, Dec 18, 2012 at 6:38 PM, Sascha Zelzer
s.zel...@dkfz-heidelberg.de wrote:
Hi Matt,
please see my comments inline.
On 12/18/2012 09:10 PM, Matt McCormick wrote:
I would be interested to get your opinion on the
21 matches
Mail list logo
