3.8 Troubleshooting

There are several reasons for PaPCo not initializing properly, or crashing because some or other routine couldn't be found:

1.

The paths to the PaPCo package and/or modules are not set properly.

2.

There is a conflict between the way PaPCo sets up IDL and the way IDL is set up by the system or current user.

3.

There is a naming conflict between PaPCo routines and other IDL routines on the system (and in the IDL search path).

3.8.1 Are you using an own idl_startup.pro?

On starting IDL, one can give the name of a batch file on the command line that is executed on start-up. This is the method employed by PaPCo. However, if the environmental variable IDL_STARTUP is set to the name of a different start-up file, then IDL will execute this batch file, on start-up, BEFORE the file on the command line is executed. If this different start-up file also contains a command expanding the IDL search path, then the PaPCo paths will be appended to that path. Now, if IDL searches throughout this path to find a .pro it needs to compile, then it will compile the one that is found first; and if there are duplicate file names present, then the one it compiles might not be the one PaPCo needs!

The way to get around this, and to make sure that IDL ONLY searches the path set up by PaPCo, you need to unset the environmental variable IDL_STARTUP. Under UNIX the command for this is:

unset IDL_STARTUP

3.8.2 Are my own routines found?

The only way your routines can be found is when the path to their location is included in the IDL search path !path. For the PaPCo core routines this is done in This is done in the file papco_set_variables.pro, and for the modules in the file papco_include_modules.pro which is written by the configuration widget program. Check this file to make sure all paths are correctly set.

Traditionally all the module directories are subdirectories under papco_XX/papco_modules, but this is not prescribed. Putting them there just simply makes it easier to distribute them with the whole PaPCo package using a tar file. But since you can include the path to your modules in the PaPCo configuration widget, they can be located anywhere, even on other workstations! The idea here is that you can use whatever is already existing on your workstation and interface those modules to PaPCo by simply expanding the search path accordingly.

Just beware that none of your routine names (or procedure/function names) are in conflict with PaPCo routines!

The additional files and directories needed in your module directory are described in Chapter 6.

   
3.8.3 Avoiding naming conflicts

In any large package such as PaPCo the chances of naming conflicts arising is large. When adding your own modules, or interfacing your own widget application, you might end up having procedure or function names that have already been used by PaPCo.

We have tried to give unique names to all the routines in core PaPCo (most of them starting with papco_), but of course have no control over what anyone else does. Instead of prescribing some rigid naming convention for everything (although there IS a naming convention for the interface files for your modules for PaPCo), PaPCo provides a utility for searching and documenting an IDL tree structure of programs, which provides warnings on duplicate file, procedure, functions, and structure names.

You may use the program 'comments.pro' in papco_XX\papco_lib to extract this information from IDL-files. Issue those commands from IDL:

   .run string_functions
   .run comments

then, use the routine commentsFor by specifying the path you want information for - all files in that directory and in its subdirectories are analyzed and information is written to some files:

commentsfor, 'papco_XX/papco', 'papco'

The first parameter specifies the directory start point to analyze (automatically goes through subdirectories), and the second the file name root for the output files (can include a path).

The second parameter is optional - if you omit it, the information is written to ~/protocol.xxxx.

This generates the following files:

papco.def_warnings

Warns you of multiple definitions in different files.

papco.definitions

List definitions of functions, procedures and structures found in any of the files (sorted by definition name).

papco.proc_ref

This is almost the same as papco.definitions, but the definitions are not complete - they are abbreviated, so that you get a quick overview (sorted by definition name).

papco.file_warnings

Warns you of file names that appear in more than one directory.

papco.files

List all .pro-files and the definitions made in them (sorted by file name)

This is extremely useful for finding out what routine is where and how it is defined, and serves as a mini-reference guide to the whole program structure. It also warns you of duplicate definitions in the two _warnings files.

This has been done for the files in:

papco_XX
papco_XX\papco
papco_XX\papco_lib
papco_XX\papco_modules

The output files are in papco_XX\papco_doc\commentsfor. These files are very useful for the developer to trace down faults, but are also useful as reference material on what files and procedures are defined where.

It is strongly recommended that you use this procedure to check your own module for naming conflicts, and then include your module under the papco_XX tree and check again for any naming conflicts with existing PaPCo procedures or modules.

If all your modules are placed under papco_modules then running

commentsFor, 'papco_XX', 'papco'

goes through the whole of the PaPCo structure INCLUDING your module. Any conflicts are then listed in papco.def_warnings and papco.file_warnings.