Re: [anjuta-devel] RFC: Symbol-db future

[Massimo Cora' <maxcvs email it>]

Hi,

On 12/10/2010 03:16 PM, Johannes Schmid wrote:
> The symbol-db should automatically scan all symbols from packages we can
> find using the pkg-config parsing of the project manager (+ meta-package
> for libc and libstdc++). As this depends on the language used (and it
> doesn't make sense to create a database if we have only non-C languages
> used) this will be handled by the language-support plugin:

by non-C languages do you mean gc languages as java*/python?
From what I see those languages provide completion by using an 
interpreter which scans the file the user is currently on. My question 
is: what about if you have a project, say in python, with tens or 
hundreds of files? The run time intepreter will have some scalability 
issues I suppose.
On the other hand it could be difficult to provide a db (the symbol-db 
one) and interface this with the interpreter.

> * Get the packages from the project-manager
> * Check for dependant packages and their include dirs (new libanjuta
> API)
> * Call ianjuta_symbol_manager_add_package() for all needed packages
> (we can skip package_(de)activate probably - see below)
>
> Get exact symbols for a file :
> (see https://bugzilla.gnome.org/show_bug.cgi?id=630198)
>
> We can get a list of files included by a particular source file using
> "gcc -MM file.c -I..." and as we know the include directories from
> pkg-config we can also easily add the needed -I flags. This is also a
> responsibility of the language-support plugin.
>
> As it would take too long to rescan those files everytime and we already
> have the global database I was thinking about creating a temporary
> (in-memory) database holding only the symbols we want. Pseudo SQL
>
> SELECT WHERE (file-list contains filename) from symbols>>  temporary
> database

you can filter the symbols from a main db without the need of creating 
temp dbs.

> * we would need to update the temporary database when the file is saved
> by keeping the project database consistent. That could be tricky. On the
> other hand we probably want to regenerate the database anyway when the
> file is saved because there could be more include files now.

one of the problems of the temp db is its maintenance.

> As a sidenote, that temporary database could be used for the "File" tab
> or symbol-db, too.

the temp db could be used when visiting non-project files, that haven't 
any reference of disk-db.

> Advanced queries (lower priority)
> ----------------
>
> I think I posted about this some months ago. Actually we would need
> something like this (simplied)
>
> symbol_query_in_scope (SymbolIter* scope, const gchar* search_string)
>
> which would return all found symbols that are available in scope
> including those of global scope. As an example if the scope is a method
> inside a class:
> ->scope of method
>   ->scope of file
>   ->scope of class
>    ->scope of parent class(es)
>     ->scope of namespace
> ->global scope

isn't "IANJUTA_SYMBOL_QUERY_SEARCH_IN_SCOPE: Query to perform substring 
search in a scope. " what you mean?

regards,
Massimo