Code Formatting by Example

15. December, 2017

People are starting to use Machine Learning to write better code.

One example is code formatting. Instead of painstakingly writing a parser and then rules which are to be applied to each node of the Abstract Syntax Tree (AST), the guys from Codebuff are using the “learn by example approach”. Just feed Codebuff with a couple of examples and it will learn to apply those implied rules to source code.

If you find something that looks bad, you don’t have to dig through dozens of pages of code formatter options or code formatter config files, just add more examples.

If you’re using Xtext, you can use the tool to write code formatters for you DSL: “Machine Learning Formatting with Xtext“

Leave a Comment » | Software | Tagged: , , | Permalink
Posted by digulla

Eclipse Finance Day 2014: Automating user interface tests with behavior-driven development (BDD)

3. November, 2014

The last two talks were about testing.

“Automating user interface tests with behavior-driven development (BDD)” by Jose Badeau and Dietmar Stoll used an Xtext-based DSL to connect requirements, wireframes and test descriptions so they can validate each other. In the example, they removed a field from the wireframe mockup and the Eclipse editor for the test cases showed errors where they were used in the DSL.

The demo showed once again how much power lies in connecting information from different sources. If you remember, then this was the key feature which set Eclipse apart from all the other Java tools in 2001: It could bring you to the place where something was defined by pressing F3 or Ctrl+Click. If you changed one file, it would instantly compile all the other files and show you any problems it would find. Having a tool which actively searches for problems saved and still saves a lot of time.

 

Leave a Comment » | Conference, Software | Tagged: , , , | Permalink
Posted by digulla

Eclipse Finance Day 2014: Modernisation of Software

3. November, 2014

In his talk “Modernisation of Software“, Georg Pietrek of itemis AG shows the key points when you need to modernize software (= make large, disruptive changes). Karsten Thoms then demonstrated those points in a practical example in his talk “Model based migration of Oracle Forms applications”.

  1. Analyze the old code
  2. Create DSLs that describe the pieces of the old code which you want to migrate
  3. Write a small demo what the new app should look like
  4. Develop code generators which take the DSLs to generate the demo

After you have proven that you have covered all important bases this way, you can expand the DSLs (or rather write more code using the DSLs) to migrate the rest of the old code. You can reuse the small demo from step #3 to test any changes to the DSLs and code generators on a small code base.

The big advantage of using models to modernize is that manual migration often runs into a death spiral: Developers start with little knowledge (especially, when the original developers aren’t around anymore). They learn as they migrate code. But as this process advances, it becomes more and more expensive to fix early mistakes. With the model driven approach, you fix the bug in the code generator and thousands of lines of code are corrected at the push of a button. This means you can make abstraction work in your favor.

The advantage over exiting tools to migrate an old code base is that the model based approach is more flexible.

A quote from the talk: “Software doesn’t rot but it’s environment changes.” Eventually, the software no longer meets the needs.

Leave a Comment » | Conference, Software | Tagged: , , , | Permalink
Posted by digulla

Eclipse Finance Day 2014: Sirius – create your own graphical designers for IT and EA

3. November, 2014

Etienne Juliot from Obeo, demonstrated Sirius, a tool to create your own modeling tools in Eclipse. Under the hood, the new UI editors work on EMF models. If you struggled with EMF (and it’s … uh … “basic” set of default editors), you should definitely have a look.

The tools also work well with Xtext, so you have a mix of textual (detail) and graphical editors (overview) in your product. The magic sauce in EMF makes sure that updates on one side propagate to the other.

Leave a Comment » | Conference, Software | Tagged: , , , , | Permalink
Posted by digulla

Upgrading from Xtext 2.3 to 2.4

16. January, 2014

This is a summary of the steps to upgrade from Xtext 2.3 to 2.4:

  • The plugin org.eclipse.xtext.xtend2.lib has been renamed to org.eclipse.xtend2.lib
  • In the *.mwe2 file of your DSL, replace EcoreGeneratorFragment with EMFGeneratorFragment
  • Run the *.mwe2 script to regenerate the whole project
  • Merge plugin.xml_gen and plugin.xml

Leave a Comment » | Software | Tagged: , | Permalink
Posted by digulla

TNBT: Documentation Sucks

11. October, 2012

Documentation is the unloved step-mother of software development: Nobody likes it.

