[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [recommenders-dev] [SnipMatch] New search result display module trial version is finished

Consider this case: the user types "move file at str1 to folder str2" into the search box (where str1 and str2 are the names of local variables). SnipMatch can identify that this search query matches the pattern: "move file at $filePathString to folder $dirPathString". 

First, a lookup is performed to locate patterns that are similar (matching on individual tokens). Then, these results are filtered into two groups: patterns that are "in-order" with respect to the search query and those that aren't (e.g. if the search query was "file move str1", the pattern would be out of order, and should thus appear below all the in-order patterns in the result listing).

Next, we remove in-order patterns when the expected parameters types don't match with the arguments (e.g. str1 and str2). This is important because there could be another pattern that is exactly identical except handles a different type (and also as a method of validation, giving the programmer confidence that the snippet will work). In order to perform this step, we need to retrieve the expected parameter types. "params" helps with this - otherwise, we would need to frequently extract the types from "code" within the json (for every pattern that might match a search query, every time the user types a letter).

However, this isn't necessarily a good reason for params to be implemented as they are. If this was the only reason for this approach, we could instead generate params from the snippet code when the snippet is created (rather than having them be specified with a separate ui).

I think there were two additional reasons for this approach, and I think it's ok to sacrifice them: (1) we were concerned that many potential snippet creators wouldn't know off-hand how to specify types (e.g. java.lang.String - and this is an easy one) - we figured a dropbox and/or suggestions, would be easier for users, and (2) we weren't certain that the JFace types would be sufficient for our purposes. In practice, I think JFace was sufficient, but I may be forgetting something - I'll check with Zi and get back to you.

In summary: I think we'll still want params, for efficiency purposes, but we can generate them from the snippet code when the snippet is created. If it's important to conform with JFace, I'm ok with using "${filePathString:var(java.lang.String)}" so long as any default can be overridden when an argument is specified in the search query (i.e. str1).


Doug



On Thu, Apr 12, 2012 at 5:16 AM, Marcel Bruch <marcel.bruch@xxxxxxxxx> wrote:
Hi Cheng,

I had a closer look at the templates and I wonder whether we couldn't change them a little bit to make them conform to real JFace templates.

 Example common14.json looks as follows:

{
  "patterns": [
    "move file at $filePathString to folder $dirPathString",
    "move file at $filePathString to directory $dirPathString"
  ],
  "params": [
    {
      "name": "filePathString",
      "majorType": "expr",
      "minorType": "String"
    },
    {
      "name": "dirPathString",
      "majorType": "expr",
      "minorType": "String"
    }
  ],
  "envName": "javasnippet",
  "majorType": "stmt",
  "minorType": "",
  "code": "${import(java.io.File)}\r\n\r\nFile ${file:freeName(file)} \u003d new File(${filePathString});\r\n${file}.renameTo(new File(${dirPathString} + File.separator + ${file}.getName()));",
  "summary": "Move the file at a string path to a directory string path.",
  "id": ""
}

Can't we get rid of the params section when using the jface templates completely? For instance using a snippet such as follows (untested braindump)


${import(java.io.File)} File ${file:newName(java.io.File)} = new File(${filePathString:var(java.lang.String)}); ${file}.renameTo(new File(${dirPathString:var(java.lang.String)+ File.separator + ${file}.getName()));

Or something similar? There might be a little more changes but if this works, we could get rid of the whole parameter section, right?


(I'd prefer this over tests ATM since there are only 15 templates so far ;))


On 12.04.2012, at 08:58, Chen Cheng wrote:

So, my following task is contributing unit test before GSoC starts (maybe fix some exist bugs), right?

2012/4/12 Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx>
Hi,
On 12.04.2012, at 07:35, Chen Cheng wrote:

Hi Marcel,

2012/4/12 Marcel Bruch <marcel.bruch@xxxxxxxxx>
Hi Chen,

You mentioned before, we should prepare a Snipmatch package before Eclipse Juno M2, so what will be focus on after search result display module before M2 ?

IMHO, focus should be:

Doug: check in snipmatch into code recommenders repository
Chen: convert code to the new structure

You mean change project name, re-factor packages etc?
For example, change project name from SnipMatchPlugin -> "org.eclipse.recommenders.snipmatch
Right?

I'm hoping this will be done by Doug? Doug. Maybe it makes sense to commit all the code to gerrit first and work on this patchset until it is in a good shape?

 
Chen: commit changes against gerrit. If possible create only patches smaller than 200 lines. if this is not possible create one large commit.

I am not very sure why we have to create patches smaller than 200 lines. This is Eclipse's rule? Anyway, i will follow this rule. 

all patches below 200 lines don't need an IP check by the Eclipse Legal Team. If it's larger we have a lengthy process to follow. If your initial commit is hard to split into several smaller ones create one large commit to gerrit.


 
Doug: initiate an IP check for that patch.
All: wait for IP check

In the meanwhile:
Integrate snipmatch into the build and write tests ;)

I will start contribute unit test code soon, but i want to know, is there any *special* rules towards unit-test bundles in Eclipse community?

Hard to say ;) You should have a look at the test bundles in our repository to get an idea.
Marcel

 

My time is unfortunately very limited until the 18th April. We apply for a large funding and have the final presentation round net week. After that I'll have a close look.

Marcel

On 11.04.2012, at 11:01, Chen Cheng wrote:

Hi all,

SnipMatch's new search result display module is finished, i built it similar with JDT's content assit, you can find the GUI in the attach picture file. You guys can have a trial of it, then i can improve it according to the feedbacks. Or if there are any advises, you can just post it here.

Marcel,
You mentioned before, we should prepare a Snipmatch package before Eclipse Juno M2, so what will be focus on after search result display module before M2 ?

--
Best Regards From Cheng Chen [chengchendoc@xxxxxxxxx]
<search_result_display.png>


_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev




--
Best Regards From Cheng Chen [chengchendoc@xxxxxxxxx]
_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev

Thanks,
Marcel



_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev




--
Best Regards From Cheng Chen [chengchendoc@xxxxxxxxx]
_______________________________________________
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