GSOC Proposal: Re-Writing SnipMatch Code Completion Engine

I am Madhuranga Lakjeewa. I hope to participate the Google Summer of Code 2013 with Eclipse Code Recommenders SnipMatch project. This is my project proposal. If you have any idea please comment here and i would be glad to hear your feedback.

Abstract

             SnipMatch is a code snippet search tool which falls under Eclipse Code Recommenders. It will be extended as a social snippet sharing tool in which the contributors can create and share snippets with others. Current version of SnipMatch can work only locally with a local snippet repository. But this current SnipMatch version has many problems in architecture level and code level. My proposal is to rewrite SnipMatch code completion engine by eliminating the current drawbacks.

Detailed Information

             Programmers often use code snippets to save their valuable time. But with the intention of time conserving they are wasting considerable amount of time to search good code snippets and customize those snippets to their code context. SnipMatch is the definite solution for this matter.
The core functionality of SnipMatch is providing code snippets quickly and adapting them to the current code context. Following are the major concerns which have been considered at the design of SnipMatch.

• Snippet repository (Local/Remote)
• Snippet Saving format
• Snippet Searching Mechanism
• Client UI

During last few years SnipMatch has been evolved through several design stages. Those are;

• SnipMatch with remote repository [1]
• SnipMatch with remote+local (Synchronized) repositories [2]
• SnipMatch with social snippet contribution [3]

             SnipMatch with remote repository was the initial idea. But the advantages of having a local repository were noticed later. A remote repository was not suitable for offline and slow internet connection usage. The next design stage was SnipMatch with a local repository which had been synchronized with the main remote repository. The major designs of this stage were discussed at the last year GSoC (GSoC 2012). The Social Snippet is the recent idea which has been immerged with GSoC 2013 idea list. It is about creating a social snippets infrastructure for SnipMatch, which allows developers to create and rate snippets.
Being interested on this idea, I started testing the current version of SnipMatch. As with the original GSoC 2013 idea, this version of SnipMatch should be extended to facilitate social snippet sharing. But I encountered several issues in the current version during the testing period.

1.     Snippet resolution mechanism does not work as intended. It does not support to the standard JFace language format.

         
           JFace template language is the standard Eclipse template language. In SnipMatch, the same language is used for code snippets. Then the code snippets can be easily handled by the JFace library. But the current version of SnipMatch does not support to Eclipse template language.

               Eg: In the SnipMatch snippet templates, Library imports are declared as;

${import(java.util.Arrays)}

               But in the standard forms like SWT statements imports are declared as;

${imp:import(java.util.Arrays)}

Even though SnipMatch core uses its own way of template variable declaration, it triggers errors. [4]

2.     Snippet editor is not user friendly.

                    Current snippet editor is just like a simple text editor. It does not provide color syntax or syntax suggestion for users. And the window is not re-sizable. Whole code should be edited in this small window.

3.     Snippet search pop-up dialog does not work properly.

                   Eg: Some times it does not give any suggestion, though we type a search pattern.

Above problems are not all the problems SnipMatch current version exhibits.  Those are the problems I could found.

             I discussed the above problems in the Bugzilla bug entity [5].  There is no point of extending the current version of SnipMatch without addressing the existing problems. It is not a simple task since reasonable architecture level and code level changes may be required for this. For an example, to solve the above 1st problem SnipMatch core should be re-written.
             This is my proposal for GSoC 2013. I will rewrite the SnipMatch code completion engine by eliminating the current problem. I am limiting my project scope to code completion engine. To achieve the ultimate goal of SinpMatch Social Sharing System, I believe that we should have a SnipMatch version which is perfectly functioning in local mode. My goal is to create the SnipMatch completion engine which is working 100% with a local snippet repository.

Technology

             Eclipse Rich Client Platform (RCP) is the main technology which I will be using. In addition to that I will get the help of Java language and its’ related technologies. I will use Eclipse Plug-in Development Environment (PDE) as my development environment.

Preparing Background

             Until GSoC program get started, I am expecting to do several background tasks. I want to test the current version of SnipMatch further and find more problems it has. I will create a detailed list of existing problems and potential solutions, which will assist me to re-design the SnipMatch architecture. In addition to that I will continue my studies on Eclipse RCP development.

