March 24 Passuma notes, Robert Kennedy, Scott Snyder and 
Chih-hao Huang presentation


These notes are not complete (or a fair coverage) of the meeting, 
and should be read together with the transparencies which are 
available online.

Root (R.K.)
-----------

Characterized as CERNLIB++ and PAW++ in one

Looked at 2.00.02 (source and binaries) Linux, IRIX6

General question for products: How many people support it; by
category, all? Style of support team forced.

Paw++ front-end - a lot underneath it. ~ 500k lines of code.

g++ compilers. Kai? Don't know but going to check. Use of shared
object libraries => must support particular compiler you use.

Runs on Win95/NT, Linux, and all the platforms considered for
run II so far. 

No official support from CERN. 
What is status/commitment from support group? Goto at HP 
(for cint)? 

They do have a track record for support. Responsive and respectful.
A number of non-fatal nuisance problems.
Many memory leaks - question: Don't they pass it through automated
testing tools like Insure++ or Purify?

repository not accessible (CMZ) though source is available with
distribution.

quick defect response (couple of days).

General question: How do supporters interact with users, will they
sit down with user and work out problems?

Documentation poor for cint. No list of what subset of C++ is 
supported and what isn't, how do you quit from cint, etc.

Incomplete spec of which OS, compilers used/supported, sensitive 
to version of OS used (Linux).

Initial root interface is command line interpreter (yuch - to some).

Source code uses CMZ (commercial version of patchy). No make files 
are provided (but there is a promise to provide them). Import into 
CVS and maintain locally?

Source all lumped into one directory - needs some structure.

AS mentioned, Kai?

HEPEVT, minuit source generated from Fortran code via f2c instead of
a real port. This is very undesirable and difficult to support.

Conditional compilation (ifdefs) heavily used in only OS dependent 
sections of code.

Self contained (not dependent on external or commercial products, 
except cint) and quite modular. 

Code must be written in a particular way (e.g. inherit from tobject).

Questions:

Using other packages with root? 

CDF worried about linear algebra. 
What about replacing minuit?

Considered as a PAW replacement for the desktop, or part of the 
online/offline framework? Probably only the former, but the 
latter would require 24/7 support with a local team.

CDF considering the data format. May not use libraries, but data
format and tools. Interested in reverse engineering the design.

Support: CVS & local repository for changes with central CMZ 
repository could lead to a maintenance nightmare, especially 
with possible local modifications. Should not evolve/diverge 
the way CLHEP did with 4-vectors. 
Everyone seemed to think that a shared and collaborative 
development and repository is desired if at all possible. 

How would support be divided? Along functional lines (graphics, 
CLI, et.c)?

Tools for data conversion? Has RZ <-> root. What about YBOS <-> root?
Rob is looking into it.

Question of release frequency: currently a new release comes out 
every couple of weeks. Core is pretty stable however with infrequent
changes to it.

Pointed out that an advantage is that a system manager is not required
to set root up on a system.

CINT (C.H.)
 -----------

Looked at source 5.13.42

> 80k lines & can interpret itself - some accomplishment
Single author (supporter)

Lex and parser are completely hard coded. No clean separation.

Recursive descend parser used for its simplicity. Not sufficient 
for C or C++. Requires patch-work, which is scattered throughout 
the cint code (messy).

Claims 95% ANSI C, 85% ANSI C++ coverage, but doesn't specify what 
5 and 15% it doesn't cover.

Started from a subset of C with no formal design could => a 
maintenance nightmare

Should not underestimate the cost of modifying/supporting their 
code if someone does it other than the author.

As-is the maintenance cost would be high, any add-ons become 
more and more difficult due to the patchy nature of the source.

Doing templates with the recursive descend parser would be 
Very difficult, if even possible - best to use as-is.

Cint (S.S.)
-----------

Again - Lex and parse and interpretation: No clean separation.
Hard to tell what syntax will work sometimes.

Support tree, etc. Not too bad.

Pretty portable across platforms.

Support level of commitment: From author: Because Root will be used
in the LHC, Root/cint will be supported for a long time.

Difficult to replace root. Root depends on cint in a fundamental 
way. There are quite a number of ifdef ROOT in the cint code. Also, 
root Run Time Type Identification depends heavily on the RTTI 
API that cint provides. A replacement would have to have a similar
API. Root depends on the RTTI for browsing and other fundamental
functionality.

Given above, a question to ask is what functionality is mission 
critical: a full ANSI C++ interpreter, browser functionality, etc.

Clearly cint is a touchy area of root.


Gene