Hey Massimo,
if I got you right, you use the index for identifying methods in source code that contain use an instance of, say, Display, and the use your AST scanner to find the interesting definitions. Right?
Sounds reasonable to me. Though, the performance could be improved with some modifications in the indexer. Should we store the definition in the index too so that you can read this field from the Lucene document directly? Would you give this a try to see how far we get with this? Then we might be able to get rid of the AST traversal and could make a very simple "clustering" (read duplicate filtering) and present the results in your extdoc provider.
BTW: I'd be curious to see a screenshot. If you like you can also tweet about it ;)
If you agree, please send me your gmail address so that I can set up the repository for you.
Best, Marcel
On 09.07.2012, at 12:16, Massimo Zugno wrote: Hi Marcel,this is an update of my progress on what we discussed in [1]. Based on what we said I set up an initial version of my index-based extdoc provider. This initial implementation search for all the usages of a selected type in the index, and then visit collected results searching for expressions, using my _expression_ visitor provided in [2]. At the moment there is no real aggregation of results, I'm more concerned on finding a better query to reduce the usage of AST parser. The problem at the moment is that the query I set up is pretty rough, it finds all the uses of a particular type, what I'm trying to achieve is something like "find all the type usages which are declarations or assignments and are not null". I spent some time getting more familiar with Lucene and our index' query terms, at the moment my setup results in:
- indexed plugins: o.e.pde.core, o.e.pde.ui, o.e.jdt.ui - index size: ~37MB - execution statistics: type: "org.eclipse.swt.widgets.Display";
index occurrences: ~100;
execution time: ~3.5s Let me know what you think. Do you think it's worth investigating on a more precise query? Or should I leave this task for later and start focusing on grouping the results?
Thanks, Massimo.
On Sat, Jun 30, 2012 at 12:12 PM, Massimo Zugno <d3k41n@xxxxxxxxx> wrote:
Hi Marcel,thanks for the update, these are good news and I agree with you, as soon as the indexer is committer we can start discussing more in detail my task.
Thanks, Massimo.
Short update: The codesearch incubator is almost ready to go. The repository has been created, gerrit configured, and the ip check of Tobias' code is complete. Please find some more details about how to access the new repository etc. below.
In the next days I'll commit parts of the indexer. Massimo, it would be nice to start a more detailed discussion on how to implement your definition recommender as soon as the initial indexer is committed.
Best, Marcel Begin forwarded message: Date: 29. Juni 2012 20:58:47 MESZ
Subject: [Bug 383511] Enable Gerrit for recommenders.incubator/org.eclipse.recommenders.codesearch.git
_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev
_______________________________________________ recommenders-dev mailing list recommenders-dev@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/recommenders-dev
|