Deliverables

             SinipMatch completion engine is my main output. It will produce all the functionalities locally with a local snippet repository which the ultimate SinpMatch snippet sharing system required. Following features will be included in my final output.

• SnipMatch preference window.

                     This window will provide the functionalities which are required to configure SnipMatch. In addition to that there will be entry in the 'Colors and Fonts' section in 'General->Appearance' for SnipMatch. It will allow users to change the colors and fonts in SnipMatch search view.

• SnipMatch search view.

                    Drop down search view with suggestions. A preview will be shown with the user ratings.

• SnipMatch search engine.

                     A good search engine with more intelligent suggestions. Apache Lucene is a potential technology which this search engine will be based on.

• Snippet insertion mechanism.

                     Snippets in JFace language format will be inserted to the code with code context based changes.

Schedule

• 17 June – 23 June (1 week)

                      Defining snippet serializing template format and finalize high level architecture

• 24 June – 07 July (2 weeks)

                      Creating SnipMatch preference window

• 08 July – 28 July (3 weeks)

                      Implementing snippet search view

• 29 July - 18 August (3 weeks)

                      Implementing snippet search engine

• 19 August - 08 September (3 weeks)

                       Implementing code context adaptation of snippets (Snippet insertion mechanism)

• 09 September – 16 September (1 week)

                      Testing and finalizing

Expectations

             I am expecting a mentor who is accessible and responsive. As I do not have a vast knowledge about the technologies related to Eclipse plug-in development, I like if my mentor can introduce me new technologies when it is applicable. Then I can learn myself and use them properly.

References

[1]. Doug Wightman,Zi Ye,Joel Brandt, Roel Vertegaal “SnipMatch: Using Source Code Context to Enhance Snippet Retrieval and Parameterization” [Online] Available:http://joelbrandt.org/publications/wightman_uist2012_snipmatch.pdf
[2]. “Merge and improve SnipMatch into Eclipse Code Recommenders” [Online] Available:https://code.google.com/p/snipmatch/wiki/Merge_SnipMatch_into_Recommeners_project_proposal
[3]. “Google Summer of Code 2013 Ideas Eclipse Code Recommenders: Social Snippets” [Online] Available:http://wiki.eclipse.org/Google_Summer_of_Code_2013_Ideas#Eclipse_Code_Recommenders:_Social_Snippets
[4]. Bugzilla Comment 44 [Online] Available: https://bugs.eclipse.org/bugs/show_bug.cgi?id=401771#c44
[5]. Bugzilla Bug 401771 - [gsoc] Social Snippets [Online] Available: https://bugs.eclipse.org/bugs/show_bug.cgi?id=401771

GSOC Proposal: Workspace Local Code Snippet Suggestions

Today I welcome Kavith Thiranga Lokuhewage who submitted an GSOC proposal about finding code snippets for your task at hand. Find out how... Best, Marcel

---

Google Summer of Code 2013 Eclipse Code Recommenders - Workspace Local Code Snippet Suggestions  - Kavith Thiranga Lokuhewage    Short description: A plugin for the Eclipse IDE which can search the entire workspace to find out code snippets, which are similar to the context that the developer is currently involved in. The plugin will suggest a list of code snippets from existing source code to the developer in a short amount of time, so that he/she will be able to have a quick look around the list and decide which results are worth a closer look to understand more about the framework/API usage.

Problem background

Today almost every software is built using existing frameworks/APIs. Most of framework libraries often provide a large number of classes and methods. Furthermore, libraries provided by different companies and different organizations follow different styles. Hence it’s always been a burden for the developers to learn new APIs for each new project that they work with. It’s a fact that the best documentation for a framework is the existing code itself. When working with new projects, the developers sometimes get stuck with a particular piece of code and even though they are certain that the other developers might have faced (and solved) the same problem previously, it is really hard to traverse through the entire source code to find out relevant pieces of code.

Full text search over source code isn’t really helping in these kind of situations as the target is to find out code snippets which have a particular set of structural characteristics. For an example a developer may need to search for a code snippet in which an object of particular data type (or several objects) is used and a particular method (or several methods) is called on that object.

A brief description about the Solution

