From Andrew Janke <a.janke@gmail.com>  Tue Mar  1 22:13:55 2005
From: Andrew Janke <a.janke@gmail.com> (Andrew Janke)
Date: Wed, 2 Mar 2005 08:13:55 +1000
Subject: [MINC-development] packages.bic.mni.mcgill.ca
Message-ID: <d747ed505030114132a5bd352@mail.gmail.com>

Morning all, 

I would like to push forward on my quest to have a public CVS or
subversion repository for MINC. Also whilst in this process I'd like
to separate out CVS into stuff that is and isn't distributable.

So, we have two options.

   a) do this all on shadow and run two CVS servers?

   b) Transfer all the public packages to packages.bic.mni.mcgill.ca

At this stage this would be: 

   minc
   minc/conversion 
   most of minc_dev
   bicpl
   mni_autoreg
   N3
   mni-acmacros
   ...

Myself I prefer b).  Also what are peoples thoughts on swiching to
subversion as part of this process over cvs?  I am led to beleive that
the two can be interchangeable but haven't investigated this myself.

Thoughts?

-- 
Andrew Janke      (a.janke@gmail.com || www.cmr.uq.edu.au/~rotor)
Australia->Brisbane     H: +61 7 3390 6332  || M: +61 4 2138 8581

From minc-development@bic.mni.mcgill.ca  Wed Mar 16 16:02:15 2005
From: minc-development@bic.mni.mcgill.ca (Vicka Corey)
Date: Wed, 16 Mar 2005 11:02:15 -0500
Subject: [MINC-development] [kteich@nmr.mgh.harvard.edu: [Fsdev] Mac OS X, MNI, and Point]
Message-ID: <20050316160214.GA2750@gate.nmr.mgh.harvard.edu>

we have a type clash....minc osx people, what's the right thing to do?

thanks
--vicka

----- Forwarded message from Kevin Teich <kteich@nmr.mgh.harvard.edu> -----

Date: Tue, 15 Mar 2005 19:13:25 -0500 (EST)
From: Kevin Teich <kteich@nmr.mgh.harvard.edu>
Subject: [Fsdev] Mac OS X, MNI, and Point

So it turns out that MNI defines a type Point. OS X also defines a type 
Point somewhere in their system headers. Normally we just compile with the 
X11 headers, but in compiling a Qt app (Qt/Mac is native Aqua, doesn't run 
in X11 environment) I got a type clash. So I made a copy of the mni/ 
install, pointed the build environment to it, and basically did a bunch of 
s/Point/MniPoint/g in the necessary mni/ header files. Now it compiles.

How should this be handled? Should I contact the MNI developers? Should we 
just use this locally modified installation in the mean time?

-- 
Kevin Teich

_______________________________________________
Fsdev mailing list
Fsdev@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/fsdev

----- End forwarded message -----

From minc-development@bic.mni.mcgill.ca  Wed Mar 16 16:27:04 2005
From: minc-development@bic.mni.mcgill.ca (Robert VINCENT)
Date: Wed, 16 Mar 2005 11:27:04 -0500
Subject: [MINC-development] [kteich@nmr.mgh.harvard.edu: [Fsdev] Mac OS
 X, MNI, and Point]
In-Reply-To: <20050316160214.GA2750@gate.nmr.mgh.harvard.edu>
Message-ID: <Pine.SGI.4.44.0503161119230.2747385-100000@shadow.bic.mni.mcgill.ca>

Hi,

I will be releasing MINC 1.4 within a few days, which will hopefully
provide a solution.  I tried to prefix all typedefs and #defines
with "VIO_", but then in each header there is a block that says:

#ifndef MINC_PLAY_NICE
typedef VIO_<type> <type>
#define VIO_<const> <const>
#endif

This should be backward compatible, but if you include <volume_io.h> with
the new magic "MINC_PLAY_NICE" macro defined, you won't get your namespace
polluted with Point, X, Y, Z, etc.

I can send you a prerelease if you want to give it a try and let me know
if it works before I make it "official".

	-bert

