SN Parsers

SN Parsers

[Mo DeJong]

Originally sent by : Andreas Kupries <a.kupries@westend.com>

> Kristoffer Lawson wrote:
>> Andreas Kupries <a.kupries@westend.com> wrote:

>>> Yes, this include structure looked very nice when I played with my
>>> recend download of SourceNavigator (Thanks Mo).  Using the
>>> infrastructure of SN (C parser, database of meta-information about
>>> the code) it should be easy to come up with some additional views
>>> showing us the, hm, 'tightly knotted' spots in the core.

>> I agree that SN is a great piece of software and highly useful for
>> that kind of stuff. I suggest everyone here tries it out.

>> Now if only I could get it properly interfaced with emacs and to
>> understand XOTcl classes etc ... ;-)

> Hey, that reminds me. If anyone would like to help improve the Tcl
> language parser in Source-Navigator, we would really like to hear
> from you on the SN mailing list.

At first I wanted to say 'Just use the tcl parser itself, as provided
by 'Tcl_ParseCommand' and 'Tcl_ParseExpr' and possibly extended from the
tcl side [*]', but when I realized that SN needs column and line
information, something these procedures do not provide.

> Some folks have already started working on a Perl and Python
> parser. Source-Navigator already has a Tcl parser, but it is not
> that great.

I glanced over the code and think that it is at least partly written
with the help of some scanner/parser generator I don't recognize.

> What we really need is for someone to write a front end
> to the regular Tcl parser that writes out Source-Navigator
> symbols. It would not be that large a project, we already have most
> of the parser utils in place.


Some other things.

Sebastien brought Autodoc back into focus and I remembered that I
wanted to rewrite it to use an extensible frontend to scan down
through a directory tree and apply a set of 'extractors' to all
eligible files. And part of the reason for the graph code in tcllib
was that I wanted some database to store the extracted relations
into.

Now with SN still in my mind I realize that SN has that framework of
scanners and database already in place. So, with some specialized
scanners to extract (or just take note of the location of)
documentation for procedures, classes, variables, etc. SN can subsume
Autodoc, Tydoc, TNA, robodoc, doxygen etc. and so on ... The only
other thing required are some backends which read the information from
the database (and possibly the code) and then generate some nicely
formatted pages. Special views, so to speak. And one formatter could
display such reports in Tk widgets (canvas, text, other ?)

Speaking of views, I would like to point you and the SN team to `VCG`,
a graph layout tool distributed under the GPL (see
http://www.cs.uni-sb.de/RW/users/sander/html/gsvcg1.html ). I guess
that the creation of a library from VCG's source for using its layout
algorithms is hard, but it has a batch mode where it processes a
textual graph description and then returns the description augmented
with node positions. Applications in SN are possibly the existing
include/symbol reference views (which have a certain irregularity in
their layout behaviour) and the creation of new (printable) views
showing chosen references and/or dependencies for the entire project.

Re: SN Parsers

[Florent Pillet]

Mo DeJong wrote:
>
> Speaking of views, I would like to point you and the SN team to `VCG`,
> a graph layout tool distributed under the GPL (see
> http://www.cs.uni-sb.de/RW/users/sander/html/gsvcg1.html ). I guess
> that the creation of a library from VCG's source for using its layout
> algorithms is hard, but it has a batch mode where it processes a
> textual graph description and then returns the description augmented
> with node positions. Applications in SN are possibly the existing
> include/symbol reference views (which have a certain irregularity in
> their layout behaviour) and the creation of new (printable) views
> showing chosen references and/or dependencies for the entire project.

On the same topic, there is also GV (GraphViz) from ATT, which is a very powerful graph
engine and already comes with TCL interfaces and lots of other stuff. The quality and
versatility of the graphs it can generate is amazing.

Here is the URL: http://www.research.att.com/sw/tools/graphviz/

-- 
Florent Pillet, Software Architect. e-mail: fpillet@opteway.com
opt[e]way S.A., 2881 route des cretes, BP 308
06906 Sophia Antipolis Cedex, France
Phone: +33 4 92 95 26 13 - Fax: +33 4 92 95 26 03
http://www.opteway.com/

Re: SN Parsers

[Mo DeJong]

On Thu, 3 Aug 2000, Florent Pillet wrote:

> On the same topic, there is also GV (GraphViz) from ATT, which is a very powerful graph
> engine and already comes with TCL interfaces and lots of other stuff. The quality and
> versatility of the graphs it can generate is amazing.
> 
> Here is the URL: http://www.research.att.com/sw/tools/graphviz/

We are definitely going to need to look into GraphViz, that
"spline o-matic" looks too cool for words. Our current
graphing layer leaves a bit to be desired.

thanks for the pointer
Mo DeJong
Red Hat Inc