Implicits, Scala-IDE and my mid GSOC evaluation
It is far long from my last blog entry. I even have not announced my acceptance of this year GSOC by Scala team. It is my honor! One reason is that it will be more useful if I put these time into solving practical problems.
Another big reason for the absence in June, is that several big things for me have happened in June. So most of them can not be expected or controlled. You would find helpless when the external force drived you to the different direction. After one influenza, I am back to gsoc to carry out my promise to community. The community trust that I can finish the project, so then give me the precious slot. I should show the feedback to the community and tell them the trust bear fruit. It is the spirit of community.
Now back to my mid gsoc evaluation topic. What my project do can be understanded here [1] at scala-ide wiki. If you are a new comer to Scala, you can read the official site[2]. One recent big news, we release the Scala 2.8.0 final[3]. The version is in high production-quality, and has many new features. Don't hesitate to join our party, especially if you are Java developer. Privately I were planned to write a series like "Step into Scala by Scala Eclipse IDE" at May, however, the idea now can not be picked up for the time limit.
Feature#1 in [1] is a long awaited feature in Scala IDE. It is involved with one cool Scala feature, that is the implicit conversion. This feature, as hinted by the name, can convert one object from one type to another type. The feature is similiar to the idea of Adapter pattern [4] in Java. The wonderful magic is this conversion happens implicitly(and can be controlled). So, something like follows can happen:
aVector + aInt // aInt be converted to a Vectot implicitly
Map(1->"one") // 1 or something else object will have not "->" method, we can convert any type to one type who has the "->" method
The implicit functionality "let you dress up existing libraries" [5], and make the code compact and clear. However, it will also be danger if it is abused. Because you do not know the conversion explicitly. Some potential unwanted implicit conversions may happen, but you are unaware of them. This will lead to unexpected result of your codes.
Although, the designer of Scala has given some rules to the usage of implicits(see PIS to get more detail explanation[5]). But you can not get hints when your editing sources. IDE tooling support will come to rescue you! Our feature#1 is just for this rescue!
Now, I finish the prototype of feature#1. Consider one simple source like follow:
object String2Int {
val a = "1";
val b = "2";
var c = "3";
implicit val somewords = new SomeWords("yeah!")
implicit def string2Int(s: String) = {
((s.toInt)+2)
}
def main(args:Array[String]) {
printInt("3")
printInt(a+b+c)
printIntWithSomeWords("5")(new SomeWords("..."))
printIntWithSomeWords("6")
val map = Map(1->"one",2->"two")
}
//implicit def otherwords: SomeWords = new SomeWords("Oh, yeah!")
def printInt(a:Int) {
println(a)
}
def printIntWithSomeWords(a: Int)(implicit sw: SomeWords) {
println(a)
println(sw.words)
}
class SomeWords(val words: String)
}
Can you recognize that this simple source has seven implicit conversion happened?:)
The follows sreenshot shows:
Three implicit conversion are based on the in-file implicit string2Int, but other fours are based on the implicits from the implicitly imported scala.Predef. I use the squiggle underlines to indicate them. This will be allowed to be customized after this feature being fully implemented.
So, to use our Scala-IDE, now you can see all the implicit conversion happened. I try one code exmaple vectors at official site[6], which shown like this.
One thing in UI here is that the hover has not been finished now. I am planning to use the Jface indepent annonation hover for this functionalites, not continue the current apsectJ-hooked version. As my opinion, hooking way is the double-edged sword. Hooking means you depend your works on the things out of your control. I suggest only using the AspectJ technique when the Eclipse and JDT have not left the door for your extension. However, this idea has not discussed with Miles:) I will discuss these to him in these days.
I used the Scala Eclipse IDE monthly. Frankly speaking, the current Scala Eclipse IDE is not very production-ready. I am forced to use one poor atom itx pc to power the development in one span recently. However, the performence is crazy crazy crazy...On the contrary, JDT works much fluently even on this pc. I do some profile on the current Scala Eclipse IDE, some cases shown as follows:
This screenshot shows the number of thread bump up to 59 suddenly
This screenshot shows this short lived threads are not collaborative. Almost of they are blocked. 
The main thread(UI thread) are blocked in several minutes by Scala Presentation Compiler thread(this is a background thread in Scala IDE).
From the primary eye, I think, the problem may be in the abused usage of SycVar. However, I am not to much time to verify it till now. The main thread shoud be kept unblocked in most cases, because it is the UI thread. Some problems seemly exist in the compiler library. That means, other IDE using the new presentation compiler, like Netbeans, may live in the same dilemma.
In one other core-duo notebook, I give the nice feedbeek, the stop feeling only happens with short time(seconds). However, I still find many other bugs, some of my cared bugs listed on my note here:
1. perfromance
memory consumaption is huge!(this cause that the full gc acitivities are heavy in some cases?)
index/build
leak?
2. code folding only for fisrt level function
(local function def is not folded)
3. local function def/call can not be displayed correctly
4.override doese not show the override indicator in outline
5. ScalaElement extends JavaElement is not elegant
6. icons for var and private var in the outline are the same
7. F2 or hover is not always available
8. building at the unnecessary time
9. Do not hook when that extensibilities has been supported by platform(or JDT).
SDT is expensively dependent on the AOP. hookings are done by AspectsJ. This technique is advanced, complex and not elegant when the framework has left the space to be extended.
10.hover in SDT is not consistent with JDT???
abd the default type hover is a little expensive for SDT
11. compilation error in one source stop all other sources compiling and clear /bin
12. scala.tools.eclipse.javaelements -> scala.tools.eclipse.scalaelements ?
13. sdt can not compile the nsc(that is the so-called "presentation compiler" of scala)
one problem is, the package.scala(package object in 2.8?) can not be seen as a scala source file. (package is a keyword in Java?)
14. auto completion is not well-behavoired.
15. scala class file editor don't support the debug?
16. hyperlink nagivations are not always available
like:class EclipseTyperRun extends TyperRun <--
17. override method hover show usefulless things.
18. reference nagviation(concurrent marking) does not work
19. sometimes compiler has been broken without any error indication in the editor. (sometimes shows unuseful things in the error log of eclipse)
20. quick fix(ctrl+1) is broken really.
21. long time sources error at IDESettings.scala?:
error: not found: value Xwarnfatal
error: not found: value Ywarndeadcode
22. open type does not match the full qualified class Type
23. Builder does not begin to work when the modification of source has been saved soemtimes
24. coding conventions are not coherent in the sources.
25. why not Scala-IDE SDK download?(I have one home-made sdk, it is easy^_^)
Don't be scared! Some are enhancement requests. And someone may have been fixed now. I will tell you when the above problems have been solved. If you have some interesting to help us, you can reach us at [7].
Let close the this reporting first. I will be back soon. Have a good night!
References:
[1] https://www.assembla.com/wiki/show/scala-ide/Google_Summer_of_Code
[2] http://www.scala-lang.org/
[3] http://www.scala-lang.org/node/7009
[4] http://en.wikipedia.org/wiki/Adapter_pattern
[5] http://www.artima.com/shop/programming_in_scala
[6] http://www.scala-lang.org/node/60
[7] http://groups.google.com/group/scala-ide-dev
No comments:
Post a Comment