I'm definately not trying to solve the general case: I'm actively trying to duck issues like "eval" and closures because the code executed by them is often only known at run time.

Similarly, with an object oriented approach, the same function may return objects of different classes depending on the data passed to it.

In all those cases, I'm of the opinion that a call stack isn't going to help very much anyway: the details have been abstracted far enough away that a simple overview document will probably do a poor job of explaining them, anyway.

Fortunately, the majority of the code I'm trying to document is code that I wrote myself, or that my co-workers did. We tend to write in a procedural style, and we tend to avoid evals and closures unless they really add something to the code. This makes "tricky stuff" rare in practice. As for recursion, I deal with it by only printing the call stack for a function the first time it's seen. This also saves space, making the overview document smaller, and hopefully, simpler.

I did consider the run-time approach. It requires that we have a full data set of inputs that's known to cover all code paths. In practice, I doubt that will be the case, though of course it should be. It would also take a lot more development time, which is a bit of an issue, I think.

I get to work on this at work because I figured out how to make it work (to the extent that it does) in a short amount of time, but it's not a long term project that I'm assigned to. So I probably can't put too many hours into it, unfortunately. :-(

I started out by parsing the output of B::Concise, but found that B::Xref provided a closer fit for what I was trying to do, and was a lot simpler, so I'm using it now. If there's something that's more stable/gives file/line-number references, etc., I'd like to hear about it.

However, the main issue I'm still really struggling with is how to tell whether a function was "born" in main, or whether it was exported there. Being able to detect un-called functions in code I'm developing is handy -- being swamped with agressively exported routines is not...

Thanks to both of you for your replies... I think I agree with all your points, I'm just trying to weasle out of all the hard questions. :-)

-- Ytrew Q. Uiop

In reply to Re^3: Auto-generating annoted call trees by Ytrew
in thread Auto-generating annoted call trees by Ytrew

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.