On Wed, 16 Mar 2005, Vicka Corey wrote:

> we have a type clash....minc osx people, what's the right thing to do?
>
> thanks
> --vicka
>
> ----- Forwarded message from Kevin Teich <kteich@nmr.mgh.harvard.edu> -----
>
> Date: Tue, 15 Mar 2005 19:13:25 -0500 (EST)
> From: Kevin Teich <kteich@nmr.mgh.harvard.edu>
> Subject: [Fsdev] Mac OS X, MNI, and Point
>
> So it turns out that MNI defines a type Point. OS X also defines a type
> Point somewhere in their system headers. Normally we just compile with the
> X11 headers, but in compiling a Qt app (Qt/Mac is native Aqua, doesn't run
> in X11 environment) I got a type clash. So I made a copy of the mni/
> install, pointed the build environment to it, and basically did a bunch of
> s/Point/MniPoint/g in the necessary mni/ header files. Now it compiles.
>
> How should this be handled? Should I contact the MNI developers? Should we
> just use this locally modified installation in the mean time?
>
> --
> Kevin Teich
>
> _______________________________________________
> Fsdev mailing list
> Fsdev@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/fsdev
>
> ----- End forwarded message -----
> _______________________________________________
> MINC-development mailing list
> MINC-development@bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development
>


From minc-development@bic.mni.mcgill.ca  Wed Mar 16 18:57:31 2005
From: minc-development@bic.mni.mcgill.ca (Robert VINCENT)
Date: Wed, 16 Mar 2005 13:57:31 -0500
Subject: [MINC-development] minc-1.4-test
In-Reply-To: <20050316170540.GD2750@gate.nmr.mgh.harvard.edu>
Message-ID: <Pine.SGI.4.44.0503161350580.2747385-100000@shadow.bic.mni.mcgill.ca>

Good afternoon,

I've placed a preliminary version of MINC 1.4 at the following URL:

http://www.bic.mni.mcgill.ca/~bert/minc-1.4-test.tar.gz

See the NEWS and ChangeLog for most of the details.  The main
changes are new bimodal threshold calculations in mincstats, a first stab
at a makefile for MSVC and NMAKE on Windows, the "simplified" MINC
programming interface, and a set of converters for NIfTI-1/Analyze, ECAT,
and microPET data (still working on DICOM...)

Perhaps the most useful feature for the FreeSurfer people should be the
ability to get rid of all or at least most of the egregious namespace
pollution in your code by defining:

#define MINC_PLAY_NICE 1

before including minc.h or volume_io.h

Of course this is preliminary software, your mileage may vary, etc.

	-bert

On Wed, 16 Mar 2005, Vicka Corey wrote:

