Bug Reports

• Double-check your input file.
• Try to reduce your input file to the absolute minimum that still produces the bug. The cleaner the example, the easier it is to debug.
• Think again if your problem really is a bug.
• If so, then it is time to send in a bug-report.
• Send an email to the code maintainer that includes:
  • The (reduced) input file that produced the error.
  • All command-line arguments when the bug was produced,
  • What went wrong and why you think this is a problem.
  • The output of running dealer with the -V flag. This will produce something like:

    Version info....
    $Revision: 1.1 $
    $Date: 1999/07/19 20:24:32 $
    $Author: henk $
    

    Include this information in your bug-report. This uniquely defines the version of the code that produced the bug.

    If a problem did not occur with a previous version of the program, do a dealer -V on that version as well.

  • The platform and operating system that you are using.
  • The compiler that you used to compile the program. If you modified the Makefile, include that as well.
• If you think that problem is caused in the code from a particular contributer, send him a copy of your mail.
• Note that dealer is free and comes without any guarantee. Bugs will be investigated and might be fixed, but all authors work on this on a voluntary basis in their spare time, so do not expect any service.

Submitting Code

Before modifying the source code, first check if you can solve your problem with a cleverly written input file and how often you would need a function. Changing the code (and testing it) does take a lot of time.

When modifying the code, you should realize that you are on your own. Other authors may be able to help you, but do not count on it. And do not even think about submitting code that almost works but that still needs a few all-night debugging sessions.

Once you are happy with your code, consider if you should submit them for inclusion in the "official" source tree. In general, only submit changes that add functionality to the code. If your code is incompatible with existing features, then do not remove it but instead put "#ifdef's" into the code so that users can select the appropriate pieces of code and still be able to run their existing input files.

When submitting code, please follow the following guidelines in order to keep the code maintainer happy:

• Try to make your changes against the latest version of the code.
• Test your code, at a very minimum:
  • Write an example that use the features of your code.
  • Try to test your code in combination with as many existing features as possible.
  • Run a make test in the Examples directory and make sure that the existing examples still work as before. If they do not work as they used to do, carefully check if the output is still correct and document the changes.
• Provide documentation:
  • Put comments in your code.
  • Update the manual if you change something.
  • Include an example that uses the features of the new code and include the output of the example. This makes it easier to check if your changes have been included correctly.
• In order to make code management easy, please observe the following rules:
  • Do not change the layout of the code because you do not like the style. This makes it a lot harder when merging updates from several sources into one source file.
  • Do not use tabs, use spaces. (Tabs may expand to different amounts of white space from one machine to another, thus making it hard to understand the code).
  • Always do a dealer -V before submitting the code and include that information, but never update the strings that produce the version info in the source. The code management system will take care of that.
  • I do not really care if you submit complete source files or just diffs, but do not submit source files that have not been modified.