Known Bugs

Warning: state-file incompatability

Due to simplifications made to the behavior of lines, labels, regions, and points in CIAO 4.1, the binary state files created by ChIPS in CIAO 4.0 can not be read into CIAO 4.1 (an error message about an incompatible version will be returned by load_state). The threads have been updated to describe this issue.

Caveat: IPython Packaged with CIAO OTS

CIAO includes IPython in the CIAO OTS directory which is used by Sherpa and ChIPS to provide command-line user interfaces. These programs create an IPython profile in the directory $HOME/.ipython-ciao.

If IPython users want any personal customizations to be available when running CIAO, they will have to copy them from $HOME/.ipython to $HOME/.ipython-ciao.

This is a list of known bugs in the ChIPS application.

• Systems using OpenGL Mesa version 6.5.* may experience problems with chips crashing due to a bug in mesa. The problem can occur if chips has been running a while and windows have been created and destroyed. In most cases the problem will be exposed by chips smoke test 3 failing.

  The only known workaround is to update to a later version of Mesa (at least 7.0.2). To check your version of mesa run:

  unix% glxinfo |grep version
  

  Systems using OpenGL Mesa version 6.5.* may also experience problems when the environment variable LIBGL_ALWAYS_INDIRECT is set or while remote logged into another machine and trying to run chips. Attempts to run chips under these circumstances has caused the xserver to crash. The problem has been observed on FC6 and FC7 machines. The problem no longer exists on FC8 machines running OpenGL Mesa version 7.0.3

• Some ATI graphics cards produce the following warning:

  libGL warning: 3D driver claims to not support visual 0x4b
  

  This does not seem to have any effect on ChIPS. A fix is supposed to be available in newer versions of mesa.

• When running ChIPS in batch mode through xvfb, multiple print_window calls to the same window may cause xvfb to crash. This happens only on large data sets, upwards of 500000 points. This is do to a limitation of Xvfb.

• Running ChIPS remotely from a Mac PPC to Mac Intel (or the reverse) produces an X error such as:

  The program 'ChipsServer' received an X Window System error.
  This probably reflects a bug in the program.
  The error was 'GLXUnsupportedPrivateRequest'.
     (Details: serial 72 error_code 163 request_code 150 minor_code 17)
     (Note to programmers: normally, X errors are reported asynchronously;
      that is, you will receive the error a while after causing it.
      To debug your program, run it with the --sync command line
      option to change this behavior. You can then get a meaningful
      backtrace from your debugger if you break on the gdk_x_error() function.) 
  

  The workaround is to set "setenv LIBGL_ALWAYS_INDIRECT".

• Remote logging into a sun machine from a linux or mac build may produce X errors such as:

  *** Cannot find the double-buffered visual.
  *** trying single-buffered visual
  *** No appropate OpenGL-capable visual found
  

• pick, get_pick and pick_limits may cause the system to hang when used when the window display is set to false

• When using greek fonts and other symbols, fonts must be exported in order to see the correct font in the postscript and pdf outputs. png and jpgs may fail completely if fonts are not exported.

• Printing of pdf, jpeg, and png formats is handled via ghostscript. This is necessary because of Solaris and OS X system issues. The jpeg and png output may show slight lines between various vertices in filled polygons as a result of how the fill is triangulated by ghostscript. These lines may also appear when viewing pdf files through acroread. The lines do not appear when printed.

  In addition, opacity level support in pdfs and pngs is currently not available.

• Adding lines, polygons or curves with large ranges (on order of 10^7) to a drawing area of with a small range (on order of 10^1), may cause unexpected behaviors, including bad clipping and or positioning of the object.

• Currently clipping labels is point clipping. This means if the point is in the data range, the whole label is displayed; otherwise, the whole label is clipped.

• Joints of line segments for curves can be very visible if the lines are thick.

• Self-intersecting polygon regions are not supported.

• If the an axis label is set using the axis.x.label or axis.y.label attributes of an add_<object> call then the string must be surrounded by double quotes if it contains spaces; for example:

  # Python
  add_curve(time, zoff, ['axis.y.label', '"Z offset (arcsec)"'])
  
  % S-Lang
  add_curve(time, zoff, {"axis.y.label", "\"Z offset (arcsec)\""});
  

• Contours of images taken near the celestial poles, which have WCS transforms applied to them, may appear distorted as the axes are gridded uniformly in ChIPS.

• ipython included with CIAO on Mac OS X PPC and Intel has an issue when displaying the traceback from an error. As a workaround it is suggested that ipython be run as:

  ipython -xmode Plain
  

  or, while in ipython:

  import sys
  sys.tracebacklimit = 0
  

  This will minimize the traceback that is printed when errors are encountered.

• NaNs and +/-inf are currently filtered out of curve and histogram data. This filtering is not performed for other data (e.g. contours, lines)

• Turning redraw off by calling

  # Python
  set_window(["display", False])
  
  % S-Lang
  set_window({"display", 0});
  

  can be a very slow command especially if running remote. It may be faster to start with the window display off, or if grouping commands in automic units, use undo buffers.

• While inside an undo buffer block redraw will be turned off. However, to increase speed the contents of the chips window are not refreshed. So while nothing is drawn to the window, if the window is obscured by another window, the obscured pixels are lost and will not be refreshed if the obscured part is made visible again. That part of the chips window will be black.

• If an undo buffer block is nested in another undo buffer block and the inside block ends with a discard_undo_buffer, but the outside block ends with a close_undo_buffer, the discard_undo_buffer will not clear out the commands from the inside block. The inside block will be executed.

• The window title is not recorded by the save_state command.

• On slower machines the first command in chips may not work. Subsequent tries will occasionally fix this problem. No error is produced.

• (3 Mar 2009)

  The unbind_axes (S-Lang or Python help) command fails and kills the ChIPS server when one of the two axes is invalid, e.g.

  unbind_axes("plot1", "ax2")
  

  instead of the correct syntax

  unbind_axes("ax1", "ax2")
  

• (1 Jul 2009)

  The pick_limits (S-Lang or Python help) command fails if current frame is set to "all".

  #Python
  chips> pick_limits()
  chips ERROR: The specified frame does not exist
  
  %S-Lang
  chips> pick_limits();
  chips ERROR: The specified frame does not exist
  

• (1 Jul 2009)

  A histogram with a single bin that starts with a negative value is not drawn correctly in ChIPS. For example:

  #Python
  chips> add_histogram([-1],[1],[5])
  
  %S-Lang
  chips> add_histogram([-1],[1],[5]);
  

Bugs Fixed in CIAO 4.1

• During an undo operation, there is a very small chance that the command will appear to miss a portion of the changes. This only occurs when the buffer is internally cleared and written to file in the middle of a sequence of commands. If this happens, simply issue another undo followed by a redo to ensure that the correct state is restored.

• If set_contour is run on a ChipsContour object which contains small values for the intervals and levels, it will take a very long time to draw the contours. Even though the final contours may not be in interval mode, ChIPS still changes the intervals to the value specified in the object.

  The workaround is to set the intervals and levels in the ChipsContour object to None or NULL if they are not required.

• The Fedora Core 7 build of ChIPS can't load state files made on a Mac.

• After a certain number of commands, using an undo tag results in the following error:

  chips ERROR: There are no actions available to undo
  

  Alternatively, the undo tag will work correctly, but the window redraw becomes locked as "off" (i.e. it's not possible to redraw the window).