Gri Bugs

1: Introduction
2: Simple example
3: Fancy example
4: Running Gri
5: Programming Gri
6: General Issues
7: X-Y Plots
8: Contour Plots
9: Image Plots
10: Examples
11: Handling Data
12: Gri Commands
13: Gri Extras
14: Evolution of Gri
15: Installing Gri
16: Gri Bugs
17: System Tools
18: Acknowledgments
19: License
20: Newsgroup

21: Concept Index

16: Bugs

16.1: Known bugs

List of known bugs:

16.1.1: All computers

  • Polar (r-theta) graphs do not work.

  • The EPSF bounding-box defaults to an 8.5 by 11 inch page, if `-no_bounding_box' is specified on the commandline see Options On Command Line. It should probably know about more paper sizes.

  • `draw contour labels nowhiteunder' does not break the line under the label, as it should.

  • `reorder columns' is slow because it uses a bubble-sort.

  • Support for `netCDF' binary files is limited, e.g. (1) consistency of grid x/y/data is not checked as it is in ascii/binary formats; (2) Gri cannot read image data; (3) `set input data window' has no effect: use `set clip' instead; and (4) Gri cannot output to `netCDF' files.

  • Errors sometimes report inaccurate line numbers. (E.G.: errors inside newcommands report wrong line numbers if continued lines are present before the bad line.)

  • Images in rasterfile format: only mapless images permitted.

  • In an `insert'ed file, `read' commands which expect input from the commandfile, as opposed to a datafile, do not work.

  • The string size rpnfunctions `ascent("string")' and `descent("string")' are inaccurate.

  • If statements: Commands in the false part of `if' statements are not checked for proper syntax. All commands in false parts of `if' statements are simply skipped, except for `end if' or `else [if]'.

  • Clipping (lines): Clipped lines should extend as far as the axis frame, but they don't. Gri only draws line segments which connect two points each of is inside the axis frame. Note, however, that postscript clipping works correctly, and that it is recommended anyway.

  • Aesthetics (y-axes): labels are sometimes ugly because they are right-justified, and the number of decimal points is not necessarily uniform in all labels. Workaround: Set the format yourself (example: `set y format %.1f').

16.2: Reporting Bugs

Please report any bugs you find in Gri. Bug reports help make Gri more reliable and useful for all users. Here is how to report bugs:

  1. Archive your present version of Gri and then acquire the most recent version, to see if your bug has already been solved see Keeping old Versions. Bugs in the current version are likely to be repaired, while the probability of my repairing bugs in previous versions is low. I invest in the future, not the past.

  2. Prepare a command-file to illustrate the bug. It is very important that you remove anything not related to the bug. Since you are familiar with the problem and I am not, you can do this easier than I can. Please make the command-file end after the line illustrating the bug and remove preceding commands that do not affect the bug. One can usually reduce the length of the file by a factor of about 2 in this way. Clean bug reports lead to early corrections, so your time is well spent.

    If Gri produces an error, it might help to produce an error traceback stack by inserting the `set error action to core dump' command at the top of the commandfile.

  3. If Gri dies with a system-level error (e.g., `segmentation fault' or `bus error'), you should re-run gri inside the debugger. I prefer the `gdb' debugger, but if you don't have that, `dbx' will do. Use the `where' command to determine where the system error occurred. Put all the debugging output in a file. The `script/exit' commands provide a convenient way to do this in unix, e.g.
    script
    gdb gri
    run cmdfile.gri
    ... answer any query questions that might get asked ...
    ...
    ... at this point, Gri has died, so type:
    where
    quit
    exit
    

    which creates a file called `typescript'.

  4. If Gri runs to completion, then save the resultant PostScript file.

  5. Write a description of your problem in a file called `README', by filling in this form:
    (1) GRI-VERSION (GET WITH 'gri -v')
    

    (2) TYPE OF COMPUTER AND VERSION OF OPERATING SYSTEM. ON MANY UNIX SYSTEMS THIS INFORMATION IS GIVEN BY THE COMMAND uname -a

    (3) IF THIS WAS NOT A PRECOMPILED VERSION, NAME AND VERSION NUMBER OF COMPILER.

    (4) SHORT DESCRIPTION OF BUG (10-20 WORDS)

    (5) DID THE BUG CAUSE A SYSTEM ERROR (E.G., ``segmentation fault'' OR ``bus error'')?

    (6) DETAILS OF BUG, EMPHASIZING DIFFERENCE BETWEEN EXPECTED BEHAVIOUR AND WHAT ACTUALLY HAPPENED. IF YOU REFER TO THE PROGRAM INSERT TAGS IN THE PROGRAM, OF THE FORM # Tag 1

  6. Assemble the `README' file, the commandfile, the debugger output or the PostScript file, and any necessary data files into one package, and mail it to me, using e.g. the unix command (here written on several lines to display in web-browswers)

    tar -cvhf - ...
     | compress -c
     | uuencode gribug
     | mail Dan.Kelley@Dal.CA
    

    where ... stands for the list of the files to be enclosed.

Note: I will extract your bug report using the following unix commands, which you should also use if I send something back to you:
uudecode extracted_stuff
# assume makes file called 'gribug'
gunzip -c gribug | tar xvf -