Scripting Systems

Scott Snyder and I have proposed that D0 use a unified system for input: RCP, PBD files, COMPAQ, etc. There are a number of well supported tools on the internet that might fill this roll.

As part of the frameworks prototype effort, we will attempt to use Python in this capacity. This will give us some hands on experience.

Software Tools Meeting -- 3/22/96

Scott and I talked about using the scripting systems. Postscript copies of our slides:

• Intro to Scripting and how it might be used in D0 -- Gordon Watts (given by Scott cause I was called away).
• Survey of freeware scripting systems -- Scott Snyder

Scotts list of language systems included four primary ones. All have web sites devoted to them that contain tutorials, examples, and other discussions:

• Python
• PERL
• TCL/TK

Others were considered, but we decided they weren't really applicible for our use. When we first started looking at this, we thought Java wasn't far enough along (lacked uniform c++ interfaces). However, there has been renewed interest in it, and, in fact, a sgi java dev kit is on loan from sgi.

A number of examples of what the code looks like are also around. Here are a few quick ones, with links to the source code files.

• ZEB Viewer This is written in TCL/TK. It displays a list of all the zeb banks in the d0$zeb hierarchy in a scrolling list. Clicking on any of the bank names opens the zeb description for viewing. This code contains VMS callbacks that will list the contents of a directory, sort files, sort a list of "records", and some general user interface code. I wrote it about a year ago on a VMS port of the TCK/TK system. The sorce is in two files.
• The first file does the non-user interface stuff. It access the directory of zeb files, collects their names, and sorts them.
• The second is the user interface code. This constructs and manages the main window along with any subwindows that are created.
• Read RCP This is written in Python. It reads a given RCP file and returns a dictionary. Each entry in the dictionary is a bank name. The value associated with each bank name is another dictionary whose keys are the RCP varriable names. Their associated value is the value entered in the RCP file. The example is procedural.

Why Choose Python?

A number of people ask why we choose to go with Python as opposed to other scripting languages like TCL/TK, which seems to have a lot more support (certianly, the computing division supports it). Here are some of our the things we thought about when deciding what to pick:

• Must have a good GUI kit (atleast the power of tk). Every language has tk.
• Must be capable of handling large programming projects. OO is a plus, as we can directly map classes in the scripting language into classes in C++.
• Must be simple to access its features from C++, C, FORTRAN simply, and with few changes as we cross platforms.
• Not something we have to write from the ground up; not homegrown, damm it.

And some of our thoughts on the particular languages:

• Java
• Wasn't ready when we made this decision.
• Very OO, able to support large programming projects.
• Lots of net support. We do not have source code for it.
• Many vendors ($$), and each seems to have a different C/C++ interface. Is there a free version we can use, w/ source?
• Static type system; more checking done at compile time (good), but less flexability at runtime.
• Compiler and run-time are seperate, makeing compilation of scripts on the fly difficult. While there seems to be an API defined for this in the sun web pages, its implementation is up to the Java VM vendor.
• TCL/TK
• Large Net support.
• Already proven as a good tool command and control language.
• Supportedby Fermilab Computing Division.
• Easy to integrate into C/C++ programs (built with that in mind).
• All variables are strings (bad; numbers are strings in TCL), and no oo representation; not clear out to map objects into tcl variables.
• Not very good for large projects, as it is not very structured. There was a big argument over using TCL as a real support system; transcripts were archived in HTML form (this has a Python bias to it).
• PERL
• Very good at text processing and extracting information from text files.
• Not a good programming language to use for large projects.
• C/C++ interfaces defined, but not pleasent.
• Many Platforms (UNIX, VMS, NT).
• PYTHON
• OO language
• C/C++ interfaces well defined.
• A real language, up to large dev projects.
• Syntax takes some getting used to, but is cleaner that C++.
• Good network support, however, Fermilab's computing doesn't know about it. See the Python Users Page for a sampling of who is using Python.
• Source code is free.
• Many platforms (UNIX, VMS, NT).
• The online group is exploring CORBA (an ORB; Object Request Broker -- objects across networks); Python can be used directly as a client of a object server.