[MINC-users] minc "make check" error -- not just a Snow Leopard problem

[Nicolas Kassis]

Hi Claude,

There is an available Mac here in the office we can play with and I
can make it available to your through VNC. A virtual OSX installation
is more work than it's worth ;p (Using OSx86 is which is not optimal).
It would be interesting to be able to make a linux, mac (windows?)
available for build testing. Linux is easy, the mac is a little bit
more work considering we need a physical machine.

Nic

On Thu, Feb 24, 2011 at 12:35 AM, Claude LEPAGE
<claude at bic.mni.mcgill.ca> wrote:
> Hi Andrew,
>
> I compiled minc on snow leopard with Jim on Monday. minc
> seems to work, although make check fails. Failure seems
> to occur while compiling a test program. I suspect a
> problem with a #define or #ifdef that causes different
> code to be compiled. How about a diff of config.h for
> OSX vs Linux? On Linux 32 and 64, the tests compile and
> run to completion, reporting 1 failure out of 7 (not the
> same failure as experienced on OSX). I reproduced the
> same Linux behaviour on CYGWIN. :-) This seems to be an
> OSX specific problem.
>
> I don't have much spare time to look into this. Moreover,
> I don't have access to OSX unless Nic brings his laptop
> to work. Maybe install OSX as a virtual machine on my
> Linux workstation? :-)
>
> Claude
>
>> Hi Jim,
>>
>> > =A0 Here's what seems to be happening:
>> >
>> > (1) Looking at the test volume "t3_grid_0.mnc" we see:
>> >>mincinfo -dimnames t3_grid_0.mnc
>> > vector_dimension zspace yspace xspace
>> >
>> >>mincinfo -varnames t3_grid_0.mnc
>> > rootvariable zspace yspace xspace image-min image-max image
>> >
>> > Note that the "vector_dimension" dimension does not have a matching
>> > variable of that name, whereas the spatial dimensions do.
>>
>> I reckon you are onto something here... I'm surprised this hasn't
>> caused problems as of yet.
>>
>> > Solutions:
>> > (1) a quick and easy solution to the current problem would be to
>> > reconstitute volume "t3_grid_0.mnc" so that it has a VARIABLE called
>> > "vector_dimension"
>> >
>> > (2) since this affects all of David MacDonald's code, we might
>> > consider implementing a rule that, for minc volumes, all dimension
>> > names *must* have a matching variable onto which one could attach
>> > attributes. This is usually indeed the case, but it might be helpful
>> > to make this explicit.
>> >
>> > (3) one could implement code changes to enforce (2), i.e. do not
>> > permit the creation of minc volumes that have dimension names without
>> > matching variable names (David's code already explicitly assumes
>> > this).
>>
>> I'm all for #3. It should not be that hard to fix given that all is
>> required is a few lines of extra code in the output_*_minc functions.
>> We would also have to include some sanity checking in open_volume or
>> perhaps in MINC proper to deal with older volumes that have been
>> created like this.  From my initial look at the code this should not
>> cause a problem with NetCDF/HDF5 interaction when converting a volume.
>>
>> So who wants to do it? :)
>>
>>
>> -- =
>>
>> Andrew Janke
>> (a.janke at gmail.com || http://a.janke.googlepages.com/)
>> Brisbane->Australia    +61 (402) 700 883
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>



-- 
-----------------
Nicolas Kassis