Known PyRAF Shortcomings, Differences from IRAF, Planned Improvements, and Bugs

This is a list of known problems or limitations of PyRAF, differences from the IRAF CL, and planned improvements for the future. Each item is followed by a parenthetical comment on our plans for responding to the item. If the comment says "no plans" then we do not currently have any plans to implement the listed feature or behavior. That may change if we receive enough feedback indicating that it is important.

Not included in this list are enhancements to the IDL-like capabilities of Python through improvements to the Numeric module (which will be a major focus of our efforts in the future.)

- Differences from the IRAF CL
- Known Bugs
- Limitations & Planned Improvements

Differences from the IRAF CL

• GOTOs in CL scripts are not supported. (no plans)
• There is no package unloading: 'bye' has no effect. (no plans, though we are considering alternative, more Pythonic approaches to similar functionality)
• There is no background execution. The cache command, which is used to keep parameter lists in memory for script execution (and apparently is useful only for background execution), also is not implemented. (may be considered)
• Redirection of graphics streams (using >G) is not supported. (tentatively planned, although the ability to save metacode from the graphics menu is probably more convenient for interactive use)
• The rarely-used fprint built-in task is not implemented (not to be confused with printf, which is available.) The hidden tasks _allocate, _deallocate, and _devstatus are not supported. (no plans)
• The stty playback mode is not implemented. Playback mode is used for some CL demo scripts; it is typically highly specific to xgterm and the IRAF CL (including, for example, the keystrokes used inside the IRAF version of epar.) Other features associated with playback mode (login, logio, logout, verify, delay) are also unimplemented, as are some other stty features (e.g., ucasein & ucaseout). (no plans)
• The CL keeplog parameter is ignored. (Use the PyRAF .logfile directive to keep a log of your session.) The putlog command is also ignored. (no plans)
• PyRAF does not limit the length of CL struct strings. PyRAF strings can be arbitrarily long. (no plans)
• Automatic conversion of characters to integers in assignments is not supported. In the CL, i="Z" is a legal statement and results in i being assigned the ASCII integer equivalent to the character "Z". (no plans)
• An unusual (little known) CL behavior involving adding integers to strings that end in numbers is not supported. In the CL, 'test5'+5 is 'test10'. In PyRAF, 'test5'+5 = 'test55'. (no plans)
• Task definitions that reference files using IRAF networking (host!filename) are not supported. (no plans)
• Binary I/O to tasks is not supported. An example is in bench$bench.cl:

  task $wipc.bb = "bench$x_bench.c"
  

  The wipc task expects to read binary data from stdin and writes binary data to stdout. This capability does not appear to be used elsewhere in the IRAF system. (may be considered, though low priority because this is little used)
• Timing the execution of tasks using the $command IRAF CL syntax is not supported. A workaround using Python libraries can be done using:

  --> import time
  --> t0=time.time(); iraf.imhead('dev$pix'); print time.time()-t0,'sec'
  dev$pix[512,512][short]: m51  B  600s
  0.032753944397 sec
  --> t0=time.clock(); iraf.imhead('dev$pix'); print time.clock()-t0,'sec'
  dev$pix[512,512][short]: m51  B  600s
  0.02 sec
  

  The first line demonstrates how to get the wall-clock time for running a task, while the second line shows how to get the CPU run-time. (no plans at this time)

• When CL scripts are executed using `cl < script.cl', any tasks inside script.cl that read input from stdin will not work correctly (because stdin has been directed to script.cl, which has no remaining data once the CL code has been read.) (fixed in next release)

• CL script error messages print the Python line number where the error occurred but not the CL line number. (planned)
• The startup configuration (e.g., IRAF home directory) is not configurable. (planned)
• Startup from within Python scripts (via 'import pyraf') is not easily configurable. (tentatively planned, although we are unsure of the best approach)
• There is no text-based epar (a la IRAF epar) that runs in a terminal window. (no plans)
• Graphics defaults (fonts, colors, etc) are not configurable. (planned)
• CL level gcur commands are incomplete. We plan to add more, though it is unclear if we will ever implement the full set of commands. (planned)
• The image display cannot be used for interactive plotting. (Note that it can already be used for noninteractive plots.) (work in progress)
• There is limited graphics support for terminal-type devices such as xgterm and xterm. (no definite plans, but we may add support for interactive use of some terminals if demand warrants it)
• A few graphics functions are not implemented (e.g., PUTCELLARRAY which is used to put an image in the graphics window.) (tentatively planned, but low priority)
• We plan to make more of the current gcur capabilities (zooming, etc.) accessible through GUI mechanisms --- menus, buttons, etc. --- as well as (or instead of) through the traditional keystroke commands.
• The PyRAF GUI epar is undergoing a redesign that will make it even better. The Help GUI available within epar will be available independently and will have more capabilities. The epar window may be persistent so that it can remain available for multiple runs of a task. The functionality of the window will be improved (e.g., making the up/down-arrow and page-up/down keys active.)

Perry Greenfield & Rick White Questions? Contact help@stsci.edu 2002 September 24