Re: [Ifeffit] Demeter on Ubuntu 14.04
Bruce, thanks for looking into that. And my apologies for the dodgy and incomplete bug report. Right to the point: - the command env | grep LC returns nothing... - the command: perl -e 'printf("%.3f\n", 5.23456)' returned 5.23456. So you're stumped, right? :-) - but env | grep LANG returns: LANG=fr_FR.UTF-8 GDM_LANG=fr_FR LANGUAGE=fr_FR So your trick to export language variables to en_US did it. And _solved my problem_. So thank you. I'd like to raise a related issue to complete my initial bug report and try to understand better those problems (which could occur again in the future). To install demeter initially (last year I think) I followed this procedure: https://gist.github.com/waveform80/3959252 One thing that I could not understand (and still cannot, it is somehow beyond my limited knowledge of linux) are the subtle differences between installing the code locally or system-wide and in particular this cryptic (to me) command: eval $(perl -I$HOME/perl5/lib/perl5 -Mlocal::lib) Indeed, the procedure I followed created a perl5 folder in my home folder. That is the reason why, when I mentionned that I erased all the folders to reinstall everything, I was referring to the folders demeter and perl5 in my home folder, as suggested in the 'Removing installation' chapter in the same page. And I'm pretty sure that many of my problems are related to that. As always, being a numb, I tried different fixes, in particular a root installation. Everything is probably a mixture of approximate fixes now and makes it hard to source the problems. The thing is I actually don't need this perl5 folder anymore. Everything now runs smoothly (with the en_US LANGUAGE trick), but I sometimes have warning messages (in dathena for example) that it can't locate Encoding/FixLatin/XS.pm in @INC for example. I copied the file from the local perl5 folder to the system wide folder in /usr/local/lib and the warning disappeared. In fact I was wondering if I should reinstall from zero with a system-wide install, or if the local install made sense in some situations. As I understood it at the time, it was to be able to erase the local perl install. Sorry for the long message. The bottom line is that you unlocked my situation. Cheers denis Le 29/05/2014 16:40, ifeffit-request@millenia.cars.aps.anl.gov a écrit :
Send Ifeffit mailing list submissions to ifeffit@millenia.cars.aps.anl.gov
To subscribe or unsubscribe via the World Wide Web, visit http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit or, via email, send a message with subject or body 'help' to ifeffit-request@millenia.cars.aps.anl.gov
You can reach the person managing the list at ifeffit-owner@millenia.cars.aps.anl.gov
When replying, please edit your Subject line so it is more specific than "Re: Contents of Ifeffit digest..."
Today's Topics:
1. Re: Demeter on Ubuntu 14.04 (Bruce Ravel) 2. Re: Demeter on Ubuntu 14.04 (Bruce Ravel) 3. Fitting EXAFS simulation to experimental (Carl Brozek) 4. Re: Fitting EXAFS simulation to experimental (Bruce Ravel) 5. Re: Fitting EXAFS simulation to experimental (Scott Calvin)
----------------------------------------------------------------------
Message: 1 Date: Wed, 28 May 2014 14:24:06 -0400 From: Bruce Ravel
To: XAFS Analysis using Ifeffit Subject: Re: [Ifeffit] Demeter on Ubuntu 14.04 Message-ID: <538629C6.7080907@bnl.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi Denis,
On 05/26/2014 10:11 AM, Denis Testemale wrote:
Context: I'm running Ubuntu 64 bits 14.04. Demeter version 0.9.20. I followed Ubuntu specific instructions found here: https://gist.github.com/3959252 Demeter once worked but I cannot guarantee that it did just before the upgrade to 14.04. After the upgrade, both trying to run dathena or to rebuild the package ran into errors such as: These:
denis@huchet4:~/demeter$ ./Build Building Demeter Perl API version v5.14.0 of DateTime does not match v5.18.0 at /usr/share/perl/5.18/XSLoader.pm line 92. ... etc... and denis@huchet4:~/demeter$ dathena Perl API version v5.14.0 of Wx does not match v5.18.0 at /usr/lib/perl/5.18/DynaLoader.pm line 207. ... etc... mean that you had built the DateTime and Wx modules for an older version of perl. The compiled bits are not, in general, forward compatible. That is, when a new version of perl is installed, the various modules must be rebuilt. This is the sort of thing that package managers (like apt-get) take care of and why it would be lovely if a package for Demeter existed.
In your case, I suspect that you ran "./Build installdeps" once upon a time when you have perl 5.14 on your computer. Normally, running "./Build installdeps" again would do the right thing because it would install to a version-specific subdirectory in someplace like /usr/local/lib/perl/.
You didn't tell me what "perl -V" had to say, so I can only guess why that didn't work for you. My best guess is that you instruct the perl Build script to install to some location in your home directory and then you have modified perl's include list.
That is, when you say
So I erased the folders and reinstalled everything. I presume that "the folders", whatever you mean by that, are something other than the system folder that perl would normally install into. Of course, it is hard for me to know for sure because you have not provided enough information to diagnose the problem.
The installation ran smoothly (except I had to install missing deps several times, but no error messages at the end). Now I can start the programs but run into problems:
Attribute (bkg_nc0) does not pass the type constraint because: Validation failed for 'LaxNum' with value 0,00000000000000 at /usr/local/lib/perl/5.18.2/Moose/Exception.pm line 37 This appears to be a localization problem. In fact, it is true that "0,000" is not a number when a dot is expected as a decimal point.
I am guessing that you have LC_ALL or LC_NUMERIC set to something like "fr_FR" and that is causing some module used by Demeter to use French localization for formatting a character string intended to represent a number. The reason I suspect this is because your stack trace points to a line of code that looks like this:
$self->bkg_nc0(sprintf("%.14f", $self->fetch_scalar("norm_c0")));
The fetch_scalar method is used to grab a value from Ifeffit and returns a floating point number. I then use sprintf to control the number of decimal places. 14 digits is a lot, making this line a bit silly, but I use this idiom extensively throughout the code, usually with much less precision. With one of the LC_* environment variables set to fr_FR (or whatever), a comma gets used.
It would not be hard to make this idiom tolerant of commas-as-decimal- points.
I suspect that there is a fairly simple work-around you could try:
* Open a new terminal window. (You want to try this in its own shell so it doesn't affect the rest of the programs running on your computer.) Do "env | grep LC" to see whether and how the LC_* variables are set.
* do perl -e 'printf("%.3f\n", 5.23456)' What gets printed? "5.235" or "5,235"?
* If the latter, do the following two commands: * export LC_ALL="" * export LC_NUMERIC="" If the former, then I'm stumped.
* try running Athena again.
You should take a look at ~/.horae/demeter.ini. If any of the values in there use commas as the decimal point, then you will either need to edit or delete the file.
Of course, I may be way off base. Let me know if that works.
B
On 06/02/2014 10:17 AM, Denis Testemale wrote:
I'd like to raise a related issue to complete my initial bug report and try to understand better those problems (which could occur again in the future). To install demeter initially (last year I think) I followed this procedure: https://gist.github.com/waveform80/3959252 One thing that I could not understand (and still cannot, it is somehow beyond my limited knowledge of linux) are the subtle differences between installing the code locally or system-wide and in particular this cryptic (to me) command:
eval $(perl -I$HOME/perl5/lib/perl5 -Mlocal::lib)
Indeed, the procedure I followed created a perl5 folder in my home folder. That is the reason why, when I mentionned that I erased all the folders to reinstall everything, I was referring to the folders demeter and perl5 in my home folder, as suggested in the 'Removing installation' chapter in the same page. And I'm pretty sure that many of my problems are related to that. As always, being a numb, I tried different fixes, in particular a root installation. Everything is probably a mixture of approximate fixes now and makes it hard to source the problems. The thing is I actually don't need this perl5 folder anymore. Everything now runs smoothly (with the en_US LANGUAGE trick), but I sometimes have warning messages (in dathena for example) that it can't locate Encoding/FixLatin/XS.pm in @INC for example. I copied the file from the local perl5 folder to the system wide folder in /usr/local/lib and the warning disappeared.
In fact I was wondering if I should reinstall from zero with a system-wide install, or if the local install made sense in some situations. As I understood it at the time, it was to be able to erase the local perl install.
Sorry for the long message. The bottom line is that you unlocked my situation.
Denis, You thought that was long? Just wait until you see my response! This is a valid question. Perl (like python, lua, ruby, and many others) is an interpreted (as opposed to a compiled language. One of the great strengths of an interpreted language is that its behavior can be modified or enhanced at run time simply by making more code available to the interpreter. In the context of perl (the story for other languages differs only in the details, not in the concepts), these language enhancements are contained in files called modules. Modules are just files containing perl code but which live in special locations, have names that end in ".pm", and contain some special lines which make them behave as modules. Demeter itself is an example of a module. If Demeter is installed in the correct location, any perl script can be enhanced to handle XAS data. Demeter, in turn, uses many dozens of such modules to add all the various features needed to make Athena, Artemis, and Hephaestus work the way they work. Sometimes, a module author finds it useful -- usually for reasons of speed and performance -- to provide some functionality in the form of code written in C, C++, or some other compiled language. In that case, there is a small module with some special code in it to provide a way of making perl communicate with the compiled portion of the code. So, there are a two substantial problems that must somehow be solved: (1) the modules must be in a location where a perl program can find them, (2) the compiled bits must be compiled in a way that is compatible with the version of perl being used. When you get to use a packaging system -- apt-get for Ubuntu, yum on Fedora, and so on -- both of those problems are guaranteed (by some definition of "guarantee"!) to be solved correctly. That is, if you ask to install an application package, its dependencies will include a certain version of perl and certain versions of packages for each of the modules that the application requires. Presumably, both of the problems are solved correctly by the person maintaining the packages. Sadly, there are not packages for Demeter for any linux system. The discussion of why is best left for another posting on the mailing list. The bottom line is that, when installing from source on a linux machine, the chore of solving both problems falls on you, the end-user. The perl environment tries to help you solve this problem, but there are pitfalls. If you can run the "./Build install" step as root, then it is likely that you will have no problem. If you do not have root, then solving the problems is a bit harder. Simply making a "perl5/" folder in your home directory is a good solution, but it is likely to cause problems when you upgrade your system. This, in fact, was the problem you ran into. The problem is that when you upgraded Ubuntu, you upgraded to a later version of perl. When Demeter's build script checked to see what modules needed to be installed, it found the modules built for the earlier version of perl and decided -- incorrectly -- that it did not need to reinstall those modules. Some of them, however, had compiled bits. Those had been compiled against the earlier version of perl and could not be used with the new version. To solve this versioning problem on a computer for which the user does not have the authority to install as root, the perl community came up with a solution called "local::lib". This sets up a "perl5/" folder in your home directory *AND* uses it in a way that deals with perl versions correctly *AND* modifies your shell login script to use it correctly. The cryptic command you quoted is part of the magic of setting up local::lib to do all that. Finally, how would you recover gracefully from the situation that you found yourself in? Well, there are several things that help: 1. The command "perl -V" displays the full list of places where perl looks for modules. It's the part under "@INC:". On my Ubuntu computer, perl modules installed by the user go to /usr/local/share/perl/5.14.2/. If I wanted to, say, simply remove the Color::Rgb module, I would do sudo rm /usr/local/share/perl/5.14.2/Color/Rgb.pm 2. The same thing can be done using the "cpanp" program, which is standard part of the perl installation. Doing sudo cpanp u Color::Rgb will uninstall the module. The advantage of using cpanp for this is that it will unistall every part of the module. For some complicated things, that could involved dozens or even hundreds of files. 3. If you suspect that you have a version clash (you'll recall that the error messages you sent me stated that somewhat clearly), you can force an update of a module. For example, you ran into this problem with the module DateTime. You could force an upgrade to that module, again using cpanp: sudo cpanp i DateTime --force Those are all useful tools to solving perl problems, but really the best solution (if system-specfic packages are not available) is to install normally as root or to use local::lib. An ad hoc solution (i.e. making your own perl5/ directory and installing there) sort of works, but can lead to problems if you're not careful. Hope that helps, B PS: If your take-away message from this absurdly long post is that it would be helpful to have Demeter packages maintained for the major Linux systems, then you read it correctly! -- Bruce Ravel ------------------------------------ bravel@bnl.gov National Institute of Standards and Technology Synchrotron Science Group at NSLS --- Beamlines U7A, X24A, X23A2 Building 535A Upton NY, 11973 Homepage: http://xafs.org/BruceRavel Software: https://github.com/bruceravel
participants (2)
-
Bruce Ravel
-
Denis Testemale