[9fans] ctags on plan 9 with acme-friendly tags

[9fans] ctags on plan 9 with acme-friendly tags

[Anthony Sorace]

i occasionally have to deal with moderate to large bodies of code
written by others and of questionable structural integrity. most often
this is C code, but sometimes its other things. there are a few tools
i've seen which help on the learning curve; ctags is one of the more
significant one.

i've gotten Exuberant Ctags 5.7 to run on plan 9 ("ported" is a bit
strong; it was two tweaks after './configure'). i've also added
options to produce filename:line tags for acme and the plumber. i'm
cleaning things up a bit for upstream submission, but in the mean time
you can get what i've done at /n/sources/contrib/anothy/src/ctags;
there's a README.plan9 that gives instructions for building ('make
ctags' under ape and then 'cp ctags $home/bin/$objtype', basically)
and what the changes from the distribution were.

exuberant generates tags for a dozen or so languages, but i've only
tested it with C; i'll be pushing some perl and php at it this week.
if anyone would like to try it with anything else it supports, please
let me know how it goes.

i'm considering doing a limbo parser; exuberant makes it relatively
easy to add language. of course, i've never seen limbo code convoluted
enough to make it relevant there. i'm also considering writing a
program for use with acme's 2-1 chord to look up elements in a tag
file. if anyone's interested in either of those (either has a use for
them or would like to do them), let me know.

i'd like to get something that'll generate visual static call graphs
eventually (feed into graphviz, perhaps), but i'm not likely to spend
any time on it in the near future. if anyone's look at that, i'd love
to hear about it.

incidentally, the levels of (mis?)indirection in exuberant's argument
processing are truly "impressive".
anthony

Re: [9fans] ctags on plan 9 with acme-friendly tags

[ron minnich]

I'm interested, I've wanted a tag-like thing for Acme for years, and
was too lazy to write it.

ron

Re: [9fans] ctags on plan 9 with acme-friendly tags

[Steve Simon]

there was somthing which analysed C and produced a call graph in the form
of input for dot(1) years ago, the problem was a complex program produced a
complex graph... I will try to find out the packages name if required, I have
a feeling it may have been in comp.sources.(unix misc).

My personal favorite for analysing other peoples code is to a regular expression
to strip (possibly misleading) comments from the code. I then toggle Undo/Redo
as I read the code; but this is old news I expect.

I wrote a crude tool for indexing large chunks of C source in my contrib area
(srch) it uses lex(1) only so much of its crudity comes from its vague understanding
of C syntax.

nemo released some interesting indexing tools (in his contrib area) for plan9 but to my
chagrin I have yet to try them.

-Steve

Re: [9fans] ctags on plan 9 with acme-friendly tags

[Anthony Sorace]

someone on irc pointed out nemo's tools when i was most of the way
through getting ctags to work. they do look interesting, the tagfs
thing particularly. i continued with ctags because it's cross-platform
(i do much of my programming with acme on OS X) and has a good range
of languages (nemo's man page talks about several languages, but i
could only find the tagger for C).

Re: [9fans] ctags on plan 9 with acme-friendly tags

[Eric Van Hensbergen]

On Feb 17, 2008 1:01 AM, Steve Simon <steve@quintile.net> wrote:
> there was somthing which analysed C and produced a call graph in the form
> of input for dot(1) years ago, the problem was a complex program produced a
> complex graph... I will try to find out the packages name if required, I have
> a feeling it may have been in comp.sources.(unix misc).
>

