Hi folks, I am pleased to announce a new version of Athena today. The source code tarball and windows executable are on my web site. Today's version offers three significant new features: 1. A fairly major user-interface change 2. The ability to fetch data files from web sites 3. An improved merging algorithm Please note that I am making use of a very recent feature of Ifeffit (the "nofx" array function) in the new merging algorithm. Windows users need to update to the version of the big Ifeffit installer from January 22, 2003. Linux, Unix and OSX users should be using Ifeffit version 1.0076 or later. The Windows installer and the ifeffit source code can be found at Matt's web site http://cars9.uchicago.edu/ifeffit/download.html If you are not running Ifeffit 1.0076 or later, then merging WILL NOT WORK in Athena 0.8.014. So, please, upgrade. I'll describe each of those features in detail below. I'd like to specifically thank Matt (who suggested the web thing) and Adam Web (who pointed out a problem with the merging algorithm). I'd also like to mention to all the people who have been asking for PCA in Athena that it's moving closer to the front of my TODO list. The change to the user interface is needed to be able to put PCA into Athena in a sensible manner. Regards B The details about each new feature: 1. Although the user interface change is pretty significant, I think it will be easy for current users to adapt to. Indeed, I think most people will appreciate the added functionality that the change allows. In earlier versions of Athena, data processing and analysis chores such as alignment, calibration, and log-ratio were done by interacting with a special dialog that popped up in a separate window. This separate window performed a grab, which means that you could not interact with the main window until you were done with the dialog and had dismissed it. Now, each of the various chores that previously used a pop-up dialog works by replacing the main part of the main window with the dialog specific to that analysis chore. Thus, when you, say, go to align data, the part of the main window where you specify background removal and Fourier transform parameters gets replaced by various menus and entry boxes relevant to that chore. If that's not clear, check out the new screenshots at http://leonardo.phys.washington.edu/~ravel/software/exafs/screenshots.html#a... There are screenshots showing each of the eight alternate views in Athena. Not only does this reduce the number of windows that Athena throws up on the screen, it also allows you to use the groups list and the plotting buttons while one of the alternate views is displayed. For example, you can now view one or more data groups in R-space *while* aligning. Chores like alignment and difference spectra which require specifying a second data data group now work by selecting the second data group from the group list. 2. You can now read data files from web sites using an extremely primitive interface. In the File menu, there is an item which says "Open URL". When you select this, the Echo area at the bottom of the screen gets replaced by a bright orange text entry box. If you type in the fully resolved URL of a data file somewhere on the web, Athena will fetch and import that file. This is not extremely convenient because you have to type in the exact URL (or use cut and paste, of course). I have not (yet) implemented a mouse-driven browser of any sort. I may in the future if this feature proves popular. One helpful feature I did implement is that Athena keeps a history of files downloaded during the current Athena session. If you hit the up or down arrows while the URL text entry box has the focus, you will scroll up and down in the history of fetched data files. If you want to try it, I put some iron foil data on my web site. Enter this URL in the orange box: http://leonardo.phys.washington.edu/~ravel/misc/fe.060 This feature will work for Windows users. It will work for other platforms only if you have the LWP perl modules installed. Because that is a very large and frequently changing package, I am not comfortable distributing it with the horae package. If you are a linux, unix, or OSX user and the "Open URL" thing is greyed out, then you will need to install LWP. You can grab the latest version of the Bundle::LWP package from http://search.cpan.org/author/GAAS/libwww-perl-5.69/ Alternately, you can use perl's CPAN interface. At the command line, type perl -MCPAN -e shell then at the CPAN prompt type install Bundle::LWP 3. The merging algorithm has changed. Before, the marked data groups were merged after interpolating them onto the abscissa grid of the first marked group in the groups list. Now, Athena determines what is the longest abscissa range common to all marked groups. The reason for this change is that the prior algorithm would extrapolate if a marked group had a shorter abscissa range than the first group. Often this isn't a problem, but it can lead to very strange and undesirable results in the merged data. I am modestly confident that I have merging working correctly again in all cases. I encourage anyone using the merging algorithm to send me a project file if they suspect that bugs remain. -- Bruce Ravel ----------------------------------- ravel@phys.washington.edu Code 6134, Building 3, Room 222 Naval Research Laboratory phone: (1) 202 767 5947 Washington DC 20375, USA fax: (1) 202 767 1697 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b, X24c, U4b National Synchrotron Light Source Brookhaven National Laboratory, Upton, NY 11973 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/
Bruce: Now I am getting the runtime problems that I reported in January again. Here is the full description of the problems. By the way, I am using perl version 5.6.1 and a Debian Linux "testing" distribution. I am starting with a clean system, that is, all Ifeffit, Atoms and horae files in /usr/local have been purged. 1. I install ifeffit 1.0076 (latest version) with ./configure make make install 2. I install the Ifeffit python extensions python setup.py install 3. I install Atoms with perl Makefile.PL make make install 4. I install horae perl Makefile.PL make make install This seems to be the propoer procedure. tkatoms works fine but here the problems begin... When I try to run athena I get ------------------------------------------------------------------------- Can't load '/usr/local/lib/perl/5.6.1/auto/Ifeffit/Ifeffit.so' for module Ifeffit: /usr/local/lib/perl/5.6.1/auto/Ifeffit/Ifeffit.so: undefined symbol: pgqndt_ at /usr/lib/perl/5.6.1/DynaLoader.pm line 202. at /usr/local/bin/athena line 55 Compilation failed in require at /usr/local/bin/athena line 55. BEGIN failed--compilation aborted at /usr/local/bin/athena line 63. ------------------------------------------------------------------------- When I try to run gifeffit I get ------------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/bin/gifeffit", line 2, in ? import GIFeffit, sys File "/usr/lib/python2.1/site-packages/Ifeffit/GIFeffit.py", line 27, in ? from Ifeffit import Ifeffit File "/usr/lib/python2.1/site-packages/Ifeffit/Ifeffit.py", line 46, in ? import _ifeffit, types, cmd, os, sys ImportError: /usr/lib/python2.1/site-packages/Ifeffit/_ifeffit.so: undefined symbol: pgqndt_ -------------------------------------------------------------------------- Note that the problem seems to be with the symbol "pgqndt_" in both cases and I believe that this has to do with ifeffit (and pgplot?). Now, I clean up the system and reinstall in exactly the same way but using ifeffit 1.0075a. gifeffit works fine now but athena gives the same error as before. I can get athena to work by installing the ifeffit perl wrappers, however. As a final test, I take the working installation and install ifeffit 1.0076 on top of it. athena continues to work now as does gifeffit. Note that I have not installed either the python or perl wrappers in ifeffit 1.0076. With trepidation I now install the python wrappers and the perl wrappers and... neither gifeffit nor athena loads and I get the errors marked above. So, to summarize this drawn out procedure: I cannot install on a clean system with the latest versions of ifeffit and horae. I can install ifeffit 1.0075a AND its wrappers and horae and then upgrade to ifeffit 1.0076 and still get functioning programs but woe is me if I install wrappers from ifeffit 1.0076. Well, that is all for now, I am about to clean up the system and install again so it works! Carlo On Fri, 28 Feb 2003, Bruce Ravel wrote:
Hi folks,
I am pleased to announce a new version of Athena today. The source code tarball and windows executable are on my web site. Today's version offers three significant new features:
-- Carlo U. Segre -- Professor of Physics Associate Dean for Research, Armour College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre@iit.edu http://www.iit.edu/~segre
On Tuesday 04 March 2003 01:47 am, Carlo U. Segre wrote:
Bruce:
Now I am getting the runtime problems that I reported in January again.
<<snip>>
When I try to run athena I get
------------------------------------------------------------------------- Can't load '/usr/local/lib/perl/5.6.1/auto/Ifeffit/Ifeffit.so' for module Ifeffit: /usr/local/lib/perl/5.6.1/auto/Ifeffit/Ifeffit.so: undefined symbol: pgqndt_ at /usr/lib/perl/5.6.1/DynaLoader.pm line 202. at /usr/local/bin/athena line 55 Compilation failed in require at /usr/local/bin/athena line 55. BEGIN failed--compilation aborted at /usr/local/bin/athena line 63. -------------------------------------------------------------------------
When I try to run gifeffit I get
------------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/bin/gifeffit", line 2, in ? import GIFeffit, sys File "/usr/lib/python2.1/site-packages/Ifeffit/GIFeffit.py", line 27, in ? from Ifeffit import Ifeffit File "/usr/lib/python2.1/site-packages/Ifeffit/Ifeffit.py", line 46, in ? import _ifeffit, types, cmd, os, sys ImportError: /usr/lib/python2.1/site-packages/Ifeffit/_ifeffit.so: undefined symbol: pgqndt_ --------------------------------------------------------------------------
Note that the problem seems to be with the symbol "pgqndt_" in both cases and I believe that this has to do with ifeffit (and pgplot?).
If the error message complains about a missing symbol beginning with "pg", then the problem is almost certainly that either (1) pgplot has not been installed or (2) ifeffit failed to figure out where pgplot was at the "./configure" step of the ifeffit installation. What you need to do is either (1) install pgplot again, paying close attention to where it gets installed or (2) figure out where pgplot is, in fact, installed on your system. FWIW, on my computer, pgplot is in /usr/local/pgplot/. Now go back to the ifeffit installation step. At the ./configure step, you see lots of cryptic stuff spewed to the screen. About 30 lines into all this, you should see a line like this: will link to PGPLOT using -L/usr/local/pgplot/ -lpgplot -lpng -lz -L/usr/X11R6/lib -lX11 Then at the end, you see something like this: === ifeffit 1.0076 Configuration Results: === linking to PGPLOT with: -L/usr/local/pgplot/ -lpgplot -lpng -lz -L/usr/X11R6/lib -lX11 If Ifeffit's configure cannot find the pgplot libraries, you will, instead, see something like this: will link to PGPLOT using /home/bruce/codes/ifeffit_1.0b/src/pgstub/libnopgplot.a Then at the end, it'll report === ifeffit 1.0076 Configuration Results: === linking to PGPLOT with: /home/bruce/codes/ifeffit_1.0b/src/pgstub/libnopgplot.a The idea is that ifeffit does a lot of stuff other than plotting. Without pgplot, ifeffit can still be useful. To that end, Matt has provided a simple stub that mimics the pgplot interface, but doesn't do anything. This lets ifeffit get compiled and run, but when you try to plot, bad things happen. Both Athena and GIfeffit expect to be able to plot and so an ifeffit library compiled against the stub leads to problems. If you ever see the messages about "libnopgplot.a", that is a signal that you need to resolve the pgplot problem. Usually, installing pgplot using Matt's `PGPLOT_install' script then building Ifeffit is sufficient. However, if pgplot is installed someplace that Ifeffit's configure script is having trouble finding, you can force the issue by doing ./configure --pgplot-dir=/actual/path/to/pgplot as the first step in the ifeffit build.
Now, I clean up the system and reinstall in exactly the same way but using ifeffit 1.0075a. gifeffit works fine now but athena gives the same error as before. I can get athena to work by installing the ifeffit perl wrappers, however.
That's mysterious and suggests that your system wasn't as purged as you thought ;-) Let me know if all that helps, B -- Bruce Ravel ----------------------------------- ravel@phys.washington.edu Code 6134, Building 3, Room 222 Naval Research Laboratory phone: (1) 202 767 5947 Washington DC 20375, USA fax: (1) 202 767 1697 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b, X24c, U4b National Synchrotron Light Source Brookhaven National Laboratory, Upton, NY 11973 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/
Bruce: As you pointed and I sort of expected, although I didn't pay enough attention to the output of the ifeffit configure step, ifeffit 1.0076 is not finding my pgplot installation. The part that fooled me was that up to 1.0076, ifeffit found pgplot with no problem. That is why the perl wrappers from 1.0075a keep things sort of working. I am using a Debian system with pgplot5 installed as a distribution package, so I prefer not to install another version in /usr/local. I will be able to keep things working with the --with-pgplot= command but I wanted to report that something that used to work in ifeffit 1.0075a is no longer working in 1.0076. Upon reflection, I should have addressed this to Matt :) Carlo On Tue, 4 Mar 2003, Bruce Ravel wrote:
On Tuesday 04 March 2003 01:47 am, Carlo U. Segre wrote:
------------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/bin/gifeffit", line 2, in ? import GIFeffit, sys File "/usr/lib/python2.1/site-packages/Ifeffit/GIFeffit.py", line 27, in ? from Ifeffit import Ifeffit File "/usr/lib/python2.1/site-packages/Ifeffit/Ifeffit.py", line 46, in ? import _ifeffit, types, cmd, os, sys ImportError: /usr/lib/python2.1/site-packages/Ifeffit/_ifeffit.so: undefined symbol: pgqndt_ --------------------------------------------------------------------------
Note that the problem seems to be with the symbol "pgqndt_" in both cases and I believe that this has to do with ifeffit (and pgplot?).
If the error message complains about a missing symbol beginning with "pg", then the problem is almost certainly that either (1) pgplot has not been installed or (2) ifeffit failed to figure out where pgplot was at the "./configure" step of the ifeffit installation.
What you need to do is either (1) install pgplot again, paying close attention to where it gets installed or (2) figure out where pgplot is, in fact, installed on your system. FWIW, on my computer, pgplot is in /usr/local/pgplot/.
Now go back to the ifeffit installation step. At the ./configure step, you see lots of cryptic stuff spewed to the screen. About 30 lines into all this, you should see a line like this:
will link to PGPLOT using -L/usr/local/pgplot/ -lpgplot -lpng -lz -L/usr/X11R6/lib -lX11
-- Carlo U. Segre -- Professor of Physics Associate Dean for Research, Armour College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre@iit.edu http://www.iit.edu/~segre
Hi Carlo, Yes, the problem you're seeing is almost certainly due to the debian PGPLOT package providing a shared library (libpgplot.so) which the compiler sees at compile time but the loader cannot find at run time. An easy way to check this (on linux, darwin, and a few other unix-like systems) is to do ldd /usr/local/bin/ifeffit which will list all shared libraries this exe will try to load. If the comiler has tried to use a shared library, it will be listed. If the loader can find it, the actual path to the shared library will be given. If it can't be found, that will be stated, and the exe will fail when trying to use anything from that library. There are a few possible solutions. One option is to not use the debian PGPLOT package, but use my PGPLOT_INSTALL instead. This makes sure the shared object is deleted, so that ifeffit will build with the static library. Another option is to copy the shared object to somewhere it can be found by the system -- /usr/lib always works, and /usr/local/lib usually works too. A final option is to tell the loader where to look for shared objects. On linux, the list is in /etc/ld.so.conf. Edit this file to include /usr/local/lib, and/or /usr/local/pgplot, and then run /sbin/ldconfig. You will probably also need to run ldd on /usr/lib/perl5.6/..../auto/Ifeffit/Ifeffit.so /usr/lib/python.../site-packages/Ifeffit/_ifeffit.so to make sure that these can see libpgplot.so as well. It seems strange that Debian would distribute a PGPLOT package that provides a shared-object in a place that does not work. What other packages rely on the PGPLOT package? Do those work? A positive aspect of all of this is that if Debian and Fink are both distributing binary packages of PGPLOT, then I could probably distribute my own PGPLOT binaries (say for linux and darwin) to be used in the Ifeffit build process. That would be a little bit of work, and there seem to be no volunteers, so it won't happen immediately. Frankly, I view this as a low priority compared to fixing the Mac OS X build issues. --Matt
Matt: Yes, I agree and using the --with-pgplot=/usr/lib/pgplot5/ option fixes things. The only confusion I have is why version 1.0075a seemed to work correctly. Oh, well. Carlo On Tue, 4 Mar 2003, Matt Newville wrote:
Hi Carlo,
Yes, the problem you're seeing is almost certainly due to the debian PGPLOT package providing a shared library (libpgplot.so) which the compiler sees at compile time but the loader cannot find at run time. An easy way to check this (on linux, darwin, and a few other unix-like systems) is to do ldd /usr/local/bin/ifeffit
which will list all shared libraries this exe will try to load. If the comiler has tried to use a shared library, it will be listed. If the loader can find it, the actual path to the shared library will be given. If it can't be found, that will be stated, and the exe will fail when trying to use anything from that library.
There are a few possible solutions. One option is to not use the debian PGPLOT package, but use my PGPLOT_INSTALL instead. This makes sure the shared object is deleted, so that ifeffit will build with the static library. Another option is to copy the shared object to somewhere it can be found by the system -- /usr/lib always works, and /usr/local/lib usually works too. A final option is to tell the loader where to look for shared objects. On linux, the list is in /etc/ld.so.conf. Edit this file to include /usr/local/lib, and/or /usr/local/pgplot, and then run /sbin/ldconfig.
You will probably also need to run ldd on
/usr/lib/perl5.6/..../auto/Ifeffit/Ifeffit.so /usr/lib/python.../site-packages/Ifeffit/_ifeffit.so
to make sure that these can see libpgplot.so as well.
It seems strange that Debian would distribute a PGPLOT package that provides a shared-object in a place that does not work. What other packages rely on the PGPLOT package? Do those work?
A positive aspect of all of this is that if Debian and Fink are both distributing binary packages of PGPLOT, then I could probably distribute my own PGPLOT binaries (say for linux and darwin) to be used in the Ifeffit build process. That would be a little bit of work, and there seem to be no volunteers, so it won't happen immediately. Frankly, I view this as a low priority compared to fixing the Mac OS X build issues.
--Matt
-- Carlo U. Segre -- Professor of Physics Associate Dean for Research, Armour College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre@iit.edu http://www.iit.edu/~segre
Carlo, On Tue, 4 Mar 2003, Carlo U. Segre wrote:
Matt:
Yes, I agree and using the --with-pgplot=/usr/lib/pgplot5/ option fixes things. The only confusion I have is why version 1.0075a seemed to work correctly. Oh, well.
I'm a little confused about what works and what doesn't. You said ./configure ; make ; make install made executables could not find the PGPLOT library supplied by Debian. You did not say what './configure' reported it would use for PGPLOT. Now you seem to be saying that ./configure --with-pgplot=/usr/lib/pgplot5 make install works. Is that correct? The script used by configure to look for PGPLOT installations could be changed to look for /usr/local/pgplot5 if that's where Debian puts it. It's possible that this changed betweeen 1.0075 and 1.0076 -- I did change some of these scripts. To make this change, I would have to hear where Debian puts PGPLOT. PGPLOT_install works on linux, and I'm willing to try to get it to work on any system. But it's very difficult to ensure that a PGPLOT binary made by someone else will work with Ifeffit, and I have no idea what's in the Debian PGPLOT package. If it happens to work, that's great, but I really can't support it. --Matt
Matt: I bit the bullet last night and made a stab at an IFEFFIT Debian package. By the end of the evening (or beginning of the morning if you will) I had two functioning, but certainly not complete packages of ifeffit for the woody (stable) and sarge (testing) Debian distributions. They do not, at this point in time, include any of the wrappers (I have yet to figure out how to do this) and are compile only for i386 architecture. According to Debian policy, they install in /usr rather than /usr/local. They seem to work with the latest installation of Athena and Artemis but I am still in the process of testing them. It should be possible to use the Debian alien program to comvert them to RPMs as well. I will keep you updated on my progress and when I am sure that they aren't incredibly broken, I will be happy to make them available. Carlo On Tue, 4 Mar 2003, Matt Newville wrote:
Hi Carlo,
Yes, the problem you're seeing is almost certainly due to the debian PGPLOT package providing a shared library (libpgplot.so) which the compiler sees at compile time but the loader cannot find at run time. An easy way to check this (on linux, darwin, and a few other unix-like systems) is to do ldd /usr/local/bin/ifeffit
which will list all shared libraries this exe will try to load. If the comiler has tried to use a shared library, it will be listed. If the loader can find it, the actual path to the shared library will be given. If it can't be found, that will be stated, and the exe will fail when trying to use anything from that library.
There are a few possible solutions. One option is to not use the debian PGPLOT package, but use my PGPLOT_INSTALL instead. This makes sure the shared object is deleted, so that ifeffit will build with the static library. Another option is to copy the shared object to somewhere it can be found by the system -- /usr/lib always works, and /usr/local/lib usually works too. A final option is to tell the loader where to look for shared objects. On linux, the list is in /etc/ld.so.conf. Edit this file to include /usr/local/lib, and/or /usr/local/pgplot, and then run /sbin/ldconfig.
You will probably also need to run ldd on
/usr/lib/perl5.6/..../auto/Ifeffit/Ifeffit.so /usr/lib/python.../site-packages/Ifeffit/_ifeffit.so
to make sure that these can see libpgplot.so as well.
It seems strange that Debian would distribute a PGPLOT package that provides a shared-object in a place that does not work. What other packages rely on the PGPLOT package? Do those work?
A positive aspect of all of this is that if Debian and Fink are both distributing binary packages of PGPLOT, then I could probably distribute my own PGPLOT binaries (say for linux and darwin) to be used in the Ifeffit build process. That would be a little bit of work, and there seem to be no volunteers, so it won't happen immediately. Frankly, I view this as a low priority compared to fixing the Mac OS X build issues.
--Matt
-- Carlo U. Segre -- Professor of Physics Associate Dean for Research, Armour College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre@iit.edu http://www.iit.edu/~segre
Hi Carlo, At the risk of being the obnoxious guy who's always chock-full of ideas for work that other people can do .... I'd like to recommend that, once you are happy with your .debs, you do a bit more work. Ifeffit and my codes are, as you well know, ongoing and frequently updated projects. The problem with any given .deb (or .rpm or whatever) is that it is prone to fall out of date rather quickly. I would strongly encourage you to automate *fully* the process of building your .debs. Both Matt and I put our source packages in predictable places and under predictable names. For example, the ifeffit tarball is always in http://cars9.uchicago.edu/ifeffit/src/ and is always called "ifeffit-X.XXXX.tar.gz", where X.XXXX is the version number. I do the similar thing with the horae tarballs. You could have a cron job that checks the web sites every night to see if the tarballs have been updated (easy to do since the tarballs follow well-defined naming conventions). If they have been, then have the cron job 1. download the latest 2. build the .deb from the tarball 3. upload the new .deb to a web site and perhaps 4. send an short, auto-generated note to the mailing list saying that the new .deb is in place I think you would appreciate having done the work of automation during one of those weeks where someone finds a bug in my code a few hours after I make a new release (it's happened more than once ;-), and I make a new release the next day. I would, unsurprisingly, make the same suggstion of anyone else out there in ifeffit-land who wants to make, say, Red Hat .rpms or Fink .debs or whatever. B -- Bruce Ravel ----------------------------------- ravel@phys.washington.edu Code 6134, Building 3, Room 222 Naval Research Laboratory phone: (1) 202 767 5947 Washington DC 20375, USA fax: (1) 202 767 1697 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b, X24c, U4b National Synchrotron Light Source Brookhaven National Laboratory, Upton, NY 11973 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/
I shall certainly do that once I figure out the entire process. The next step form me now is to figure out how to make horae and Atoms packages. Carlo On Wed, 5 Mar 2003, Bruce Ravel wrote:
Hi Carlo,
At the risk of being the obnoxious guy who's always chock-full of ideas for work that other people can do ....
I'd like to recommend that, once you are happy with your .debs, you do a bit more work. Ifeffit and my codes are, as you well know, ongoing and frequently updated projects. The problem with any given .deb (or .rpm or whatever) is that it is prone to fall out of date rather quickly. I would strongly encourage you to automate *fully* the process of building your .debs.
Both Matt and I put our source packages in predictable places and under predictable names. For example, the ifeffit tarball is always in http://cars9.uchicago.edu/ifeffit/src/ and is always called "ifeffit-X.XXXX.tar.gz", where X.XXXX is the version number. I do the similar thing with the horae tarballs.
You could have a cron job that checks the web sites every night to see if the tarballs have been updated (easy to do since the tarballs follow well-defined naming conventions). If they have been, then have the cron job 1. download the latest 2. build the .deb from the tarball 3. upload the new .deb to a web site and perhaps 4. send an short, auto-generated note to the mailing list saying that the new .deb is in place
I think you would appreciate having done the work of automation during one of those weeks where someone finds a bug in my code a few hours after I make a new release (it's happened more than once ;-), and I make a new release the next day.
I would, unsurprisingly, make the same suggstion of anyone else out there in ifeffit-land who wants to make, say, Red Hat .rpms or Fink .debs or whatever.
B
-- Carlo U. Segre -- Professor of Physics Associate Dean for Research, Armour College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre@iit.edu http://www.iit.edu/~segre
Bruce, Matt: I have made some significant progress today. I now have installable Debian packages for ifeffit, atoms and horae. They seem to function correctly as a unit but I have not tested them thoroughly as yet. I do have a couple of questions for Bruce. These relate to perl modules included in horae and duplicate files between atoms and horae. If you can give me some guidance on what to do, the horae package will install more smoothly. 1. horae overwrites two files which are already in atoms ./bin/tkpod ./share/man/man3/Chemistry::Elements.3pm.gz Are these different files in the two programs? Is there are good reason why they need to be in horae since horae seems to depend on atoms being installed (at least that is how I would like to structure Debian dependencies)? If they can safely be removed from horae, what is the best way to modify the source tree for this purpose? 2. horae has the Tie-Watch perl module included which is in the standard Debian perl-tk package. Is your version significantly different that the stock version? if not, what will be the best way to remove it from teh distribution since horae should be dependent on perl-tk being installed anyway? 3. horae seems to rewrite another module which is in perl-tk ./lib/perl5/Tk/FBox.pm Again, is this different than the stock version and how can it be removed from the source distribution for Debian packaging? After resolving these issues, I will move on to producing a gifeffit installtion and getting the documentation properly installed as well. In the meantime, I can force the installation and at least test the executables. Thanks in advance... Carlo On Wed, 5 Mar 2003, Bruce Ravel wrote:
Hi Carlo,
At the risk of being the obnoxious guy who's always chock-full of ideas for work that other people can do ....
I'd like to recommend that, once you are happy with your .debs, you do a bit more work. Ifeffit and my codes are, as you well know, ongoing and frequently updated projects. The problem with any given .deb (or .rpm or whatever) is that it is prone to fall out of date rather quickly. I would strongly encourage you to automate *fully* the process of building your .debs.
Both Matt and I put our source packages in predictable places and under predictable names. For example, the ifeffit tarball is always in http://cars9.uchicago.edu/ifeffit/src/ and is always called "ifeffit-X.XXXX.tar.gz", where X.XXXX is the version number. I do the similar thing with the horae tarballs.
You could have a cron job that checks the web sites every night to see if the tarballs have been updated (easy to do since the tarballs follow well-defined naming conventions). If they have been, then have the cron job 1. download the latest 2. build the .deb from the tarball 3. upload the new .deb to a web site and perhaps 4. send an short, auto-generated note to the mailing list saying that the new .deb is in place
I think you would appreciate having done the work of automation during one of those weeks where someone finds a bug in my code a few hours after I make a new release (it's happened more than once ;-), and I make a new release the next day.
I would, unsurprisingly, make the same suggstion of anyone else out there in ifeffit-land who wants to make, say, Red Hat .rpms or Fink .debs or whatever.
B
-- Carlo U. Segre -- Professor of Physics Associate Dean for Research, Armour College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre@iit.edu http://www.iit.edu/~segre
Hi Carlo, Just about everything you are asking about involved some history. In each case, your guess for what to do is the right thing.
1. horae overwrites two files which are already in atoms ./bin/tkpod ./share/man/man3/Chemistry::Elements.3pm.gz Are these different files in the two programs? Is there are good reason why they need to be in horae since horae seems to depend on atoms being installed (at least that is how I would like to structure Debian dependencies)? If they can safely be removed from horae, what is the best way to modify the source tree for this purpose?
Not different. Each tarball has a copy so that one can be installed without the other. Eventually I intend for atoms to be rolled into the other tarball.... eventually....
2. horae has the Tie-Watch perl module included which is in the standard Debian perl-tk package. Is your version significantly different that the stock version? if not, what will be the best way to remove it from teh distribution since horae should be dependent on perl-tk being installed anyway?
Tie::Watch was not a standard part of perl 5.6 but it is with 5.8. I started using Tie::Watch while I was still using 5.6 on my computers. If you make your .deb dependent on a deb of 5.8 then Tie::Watch should not be necessary.
3. horae seems to rewrite another module which is in perl-tk ./lib/perl5/Tk/FBox.pm Again, is this different than the stock version and how can it be removed from the source distribution for Debian packaging?
I don't like how FBox.pm works and at one time had a notion of rewriting it. I have made my peace with what I see as flawed behavior but never thought to remove FBox from the tarball. Go ahead and do so. One of the nice things about perl build and install routines is that it deals well with these situations. I suppose that is why I never needed to deal with any of them myself. B -- Bruce Ravel ----------------------------------- ravel@phys.washington.edu Code 6134, Building 3, Room 222 Naval Research Laboratory phone: (1) 202 767 5947 Washington DC 20375, USA fax: (1) 202 767 1697 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b, X24c, U4b National Synchrotron Light Source Brookhaven National Laboratory, Upton, NY 11973 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/
Bruce: What I plan to do is not to modify the tarball at all but just the Makefiles (I hope). The way the Debian packages work is to keep the original tarball, patch in the differences that the package maintainer makes and then do the installation. This way, when a new tarball comes out from you or Matt, there is a chance that the patches will work right out of the box with not much extra effort. Carlo On Thu, 6 Mar 2003, Bruce Ravel wrote:
Hi Carlo,
Just about everything you are asking about involved some history. In each case, your guess for what to do is the right thing.
1. horae overwrites two files which are already in atoms ./bin/tkpod ./share/man/man3/Chemistry::Elements.3pm.gz Are these different files in the two programs? Is there are good reason why they need to be in horae since horae seems to depend on atoms being installed (at least that is how I would like to structure Debian dependencies)? If they can safely be removed from horae, what is the best way to modify the source tree for this purpose?
Not different. Each tarball has a copy so that one can be installed without the other. Eventually I intend for atoms to be rolled into the other tarball.... eventually....
2. horae has the Tie-Watch perl module included which is in the standard Debian perl-tk package. Is your version significantly different that the stock version? if not, what will be the best way to remove it from teh distribution since horae should be dependent on perl-tk being installed anyway?
Tie::Watch was not a standard part of perl 5.6 but it is with 5.8. I started using Tie::Watch while I was still using 5.6 on my computers. If you make your .deb dependent on a deb of 5.8 then Tie::Watch should not be necessary.
3. horae seems to rewrite another module which is in perl-tk ./lib/perl5/Tk/FBox.pm Again, is this different than the stock version and how can it be removed from the source distribution for Debian packaging?
I don't like how FBox.pm works and at one time had a notion of rewriting it. I have made my peace with what I see as flawed behavior but never thought to remove FBox from the tarball. Go ahead and do so.
One of the nice things about perl build and install routines is that it deals well with these situations. I suppose that is why I never needed to deal with any of them myself.
B
-- Carlo U. Segre -- Professor of Physics Associate Dean for Research, Armour College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre@iit.edu http://www.iit.edu/~segre
participants (3)
-
Bruce Ravel -
Carlo U. Segre -
Matt Newville