[Rivet] python in rivet 1.8.1

[Andy Buckley]

Hi Mikhail,

That script does a *lot* after installation -- much of which *can't* be
tested until Rivet's been built. We could explicitly test for missing dl
or ctypes libraries but I'm not sure that'd be testing everything
needed. As I said, I don't really know what was going on with your
Python setup: here's how that bit of code works interactively on lxplus
(if I disable my account's automatic setup of Python 2.6 from LCGAA):

Python 2.4.3 (#1, Jun 19 2012, 13:51:22)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-52)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> import ctypes
>>> sys.setdlopenflags(sys.getdlopenflags() | ctypes.RTLD_GLOBAL)
>>> import dl

It *all* works fine... so I'm not sure what sort of system this would be
expected to be able to fail on :/

Re. the compilation speed, 32 bit SLC5 is still the main ATLAS evgen
production platform, until the next MC campaign: due to the change of
energy and a major shift in our production generators to the C++ era we
weren't able to run a full validation of 64 bit vs. 32 bit for all
generators against the MC11 generators at 7 TeV. So maybe that'll help
you to argue for another native 32 bit SLC5 machine on which to make
builds: that platform is still very much alive for now! Alternatively,
if there are several 32 bit machines that you can log into, then running
distcc pointed specifically at those machines might be enough.

Cheers,
Andy


On 09/07/12 18:27, Mikhail KIRSANOV wrote:
>  Hello, Andy,
>  I can add some more details. We had python 2.4.3 installed. The error
> disappeared after installing python2.6. Well, may be you can just try
> to do at the configuration step what you do after the compilation?
>  About timing: note that we have several platforms, and slc5 32 bits is
> rare, so it is on a not very new computer.
>                                     Cheers, Mikhail
> 
> 
> 
> On 07/09/2012 07:17 PM, Andy Buckley wrote:
>> Hi Mikhail,
>>
>> Odd -- that "import dl" is actually a fallback in the case that "import
>> ctypes" doesn't work, so your Python installation must have been a real
>> mess! So I'm not sure we should add an explicit test for what should be
>> a standard Python behaviour: we can't write our configure script to test
>> for *every* standard Python feature that might be used!
>>
>> At least this should have been a runtime failure, meaning that you could
>> update your Python installation without having to restart the
>> compilation from scratch: right?
>>
>> Are you able to test the broken Python setup now? My impression is that
>> a test of "python -m ctypes || python -m dl" should be sufficient as a
>> test... if so, I'll add it to our configure script for next time.
>>
>> Andy
>>
>> PS. 1-2 hours to compile Rivet? Really?! You need a better build
>> machine, or failing that, a distcc setup! Seriously, if your job is to
>> build generators and it takes hours to build Rivet, how long does
>> ThePEG+Herwig++ take? I'm assuming that you're already using parallel
>> make, i.e. -j5 or so depending on your build machine.
>>
>>
>> On 09/07/12 18:07, Mikhail KIRSANOV wrote:
>>>   Dear rivet developers,
>>>   Sorry for my previous e-mail with incomplete info.
>>>
>>>   This is not a bug report, but a feature request from GENSER. On our
>>> computer python was not up-to-date and I had the following error in the
>>> end of compilation:
>>>
>>> PYTHONPATH=../pyext: \
>>> /afs/cern.ch/sw/lcg/external/Python/2.6.5/x86_64-slc5-gcc43-opt/bin/python
>>>
>>> mk-analysis-html analyses.html
>>> Traceback (most recent call last):
>>>    File "mk-analysis-html", line 41, in<module>
>>>      import dl
>>> ImportError: No module named dl
>>> make[1]: *** [analyses.html] Error 1
>>> make[1]: Leaving directory
>>> `/genser1/mkirsano/GENSER/simu/work/tmp28/Rivet-1.5.1/doc'
>>> make: *** [all-recursive] Error 1
>>>
>>> It seems that it happens even after the compilation, at the
>>> documentation making. After updating python it is OK, but we understood
>>> it quickly only because we remembered a similar problem from the past,
>>> otherwise the reason of this error is not obvious. It is also rather
>>> annoying that it happens after 1 - 2 hours of compilation.
>>>
>>> So, the request is: is it possible to check that the corresponding part
>>> of python works before the compilation, at the configure step?
>>>
>>>                                          Regards, Mikhail
>>> _______________________________________________
>>> Rivet mailing list
>>> Rivet at projects.hepforge.org
>>> http://www.hepforge.org/lists/listinfo/rivet
>>>
>>
>>
> 


-- 
Dr Andy Buckley, SUPA Advanced Research Fellow
Particle Physics Expt Group, University of Edinburgh



The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.