Difference: CoreSoftwareMeetingMinutes20070725 (1 vs. 2)

Revision 22007-07-25 - MarcoClemencic

Line: 1 to 1
 
META TOPICPARENT name="CoreSoftwareMeetingMinutes"

LHCb Core Software Meeting

Line: 72 to 72
  The v* directories are extremely useful for casual users and for librarians. The only use-case when they create problems is for people working with the HEAD version of many packages. For those cases it will be useful a flag in getpack to avoid the creation of v* directories, but the default behavior should remain the current one. (Hubert already added this flag)
Olivier
A recent discussion on lhcb-soft-talk pointed out that we do not have a way of finding which library a component comes from and in which directory it is. It should be trivial to develop an external tool to discover it or it could even be already possible with available tools. To have something at the C++ level, we need some hook from Reflex. The external tool is easy to write, but should be maintained following the evolution of the the plug-in manager. The C++ functionality can be very complex, but maintained by the Reflex team.
Marco Cl. will try to understand what we can do (may be starting from the external tool).
Added:
>
>
Marco Cl.
  • Steve Blusk asked about the binaries for PyQt. The situation is that the version of PyQt for Qt3 has not be updated (using Python 2.3.4 and only for slc3 and rh73). PyQt for Qt 4 is better supported, but the default version of Qt is still 3.3. Marco Ca. will report at the Architects Forum.
  • Just a reminder: we need to discuss the migration of the conditions database to Oracle.
 

Revision 12007-07-25 - MarcoClemencic

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="CoreSoftwareMeetingMinutes"

LHCb Core Software Meeting

Date and Location

25 July 2007
10:35 - 12:08
CERN (2-R-030)

Attendees

Gloria, Hubert, Marco Ca., Marco Cl. (minutes), Olivier, Patrick (phone), Thomas
<!--

Apologies

-->

Subjects

News

  • LCG 53a in preparation
    The documentation (TWiki) is not precise. We cannot use LCG 53 because of a segmentation fault when using GaudiPoolDb together with Python.

Software Releases

Gaudi (Hubert, Marco Cl.)

  • Hubert fixed a problem with the pattern for genreflex because it didn't work with make -j (using the make special target .NOTPARALLEL).
  • Hubert got the correct rights to modify the TWiki Gaudi Web.
  • Marco Cl. applied few patches. The most interesting is the one by Vanya to implement Guards.
  • Marco Cl. is going to prepare a Gaudi package to use QMTest.
  • Hubert intoduced in GaudiPolicy the dependency on Python
  • The cyclic dependency in GaudiSvc has been removed.

It is somehow a common feeling that GaudiSvc is too big, with components that should not stay together. One possibility is to start with a package like GaudiCoreSvc where to move only the components that are needed for a basic Gaudi application, while the rest of GaudiSvc can be adiabatically splitted.

Marco Ca. asked to introduce osx_ia32 and slc4_gcc41 in the nightlies.

Marco Ca. asked if there are news about the migration of the Power.* headers in LHCbMath to Gaudi. Marco Cl. forgot to look and will do it soon.

LHCb, Boole, Brunel (Marco Ca.)

  • Next release of the stack is ready to be built (Hubert is doing it).
    • The main changes are the extension to detector description introduced by the A-Team.
    • The usual bug-fixes.
    • OTDet and STDet changed minor version because of few extensions.
    • VeloDet changed major version because it underwent a major internal restructuring.
  • Testing a patch for G.O.D. to have dictionaries for enums in namespaces generated from XML (by Brett Viren).

Gauss (Gloria)

  • Problems with the Win32 build of Geant4: the library G4processes contains too many symbols to be exported (limitation of VC7). Hubert is trying to split it in 2 pieces.
  • Ricardo Graciani has made some study on the performances of Geant4 builds (32 and 64 bits) on different architectures.
<!-- 
  • Problem in production with
-->
  • Many users are confused by the error message about a missing command "-tag_add=xxx" when setting up the environment with source setup -tag_add=xxx. It is not a real problem, because the environment is set up correctly, but users think it is not and do not even try. Hubert suggested to try to use the environment variable CMTEXTRATAGS instead of -tag_add. Marco Ca. suggested that SetupProject should do the same. Marco Cl. said that Setupproject is currently using -tag_add, but he will change it.
  • A problem has been found with the generation of halo events. It seems that the G4 event is cleaned only when there is something in the following event, so, if the next event is empty, we get a copy of the previous one.
  • Muon experts are checking if enabling the default G4 physics description of multiple scattering, they have the same strange behavior observed with the previous version. Using the new version and the old physics (which is our default configuration), the problem is still present.

HLT (Patrick)

  • Slowly converging. Should be ready by the end of the week or early next week.

Round Table

Patrick
  • Tested the procedure discussed via mail with few people to build/run/submit SLC3 binaries on SLC4. Asked Juan to update the DaVinci documentation.
  • Using the phone to attend the Core Software meetings is a bit problematic and he would prefer to use EVO (the evolution of VRVS). EVO has been successfully tested during the last T-Rec meeting.
    For the next meeting we will try to set up parallel phone and EVO conferences.
Marco Ca.
  • TWikifying the Bologna tutorials to use them in the upcoming Software Week. The Getting Started F.A.Q. will contain links to the tutorials.
  • Moved his CVS configuration on Win32 to SSH2 (SSH will soon be removed). He updated the documentation on the LHCb Windows page to address users to the correct IT page.
  • Our documentation is messy and it is not well maintained. E.g. our instructions refer to Emacs and use the lint to the official page instead of our Emacs instruction (including the link to the official page and instructions for our customization). Another example is the link to Vi home page, which he replaced with a link to the Wikipedia page about Vi (more useful for beginners).
    We should also try to use as much as possible TWiki, which is much easier to maintain (if you find a typo or a broken link, you can fix it yourself).
Hubert
Can we get rid of the v* directories in our projects?
The v* directories are extremely useful for casual users and for librarians. The only use-case when they create problems is for people working with the HEAD version of many packages. For those cases it will be useful a flag in getpack to avoid the creation of v* directories, but the default behavior should remain the current one. (Hubert already added this flag)
Olivier
A recent discussion on lhcb-soft-talk pointed out that we do not have a way of finding which library a component comes from and in which directory it is. It should be trivial to develop an external tool to discover it or it could even be already possible with available tools. To have something at the C++ level, we need some hook from Reflex. The external tool is easy to write, but should be maintained following the evolution of the the plug-in manager. The C++ functionality can be very complex, but maintained by the Reflex team.
Marco Cl. will try to understand what we can do (may be starting from the external tool).

-- MarcoClemencic - 25 Jul 2007

 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback