[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

Hi Marcel,

Doug & Zi Ye have supply a grammar parsing module for this *specific* template grammar, if we want to change it, there are at least two points to  notice:
1. We should re-write a paring module to parse the new template grammar, OR the new template is  jface templates, there are already some existing tools can help us.
2. Why did Doug & Zi design the grammar like this? There must be some reasons, we should hear what Doug say first.

AND what can we benefit from this change? If we have enough time, we can re-factor anything, but if we want to finish certain amount of work in specific time period, we should think about priority. 

I do not oppose any IMPROVEMENT change, just concern time plan :-)

2012/4/12 Marcel Bruch <marcel.bruch@xxxxxxxxx>
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




--
Best Regards From Cheng Chen [chengchendoc@xxxxxxxxx]