Core Minutes 10/5/2004  

Present:    Joanne Bogart, Anders Borgland, Larry Brown, Toby Burnett, David Chamont, James Chiang, Johann Cohen-Tanugi, Seth Digel, Richard Dubois, Zachary Fewtrell, Warren Focke, Marco Frailis, Riccardo Giannitrapani, Navid Golpayegani, Heather Kelly, Michael Kuss, Matt Langston, Julie McEnery, Pat Nolan, Chuck Patterson, James Peachey, Dirk Petry, Leon Rochester, Alex Schlessinger, Tom Stephens, Tracy Usher

• GlastRelease tag: (Toby) See this little discussion of the new release, v4r5p1, probably the last one before incorporating the Tracker code reorganization. Bottom line: looks ok so far. The small differences in energy resolution don't appear to be significant. Julie is in the process of examining System Tests output.
• CMT-less build of Science Tools: Background from Richard: decision was made to use CMT for Science Tools development, but distribute in some form not requiring CMT.  That hasn't happened so far and SSC is somewhat unhappy about it. Hence James has been looking into hmake  potentially both as a distribution mechanism and as a tool for development at SSC on Linux.

  (James) hmake is just a build tool, not meant as a replacement for CMT since it doesn't have all the functions of CMT. hmake is a front end for (gnu) make which sets some environment variables (based on running unix configure) before invoking make. (Toby) What about Windows?  Could do as is done for ROOT distribution: use cygwin, but point it to Studio compiler and linker. (James) He's planning on using cmake; input is simlar to what's needed for hmake. (Heather) In order to be able to evaluate hmake/cmake, she'd like to see hmake documentation and a demonstration on both Windows and Linux. How do we get a single source for hmake and cmake, analogous to single CMT requirements file for both platforms? (Toby) ..is concerned about keeping everything in sync.  Perhaps CMT could be induced to generate input for hmake, something like its secondary makefiles. (James) Don't the secondary makefiles have built-in information specific to environment where they were created? (Larry) hmake and cmake are very similar. He's hoping to be able to generate cmake files from hmake files.  (James) A single source is certainly preferable, but having two would not be the end of the world.

  (James) ..is not suggesting that hmake be used for GlastRelease, only for ScienceTools. And there the primary focus is for distribution. (Toby) What about MRvcmt? Can it be made aware of the alternate build technology?(Heather) ..votes strongly for a single build system, whatever it is. We don't have the person power to keep track of more. (Julie) Science Tools is used differently; a different build system might be appropriate. (Richard)..seconds Heather's vote.

  And there you have it.

  
  
• Installer:  (Johann) ..has been beta tester for Navid's Installer.  It's a Perl script which, when invoked by a remote user, queries a central database to find out what's available, what it should download, etc. to satisfy request. The documentation describes all options and includes several examples (e.g, can ask for external libraries only). All executables are put in a single bin directory. Johann's experience (and Julie's) is that it works just as documented, which is fine for end-users.  He questions the need for including CVS and CMT directories for this audience. (Navid)..subsequently took them out.  (Richard) Perhaps we want them after all, to allow possibility of developing from this base. (Johann) Remote developers also have the option of downloading a ReleaseManager source tarball. But he would like the ability to move easily between developer and user environment, or, better, have one installation for both.  (Joanne) Can one thing really do both? For tracking down end-user problems, one really needs to duplicate their environment without any possibility of local developer detritus sneaking in.

  So far this is only for Linux. In order to get it going on Windows, need RM-created Windows binaries (Richard: perhaps we could get going with a manually-generated set) and a way to copy and unpack them. Navid's script relies on command-line ftp and unzipping tools. They're standard equipment on Linux. He investigated using cygwin, but this is too top-heavy a solution to impose on end-users; should be possible to find suitable command-line tools. (Toby) Unzip exists. Doesn't handle tarballs, but, as other distributed Windows binaries are in zip format, ought to be able to use it here as well.

  (Heather) Is the Installer ready for prime-time on Linux? If so, how do people get it?  Beta-testers agree it's ready. Navid will put the Perl script in FTP space.

• Gleam GUIs: (Richard) Proposal is to support only FRED, discarding old Gleam GUI. So far only FRED has been upgraded to keep pace with Tracker rewrite. The old GUI will not be very useful for viewing much of the Tracker information.  Something similar is likely to happen for Calorimeter. (Toby) New GUI is not as simple to start up  (Richard) It's just a question of who's on top.  For new GUI you start up Fred and it starts up Gleam (Toby)..and it's more difficult to debug with it. (Leon) You can first start Gleam in debug, then start FRED, then attach (Tracy)..or use a method Riccardo provided to start FRED in debug.

  Everyone agrees we don't want to duplicate significant effort in keeping display up to date. Modified proposal is to concentrate develop effort on FRED, but keep the old GUI around as long as it's useful.

∫ Flight(w, ..) dw

• EM status: (Heather) She made a new tag, v3r0404p2 which includes the latest in LDF-aware code. She would like to make another tag no later than Thursday including, if possible, the new Tracker tags from before the major update, new Calorimeter code, and recent Calibration updates. EM2 starts taking data on Monday the 11th Friday the 15th!
• Pipeline: (Richard for Dan) Goal for this week is to finish off proper archiving of successful runs and notification when there are failures.
• Infrastructure plumbing: (Matt) LDAP database is installed, but not fully hooked up, awaiting policy advice from SCS. (Richard) Tomcat servers need to be made secure. They will be hidden behind one public web server, glast-ground.

previous

minutes index

next

J. Bogart Last Modified: 01-Jun-2010 15:45:49 -0700