an attempt at a roadmap
iulian dragos
We had lots of good things happening during the past few months, and
the Scala IDE for Eclipse is getting better and better by the day.
Sure, it may not be yet at the level of Java tools, but remember that
success does not come suddenly (though it may appear so). Instead,
it's a collection of small steps. So that's why I put together a few
steps that I see as important for the next few months in our journey
towards a great IDE for Scala. This is not set in stone, it's a
starting point for discussion. In the end, I wanted all to have a
better picture of what is ahead, what needs to be done, and how we can
achieve it.
First step is going out of 'beta', and have a...
2.0 version: 1st week of September (optimistic)
==================================
To get there, there are a couple of blockers, or maybe we should call
them 'hurdles' ;)
- We really need to get a (more) reliable build, with good dependency
between projects. SBT builder (Hubert): currently in a branch, needs
to be merged in, so we can try out the nightlies
- Bugfixing (32 open tickets).:
- many bugs at the integration layer between JDT and Scala. We can't
fix all of them, but we need to prioritize and go for the real
'blockers'.
- UI bugs/indentation. It would be great to integrate indenting with
the excellent formatting based on scalariform (something Matt
suggested a while ago).
- presentation compiler bugs: completion unreliable for certain
common patterns - Mirco (Dotta) is working on it and I think we'll
soon have a very pleasant surprise
- builder bugs (7 open tickets), most probably obsolete but may be
replaced by new bugs against the SBT builder
- weaving related: integration with other plugins (maven, GWT, WTP).
This is sort of an open problem, and could really use help from people
who know more about these plugins
- scope completion using all types in the classpath (can be done
based on the Java search engine) -- probably a 'low hanging fruit'
- Scaladoc integration with completion and hovering (this would be
great to have, almost there, needs some finishing touches from Daniel)
Once we have a stable release, we can concentrate on a 'feature'
release. The following features are in no particular order, and a bit
too vague to know exactly how long they will take.
2.1: sometime in November
====================
- REPL Scratchpad -- Martin added support in the presentation compiler
for a 'worksheet' like interpreter. We should see how to integrate
that in Eclipse
- Reliable Find references. Integrate the search engine in JDT.
- Better/More Refactorings. Mirko's scala-refactoring
- better completions (relevance, sort and filter by expected type,
etc) -- here we'd probably need help from the compiler
- Scala debugger -- concentrated effort both on the scala compiler
side, and the IDE -- long-running effort
- Scala API for tool developers - we need better abstractions that
compiler internal Symbols and Types. More documentation.
What do you think? What is a real blocker for you, what would you like
to see next?
thanks,
iulian
--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais
Mirco Dotta
> presentation compiler bugs: completion unreliable for certain
> common patterns - Mirco (Dotta) is working on it and I think we'll
> soon have a very pleasant surprise
I just committed so that people interested can give it a try after tonight build.
Cheers,
Mirco
Grzegorz Kossakowski
Dear all,
We had lots of good things happening during the past few months, and
the Scala IDE for Eclipse is getting better and better by the day.
Sure, it may not be yet at the level of Java tools, but remember that
success does not come suddenly (though it may appear so). Instead,
it's a collection of small steps. So that's why I put together a few
steps that I see as important for the next few months in our journey
towards a great IDE for Scala. This is not set in stone, it's a
starting point for discussion. In the end, I wanted all to have a
better picture of what is ahead, what needs to be done, and how we can
achieve it.
What do you think? What is a real blocker for you, what would you like
to see next?
--
Grzegorz Kossakowski
Mirko Stocker
On Friday 15 July 2011 15:06:39 iulian dragos wrote:
> What do you think? What is a real blocker for you, what would you like
> to see next?
There's one thing I miss on the roadmap: highlighting of implicits! A few
months back I created a "reconciliationParticipants" extension point in the
wip_exp_backport branch and used it to hook up Jin's highlighting of
implicits. If you want, I could port this to wip_experiment. Or do we want to
wait for 2.1?
Cheers,
Mirko
--
Mirko Stocker | m...@misto.ch
Work: http://ifs.hsr.ch | http://infoq.com
Personal: http://misto.ch | http://twitter.com/m_st
Grzegorz Kossakowski
Hi,
There's one thing I miss on the roadmap: highlighting of implicits! A few
On Friday 15 July 2011 15:06:39 iulian dragos wrote:
> What do you think? What is a real blocker for you, what would you like
> to see next?
months back I created a "reconciliationParticipants" extension point in the
wip_exp_backport branch and used it to hook up Jin's highlighting of
implicits. If you want, I could port this to wip_experiment. Or do we want to
wait for 2.1?
--
Grzegorz Kossakowski
David Bernard
Mirco Dotta
Thanks for offering to port "highlighting implicit" in wip_experiment.
I have a couple of questions about this feature, as I'm not familiar with what
was implemented in the wip_exp_backport branch.
(1) Does this new feature has to use the presentation compiler to
be working? If the answer is yes, then I think that the merge
should be done on a new branch so that Martin, Iulian or me could
review the code. This because the communication protocol with the
presentation compiler is currently too "open", and it's easy to affect
the stability of the IDE if used improperly (e.g., completion was not
working reliably before beta09 simply because a call to
`compiler.askType` was performed inside a `compiler.askOption` :)
(2) How much time do you estimate is necessary to carry out the port?
If it is not going to take long, and you are interested in seeing this
feature now, go ahead. Though, it is true that there are some bugs
in the refactoring side that it would be good to fix. On the top of my
head, renaming is the one that would really need some work (I know
there has been a code rollback at some point...).
What do you think?
Cheers,
Mirco
Mirco Dotta
Mirko Stocker
On Friday 22 July 2011 14:00:05 Mirco Dotta wrote:
> (1) Does this new feature has to use the presentation compiler to
> be working? If the answer is yes, then I think that the merge
> should be done on a new branch so that Martin, Iulian or me could review
> the code. This because the communication protocol with the presentation
> compiler is currently too "open", and it's easy to affect the stability of
> the IDE if used improperly (e.g., completion was not working reliably
> before beta09 simply because a call to `compiler.askType` was performed
> inside a `compiler.askOption`
Yes it does; it traverses the AST looking for ApplyImplicitView and
ApplyToImplicitArgs. Nothing fancy really, but I agree that it would be good
if someone reviewed the code. That reminds me, has anyone tried Assembla's
Gerrit support?
> (2) How much time do you estimate is necessary to carry out the
> port? If it is not going to take long, and you are interested in seeing
> this feature now, go ahead.
I'd say maybe 2-3 hours. I think it's a nice feature, and it could be used to
calm down all those who are sooo afraid of this complicated language feature
:-) But it could just as well wait for 2.1, I don't have a problem with that.
Let me do it in a branch and then we can see whether we want to merge it for
2.0 or 2.1, ok?
> Though, it is true that there are some bugs in
> the refactoring side that it would be good to fix. On the top of my head,
> renaming is the one that would really need some work (I know there has been
> a code rollback at some point...).
> What do you think?
Yes, Iulian had to disable the rename participant of the rename resource
refactoring. The problem is that I don't think I could easily fix this, it's
simply horribly inefficient to load the complete project into the PC just to find
all occurrences of a name. So for me the "fix" is to wait until the JDT index
works for Scala elements :-)
Mirco Dotta
> Hi Mirco :-)
:)
> That reminds me, has anyone tried Assembla's
> Gerrit support?
I did not, but I think we should enable it and try it out. Anyone against?
>> (2) How much time do you estimate is necessary to carry out the
>> port? If it is not going to take long, and you are interested in seeing
>> this feature now, go ahead.
>
> I'd say maybe 2-3 hours. I think it's a nice feature, and it could be used to
> calm down all those who are sooo afraid of this complicated language feature
I definitely think it is a super-useful feature, top-3 after completion/hyperlinking/building.
So I'd definitely be super-happy to see it if we can easily port it.
> :-) But it could just as well wait for 2.1, I don't have a problem with that.
> Let me do it in a branch and then we can see whether we want to merge it for
> 2.0 or 2.1, ok?
I think it makes sense. Though, talk with David before doing the process as he mentioned
an issue with the current implementation.
> So for me the "fix" is to wait until the JDT index
> works for Scala elements :-)
Oh, I see. I wasn't aware of the full reason. Thanks for the update.
-- Mirco
Miles Sabin
> > That reminds me, has anyone tried Assembla's Gerrit support?
>
> I did not, but I think we should enable it and try it out. Anyone against?
Excellent idea ...
Cheers,
Miles
--
Miles Sabin
tel: +44 7813 944 528
gtalk: mi...@milessabin.com
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin
Mirco Dotta
Miles, can you and add the tool to assembla.
I wanted to do it myself, but I don't think I can.
Cheers,
Mirco
Miles Sabin
Hmm ... neither can I. It looks like it's only available for
non-Assembla git repositories.
Mirko Stocker
Can you tell me more about the bug (and the solution :-) ) you found in
implicit highlighting?
I've ported the code to wip_experiment and pushed it as a new branch:
http://www.assembla.com/code/scala-ide/git/nodes?rev=wip_experiment-
implicit_highlighting
Cheers,
Mirko
On Friday 22 July 2011 13:55:45 David Bernard wrote:
> Mirko,
>
> Yesterday I found a bug in implicits, I already made the workaround (avoid
> break) but not the clean fix. I'm experimenting OSGi and wait to extends
> the sdt (on 1.x.y). Like Grzegorz I thinks new features should wait (not
> too long).
>
> /davidB
David Bernard
Mirko Stocker
I saw it; thanks! I'll take a look at the code, maybe I can find the cause :-)
Thanks,
Mirko
On Monday 25 July 2011 22:29:11 David Bernard wrote:
> Hi Mirko,
>
> I cherry-pick the NPE workaround to the branch wip_....implicit_highlighting
> (I'm not sur the NPE is always possible with scala 2.9.0, I didn't check)
> The real fix should be to display the value of implicit args and find
> why Tree.symbol is null.
>
> /davidB
ijuma
iulian dragos
> Hi David
>
> Can you tell me more about the bug (and the solution :-) ) you found in
> implicit highlighting?
>
> I've ported the code to wip_experiment and pushed it as a new branch:
>
> http://www.assembla.com/code/scala-ide/git/nodes?rev=wip_experiment-
> implicit_highlighting
Hi Mirko,
Thanks for working on this, and sorry for the long delay. I had a look
at it today, and the code looks fine. I have a couple of observations:
- the default value should be 'off'
- the startup sequence seems to be (sometimes) wrong: it tries to
highlight a file that hasn't yet been 'reloaded' in the presentation
compiler
- related to one of your TODOs, I have no idea why the symbol can be
null on that code path (nor could I reproduce it with the example in
the ticket you mentioned). Maybe we can ignore this issue at the
moment, and just log it when it's null.
iulian
>
> Cheers,
>
> Mirko
>
> On Friday 22 July 2011 13:55:45 David Bernard wrote:
>> Mirko,
>>
>> Yesterday I found a bug in implicits, I already made the workaround (avoid
>> break) but not the clean fix. I'm experimenting OSGi and wait to extends
>> the sdt (on 1.x.y). Like Grzegorz I thinks new features should wait (not
>> too long).
>>
>> /davidB
> --
> Mirko Stocker | m...@misto.ch
> Work: http://ifs.hsr.ch | http://infoq.com
> Personal: http://misto.ch | http://twitter.com/m_st
>
>
--
Mirko Stocker
On Monday 29 August 2011 18:02:46 iulian dragos wrote:
> Thanks for working on this, and sorry for the long delay. I had a look
> at it today, and the code looks fine.
No problem! It's waiting for 2.1 anyways, so there's no hurry.
> - the default value should be 'off'
Done.
> - the startup sequence seems to be (sometimes) wrong: it tries to
> highlight a file that hasn't yet been 'reloaded' in the presentation
> compiler
I couldn't reproduce this, but I've made a change to use askLoadedTyped with a
timeout of 200ms. Do you think this might fix the problem you saw?
> - related to one of your TODOs, I have no idea why the symbol can be
> null on that code path (nor could I reproduce it with the example in
> the ticket you mentioned). Maybe we can ignore this issue at the
> moment, and just log it when it's null.
That's interesting.. (btw. David wrote that TODO) I just tried it again with
2.10-SNAPSHOT, and it's still the same issue: ApplyToImplicitArgs's args is a
list with one Block, and the block doesn't have a symbol, so the original code
failed:
v.args.map(_.symbol.name)
David's change now prevents this from happening:
val argsStr = v.args match {
case null => ""
case l => l.collect{case x if x.hasSymbol ....
}
but we still need a better way to extract the implicit argument. I'm not sure
why the "case null" is needed, IMO this shouldn't be necessary.
Cheers,
Mirko
iulian dragos
> Hi Iulian
>
> On Monday 29 August 2011 18:02:46 iulian dragos wrote:
>> Thanks for working on this, and sorry for the long delay. I had a look
>> at it today, and the code looks fine.
>
> No problem! It's waiting for 2.1 anyways, so there's no hurry.
Why not merge the extension point right now, and make the highlighter
a separate plugin? This way people could try it early, and since it's
already well isolated using the extension point, it might be not that
much additional work. Just an idea, otherwise we an also wait until
2.1.
>> - the default value should be 'off'
>
> Done.
>
>> - the startup sequence seems to be (sometimes) wrong: it tries to
>> highlight a file that hasn't yet been 'reloaded' in the presentation
>> compiler
>
> I couldn't reproduce this, but I've made a change to use askLoadedTyped with a
> timeout of 200ms. Do you think this might fix the problem you saw?
I think this should do.
>
>> - related to one of your TODOs, I have no idea why the symbol can be
>> null on that code path (nor could I reproduce it with the example in
>> the ticket you mentioned). Maybe we can ignore this issue at the
>> moment, and just log it when it's null.
>
> That's interesting.. (btw. David wrote that TODO) I just tried it again with
> 2.10-SNAPSHOT, and it's still the same issue: ApplyToImplicitArgs's args is a
> list with one Block, and the block doesn't have a symbol, so the original code
> failed:
Hm, I must have been doing something wrong. I tried the shortened
example you posted in that ticket. I'll have a look again.
>
> v.args.map(_.symbol.name)
>
> David's change now prevents this from happening:
>
> val argsStr = v.args match {
> case null => ""
> case l => l.collect{case x if x.hasSymbol ....
> }
>
> but we still need a better way to extract the implicit argument. I'm not sure
> why the "case null" is needed, IMO this shouldn't be necessary.
Agreed, it shouldn't happen. I'll try to reproduce and see why that happened.
iulian
>
> Cheers,
>
> Mirko
>
> --
> Mirko Stocker | m...@misto.ch
> Work: http://ifs.hsr.ch | http://infoq.com
> Personal: http://misto.ch | http://twitter.com/m_st
>
>
--
Daniel Ratiu
> - Scaladoc integration with completion and hovering (this would be
> great to have, almost there, needs some finishing touches from Daniel)
initial review a few weeks ago. My new code still needs review from
the core team, so it needs now "your touches :-)".
Cheers,
Daniel
Matt Russell
Why not merge the extension point right now, and make the highlighter
a separate plugin? This way people could try it early, and since it's
already well isolated using the extension point, it might be not that
much additional work. Just an idea, otherwise we an also wait until
2.1.
iulian dragos
> Hi Iulian,
>
>> - Scaladoc integration with completion and hovering (this would be
>> great to have, almost there, needs some finishing touches from Daniel)
> I've pushed the Scaladoc/Javadoc integration that contains your
> initial review a few weeks ago. My new code still needs review from
> the core team, so it needs now "your touches :-)".
:) Daniel, I remember you noticed the unreliability as well (sometimes
the doc comments are found, sometimes they are not -- for the same
definition). I think we need to get to the bottom of it before we push
it to users, and that may require more work on the compiler side.
Unfortunately, I can't look into it as we are trying hard to push a
new release and reach a 2.0 final soon. If you have some time and can
identify more precisely why (or when) the scaladoc is not found, I
could talk Martin into fixing it. ;-)
iulian
Mirco Dotta
>>> great to have, almost there, needs some finishing touches from Daniel)
>> I've pushed the Scaladoc/Javadoc integration that contains your
>> initial review a few weeks ago. My new code still needs review from
>> the core team, so it needs now "your touches :-)".
>
> could talk Martin into fixing it. ;-)
If the presentation compiler is on blame, it might be valuable to create a test.
This will provide a way to reproduce the issue and make it easier for Martin to fix it.
There is a wiki page that explains -- to some extent -- how to exercise the presentation compiler
in isolation:
Also, look at the existing presentation compiler tests, to have a better idea of how you can define a test case.
I'm not sure if the current testing infrastructure will be enough for your needs, but you are free to extend it and
submit a patch (in case you do that, simply submit the patch to me).
Hope this helps.
-- Mirco
Mirko Stocker
On Friday 02 September 2011 00:48:07 Matt Russell wrote:
> I'm also keen to see this land; I've done a small amount of work on semantic
> highlighting which would be ideal to port to it.
Ok, then I'll merge the extension point (and disable the implicit highlighting
for now).