Darker Theme 1.1: CSS Selector and OSGI Weaving

I am proud to announce Darker theme plugin 1.1 [1] for Eclipse 4.x platform. The reasons to be proud are two:

1. It gets 32 stars! As a one-day amateur work, I originally just try to experience and show the Eclipse 4 good stuffs[2]. But the community pushes the project forward. I decide to maintain the project constantly until we can get one better theme in the Eclipse itself of some time.
   
2. One weaving facility has been added into the Darker. The Darker is the first/only theme plugin to get over some styling defects shipped with the standard Eclipse instance. With this on the Darker, I can announce that it can do almost anything to challenge IDEA all round on the aesthetics of dark UI! (However, I truely have no time to make this done^_^)

To update minor version, Of course, it not only contains several bug fixings, but also introduces new things. One thing is,

• CSS selector.

The is an old pearl of e4/CSS works. But I am aware of its power until Lars[4]' pointing out in one issue[5]. In fact, the Eclipse 4 makes a hard work to provide one full CSS-spec-conformant styling engine.(At least, they want it to be full^_^) The CSS properties is just one aspect of CSS spec. The full story should includes the CSS selector. The CSS selector syntax provides a very powerful way to pick up some elements/objects to apply your style with.

Like Lars suggest "styling the Quick Access box"[5], this styling could be done by this following piece[7]:

Here, #SearchField Text is a traditional descendant selector syntax in CSS[8], which picks up the Text widget on the widget with ID #SearchField.

Simple and neat!

If you want to dig a little more, the Eclipse's wiki here[9] and the old Kai tutorial(in the bottom of that wiki page)[10] may be useful. The CSS styling engine gives more fun to Eclipse UI developers, although I am afraid that the layout problems seemly show barriers mentioned in that wike page in the meantime:)

The another new is just as I mentioned above,

• OSGI Weaving.

This weaving facility use the OSGI weaving functionality introduced in OSGI R4.3[6]. It allows load-time bytecode weaving, which can grant your some AOP capacities without huge dependencies.

It is a must. Because the investigation into another request[15] shows the SWT CLabel, as the background widget of stateline, forces a fixed OS related widget color as its foreground color from Control. That is, the CSS property setting is dumb here. Obvoiusly, the problem is systematic and  it can not be fixed in a near future of Eclipse development(or maybe never). I will feel very unhappy and stupid if I say to our guies that like "please wait, I have filed a bug entry against Eclipse". Then, the OSGI weaving comes to help.

Maybe you have known Equinox weaving[11] or AspectJ[12]. Yes, the OSGI weaving is a simplified version of Equinox weaving(but note that they are still different codes). AspectJ is an big animial. I have bitter memories about the AspectJ in my Scala IDE journey[13]:) One big headache is, that the Scala IDE users regularly report some update or functionality does not take effect in their environment. One reason is just due to the weaving configuration file have not been updated or picked up successfully by their Eclipse instances. I hope Iulian Dragos(leader of Scala IDE, Typesafe) has solved this problem:)

For one little theme plugin, I definitely do not want to take the nigtmare to the users. As a developer, we should be cautious to any addition. Then, the OSGI weaving is my choice.  The detail of implementation needs some ASM bytecode generation knowledge and provides the context based weaving(like cflow pointcut in AspectJ). To be honest, AspectJ syntax is simpler than direct bytecode manipulation if you have much complex context/condition combinations. I am just preparing a game-changing AOP kind of tool, but it needs time to come to the world:)

With correct weaving to SWT CLabel, Darker get a right white text color for the dark status line.


One tricky part I just to point out here, is the starting sequence of the plugins. The weave-working plugin should takes effect before the Eclipse UI things, more detailly here SWT CLabel, loaded into runtime. If you define this logics in your UI plugin, the order is definitly wrong. I solve this problem with two
simple points:

• separate the UI and weaving(non-UI) logics into different bundles;

• start the weaving bundle immediately after framework started.

The interesting thing is I use another new R4.3 "Start Level" API[4].(The other way may be to use kinds of hook[14], but I think it is just overkill.) It avoids any forced configuration modification for users in the Eclipse. It is a good practice.

OK, after this update, I plan to fully focus on my wonderful backend stuffs in my hobby time.
Stay tuned!


