 |
 |
 |
 |
 |
 |
 |
 |
When you run Yorick in a window or Emacs environment, keep a window containing the include file you are writing, in addition to the window where Yorick is running. When you want to test the latest changes to your include file — let’s call it ‘damped.i’ — save the file, then move to your Yorick window and type:
#include "damped.i" |
The special character # reminds you that the include directive is not a Yorick statement, like all other inputs to Yorick. Instead, #include directs Yorick to switch its input stream from the keyboard to the quoted file. Yorick then treats each line of the file exactly as if it were a line you had typed at the keyboard (including, of course, additional #include lines). When there are no more lines in the file, the input stream switches back to the keyboard.
While you are debugging an include file, you will ordinarily include it over and over again, until you get it right. This does no harm, since any functions or variables defined in the file will be replaced by their new definitions the next time you include the file, just as they would if you typed new definitions.
Ideally, your include files should consist of a series of function definitions and variable initializations. If you follow this discipline, you can regard each include file as a library or package of functions. You type #include once in order to load this library, making the functions defined there available, just like Yorick’s built in functions. Many such libraries come with Yorick — Bessel functions, cubic spline interpolators, and other goodies. Most of these functions are available without the need to explicitly #include the required package, via yorick’s autoload function (see Customizing).
| • Sample include | ||
| • Comments | ||
| • DOCUMENT | The help command recognizes special comments. | |
| • Include path | Directories Yorick searches for include files. | |
| • Customizing | How to execute Yorick statements at startup. |
|
|
|
|
|
|
|
|
