On Fri, Mar 23, 2012 at 12:37 PM, Chen Cheng <
chengchendoc@xxxxxxxxx> wrote:
> My opinion comment below:
>
>
> 2012/3/23 Marcel Bruch <
bruch@xxxxxxxxxxxxxxxxxx>
>>
>> I think, we need to split and distribute the workload for the critical
>> tasks.
>>
>> From my end, it looks as follows:
>>
>> Chen can work on SnipMatch "full" time from July. Before that date he
>> shouldn't do any work on the (very) critical path.
>> The completion frontend/ui _is_ a critical thing to me.
>>
>> Things like repository upload, template editing, git support etc. isn't
>> required for M7 and might even not be needed for Juno at all (although we
>> all would love to see it in), and thus, it all boils down to a few things:
>>
>> * be able to download a zip from a repository, unpack, and index its
>> contents.
>> * do this whenever the zip file on the server side changes
>> * have an excellent completion popup with a table viewer with dynamic
>> contents and proposal previews as we know it from JDT
>> * use JDT's templates API to make it work 'smoothly', i.e, (re-) use JDT's
>> template proposals + preview popup etc.
>
>
> It is a pity that i am not very familiar with JDT's template proposals part,
> so i have no idea how long this part of job will cost. And this is the
> *critical* part of Snipmatch before M7, i can not promise finish it all by
> myself although i really want to. But i won't let it go, I will study JDT's
> template proposals + preview popup solution and then try to work together
> with you guys here.
>
>>
>>
>>
>> I think the completion popup is the most critical thing that will consume
>> _a lot_ of time. To give an estimation: I think it will need ~3 weeks full
>> time to do it and being sure it works afterwards :) Doug, since you know
>> your tool best, I think this task is best located in your hands. I can
>> assist you when it comes to details like highlighting in table viewers or
>> using lazy content providers etc. But in its core, you (an Zi) are the pros
>> here.
>
>
> Doug (and Zi), if you have detailed plan about this part, please let me
> know. I will try to keep up with your job, and hope i can coding together
> with you.
>
>>
>>
>>
>> I can also assist on the search interface and automated model download,
>> unzip, and index part. I actually planed the indexing part for mid of April.
>>
>> Chen can do lot's of ui improvements like preference pages, cleanups, and
>> start working on the "flexible repository modules" concept as warmup for the
>> GSOC. I think there is much to do but we shouldn't rely on him doing the
>> critical work until M7 :)
>
>
> No problem for me here, i have been working with SnipMatch's source code for
> so long, i can promise finish this part of job before M7.
>
>
>>
>>
>>
>> After all, I think it depends on how much time we can invest into this
>> until M7. I'm heavily involved in the completion and code search projects.
>> Johannes and Sebastian are working on the mining approaches. The other
>> students have their separate projects (codesearch, annotation mining,
>> multi-object pattern mining etc.) and cannot assist. Doug, honestly I think
>> it's time you check in the code and start working on it to make Snipmatch
>> happen ;)
>>
>>
>> FWIW, I agree with all your UI constraints below.
>>
>>
>> On 23.03.2012, at 15:20, Doug Wightman wrote:
>>
>> > I agree that we absolutely need downloading and indexing of
>> > repositories.
>> >
>> > In terms of displaying and inserting code snippets, reusing existing
>> > (stable) code sounds good. However, I want to ensure that we won't
>> > lose the following features:
>> > -you still search in a search box, and you can include arguments (e.g.
>> > local variables) in the search query. Note: with templates, these
>> > arguments would then be used to pre-fill the templates.
>> > -the result listing updates as you type
>> >
>> > So long as we retain these two features, these changes make sense to
>> > me. If either is at risk, let's explicitly discuss.
>> >
>> > Given the timeframe, it might make the most sense to build each of
>> > these changes (repository integration + new display system) in the
>> > next 6 weeks: splitting the time between the two of them, then
>> > polishing afterwards. But Marcel is in a much better position to judge
>> > timeline and priorities. I really appreciate your feedback - it's
>> > critical that we have a strong offering for M7.
>> >
>> > I also want to hear from Chen: is this reasonable for you? Is there
>> > anything that you think we need to cut?
>> >
>> >
>> > Doug
>> >
>> >
>> >
>> >
>> > On Fri, Mar 23, 2012 at 8:27 AM, Chen Cheng <
chengchendoc@xxxxxxxxx>
>> > wrote:
>> >> The only problem is the time, if we change display module now, we have
>> >> too
>> >> much things to do, we should decide the priority
>> >>
>> >>
>> >> 2012/3/23 Marcel Bruch <
bruch@xxxxxxxxxxxxxxxxxx>
>> >>>
>> >>>
>> >>> On 23.03.2012, at 11:49, Chen Cheng wrote:
>> >>>
>> >>> It seems that time is really emergency for us. About the two features:
>> >>>
>> >>> * downloading and indexing a local repository
>> >>>
>> >>> You mean current local search module, add EGit module to download
>> >>> snippet
>> >>> files from remote repository automatic. And with some preference
>> >>> pages,
>> >>> right ?
>> >>>
>> >>>
>> >>> Exactly.
>> >>>
>> >>>
>> >>> * code completion engine based on Eclipse standard features like
>> >>> templates
>> >>> and Linking mode
>> >>>
>> >>> You mean abandoned current match result display module, change to
>> >>> Eclipse
>> >>> standard features. I am not very clear what your words "templates and
>> >>> Linking mode" mean, but i think the new search result display will
>> >>> looks
>> >>> like Java Class Editor's content assist(see attach file assist.png),
>> >>> right ?
>> >>>
>> >>>
>> >>> Yes. I'm proposing to reuse JDT's template framework for now. With
>> >>> linking
>> >>> mode I refer to "the placeholders can be navigated by tab" feature of
>> >>> JDT's
>> >>> templates . It also offers functionality like guessing arguments for
>> >>> template variables.
>> >>>
>> >>>
>> >>> Anyway, current match result display module works, but i don't think
>> >>> it is
>> >>> a long term solution, if you mean change it. I agree.
>> >>>
>> >>>
>> >>> Standing by for Doug's opinion. Must be 6AM in Canada ;)
>> >>>
>> >>> Thanks
>> >>> Marcel
>> >>>
>> >>>
>> >>>
>> >>> 2012/3/23 Marcel Bruch <
marcel.bruch@xxxxxxxxx>
>> >>>>
>> >>>> Hi Chen,
>> >>>>
>> >>>> this fix looks good to me and is good to go for EclipseCon demo.
>> >>>> Thanks a
>> >>>> lot.
>> >>>>
>> >>>>
>> >>>> I'd like to initiate a discussion about how the whole template code
>> >>>> insertion & display mechanism should look like for Juno - and discuss
>> >>>> the
>> >>>> important milestones.
>> >>>>
>> >>>> M6 is today. M7 is in 6 weeks and then projects do a feature freeze,
>> >>>> i.e., all the time is put into testing, bug fixing and small
>> >>>> improvements.
>> >>>> Projects like JDT or RAP have feature freeze since M6 already. I'm a
>> >>>> bit
>> >>>> concerned that we'll run out of time to deliver a stable version of
>> >>>> snipmatch. Doug, Zi, Cheng, how do you think about that?
>> >>>>
>> >>>> I'd propose to focus on just a few features and make them as stable
>> >>>> as
>> >>>> possible for Juno.
>> >>>>
>> >>>> Features could include:
>> >>>> * downloading and indexing a local repository
>> >>>> * code completion engine based on Eclipse standard features like
>> >>>> templates and Linking mode
>> >>>>
>> >>>> Although I love the "insert directly in code" and the custom popup
>> >>>> feature very much, I think, they are not stable and fast enough yet.
>> >>>> I'm
>> >>>> concerned that the success of Snipmatch depends on usability and that
>> >>>> it
>> >>>> will be hard to convince package owners to include it. I'll talk to
>> >>>> some
>> >>>> package maintainers at EclipseCon to learn about their requirements
>> >>>> but
>> >>>> before that I'd like to know your opinions on this.
>> >>>>
>> >>>> Thanks,
>> >>>> Marcel
>> >>>>
>> >>>>
>> >>>>
>> >>>> On 23.03.2012, at 03:25, Chen Cheng wrote:
>> >>>>
>> >>>> Hi Marcel,
>> >>>>
>> >>>> I have fixed this issue, the popup window will not cover the inserted
>> >>>> code anymore, and submit source code already.
>> >>>>
>> >>>> About the other issue "Is it possible to run the code without
>> >>>> revealing
>> >>>> the active editing position?", my current answer is NO, it seems that
>> >>>> the
>> >>>> "scrolls" job was done by editor itself, we can not fix it easily
>> >>>> now. But i
>> >>>> will add this into my TODO list and find solution in the future, in
>> >>>> fact, we
>> >>>> have plan to improve the whole search result display canvas.
>> >>>>
>> >>>> 2012/3/22 Marcel Bruch <
bruch@xxxxxxxxxxxxxxxxxx>
>> >>>>>
>> >>>>> Hi Chen,
>> >>>>>
>> >>>>> I experienced a serious issue for the snipmatch demo:
>> >>>>>
>> >>>>> When I trigger completion at an empty location, enter "file", wait
>> >>>>> for
>> >>>>> proposals and then scroll trough the proposals the popup window
>> >>>>> completely
>> >>>>> covers the inserted code. With that behavior, we can't see the code
>> >>>>> that
>> >>>>> gets inserted by snipmatch.
>> >>>>>
>> >>>>> Can you reproduce that? What can we do with this?
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> Thanks,
>> >>>>> Marcel
>> >>>>>
>> >>>>> --
>> >>>>> Eclipse Code Recommenders:
>> >>>>> w
www.eclipse.org/recommenders
>> >>>>> tw
www.twitter.com/marcelbruch
>> >>>>> g+
www.gplus.to/marcelbruch
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> 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]
>> >>> <assist.png>_______________________________________________
>> >>>
>> >>> recommenders-dev mailing list
>> >>>
recommenders-dev@xxxxxxxxxxx
>> >>>
http://dev.eclipse.org/mailman/listinfo/recommenders-dev
>> >>>
>> >>>
>> >>> Thanks,
>> >>> Marcel
>> >>>
>> >>> --
>> >>> Eclipse Code Recommenders:
>> >>> w
www.eclipse.org/recommenders
>> >>> tw
www.twitter.com/marcelbruch
>> >>> g+
www.gplus.to/marcelbruch
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> 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
>>
>> Thanks,
>> Marcel
>>
>> --
>> Eclipse Code Recommenders:
>> w
www.eclipse.org/recommenders
>> tw
www.twitter.com/marcelbruch
>> g+
www.gplus.to/marcelbruch
>>
>> _______________________________________________
>> 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