[1]:  https://github.com/jinmingjian/eclipse.themes.darker
[2]:  http://jmj-eclipse.blogspot.jp/2012/12/practices-for-eclipse-4-programming.html
[3]:  http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/hook/weaving/WeavingHook.html
[4]:  http://www.vogella.com
[5]:  https://github.com/jinmingjian/eclipse.themes.darker/issues/14
[6]:  http://wiki.osgi.org/wiki/Release_4.3
[7]:  https://gist.github.com/jinmingjian/5546115
[8]:  http://www.w3.org/TR/CSS21/selector.html#descendant-selectors
[9]:  http://wiki.eclipse.org/Eclipse4/RCP/CSS
[10]: http://www.toedter.com/blog/?p=477
[11]: http://eclipse.org/equinox/weaving
[12]: http://www.eclipse.org/aspectj
[13]: http://www.scala-lang.org/gsoc2010
[14]: http://wiki.eclipse.org/Adaptor_Hooks
[15]: https://github.com/jinmingjian/eclipse.themes.darker/issues/11

Practices for Eclipse 4 Programming Model

For "Eclipse 4 programming model"[1], I mean the way of how to program with the Eclipse 4.x platform, not the "Eclipse 4 application model"[2] itself, although they definitely have some close relations.

There are several tutorials[3] for the Eclipse 4 techologies. Here, I share some of practices in my last weekend theme plugin project[4] for making your projects more happy in Eclipse 4 platform. They may not be the best practices although I hope them are. So it is welcome to add criticisms and suggestions here:)

The biggest advantages of Eclipse 4 programming model, IMHO, is that:

• Dependency injection has been introduced;

We have had the Guice[5] from crazy Bob[6] for a long time. We found it is bettter to be adopted for container/framework-provided behaviors. This has been widely used in Java EE 6+ world. And now it comes to Eclipse planet!

• Many services have been extracted and become standard;

This is a absolute overhaul for Eclipse platform. This makes the consuming to Eclipse platform become much simple and relaxed.

Let me summarize somethings for you:

1. Consume the services by dependency injection way as possible.

For a self-explained instance,

Loading ....

Here, I get the IEclipsePreferences service.

Another way is to use the programatic API call. As you known, the service is verbose to use it correctly. The DI way makes your life easier!
[caveats/bugs]
Note, there are some caveats described here[9]. If you have problems in DI, please report it to Eclipse[10] and this helps Eclipse 4 to faster growth.

2. Consume plaform services as possible.

There are many very important services have been abstracted as the services of platform.

Loading ....

In this sinppet, Eclipse will provide four services for us. For example, the event service is powerful for general use. It, in fact, provides a mechanism for hooking/intercepting into the whole platform.

Loading ....

Here, I observe the theme change event for hooking editor-scoped preferences customization.

More detailed services could be seen in [7] and [8].
[caveats/bugs]
In my experiences with the event service, there is a bug for @EventTopic injection now, which, I found, has been discussed here[12]. That is, if you work under the Eclipse IDE environment, then the @EventTopic annotated method parameter will be injected with an org.eclipse.equinox.console.command.adapter.CommandProviderAdapter object. My workaround, shown above, is to use the event handler explicitly. But seemly you can use @Optional annotation with combination of @Inject as metioned in that discussion[12], although it is an e4 specific annontation and the semantics of it is not for the workaround obviously. However, finally, I prefer @EventTopic way in that reason shown in the following #3.

3. Injection to your objects in a full managed way is simple.

The truth here is, Eclipse 4 DI does not come into your world automatically. Then, how to link the Eclipse world with your business?
One workable way is to use IEclipseContext to bind you model. IEclipseContext is hierarchical. There are several kinds of IEclipseContext. Do not mess you up with the hierarchy! You can consult one Jonas's tutorial [11] for getting more basic infos. If you construct an RCP, then you may like to use this way.
For IDE managed enirvoment, like an Eclipse plugin, I recommend you to use the model processor extension as your entry point to the Eclipse 4 DI world.

Loading ....

You can extend the extension point org.eclipse.e4.workbench.model to enable it, like this:

Loading ....
It extension point is for the application model, in fact, as the document. But I think, it is simple and nice to use it with you business objects before we have a general DI hooking point if you want to forget the programatic injection.

[caveats/bugs]
Do not assume that a platform UI side services or objects could be injected and used here. For instance, you can not inject the IThemeEngine service in the model processor(IThemeEngine service is prepared after the processing of model). I guess it is intentional. There are still two ways for  this:

• use the EventHandler to watch the UI side topic exactly.
• use application model to bridge to your UI related POJOs. You can inject kinds of services here. This is just the way the e4 bundles selfs do their works.

