Bookmark and Share

Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: st: Disable -trace- for built-in functions

From   Nick Cox <>
To   "" <>
Subject   Re: st: Disable -trace- for built-in functions
Date   Thu, 11 Jul 2013 14:18:10 +0100

I have often thought that some kind of paper on debugging might
interest others, but I don't know how to write a good one.

When you are interested in doing that, it is hard to think up good
examples that don't look trivial, contrived or both.

Conversely, suppose you've just found a bug that was highly elusive.
Would this help others as a war story?  It is usually then obvious
that you made one stupid mistake originally and several stupid guesses
about what it might have been. Writing that all up is not appealing --
often the stupid guesses don't survive any way -- and it wouldn't
necessarily be instructive. Also, there would be a temptation to
sanitise the search to remove the really embarrassing dead ends and
repetitions, which wouldn't be realistic.

Yet another converse is that one might try to list common bugs, but
one needs good ideas on how to do that.

On 11 July 2013 11:30, Nick Cox <> wrote:
> By functions, you mean here commands. Stata has functions, but their
> code is inbuilt. (By functions I don't mean -egen- functions.)
> Short answer is No. Much of the point of how Stata is written is that
> your ado code and Stata's ado code are on the same level, which is
> usually a very good thing, but bites you here. What you are protected
> from seeing is Stata's built-in code (C, some of the Mata), but that's
> not pertinent.
> Being able to plan an ideal debugging strategy depends on knowing in
> advance exactly what the bug is, manifestly what one doesn't have.
> Some incomplete hints follow, at the risk of being very obvious. In
> this territory, the advice often looks like "To become rich, you need
> a lot of money". Or, closer to home, "To solve this differential
> equation, stare at it until the answer becomes obvious".
> * The art is to place -set trace on- and -set trace off- as deep in
> your code as you can and as close together as possible.
> * -set more off- and -set more on- can help.
> * Very long traces need not be awkward to inspect. Always open and
> close a log file around any long trace and scroll to the end of the
> log in your favourite text editor.
> * Debugging is often better done proactively rather than reactively. I
> spend a lot of time putting in markers such as
> di "here"
> di "there"
> to isolate a bug, together with tailored -display- and -list-
> statements to show  what exists and what values they have.
> * Sometimes to debug a program I need to write another program that
> includes just what appears to be problematic.
> * Use the smallest and simplest dataset you can devise that exposes
> the bug. The data need not be real.
> * Sometimes to expose an error in Stata code I try writing an
> equivalent in Mata. That can be easier to step through one line at a
> time and displaying stuff is easy. Sometimes the translation shakes
> loose an incorrect assumption or misconception.
> * Sometimes thinking through the problem in a different way can help.
> If your code is very concise, perhaps it is too clever and makes an
> assumption that is incorrect, and you need to take things more slowly.
> Sometimes you never find the original bug, but the different code
> works, so you move on.
> Nick
> On 11 July 2013 10:27, Richard Foltyn <> wrote:
>> Dear Stata listers,
>> is there any sensible way to disable tracing of built-in Stata
>> functions? I need to debug my nested code with tracedepth 3, but as
>> you can imagine this produces insane amounts of trace output from
>> built-in programs as well, resulting in a noise-to-signal ratio that
>> makes the trace output almost useless.
>> What is the best practice to avoid this issue? Is there something
>> similar to -quietly- that lets you disable tracing line by line?
*   For searches and help try:

© Copyright 1996–2018 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   Site index