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

[Richard Foltyn <richard.foltyn@gmail.com>]

Nick, thanks for your input.

I also believe that debugging should be done proactively, in
particular if one has a different programming language background, as
then Stata's treatment of macros is not what one is used to.
I therefore run all of my code with trace enabled at least once to
check whether macros expanded to what I expected them to.

Coming to think about it, it seems to be quite simple to write an
analogue to -quietly- for tracing that suppresses output. I've come up
with the following program

capture program drop dbg_off
program define dbg_off
    local trc = c(trace)
    set trace off

    // execute whatever was passed as arguments
    `*'
    set trace `trc'
end


which restores the initial trace depth after executing the desired
command. At least so far this has worked as expected, e.g. by calling

dbg_off tostring varname1 varname2 varname3, generate(strvarname1
strvarname2 strvarname3)

Using this method on -tostring-, -clear- and -egen- in my code reduced
the log size from 5.6mb to only ~25kb, so almost all the "noise" I did
not care about was gone.
I just hope that there are not side effects which I missed.

The only downside is that there are still ~4 lines in the trace log
that cannot be completely eliminated, but for me that is much better
than hundreds of irrelevant lines.

Best,
Richard

On Thu, Jul 11, 2013 at 3:18 PM, Nick Cox <njcoxstata@gmail.com> wrote:
> 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.
> Nick
> njcoxstata@gmail.com
>
>
> On 11 July 2013 11:30, Nick Cox <njcoxstata@gmail.com> 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
>> njcoxstata@gmail.com
>>
>>
>> On 11 July 2013 10:27, Richard Foltyn <richard.foltyn@gmail.com> 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/
*
*   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/