Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: Fw: [cdt-dev] Questions about indexing

Life isn't easy boy ;-)

Please don't introduce the dependency on ICElement from search unless you 
absolutely have to.  It's not clear to me that there will be ICElements 
for everything we want to search for and I'm not sure how the lifecycle of 
an ICElement will meet your needs.  The whole thing scares me...

Doug Schaefer, Senior Software Developer
IBM Rational Software, Ottawa, Ontario, Canada

Andrew Niefer/Ottawa/IBM@IBMCA 
Sent by: cdt-dev-admin@xxxxxxxxxxx
07/07/2003 10:50 AM
Please respond to


Re: Fw: [cdt-dev] Questions about indexing

Its more about the reporting of the results.  We need something to put in 
the search pane that has enough information to be able provide the proper 
labels and sort the elements (by name, by parent, by path), and also to 
support "Search Again" from the search pane.  It doesn't necessarily need 
to be an ICElement, but if we can get them, it would probably be the 
easiest way. 


Douglas Schaefer/Ottawa/IBM@IBMCA 
Sent by: cdt-dev-admin@xxxxxxxxxxx 
07/07/2003 10:35 AM 

Please respond to


Re: Fw: [cdt-dev] Questions about indexing

Why is ICElement involved in search?

Doug Schaefer, Senior Software Developer
IBM Rational Software, Ottawa, Ontario, Canada

Andrew Niefer/Ottawa/IBM@IBMCA 
Sent by: cdt-dev-admin@xxxxxxxxxxx
07/07/2003 10:23 AM
Please respond to


Fw: [cdt-dev] Questions about indexing

It seems I forgot to switch the dev list to my IBM address, so my first 
message didn't go through (see below). 

I also didn't mention below, its not quite clear yet how the search engine 

is going to get from AST node to ICElement (whether it builds its own 
ICElements or tries to find the correct one from the C Model).  The AST 
nodes contain all the information you want, so a visitor to that tree 
could be enough for code assist. 

----- Forwarded by Andrew Niefer/Ottawa/IBM on 07/07/2003 10:20 AM ----- 
Andrew Niefer/Ottawa/IBM 
07/07/2003 10:02 AM 

cdt-dev@xxxxxxxxxxx, cdt-dev-admin@xxxxxxxxxxx 
Re: [cdt-dev] Questions about indexingLink


The outline of the searching goes like 1: get from the indexer a list of 
files to look in, 2: use the parser to search those files, and 3: report 
any matches. 

1) Starting in,  get the index manager call it with a 
new search job.  This part is still under development, but the ultimate 
result will be a collection of paths in which we will find references to 
the item in question.  (Bogdan knows the details here more than I) 
2) With this collection of paths,  make a new MatchLocator and call 
locateMatches.  MatchLocator implements the parser interface 
ISourceElementRequestor.  It starts a parse for each file returned from 
the indexer, and it uses the ICSearchPattern as it receives AST nodes to 
determine if it finds a match. 
3) Matches are reported to ICSearchResultCollector.  This class is still 
being worked on, but the idea is to create an ICElement  using the 
information from the AST node and then hook that up to an IMarker and put 
it in the search pane. 

In general, I think if the code assist wanted to use the search engine, it 

could implement ICSearchPattern and ICSearchResultCollector to decide for 
itself what is a match and then what to do with that match. 


"Thomas Fletcher" <thomasf@xxxxxxx> 
Sent by: cdt-dev-admin@xxxxxxxxxxx 
07/06/2003 02:30 PM 

Please respond to


[cdt-dev] Questions about indexing

So with the recent flurry of activity on indexing I thought .. well now
be the time to start looking at improving the current content assist.  So 
started looking into the indexing ... and I got confused.

There is the original IndexModel defined in
Using this very simple indexing model I would do:

  IndexModel model = IndexModel.getDefault();
  ITagEntry [] tags = model.query(project, "*string-reg-exp*", false,

Which was mega simple, but also very far from being complete (even though
tags theoretically included lots of additional information about variables
and types etc).

Looking into the search stuff under development I found the new indexing
  CModelManager modelManager = CModelManager.getDefault();
  IndexManager indexManager = modelManager.getIndexManager();

  indexManager.performConcurrentJob(new PatternSearchJob(),


I looked at PatternSearchJob() and it is pretty well an empty shell at the
moment since
it is under development, but even then I don't see what the interaction is
between this
class and the actual "searching for something" since there is also a
mysterious MatchLocator/
ICSearchPattern whose roles have to do with reporting the match back, but
seem to be
distantly located from the the indexManager and more related to the

My question is, can someone outline the basic flow of how I would be able 
use the
facilities of the new indexer to programmatically generate an array of
entries which might
match a given expression.  As a starter I'll provide my current guess (and
its problems?):

- Create a new search engine using SearchEngine()
- Create a search pattern using SearchEngine.createSearchPattern()
- Create a collector which will grab the results and stuff them somewhere
- Limit the scope appropriately and execute the search engine with the 
pieces (incidentally can I limit the scope to variables local to a
function? Can
I limit the scope to global variables? ... didn't see this in the

My question on this, is that the results returned back by the collector 
file oriented, though there is an ICElement included.  Lets say that I
submit a
query and get back a function and a variable: foofunc and foovar.
- I can get the element name: Great!
- Can I get the return value/parameters for a function or the type
for a variable?  Is is possible to go back to the model easily given an
to extract this information?

I'll wait until I hear back on this until I decided to go further and
replace/enhance the
editor code completion facility.


cdt-dev mailing list

cdt-dev mailing list

Back to the top