By building an IDE extension which helps developers to easily find out code snippets which are in similar context in which the developer is currently involved in, it is able to increase the framework learning speed of the developer. Since full text search is not enough, the search engine should be able to capture the structural information of source code.

Furthermore it has to be fast enough to provide a comfortable experience to the developer. There should also be a good scoring system for the results so that the most important snippets come up in the list.

A brief description about available Code Search tools for Eclipse IDE

As discussed by (Böhm, 2012) , there are few tools available for Eclipse IDE which provide structural information based search over source code, namely Strathcona, Java Tools Language, Java Development Tools, JQuery ( not the JavaScript Library ) and CodeGenie. With all of them excluding Strathcona, developer has to manually query for data types, method signatures, etc. Some of them have disadvantages such as index is not updated frequently, index is hosted online and someone has to manually update the index, etc.

Considering the information being captured and the options been given for the search, JDT provides excellent tools for java source code searching. Its search index is saved on client side and updating the index happens upon saving a file. Below table represents the information captured by JDT Search Index. Source: (Böhm, 2012)

Type	Method	Field
Name Modifiers Implemented Types Declaring Type Type Arguments Extended Types Annotations Fields written Fields read Used Types Used Methods	Name Modifiers Declaring Type Return Type Parameter Types Checked Exception Types Annotations Fields written Fields read Used Types Used Methods	Name Modifiers Declaring Type Type

 

Advantages of using the proposed solution over available tools

The proposed solution will use an indexed storage on client side as same as JDT hence getting results will be fast. Comparing to JDT indexing, the proposed search engine will be able to capture a lot more structural information of source code such as Try/catch blocs, variable usage, etc. (Please refer to the topic “Prototype Implementation” to view a full list of information being captured).

The proposed solution will detect developer’s current context automatically and provide a list of similar code snippets in a condensed snippet form. So the search query will be created automatically rather than requiring the developer to manually execute the queries. This a similar kind of approach as used in Strathcona, but comparing to the information captured by Strathcona, this plugin is far ahead.

Project Description

The objective of the project is to implement a plugin for the Eclipse IDE, which will suggest existing source code snippets to the developer depending on the context in which the developer is involved in.

Scope

Since the way of capturing structural information differs from language to language, this plugin will only target the projects which are built using Java language. Furthermore it will provide example code snippets only from the existing source code which is available in local workspace. Hence it will be more suitable for projects which already have enough amount of existing source code.

Features

The users will be able to enable the plugin for a particular project via the IDE preferences window so that it is able to enable the indexing of source code on demand, preventing unnecessary performance issues. The preference window will also provide additional options for the plugin.

The users will be able to get a list of suggested code snippets in a condensed snippet form so that they can quickly decide which snippets are worth a closer look. By clicking on a result, users will be able to open the source code file which contains the relevant code snippet, in a new editor view.

Prototype search engine Implementation

Please refer to this git repository of the prototype implementation. A prototype of a code search engine has already been developed as a Master's thesis by Tobias Böhm. It is implemented using Apache Lucene. His project’s main objective was to allow developers to execute search queries by using a query language called Lucene QL which is built upon Lucene Query Syntax.

The indexing mechanism implemented in the prototype is outstanding. This prototype is able to capture a large amount of structural information under five main entities data type, method, field, tryCatch block and Variable Usage. Below list is a full set of structural information captured by indexers of prototype implementation. Source: (Böhm, 2012)

Type	Method	Field	Try Catch
Type Handle FriendlyName AllDeclaredMethodNames DeclaredMethodNames DeclaredFieldNames AllDeclaredFieldNames FullText FieldsRead Annotations FullyQualifiedName ImplementedTypes ExtendedTypes UsedTypes InstanceofTypes AllImplementedTypes AllExtendedTypes DeclaredFieldTypes UsedMethods OverriddenMethods DeclaredMethods ResourcePath Timestamp Modifiers ProjectName	Type Handle FriendlyName ReturnVariableExpressions DeclaredFieldNames AllDeclaredFieldNames FullText FieldsRead FieldsWritten ParameterTypesStructural Annotations FullyQualifiedName UsedTypes ParameterTypes ReturnType InstanceofTypes DeclaredFieldTypes DeclaringType CheckedExceptions UsedMethods ResourcePath ParameterCount Timestamp Modifiers ProjectName	Type Handle FriendlyName FullText FullyQualifiedName UsedTypes FieldType DeclaringType ResourcePath Timestamp Modifiers ProjectName	Type DeclaredFieldNames AllDeclaredFieldNames FullText FieldsRead FieldsWritten UsedFieldsInFinally UsedFieldsInTry FullyQualifiedName UsedTypes UsedTypesInTry UsedTypesInFinally InstanceofTypes CaughtType DeclaredFieldTypes DeclaringType UsedMethods UsedMethodsInTry UsedMethodsInFinally ResourcePath Timestamp ProjectName
		Variable usage
		Type Handle VariableName VariableType DeclaringMethod UsedAsParameterInMethods UsedAsTargetForMethods VariableDefinition