> hi bert -- yes, please, could you send a prerelease to kevin?
> his address is kteich@nmr.mgh.harvard.edu.
>
> many thanks,
> --vicka
>
> ----- Forwarded message from Kevin Teich <kteich@nmr.mgh.harvard.edu> -----
>
> X-Authentication-Warning: entry.nmr.mgh.harvard.edu: kteich owned process doing -bs
> Date: Wed, 16 Mar 2005 11:41:30 -0500 (EST)
> From: Kevin Teich <kteich@nmr.mgh.harvard.edu>
> To: Vicka Corey <vicka@nmr.mgh.harvard.edu>
> cc: fsdev@nmr.mgh.harvard.edu
> Subject: Re: [bert@bic.mni.mcgill.ca: Re: [MINC-development] [kteich@nmr.mgh.harvard.edu:
>  [Fsdev] Mac OS X, MNI, and Point]]
> In-Reply-To: <20050316163209.GC2750@gate.nmr.mgh.harvard.edu>
> X-NMR-MGH-MailScanner-Information: Please contact the ISP for more information
> X-NMR-MGH-MailScanner: Found to be clean
> X-NMR-MGH-MailScanner-SpamCheck: not spam, SpamAssassin (score=-100,
> 	required 5, USER_IN_WHITELIST -100.00)
> X-MailScanner-From: kteich@nmr.mgh.harvard.edu
>
> Yeah, that'd be great, thanks.
>
>
> On Wed, 16 Mar 2005, Vicka Corey wrote:
>
> >here's the response from mni.  kevin, do you want to get a prerelease?
> >
> >--vicka
> >
> >----- Forwarded message from Robert VINCENT <bert@bic.mni.mcgill.ca> -----
> >
> >From: Robert VINCENT <bert@bic.mni.mcgill.ca>
> >To: minc-development@bic.mni.mcgill.ca
> >Subject: Re: [MINC-development] [kteich@nmr.mgh.harvard.edu: [Fsdev] Mac OS
> >X, MNI, and Point]
> >
> >Hi,
> >
> >I will be releasing MINC 1.4 within a few days, which will hopefully
> >provide a solution.  I tried to prefix all typedefs and #defines
> >with "VIO_", but then in each header there is a block that says:
> >
> >#ifndef MINC_PLAY_NICE
> >typedef VIO_<type> <type>
> >#define VIO_<const> <const>
> >#endif
> >
> >This should be backward compatible, but if you include <volume_io.h> with
> >the new magic "MINC_PLAY_NICE" macro defined, you won't get your namespace
> >polluted with Point, X, Y, Z, etc.
> >
> >I can send you a prerelease if you want to give it a try and let me know
> >if it works before I make it "official".
> >
> >	-bert
> >
> >On Wed, 16 Mar 2005, Vicka Corey wrote:
> >
> >>we have a type clash....minc osx people, what's the right thing to do?
> >>
> >>thanks
> >>--vicka
> >>
> >>----- Forwarded message from Kevin Teich <kteich@nmr.mgh.harvard.edu> -----
> >>
> >>Date: Tue, 15 Mar 2005 19:13:25 -0500 (EST)
> >>From: Kevin Teich <kteich@nmr.mgh.harvard.edu>
> >>Subject: [Fsdev] Mac OS X, MNI, and Point
> >>
> >>So it turns out that MNI defines a type Point. OS X also defines a type
> >>Point somewhere in their system headers. Normally we just compile with the
> >>X11 headers, but in compiling a Qt app (Qt/Mac is native Aqua, doesn't run
> >>in X11 environment) I got a type clash. So I made a copy of the mni/
> >>install, pointed the build environment to it, and basically did a bunch of
> >>s/Point/MniPoint/g in the necessary mni/ header files. Now it compiles.
> >>
> >>How should this be handled? Should I contact the MNI developers? Should we
> >>just use this locally modified installation in the mean time?
> >>
> >>--
> >>Kevin Teich
> >>
> >>_______________________________________________
> >>Fsdev mailing list
> >>Fsdev@nmr.mgh.harvard.edu
> >>https://mail.nmr.mgh.harvard.edu/mailman/listinfo/fsdev
> >>
> >>----- End forwarded message -----
> >>_______________________________________________
> >>MINC-development mailing list
> >>MINC-development@bic.mni.mcgill.ca
> >>http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development
> >>
> >
> >_______________________________________________
> >MINC-development mailing list
> >MINC-development@bic.mni.mcgill.ca
> >http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development
> >
> >----- End forwarded message -----
> >_______________________________________________
> >Fsdev mailing list
> >Fsdev@nmr.mgh.harvard.edu
> >https://mail.nmr.mgh.harvard.edu/mailman/listinfo/fsdev
> >
>
> --
> Kevin Teich
>
> ----- End forwarded message -----
>



From Andrew Janke <a.janke@gmail.com>  Mon Mar 21 16:08:23 2005
From: Andrew Janke <a.janke@gmail.com> (Andrew Janke)
Date: Tue, 22 Mar 2005 02:08:23 +1000
Subject: [MINC-development] Fwd: xdisp -- For the brave
In-Reply-To: <d747ed50503210801696822c0@mail.gmail.com>
References: <d747ed50503210801696822c0@mail.gmail.com>
Message-ID: <d747ed50503210808279f3e35@mail.gmail.com>

   http://packages.bic.mni.mcgill.ca/tgz/xdisp-4.5.tar.gz

