\documentclass[12pt,a4paper]{article} %%\usepackage[dvips]{graphics} %%\usepackage{epsf} \setlength{\textheight}{24cm} \setlength{\textwidth}{16cm} \setlength{\headheight}{0cm} \setlength{\headsep}{0cm} \setlength{\topmargin}{0cm} \setlength{\oddsidemargin}{0cm} \setlength{\evensidemargin}{0cm} \setlength{\hoffset}{0cm} \setlength{\marginparwidth}{0cm} \begin{document} \begin{center} \begin{Large} SICS Syntax Checker\\ Implementation Notes\\ \end{Large} Mark K\"onnecke\\ Mark.Koennecke@psi.ch\\ March/April 2003\\ Laboratory for Neutron Scattering\\ Paul Scherrer Institute\\ CH--5232 Villigen--PSI Switzerland \end{center} Users wish to check their batch files for syntax errors before submitting them to SICS for the weekend or the night. Unfortunately checking SICS syntax is not so easy as it consists of Tcl syntax plus SICS commands. In order to implement a syntax checker various possibilities exist:\begin{itemize} \item Implement the syntax checker as a calculation mode within SICS. This has the disadvantage that the syntax check can only be run by one person and only when the SICS server is not performing an experiment. This is due to the fact, that SICS has only one set of variables which may be changed dureing the syntax check. In order to prevent corruption the security measures stated above are necessary. \item Use a SICServer with simulated hardware. This would work. Problems are that this is very time consuming to set up and the synchronisation of parameter values with the main SICServer. This has been solved through the sync command and thus this option is available for complex scripts. \item Use a Tcl interpreter with dummy SICS commands as a syntax checker. In many cases batch files are fairly simple and a complete simulation is not needed. The such a option would be sufficient. \end{itemize} \end{document} \section{The Tcl Syntax Checker} This section describes the syntax checker built from a Tcl interpreter with dummy routines testing SICS syntax. The dummy procedures only have to test the syntax and else do nothing. Not many such proecdures have to be implemented but a means is needed for mapping names, for instance motor names, to a suitable procedure for checking the syntax. This syntax checker can be used in a variety of situations: \begin{itemize} \item Standalone: the preferred mode of operation \item Within SICS: SICS would need to have a second Tcl interpreter for this purpose in order to prevent corruption of the main interpreter. Even then a rogue script could go into an endless loop and thus hang the SICS server. Thus this second interpreter would have to run as a separate process or thread. \item This syntax checker could also help debugging SICS scripts. \end{itemize} For each instrument two files are needed for this syntax checker. The first is a common library file which implements the syntax checking procedures and the sics_alias procedure which maps names to procedures. The second is a mapping file which defines the instrument and enables those names the instrument provides. This is much like the instrument initialization file for the main SICS program. In order to help in script debugging, a global array with parameter values defined through the user script will be maintained. In a latter stage a connection to the main SICS could be added to the system. Through this connection the actual configuration of the instrument could be queried. Also parameter values can be updated in order to help in debugging sophisticated scripts. Moreover this connection could be used to check limit violations.