There’s also an extdoc provider named local code samples implemented using this search engine prototype. The local code samples extdoc provider is currently able to provide code snippets suggestions depending on variable type and called methods.

For an example, when a developer selects a variable name or a method call in the editor, list of code snippets in which a similar type of variable/ similar method call is used, will be displayed in the extdoc provider view given that the indexing of code base is completed.

Implementation of proposed solution

The prototype is using Apache Lucene to implement the search engine. Since Lucene is using an Inverted Index for the index storage, even though insertion may take some time, querying will be pretty much fast. Since viewing a list of condensed code snippets should be done in a short amount of time, it suits best for the local code search plugin.
Considering the fact that the above mentioned search engine does a great job with indexing and there is a good amount of code which is worth to keep, it make sense to improve the search engine and use it for the local code search plugin rather than building a search engine from the scratch.

Targetting Deliverables for GSOC

As mentioned by Marcel (refer to this comment) the searcher and indexer do not work together very well. Sometimes accessing the search index fails. This need to be looked in deeper and fixed since it is the heart of everything. This will be a main task of the project.

The implemented extdoc provider already triggers search and displays results when a filed name or method call is selected. The extdoc provider can be extended to trigger search upon selection of many more structral elements in the editor. Search can be triggered upon selecting,

1. Data Types (upon selecting Extended, Implemented or Declared Types)
2. Return Types (find methods which returns similar types)
3. Overidden Methods
4. Annotations
5. Checked Exceptions

The representation of code snippet results in condensed form need improvements. Currently it only displays a simple code summery of each snippet. A screen shot of a result list is shown below.

This can be improved to provide more expressive summary so that the developers will be able to quickly decide which snippets are worth looking at. Below is a list of things which can be added to summary view so that it will be more expressive.

1. Containing Package
2. The Class name/ Method Name
3. Whether it is a abstract class/ Interface
4. Whether it is a abstract method/ overriden Method, overloads available, etc
5. May be diplay two or three surrounding code lines in muted text

Further possible improvements to prototype

Please refer to the bugzilla issue for more information.

As discussed by Tobias, there are several improvements which can be done for the indexing.

• Structural information such as Class Castings and thrown exceptions are not captured by current indexers.
• Improvements also can be done to indexing variable usage as currently it only captures information of variables which are declared inside the same block where it is used.

For an example, if a variable is declared as a class variable and used inside a method, usage of variable isn’t considered when the method is being indexed.

• The current implementation doesn’t provide a custom ranking mechanism for search results.
  

  Scoring is all left to default Lucene scoring which uses a Vector Space Model (VSM). It is possible to affect default scoring of Lucene by implementing our own query classes. This will help to receive a search result in which the most relevant code snippets are on top of the list.

These improvements needs further discussions, specially implementing a scoring system. Some of these improvements may be achieved during the GSOC if time permits.

GSOC Proposal: Usage Data Collection for Code Completion

Hey all. As you probably all know, this is the Code Recommenders project blog we typically use to announce new features, releases or other noteworthy topics related to Code Recommenders. This blog post series will be a bit different: In this series we will have a set of (wannabe) GSOC students presenting their projet proposals to the Eclipse Community in the large to get your feedback. If you like these ideas please post your ideas and comments here. Students would be glad to hear what you think!
Best,
Marcel

_______________________________________________________________________________

Hello,


my name is Timur and I want to participate this year on Google summer of code 2013 (GSoC) extend the Eclipse Code Recommenders project by a specific dialog, which shows user specific statistics how they use the Eclipse code completion. This data will be graphical presented in an own dialog. Eclipse developers thus have the possibility to see how effectively they work every day with their IDE. 


