From a.janke at gmail.com Thu Jan 10 07:25:18 2008 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 10 Jan 2008 23:25:18 +1100 Subject: [MINC-development] bug in emma's miwriteimages In-Reply-To: <472F979A.3000204@bic.mni.mcgill.ca> References: <472F979A.3000204@bic.mni.mcgill.ca> Message-ID: On Nov 6, 2007 9:22 AM, Michael Ferreira wrote: > Hi Minc-developers, > > There's a small, annoying bug in the compiled binary of emma's > miwriteimages that people are running into a lot these days. This is an > error message obtained when creating a file that has more than 160 slices: > > Error: Too many slices specified (max 160) Hi Mike, Did you ever get any more resolution on this? In any case I have updated the version of emma in CVS (for both read and write) to 256. Previously there was a limit of 256 for reading also. Let me know how the version in cvs -d cvs.bic.mni.mcgill.ca/private-cvsroot co emma/emma goes. If all is good I see no reason as to why we cannot make another point release. Thanks a From richard.beare at gmail.com Thu Jan 10 17:16:57 2008 From: richard.beare at gmail.com (Richard Beare) Date: Fri, 11 Jan 2008 09:16:57 +1100 Subject: [MINC-development] multi-architecture builds of minc2 on OSX Message-ID: <779dabeb0801101416k49ffd2a1ofe1207dd4c3149d9@mail.gmail.com> Hi, I suspect this isn't a major problem for most people, but it does cause slight headaches. If I attempt to build a combined 32/64 bit library using the following configure command: (export CFLAGS="-arch i386 -arch x86_64 -I/opt/local/include"; export LDFLAGS="-arch i386 -arch x86_64 -L/opt/local/lib";./configure --enable-minc2) I get this error: gcc -DHAVE_CONFIG_H -I. -I./libsrc -I./volume_io/Include -I./volume_io/Include -I./progs/Proglib -I./conversion/Acr_nema -I./libsrc2 -arch i386 -arch x86_64 -I/opt/local/include -MT libsrc/ParseArgv.lo -MD -MP -MF libsrc/.deps/ParseArgv.Tpo -c libsrc/ParseArgv.c -o libsrc/ParseArgv.o gcc-4.0: -E, -S, -save-temps and -M options are not allowed with multiple -arch flags looks like some minor configure tweaks should fix things. I've created the 32 and 64 bit libraries separately and merged them. From steve at sumost.ca Fri Jan 11 00:56:07 2008 From: steve at sumost.ca (Steve M. Robbins) Date: Thu, 10 Jan 2008 23:56:07 -0600 Subject: [MINC-development] minc 2.0.14 issues Message-ID: <20080111055607.GY7777@sumost.ca> Hi, Just to let you know, I've recently uploaded MINC 2.0.14 to Debian. There's an active project to get all kinds of medical imaging software into Debian; see http://wiki.debian.org/DebianMedImaging. FSL is in, and there is interest in AFNI, Caret, and FreeSurfer. Since the latter is built on MINC, work was started on a number of BIC packages, including mni_autoreg and N3. Since Andrew says 2.0.15 is imminent, I thought I'd share a couple of issues that have come up, in case you're not closely following the Debian packaging effort (http://packages.qa.debian.org/m/minc.html). 1. The 2.0.14 upload failed to build on Arm and on Sparc. See http://buildd.debian.org/build.php?pkg=minc for build logs. The failures are in test cases in libsrc2/test. I will poke around, but if you have any hints for me: I'm all ears. 2. I built MINC using --enable-acr-nema for the first time, and discovered that it produces a program named "extract" that simply extracts bytes from the middle of the input. Unfortunately, this name clashes with a pre-existing software package that has more claim to the name (http://bugs.debian.org/459834). Fortunately, it looks to me like MINC's extract can be replaced by "dd". So I plan to solve this by removing "extract" from Debian's package. The same goes for byte_swap. Maybe they can be removed completely? Is anyone really using these tools (and can't switch to using dd)? 3. I notice now that --enable-acr-nema installs libacr_nema, which is not versioned. It should be versioned the same manner as libminc and libvolume_io. 4. It turns out that one should build using -mieee on Alpha (http://bugs.debian.org/368263). Cheers, -Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.bic.mni.mcgill.ca/pipermail/minc-development/attachments/20080111/33788534/attachment.bin From steve at sumost.ca Fri Jan 11 03:01:25 2008 From: steve at sumost.ca (Steve M. Robbins) Date: Fri, 11 Jan 2008 02:01:25 -0600 Subject: [MINC-development] clearing compile warnings Message-ID: <20080111080125.GZ7777@sumost.ca> Hi, Since I hear that 2.0.15 is imminent, I thought I'd see if I can remove some of the warnings emitted by gcc -Wall in hopes of having it build on sparc and arm. I committed changes to remove unused variables. There are also a number of unhandled cases in switch statements. Attached is a patch that clears some of them, for your consideration. Is logging an error message in MI_TO_DOUBLE / MI_FROM_DOUBLE kosher? In the minc_convenience patch? Regards -Steve Index: libsrc/minc_basic.h =================================================================== RCS file: /private-cvsroot/minc/libsrc/minc_basic.h,v retrieving revision 6.4 diff -u -b -B -r6.4 minc_basic.h --- libsrc/minc_basic.h 9 Aug 2007 17:05:25 -0000 6.4 +++ libsrc/minc_basic.h 11 Jan 2008 07:52:31 -0000 @@ -66,6 +66,8 @@ @RCSID : $Header: /private-cvsroot/minc/libsrc/minc_basic.h,v 6.4 2007/08/09 17:05:25 rotor Exp $ MINC (MNI) ---------------------------------------------------------------------------- */ +#include + /* --------- MINC specific constants ------------- */ /* Maximum buffer size for conversions. Should not be a power of 2 - this @@ -129,6 +131,7 @@ #define MI_TO_DOUBLE(dvalue, type, sign, ptr) \ switch (type) { \ case NC_BYTE : \ + case NC_CHAR : \ switch (sign) { \ case MI_PRIV_UNSIGNED : \ dvalue = (double) *((unsigned char *) ptr); break; \ @@ -158,11 +161,17 @@ case NC_DOUBLE : \ dvalue = (double) *((double *) ptr); \ break; \ + case NC_NAT : \ + MI_LOG_PKG_ERROR2(MI_ERR_NONNUMERIC, \ + "Attempt to convert NC_NAT value to double"); \ + dvalue = 0; \ + break; \ } #define MI_FROM_DOUBLE(dvalue, type, sign, ptr) \ switch (type) { \ case NC_BYTE : \ + case NC_CHAR : \ switch (sign) { \ case MI_PRIV_UNSIGNED : \ dvalue = MAX(0, dvalue); \ @@ -211,6 +220,11 @@ case NC_DOUBLE : \ *((double *) ptr) = dvalue; \ break; \ + case NC_NAT : \ + MI_LOG_PKG_ERROR2(MI_ERR_NONNUMERIC, \ + "Attempt to convert to NC_NAT value from double"); \ + dvalue = 0; \ + break; \ } /**/ Index: libsrc/minc_convenience.c =================================================================== RCS file: /private-cvsroot/minc/libsrc/minc_convenience.c,v retrieving revision 6.19 diff -u -b -B -r6.19 minc_convenience.c --- libsrc/minc_convenience.c 3 Dec 2007 14:19:35 -0000 6.19 +++ libsrc/minc_convenience.c 11 Jan 2008 07:59:42 -0000 @@ -315,6 +315,12 @@ if (miget_datatype(cdfid, imgid, &datatype, &is_signed) == MI_ERROR) MI_RETURN(MI_ERROR); + if ( datatype == NC_NAT ) { + MI_LOG_PKG_ERROR2(MI_ERR_NONNUMERIC, + "Attempt to get valid range from NC_NAT variable"); + MI_RETURN(MI_ERROR); + } + /* Save the ncopts value */ old_ncopts = ncopts; ncopts = 0; @@ -364,6 +370,7 @@ case NC_INT: case NC_SHORT: case NC_BYTE: + case NC_CHAR: if (is_signed) { valid_range[0] = (int) valid_range[0]; valid_range[1] = (int) valid_range[1]; @@ -377,6 +384,12 @@ valid_range[0] = (float) valid_range[0]; valid_range[1] = (float) valid_range[1]; break; + /* NC_DOUBLE is no-op, but include case to let compiler know we thought about it. */ + case NC_DOUBLE: + break; + /* NC_NAT should have been handled at start of this routine. */ + case NC_NAT: + MI_RETURN(MI_ERROR); } MI_RETURN(MI_NOERROR); -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.bic.mni.mcgill.ca/pipermail/minc-development/attachments/20080111/79f387fa/attachment.bin From a.janke at gmail.com Fri Jan 11 04:49:49 2008 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 11 Jan 2008 20:49:49 +1100 Subject: [MINC-development] fortran and MINC Message-ID: Would anyone have any serious objections if I removed this from the MINC distribution? It is not maintained, not up to date and contains code with copyrights from other places (notably unidata) whose licences I suspect (but dont know) we may not be respecting. In any case I think it should be removed from all minc2 builds. -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883 From a.janke at gmail.com Fri Jan 11 20:09:58 2008 From: a.janke at gmail.com (Andrew Janke) Date: Sat, 12 Jan 2008 12:09:58 +1100 Subject: [MINC-development] clearing compile warnings In-Reply-To: <20080111080125.GZ7777@sumost.ca> References: <20080111080125.GZ7777@sumost.ca> Message-ID: > Since I hear that 2.0.15 is imminent, I thought I'd see if I can > remove some of the warnings emitted by gcc -Wall in hopes of having it > build on sparc and arm. > > I committed changes to remove unused variables. Oh? I didnt see these. Perhaps I was looking in the wrong places. Either that or did you mean the rcsid vars? > There are also a number of unhandled cases in switch > statements. Aye, these seem to become more and more prevalent with each new release of Netcdf/HDF5. > Attached is a patch that clears some of them, > for your consideration. Is logging an error message > in MI_TO_DOUBLE / MI_FROM_DOUBLE kosher? I would think so. I didnt even know they had come up with a NC_NAT "type". > In the minc_convenience patch? This one I am not so sure of. Of course this as you well know is only the tip of the iceberg of warnings... :) Perhaps a concerted effort one night on my behalf could hunt down all the others... I would be willing to do this for the MINC library itself but see little point in persevering for all the older volume_io and contributed progs stuff. Perhaps in time. a From steve at sumost.ca Sat Jan 12 13:49:57 2008 From: steve at sumost.ca (Steve M. Robbins) Date: Sat, 12 Jan 2008 12:49:57 -0600 Subject: [MINC-development] clearing compile warnings In-Reply-To: References: <20080111080125.GZ7777@sumost.ca> Message-ID: <20080112184957.GA7777@sumost.ca> On Sat, Jan 12, 2008 at 12:09:58PM +1100, Andrew Janke wrote: > > Since I hear that 2.0.15 is imminent, I thought I'd see if I can > > remove some of the warnings emitted by gcc -Wall in hopes of having it > > build on sparc and arm. > > > > I committed changes to remove unused variables. > > Oh? I didnt see these. I felt those changes would be uncontroversial, so I committed them before sending the e-mail. Using "cvs diff -d '1 week ago'" should reveal them to you. > Either that or did you mean the rcsid vars? No, I didn't touch those. My initial inclination was to rip them out, but not before asking so thanks for the poke on the "geeks" list. I don't see any need for them, myself. As you point out on the "geeks" list, we have "-version" for most (if not all) programs. If removing them is controversial, I had planned to attach __attribute__ unused [1] to all of them. That at least shuts up the gcc warning. > > There are also a number of unhandled cases in switch > > statements. > > Aye, these seem to become more and more prevalent with each new > release of Netcdf/HDF5. > > > Attached is a patch that clears some of them, > > for your consideration. Is logging an error message > > in MI_TO_DOUBLE / MI_FROM_DOUBLE kosher? > > I would think so. I didnt even know they had come up with a NC_NAT "type". Thanks for applying this to the sources. > > In the minc_convenience patch? > > This one I am not so sure of. OK. What issue do you see with it? > Of course this as you well know is only > the tip of the iceberg of warnings... :) Yes. I started with some low-hanging fruit. There are a number of more serious ones that I plan to get at in the coming days. If you and others start looking at them, we'll get through them even more quickly! -Steve [1] http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Variable-Attributes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.bic.mni.mcgill.ca/pipermail/minc-development/attachments/20080112/1a6bffd0/attachment.bin From steve at sumost.ca Sat Jan 12 14:16:54 2008 From: steve at sumost.ca (Steve M. Robbins) Date: Sat, 12 Jan 2008 13:16:54 -0600 Subject: [MINC-development] clearing compile warnings In-Reply-To: <20080112184957.GA7777@sumost.ca> References: <20080111080125.GZ7777@sumost.ca> <20080112184957.GA7777@sumost.ca> Message-ID: <20080112191654.GB7777@sumost.ca> On Sat, Jan 12, 2008 at 12:49:57PM -0600, Steve M. Robbins wrote: > If removing them is controversial, I had planned to attach > __attribute__ unused [1] to all of them. That at least shuts > up the gcc warning. OK, I still favour removing rcsid, but I went ahead and did this for now. If this causes trouble with some other compiler, let me know and I can revert them all fairly easily. -Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.bic.mni.mcgill.ca/pipermail/minc-development/attachments/20080112/be63bfd0/attachment.bin From a.janke at gmail.com Wed Jan 16 11:29:12 2008 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 17 Jan 2008 03:29:12 +1100 Subject: [MINC-development] clearing compile warnings In-Reply-To: <20080112191654.GB7777@sumost.ca> References: <20080111080125.GZ7777@sumost.ca> <20080112184957.GA7777@sumost.ca> <20080112191654.GB7777@sumost.ca> Message-ID: > OK, I still favour removing rcsid, but I went ahead and did this for > now. If this causes trouble with some other compiler, let me know and > I can revert them all fairly easily. Most pretty. Although I am more than happy to just bonk them. No-one has whinged (or knew what they did). I note a number of ^L's have crept in as of late in the MINC source... You dont happen to be using a (cuss spit) Windows machine for CVS do you? :) a From peter.neelin at gmail.com Wed Jan 16 23:40:18 2008 From: peter.neelin at gmail.com (Peter Neelin) Date: Wed, 16 Jan 2008 23:40:18 -0500 Subject: [MINC-development] clearing compile warnings In-Reply-To: References: <20080111080125.GZ7777@sumost.ca> <20080112184957.GA7777@sumost.ca> <20080112191654.GB7777@sumost.ca> Message-ID: On 1/16/08, Andrew Janke wrote: > > OK, I still favour removing rcsid, but I went ahead and did this for > > now. If this causes trouble with some other compiler, let me know and > > I can revert them all fairly easily. > > Although I am more than happy to just bonk them. No-one has whinged > (or knew what they did). My goodness you guys are cautious! As far as I know, I'm the only one who ever cared about those and (as Steve knows) rcsid is a habit I lost a long time ago. It was useful before -version and for tracking problems in other people's binaries, but I haven't string'ed for those in a very long time (a decade or more, perhaps) and I doubt that anyone else has either. Please zap them (or bonk if you prefer)! BTW, happy decade-and-a-half of MINC. Peter -- Peter Neelin (peter.neelin at gmail.com) From a.janke at gmail.com Thu Jan 17 06:34:44 2008 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 17 Jan 2008 22:34:44 +1100 Subject: [MINC-development] minc 2.0.14 issues In-Reply-To: <20080111055607.GY7777@sumost.ca> References: <20080111055607.GY7777@sumost.ca> Message-ID: > Just to let you know, I've recently uploaded MINC 2.0.14 to Debian. > There's an active project to get all kinds of medical imaging software > into Debian; see http://wiki.debian.org/DebianMedImaging. FSL is in, > and there is interest in AFNI, Caret, and FreeSurfer. Since the > latter is built on MINC, work was started on a number of BIC packages, > including mni_autoreg and N3. I presume you are talking about Michael Hanke here. I have been in contact with him a few times about this and the plan is to join build forces. He is apparently busy until feb though so I was happy to leave it until them. I dont think there is a ITP for them yet though? > Since Andrew says 2.0.15 is imminent, I thought I'd share a couple of > issues that have come up, in case you're not closely following the > Debian packaging effort (http://packages.qa.debian.org/m/minc.html). > 1. The 2.0.14 upload failed to build on Arm and on Sparc. See > http://buildd.debian.org/build.php?pkg=minc for build logs. The > failures are in test cases in libsrc2/test. I will poke around, but > if you have any hints for me: I'm all ears. I am more than keen to get things right upstream. I note there are a number of patches in the deb build. I presume you will commit these upstream also? I have been also working on removing all instances of (t)csh in MINC in order to make things work nice on OSX/etc. This should clean up at least one dependency. I suspect i will convert mincview to perl as opposed to sh given the lack of ARRAY variables unless you resort to bash. mincview should in any case be not much more than a wrapper around mincpik with a bit more work on mincpik to get it to output a range of images slices. > 2. I built MINC using --enable-acr-nema for the first time, and > discovered that it produces a program named "extract" that simply > extracts bytes from the middle of the input. Unfortunately, this name > clashes with a pre-existing software package that has more claim to > the name (http://bugs.debian.org/459834). Fortunately, it looks to me > like MINC's extract can be replaced by "dd". So I plan to solve this > by removing "extract" from Debian's package. The same goes for > byte_swap. Maybe they can be removed completely? Is anyone really > using these tools (and can't switch to using dd)? I would go further than this. I see no reason as to why acr-nema should be a library. Berts intention here probably was noble but no-one else that I know of would use it that I can think of when there are things like dc3tools from david clunie. My suggestion would be to mod the build process so that the library is not built at all. As for extract there is no reason as to why it should not be dd. byte_swap is a little more interesting though, there was at one stage a byte_swap4 and a byte_swap8 I have no idea if these still exist as these are a tad more difficult to implement with dd. a From steve at sumost.ca Sun Jan 20 19:51:56 2008 From: steve at sumost.ca (Steve M. Robbins) Date: Sun, 20 Jan 2008 18:51:56 -0600 Subject: [MINC-development] minc 2.0.14 issues In-Reply-To: References: <20080111055607.GY7777@sumost.ca> Message-ID: <20080121005156.GD5085@sumost.ca> On Thu, Jan 17, 2008 at 10:34:44PM +1100, Andrew Janke wrote: > > Just to let you know, I've recently uploaded MINC 2.0.14 to Debian. > > There's an active project to get all kinds of medical imaging software > > into Debian; see http://wiki.debian.org/DebianMedImaging. FSL is in, > > and there is interest in AFNI, Caret, and FreeSurfer. Since the > > latter is built on MINC, work was started on a number of BIC packages, > > including mni_autoreg and N3. > > I presume you are talking about Michael Hanke here. Yes. I'm glad to hear you've been in contact. > I am more than keen to get things right upstream. I note there are a > number of patches in the deb build. I presume you will commit these > upstream also? At present there are just three patches in Debian's package of MINC. 01_mincedit-sensible-viewer.diff simply sets the default editor to "sensible-editor" rather than "emacs". Since "sensible-editor" is a Debianism (basically a script that tries VISUAL, EDITOR, then some hard-coded fallbacks) I wasn't planning to push this upstream. I might suggest, though, that mincedit use $VISUAL, falling back to $EDITOR, then something hardcoded, e.g. emacs. Then I'd probably remove the Debian patch. 02_testdir-runtests.diff is already in MNI's CVS tree, though for MINC-2 only. This is a clear bug that prevented anyone from using "make check" or "make distcheck". I patched it without announcing because I'm sure it is uncontroversial. 03_mincview.diff changes the viewer from "xv" to Imagemagick's "display". This one should probably be applied to the MNI repository since "xv" is nearly impossible to find these days, whereas Imagemagick is ubiquitous. I'm attaching the patch for comments. > > 2. I built MINC using --enable-acr-nema for the first time, and > > discovered that it produces a program named "extract" that simply > > extracts bytes from the middle of the input. Unfortunately, this name > > clashes with a pre-existing software package that has more claim to > > the name (http://bugs.debian.org/459834). Fortunately, it looks to me > > like MINC's extract can be replaced by "dd". So I plan to solve this > > by removing "extract" from Debian's package. The same goes for > > byte_swap. Maybe they can be removed completely? Is anyone really > > using these tools (and can't switch to using dd)? > > I would go further than this. I see no reason as to why acr-nema > should be a library. Berts intention here probably was noble but > no-one else that I know of would use it that I can think of when there > are things like dc3tools from david clunie. My suggestion would be to > mod the build process so that the library is not built at all. The easiest mod is to make it a "convenience library". That means it is built as a library and used to link the tools, but the library is not installed. > byte_swap is a little more interesting though, there was at one stage > a byte_swap4 and a byte_swap8 I have no idea if these still exist as > these are a tad more difficult to implement with dd. The source tree does contain byte_swap4.c, but the tool is not compiled nor installed. I don't see any byte_swap8. Cheers, -Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: 03_mincview.diff Type: text/x-diff Size: 775 bytes Desc: not available Url : http://www.bic.mni.mcgill.ca/pipermail/minc-development/attachments/20080120/f0d19d60/03_mincview.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.bic.mni.mcgill.ca/pipermail/minc-development/attachments/20080120/f0d19d60/attachment.bin