Bookmark and Share

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


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

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


From   Nick Cox <[email protected]>
To   "[email protected]" <[email protected]>
Subject   Re: st: Disable -trace- for built-in functions
Date   Thu, 11 Jul 2013 11:30:15 +0100

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
[email protected]


On 11 July 2013 10:27, Richard Foltyn <[email protected]> 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:
*   http://www.stata.com/help.cgi?search
*   http://www.stata.com/support/faqs/resources/statalist-faq/
*   http://www.ats.ucla.edu/stat/stata/


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