[Ifeffit] Manual update to iXAFS

Bruce Ravel bravel at bnl.gov
Tue Aug 31 09:07:09 CDT 2010


On Tuesday 31 August 2010 02:19:50 am Paul Fons wrote:
> Hi Bruce,
> Regards from a far too hot Japan,
> 
> Thanks for the update suggestions for iXAFS Bruce.  I managed to get it to
>  work, but I found a couple of problems.
> 
> 
> 1.  There is another intermediate directory in your steps (3,4,5), e.g.  "
>  /Applications/iXAFS/Contents/Resources/bin" should read "
>  /Applications/iXAFS/Contents/Resources/Horae/bin"  The intermediate
>  directory Horae is missing in each case.

Thanks for catching that.  Obviously, I was not cutting and pasting
when I wrote that email.

> 2.  SVN is installed by default on the Mac.  When I tried to run the
>  mkartemis.pl and friends after downloading the latest svn release,
>  however, I found that the rc.pl files were missing.  How does one generate
>  these from the svn files?  I used a rc.pl from a horae-70 release I had
>  around and it apparently worked.

Good point.  Again, I was doing this while sitting next to my normal
computer -- this is one of the inevitable gaps.

The files rc.pl for both programs normally get generated at the "perl
Build.PL" stage of the installation (as do the files in the bin/
folder).  So you can either just run "perl Build.PL" or run the scripts
mkathenarc.PL and mkartemisrc.PL by hand.

Given that one, in fact, can upgrade the iXAFS installation by hand
starting from an svn export, it would be really great to have a script
that does all the steps to do the iXAFS update.  Given that, I could
incorporate it into the Build.PL file.  Then you could imagine
updating by doing an "svn export" followed by "perl Build.PL" followed
by "perl iXAFS-install" (or some such).  Given that svn and perl are
already on the computer, that would be a relatively low impact avenue
to an update.


> 3. The version numbers in the SVN release conflict within the files from
>  the SVN (at least when following the procedure you mentioned above).  Some
>  of the files from the SVN release have (ArtemisLog) $VERSION set to
>  0.8.014 while others (e.g. Group.pm had $VERSION = "0.0.8.061").  This
>  triggers an error in the athena and artemis of a version mismatch. I
>  "fixed" this by disabling the check, as the logic of the versioning is not
>  very clear from a simple examination of the files.  What should the
>  "$VERSION" string (and any other version related strings) be set to in
>  each of the files?

There has to be some confusion here.  What you describe cannot
possibly be correct as written.  Running from a terminal window, what
is written to the terminal when you see this conflict?

The way it works is that $VERSION for athena and Groups.pm have to
match, and $VERSION from artemis, Path.pm, ArtemisLog.pm, and
Parameter.pm have to match.  But one group does not have to match the
other.


>  In any case it work, but it sure would be nice to have a nice new
> 	official release!

I concur, but it would be nice to have an updater to incorporate into
the Build script.  Any takers?  It doesn't even need to be written in
perl (althoguh that would be easier to maintain).

B

-- 

 Bruce Ravel  ------------------------------------ bravel at bnl.gov

 National Institute of Standards and Technology
 Synchrotron Methods Group at NSLS --- Beamlines U7A, X24A, X23A2
 Building 535A
 Upton NY, 11973

 My homepage:    http://xafs.org/BruceRavel
 EXAFS software: http://cars9.uchicago.edu/~ravel/software/exafs/



More information about the Ifeffit mailing list