Codegeneration 2008 is coming! And there'll be a lot of friends giving talks.
Peter and Frank are talking about model-driven Lego.
Markus will give two talks (Implementation Techniques for Domain-Specific Languages and Building Interpreters with EMF, Xtext and Scala).
I'll do two tutorials together with Arno:
One is called Concrete Syntaxes of DSLs and the other will give an Overview of Eclipse Modeling.
Finally on Friday, Karsten, Jan and me are holding a workshop about Using openArchitectureWare for M2M and M2T.
As this conference is specialized on code generation I'm looking forward to some interesting discussions. See you there!
Tuesday, June 10, 2008
Friday, May 16, 2008
Current Development at itemis Kiel
Just to give you a short update.
We've been working on a complete rework of Xtext for the last two weeks. While Jan and me have been developing the grammar language and witten the code generator, Peter and Dennis started to develop Xtext's new IDE framework.
Started with the new grammar language written in the new grammar language, we are now able to generate the parser, meta model and some other cool stuff from that description. Actually it took us some time to understand and manage the whole bootstrapping process. It 's never been so easy to shoot yourself in the foot... :-)
Currently we're working on a generic serialization mechanism. With this, one can modify instantiated models and write them back without loosing original layout information or comments.
Hopefully it won't be long until we can start reimplementing Xpand using the new framework (we yet have to add syntactic and semantic predicates to the grammar language in order to describe Xpand).
The current state can be checked out from eclipse's cvs : :pserver:anonymous@dev.eclipse.org:/cvsroot/modeling/org.eclipse.tmf/org.eclipse.xtext
Milestone planning can be found here : http://wiki.eclipse.org/Xtext_Project_Plan
Feedback or feature requests are of course welcome. Please use the developer mailing list for that : xtext-dev@eclipse.org
We've been working on a complete rework of Xtext for the last two weeks. While Jan and me have been developing the grammar language and witten the code generator, Peter and Dennis started to develop Xtext's new IDE framework.
Started with the new grammar language written in the new grammar language, we are now able to generate the parser, meta model and some other cool stuff from that description. Actually it took us some time to understand and manage the whole bootstrapping process. It 's never been so easy to shoot yourself in the foot... :-)
Currently we're working on a generic serialization mechanism. With this, one can modify instantiated models and write them back without loosing original layout information or comments.
Hopefully it won't be long until we can start reimplementing Xpand using the new framework (we yet have to add syntactic and semantic predicates to the grammar language in order to describe Xpand).
The current state can be checked out from eclipse's cvs : :pserver:anonymous@dev.eclipse.org:/cvsroot/modeling/org.eclipse.tmf/org.eclipse.xtext
Milestone planning can be found here : http://wiki.eclipse.org/Xtext_Project_Plan
Feedback or feature requests are of course welcome. Please use the developer mailing list for that : xtext-dev@eclipse.org
Labels:
oaw eclipse xtext
Wednesday, April 16, 2008
Game development with oAW
Last week Jens Wagener posted a small riddle in his blog. He stated that it is claimed that 98% of all people are incapable of solving it.
To put it short: I didn't solve it. (Thank God! I'm not that freaky ;-))
But hey, as we're currently testing our next release of openArchitectureWare, I thought I should give it a try and do something which helps solving it (our at least help to understand that it is really hard to solve ;-)) using oAW.
So first I wrote a DSL implemented in Xtext and then I specified the constraints outlined in the riddle using Check. (At this point you should have read Jens' post so you can understand what I'm talking about)
Using the DSL one writes the attributes (Color, Role, Pet, Language and Magazine) for the five houses down, one house per line. As I said the constraints outlined in the riddle are implemented using Check. So if there are any of theses constraints violated the editor provides the appropriate feedback.
The puzzle is solved when all markers have gone and there are no more wildcards 'X' in it.
This is a screenshot, of the "game" implemented in oAW:

So if you want to play around with it, just drop me a mail, and please don't come up with boring rule engine solutions ;-)
To put it short: I didn't solve it. (Thank God! I'm not that freaky ;-))
But hey, as we're currently testing our next release of openArchitectureWare, I thought I should give it a try and do something which helps solving it (our at least help to understand that it is really hard to solve ;-)) using oAW.
So first I wrote a DSL implemented in Xtext and then I specified the constraints outlined in the riddle using Check. (At this point you should have read Jens' post so you can understand what I'm talking about)
Using the DSL one writes the attributes (Color, Role, Pet, Language and Magazine) for the five houses down, one house per line. As I said the constraints outlined in the riddle are implemented using Check. So if there are any of theses constraints violated the editor provides the appropriate feedback.
The puzzle is solved when all markers have gone and there are no more wildcards 'X' in it.
This is a screenshot, of the "game" implemented in oAW:

So if you want to play around with it, just drop me a mail, and please don't come up with boring rule engine solutions ;-)
Friday, March 28, 2008
Initializers in Java
I'm working on slides about language features I'ld like to see in Java. One of them are initializers.
IMHO the lack of this features is the main reason why everybody uses XML. It's just ugly to construct object graphs in an imperative way. Usually such code looks like:
Would be much better if we could specify such a data structure like this:
Btw.: the same mechanism forks for collections of course:
I'ld still prefer "real" initializers and "real" collection literals, but all in all I think this seems to be a pretty useful idiom.
IMHO the lack of this features is the main reason why everybody uses XML. It's just ugly to construct object graphs in an imperative way. Usually such code looks like:
Customer c = new Customer();
c.setName("foobar");
c.setId(4711);
Address address = new Address();
address.setStreet("Schauenburgerstr. 116");
address.setZip("24118");
address.setCity("Kiel");
c.setAddress(address);
Order o1 = new Order();
o1.setArticleId(0815);
o1.setAmount(2);
c.addOrder(o1);
Would be much better if we could specify such a data structure like this:
Actually Java already supports this in some way (not ideal but IMHO better than doing it in a procedural manner). The following code is working Java code:
Customer c = new Customer {
name = "foobar",
id = 4711,
address = new Address {
street = "Schauenburgerstr. 116",
zip = "24118",
city = "Kiel",
},
orders = [new Order {
articleId = 0815;
amount = 2;
}]
};
Customer c = new Customer() {{
name = "foobar";
id = 4711;
address = new Address {{
street = "Schauenburgerstr. 116";
zip = "24118";
city = "Kiel";
}};
addOrder(new Order {{
articleId = 0815;
amount = 2;
}});
}};The code creates anonymous subclasses with initializers in it. However, as there are no such thing as properties for now you may want to replace the field access by getters and setters. Note that you don't have to make the fields public. So with a combination of getters and protected fields you get immutable types.Btw.: the same mechanism forks for collections of course:
Listl = new ArrayList () {{
add(new Order() {{
setName("stuff");
}});
add(new Order() {{
setName("foo");
setAmount(34);
}});
}};
I'ld still prefer "real" initializers and "real" collection literals, but all in all I think this seems to be a pretty useful idiom.
Wednesday, March 19, 2008
DSL development with MagicDraw
Ekkehard Gentz just showed me how to customize MagicDraw so that diagrams are really domain specific (no UML anymore). And it looks pretty cool. You can (and it seemed not to be too hard to do so) hide everything you don't want, extend and customize existing UML2 diagrams, etc.
In the end the modeling language ekkehard showed me didn't look like UML anymore. It was very simple and just showed the domain-specific concepts.
Unfortunately, if you go and process those models you are back in UML-hell again. But as all the customization information is modeled within the profile, one could transform a real domain-specific meta model (based on ecore of course) and a corresponing transformation from it. This would encapsulate the UML stuff completely.
Ekkehard will present his DSLs at this year's JAX during the DSL day.
In the end the modeling language ekkehard showed me didn't look like UML anymore. It was very simple and just showed the domain-specific concepts.
Unfortunately, if you go and process those models you are back in UML-hell again. But as all the customization information is modeled within the profile, one could transform a real domain-specific meta model (based on ecore of course) and a corresponing transformation from it. This would encapsulate the UML stuff completely.
Ekkehard will present his DSLs at this year's JAX during the DSL day.
Mega modeling at EclipseCon
Yesterday, at EclipseCon there was a BOF called "Mega Modeling Mania", which was pretty interesting. It started with a discussion whether UML is a good starting point for domain specific languages or not. Some people argued that with profiles you can do a lot of cool stuff, but the tools have failed. But in the end I think (and hope ;-)) most people were convinced that there is no point in starting with such a huge meta model with hundreds of concepts in it just to design a language having couple of them.
After that we were discussing whether Ecore is good enough for meta modeling. Some people would like to see CMOF concepts like "Package Merge" or "Associations". Actually, the absence of associations was one of things I really liked when I started to do meta modeling in Ecore. And until today I never missed them. I got the impression that it is more a matter of taste, and that people who meta model using graphical syntax and often use bidirectional relationships want to design them at once. So to me this sounds more like a tooling thing...
Package merge seems to be an application of model-to-model transformations. And because it's so specific it makes sense to have a DSL to describe those transformations. Markus did this when he developed XWeave. Actually Achim Demelt told me that XWeave is even more powerful than Package Merge. So why should we want to have that in the core, i.e. EMF? It's already there and you can use it if you want.
To me everything seemed unecessary complicated.
After that we were discussing whether Ecore is good enough for meta modeling. Some people would like to see CMOF concepts like "Package Merge" or "Associations". Actually, the absence of associations was one of things I really liked when I started to do meta modeling in Ecore. And until today I never missed them. I got the impression that it is more a matter of taste, and that people who meta model using graphical syntax and often use bidirectional relationships want to design them at once. So to me this sounds more like a tooling thing...
Package merge seems to be an application of model-to-model transformations. And because it's so specific it makes sense to have a DSL to describe those transformations. Markus did this when he developed XWeave. Actually Achim Demelt told me that XWeave is even more powerful than Package Merge. So why should we want to have that in the core, i.e. EMF? It's already there and you can use it if you want.
To me everything seemed unecessary complicated.
Sunday, March 02, 2008
EclipseCon 2008
Originally I didn't plan to attend this years' EclipseCon. But as we have big plans wrt our contributions to Eclipse Modeling, I decided to register myself in order to meet up with the other "Eclipse Modelers". Wolfgang will join as well.
Too bad I didn't submit some talks myself. Anyway, there are many interesting presentations to be visited. :-)
Too bad I didn't submit some talks myself. Anyway, there are many interesting presentations to be visited. :-)
Subscribe to:
Posts (Atom)