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-requ...@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-requ...@millenia.cars.aps.anl.gov
You can reach the person managing the list at
ifeffit-ow...@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 <bra...@bnl.gov>
To: XAFS Analysis using Ifeffit <ifeffit@millenia.cars.aps.anl.gov>
Subject: Re: [Ifeffit] Demeter on Ubuntu 14.04
Message-ID: <538629c6.7080...@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
_______________________________________________
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
