You're right. I'll try to do some work on Diana verision this week. But I'm not sure, that it will be enough for you. I can suggest you to try last Maia releases. Just one reason possible to not use Maia: possibly broken testing frameworks, and no code completion in console. But with scala 2.7 it must work as it was in Diana, and some work for 2.8 will be soon. So I think you can use Maia, after your project refactoring to avoid red code (what you will do when you try to use scala 2.8). I'm really sorry for this inconveniences, but currently we have very poor resources, and we need to have working plugin with Maia and scala 2.8 releases. I hope you exuse us for it.
You'll find that I get numerous exceptions (I send them on using the built-in reporting mechanism, but I've sort of given up describing what I'm doing every time they happen) and these are naturally the most onerous. Some of them (but not all) seem to be "modal" in the sense that once they occur in a given source file, they keep occurring, sometimes without intervention, sometimes with some time and editing in between.
The improperly red code is far less problematic and I can live with that. The gaps in rename refactoring a little more annoying, but also survivable.
Naturally, we all can sympathize with resource constraints in development organizations. And I realize that the current situation with 2.7 about to be replaced by 2.8 but with 2.8 far from stable makes the situation rather hard to manage.
I look forward to moving up to IDEA 9 and Scala 2.8 and hope that transition comes soon.
Actually, you should to send only one exception related to same bug. For example, that exception about pressing Enter (which related to IDEA, and the same thing for IDEA 9.0 and IDEA 8.0, fixes for IDEA 8.0 only for critical bugs, and I'm not sure about fix for it).
Unfortunately, yes. You can find only small bugfixes if it will be.
Best regards,
Alexander Podkhalyuzin.
A month ago you wrote this.
Currently this is fixed only in Maia.
Best regards,
Alexander Podkhalyuzin.
Come on. Isn't it unreasonable not to fix bugs in the supported version and provide them only in pre-release software?
You're right. I'll try to do some work on Diana verision this week. But I'm not sure, that it will be enough for you.
I can suggest you to try last Maia releases. Just one reason possible to not use Maia: possibly broken testing frameworks, and no code completion in console. But with scala 2.7 it must work as it was in Diana, and some work for 2.8 will be soon. So I think you can use Maia, after your project refactoring to avoid red code (what you will do when you try to use scala 2.8).
I'm really sorry for this inconveniences, but currently we have very poor resources, and we need to have working plugin with Maia and scala 2.8 releases.
I hope you exuse us for it.
Best regards,
Alexander Podkhalyuzin.
Alexander,
Thank you.
You'll find that I get numerous exceptions (I send them on using the built-in reporting mechanism, but I've sort of given up describing what I'm doing every time they happen) and these are naturally the most onerous. Some of them (but not all) seem to be "modal" in the sense that once they occur in a given source file, they keep occurring, sometimes without intervention, sometimes with some time and editing in between.
The improperly red code is far less problematic and I can live with that. The gaps in rename refactoring a little more annoying, but also survivable.
Naturally, we all can sympathize with resource constraints in development organizations. And I realize that the current situation with 2.7 about to be replaced by 2.8 but with 2.8 far from stable makes the situation rather hard to manage.
I look forward to moving up to IDEA 9 and Scala 2.8 and hope that transition comes soon.
Randall Schulz
Actually, you should to send only one exception related to same bug.
For example, that exception about pressing Enter (which related to IDEA, and the same thing for IDEA 9.0 and IDEA 8.0, fixes for IDEA 8.0 only for critical bugs, and I'm not sure about fix for it).
Best regards,
Alexander Podkhalyuzin.