call graph functionality

[sinbad]

hi,

i know many of the developers must be using vim to write
their c programs, but why there isn't an effort to add this
crucial functionality to vim. some vim scripts are available
to do exactly this, but they are not efficient and can't run
in parallel like figuring out function relationship in the
background.

thanks

[Sasha]

I guess you didn't like vim's cscope support (:help cscope) or the
CCTree plugin (http://www.vim.org/scripts/script.php?script_id=2368).

I assume you mean you want to generate vector/raster graphical
representations of the call graph. Doing this efficiently and well
realistically requires using a tool built for the purpose (e.g.
codeviz, just for one example: http://www.csn.ul.ie/~mel/projects/codeviz/)

Why not find a tool which does the job as you like it, and then map
keys to control that tool from vim?

Sasha

[sinbad]

i was referring to CCTree Plugin in my OP. the problem with that
script is it can't be run
in background (as none of the vim scripts can), while it is building
the call tree,
vim will not be available for editing, this is a big problem if the
source files are huge.
if vim has this capability in-built (like a pthread running in
background) then it will be of
useful. btw, i am not looking for any fancy graphical natured call
graphs. an ascii tree
like the one provided in CCTree will be enough.

[Ben Fritz]

On Mar 30, 2:35 am, sinbad <sinbad.sin...@gmail.com> wrote:
> i was referring to CCTree Plugin in my OP. the problem with that
> script is it can't be run
> in background (as none of the vim scripts can)

Not quite true. There are ways to do things in the background by using
the shell or an integrated scripting language like Python. Most
plugins don't use them, though. See the following:

http://vim.wikia.com/wiki/Execute_external_programs_asynchronously_under_Windows
https://github.com/MarcWeber/vim-addon-background-cmd

> while it is building
> the call tree,
> vim will not be available for editing,  this is a big problem if the
> source files are huge.

Yes, I have same problem with CScope. I haven't gotten around to
making my setup commands asynchronous, but I intend to do
so...sometime.

> if vim has this capability in-built (like a pthread running in
> background) then it will be of
> useful. btw, i am not looking for any fancy graphical natured call
> graphs. an ascii tree
> like the one provided in CCTree will be enough.
>

I don't use CCTree, if it's possible to load a pre-generated tree from
a file rather than generating it every time you open Vim, you could
create a command which would launch another Vim in the background,
generate this file, exit Vim, and call back into the current Vim
telling it to load the file. This could use the same techniques
discussed in the tip mentioned above.

[hari.ra...@gmail.com]

Version 1.21 of CCTree allows serialization of loaded cscope databases. So, you could run a vim process
in the background sourcing the script which goes something like:

load_my_cscope.vim:
:CCTreeLoadDB cscope.out
:CCTreeSaveXRefDb cctree.out

$ vim -S load_my_cscope.vim

Once it's done, you can load it in your current session with
:CCTreeLoadXRefDb cctree.out

The second load will take a few minutes usually. I'm currently testing a version that allows tracing from disk, requiring
no load time (If you would like to try that out, let me know).

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

[Ben Fritz]

On Mar 30, 11:41 am, "hari.rangara...@gmail.com"

<hari.rangara...@gmail.com> wrote:
> Version 1.21 of CCTree allows serialization of loaded cscope databases. So,
> you could run a vim process
> in the background sourcing the script which goes something like:
>
> load_my_cscope.vim:
> :CCTreeLoadDB cscope.out
> :CCTreeSaveXRefDb cctree.out
>
> $ vim -S load_my_cscope.vim
>
> Once it's done, you can load it in your current session with
> :CCTreeLoadXRefDb cctree.out
>
> The second load will take a few minutes usually. I'm currently testing a
> version that allows tracing from disk, requiring
> no load time (If you would like to try that out, let me know).
>
>
>

Wow! Does the initial generation/load take more time than the
secondary load (I hope it does)?

[hari.ra...@gmail.com]

I didn't quite get the tone of the "Wow!". But, yes, it does take a bit of time during the first load to parse through cscope database and build a cross-reference index. Note that its written in pure native Vimscript with no external tools or interpreters. Once serialized, subsequent loads will be extremely fast.

[sinbad]

hi hari,

i really appreciate your effort on this front.
i guess the only reason the script is not
being used by many hardcore programmers
is it's lack of usability for huge projects.
as it is obvious that you are clearly working
on it to make it better. i would love to give
it a try, but the only reasonable way for it
to become useful is when it gets the capability
to run in background.

cheers


On Mar 30, 9:41 pm, "hari.rangara...@gmail.com"

[hari.ra...@gmail.com]

I'm not sure I still get your exact requirements. The latest version of CCTree can load a kernel cscope
database of 280 Mb in about 10 mins, and now you have the option of saving a native cross-ref db
and loading it later; these only take about a couple of mins and you can reuse them (and also, I mentioned
 the next release will cover the loads directly from disk). If you can run multiple sessions of vim, you can load
the database in a session, save it and then load it to memory or trace from disk in any session. That would allow you
to continue your editing in another session; well, yes, it's like manual background processing.

On another note, background processing is something that Vimscript API should natively offer; there is nothing
that can be done inside a plugin to achieve that.