Team blog

Ceylon after two weeks

This has been almost two weeks since Stephane and I have done our presentation at Devoxx and revealed the Ceylon community. Let me give you some feedback.

IDE

Our IDE sneak preview has been very popular. Not surprising since it let's you play with Ceylon right from your comfy Eclipse seat in five minutes.

Many thanks to our early testers for finding a few bugs including the infamous issue 107 which basically was shutting down Eclipse if the language module was not installed (yep the System.exit(1) was mine :) ).

All of this is now fixed and David has pushed a new IDE release with many improvements. Make sure to update the Eclipse plugin (Help->Check for updates).

Community

We are very happy with how the community is shaping up. We had a few interesting and engaging discussions as well as contributions. Just one example: Visibility model ; we have been discussing how to improveupon our visibility model (the shared keyword).

That's exactly how we wanted it to be, so keep coming :) If you are interested, Gavin marks discussions as request for feedback in our issue tracker.

Or simply join our development mailing list. We have recently discussed Java interop, killer features that should or should not be added and more.

Website

The website had a few glitches including an faulty atom feed. This is now fixed. We took the opportunity to improve ceylondoc (the equivalent of javadoc). You can now search for a type, attribute, method name etc right from the page. Thanks Stef for the jQuery wizardry.

That's all forks, if you are interested, please join the fun and come contribute by talking or by coding.

First community Feedback Requests

A Feedback Request is our new way of asking for input from the community on design issues that we're uncertain about. I created the first two feeback requests over the weekend:

  1. Syntax for inline functions and objects
  2. Alternate visibility model

Please join in the discussions! The decisions we make on these issues will be incorporated into the Milestone 2 release.

Welcome to ceylon-lang.org!

Today, we're proud to announce a dedicated Ceylon community, ceylon-lang.org. Simultaneously, we're opening up access to our git repositories and even providing a special pre-release build of the Ceylon IDE, only for the truly adventurous.

We're not yet quite ready to release Milestone 1, due to a number of unsolved bugs and integration issues. But we're working really hard to get these sorted out!

I'm taking this opportunity to thank Red Hat's James Cobb for the web design, Emmanuel Bernard for setting up the infrastructure behind this site, and Tom Bentley for helping with much of the content. And, while I'm mentioning people's names, I would also like to thank new hires Stef Épardaud and Tako Schotanus for all the work they did getting the compiler up and running as volunteer contributors before coming on board, and David Festal from SERLI for making the IDE happen.

If you're interested in contributing to Ceylon, now is a really great time to get involved!

Update on the debugging support in the IDE

Basic support for debugging ceylon programs is now available in the IDE plugin on GitHub.

Description of available support

How to install

From the sources

For those who already have the ceylon-ide-eclipse plugin project in the Eclipse workspace, just pull the last GitHub version and run with a "Eclipse Application" launch configuration.

From the update site

  • From within Eclipse, install or update the Ceylon plugin through the Ceylon Update Site : http://ceylon-lang.org/eclipse/updatesite/
  • Restart Eclipse
  • You should be able to use basic debugging support

How to use it

Start debugging a ceylon program

In order to debug a ceylon program, just do the following : - When editing a ceylon source file, you can add a breakpoint by double-clicking in the editor ruler. - In the Package Explorer, select the ceylon source file. - In the contextual menu, start the following command : Debug as -> Ceylon Application - If more than one top-level definition is available in the source file, a dialog allows you to choose the one you want to debug. - The program is then started and paused at the first breakpoint. - You can then use the Step into, Step over and Step out or Resume buttons, just as with JDT debugging.

Step Filtering

In order to avoid going into unwanted stackframes when stepping into the code, you should activate debug step filtering in the Eclipse general preferences : Java -> Debug -> Step Filtering

Select all the proposed filters, as well as the simple getters and setters.

Variables View

The Variables is available in the Debug perspective, and shows the variables in the current stack frame context. variables are shown in their Java flavour (that means how they had been translated to Java). However thanks to the Ceylon-Java mapping, the variable representation of objects is very near to what is declared in the ceylon file.

For the moment, the Change value contextual command only works for simple types such as String or numeric values.

Breakpoints View

The Breakpoints view is also available and, for each breakpoint, allows enabling/disable it, but also setting a hit count. However do to the type of breakpoint used internally, it is not possible to add a breakpoint condition for the moment.

Known problems and limitations

Line problems

It might happen that when paused on a specific stack frame, the instruction pointer is not positioned on the right corresponding line in the ceylon source file. This is due to wrong line information in the class files generated by the ceylon compiler. Such errors should be reported with the corresponding source code and erroneous lines, so that the corresponding problem in the compiler code would be corrected and additional tests implemented.

Limitations

  • In the Variables view, the Open Declared Type and Open Declared Type Hierarchy contextual commands don't work, since for now the variables are seen as pure Java variables. Thus the source file of the Ceylon objects cannot be found. This will be solved once the plugin is able to support a true Ceylon-specific debug model (see next section).
  • Also in the Variables view, the Watch contextual command doesn't work : the Watches is opened but the expressions are not successfully parsed and evaluated. This will also require some overloading of the standard JDT Debug support.

Next steps

  • Extend/override JDT debug model in order to :
    • add ceylon-specific step filters (e.g. for attribute generated getters, etc ...),
    • define ceytlon-specific lin-breakpoints that allow advanced usages such as conditions,
    • manage variables and values and type references with the ceylon semantics,
    • etc ...
  • Provide a more powerful breakpoint support (conditions, watchpoints, etc ...)
  • Override the expression management to support ceylon code parsing/evaluation
  • Allow ceylon code snippets in breakpoint cnditions for example
  • etc ...

Some (many) of those next steps, which mainly consist in extending/overriding existing implementations in JDT debug plugin, imply building a Ceylon-specific logical core resource model, by extending the JDT core model.

Wire the site with spec and ceylondoc

The site now integrates the specification and the ceylondoc for ceylon.language.

How to build the integrated site

Run ./build-site.sh from the root of your ceylon-lang.org repository. This will

  • clone or refresh the ceylon-spec, ceylon.language and ceylon-compiler repos
  • build the documentation as of the latest in master
  • push the bits in the generated directory of awestruct

How to reference the spec or the ceylondoc

This information is out dated and has changed in later versions of the website, check out our how to edit a page section.

If you want to point the spec to a user in the site, point to /documentation/1.0/spec. This page show the spec in HTML, HTML in single page and PDF.

If you want to point to a specific paragraph in the spec, use the variable site.urls.spec.current and the anchor to the paragraph in the spec.

eg This is a [pointer to the spec](#{site.urls.spec}#anchor-in-spec).

That means the specification anchors should be stable.

Likewise, to point to a ceylondoc entry, use the variable site.urls.apidocs.

[Doc for Comparable](#{site.urls.apidoc_current}/ceylon/language/Comparable.html)

By using these placeholders, we will be able to move the spec or ceylondoc to other places. Note that /documentation/1.0/api page is pretty useless as it is but should be fixed in ceylondoc.