Project Description

Do you know how much time code completion saves you per day? No? Well, this proposal should address that by (locally) collecting usage data that can answer this and more sophisticated questions. Moreover, the collected data can then be used to make recommendations on the most effective use of your IDE, e.g., recommending a keyboard shortcut that you don't use (and presumably don't even know about).

With this project various metrics could be created, which provide the developer interesting facts about his work. For example, we could show how many keystrokes are saved from a developer through the code completion engine that would have to type manually without this engine. With this additional data we could also evaluate the developer activity. On which days/weeks is the developer more productive and show this interesting information in a chart (or block diagram). So we can see which days/weeks are the real working days/weeks and the other one. This stats center could extend through other Eclipse data, like the Eclipse shortcuts and something else. The following data we could show about the using of the code completion engine in a specific dialog:

• Number of times code completion triggered, concluded and aborted 
• Number of saved keystrokes by using the code completion 
• Types on which the code completion was used (fields, local variables etc.) 
• In which classes code completion was used 
• How much time code completion saves

Mockup

The dialog for this additional information could be split in several tabs. The first tab contains all metric data about the use with code completion. The next tab “Charts” could contain a few graphical analyses about the use of the code completion engine based on days or weeks. The “Conclusion” tab contains some summarized data about the developer himself and some suggestions how developer could be more productive with the Eclipse IDE. For this use case we could analyse in the background the used Eclipse shortcuts. With this data we know, which shortcuts are often used and which one are not used. With this information we could suggest which other common shortcuts are used by another proficient developers. This could help some Eclipse newbies, because they can learn very fast, which is the common way to develop productive software. But also real Eclipse experts will hopefully give some good tips.

Deliverables

In the final stage, of course, the implemented plugins should have been tested and checked out for their functionality (through the mentor). For this project I have planed the following milestones:

• Milestone 1 (25. May): 
• Create UI Mockup with the community
• Study the documentation and the code base 
• Milestone 2 (20. June):
• Integrate various metrics and implement the infrastructure for this project
• Pimp the dialog, e.g. with ui.forms and some cool icons etc. 
• Milestone 3 (15. July): 
• Integrate the charts and conclusion tabs in the dialog 
• Milestone 4 (10. August):
• Create tests for this project, if possible I will do this parallel 
• Maintain the wiki and document the new created code 

Public Checkpoints

• Checkpoint 1 (31. May):
• Announce the UI Mockup in a blog post or Wiki 
• Checkpoint 2 (30. June):
• Announce the dialog with the first tab (contains metrics) 
• Checkpoint 3 (31. July):
• Announce the chart and conclusion tab 

Tech-Spec

Here are some tools or frameworks are listed, which I would to use:

• Attractive look & feel in the dialog
• SWT, JFace und UI.Forms 
• Persist user data 
• JSON: persist the java objects on the file system
• Plugin: com.google.gson.Gson 
• Create charts
• JFreeChart (Open Source under LGPL)
• http://www.jfree.org/jfreechart/ 
• Tests
• JUnit, JUnit Plugin Tests and SWTBot tests 

Code Recommenders in the latest Oracle Java Magazine

This is fantastic news: There is a short article about Code Recommenders in the latest Oracle Java Magazine in the section "Java Nation". Get your copy soon.

[ctrl]+space means [ctrl]flow... - Mine your own APIs

After months of hard work, we are happy to announce that Codetrails has released it's developer preview of the [ctrl]flow mining server - just in time for EclipseCon 2013 in Boston. With [ctrl]flow you now can easily add the well known Code Recommenders support (intelligent call completion and overrides completion, dynamic templates, and various addons to API documentation) to your own APIs:

The [ctrl]flow Server download also contains a tutorial about how you can generate models for JavaFX in less than 5 minutes. If you like what you see, it would be great if you try the mining engine on your own repository and give us your feedback. If you'd like to work together with us on a special context, contact us.  Meantime, thanks for trying [ctrl]flow!

Best,
Marcel

P.S.: If you haven't taken the Code Recommenders "Family Developer Feud" Challenge, drop by the Recommenders Table and get your chance to win a Amazon Gift Certificate! But only today!