4. Eclipse 4 Tooling is your friend.

It is not easy to consume the Eclipse 4 technologies now. There is a tooling project[13] come to help you: it includes the CSS Spy, CSS editor, application model editor and live editor.
For example, there are two ways to contribute/extend the application model:

• one is to change the model pragramatically(this is my favorite way).
• another is to use e4xmi model file. For this way, an application model editor is expected to have. Lars has provide the step-by-step guide[16].

[caveats/bugs]
The emf live editor is a little out-of-date in the weekend. I think it will be fixed soon. If you meet error log shows that one shell can not be found and injected. You can pull the source from[13] and annonated IServiceConstants.ACTIVE_SELECTION) to it. This is an intentional change documented in the[9].

As my evaluation to the Eclipse 4.3 nightly, it is good to consume now!
And we have got famous perfermance bugs fixed[14].
And I find the quick fixing for plugins is more intellisense[15].
And GTK3 is out for linux fans' testing(But it has an obvious bug now. So, I suggest you wait one or two milestone to test)[15].

As a plaform, Eclipse 4 has many many advantages to IDEA 12, IMHO. Do not hesitate to migrate to Eclipse 4! Help us to evolve!


References:
[1] http://www.eclipse.org/eclipse4/
[2] http://eclipsesource.com/blogs/2012/05/10/eclipse-4-final-sprint-part-1-the-e4-application-model/
[3] http://wiki.eclipse.org/Eclipse4/Tutorials
[4] https://github.com/jinmingjian/eclipse.themes.darker
[5] http://code.google.com/p/google-guice/
[6] http://blog.crazybob.org/
[7] http://wiki.eclipse.org/E4/Contexts
[8] http://wiki.eclipse.org/E4/EAS
[9] http://wiki.eclipse.org/Eclipse4/RCP/Dependency_Injection
[10] https://bugs.eclipse.org/bugs/
[11] http://eclipsesource.com/blogs/tutorials/eclipse-4-e4-tutorial-part-4-dependency-injection-basics/
[12] http://www.eclipse.org/forums/index.php/t/351144/
[13] http://git.eclipse.org/c/e4/org.eclipse.e4.tools.git/
[14] http://wiki.eclipse.org/Platform_UI/Juno_Performance_Investigation
[15] http://download.eclipse.org/eclipse/downloads/drops4/S-4.3M4-201212140730/news/
[16] http://www.vogella.com/articles/EclipseRCP/article.html

Eclipse Darker Theme and Sorry to Unexpected Blog Update

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 " [| new URI(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.


"Java Is Dead, Long Live Java!"


[1] https://github.com/jinmingjian/seed
[2] http://zarnekow.blogspot.jp/2012/12/fixed-checked-exceptions-xtend-way.html
[3] http://eblog.chrononsystems.com/dark-eclipse-theme
[4] https://bugs.eclipse.org/bugs/show_bug.cgi?id=367691
[5] https://github.com/jinmingjian/eclipse.themes.darker
[6] https://github.com/eclipse-color-theme
[7] http://wiki.eclipse.org/Eclipse4/RCP/Dependency_Injection

SEED(Scala Eclipse Effort for Development) 1.0M0 Reached

NOTE: the project has been stopped in that no enough time and my reflection to the language.

Firstly, thanks for your jumping into this entry. The SEED(Scala Eclipse Effort for Development) project is my current weekend project. The sources of SEED can be seen in the github: https://github.com/jinmingjian/seed.

table of contents

Motivation

M0: a clear architecture

Incubated in the bleeding edge

Answer to the community

What’s next

Invite to contribute

Self-introduction

​

Motivation

​What do you really matter when taking Scala into one large software production instead of Java? the IDE tooling? Yes, the professional Scala Developers need the professional tools to hack engineering. Because Java IDE have set a high bar to the user experience of language IDE, it is hard to think the developers and especially the enterprises will be comfortable with changing into a much worse coding environment although the language itself seem better.

The basic motivation is to drive the design and implementation of SEED to match the requirements of the professional Scala Developers.

​

M0: a clear architecture

The basic philosophy of the SEED is :

1. stable user experiences is first

2. reflect the language characteristics and merits of Scala itself

3. do not depend on uncontrolled sources;

4. invite community to contribute

The overall architecture and concerns could be seen as follow picture:

Then, what can we see in the SEED m0? Compare two snapshots between the SEED m0 and the Scala-IDE(one version in July, 2011):

​

from Scala-IDE

​

from SEED

from the snapshots, it can been seen that:

1. the packagings are mapped usefully

it will provide the viewpoint of flattening the packaging(collapse empty packagings)

2. method member's signature only displays the type of parameter, some member's type is missing

this is by design almostly , except the main(Array) is not full displayed for the unfinished type model. It is decided that the SEED Scala model scanner will not do any inference than the simple syntax scanning. Then, how to get the type infos? The type infos will be decorated in the later when it is resovled by the nsc. The Scala model scanner is not replacement for NSC. It collaborates with NSC.

3. ':', '=' are highlighted as the keyword

these symbols are reserved words explicitly by the Scala specification[1]. As this is a little different to the Java, the SEED will provide a preferences to configure this in the future.

4. expression have been addressed

this construct is quasi-unique for Scala(but similar to the initialization block ), like the self type, early definition, class parameters, type definition... The SEED will provide the outline item for visualizing them. However, as the reason that I mentioned in one previous blog entry, it is decided that the SEED Scala Model scanner will not do any inference than the simple syntax scanning. So, the Expression, as one kind of template statement, will be displayed as {...}, FYI.

​

The internal thought behind the snapshot is:

1. the SEED have a lightweight Scala Model system which services for the presentation layer ​and kept in the memory with editor.

2. Scala NSC will provide the full semantics and AST of Scala sources as a background service;

3. Scalal NSC nuts (like AST...) considered heavyweight will be discarded by UI immediately after used.(however, it has not right to ask the NSC to do this as well)

For the time limitation, I do not deep into more aspects of design. However, heavy investigations and works have been done in the m0. I believe the architecture have given a solid basic editing exprience to the SEED, and will pave the way for cool features like reference navigation in the next.

In m0, the SEED goes beyond the editor.

​

Incubated in the bleeding edge

This is long topic for the SEED. I pick up some interestings for showing. The SEED adopts two techniques in e4: EMF and DI(Dependency Injection).

​These two techniques are just the basestones of the coming Eclipse 4.2 release("Juno") . However, they are not very known even by Eclipse platform developers.

EMF is one effective modeling framework in fact. The big picture of the SEED Scala Model is here:

​​It shows a early version of model structure in that I drop the ecore graphical tooling later for the obvious sync problem. And the type subsystem is still in the changing.

​EMF really makes the SEED deveoplement easier. With it, the SEED model elmenets have the capabilities of notification and navigation when it borns. And I have done the ContentProvider for thirty model elements in thirty lines by just using the EMF reflection. And I predicate that more emf based techniques would contribute to the SEED. This is just the trend shown in Eclipse Juno.

​

The other technique - e4 DI(Dependency Injection), is relatively new topic in the Eclipse world.

The OSGI DS spec trys to remove the boilerplate codes in the services' publishing/referencing in the form of one component model. However, the component model itself introduces some new boilerplates. One problem is, you need to reference the service in one component in the DS. Even through one component is like one POJO in appearance, its cost is far from that of POJO in the bottom. The worse thing is, the component instantiation is under the control of (DS) framework. If some components need to be instantiated by hand or by other frameworks, the own business object can not consume the service directly. It needs to design kinds of auxiliary callback structures to expose the service to the business object(or some services may be designed with "Whiteboard" pattern). (This is by my understanding to the DS spec in the early years. If some one think it is not true, please correct me. I will clear it for DS^_^) The final result is that, we pusblish the serivce in the DS-style, but return to consume it in the ServiceTracker-style in our own business object.

​The e4 DI is one technique which could solve all these problem . We can use the e4 DI to inject the service directly. The contexts should/can maintain the boiledplates for service consumers.

For the Eclipse 4.2's ugly face and a little bad experiences, I still use the Eclipse 3.8 milestone. After some investigation into sources, I have successfully integrate the e4 DI in the 3.8 enviroment. There are some tricks for doing this. However, still for the time limitation, I can write another blog to address these tricks. If you want to do similar things just now, you can consult the usage of ILexingService in the com.github.seed.core here.

In a word, the SEED, as the Eclipse-based IDE, have aligned with the newest Eclipse techniques. Futhermore, the SEED will follow the rhythm of Eclipse, but not the Scala(however, the internal of SEED will depends on the svn head of Scala after bootstrap). The SEED definitely should support to choose your favorite Scala system library(I leave the Scala team to guarantee the compatibility^_^). the SEED R1.0 will come soon after the Eclipse R4.2/3.8. I will definitely consider the compatibility to the Eclipse platform. As for the clear base, the SEED may support the plaftform from R3.6 to R4.2 if it is really needed:)

