That is not so easy to define, but roughly these are bugs:
- Inconsistencies between standards (both ISO and de-facto) and
- Inconsistency between documentation and system behaviour (which
might be a bug in the documentation).
- Crashes. Any reproducible crash is worth reporting.
Non-experienced users are often surprised by how Prolog behaves. In the
vast majority of cases this is not a bug. Use the
forum/mailing list or
What do I include in the bug-report?
Typically, a report must include the parts below to be meaningful. This
is just a guideline, but if any of these parts are missing it is very likely that your report will not be answered at all or by additional questions.
- The version of SWI-Prolog you use and the operating system.
- A clear description on how to reproduce the issue. Typically,
his consists of:
- A complete program. Please do not send merely a fragment
- It costs us a lot of time to complete and
- we typically complete it differently and the problem doesn't reproduce.
Small programs are better, but it isn't always worthwhile to spend
effort in creating a small program. If the program is big, do not
include it in the first message, but merely describe that it is
available and what it would take to obtain and run it.
- The behavior you observe. If there are warnings or error messages,
include at least the first couple of them literally.
- The behavior you expected.
Where do I send my bug report
Preferably, bugs are reported using the GitHub issue
tracker. Bugs raised there
can be found by other users. Alternatively you can add a post to the
forum, preferably using the bugs
Finally, for bug reports containing information you do not what to
become public, bugs can be sent by
- See also
- - Raise an issue at GitHub
- - Submit a patch
- - "How to Report Bugs Effectively" by Simon Tatham, professional and free-software programmer