Doxygen does this (and data-structure graphs as well) - I'm not sure
if its a component which could be easily extracted or not.
Actually, I just did this to look at the data-structures and
call-graphs for v9fs (http://www.kernel.org/~ericvh/doxygen)

            -eric

Re: [9fans] ctags on plan 9 with acme-friendly tags

[Fco. J. Ballesteros]

>  of languages (nemo's man page talks about several languages, but i
>  could only find the tagger for C).

If you don't provide your own tagger, it assumes it's text, which works
mostly ok. If you want a tagger for a particular language you may
do it with a simple script, probably. The one supplied was just an example.

Re: [9fans] ctags on plan 9 with acme-friendly tags

[balaji]

I still use 'cscope' and 'mlcscope'. Still the best for me.
Any acme support for this will be great as well.

On Feb 16, 2008 9:34 PM, Anthony Sorace <anothy@gmail.com> wrote:
> i occasionally have to deal with moderate to large bodies of code
> written by others and of questionable structural integrity. most often
> this is C code, but sometimes its other things. there are a few tools
> i've seen which help on the learning curve; ctags is one of the more
> significant one.
>
> i've gotten Exuberant Ctags 5.7 to run on plan 9 ("ported" is a bit
> strong; it was two tweaks after './configure'). i've also added
> options to produce filename:line tags for acme and the plumber. i'm
> cleaning things up a bit for upstream submission, but in the mean time
> you can get what i've done at /n/sources/contrib/anothy/src/ctags;
> there's a README.plan9 that gives instructions for building ('make
> ctags' under ape and then 'cp ctags $home/bin/$objtype', basically)
> and what the changes from the distribution were.
>
> exuberant generates tags for a dozen or so languages, but i've only
> tested it with C; i'll be pushing some perl and php at it this week.
> if anyone would like to try it with anything else it supports, please
> let me know how it goes.
>
> i'm considering doing a limbo parser; exuberant makes it relatively
> easy to add language. of course, i've never seen limbo code convoluted
> enough to make it relevant there. i'm also considering writing a
> program for use with acme's 2-1 chord to look up elements in a tag
> file. if anyone's interested in either of those (either has a use for
> them or would like to do them), let me know.
>
> i'd like to get something that'll generate visual static call graphs
> eventually (feed into graphviz, perhaps), but i'm not likely to spend
> any time on it in the near future. if anyone's look at that, i'd love
> to hear about it.
>
> incidentally, the levels of (mis?)indirection in exuberant's argument
> processing are truly "impressive".
> anthony
>

Re: [9fans] ctags on plan 9 with acme-friendly tags

[Anthony Sorace]

Okay, /n/sources/contrib/anothy/rc/bin/looktag is useful, i think.
It'll take a list of tags as arguments, look for them in a tags file
(-f file, or tags in the local dir by default), and plumbs the results
correctly. It's intended so that if you put it in the tag of an acme
window, 1-click at an identifier, and 2-1 chord looktag, it'll do the
right thing.

It'll handle multiple tags and multiple occurrences correctly. If
multiple tags are in one file, you only get the last one (I suppose
one could Zerox the window for each occurence if the file's already
open; have at it). I believe it'll work properly with p9p, but have
not tested it (later tonight).

As an aside, it might be nice of Acme provided the path or file name
the supplied argument in a 2-1 chord came from in the environment
somewhere. I imagine it'd be useful more generally, but here it'd
allow sticking (a modified) 'looktag' in a Guide file or similar and
using that for every window, rather than typing it in every window's
tag.

I spent a few minutes looking at doing a Limbo tagger and decided it
wasn't worth it for me, but I'd be interested if anyone decides to
give it a go.
Anthony

Re: [9fans] ctags on plan 9 with acme-friendly tags

[Douglas A. Gwyn]

Steve Simon wrote:
> there was somthing which analysed C and produced a call graph in the form
> of input for dot(1) years ago, the problem was a complex program produced a
> complex graph...

I think there are quite a few programs of that kind these days;
Doxygen seems to come to mind..  For C++, there are class browsers.
The problem, as you noted, is that poorly structured large programs
tend to produce poorly structured large call graphs.

Whenever I have gotten involved with analyzing such code prior to
making significant changes, I've found it easier to redesign and
recode it from scratch, using the old code only for reference
concerning existing data formats, etc.