{ANN} IntelliScala

Howdy,

We've made our efforts to support Scala in IntelliJ available in plugin repository.
The feature highlihts are:

-Syntax highlighting
-Parsing errors highlighting
-Compiling Scala in the same module as Java with Scala to Java dependencies
-Debugging Scala
-Goto class/trait/object
-Structure view
-Folding
-Keyword completion
-Resolving references to java classes and Scala classes and traits from Scala type references

Enjoy!

P.S. the sources will be opened really soon

20 comments
Comment actions Permalink

Hi Eugene,
Hope you had fun! I see it from the plugin manager of my Selena EAP -
is it available for 6.0 as well? (The plugin page says "Since 6.0
(6666)" and my 6.0 build is 6141 so I don't see it.)
R

0
Comment actions Permalink

Robert,
Unfortunately the plugin is available for Selena only, preferrably with last EAP, though most of it should work with earlier builds.

Eugene.

0
Comment actions Permalink

Hi Eugene,
OK no problem. Now to get it working under Linux ;)
R

0
Comment actions Permalink

How about a plug-in for Groovy, Eugene? We already had Ruby and Scala plug-in but a Groovy plug-in will be the one I love 'cause the development progress of GroovyJ is very very slow.

0
Comment actions Permalink

How about a plug-in for Groovy, Eugene?
We already had Ruby and Scala plug-in but
a Groovy plug-in will be the one I
love 'cause the development progress of GroovyJ is very very slow.

How about Python?
The PythonID progress is also very very slow :).

Also, Python was promised as the first "independent from the core" language plug-in
when the Language API was introduced,
and it's still not "production ready" and not even at the level of the Ruby plug-in :(.

It looks like a very very difficult task to implement such a thing.
Maybe Netbeans new approach:
http://wiki.netbeans.org/wiki/view/Schliemann
http://scripting.netbeans.org/
is not that bad idea (since MPS doesn't seems to deliver what it promised 3 years ago).

Thanks in advance,

Ahmed.

0
Comment actions Permalink

Hello Ahmed,

>> How about a plug-in for Groovy, Eugene? We already had Ruby and Scala
>> plug-in but a Groovy plug-in will be the one I love 'cause the
>> development progress of GroovyJ is very very slow.
>>

How about Python?
The PythonID progress is also very very slow :).
Also, Python was promised as the first "independent from the core"
language plug-in
when the Language API was introduced,
and it's still not "production ready" and not even at the level of the
Ruby plug-in :(.
It looks like a very very difficult task to implement such a thing.
Maybe Netbeans new approach:
http://wiki.netbeans.org/wiki/view/Schliemann
http://scripting.netbeans.org/
is not that bad idea


If you look at their proposed feature set, you'll basically find lexing,
parsing, structure view and folding. This is very straightforward to implement
for most languages - it works even for Python. :)

However, it doesn't cover the interesting functionality - import resolution,
navigation, completion etc. And that's much harder to implement, and hardly
possible to provide a general solution for.

(since MPS doesn't seems to deliver what it
promised 3 years ago).


MPS has exactly nothing to do with supporting existing scripting languages.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

>>> How about a plug-in for Groovy, Eugene? We already had Ruby and Scala
>>> plug-in but a Groovy plug-in will be the one I love 'cause the
>>> development progress of GroovyJ is very very slow.
>>>
>> How about Python?
>> The PythonID progress is also very very slow :).
>> Also, Python was promised as the first "independent from the core"
>> language plug-in
>> when the Language API was introduced,
>> and it's still not "production ready" and not even at the level of the
>> Ruby plug-in :(.
>> It looks like a very very difficult task to implement such a thing.
>> Maybe Netbeans new approach:
>> http://wiki.netbeans.org/wiki/view/Schliemann
>> http://scripting.netbeans.org/
>> is not that bad idea


If you look at their proposed feature set, you'll basically find lexing,
parsing, structure view and folding.

The module is still experimental, and the planned features set is bigger.
http://wiki.netbeans.org/wiki/view/SchliemannNBSLanguageDescription
Imports definition.
Code completion definition.
Actions definition.
Tooltips definition.
Hyperlinks definition.
Indentation definition.
Properties definition.
Annotations definition.

This is very straightforward to
implement for most languages - it works even for Python. :)

Yeah but the plug-in is still not very usable in practice :(.

>> (since MPS doesn't seems to deliver what it
>> promised 3 years ago).


MPS has exactly nothing to do with supporting existing scripting languages.

Maybe not now, but it was promised to support the easy definition DSLs and scripting languages were
also included at that time.

Ahmed.

0
Comment actions Permalink

Hello Ahmed,

>> This is very straightforward to implement for most languages - it
>> works even for Python. :)
>>