On the writing side, documentation is either considered a waste of time:

  • I could write code in that time
  • It won’t be valid anymore after the code changes tomorrow, anyway
  • There is no way to make sure you can trust documentation
  • Stringing sentences is hard work, especially when you want to make them easy to read, understand and interesting to follow.
  • It’s hard to connect code samples with documentation
  • If I describe too many details, readers will be bored. If I omit too many, they will be confused. There is no way to know which level of detail is good.

On the reading side, it’s a waste of time:

  • I need to solve a problem, I don’t have time to search in a huge dump of text
  • If the author doesn’t trust the documentation, how can I?
  • It will contain too many details that I already know and omit too many facts that I need to understand what is going on.

The core of the issue is that documentation and code are two different things. Documentation is, by nature, abstract. It’s at least one step removed from the solution.

Does it have to be that way?

I hope, with new technologies like Xtext or JetBrains’ Meta Programming System, we will eventually be able to turn documentation into code.

So instead of writing hundreds of lines of code to open a window, give it a size, make sure it remembers its size and position, etc., we could write:

Allow the user to edit a Customer object which has properties from foaf:Person and one or more addresses.

Users can search for Customer objects by any of the name fields.

Note that the links are part of the documentation and the code; the underlying code generator should follow them and examine the code/documentation on the other side.

Related Articles:

Leave a Comment » | Software | Tagged: , , , | Permalink
Posted by digulla

Could not find a GenModel for EPackage ‘http://www.eclipse.org/xtext/common/JavaVMTypes’

20. September, 2012

If you added

import "http://www.eclipse.org/xtext/common/JavaVMTypes" as jvmTypes

to your DSL and now you get this error:

java.lang.RuntimeException: Could not find a GenModel for EPackage 'http://www.eclipse.org/xtext/common/JavaVMTypes'
If the missing GenModel has been generated via EcoreGeneratorFragment make sure to run it first in the workflow.
If you have a *.genmodel-file, make sure to register it via StandaloneSetup.registerGenModelFile(String)
	at org.eclipse.xtext.generator.GenModelAccess.getGenModelResource(GenModelAccess.java:119)
	at org.eclipse.xtext.generator.ecore.EcoreGeneratorFragment.findEPackagesInGenPackages(EcoreGeneratorFragment.java:347)

then add this line

registerGenModelFile = "platform:/resource/org.eclipse.xtext.common.types/model/JavaVMTypes.genmodel"

to the “bean” block in your MWE2 workflow. It should then look like this:

Workflow {
    bean = StandaloneSetup {
        scanClassPath = true
        platformUri = "${runtimeProject}/.."
		registerGenModelFile = "platform:/resource/org.eclipse.xtext.common.types/model/JavaVMTypes.genmodel"
    }

Leave a Comment » | Software | Tagged: , | Permalink
Posted by digulla

Jazoon 2011, Day 1 – Cross-Platform Mobile Development with Eclipse – Heiko Behrens and Peter Friese

26. June, 2011

Cross-Platform Mobile Development with Eclipse – Heiko Behrens and Peter Friese

The duo showed a nice example how a DSL (created with Xtext, of course) can be used to generate code for an iPhone app, an Android app, a standard Java web app and an app for the Google App Engine from the same source.

The point here is not to emulate all features on each platform but to fall back to sensible replacements if a platform doesn’t support something.

It also showed the blazing speed of the new Xtext 2 code generator.

Links:

1 Comment | Conference | Tagged: , , , , , , | Permalink
Posted by digulla

Solutions for Common Xtext Problems

10. June, 2011

Jens von Pilgrim compiled an excellent list of common errors when using Xtext 1 in his blog: When your MWE2 workflow is not working…

Leave a Comment » | Software | Tagged: , | Permalink
Posted by digulla

Spray Graphiti – Xtext for the Eyes

30. May, 2011

I’ve come to love Xtext. It’s powerful out of the box, simple enough to grasp and the rough edges cut you just once (i.e. after you put tape over them, the hurting stops).

But sometimes, a picture says more than a thousand words. Unfortunately, creating a graphical editor is still a daunting task. Which probably explains why most graphical editors aren’t worth the shadow the mouse pointer casts over them.

If we only had a compact language to define UI editors … but wait, we have. Or rather we could have with a bit of help with Xtext.

Welcome project Spray. Spray is a DSL to create Graphiti editors.

Leave a Comment » | Software | Tagged: , , , , , , | Permalink
Posted by digulla

« Previous Entries
%d bloggers like this: