From a.janke at gmail.com Thu Mar 18 06:29:04 2010 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 18 Mar 2010 21:29:04 +1100 Subject: [MINC-development] MINC 2.0.19/2.1 and HDF 1.6/1.8 Message-ID: Hi all, I am getting more and more help requests from users with build problems with MINC. Generally as they have downloaded the latest version of HDF (1.8) which is broken against our current release. This is all fixed in CVS and ready for release. Problem is 1.8 hasn't hit the various distros yet. It is now in testing in debian and slated for lynx in Ubuntu (this month). My problem is if I release a new version of MINC (2.1) now then odds are I will then get whinges that it won't build without having to download and install a new version of HDF on distros. So, a quick survey. Who has HDF 1.8 on their machines? and who says stuff it, let's release 2.1 early. ta -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883 From jharlap at bic.mni.mcgill.ca Thu Mar 18 06:55:31 2010 From: jharlap at bic.mni.mcgill.ca (Jonathan Harlap) Date: Thu, 18 Mar 2010 10:55:31 +0000 Subject: [MINC-development] MINC 2.0.19/2.1 and HDF 1.6/1.8 In-Reply-To: References: Message-ID: <115a643d1003180355x77b3a781o298dad0b0427aa9d@mail.gmail.com> [hope this isn't double posted - my apologies if it is] I haven't been following the HDF 1.6 vs 1.8 thing - but may I dare to ask, does supporting HDF 1.8 mean no longer supporting HDF 1.6? Could not MINC 2.1 run equally with both versions? It's just a question to know - let me pre-empt the obvious reaction: I can't offer time right now to make that happen, and as such I don't claim to have a meaningful vote here. I know of several servers in the world I'm still connected to using these tools which will not be updated to new (or even current) distro versions any time soon - they don't have HDF 1.8. Cheers, J On Thu, Mar 18, 2010 at 10:29 AM, Andrew Janke wrote: > Hi all, > > I am getting more and more help requests from users with build > problems with MINC. Generally as they have downloaded the latest > version of HDF (1.8) which is broken against our current release. This > is all fixed in CVS and ready for release. > > Problem is 1.8 hasn't hit the various distros yet. It is now in > testing in debian and slated for lynx in Ubuntu (this month). My > problem is if I release a new version of MINC (2.1) now then odds are > I will then get whinges that it won't build without having to download > and install a new version of HDF on distros. > > So, a quick survey. Who has HDF 1.8 on their machines? and who says > stuff it, let's release 2.1 early. > > ta > > > -- > Andrew Janke > (a.janke at gmail.com || http://a.janke.googlepages.com/) > Canberra->Australia +61 (402) 700 883 > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.janke at gmail.com Thu Mar 18 08:33:20 2010 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 18 Mar 2010 23:33:20 +1100 Subject: [MINC-development] MINC 2.0.19/2.1 and HDF 1.6/1.8 In-Reply-To: <115a643d1003180355x77b3a781o298dad0b0427aa9d@mail.gmail.com> References: <115a643d1003180355x77b3a781o298dad0b0427aa9d@mail.gmail.com> Message-ID: > I haven't been following the HDF 1.6 vs 1.8 thing - but may I dare to ask, > does supporting HDF 1.8 mean no longer supporting HDF 1.6? Sort of. Certainly the changes break things in both directions. There now seems to be two versions of all functions. (the new ending with 2 and the old ending with 1). So you get diffs like this: $ cvs diff -r 6.16 -r HEAD libsrc/hdf_convenience.c ... - H5Aiterate(var->dset_id, &i, hdf_copy_attr, (void *) new_dset_id); + H5Aiterate1(var->dset_id, &i, hdf_copy_attr, (void *) new_dset_id); H5Dclose(var->dset_id); H5Tclose(var->ftyp_id); @@ -1186,7 +1186,7 @@ /* Create the attribute anew. */ - att_id = H5Acreate(loc_id, attnm, ftyp_id, spc_id, H5P_DEFAULT); + att_id = H5Acreate2(loc_id, attnm, ftyp_id, spc_id, H5P_DEFAULT, H5P_DEFAULT); } H5E_END_TRY; if (att_id < 0) @@ -1381,7 +1381,7 @@ } H5E_BEGIN_TRY { - dst_id = H5Dcreate(fd, varpath, typ_id, spc_id, prp_id); + dst_id = H5Dcreate1(fd, varpath, typ_id, spc_id, prp_id); In some cases the change is straight forward in others you have to go read a *gasp* manual. > Could not MINC 2.1 run equally with both versions? Well the obvious answer is yes with a bit of configure tomfoolery and a bunch of #ifdefs but I think you lot will know that I really _really_ despise such code mods as it doesn't really fix anything, just hides the problem until later. > I know of several servers?in the world I'm still connected to?using these > tools which will not be updated to new (or even current) distro versions any > time soon - they don't have HDF 1.8. ditto. Mind you with all this HDF5 change it makes me begin to wonder about why we persist with the thing. I have since learnt that a HDF5 file _changes_ based upon the library version it was written with (blark!). Meaning if I write a "MINC" file with my version of HDF (1.8), someone running a version of HDF5 before 1.4 can't read it. Apparently backwards compatibility is always preserved though. Dare I suggest we shoehorn MINC into a Nifti-1 file with a bunch of custom Nifti-1 headers? The spec for these is now defined and you can have as many of them as you like. For one it'd certainly make us more "compatible" ;) -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883 From claude at bic.mni.mcgill.ca Thu Mar 18 09:25:57 2010 From: claude at bic.mni.mcgill.ca (Claude LEPAGE) Date: Thu, 18 Mar 2010 09:25:57 -0400 Subject: [MINC-development] MINC 2.0.19/2.1 and HDF 1.6/1.8 In-Reply-To: Message-ID: <201003181325.o2IDPvTD022447@grumio.bic.mni.mcgill.ca> Hi guys, May I suggest a different solution? Why not dump HDF and use exclusively netCDF 4 which now offers compression a la HDF? I haven't read about it, so I don't know if it would replace HDF fully. This could be minc3. :-) What do we do with netCDF 3.X vs 4.X? Same problem as HDF 1.6 vs 1.8. Claude From a.janke at gmail.com Thu Mar 18 09:38:56 2010 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 19 Mar 2010 00:38:56 +1100 Subject: [MINC-development] MINC 2.0.19/2.1 and HDF 1.6/1.8 In-Reply-To: <201003181325.o2IDPvTD022447@grumio.bic.mni.mcgill.ca> References: <201003181325.o2IDPvTD022447@grumio.bic.mni.mcgill.ca> Message-ID: > May I suggest a different solution? Why not dump HDF and > use exclusively netCDF 4 which now offers compression a > la HDF? > I haven't read about it, I just did. http://www.unidata.ucar.edu/software/netcdf/docs/faq.html#fv4 > so I don't know if it would replace HDF fully. This could be minc3. :-) Apparently yes. > What do we do with netCDF 3.X vs 4.X? Apparently not a problem and all netcdf3 code is supposed to just work. > Same problem as HDF > 1.6 vs 1.8. Nope. Well I don't see a downside, we just remove all the HDF code from MINC2 and push everything back to netcdf. :) (ie: remove all the switches). Right now I don't see a downside beyond perhaps having to sort out the apparent dimension ordering thingamybob that I don't think anyone uses. I suspect but don't know if netcdf4 supports data chunking ala HDF/MINC2 but would have to look deeper. -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883 From a.janke at gmail.com Thu Mar 18 09:52:39 2010 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 19 Mar 2010 00:52:39 +1100 Subject: [MINC-development] MINC 2.0.19/2.1 and HDF 1.6/1.8 In-Reply-To: References: <201003181325.o2IDPvTD022447@grumio.bic.mni.mcgill.ca> Message-ID: > Well I don't see a downside, we just remove all the HDF code from > MINC2 and push everything back to netcdf. :) ?(ie: remove all the > switches). Well on further reading I now see a downside. netcdf4 _requires_ HDF 1.8.x so all we would be doing is shifting the netcdf->hdf glue layer from our code to theirs. netcdf4 also does chunking and all the other things that HDF5 does so it is pretty obvious that it is a glue layer to HDF5. -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883 From vladimir.fonov at gmail.com Thu Mar 18 10:35:05 2010 From: vladimir.fonov at gmail.com (Vladimir FONOV) Date: Thu, 18 Mar 2010 10:35:05 -0400 Subject: [MINC-development] MINC 2.0.19/2.1 and HDF 1.6/1.8 In-Reply-To: References: Message-ID: <4BA23A19.4010906@gmail.com> Hello, Andrew Janke wrote: > So, a quick survey. Who has HDF 1.8 on their machines? and who says > stuff it, let's release 2.1 early. why not make a statically linked binary with HDF 1.8 ? -- Best regards, Vladimir S. FONOV ~ v.s.fonov ilmarin.info From sean at rogue-research.com Thu Mar 18 10:47:53 2010 From: sean at rogue-research.com (Sean McBride) Date: Thu, 18 Mar 2010 10:47:53 -0400 Subject: [MINC-development] MINC 2.0.19/2.1 and HDF 1.6/1.8 In-Reply-To: References: Message-ID: <20100318144753.441161271@mail.rogue-research.com> On Thu, 18 Mar 2010 21:29:04 +1100, Andrew Janke said: >I am getting more and more help requests from users with build >problems with MINC. Generally as they have downloaded the latest >version of HDF (1.8) which is broken against our current release. This >is all fixed in CVS and ready for release. > >Problem is 1.8 hasn't hit the various distros yet. It is now in >testing in debian and slated for lynx in Ubuntu (this month). My >problem is if I release a new version of MINC (2.1) now then odds are >I will then get whinges that it won't build without having to download >and install a new version of HDF on distros. > >So, a quick survey. Who has HDF 1.8 on their machines? and who says >stuff it, let's release 2.1 early. It's been a while since the last release. And since the CVS repo with your fixes is not public, I vote for a new release. The HDF Group has announced that there will be no further 1.6.x releases, so sticking with it will become more and more difficult as time goes on. -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From vladimir.fonov at gmail.com Thu Mar 18 10:48:02 2010 From: vladimir.fonov at gmail.com (Vladimir FONOV) Date: Thu, 18 Mar 2010 10:48:02 -0400 Subject: [MINC-development] MINC 2.0.19/2.1 and HDF 1.6/1.8 In-Reply-To: References: <201003181325.o2IDPvTD022447@grumio.bic.mni.mcgill.ca> Message-ID: <4BA23D22.3080108@gmail.com> Hello, Andrew Janke wrote: >> Well I don't see a downside, we just remove all the HDF code from >> MINC2 and push everything back to netcdf. :) (ie: remove all the >> switches). > > Well on further reading I now see a downside. netcdf4 _requires_ HDF > 1.8.x so all we would be doing is shifting the netcdf->hdf glue layer > from our code to theirs. > > netcdf4 also does chunking and all the other things that HDF5 does so > it is pretty obvious that it is a glue layer to HDF5. I have even tried to compile minc 2.0.19 with this netcdf4 compiled with HDF5 support, but got a lot of errors. Apparently, they have changed the API -- Best regards, Vladimir S. FONOV ~ v.s.fonov ilmarin.info From nikelski at bic.mni.mcgill.ca Thu Mar 18 11:54:24 2010 From: nikelski at bic.mni.mcgill.ca (EJ Nikelski) Date: Thu, 18 Mar 2010 08:54:24 -0700 Subject: [MINC-development] MINC 2.0.19/2.1 and HDF 1.6/1.8 In-Reply-To: References: <201003181325.o2IDPvTD022447@grumio.bic.mni.mcgill.ca> Message-ID: Hi all, Regarding Claude's suggestion of moving back to a netcdf-based API ... what would this do to those of us who have written fairly large wacks of minc2 API code? From my casual perusal of the code, the API makes calls directly to hdf5 routines, so ... such a move would effectively kill the minc2 API (and all of my code), yes?. Andrew: Just FYI, I also use the apparent dimension ordering feature, and would be very saddened to see it go. -Jim On Thu, Mar 18, 2010 at 6:52 AM, Andrew Janke wrote: >> Well I don't see a downside, we just remove all the HDF code from >> MINC2 and push everything back to netcdf. :) ?(ie: remove all the >> switches). > > Well on further reading I now see a downside. ?netcdf4 _requires_ HDF > 1.8.x so all we would be doing is shifting the netcdf->hdf glue layer > from our code to theirs. > > netcdf4 also does chunking and all the other things that HDF5 does so > it is pretty obvious that it is a glue layer to HDF5. > > -- > Andrew Janke > (a.janke at gmail.com || http://a.janke.googlepages.com/) > Canberra->Australia ? ?+61 (402) 700 883 > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > -- ================================= Jim Nikelski, Ph.D. Postdoctoral Research Fellow Bloomfield Centre for Research in Aging Lady Davis Institute for Medical Research Sir Mortimer B. Davis - Jewish General Hospital McGill University From a.janke at gmail.com Thu Mar 18 19:47:41 2010 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 19 Mar 2010 10:47:41 +1100 Subject: [MINC-development] MINC 2.0.19/2.1 and HDF 1.6/1.8 In-Reply-To: <4BA23A19.4010906@gmail.com> References: <4BA23A19.4010906@gmail.com> Message-ID: >> So, a quick survey. ?Who has HDF 1.8 on their machines? ?and who says >> stuff it, let's release 2.1 early. > > why not make a statically linked binary with HDF 1.8 ? This doesn't solve the problem of those who have to compile from source. And I am busy enough as it is trying to keep us with the platforms for which I already build binaries for. I would need a platoon of virtual machine's to build for even 80% of the most common platforms as a guess. a From a.janke at gmail.com Thu Mar 18 19:48:27 2010 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 19 Mar 2010 10:48:27 +1100 Subject: [MINC-development] MINC 2.0.19/2.1 and HDF 1.6/1.8 In-Reply-To: <4BA23D22.3080108@gmail.com> References: <201003181325.o2IDPvTD022447@grumio.bic.mni.mcgill.ca> <4BA23D22.3080108@gmail.com> Message-ID: >> netcdf4 also does chunking and all the other things that HDF5 does so >> it is pretty obvious that it is a glue layer to HDF5. > > I have even tried to compile minc 2.0.19 with this netcdf4 compiled with > HDF5 support, but got a lot of errors. Apparently, they have changed the API Well so much for that then. a From a.janke at gmail.com Thu Mar 18 19:49:21 2010 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 19 Mar 2010 10:49:21 +1100 Subject: [MINC-development] MINC 2.0.19/2.1 and HDF 1.6/1.8 In-Reply-To: References: <201003181325.o2IDPvTD022447@grumio.bic.mni.mcgill.ca> Message-ID: > ? Regarding Claude's suggestion of moving back to a netcdf-based API > ... what would this do to those of us who have written fairly large > wacks of minc2 API code? Well whatever the plan turns out to be I have no intention of ever breaking backwards compatibility for MINC files and API calls. > Andrew: Just FYI, I also use the apparent dimension ordering feature, > and would be very saddened to see it go. Interesting. a From a.janke at gmail.com Thu Mar 18 19:53:33 2010 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 19 Mar 2010 10:53:33 +1100 Subject: [MINC-development] MINC 2.0.19/2.1 and HDF 1.6/1.8 In-Reply-To: <20100318144753.441161271@mail.rogue-research.com> References: <20100318144753.441161271@mail.rogue-research.com> Message-ID: > It's been a while since the last release. ?And since the CVS repo with > your fixes is not public, I vote for a new release. I am beginning to think this is the best too. > The HDF Group has announced that there will be no further 1.6.x > releases, so sticking with it will become more and more difficult as > time goes on. Aye, perhaps the best plan is to just plan in the future to remove netcdf. I am not sure but I am sure I read somewhere that HDF5 can read netcdf files. No doubt this is via having netcdf4 installed given that Netcdf4 seems to be a pre-requisite for HDF5 1.8.x So for now it seems that we have to keep chugging on with both of them installed and not expect this to change soon. Thanks all, for now I will release MINC 2.1 and write a big warning page about it or something. -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883 From claude at bic.mni.mcgill.ca Thu Mar 18 20:42:01 2010 From: claude at bic.mni.mcgill.ca (Claude LEPAGE) Date: Thu, 18 Mar 2010 20:42:01 -0400 Subject: [MINC-development] MINC 2.0.19/2.1 and HDF 1.6/1.8 In-Reply-To: Message-ID: <201003190042.o2J0g17b026256@grumio.bic.mni.mcgill.ca> Andrew, > > It's been a while since the last release. =A0And since the CVS repo with > > your fixes is not public, I vote for a new release. > > I am beginning to think this is the best too. > > Thanks all, for now I will release MINC 2.1 and write a big warning > page about it or something. Can you hold on to your release for a day or two? I think I have goodies to add to cvs. I've been using my own "minc-2.0.19" internally for a while. Sylvain has also tried it with the standard minctracc benchmark and he found that 2.0.19 is slower than 2.0.18. Certainly something to consider before releasing minc-2.1. Forecast for the weekend is rain+rain. Maybe a good time to catch up with this kind of stuff. Claude From a.janke at gmail.com Thu Mar 18 20:52:52 2010 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 19 Mar 2010 11:52:52 +1100 Subject: [MINC-development] MINC 2.0.19/2.1 and HDF 1.6/1.8 In-Reply-To: <201003190042.o2J0g17b026256@grumio.bic.mni.mcgill.ca> References: <201003190042.o2J0g17b026256@grumio.bic.mni.mcgill.ca> Message-ID: > Can you hold on to your release for a day or two? No problem. > I think I have goodies to add to cvs. I have a few more things to add too in any case. (mincmorph, minccomplete, mincsample). Although with mincsample I will have to be careful with licensing so perhaps not. > I've been using my own "minc-2.0.19" internally for a while. > Sylvain has also tried it with the standard minctracc benchmark and he > found that 2.0.19 is slower than 2.0.18. Certainly something to consider > before releasing minc-2.1. Wierd. I didn't notice this. Of course there is no way of telling if this is a HDF5 or MINC issue. > Forecast for the weekend is rain+rain. Maybe a good time to catch up with > this kind of stuff. And cold, you forgot cold. -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883 From claude at bic.mni.mcgill.ca Thu Mar 18 21:00:24 2010 From: claude at bic.mni.mcgill.ca (Claude LEPAGE) Date: Thu, 18 Mar 2010 21:00:24 -0400 Subject: [MINC-development] MINC 2.0.19/2.1 and HDF 1.6/1.8 In-Reply-To: Message-ID: <201003190100.o2J10O5H031168@grumio.bic.mni.mcgill.ca> > > I've been using my own "minc-2.0.19" internally for a while. > > Sylvain has also tried it with the standard minctracc benchmark and he > > found that 2.0.19 is slower than 2.0.18. Certainly something to consider > > before releasing minc-2.1. > > Wierd. I didn't notice this. Of course there is no way of telling if > this is a HDF5 or MINC issue. The version for all other packages were the same. Only minc changed. Sylvain, are you reading this? Comments? From a.janke at gmail.com Thu Mar 18 21:03:15 2010 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 19 Mar 2010 12:03:15 +1100 Subject: [MINC-development] MINC 2.0.19/2.1 and HDF 1.6/1.8 In-Reply-To: <201003190100.o2J10O5H031168@grumio.bic.mni.mcgill.ca> References: <201003190100.o2J10O5H031168@grumio.bic.mni.mcgill.ca> Message-ID: >> Wierd. I didn't notice this. Of course there is no way of telling if >> this is a HDF5 or MINC issue. > > The version for all other packages were the same. Only minc changed. eh? unpossible! :) MINC 2.0.18 == HDF5 1.6.x MINC 2.0.19 (current CVS HEAD == HDF5 1.8.x ? a From a.janke at gmail.com Thu Mar 18 22:00:25 2010 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 19 Mar 2010 13:00:25 +1100 Subject: [MINC-development] MINC 2.0.19/2.1 and HDF 1.6/1.8 In-Reply-To: References: <201003190100.o2J10O5H031168@grumio.bic.mni.mcgill.ca> Message-ID: On Fri, Mar 19, 2010 at 12:03, Andrew Janke wrote: >>> Wierd. I didn't notice this. Of course there is no way of telling if >>> this is a HDF5 or MINC issue. >> >> The version for all other packages were the same. Only minc changed. > > eh? unpossible! :) > > MINC 2.0.18 == HDF5 1.6.x > > MINC 2.0.19 (current CVS HEAD == HDF5 1.8.x Well this got me curious... So I just ran my own test. (Core i7 950 3.07Ghz std "clock" speed, 12GB RAM, 30GB OCZ SSD HDD). First std karmic build using packages. $ mincmath -version program: 2.0.18 libminc: 2.0.18 netcdf : "3.6.2" of Sep 24 2009 17:09:40 $ HDF5 : 1.6.6 $ minctracc -version The program was built from: Package mni_autoreg 0.99.6, compiled by @bertie (x86_64-unknown-linux-gnu) on Fri Oct 9 11:41:30 EST 2009 real 2m28.078s user 2m27.880s sys 0m0.180s Now the new stuff $ ./tree/bin/mincmath -version program: 2.0.19 libminc: 2.0.19 netcdf : "3.6.2" of Sep 24 2009 17:09:40 $ HDF5 : 1.8.4 $ ./tree/bin/minctracc -version The program <./tree/bin/minctracc> was built from: Package mni_autoreg 0.99.6, compiled by @harold (x86_64-unknown-linux-gnu) on Fri Mar 19 12:23:26 EST 2010 real 2m33.449s user 2m33.050s sys 0m0.400s --- I was also doing a bunch of things while this was happening so re-ran the tests and got a 2m30 for the original and 2m31 for the new. So yes perhaps there is a minute slow down (1%) but from what I can see, not anything to write home and tell mum about. Interested to see Sylvains numbers. -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883 From claude at bic.mni.mcgill.ca Thu Mar 18 22:55:42 2010 From: claude at bic.mni.mcgill.ca (Claude LEPAGE) Date: Thu, 18 Mar 2010 22:55:42 -0400 Subject: [MINC-development] MINC 2.0.19/2.1 and HDF 1.6/1.8 In-Reply-To: Message-ID: <201003190255.o2J2tgts029624@grumio.bic.mni.mcgill.ca> > > > > The version for all other packages were the same. Only minc changed. > > eh? unpossible! :) > > MINC 2.0.18 == HDF5 1.6.x > > MINC 2.0.19 (current CVS HEAD == HDF5 1.8.x > > ? Not the same 2.0.19. At the time, it must have been CVS head before you added your changes. So based on hdf5 1.6.x in both cases. From claude at bic.mni.mcgill.ca Thu Mar 18 23:00:35 2010 From: claude at bic.mni.mcgill.ca (Claude LEPAGE) Date: Thu, 18 Mar 2010 23:00:35 -0400 Subject: [MINC-development] MINC 2.0.19/2.1 and HDF 1.6/1.8 In-Reply-To: Message-ID: <201003190300.o2J30Zkv030899@grumio.bic.mni.mcgill.ca> Andrew, Below are Sylvain's number (en francais). :-) > > eh? unpossible! :) > > > > MINC 2.0.18 == HDF5 1.6.x > > > > MINC 2.0.19 (current CVS HEAD == HDF5 1.8.x > > Well this got me curious... So I just ran my own test. (Core i7 950 > 3.07Ghz std "clock" speed, 12GB RAM, 30GB OCZ SSD HDD). > > First std karmic build using packages. > > $ mincmath -version > program: 2.0.18 > libminc: 2.0.18 > netcdf : "3.6.2" of Sep 24 2009 17:09:40 $ > HDF5 : 1.6.6 > > $ minctracc -version > The program was built from: > Package mni_autoreg 0.99.6, compiled by @bertie > (x86_64-unknown-linux-gnu) on Fri Oct 9 11:41:30 EST 2009 > > real 2m28.078s > user 2m27.880s > sys 0m0.180s > > Now the new stuff > $ ./tree/bin/mincmath -version > program: 2.0.19 > libminc: 2.0.19 > netcdf : "3.6.2" of Sep 24 2009 17:09:40 $ > HDF5 : 1.8.4 > > $ ./tree/bin/minctracc -version > The program <./tree/bin/minctracc> was built from: > Package mni_autoreg 0.99.6, compiled by @harold > (x86_64-unknown-linux-gnu) on Fri Mar 19 12:23:26 EST 2010 > > real 2m33.449s > user 2m33.050s > sys 0m0.400s > > --- > > I was also doing a bunch of things while this was happening so re-ran > the tests and got a 2m30 for the original and 2m31 for the new. So > yes perhaps there is a minute slow down (1%) but from what I can see, > not anything to write home and tell mum about. > > Interested to see Sylvains numbers. > ****************************************************************** > > je sais que 2.0.19 n'est pas encore officiel mais je viens de remarquer > une chose lorsque je compare le test minctracc d'Andrew avec 2.0.18 et 2.0.19: > > le test est le suivant: > > time /usr/local/bic/bin/minctracc -clobber -debug -nonlinear -step 2 2 2 /usr/local/bic/share/mni_autoreg/icbm_avg_152_t1_tal_lin.mnc /usr/local/bic/share/mni_autoreg/icbm_avg_152_t1_tal_lin.mnc /tmp/out.xfm > > avec 2.0.18, j'obtiens > > 190.943u 0.240s 3:11.15 100.0% 0+0k 0+0io 0pf+0w > > et avec 2.0.19: > > 304.327u 0.220s 5:04.50 100.0% 0+0k 0+0io 0pf+0w > > niveau optimization, ca va pas dans le bon sens! ;-) > > J'ai fait mes tests sur une nouvelle machine, ie taurus. ****************************************************************** 1 second difference is fine. 2 minutes more is not ok. I'll check what's in my 2.0.19. It is very similar to 2.0.18. Maybe I should not commit these changes. :-) Claude From a.janke at gmail.com Thu Mar 18 23:07:42 2010 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 19 Mar 2010 14:07:42 +1100 Subject: [MINC-development] MINC 2.0.19/2.1 and HDF 1.6/1.8 In-Reply-To: <201003190300.o2J30Zkv030899@grumio.bic.mni.mcgill.ca> References: <201003190300.o2J30Zkv030899@grumio.bic.mni.mcgill.ca> Message-ID: > Below are Sylvain's number (en francais). :-) heh... >> niveau optimization, ca va pas dans le bon sens! ;-) >> >> J'ai fait mes tests sur une nouvelle machine, ie taurus. What does this "new machine" (taurus) have in it? 3.11 is not a crash hot time for a new machine unless this was a while back. Perhaps something else is afoot. > I'll check what's in my 2.0.19. It is very similar to 2.0.18. > Maybe I should not commit these changes. :-) Aye, something is fishy. a From sylvain at bic.mni.mcgill.ca Fri Mar 19 00:36:54 2010 From: sylvain at bic.mni.mcgill.ca (Sylvain Milot) Date: Fri, 19 Mar 2010 00:36:54 -0400 (EDT) Subject: [MINC-development] MINC 2.0.19/2.1 and HDF 1.6/1.8 In-Reply-To: References: <201003190300.o2J30Zkv030899@grumio.bic.mni.mcgill.ca> Message-ID: On Fri, 19 Mar 2010, Andrew Janke wrote: >> Below are Sylvain's number (en francais). :-) > > heh... > >>> niveau optimization, ca va pas dans le bon sens! ;-) >>> >>> J'ai fait mes tests sur une nouvelle machine, ie taurus. > > What does this "new machine" (taurus) have in it? 3.11 is not a crash > hot time for a new machine unless this was a while back. Perhaps > something else is afoot. 3.11 would put it in 6th position - taurus has an Intel 2.83GHz Core2Quad with Debian lenny 64bit ... essentially the same as paris. new doesn't necessarily mean the fastest cpu available - it all depends on your wallet! being No 1 on http://en.wikibooks.org/wiki/MINC/Benchmarks is not a top priority but being close to similar installations is good to know. >> I'll check what's in my 2.0.19. It is very similar to 2.0.18. >> Maybe I should not commit these changes. :-) > > Aye, something is fishy. here are some details on the versions used: I used HDF5 1.6.9 with MINC 2.0.19, so maybe that's the culprit ... # ssh taurus /usr/local/bic/bin/minctracc -version The program was built from: Package mni_autoreg 0.99.6, compiled by @nestor (x86_64-unknown-linux-gnu) on Wed Dec 9 16:09:23 EST 2009 ssh taurus /usr/local/bic/bin/mincaverage -version program: 2.0.18 libminc: 2.0.18 netcdf : "3.6.3" of Dec 9 2009 15:33:29 $ HDF5 : 1.6.6 # /tmp/mni-autoreg-0.99.6-2.0.19//usr/local/bic/bin/minctracc -version The program was built from: Package mni_autoreg 0.99.6, compiled by @nestor (x86_64-unknown-linux-gnu) on Wed Feb 24 17:21:39 EST 2010 # /tmp/minc-2.0.19/usr/local/bic/bin/mincaverage -version program: 2.0.19 libminc: 2.0.19 netcdf : "3.6.3" of Feb 24 2010 15:56:43 $ HDF5 : 1.6.9 --- Sylvain Milot (sylvain at bic.mni.mcgill.ca) (bicadmin at bic.mni.mcgill.ca) Brain Imaging Centre Montreal Neurological Institute 3801 University Street Webster 2B, Room 206 Montreal, Qc., Canada, H3A 2B4 Phone : (514) 398-4965, Fax: 398-8948 Mobile : (514) 712-1768 Office : 527 Av Des Pins O., Room 104 Montreal, Qc., H2W 1S4 From a.janke at gmail.com Fri Mar 19 05:47:10 2010 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 19 Mar 2010 20:47:10 +1100 Subject: [MINC-development] MINC 2.0.19/2.1 and HDF 1.6/1.8 In-Reply-To: References: <201003190300.o2J30Zkv030899@grumio.bic.mni.mcgill.ca> Message-ID: > 3.11 would put it in 6th position - taurus has an Intel 2.83GHz Core2Quad > with Debian lenny 64bit ... essentially the same as paris. Ah, that would explain things. > here are some details on the versions used: I used HDF5 1.6.9 with MINC > 2.0.19, so maybe that's the culprit ... Thanks, I'll check this combination. -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883 From a.janke at gmail.com Mon Mar 22 21:27:09 2010 From: a.janke at gmail.com (Andrew Janke) Date: Tue, 23 Mar 2010 12:27:09 +1100 Subject: [MINC-development] MINC 2.0.19/2.1 and HDF 1.6/1.8 In-Reply-To: <201003190042.o2J0g17b026256@grumio.bic.mni.mcgill.ca> References: <201003190042.o2J0g17b026256@grumio.bic.mni.mcgill.ca> Message-ID: >> Thanks all, for now I will release MINC 2.1 and write a big warning >> page about it or something. > > Can you hold on to your release for a day or two? OK, I am now largely done my changes. harold:minc$ head -20 ChangeLog 2010-03-22 Andrew L Janke * added pod2man for manpage generation from scripts * shifted minchistory man to POD * conversion/vff2mnc/vff2mnc.c: added error checking for fgets 2010-03-02 Andrew L Janke * Added minccmp (minccmp.c and minccmp.man1) * libsrc/hdf_convenience.c: removed spurious debug output * libsrc/minc.h: replaced MAX_NC_OPEN with 32 * libsrc/voxel_loop.c: replaced MAX_NC_OPEN with MI_MAX_NUM_ICV 2010-02-03 Andrew L Janke * progs/mincpik/mincik: added -text_size option (Thanks Mishkin) * removed all non-quoted string barewords (hash refs) * added range calculation for anot bar if not defined Let me know when you are done and I will release 2.1 and see what breaks. :) a From burt.crepeault at crulrg.ulaval.ca Mon Mar 29 15:35:33 2010 From: burt.crepeault at crulrg.ulaval.ca (=?ISO-8859-1?Q?Burt_Cr=E9peault?=) Date: Mon, 29 Mar 2010 15:35:33 -0400 Subject: [MINC-development] Building MINC for OS X 10.6 Message-ID: Hi all, I'm currently attempting a full build of all the latest MINC packages from http://packages.bic.mni.mcgill.ca/tgz/ on OS X version 10.6 (Snow Leopard) I've managed to get to a certain point but along the way I've accumulated a number of questions that I'd like to na?vely ask here, in hope for answers and perhaps that someone will see what problems may come to a first-timer. General Questions - Is there a list of all the packages not included on http://packages.bic.mni.mcgill.ca/tgz/ and for which one or more of the MNI packages have dependencies? I'm thinking of stuff like ImageMagick, Coin and gsl. - In what order should one build the MNI packages, as some appear to depend on others? - I'd like to build everything in a "portable" installation, i.e. with all the libraries and includes and other stuff under a single location (e.g. ~/minc-2.0.18). So far, I've managed to use the --prefix and --with-build-path options to the configure command. Is there anything else I need to know? How would I configure the run-time shell environment with regards to $PATH, $LD_LIBRARY_PATH, $DYLD_LIBRARY_PATH, etc.? Package-specific Questions - Display-1.4.2 and Register-1.3.6: what is the effect of using the --with-apple-opengl-framework instruction? Must it be used for compilation on OS X? - mincfft-1.1.1: does not appear to work with the latest fftw library (version 3.x) but was successful with 2.1.5 - mni_perllib-0.08: I get the following error: - Makefile.PL: I don't grok the manifypods section, so can't tweak the pod2man args at Makefile.PL line 162. - Perl version is 5.10 on this Mac. - bicInventor-0.3.1: I can't get passed the message: - configure: error: cannot find required library GL - brain-view-0.7.0: Even though I installed Coin, I still get: - checking for Open Inventor (Coin)... no checking for Open Inventor (SGI)... no configure: error: No Open Inventor library detected. - I've tried the --with-coin=DIR with DIR set as many suspected locations for Coin but nothing worked That's all for now, I might have more as I'm not quite done going through the whole thing. Thanks! Burt. P.S. When I'm done, if anyone is interested with a recent OS X build, let me know. -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.janke at gmail.com Mon Mar 29 23:23:29 2010 From: a.janke at gmail.com (Andrew Janke) Date: Tue, 30 Mar 2010 14:23:29 +1100 Subject: [MINC-development] Building MINC for OS X 10.6 In-Reply-To: References: Message-ID: > I'm currently attempting a full build of all the latest MINC packages from > http://packages.bic.mni.mcgill.ca/tgz/ on OS X version 10.6 (Snow Leopard) > Is there a list of all the packages not included on > http://packages.bic.mni.mcgill.ca/tgz/ and for which one or more of the MNI > packages have dependencies? I'm thinking of stuff like ImageMagick, Coin and > gsl. It depends on the platform (and keeps changing). Here is a list I use for the Ubuntu Karmic though: netcdfg-dev libhdf5-serial-dev libnetpbm9-dev fftw-dev libgsl0-dev libgetopt-tabular-perl libmni-perllib-perl libxext-dev glutg3-dev libsoqt3-dev libxmu-dev libxi-dev imagemagick libtext-format-perl libpcre++0 libpcre3 libsimage-dev libpcre++-dev > In what order should one build the MNI packages, as some appear to depend on > others? There are only a few dependencies, if you do these in this order first: minc ebtks bicpl then all the rest should build with no problems > I'd like to build everything in a "portable" installation, i.e. with all the > libraries and includes and other stuff under a single location (e.g. > ~/minc-2.0.18). So far, I've managed to use the --prefix and > --with-build-path options to the configure command. Is there anything else I > need to know? Nope, sounds about right. > How would I configure the run-time shell environment with > regards to $PATH, $LD_LIBRARY_PATH, $DYLD_LIBRARY_PATH, etc.? Well you will have to at least set $DYLD_LIBRARY_PATH to include ~/minc-2.0.18/lib and add ~minc-2.0.18/bin to $PATH. Be aware that shifting things around may cause issues with libtool though (.la files). > Display-1.4.2 and Register-1.3.6: what is the effect of using the > --with-apple-opengl-framework instruction? Must it be used for compilation > on OS X? It doesn't have to be but I would recommend it. Without it you will have to install your own versions of GLUT and OpenGL. The flag uses the system versions meaning that integration with OSX is better (you can use Control-Q for example). > mincfft-1.1.1: does not appear to work with the latest fftw library (version > 3.x) but was successful with 2.1.5 I thought this had been ported by Jon Harlap but perhaps it was a previous version. > mni_perllib-0.08: I get the following error: > > Makefile.PL: I don't grok the manifypods section, so can't tweak the pod2man > args at Makefile.PL line 162. > Perl version is 5.10 on this Mac. Safe to ignore. > bicInventor-0.3.1: I can't get passed the message: > configure: error: cannot find required library GL > brain-view-0.7.0: Even though I installed Coin, I still get: Jason? -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883 ` From burt.crepeault at crulrg.ulaval.ca Tue Mar 30 14:38:11 2010 From: burt.crepeault at crulrg.ulaval.ca (=?ISO-8859-1?Q?Burt_Cr=E9peault?=) Date: Tue, 30 Mar 2010 14:38:11 -0400 Subject: [MINC-development] Building MINC for OS X 10.6 In-Reply-To: References: Message-ID: On Mon, Mar 29, 2010 at 23:23, Andrew Janke wrote: > > I'm currently attempting a full build of all the latest MINC packages > from > > http://packages.bic.mni.mcgill.ca/tgz/ on OS X version 10.6 (Snow > Leopard) > > > Is there a list of all the packages not included on > > http://packages.bic.mni.mcgill.ca/tgz/ and for which one or more of the > MNI > > packages have dependencies? I'm thinking of stuff like ImageMagick, Coin > and > > gsl. > > It depends on the platform (and keeps changing). Here is a list I use > for the Ubuntu Karmic though: > > netcdfg-dev libhdf5-serial-dev libnetpbm9-dev fftw-dev libgsl0-dev > libgetopt-tabular-perl libmni-perllib-perl libxext-dev glutg3-dev > libsoqt3-dev libxmu-dev libxi-dev imagemagick libtext-format-perl > libpcre++0 libpcre3 libsimage-dev libpcre++-dev > Ah the beauty of the Debian/Ubuntu package manager... The list gets much longer when you include the dependencies of the dependencies. There used to be a MINC port on Fink or Macports but I think it's grown out of date. Who was the owner of those ports by the way? If i'm successful here, I might consider maintaining them and save future Mac users some sweat. > > > > > Makefile.PL: I don't grok the manifypods section, so can't tweak the > pod2man > > args at Makefile.PL line 162. > > Perl version is 5.10 on this Mac. > > > mni_perllib-0.08: I get the following error: > Safe to ignore. > > Certain? The script doesn't seem to finish as no config.h is created. Make won't run. > > bicInventor-0.3.1: I can't get passed the message: > > configure: error: cannot find required library GL > > brain-view-0.7.0: Even though I installed Coin, I still get: > > Jason? > I was able to build bicInventor by using LDFLAGS as such: ./configure LDFLAGS="-L/Library/Frameworks/Inventor.framework/Versions/C/Libraries" --prefix=/Users/burt/Desktop/build/install --with-build-path=/Users/burt/Desktop/build/install --with-minc2 --x-includes=/usr/X11/include --x-libraries=/usr/X11/lib I suppose the same could be accomplished with brain-view but I'm going to let that one drop for now as we don't really need it. I must add another one to the list: xdisp-4.6 doesn't build. Here's the complete trace: neon:xdisp-4.6:# ./configure --prefix=/Users/burt/Desktop/build/install --with-build-path=/Users/burt/Desktop/build/install --with-minc2 --x-includes=/usr/X11/include --x-libraries=/usr/X11/lib checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for ranlib... ranlib checking for a BSD-compatible install... /usr/bin/install -c checking how to run the C preprocessor... gcc -E checking for X... libraries /usr/X11/lib, headers /usr/X11/include checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... yes checking for library m... yes checking for library netcdf... yes checking for library z... yes checking for library hdf5... yes checking for library minc2... yes checking for library volume_io2... yes configure: creating ./config.status config.status: creating epm-header config.status: creating Makefile config.status: creating olgx/Makefile config.status: creating config.h config.status: executing depfiles commands neon:xdisp-4.6:# make make all-recursive Making all in olgx if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/Users/burt/Desktop/build/install/include -g -O2 -MT ol_button.o -MD -MP -MF ".deps/ol_button.Tpo" -c -o ol_button.o ol_button.c; \ then mv -f ".deps/ol_button.Tpo" ".deps/ol_button.Po"; else rm -f ".deps/ol_button.Tpo"; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/Users/burt/Desktop/build/install/include -g -O2 -MT ol_color.o -MD -MP -MF ".deps/ol_color.Tpo" -c -o ol_color.o ol_color.c; \ then mv -f ".deps/ol_color.Tpo" ".deps/ol_color.Po"; else rm -f ".deps/ol_color.Tpo"; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/Users/burt/Desktop/build/install/include -g -O2 -MT ol_draw.o -MD -MP -MF ".deps/ol_draw.Tpo" -c -o ol_draw.o ol_draw.c; \ then mv -f ".deps/ol_draw.Tpo" ".deps/ol_draw.Po"; else rm -f ".deps/ol_draw.Tpo"; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/Users/burt/Desktop/build/install/include -g -O2 -MT ol_init.o -MD -MP -MF ".deps/ol_init.Tpo" -c -o ol_init.o ol_init.c; \ then mv -f ".deps/ol_init.Tpo" ".deps/ol_init.Po"; else rm -f ".deps/ol_init.Tpo"; exit 1; fi ol_init.c:12:20: error: malloc.h: No such file or directory ol_init.c: In function ?olgx_get_perdisplay_list?: ol_init.c:1564: warning: assignment makes integer from pointer without a cast ol_init.c:1565: warning: assignment makes integer from pointer without a cast make[2]: *** [ol_init.o] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.janke at gmail.com Tue Mar 30 20:14:52 2010 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 31 Mar 2010 11:14:52 +1100 Subject: [MINC-development] Building MINC for OS X 10.6 In-Reply-To: References: Message-ID: >> ?netcdfg-dev libhdf5-serial-dev libnetpbm9-dev fftw-dev libgsl0-dev >> libgetopt-tabular-perl libmni-perllib-perl libxext-dev glutg3-dev >> libsoqt3-dev libxmu-dev libxi-dev imagemagick libtext-format-perl >> libpcre++0 libpcre3 libsimage-dev libpcre++-dev > > Ah the beauty of the Debian/Ubuntu package manager... The list gets much > longer when you include the dependencies of the dependencies. Absolutely > There used to > be a MINC port on Fink or Macports but I think it's grown out of date. Who > was the owner of those ports by the way? I remember starting one a yonk ago and since then various people have looked after various things but there is no consistent mac build that I know of. Primarily as the only Mac that I have is my trusty old 13" PowerBook G4 running Tiger. > If i'm successful here, I might consider maintaining them and save future Mac users some sweat. Well I for one won't stop you. Jason Lerch and myself were at one stage building monolithic MINC OSX installers that were using the Mac packager/installer. (.pkg and .mpkg files) See: http://packages.bic.mni.mcgill.ca/osx-10.4/minc-1.4-20060620.mpkg.tar.gz >> > mni_perllib-0.08: I get the following error: >> Safe to ignore. > > Certain? The script doesn't seem to finish as no config.h is created. Make > won't run. Hrm, perhaps it's a perl 5.1 vs 5.4 thing. In my (often not so humble) opinion mni_perllib should die. It's antiquated and VERY BIC specific. The tests check for a long.q on shadow for example... (shadow was an old SGI O200 system at the BIC 10 years ago.... I think I stubbed this bit out a while back but I certainly don't use mni_perllib for anything I do and remove it where feasible in all code I maintain. > I must add another one to the list: xdisp-4.6 doesn't build. Here's the > complete trace: xdisp is really a bit of an esoteric old dinosaur (sorry Bruce if you are reading this.. :) It has no maintainer and I am not going to stick my hand up to do it right now.... -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883 From a.janke at gmail.com Tue Mar 30 20:16:42 2010 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 31 Mar 2010 11:16:42 +1100 Subject: [MINC-development] Building MINC for OS X 10.6 In-Reply-To: <4BB22CE8.9040500@phenogenomics.ca> References: <4BB22CE8.9040500@phenogenomics.ca> Message-ID: On Wed, Mar 31, 2010 at 03:55, Matthijs van Eede wrote: > Not 100% sure about this, but is octave not also something the software > (xfmavg) depends on? Should that be part of the dependency list? You are bang on. But xfmavg is not part of MINC proper and is just a script of mine that I distribute. I am slowly adding such scripts to places that make sense in MINC itself but I tend to wait for them to be tested well before releasing them. I often fork to octave in perl scripts that I write. -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883 From burt.crepeault at crulrg.ulaval.ca Wed Mar 31 10:00:32 2010 From: burt.crepeault at crulrg.ulaval.ca (=?ISO-8859-1?Q?Burt_Cr=E9peault?=) Date: Wed, 31 Mar 2010 10:00:32 -0400 Subject: [MINC-development] Building MINC for OS X 10.6 In-Reply-To: References: Message-ID: > Jason Lerch and myself were at one > stage building monolithic MINC OSX installers that were using the Mac > packager/installer. (.pkg and .mpkg files) See: > > http://packages.bic.mni.mcgill.ca/osx-10.4/minc-1.4-20060620.mpkg.tar.gz > > I figured things must have changed since 2006... ;) I must first educate myself on creating packages but I'll get there eventually. > >> > mni_perllib-0.08: I get the following error: > >> Safe to ignore. > > > > Certain? The script doesn't seem to finish as no config.h is created. > Make > > won't run. > > Hrm, perhaps it's a perl 5.1 vs 5.4 thing. In my (often not so humble) > opinion mni_perllib should die. It's antiquated and VERY BIC specific. > The tests check for a long.q on shadow for example... (shadow was an > old SGI O200 system at the BIC 10 years ago.... I think I stubbed > this bit out a while back but I certainly don't use mni_perllib for > anything I do and remove it where feasible in all code I maintain. > > Pardon my newbieness with Perl, when I said that no config.h was created, this is what I meant: After running the Makefile.PL script, the makefile references the latest perl installation on this machine which is 5.10.0. When I attempt to make, I get this error: make: *** No rule to make target `/System/Library/Perl/5.10.0/darwin-thread-multi-2level/CORE/config.h', needed by `Makefile'. Stop. Here's the content of /System/Library/Perl/5.10.0/darwin-thread-multi-2level/CORE/ -rwxr-xr-x 1 root wheel 3679344 26 Jun 2009 libperl.dylib -rw-r--r-- 1 root wheel 168689 26 Jun 2009 perl.h while /System/Library/Perl/5.8.8/darwin-thread-multi-2level/CORE has -rw-r--r-- 1 root wheel 1751 23 Sep 2007 EXTERN.h -rw-r--r-- 1 root wheel 1424 23 Sep 2007 INTERN.h -rw-r--r-- 1 root wheel 18793 23 Sep 2007 XSUB.h -rw-r--r-- 1 root wheel 3044 23 Sep 2007 av.h -rw-r--r-- 1 root wheel 2196 23 Sep 2007 cc_runtime.h -rw-r--r-- 1 root wheel 138389 23 Sep 2007 config.h -rw-r--r-- 1 root wheel 18737 23 Sep 2007 cop.h -rw-r--r-- 1 root wheel 7992 23 Sep 2007 cv.h -rw-r--r-- 1 root wheel 5717 23 Sep 2007 dosish.h -rw-r--r-- 1 root wheel 150252 23 Sep 2007 embed.h -rw-r--r-- 1 root wheel 61978 23 Sep 2007 embedvar.h -rw-r--r-- 1 root wheel 3180 23 Sep 2007 fakesdio.h -rw-r--r-- 1 root wheel 1822 23 Sep 2007 fakethr.h -rw-r--r-- 1 root wheel 723 23 Sep 2007 form.h -rw-r--r-- 1 root wheel 5477 23 Sep 2007 gv.h -rw-r--r-- 1 root wheel 24923 23 Sep 2007 handy.h -rw-r--r-- 1 root wheel 13647 23 Sep 2007 hv.h -rw-r--r-- 1 root wheel 20855 23 Sep 2007 intrpvar.h -rw-r--r-- 1 root wheel 48335 23 Sep 2007 iperlsys.h -rw-r--r-- 1 root wheel 6257 23 Sep 2007 keywords.h -rw-r--r-- 1 root wheel 1484 23 Sep 2007 malloc_ctl.h -rw-r--r-- 1 root wheel 2083 23 Sep 2007 mg.h -rw-r--r-- 1 root wheel 3306 23 Sep 2007 nostdio.h -rw-r--r-- 1 root wheel 16267 23 Sep 2007 op.h -rw-r--r-- 1 root wheel 46737 23 Sep 2007 opcode.h -rw-r--r-- 1 root wheel 9351 23 Sep 2007 opnames.h -rw-r--r-- 1 root wheel 8810 23 Sep 2007 pad.h -rw-r--r-- 1 root wheel 4711 23 Sep 2007 patchlevel.h -rw-r--r-- 1 root wheel 37087 23 Sep 2007 perlapi.h -rw-r--r-- 1 root wheel 10800 23 Sep 2007 perlio.h -rw-r--r-- 1 root wheel 13734 23 Sep 2007 perliol.h -rw-r--r-- 1 root wheel 4867 23 Sep 2007 perlsdio.h -rw-r--r-- 1 root wheel 2537 23 Sep 2007 perlsfio.h -rw-r--r-- 1 root wheel 2443 23 Sep 2007 perlvars.h -rw-r--r-- 1 root wheel 1270 23 Sep 2007 perly.h -rw-r--r-- 1 root wheel 1215 23 Sep 2007 pldtrace.h -rw-r--r-- 1 root wheel 17703 23 Sep 2007 pp.h -rw-r--r-- 1 root wheel 10583 23 Sep 2007 pp_proto.h -rw-r--r-- 1 root wheel 95139 23 Sep 2007 proto.h -rw-r--r-- 1 root wheel 26087 23 Sep 2007 reentr.h -rw-r--r-- 1 root wheel 13339 23 Sep 2007 regcomp.h -rw-r--r-- 1 root wheel 4665 23 Sep 2007 regexp.h -rw-r--r-- 1 root wheel 9736 23 Sep 2007 regnodes.h -rw-r--r-- 1 root wheel 13300 23 Sep 2007 scope.h -rw-r--r-- 1 root wheel 48284 23 Sep 2007 sv.h -rw-r--r-- 1 root wheel 10353 23 Sep 2007 thrdvar.h -rw-r--r-- 1 root wheel 14379 23 Sep 2007 thread.h -rw-r--r-- 1 root wheel 135311 23 Sep 2007 uconfig.h -rw-r--r-- 1 root wheel 4280 23 Sep 2007 unixish.h -rw-r--r-- 1 root wheel 12339 23 Sep 2007 utf8.h -rw-r--r-- 1 root wheel 26969 23 Sep 2007 utfebcdic.h -rw-r--r-- 1 root wheel 1449 23 Sep 2007 util.h -rw-r--r-- 1 root wheel 3845 23 Sep 2007 warnings.h So yes indeed, this looks like a Perl version thing. I'm tempted to manually edit the makefile and change all references to 5.10.0 back to 5.8.8. Would that be a reasonable workaround? Burt. -------------- next part -------------- An HTML attachment was scrubbed... URL: From burt.crepeault at crulrg.ulaval.ca Wed Mar 31 10:32:40 2010 From: burt.crepeault at crulrg.ulaval.ca (=?ISO-8859-1?Q?Burt_Cr=E9peault?=) Date: Wed, 31 Mar 2010 10:32:40 -0400 Subject: [MINC-development] Building MINC for OS X 10.6 In-Reply-To: References: Message-ID: > So yes indeed, this looks like a Perl version thing. I'm tempted to > manually edit the makefile and change all references to 5.10.0 back to > 5.8.8. > > Would that be a reasonable workaround? > > Further down the rabbit hole, I did just that but got stopped again. Here's the full trace: neon:mni_perllib-0.08:# perl Makefile.PL PREFIX=/Users/burt/Desktop/build/install INSTALLDIRS=perl Default directory for model data [/usr/local/mni/data]? /Users/burt/Desktop/build/install/share/mni-models MakeMaker (v6.42) INSTALLDIRS => q[perl] NAME => q[mni_perllib] PMLIBDIRS => [q[MNI]] PREFIX => q[/Users/burt/Desktop/build/install] PREREQ_PM => { } VERSION_FROM => q[MNI.pm] clean => { FILES=>q[MNI/DataDir.pm t/datadir.t t/toy_ls] } dist => { COMPRESS=>q[gzip], SUFFIX=>q[gz] } Using PERL=/usr/bin/perl Makefile.PL: I don't grok the manifypods section, so can't tweak the pod2man args at Makefile.PL line 162. couldn't tweak pod2man command Writing Makefile for mni_perllib (changed all 5.10.0 references to 5.8.8 in the Makefile) neon:mni_perllib-0.08:# make make: *** No rule to make target `/System/Library/Perl/5.8.8/darwin-thread-multi-2level/Config.pm', needed by `Makefile'. Stop. -------------- next part -------------- An HTML attachment was scrubbed... URL: From burt.crepeault at crulrg.ulaval.ca Wed Mar 31 11:52:57 2010 From: burt.crepeault at crulrg.ulaval.ca (=?ISO-8859-1?Q?Burt_Cr=E9peault?=) Date: Wed, 31 Mar 2010 11:52:57 -0400 Subject: [MINC-development] Building MINC for OS X 10.6 In-Reply-To: References: Message-ID: On Wed, Mar 31, 2010 at 10:32, Burt Cr?peault < burt.crepeault at crulrg.ulaval.ca> wrote: > > >> So yes indeed, this looks like a Perl version thing. I'm tempted to >> manually edit the makefile and change all references to 5.10.0 back to >> 5.8.8. >> >> Would that be a reasonable workaround? >> >> > Further down the rabbit hole, I did just that but got stopped again. Here's > the full trace: > > neon:mni_perllib-0.08:# perl Makefile.PL > PREFIX=/Users/burt/Desktop/build/install INSTALLDIRS=perl > Default directory for model data [/usr/local/mni/data]? > /Users/burt/Desktop/build/install/share/mni-models > MakeMaker (v6.42) > INSTALLDIRS => q[perl] > NAME => q[mni_perllib] > PMLIBDIRS => [q[MNI]] > PREFIX => q[/Users/burt/Desktop/build/install] > PREREQ_PM => { } > VERSION_FROM => q[MNI.pm] > clean => { FILES=>q[MNI/DataDir.pm t/datadir.t t/toy_ls] } > dist => { COMPRESS=>q[gzip], SUFFIX=>q[gz] } > Using PERL=/usr/bin/perl > > Makefile.PL: I don't grok the manifypods section, so can't tweak the > pod2man args at Makefile.PL line 162. > couldn't tweak pod2man command > Writing Makefile for mni_perllib > > (changed all 5.10.0 references to 5.8.8 in the Makefile) > > neon:mni_perllib-0.08:# make > make: *** No rule to make target > `/System/Library/Perl/5.8.8/darwin-thread-multi-2level/Config.pm', needed by > `Makefile'. Stop. > > Don't you just love it when people ask difficult questions and find the solution themselves? It turned out the problem was with the Perl installation being not quite to par. I installed the latest version of Apple's XCode with all the options checked and everything built fine. Thanks. Burt. -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.janke at gmail.com Wed Mar 31 11:56:53 2010 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 1 Apr 2010 02:56:53 +1100 Subject: [MINC-development] Building MINC for OS X 10.6 In-Reply-To: References: Message-ID: > Don't you just love it when people ask difficult questions and find the > solution themselves? Absolutely. :) Means I can give up digging about documentation for the perl install on OSX now. -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883