Yeah but the plug-in is still not very usable in practice :(.


I know. Sorry, but what do you expect to gain by bringing this up yet again
here? I think I've explained the status of the project enough times already.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

>>> This is very straightforward to implement for most languages - it
>>> works even for Python. :)
>>>
>> Yeah but the plug-in is still not very usable in practice :(.


I know. Sorry, but what do you expect to gain by bringing this up yet
again here?

I expect a higher priority for this project.

Even if scala is nice, the usage of Python is much higher and also the
potential of new IntelliJ users.
Also much more users use Python than Groovy.

So I expect much more new IntelliJ users if there were a usable
Python plug-in.

I saw just too many users going away from IntelliJ :(, so I think this is
a way to get other new users.

Another smart move from IntelliJ would be a PHP plug-in, but a good one.
This would bring of course the highest user base, but it would also take
too much time to develop it. This is why I insisted on Python since it's "almost ready".

I think I've explained the status of the project enough
times already.

Yes, sorry :(.

Thanks in advance and sorry,

Ahmed.


0
Comment actions Permalink

Well, please don't get me wrong and we do plan to participate in Groovy support. Still I am rather disappointed with the reaction of IJ community to seeing new language plugin. For years IntelliJ community was the one driving the technology, not driven by big guys marketing vehicle. Now I wonder how many people demanding Groovy, PHP and the like have actually tried Scala. I don't argue Scala is better or worse than those other languages, they are too different to compare. But I personally and the other members of the team that has been working on a plugin have been getting fun and lots of enjoyment from writing the plugin in Scala. Also note that the plugin is not the official JetBrains product, so "more users is better" logic is not applicable here. BTW, I would definitely like to suggest new Forum topic: "This would make IDEA cooler to users" for people to suggest what would make IDEA more marketing appealing.

0
Comment actions Permalink

Don't forget that the Scala plug-in is, as far as I understand, a
personal project for some of the Idea developers, so you shouldn't
compare it to one of the official plug-ins.
R

0
Comment actions Permalink

Eugene, I'm just thankful for you guys pointing my attention to what
looks like a very interesting language... and these sort of plugins are
great for supporting the 'underdog' which is always a good philosophy...
not only is todays underdog sometimes tomorrows 'top-dog', but the
pebbles on the beach are just as important as the huge hulking rocks.

Don't be discouraged by the spoilt brats, who get narked because you
spent some of your time doing what you guys wanted rather than what
they want you to do; I'm glad you had a good time coding this up, and
the boost to your morale and the things you learn doing it is only going
to improve the whole product in the long run.

Regards,
N.

ps. You actually wrote the plugin for Scala in Scala? Hardcore!

Eugene Vigdorchik wrote:

Well, please don't get me wrong and we do plan to participate in
Groovy support. Still I am rather disappointed with the reaction of
IJ community to seeing new language plugin. For years IntelliJ
community was the one driving the technology, not driven by big guys
marketing vehicle. Now I wonder how many people demanding Groovy, PHP
and the like have actually tried Scala. I don't argue Scala is better
or worse than those other languages, they are too different to
compare. But I personally and the other members of the team that has
been working on a plugin have been getting fun and lots of enjoyment
from writing the plugin in Scala. Also note that the plugin is not
the official JetBrains product, so "more users is better" logic is
not applicable here. BTW, I would definitely like to suggest new
Forum topic: "This would make IDEA cooler to users" for people to
suggest what would make IDEA more marketing appealing.

0
Comment actions Permalink

Excellent, and congratulations!

--Dave Griffith

0
Comment actions Permalink

Great!
I haven't figured out though, how to actually run/debug. I just copied one of the random
source files that appear on the scala homepage.
Highlighting, structure view, go to class, compiling all work fine.

The class has a main method. I get no run/debug on the context menu like in Java.
Also I haven't found a way to explicitly create a debug configuration.

Any hints?

Eugene Vigdorchik wrote:

Howdy,

We've made our efforts to support Scala in IntelliJ available in plugin repository.
The feature highlihts are:

-Syntax highlighting
-Parsing errors highlighting
-Compiling Scala in the same module as Java with Scala to Java dependencies
-Debugging Scala
-Goto class/trait/object
-Structure view
-Folding
-Keyword completion
-Resolving references to java classes and Scala classes and traits from Scala type references

Enjoy!

P.S. the sources will be opened really soon

0
Comment actions Permalink

Automatic run configurations creation is not yet supported. But you should be able to set up run configuration manually in "edit run configurations", and setting up a breakpoint and stepping should work.

0
Comment actions Permalink

Eugene Vigdorchik wrote:

Automatic run configurations creation is not yet supported. But you should be able to set up run configuration manually in "edit run configurations", and setting up a breakpoint and stepping should work.

Hm, I tried with the file Main.scala directly in a source folder:

object Main {
import Console._
var verbose = false

def main(args: Array[String]) {
for (val a <- args)
a match {
case "-h" | "-help" => println("Usage: scala Main -help")
case "-v" | "-verbose" => verbose = true
case x => println("Unknown option: '" + x + "'")
}
if (verbose)
println("How are you today?")
}
}

When I manually create a run/debug configuration (of type Application) Idea does not find the main class.
If I just enter "Main" there, I can run the class fine (but the run configuration still has a red cross
with warning message "Main method not found in class Main").
But when I debug breakpoints do not work at all.

Maybe there's a deeper problem here:
I get "Cannot save application settings: null" much more often that before installing the Scala plugin.
No RCOD when this happens and log does not show any exception, either.

I have some of these exceptions in the log, but don't know when exactly they happened:
ERROR - penapi.actionSystem.impl.Utils - update failed for AnAction with ID=DebugClass
java.lang.NullPointerException
at com.intellij.execution.junit.JUnitUtil.isTestClass(JUnitUtil.java:74)
at com.intellij.execution.junit.JUnitUtil.isTestClass(JUnitUtil.java:75)
at com.intellij.execution.junit.JUnitConfigurationProducer.getTestClass(JUnitConfigurationProducer.java:2)
at com.intellij.execution.junit.TestClassConfigurationProducer.createConfigurationByElement(TestClassConfigurationProducer.java:10)
at com.intellij.execution.junit.RuntimeConfigurationProducer.createProducer(RuntimeConfigurationProducer.java:7)
at com.intellij.execution.actions.PreferedProducerFind.findPreferedProducer(PreferedProducerFind.java:1)
at com.intellij.execution.actions.PreferedProducerFind.createConfiguration(PreferedProducerFind.java:16)
at com.intellij.execution.actions.ConfigurationContext.a(ConfigurationContext.java:35)
at com.intellij.execution.actions.ConfigurationContext.getConfiguration(ConfigurationContext.java:21)
at com.intellij.execution.actions.BaseRunConfigurationAction.update(BaseRunConfigurationAction.java:13)
at com.intellij.openapi.actionSystem.impl.Utils.a(Utils.java:2)
at com.intellij.openapi.actionSystem.impl.Utils.expandActionGroup(Utils.java:75)
at com.intellij.openapi.actionSystem.impl.Utils.expandActionGroup(Utils.java:41)
at com.intellij.openapi.actionSystem.impl.Utils.expandActionGroup(Utils.java:41)
at com.intellij.openapi.actionSystem.impl.Utils.fillMenu(Utils.java:19)
at com.intellij.openapi.actionSystem.impl.ActionPopupMenuImpl$MyMenu$MyPopupMenuListener.popupMenuWillBecomeVisible(ActionPopupMenuImpl.java:4)
at javax.swing.JPopupMenu.firePopupMenuWillBecomeVisible(JPopupMenu.java:674)
at javax.swing.JPopupMenu.setVisible(JPopupMenu.java:788)
at javax.swing.JPopupMenu.show(JPopupMenu.java:951)
at com.intellij.openapi.actionSystem.impl.ActionPopupMenuImpl$MyMenu.show(ActionPopupMenuImpl.java:6)
at com.intellij.ide.projectView.impl.AbstractProjectViewPane$3.invokePopup(AbstractProjectViewPane.java:3)
at com.intellij.ui.PopupHandler.mouseReleased(PopupHandler.java:54)
at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:232)
at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231)
at java.awt.Component.processMouseEvent(Component.java:5501)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3135)
at com.intellij.util.ui.Tree.processMouseEvent(Tree.java:71)
at java.awt.Component.processEvent(Component.java:5266)
at java.awt.Container.processEvent(Container.java:1966)
at java.awt.Component.dispatchEventImpl(Component.java:3968)
at java.awt.Container.dispatchEventImpl(Container.java:2024)
at java.awt.Component.dispatchEvent(Component.java:3803)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3892)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)
at java.awt.Container.dispatchEventImpl(Container.java:2010)
at java.awt.Window.dispatchEventImpl(Window.java:1778)
at java.awt.Component.dispatchEvent(Component.java:3803)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
at com.intellij.ide.IdeEventQueue.b(IdeEventQueue.java:165)
at com.intellij.ide.IdeEventQueue.a(IdeEventQueue.java:125)
at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:83)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)

0
Comment actions Permalink

The exception is really a bug in IDEA core that I have fixed.
Setting breakpoints in scala objects indeed does not work now due to Scalac code generation scheme, but we plan to adopt to it very soon.

Eugene.

0
Comment actions Permalink

Congratulations, guys! I'm looking forward to trying this out - I've been looking for a new language to learn, and it's become painfully obvious to me that I can't stand working in any language that doesn't have IntelliJ support :)

BTW Eugene did I read that right? You're actually developing the plugin in Scala? Interesting... how did that work out?

0
Comment actions Permalink

Yes, the plugin is developed in Scala + some Java where interaction with IDEA API requires lots of boilerplate code. And apart from some issues with generics that are really different in Scala and Java we are having no problems.

Eugene.

0
Comment actions Permalink

I'm curious, how would you guys rate the experience of developing the plugin in Scala compared to doing it in Java? Parsing and language analysis are some of the classic things that are supposed to be easier in functional languages - was writing the plugin easier in Scala than it would have been in Java?

It's cool, either way :)

Cheers,
Colin

0

Please sign in to leave a comment.