Scaladoc in hovers and completions

[iulian dragos]

I spent some time today trying to merge-in the excellent contribution from Daniel and Marek. Thanks a lot! There are a couple of issues that, once resolved, we can finally take advantage of this extremely useful improvement.

The codebase evolved since the contribution was made, and most importantly we have integration tests! Unfortunately, they don't pass with the scaladoc functionality.

The first issue is related to how the scaladoc comments are built. Right now, the functionality is inside a trait that is mixed-in in the PresentationCompiler. Moreover, the functionality requires the UI to be fired up, because it retrieves some image identifiers. This is bad thing on several accounts, but mostly it makes the compiler unusable in a headless environment (such as the Jenkins nightly).

I propose the functionality is split in two:

 - functionality to retrieve the 'raw' scaladoc comment from a symbol, which could be part of the Scala Presentation Compiler (but not necessarily, I can see that migrating into ScalaProject as well -- up to you).

 - functionality to build the 'rich' HTML to be displayed in the UI. This should be moved to the 'scala.tools.eclipse.ui' package

Second, it would be great to have a few basic tests. The above split allows makes testing almost free :). So we'd need a test for the hovering component that can run during the nightly, therefore it needs to use only the non-UI part. There are already some tests in org.scala-ide.sdt.core.tests (look at StructureBuilderTest or HyperlinkDetectorTests (which also tests only the non-UI part) for examples how to use them), I plan to write up some documentation on how to write integration tests, but hopefully the existing ones are easy to understand. Let me know if you need help there.

Things change quite a lot in the last few weeks, so there were some nasty merge conflicts when I rebased over wip_experiment. I pushed a new branch 'feature/hover-scaladoc-rebased that is up-to-date with the latest wip_experiment to save you the pain of re-merging (but I did not delete wip_hovering -- please delete it yourself if you are fine with my rebasing). Right now the tests pass, but still fire-up the UI (so they would fail in Jenkins). I also noticed some flakiness, sometimes the scaladoc would be found, and other times it would be missing.. 

let me know if I can do anything to help you with this. In the mid-term run, I'd like to push out a new beta beginning/middle of next week, and it would be great to have this in, so people can try it out.

thanks,

iulian

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

[Daniel Ratiu]

Hi Iulian,

I tried to compile the feature/hover-scaladoc-rebased but I did not
succeed.

For example, I get the following error message (when I try to build
with: org.scala-ide.build/build-ide-trunk.sh)

---
org.scala-ide.sdt.core/src/scala/tools/eclipse/wizards/
CodeBuilder.scala:164: error: case class `class Args' has case
ancestor `class ParenList'. Case-to-case inheritance is prohibited. To
overcome this limitation use extractors to pattern match on non-leaf
nodes.
---

I get the same error in my eclipse with the following version of Scala
plugin:
http://download.scala-ide.org/nightly-update-wip-experiment-trunk

Which version of the scala plugin, which works fine with hover-
scaladoc-rebased, do I need in my eclipse or how can I build one?

have a nice weekend,
Daniel

[iulian dragos]

On Sat, Jul 16, 2011 at 11:01 AM, Daniel Ratiu <rat...@googlemail.com> wrote:
> Hi Iulian,
>
> I tried to compile the feature/hover-scaladoc-rebased but I did not
> succeed.
>
> For example, I get the following error message (when I try to build
> with: org.scala-ide.build/build-ide-trunk.sh)

This is because case-class inheritance has been removed from the trunk
version of scala (future 2.10). It has been deprecated for several
years. I already ported wip_experiment, so if you merge
wip_experiment, you will be able to compile. This is the changeset:

https://www.assembla.com/code/scala-ide/git/changesets/fd367cffb067632d2ee0d877f6e7bb79b13cb013

cheers,
iulian

[iulian dragos]

Hi Daniel,

In case you haven't started yet on the UI/non-UI refactoring, you can
take advantage of my latest commit: I just had to do the refactoring
myself in order to be able to test completions, and re-enable Mirco's
tests in a headless environment (remember, any code that touches UI
elements and tries to fire up a display will fail under Jenkins).

Basically, code that needs the UI to run is in
'scala.tools.eclipse.ui', and code that implements core functionality
is in scala.tools.eclipse.completions. I believe it's easy to find
your way around those classes.

cheers,
iulian

[Miles Sabin]

On Tue, Jul 19, 2011 at 2:44 PM, iulian dragos <jagu...@gmail.com> wrote:
> In case you haven't started yet on the UI/non-UI refactoring, you can
> take advantage of my latest commit: I just had to do the refactoring
> myself in order to be able to test completions, and re-enable Mirco's
> tests in a headless environment (remember, any code that touches UI
> elements and tries to fire up a display will fail under Jenkins).
>
> Basically, code that needs the UI to run is in
> 'scala.tools.eclipse.ui', and code that implements core functionality
> is in scala.tools.eclipse.completions. I believe it's easy to find
> your way around those classes.

Looks good ... I'd be tempted to split org.scala-ide.sdt.core into two
disctinct non-UI and UI bundles as well, ie. org.scala-ide.sdt.core
and org.scala-ide.sdt.core.ui.

Cheers,

Miles

--
Miles Sabin
tel: +44 7813 944 528
gtalk: mi...@milessabin.com
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

[iulian dragos]

