Updated 2014-12-14 04:28:45 by RLE ▲

Purpose:to provide some pointers and guidelines to people wanting to report a bug in Tcl.

First, it is very important to be certain that you have a real bug.

To determine this, you can do research on your own, and if it appears that you have a bug post a note to the Usenet news group news:comp.lang.tcl. It is an unmoderated Usenet newsgroup, created for the discussion of the Tcl programming language and tools that use some form of Tcl (such as extensions like Tk, Extended Tcl, and Expect).

When you post a question about a potential problem/bug, be sure you mention what hardware and operating system you are using (e.g. Pentium 100 Mhz running Linux version x.y.z), what version of tcl/tk you are using (e.g. Tcl/Tk 8.3.2), what extensions (and versions) you are using (e.g. tclX, itcl, tix, blt, etc.), and any local modifications you have made. Then, provide if possible either a small piece of code, or a URL (e.g. ftp://ftp.myhost.com/some/path/stuff.tcl) to a small coherent example of code which demonstrates the problem. Either have the code explicitly mention "here's what I thought would happen", or mention this in your posting. Also, if the code used to work, mention which configuration you used and what you have changed.

Most of all, be sure to provide an email address that is valid, and be sure to watch the usenet newsgroups for responses, since seldom will folk send private email on a matter which likely is of public interest. But if your problem is urgent, they might try to send you email. If you have 'spam-proofed' your email address, you might make it so 'secure' that no one can send you a solution! On the other hand, if you DO get private email replies, remember to post a summary of what works to the group, so that future generations can benefit from your learning experience.

If something in Tcl fails, don't just say "Tcl_Eval() fails" (or whatever function) but tell the readers specifically what type of failure occured (Segmentation fault, system error 403, or whatever), or what error codes were returned, what values were left in $errorCode and interp->result, and so on.

Note also that Tcl and Tk support, as well as support for a number of other extensions, has moved over to SourceForge. You should use this SourceForge bug-reporting interface once you have identified the specifics of the bug. Before reporting the bug, check to see if it has already been reported and fixed. I found http://www.geocrawler.com/mail/msg_raw.php3?msg_id=4673084 to be a msg describing the searching of the Bug database. If you use this interface, be sure to provide specific information about your platform, version of tcl, and code which can easily duplicate the bug. Then the bug can be examined, verified, logged and possibly fixed in a future Tcl/Tk release. If you have devised a fix or work around (commonly referred to as a patch) for any Tcl or Tk related software, be sure to notify the support team on SourceForge.

Where is The Bug Directory? The relevant urls are

Note that there is also a mechanism for submitting requests for enhancement. See the http://tcl.sf.net/ page for the link. NB: that page is now defunct. The nearest equivalent is probably the TIP process.

Question: Does anyone read the bug reports submitted to core.tcl.tk? Do they get fixed?

A: Fossil (the bug tracker software) sends e-mail to the developer(s) responsible for the area the bug gets filed in. Most bugs do get fixed (compare the number of open bugs to the number of all bugs), but some may be tricky, and the developers don't always agree with the reporters on what constitutes a "fix".

Question: Does anyone read the requests for enhancements? Do they ever get implemented?

A: See Tcl Improvement Proposal for details of the process.

Out-dated information of mostly historical interest below:

But, isn't SourceForge pretty complex? Bob Techentin wrote on news:comp.lang.tcl:

You can contribute to a sourceforge project without any complex setup. Click on the "Bugs" or "Patches" link on most sourceforge projects, and you can enter bug reports, suggestions, or code for patches. You may do so without a sourceforge ID. It asks for an email address, but you can submit anonymously if you feel you must.

You may easily create a sourceforge ID, which allows you to "log in" to the sourceforge site, post in forums, and otherwise participate as a specific person. All this requires is a web browser that does SSL. My Netscape 4.5 works just fine.

If you want CVS access to sourceforge projects, you'll need to install CVS. If you want to be a project admin, do file releases, manage your project's web pages, use the compile farm, and some other activities, you'll need ssh to log in to the shell accounts. The "Site Docs" describe how to set up ssh for secure telnet.

Category Community