You will have to add in your own version of EZWGL, it is in CVS but
not in the distro.  I am looking into the best way to get around this.

--
Andrew Janke      (a.janke@gmail.com || www.cmr.uq.edu.au/~rotor)
Australia->Brisbane     H: +61 7 3390 6332  || M: +61 4 2138 8581

From minc-development@bic.mni.mcgill.ca  Thu Mar 31 05:18:59 2005
From: minc-development@bic.mni.mcgill.ca (minc-development@bic.mni.mcgill.ca)
Date: Thu, 31 Mar 2005 00:18:59 -0500
Subject: [MINC-development] [kteich@nmr.mgh.harvard.edu: [Fsdev] Mac OS X,
 MNI, and Point]
In-Reply-To: <Pine.SGI.4.44.0503161119230.2747385-100000@shadow.bic.mni.mcgill.ca>
References: <20050316160214.GA2750@gate.nmr.mgh.harvard.edu>
 <Pine.SGI.4.44.0503161119230.2747385-100000@shadow.bic.mni.mcgill.ca>
Message-ID: <20050331051859.GB5459@nyongwa.montreal.qc.ca>

On Wed, Mar 16, 2005 at 11:27:04AM -0500, Robert VINCENT wrote:
> Hi,
> 
> I will be releasing MINC 1.4 within a few days, which will hopefully
> provide a solution.  I tried to prefix all typedefs and #defines
> with "VIO_", 

Yay!!!

> but then in each header there is a block that says:
> 
> #ifndef MINC_PLAY_NICE
> typedef VIO_<type> <type>
> #define VIO_<const> <const>
> #endif
> 
> This should be backward compatible, but if you include <volume_io.h> with
> the new magic "MINC_PLAY_NICE" macro defined, you won't get your namespace
> polluted with Point, X, Y, Z, etc.

I think the idea of providing a backwards compatibility mode is a good
one.  However, if I may nitpick, MINC_PLAY_NICE doesn't strike me as
an intuitive name for this mode.  What about something like
VIO_USE_NAMESPACE?

Incidentally, many folks prefer to test that a symbol is set to
"true" rather than just set; i.e. use

    #if !VIO_USE_NAMESPACE
    typedef ...
    #endif

Then the user can compile with -DVIO_USE_NAMESPACE=0
or -DVIO_USE_NAMESPACE=1.  Symbols not defined evaluate to "false",
so the default behaviour is the backwards-compatible mode of
NOT using the VIO namespace.

When you want to switch the out-of-the-box behaviour, you
could put

    #ifndef VIO_USE_NAMESPACE
    #define VIO_USE_NAMESPACE 1
    #endif

into volume_io.h while still allowing the programmer to
explicitly choose the mode.


Regards,
-Steve

From minc-development@bic.mni.mcgill.ca  Thu Mar 31 05:18:59 2005
From: minc-development@bic.mni.mcgill.ca (Steve M. Robbins)
Date: Thu, 31 Mar 2005 00:18:59 -0500
Subject: [MINC-development] [kteich@nmr.mgh.harvard.edu: [Fsdev] Mac OS X,
 MNI, and Point]
In-Reply-To: <Pine.SGI.4.44.0503161119230.2747385-100000@shadow.bic.mni.mcgill.ca>
References: <20050316160214.GA2750@gate.nmr.mgh.harvard.edu>
 <Pine.SGI.4.44.0503161119230.2747385-100000@shadow.bic.mni.mcgill.ca>
Message-ID: <20050331051859.GB5459@nyongwa.montreal.qc.ca>

On Wed, Mar 16, 2005 at 11:27:04AM -0500, Robert VINCENT wrote:
> Hi,
> 
> I will be releasing MINC 1.4 within a few days, which will hopefully
> provide a solution.  I tried to prefix all typedefs and #defines
> with "VIO_", 

