Fwd: I released the refactoring tool

Tu Do <[email protected]> Mon, 16 Feb 2015 06:00:59 +0700
Newsgroups gmane.emacs.cedet
Message-ID <CAOEd9jk_AC6N1RBx7f7N9csFOTS3JS=RKTyLcsFRT3yVoVJ+NA@mail.gmail.com>
---------- Forwarded message ----------
From: Tu Do <[email protected]>
Date: Mon, Feb 16, 2015 at 5:54 AM
Subject: Re: [CEDET-devel] I released the refactoring tool
To: David Engster <[email protected]>


> That's my plan as well, using libtooling.

That's great if you can take care of this. I would not want to wait forever
until we are permitted to use GCC :)

> Not sure what you're planning here. Do you want to replace Semanticdb
completely, or do you want to make Sqlite a back end for Semanticdb?
Hard to say how much that would gain, since AFAIK, there's no efficient
way to transfer large amounts of data between Emacs and Sqlite.

I want to make Sqlite a backend for SemanticDB, not replacing it with my
own, since it is possible to use another backend (if I understood correctly
from Semantic documentation). It's hard to say whether it works well enough
until we try. But I think at the current state, Emacs is pretty good at
retrieving and processing data from external process. For example, I use
helm-ag that uses Ag with Helm interface to search for a large amount of
text, and the results are updated for every character I entered into the
prompt. It looks like this: http://tuhdo.github.io/static/live_grep.gif

Another example is helm-gtags: https://github.com/syohex/emacs-helm-gtags that
uses GNU Global tag database and Helm frontend. It searches very fast and
gives results instantly, even if there are more than 10,000 matches and
won't block Emacs.  I am using it to surf through large code base with
ease.

The benefits are:

- Async: this alone is worth it.
- Code querying with a popular and robust language. This will enable people
to write small utilities using SQL, such as code metrics or statistics.
With an actual database engine, we can do operation like searching for all
functions that call current function, accurately; or all files that include
a particular header files; or see all the included files that contain the
definitions of tags in a current class; or simply creating a class index of
a project (similar to what Ebrowse does, but for large index, it took Emacs
really long to load all).... All of this can be delegated to a fast
database engine. All we need is a properly designed database for tags.

On Mon, Feb 16, 2015 at 5:24 AM, David Engster <[email protected]> wrote:

> Tu Do writes:
> > As discussed before, in the long run, I want to write an source code
> indexer
> > with Clang that is compatible with Semantic, so the built-in parser only
> needs
> > to be responsible for new code entered from the keyboard, not existing
> code
> > which could be huge.
>
> That's my plan as well, using libtooling.
>
> > Also, I intend to use Sqlite to store create a real tag database. The
> > advantages:
> >
> > - We can do async operation because Sqlite is an external process, so
> Emacs
> > does not have to do the heavy lifting of various tag querying operations
> and
> > does not have to keep tags in memory. The database can take care of it.
>
> Not sure what you're planning here. Do you want to replace Semanticdb
> completely, or do you want to make Sqlite a back end for Semanticdb?
> Hard to say how much that would gain, since AFAIK, there's no efficient
> way to transfer large amounts of data between Emacs and Sqlite.
>
> -David
>

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/

_______________________________________________
Cedet-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cedet-devel