Effective ways to request help with Tcl-related problems

Effective ways to request help with Tcl-related problems

Description edit

Here are some of the places on the internet where questions relating to how one programs in Tcl, or makes use of Tcl, can be discussed.

LV:

My first suggestion is to take several deep breaths, as it sounds like you are about to hypervenilate.
Be prepared to show what your current code looks like.
As specifically as possible, tell what it is that the shown code should do. If your code is very long, feel free to visit the wiki's [graffiti] or new pages page and start a new wiki page and just glue your code in there and then give a url. Or, if you have your own web page, just give a url to that.
tell what kind of computer and operating system you are using, along with what version of tcl/expect ...

These steps will help you in that focusing on positive actions should slow down your heart rate and regulate your breathing... and for us it provides us a common background from which to try to help you.

Cameron: On communicating code fragments and the limitations of this medium: the constraint is a good thing. Working to reduce your situation to a textual description augmented by at most a couple of lines of code is sure to benefit everyone concerned.

LV: Good point - I really hammer my users on this point. Handing me a foreign piece of code thousands of lines and procs long is guaranteed to cause me to try to hand it back ... On the other hand, showing me a small piece of code - hopefully stand alone so that I can try it on my machine without having to load and build a thousand pieces - results in me being able to 'tinker'.

DNew: Also, it can be helpful to describe the larger, over-all problem in addition to the Tcl question you have. You may be seeking help getting a sub-optimal solution working, or someone else may have already solved the larger problem for you.

[Months later, CL muses on the idea of construction of minimal examples.]

LV: later muses that often he finds the person asking the question is too close to the trees to see the forest - that is to say, asks questions about the immediate error rather than stepping back and seeing if there are more fundamental misunderstandings or assumptions. CL replies, though, that it's hard to know how to operationalize that, in a content-free way. The naive can easily go too far in the other direction. On one hand, yes, people frequently come through asking extremely involved questions about the Tcl/Tk Tclet Plugin, say, without understanding the most basic facts about the differences between server-side and client-side processing. On the other hand, we have folks who give us pages of details about version numbers, processor variant, script source, and so on, when all that's going on ("in their visible spectrum") is that they have "" where they want {}. All I know to do is condition people to expect to engage in civil, productive conversation.

Without qualification, "urgent" might mean anything from a few hours to a few months, and "beginner" ranges between twelve-year-old with first computer to fifty-five-year-old engineer who has used Expect for a decade without realizing it's a superset of Tcl. The quality of questions strongly determines the quality of responses that you will get.

LV: Just a bit of internet manners to consider. Most people don't want to receive personal phone calls, or visits at the house, from internet strangers. So please exercise restraint.

On the other hand, in this age of lawsuits, developers should not be surprised, or offended, if a company requests contact information about a package they want to use. Just because the package has a BSD license, GPL, etc. doesn't mean that the lawyers won't push for such information so that they can clarify any ambiguous wording in the license.

Category Community

See Also edit

Description edit