[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [recommenders-dev] [GSOC 2013] SnipEditor Weekly Report

Hi Stefan,

On Sep 8, 2013, at 5:49 PM, stefan.prisca@xxxxxxxxx wrote:

>sounds promising. I added the snippets I used to Gerrit: https://git.eclipse.org/r/#/c/16206/ Can >you check out this change-set and see if you can parse these snippets properly?
There are some problems here.
Some of this snippets use swt elements. In order to support this, swt should be on the build-path of the project, and at the moment only the standard java build path is added to the project. I could simply add it in the path when the project is created, but I was thinking to implement some sort of build path set-up mechanism in the snipmatch preference page where the user will set the jars available on the buildpath for the External Snippets project. Something similar to the dependencies section from MANIFEST.MF.

Okay. for now it would be okay to manually edit the project's classpath manually. I added this item to the backlog for later.
I also had issues with the classpath being set properly. Maybe we can fix this this week with a higher priority?

 There are some other issues as well of which I will try to take care this week.

If you can name then, can you please add them to the planning document?

 I managed to separate the project in the o.e.r.snipmatch.rcp and o.e.r.templates.rcp modules.
The contents are the following:
    • o.e.r.snipmatch.rcp contains the snipmatch plug-in elements (preference page, multi page editor, etc).
    • o.e.r.templates.rcp contains the Xtext grammar core elements(compiler, type computer, formatter, the grammar itself etc). This also contains an out-of-the-box editor for .cSnip files.
This can be found here[1]. A Readme will be available soon ð

Sounds good. The naming for the templates projects still looks a bit weird though. It should be o.e.r.templates (for the headless) and o.e.r.templates.rcp (what's o.e.r.templates.rcp.ui at the moment). We also changed the naming conventions for feature a p2 repos in 2.0 a bit: E.g."feature" should be a suffix rather then an infix to name. These things we can fix later.

Let's wait until we get Madhuranga's changes IP checked. Then, we can add your code to the repository and work on the proper naming.

Regarding support for ${cursor}:
Does it make sense to map this statement to any type at all? To me it looks like that this statement (like ${line_selection} and others) should not have any code completion. They should simply be ignored IMHO.


The update site [2] contains only the o.e.r.snipmatch.rcp plugin installable unit, which means that only the multi-page editor and its requirements from the templates.rcp will be installed.
Best Regards,
From: Marcel Bruch
Sent: âSundayâ, âSeptemberâ â8â, â2013 â2â:â06â âAM
To: Recommenders developer discussions
Hi Stefan,

sounds promising. I added the snippets I used to Gerrit: https://git.eclipse.org/r/#/c/16206/ Can you check out this change-set and see if you can parse these snippets properly?

Note that the snippet format changed a bit: You may consider using /snipmatch-org.eclipse.recommenders.snipmatch.rcp/src/org/eclipse/recommenders/snipmatch/Snippet.java for deserializing the snippets instead of using the old Effect class.


On Sep 7, 2013, at 10:06 PM, stefan.prisca@xxxxxxxxx wrote:

This is the weekly report for the snipeditor:
What was planned:
-> implement type computation for the other template variables and continue implementing the remaining syntax
-> add functionality to the metadata page of the snipeditor (allow user to edit the fields)
-> test the syntax with java templates to ensure it works.
What was accomplished:
->all of the syntax is supported; The expressions can be found here [1].
-> most of these expressions should be resolved to the correct type. There still are some that do not work properly in certain situations, e.g.  ${cursor} is only treated as an object, so the following will produce an "Unable to cast Object to boolean" error : if(${cursor}){}.  I tried to set the type to void but in this case the error would change to "Unable to cast Void to boolean".
-> Iâve added a small (nasty looking) pop-up that allows the search phrases to be edited and the types used in the snippet are available. Note that at the moment it displays all types that were computed (including the code snippet itself) and sometimes does not work.  The interface can be seen here [2].
What the plan for the next week is:
-> try to compute types for elements like ${cursor} based on the context. e.g.: for the _expression_ if(${cursor}){}, ${cursor} should be treated as a Boolean.
-> try to add content assist to jFace variables like ${array}.
-> make the type section of the metadata page work properly and set up a nicer dialog to edit the fields in search patterns.
Best Regards,
recommenders-dev mailing list

recommenders-dev mailing list