Plugin starting to become flaky?

Hi folks,

On 11.1.3, and updated on the scala plugin.  I'm finding the plugin is starting to become flaky, flagging things red when they are arent, or telling me packages like scala.collections doesnt exist.  For example this code:

for (*val* column <- table.getColumns) {


the *val* is red... This file compiles just fine.  

This just popped up a few days ago, I think of the regular auto plugin updates did this to me.

评论操作 固定链接

( for what it's worth, the val should not be used anyways:

scala> for (val column <- Seq(1,2,3,4,5)) { }
<console>:1: warning: for (val x <- ... ) has been deprecated; use for (x <- ... ) instead
       for (val column <- Seq(1,2,3,4,5)) { }
            ^
)

0
评论操作 固定链接

fair enough, but it's still valid syntax?

0
评论操作 固定链接

Sure, it shouldn't be red, just saying that you can just eliminate that case without problem.

0
评论操作 固定链接

Currently plugin works according to Scala 2.10 syntax where this code is illegal.

Best regards,
Alexander Podkhlayuzin.

0
评论操作 固定链接

ok that's great for those who are using scala 2.10, but I'm using scala 2.9.1... where this code is legal.

I think it's time to dump scala for good.  The language just doesnt bring enough to the table to overcome the additional complexity and poor tooling support (not necessairly your fault I know)

0
评论操作 固定链接

Scala has a reasonable legacy policy: deprecate something in one major version, possibly remove it in the next major version. It is true that correct highlight would be orange not red, but since you are editing your own source code here, removing the val is not too much effort. The Scala plug-in team is usually quite helpful fixing issues like the one you reported, so while I understand it is an annoyance for you right now, there is no reason to get upset; especially if you want to "dump" Scala anyway.

I personally have witnessed the opposite movement, the plug-in becoming less and less flaky. Very good work from the JetBrains side IMHO.

0
评论操作 固定链接

don't mistake me... Scala plugin has been improving, but recently I ran into a situation where known good code was throwing up red like crazy.  I ended up invalidating caches, recreating the project, removing the scala plugin, adding it back, invalidating caches again.  

When I Saw the red 'var' I figured it was that problem popping up again.  Apparently not I guess.

0
评论操作 固定链接

is it planned to add language version support someday, like it's possible for java now? if yes, where is it going to start?

0
评论操作 固定链接

We missed it for 2.9, but I think it will be implemented for 2.10 and 2.11.

Best regards,
Alexander Podkhalyuzin.

0
评论操作 固定链接

I'd not say that it is getting flaky. The developers are putting for sure lots of effort to improve the plugin and if you look at the commitlog, there is plenty of issues being fixed every week. I really appreciate all the good work that goes into this plugin. If I had more time, I'd probably join coding, I'm sorry I limit myself to posting bug reports so far...

On the other hand I must say there are some things that worry me:

* The plugin has lots of great features, but most of them are constantly kinda broken or not finished. Some of them are basic ones: error highlighting, move/rename refactoring (I hope this one has been finally fixed once and for all, but it took far too long). IMHO at the current stage of development, you should really put more effort into making the basic features rock solid than adding new "nice-to-have" features like inspections. You may say error highligting and type inference work in 99% cases. True. But what use is it if you had a calculator that gives correct results in 99% cases? The problem is about trust - I still can't trust this plugin telling me my code is good or broken. If I do a Scala training for someone, I'd have to tell them "well, if your code gets underlined in red, this doesn't mean it is wrong. If it doesn't, it also doesn't mean it is correct. Well, just ignore thoses underlines or turn this feature off.." That is sad. The same about refactoring "yeah, you can use that feature to refactor your code, but make sure afterwards it didn't actually break it...". So if it is possible, move some effort from less critical parts of the plugin into those that are used all the time - make basic features rock solid, like in Java plugin.  

* Stable production releases with well defined working feature set. Like e.g. you announce "in this release we introduce and 'extract method refactoring'". And then it simply works, always, not in 90% cases. I'd like there are some releases that get a good portion of testing and at least the non-experimental, announced features are rock solid. That would help industrial adoption a lot. Currently it seems releases are the nightly builds that turned out to be more stable than the rest. Correct me if I'm wrong. Well I tried running from releases many times, and always hit some major or critical bugs. Maybe you should work more on a feature-by-feature basis. Add less, but with better quality.

* Performance. Ok, I must admint performance got a lot better. This was a huge achievement. On a powerful enough computer it is almost ok... but I still see the problem here running on batteries. First, my smaller laptop is much slower. Second, it is even slower when not plugged. I tried coding Scala on a plane. While I can work with Java code for about 4-5 hours from batteries (and no lags there and fast compilation), when coding in Scala it lasts for much, much less. Actually 3 hours and it started complaining the battery is low. The plugin seems to do lots of the same work again and again. If I edit a small function, It looks like the whole file gets checked, not just that edited function itself. And while the functions in Scala are usually small, this would be a huge performance win if the plugin could do incremental type checking of code, per function / method, not per file - just typecheck the function I modified and, if and only if its type changed, typecheck all the dependent functions. Most of edits don't change the arguments not inferred return type of the function. A bonus would be error highlighting could be much more responsive. If type-aware error highlighting worked correctly and was fast, the slow compile times in Scala would not be a problem.

Don't get me wrong, I'm not criticizing you or the project. I'm trying only to give some hints, how to make us, the users of the plugin more happy. I hope this helps a little. And even though these problems, I still love this plugin ;)

0
评论操作 固定链接

Thank you for your hints and also thank you very much for your reports in tracker. Actually your thoughts is very similar to mine. I'm planning to concentrate my work only on error highlighting next few monthes (and slightly on code completion), but this progress is very slow, I hope it will become faster before IDEA 12 release.
Stability of releases is also my task, which I want to fix before IDEA 12 release.
What's about performance this is very complicated thing, and actually needs something what you just described to improve it a lot. This is very complex task and I think I won't do it soon, because of problems with error highlighting (like you just described).

Best regards,
Alexander Podkhalyuzin.

0
评论操作 固定链接

+1 for focus on basic features

0

请先登录再写评论。