Gavin has just created a very nice set of screenshots picturing what our IDE is capable of. Have a look at it, a picture is worth a thousand words so imagine 13!

More info on the IDE

I also wanted to point out that with the release of Milestone 1, we have opened up the user centered forum on Google groups. Come join the fun and feel free to ask any questions, comments etc we want to know what you think and what we need to improve.

Happy holidays everyone :)

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.