From a.janke at gmail.com  Mon Nov 24 01:05:31 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Mon, 24 Nov 2008 17:05:31 +1100
Subject: [MINC-development] "Amusing" mincblur issue...
Message-ID: <d747ed50811232205m1085669fpb18201a34826c56a@mail.gmail.com>

Hi all,

Try this on for size:

1. First add this to mincblur.c

@@ -192,6 +192,8 @@
     exit(EXIT_FAILURE);
   }

+  print ("FRED VERBOSE:%d CLOB:%d
GRAD:%d\n",verbose,clobber_flag,do_gradient_flag);
+
   /******************************************************************************/
   /* find the size of the blurring kernel, from one of -std, -fwhm,
-fwhm3d     */

2. Do this on a 32 bit machine:

mavis:mincblur$ ./mincblur -verbose -clobber ~/data/me/a.mnc /tmp/out.mnc
FRED VERBOSE:1 CLOB:1 GRAD:0
...

mavis:mincblur$ ./mincblur -clobber -verbose ~/data/me/a.mnc /tmp/out.mnc
FRED VERBOSE:1 CLOB:1 GRAD:0

...

3. Do the same on a 64 bit machine.

ben:mincblur$ mincblur -clobber -verbose ~/data/me/a.mnc /tmp/out.mnc
FRED VERBOSE:1 CLOB:1 GRAD:0
...

ben:mincblur$ mincblur -verbose -clobber ~/data/me/a.mnc /tmp/out.mnc
FRED VERBOSE:0 CLOB:1 GRAD:0
...

4. Scratch your head.

I will bet this is (yet another) 64bit problem with ParseArgv.{c,h}
but am open to suggestions...  I have only spent a bit of time trying
to hunt this down so far but it is beginning to get on my goat as it
means that in my case bestlinreg fails with an error that is somewhat
misleading.  ie:

   $mincblur -clobber -no_apodize -fwhm 8 -gradient
volgenmodel-work-flip/00/fit-model-iso.mnc
/tmp/bestlinreg-wL7Mdx7w/Sfit-model-iso_8
   File /tmp/bestlinreg-wL7Mdx7w/Sfit-model-iso_8_blur.mnc exists.
   Use -clobber to overwrite.
   Died at /data/home/rotor/opt/script_bin/bestlinreg line 280.

Of course here -clobber is given but in this case the -gradient option
is "knocking" it out.  I was first hunting for something wrong with
the -gradient option and then realised that the same problem happens
with -verbose and -clobber...

I will bet this same issue exists in other MINC tools too but have not
tried to find any yet, I had first thought it was an #define quoted
string problem as per what surfaced with rawtominc a while back that
Claude pointed out.

Thoughts?


-- 
Andrew Janke - andrew.janke at anu.edu.au
Department of Geriatric Medicine, ANU
(a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883

From vladimir.fonov at gmail.com  Mon Nov 24 01:22:15 2008
From: vladimir.fonov at gmail.com (Vladimir S. Fonov)
Date: Mon, 24 Nov 2008 01:22:15 -0500
Subject: [MINC-development] "Amusing" mincblur issue...
In-Reply-To: <d747ed50811232205m1085669fpb18201a34826c56a@mail.gmail.com>
References: <d747ed50811232205m1085669fpb18201a34826c56a@mail.gmail.com>
Message-ID: <492A4817.40502@gmail.com>

Hello,

Andrew Janke wrote:
> 
> 4. Scratch your head.
> 
> I will bet this is (yet another) 64bit problem with ParseArgv.{c,h}
> but am open to suggestions...  I have only spent a bit of time trying
> to hunt this down so far but it is beginning to get on my goat as it
> means that in my case bestlinreg fails with an error that is somewhat
> misleading.  ie:

> Thoughts?

Switch to getopt_long  ?

-- 
Best regards,
  Vladimir S. Fonov ~ vladimir.fonov <at> gmail.com

From a.janke at gmail.com  Mon Nov 24 01:29:11 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Mon, 24 Nov 2008 17:29:11 +1100
Subject: [MINC-development] "Amusing" mincblur issue...
In-Reply-To: <492A4817.40502@gmail.com>
References: <d747ed50811232205m1085669fpb18201a34826c56a@mail.gmail.com>
	<492A4817.40502@gmail.com>
Message-ID: <d747ed50811232229o64502d91s71e0f56148def556@mail.gmail.com>

>> Thoughts?
>
> Switch to getopt_long  ?

:)  Trite but True.

I am certainly now in the habit of no longer using GetOpt::Tabular and
am now using GetOpt::Long for perl, meaning I now have POD for all
progs I write.


a

From a.janke at gmail.com  Mon Nov 24 17:24:05 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 25 Nov 2008 09:24:05 +1100
Subject: [MINC-development] "Amusing" mincblur issue...
In-Reply-To: <d747ed50811232229o64502d91s71e0f56148def556@mail.gmail.com>
References: <d747ed50811232205m1085669fpb18201a34826c56a@mail.gmail.com>
	<492A4817.40502@gmail.com>
	<d747ed50811232229o64502d91s71e0f56148def556@mail.gmail.com>
Message-ID: <d747ed50811241424m20552c3by92aaf6e27e965e66@mail.gmail.com>

>> Switch to getopt_long  ?
>
> :)  Trite but True.

Mind you further to this, I would be amenable to start to instigate
this change if you didnt have to manually enumerate the usage (--help)
option in getopt_long meaning you are more prone to error and/or not
keeping things up to data ala Perl POD. Add to that that you also have
to manually set variables from what I can see meaning even more code
for each MINC tool.

ie: (from uname.c).

....

static struct option const long_options[] =
{
  {"all", no_argument, NULL, 'a'},
  {"kernel-name", no_argument, NULL, 's'},
  {"sysname", no_argument, NULL, 's'},	/* Obsolescent.  */
  {"nodename", no_argument, NULL, 'n'},
  {"kernel-release", no_argument, NULL, 'r'},
  {"release", no_argument, NULL, 'r'},  /* Obsolescent.  */
  {"kernel-version", no_argument, NULL, 'v'},
  {"machine", no_argument, NULL, 'm'},
  {"processor", no_argument, NULL, 'p'},
  {"hardware-platform", no_argument, NULL, 'i'},
  {"operating-system", no_argument, NULL, 'o'},
  {GETOPT_HELP_OPTION_DECL},
  {GETOPT_VERSION_OPTION_DECL},
  {NULL, 0, NULL, 0}
};

...

void
usage (int status)
{
  if (status != 0)
    fprintf (stderr, _("Try `%s --help' for more information.\n"),
	     program_name);
  else
    {
      printf (_("Usage: %s [OPTION]...\n"), program_name);
      fputs (_("\
Print certain system information.  With no OPTION, same as -s.\n\
\n\
  -a, --all                print all information, in the following order:\n\
  -s, --kernel-name        print the kernel name\n\
  -n, --nodename           print the network node hostname\n\
  -r, --kernel-release     print the kernel release\n\
"), stdout);
      fputs (_("\
  -v, --kernel-version     print the kernel version\n\
  -m, --machine            print the machine hardware name\n\
  -p, --processor          print the processor type\n\
  -i, --hardware-platform  print the hardware platform\n\
  -o, --operating-system   print the operating system\n\
"), stdout);
      fputs (HELP_OPTION_DESCRIPTION, stdout);
      fputs (VERSION_OPTION_DESCRIPTION, stdout);
      printf (_("\nReport bugs to <%s>.\n"), PACKAGE_BUGREPORT);
    }
  exit (status);
}

...



a

From a.janke at gmail.com  Tue Nov 25 07:52:38 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 25 Nov 2008 23:52:38 +1100
Subject: [MINC-development] "Amusing" mincblur issue...
In-Reply-To: <d747ed50811241424m20552c3by92aaf6e27e965e66@mail.gmail.com>
References: <d747ed50811232205m1085669fpb18201a34826c56a@mail.gmail.com>
	<492A4817.40502@gmail.com>
	<d747ed50811232229o64502d91s71e0f56148def556@mail.gmail.com>
	<d747ed50811241424m20552c3by92aaf6e27e965e66@mail.gmail.com>
Message-ID: <d747ed50811250452l605f46d8r52b9a202b6aeb2b5@mail.gmail.com>

> Mind you further to this,

And even further now that I have been looking around...

   http://code.google.com/p/google-gflags/