There are many other internal designs and implementations in the SEED not mentioned above. such as how about the Scala Model Scanner, the source Lexer. Some of them are in the changing. The key here is that, all designs and implementations have been thought to conform to the basic philosophy mentioned above. For the limitation of both time and space, it is hoped it could be covered in the future.

What’s next

Recent milestone concerns:

M1 theme: bootstrapping

type system(index system)

nsc integration(I am planning to do a tweek for NSC to make the integration more more natively)

build system(fsc?/sbt?)

M2 theme: self-hosted

binary class viewer

preference to switch your own scala system library

classpath container support

SEED codes wiill switch to Scala(eat my own dog food)

M3-R1.0:

performance

preferences

customized CNF-based "Scala Package" view

basic mixed Java/Scala integration

basic refactoring support(rename)

my implicit highlighting work

...

any contributions

Answer to the community

I may answer one question to the community: why not contribute to the Scala-IDE project?

The answer is: Simply, I can not agree on the base architecture of the Scala-IDE. In fact, the two projects has much different architectures. SEED is a clean-room implementation, even for its icons. All of my ideas are hard to be implemented in the Scala-IDE. Workarounds may exist, but it is definitely ugly. The tooling for Scala should originally be one straight, happy, rhythmical work for developer. But now it becomes the headaches of some hardworker. However, in the future, it could be possible to collaborate if we reach an agreement on the base. I hope the SEED would become a seed for one great Scala IDE.

Invite to contribute

For the clear architecture, it is easy and fun to contribute to SEED. The informal prerequisite is the basic knowledge of Java, Scala, Eclipse and/or OSGI. But you can contribute anything even if you are not a programmer.

Let's say about the feature of "Mark Occurrences", it could be implemented by adding a new token based occurrences detection service (like IFetchOccurrencesService) by consuming the LexingService as the backend. As for the frontend(UI), you can mock my token highlighting logic firstly. Or it is better to abstract one token based rendering service for all kinds of things in the future. It may cost hours or days which depends on what you want to do and how much you are familiar with the Eclipse platform.

I will be very glad to see your name here. Or you like to fork or clone to play the codes first.

Self-introduction

This last section in this blog entry seem odd. I hope this advertisement will not disturb you. I have written a blog entry about myself and my techinical road here in July.

I have touched several startups for some Scala opportunities. It is interesting that the number of scala opportunities is much less than ruby/python/javascript in the U.S..

However, it is found that the main problem for me is that the foreign H1B sponsorship is considered heavy for the startup. So, I decide to widen the seeking range to Eclipse/OSGI(or Java?) now.

If you read here and your employer are seeking Scala/Eclipse/OSGI work and your employer supports the foreign H1B sponsorship, please help to give me a recommendation if you think I am qualified for your works. What I can promise is, if it fail to apply for the work permit, I can contribute to one project your company pointing in my two month's weekends to compensate your application cost! My current work is about the web serivce component development for an well-known application server. In fact, I have done many backend works as well. For the sake of privacy, we can talk about more privately. I gratefully thank for any opportunities on behalf of my family.

I will pause the SEED development in the following several weekends for fully seeking the new opportunities. But I think it will be finalized quickly. I will be back soon.

Finally, as a rule, the SEED 1.0 should have a codename. I decide to call the R1.0 as the "SuperDaddy"(under the umbrella of Eclipse "Juno"^_^) to acknowledge my wife and daughter's support in these weekends. I love you!

Implicits, Scala-IDE and my mid GSOC evaluation

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

 

Align the Scala Development Tools with the Bleeding Edge of Eclip

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!:)

[1] http://socghop.appspot.com/

[2] http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#graduate

[3] http://www.scala-lang.org/node/94

[4] http://old.nabble.com/IntelliJ-and-Eclipse-Plugins---Scala-2.8.0.Beta1-td28035792.html

[5] http://download.eclipse.org/eclipse/downloads/drops/S-3.6M6-201003121448/index.php

[6] http://www.eclipsecon.org/2008/?page=sub/&id=377

[7] http://lampsvn.epfl.ch/trac/scala/wiki/EclipsePlugin#CreatingAndSubmittingPatches