Firstly, please allow me to say sorry to my unexpected update to one of my blog entry in the last weekend. This caused an very old blog entry re-posted to the planet again.
Because I am planning to start new round of posts in the community, so I do a little tweaking to the blog. I do a update to that blog entry in that several readers asked the status of my SEED project[1] in its release-following period. Unfortunately I must say it has been dead for many reasons.
After the SEED project M0, I have done a more deep investigation and reflection to the current languages on JVM. Like Scala, Kotlin(Ceylon, althoug I've forgot it, but not including the Groovy and Xtend), the basic conclusion is that the complexity much outweights the advantages of the language after the advanced features coming right before your eyes. Some adopters likes to keep to use a subset of the language to keep a good taste. But, if we only limits us to a subset, why we choose this language?
For example, recently, our Xtender Sebastian addressed an exception checking codes in Xtend v.s. Java 8[2]. His favorate Xtend codes like this:
" import static extension Throwables.* val uri = [| new URI(requestURI) ].onException [ new IllegalArgumentException(it) ] "
This codes, IMHO, just uncovers one big problem(or fault) which is much popular in the current mainstreaming JVM languages: that is, "Symbol Hell".
Who knows what " [|newURI(requestURI)]" stands for when one man meets these codes firstly? In some language, the operator could be mostly arbitrarily customized(to encourage the flow controlling). The result is that, you would regularly sees the in “clever” coders 's DSL library or framework:
~[...] ... ^ ... -|| ... <- -="-" ...="..."> ...
Are this codes happy to see by us?... I am afraid that, it is not the right direction that for the future of language...
Now, back to the topic of this post:)
Recently, IDEA 12 re-introduce a darkula theme[3], which makes our community a little nervous. The chronon boy posted one solution in the planet[3].
Recently, I start to migrate to the Eclipse 4.3 from old 3.8 platform. As I point out in my preious post[1] , the biggest problem to Eclipse Juno is that, the UI is ugly. The color is not harmony with native platform. The default Sash separation is too large. The worst thing is that, we always hate the round-corner tab[4]!
Not it is the time to eat our dog food!
In the weekend, I hack a simplest dark theme implemenation for the community: eclipse.themes.darker[5], which is based the style schema of eclipse-color-theme[6].
As you can see, the dark theme still has some not-dark elements in fact. Some of these is from the limitation of the SWT, like the button background color. But the css style engine still leaves the contribution space for us. After a little more work, I got this:
Yes, it is darker than that of the dark:)
The big fun is that, the codes are minimized by using Eclipse4 platform technologies like dependency injection[7]. It proves that again, the concise codes and advanced features could be achieved by contributing or extending with the external form(like library, framework). New language is not necessary just for this kind of purpose.
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";
implicitval somewords = new SomeWords("yeah!")
implicitdef 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 defotherwords: SomeWords = new SomeWords("Oh, yeah!")
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
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!
Align the Scala Development Tools with the Bleeding Edge of Eclipse
Too long time for me to blog anything here. In this long time, I’ve received three important offers(one small company, one big big company and one institute). Although I have not decided which to go finally, this these days are and will be impressive in my life:)
Recently, I’m beginning to prepare the defense of my Phd thesis. I accidentally found I received one email to ask whether I'd like to continue one of my 2009 GSOC[1] proposals in this year. After some browsing, I find that I am really eligible to participate in the 2010's program[2]. So, I decide to prepare this year’s GSOC for the real last time.
As an Eclipse guy, that you know, I will stick around the community. This year I raise my hands over the topic of language support using Eclipse technology, which is my best point of interest in recent years. In this year’s program, I will submit Scala Eclipse-sided enhancement proposals to promote both communities deeply into each other:)
One BIG picture! Scala is really one nice and natural language choice for one Java programmer, after I have learned some other dynamic languages like JRuby/Javascript/Lua. All the languages have their values in the appropriate places. So, in the this blogging, I don't like to fire the language WAR. I just record things about Scala and mainly SDT (Scala Development Tools, formally called Scala IDE for Eclipse[3]). This blogging could be considered as the starting point of my adventure.
Scala have three mainstream IDE supports currently. Without doubt, the enirovement of them are Eclipse, Netbeans and IntelliJ IDEA respectly. Some of Scala developers will use some of them. Among them, the SDT(I use SDT as the synonym to the "Scala IDE for Eclipse", it is my favorite name) seemly has the best integration with Java development tools(yeah, that is, JDT). I will not fire another IDE WAR...But, I predict that, the future belongs to Eclipse:)
Thanks to Miles Sabin, the SDT have one good body and have provided many nice basic functionalities, such as the wizards, highlighting, hyperlink navigation, builder, and recent code completion [4]. However, many advanced features still have not been included in the current SDT. One much inconvenient thing for me is that, the latest SDT only works with Eclipse Galileo(R3.5). The milestone of Eclipse release train has been already relatively stable for coding. Nobody will wait one year to taste the latest cool Eclipse functionalities by milestones:)
I spent about three non-fulltime days to review the SDT codes(and knowledges about the Scala and AspectJ). Finally I make the SDT avaiable under the 3.6M6[5], the latest milestone of Eclipse Helios. Cool!:) All of the basic functionalities work finely. Yeah, now the latest Scala 2.8, latest SDT(SVN) and the latest Eclipse 3.6 are in the same box now.
Some thoughts about the SDT as follows:
1. The current architecture of SDT is much nice.
This makes JDT infrastructure reusable and makes JDT integration natural. AOP/AspectJ is another cool technology. AOP/AspectJ was one of hottest topic in some days. After many new technlogies(like DI?) or frameworks appear, the people go to forgot this technology. The SDT demonstrate the power of AOP/AspectJ.
2. many codes highly depend on the Java reflection and Class.forName.
This is a little against to the OSGI best practice. And this cause one HyperlinkDetector bug when my porting. I suggest every man in the community read BJ Hargrave's "Why Class.forName sucks!" at EclipseCon 2008[6]. There are many reasons and ways to refute using the Class.forName. I rewrite the HyperlinkDetector related part in codes, and remove Class.forName statement. No problem here. (I will describe some details in my proposal.)
3. some aspects codes can be updated for new Equinox Apsects runtime.
I rewrite the aop.xml to mf.
4. the Java<->Scala collection interoperability is a little problem for newcomer.
I met some Map type checking problems when I overrided one class from one existed Java framework(Eclipse indeed). Scala has the concept of "Existential Types". I think I need more deeply lookups in this field to see what is the best practice. This is a language level problem indeed, not related to SDT. But this gives the Eclipse tooling more space to be improved as well:)
5. The build process of SDT can be simplified into small and easy pieces.
My original thought is that, bootstrapping the SDT form plain Eclipse enirvonment.That is, I can not use the SDT to build SDT at the very beginning. Miles has written one great document to show how to build the SDT[7]. But, frankly, I have not the courage to read through the document. This will be more serious for the Eclipse newcomers.
As my testing, the Eclipse PDE build tooling workflow fits the SDT as well in fact. (need a little trick:)) After some targeting and layouting, I even can run and debug the plugins in the workspace directly without any packaging, deploying or the prerequisite SDT installing step. This aslo makes SDT development's life easier.
6. naming of the version of scala-plugin-aspects is a little not consistent.
The version of bundle in the svn is 1.0.0. But the name of the scala-plugin-aspects jar is like "ch.epfl.lamp.sdt.aspects_2.8.0.r21304-b20100331125642.jar". It is the product of the ant build scripts. It is not an error strictly. However, I think it is not the best practice in Eclipse world. Just a note here:)
7. SDT in svn seem not much stable.
I meet several wired bugs, however they can not be repeatened...
Oh, here, I add one pciture to show the code completion is ready-for-use now:)
At the end of this blogging, some immediate suggestions for the current SDT, IMHO
1. re-arrange the build flow
Beside the above mentioned, SDT building artifacts can depend on the binary snapshots of latest Scala and Eclipse instance. Re-build sources of Scala is time-cost and not convenient/necessary in common cases.
2. "Release early, Release often"
align the head of SDT with the latest Eclipse and latest Scala(latest Scala is said to be used for SDT development, not SDT user)
The SDT is a tooling under the umbrella of Eclipse, so keeping its release rhythm synchronous with Eclipse(JDT) will a killing reason for the acceptance of SDT.
3. add the dist of standalone SDT installment package for downloading
The SDT needs some bootstrapping hackings in the configuration of Eclipse instance. Although it is easy for old men, it is not cheap for newcomer. I guess many people would not configure the SDT correctly. This would highly block the acceptance of the SDT and, of course, Scala itself.
I will contact Miles/scala-plugin team to see whether he/they like to accept my codes or some of it. Of course, it can be hoped that Scala will have one more bright future with the help of Eclipse:)
I have one little idea about the Scala language for e4, although I am afraid whether this will be supported by our voters. But I think I will start/push this idea some day. It will not be long...
I am planning to write more things about Scala and SDT recently. I wonder if there are some collaboration efforts about these in the community. If you are, let me know!:)