On Tue, Jul 19, 2011 at 4:11 PM, Miles Sabin <mi...@milessabin.com> wrote:
> On Tue, Jul 19, 2011 at 2:44 PM, iulian dragos <jagu...@gmail.com> wrote:
>> In case you haven't started yet on the UI/non-UI refactoring, you can
>> take advantage of my latest commit: I just had to do the refactoring
>> myself in order to be able to test completions, and re-enable Mirco's
>> tests in a headless environment (remember, any code that touches UI
>> elements and tries to fire up a display will fail under Jenkins).
>>
>> Basically, code that needs the UI to run is in
>> 'scala.tools.eclipse.ui', and code that implements core functionality
>> is in scala.tools.eclipse.completions. I believe it's easy to find
>> your way around those classes.
>
> Looks good ... I'd be tempted to split org.scala-ide.sdt.core into two
> disctinct non-UI and UI bundles as well, ie. org.scala-ide.sdt.core
> and org.scala-ide.sdt.core.ui.

That would be good as well...

>
> Cheers,
>
>
> Miles
>
> --
> Miles Sabin
> tel: +44 7813 944 528
> gtalk: mi...@milessabin.com
> skype: milessabin
> http://www.chuusai.com/
> http://twitter.com/milessabin
>

--

[Michel Krämer]

On 19 Jul., 16:11, Miles Sabin <mi...@milessabin.com> wrote:
> Looks good ... I'd be tempted to split org.scala-ide.sdt.core into two
> disctinct non-UI and UI bundles as well, ie. org.scala-ide.sdt.core
> and org.scala-ide.sdt.core.ui.

+1

This could also make building RCP products with Buckminster easier.
Currently you have to go for a workaround:
http://www.michel-kraemer.de/en/build-scala-projects-with-eclipse-buckminster

Bye,
Michel

[iulian dragos]

On Tue, Jul 19, 2011 at 10:45 PM, Michel Krämer
<michel....@googlemail.com> wrote:
> On 19 Jul., 16:11, Miles Sabin <mi...@milessabin.com> wrote:
>> Looks good ... I'd be tempted to split org.scala-ide.sdt.core into two
>> disctinct non-UI and UI bundles as well, ie. org.scala-ide.sdt.core
>> and org.scala-ide.sdt.core.ui.
>
> +1
>
> This could also make building RCP products with Buckminster easier.
> Currently you have to go for a workaround:
> http://www.michel-kraemer.de/en/build-scala-projects-with-eclipse-buckminster

We should do that. However, it's going to be a lot of work, and we
could use some help. (I personally have no experience with
Buckminster).

iulian

>
> Bye,
> Michel
>
>>
>> Cheers,
>>
>> Miles
>>
>> --
>> Miles Sabin
>> tel: +44 7813 944 528
>> gtalk: mi...@milessabin.com
>> skype: milessabinhttp://www.chuusai.com/http://twitter.com/milessabin

--

[Daniel Ratiu]

Hi Iulian,

I split the UI functionality apart from the core scaladoc harvesting
(which runs in the presentation compiler thread). I also wrote some
tests (some of them fail and they mirror the problems that occur in
the IDE -- is about what you said: "I also noticed some flakiness,

sometimes the scaladoc would be found, and other times it would be

missing.").

I am not convinced that my solution is the most elegant possible -
this needs to be reviewed by the core team.

To sum up, we are now a little bit further -- the problem I am facing
is that when I try to push back in the origin/feature I get an error
message:
---
> git push origin/feature hover-scaladoc-rebased
fatal: 'origin/feature' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
---

I tried "git push origin hover-scaladoc-rebased" and it functioned,
but it pushed directly in origin (and not in origin/feature) so I
deleted that :-(
It would be great if somebody tells me how to do this.

Buckminster + jenkins allows also to automatically run "JUnit Plug-in
Tests" (tests that require a running eclipse instance, like e.g. those
based on "EclipseUserSimulator")
By doing this, the whole code could be in principle tested, also the
combination scala and UI features.

cheers,
Daniel

On Jul 20, 10:15 am, iulian dragos <jagua...@gmail.com> wrote:
> On Tue, Jul 19, 2011 at 10:45 PM, Michel Krämer
>

> <michel.krae...@googlemail.com> wrote:
> > On 19 Jul., 16:11, Miles Sabin <mi...@milessabin.com> wrote:
> >> Looks good ... I'd be tempted to split org.scala-ide.sdt.core into two
> >> disctinct non-UI and UI bundles as well, ie. org.scala-ide.sdt.core
> >> and org.scala-ide.sdt.core.ui.
>
> > +1
>
> > This could also make building RCP products with Buckminster easier.
> > Currently you have to go for a workaround:

> >http://www.michel-kraemer.de/en/build-scala-projects-with-eclipse-buc...

[Michel Krämer]

On 20 Jul., 10:15, iulian dragos <jagua...@gmail.com> wrote:
> We should do that. However, it's going to be a lot of work, and we
> could use some help. (I personally have no experience with
> Buckminster).

Unfortunately, I don't have enough time to help you splitting up the
bundles, but whenever you have any questions regarding Buckminster or
if you need someone testing the splitted bundles, I'll be more than
glad to help.

Bye,
Michel

[Daniel Ratiu]

Hi Iulian,

I've pushed my changes on assembla in the "feature/hover-scaladoc-
rebased" branch.

Cheers,

Daniel

On Jul 13, 3:22 pm, iulian dragos <jagua...@gmail.com> wrote:

[Mirco Dotta]

Hi Daniel,

Iulian is currently in holiday, he will be back in mid august.

-- Mirco