Yay!!!

> but then in each header there is a block that says:
> 
> #ifndef MINC_PLAY_NICE
> typedef VIO_<type> <type>
> #define VIO_<const> <const>
> #endif
> 
> This should be backward compatible, but if you include <volume_io.h> with
> the new magic "MINC_PLAY_NICE" macro defined, you won't get your namespace
> polluted with Point, X, Y, Z, etc.

I think the idea of providing a backwards compatibility mode is a good
one.  However, if I may nitpick, MINC_PLAY_NICE doesn't strike me as
an intuitive name for this mode.  What about something like
VIO_USE_NAMESPACE?

Incidentally, many folks prefer to test that a symbol is set to
"true" rather than just set; i.e. use

    #if !VIO_USE_NAMESPACE
    typedef ...
    #endif

Then the user can compile with -DVIO_USE_NAMESPACE=0
or -DVIO_USE_NAMESPACE=1.  Symbols not defined evaluate to "false",
so the default behaviour is the backwards-compatible mode of
NOT using the VIO namespace.

When you want to switch the out-of-the-box behaviour, you
could put

    #ifndef VIO_USE_NAMESPACE
    #define VIO_USE_NAMESPACE 1
    #endif

into volume_io.h while still allowing the programmer to
explicitly choose the mode.


Regards,
-Steve

From minc-development@bic.mni.mcgill.ca  Thu Mar 31 15:37:10 2005
From: minc-development@bic.mni.mcgill.ca (Robert VINCENT)
Date: Thu, 31 Mar 2005 10:37:10 -0500
Subject: [MINC-development] [kteich@nmr.mgh.harvard.edu: [Fsdev] Mac OS
 X, MNI, and Point]
In-Reply-To: <20050331051859.GB5459@nyongwa.montreal.qc.ca>
Message-ID: <Pine.SGI.4.44.0503311036330.3884074-100000@shadow.bic.mni.mcgill.ca>

Hi Steve,

That's a fine suggestion.  I'll change it before the "real" release.

Thanks,

	-bert

On Thu, 31 Mar 2005, Steve M. Robbins wrote:

> On Wed, Mar 16, 2005 at 11:27:04AM -0500, Robert VINCENT wrote:
> > Hi,
> >
> > I will be releasing MINC 1.4 within a few days, which will hopefully
> > provide a solution.  I tried to prefix all typedefs and #defines
> > with "VIO_",
>
> Yay!!!
>
> > but then in each header there is a block that says:
> >
> > #ifndef MINC_PLAY_NICE
> > typedef VIO_<type> <type>
> > #define VIO_<const> <const>
> > #endif
> >
> > This should be backward compatible, but if you include <volume_io.h> with
> > the new magic "MINC_PLAY_NICE" macro defined, you won't get your namespace
> > polluted with Point, X, Y, Z, etc.
>
> I think the idea of providing a backwards compatibility mode is a good
> one.  However, if I may nitpick, MINC_PLAY_NICE doesn't strike me as
> an intuitive name for this mode.  What about something like
> VIO_USE_NAMESPACE?
>
> Incidentally, many folks prefer to test that a symbol is set to
> "true" rather than just set; i.e. use
>
>     #if !VIO_USE_NAMESPACE
>     typedef ...
>     #endif
>
> Then the user can compile with -DVIO_USE_NAMESPACE=0
> or -DVIO_USE_NAMESPACE=1.  Symbols not defined evaluate to "false",
> so the default behaviour is the backwards-compatible mode of
> NOT using the VIO namespace.
>
> When you want to switch the out-of-the-box behaviour, you
> could put
>
>     #ifndef VIO_USE_NAMESPACE
>     #define VIO_USE_NAMESPACE 1
>     #endif
>
> into volume_io.h while still allowing the programmer to
> explicitly choose the mode.
>
>
> Regards,
> -Steve
> _______________________________________________
> MINC-development mailing list
> MINC-development@bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development
>