Next: Distributing, Previous: Uninstalling, Up: Installation [Index]
If you can’t get C-INTERCAL to install at all, or something goes wrong when you’re using it, reporting a bug is probably a good idea. (This is still important even if you figure out how to fix it, and the information isn’t in the manual, because the fix can be added to the source code if possible, or at least to the manual, to benefit future users.) For general help, you may want to post to the alt.lang.intercal news group; to report a bug or submit a patch, email the person who released the most recent C-INTERCAL version (which you can determine by looking at that newsgroup).
If you do find a bug (either the compiler not behaving in the way you’d expect, or if you find a way to cause E778 (see E778) without modifying the source code), it helps a lot if you can submit a bug report explaining what causes it. If you’re not sure, say that; it helps if you give examples of input, command line options, etc. that cause the bug. There are several debug options (see Debug Options) that you can use to help pin down a bug if you’re interested in trying to solve the problem yourself; looking at the output C code can also help pin down a bug if the compiler gets that far.
Information that should be given in a bug report is what you expect to
happen, what actually happens, what input and command line options you
gave to the compiler, what operating system you’re using, any
ideas you might have as to what the problem is, and any appropriate
debug traces (for instance, -H (see -H) output if you think the bug is in
the optimizer). Core dumps aren’t portable between systems, so
don’t send those; however, if you’re getting an internal
error and can dump core with -U (see -U), it helps if you can load a
debugger (such as gdb
) on the core dump, use the debugger
to produce a backtrace, and send that backtrace.
If you figure out how to solve the bug yourself, and want to submit the
patches to help other users (this also carries the advantage that your
patches will then be maintained along with the rest of the
distribution, and that you won’t have to reapply them every time
you upgrade to a newer version of C-INTERCAL), you must
first agree to license your code under the same license as the code
that surrounds it (normally, that’s the GNU General Public
License, but if you submit a patch to a file with a different license,
like this manual (yes, documentation patches are useful too), you must
agree to that license). You will be credited for the patch in the
source code unless you specifically ask not to be or you don’t
give your name (in both these cases, you must license the code to the
public domain so that it can be incorporated without the attribution
requirement). Preferably, patches should be submitted in the format
created by the command diff -u
; this command is likely to
be available on UNIX and Linux systems and versions are also available
for DOS and Windows (including a DJGPP port of the GNU version). If you
can’t manage that, just submit your new code with enough lines of
old code around it to show where it’s meant to go, and a
description of approximately where in the file it was. Patches should
be submitted by email to the person who most recently released a
version of C-INTERCAL.
If you have a suggestion for a new feature, it makes sense to first discuss it on the alt.lang.intercal news group; other INTERCAL compiler maintainers may also want to implement that feature. If you have developed code to implement that feature in C-INTERCAL, you can submit it the same way that you would submit a patch for a bug.
Next: Distributing, Previous: Uninstalling, Up: Installation [Index]