Looks like good fun if you happen to play C++. There is no C version
from what I can see but there is a bash version!  (and likely a python
version being a google thing.


a

From a.janke at gmail.com  Wed Nov 26 19:07:42 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 27 Nov 2008 11:07:42 +1100
Subject: [MINC-development] "Amusing" mincblur issue...
In-Reply-To: <d747ed50811232205m1085669fpb18201a34826c56a@mail.gmail.com>
References: <d747ed50811232205m1085669fpb18201a34826c56a@mail.gmail.com>
Message-ID: <d747ed50811261607x3b0aa554r9e0e684f70e4b0dd@mail.gmail.com>

Hrm, seems like this is more endemic than I originally thought...

Get this:

   http://mavis.anu.edu.au/minc-beta/parsetest.tar.gz

Make it. (or use my prebuilt intrepid ones) then do this:

(on 64 bit)

   ben:parsetest$ ./parsetest64 -a -b; ./parsetest64 -b -a
   result a:1 b:1
   result a:1 b:0

(on 32 bit)

   mavis:parsetest$ ./parsetest32 -a -b; ./parsetest64 -b -a
   result a:1 b:1
   result a:1 b:1

oops.

As for a fix I went digging to see what the tcl/tk people do (given
that this is their library to start with) and found this:

   http://tktoolkit.cvs.sourceforge.net/viewvc/tktoolkit/tk/generic/tkArgv.c?revision=1.17&view=markup

Specifically:

  173 	switch (infoPtr->type) {
  174 	case TK_ARGV_CONSTANT:
  175 	    *((int *) infoPtr->dst) = PTR2INT(infoPtr->src);
  176 	    break;


Interesting, Macros...  and what pray tell are these macros?

   http://tktoolkit.cvs.sourceforge.net/viewvc/tktoolkit/tk/generic/tkInt.h?view=markup

Gives us this little bit of blah:

   69 /*
   70  * Macros used to cast between pointers and integers (e.g. when
storing an int
   71  * in ClientData), on 64-bit architectures they avoid gcc
warning about "cast
   72  * to/from pointer from/to integer of different size".
   73  */
   74
   75 #if !defined(INT2PTR) && !defined(PTR2INT)
   76 #   if defined(HAVE_INTPTR_T) || defined(intptr_t)
   77 #	define INT2PTR(p) ((void*)(intptr_t)(p))
   78 #	define PTR2INT(p) ((int)(intptr_t)(p))
   79 #   else
   80 #	define INT2PTR(p) ((void*)(p))
   81 #	define PTR2INT(p) ((int)(p))
   82 #   endif
   83 #endif
   84 #if !defined(UINT2PTR) && !defined(PTR2UINT)
   85 #   if defined(HAVE_UINTPTR_T) || defined(uintptr_t)
   86 #	define UINT2PTR(p) ((void*)(uintptr_t)(p))
   87 #	define PTR2UINT(p) ((unsigned int)(uintptr_t)(p))
   88 #   else
   89 #	define UINT2PTR(p) ((void*)(p))
   90 #	define PTR2UINT(p) ((unsigned int)(p))
   91 #   endif
   92 #endif

So do we just do this:

ben:libsrc$ cvs diff ParseArgv.c
Index: ParseArgv.c
===================================================================
RCS file: /private-cvsroot/minc/libsrc/ParseArgv.c,v
retrieving revision 6.9
diff -u -b -B -r6.9 ParseArgv.c
--- ParseArgv.c	12 Aug 2008 05:00:23 -0000	6.9
+++ ParseArgv.c	27 Nov 2008 00:05:45 -0000
@@ -27,6 +27,8 @@
 #include <math.h>
 #include <ParseArgv.h>

+#define PTR2INT(p) ((int)(p))
+
 /*
  * Default table of argument descriptors.  These are normally available
  * in every application.
@@ -174,7 +176,7 @@
       infoPtr = matchPtr;
       switch (infoPtr->type) {
       case ARGV_CONSTANT:
-         *((long *) infoPtr->dst) = (long) infoPtr->src;
+         *((int *) infoPtr->dst) = PTR2INT(infoPtr->src);
          break;
       case ARGV_INT:
          nargs = (int) infoPtr->src;

Which then gives up this result:

   ben:parsetest$ ./parsetest -a -b
   result a:1 b:1
   ben:parsetest$ ./parsetest -b -a
   result a:1 b:1

Which is "correct", but now spits a compiler warning for minc (amongst
others). The question is will this cause other bugs to creep in.
blah.

Thoughts?


a

From v.s.fonov at ilmarin.info  Tue Nov 25 10:47:16 2008
From: v.s.fonov at ilmarin.info (Vladimir Fonov)
Date: Tue, 25 Nov 2008 10:47:16 -0500
Subject: [MINC-development] "Amusing" mincblur issue...
In-Reply-To: <d747ed50811250452l605f46d8r52b9a202b6aeb2b5@mail.gmail.com>
References: <d747ed50811232205m1085669fpb18201a34826c56a@mail.gmail.com>
	<492A4817.40502@gmail.com>
	<d747ed50811232229o64502d91s71e0f56148def556@mail.gmail.com>
	<d747ed50811241424m20552c3by92aaf6e27e965e66@mail.gmail.com>
	<d747ed50811250452l605f46d8r52b9a202b6aeb2b5@mail.gmail.com>
Message-ID: <fb3c4430811250747h1d5b15dcqf92187746e389782@mail.gmail.com>

Hello,

On Tue, Nov 25, 2008 at 7:52 AM, Andrew Janke <a.janke at gmail.com> wrote:
>> Mind you further to this,
>
> And even further now that I have been looking around...
>
>   http://code.google.com/p/google-gflags/
>
> Looks like good fun if you happen to play C++. There is no C version
> from what I can see but there is a bash version!  (and likely a python
> version being a google thing.

I can try it. I've been using something like this for Windows for a while now .



-- 
Best regards,
 Vladimir S. Fonov ~ v.s.fonov <@> ilmarin.info