Currently I am working on a Java-to-.Net-Compiler. In addition to using
ANTLR and Micosoft's Phoenix framework I have to write a lot of C# code that lends itself to be generated.
Besides the need for a java grammar, which can be found here, we need an AST (Abstract Syntax Tree) to accomplish the semantic analysis. ANTLR offers an AST construction mechanism and generates an AST walker from a tree grammar. Basically the semantic analysis can be done solely with ANTLR. But, we are facing the challenge that each teammate needs to work with the AST and not everyone knows ANTLR. Thus we need an ANTLR independent AST.
The basis of our Java AST is the Eclipse JDT AST. My task is to implement the AST using C#. So, to implement means to copy since the JDT AST seems be a good model.
Did I say model? This sounds like feeding the JDT AST code into a code generator and letting the generator create the C# implementation.
Consequently we create a generator using openArchitectureWare that will take an UML2 class model, yes we decided to create an UML model of the AST ;), and generate C# classes.
I sat down with a teammate having C# experiences to create the generator templates for generating C# code.
Perfect! Now, our generator knows how to create C# classes .. and my teammate can go home :D. Furthermore we generate the basic visitor code for the AST from its model.
By the way .. a language grammar lends itself to automatic AST generation .. check out this paper.
Generators are knowledge containers!
steven
Mittwoch, 21. Januar 2009
Mittwoch, 6. August 2008
new oaw refactoring features
hello folks,
here are news from the oaw code frontier. I finished implementing the move extension and rename resource feature. the move extension feature was trickier than I thought .. you not only have to delete the extension from the source file and insert it into the target file, you have to check which namespace and extensions are required to get the moved extension running within the target xtend file and you have to determine where to insert each import. I had a lot of MalformedTreeExceptions meaning that the insertions of new imports overlap or the inserted extension is not inside the document range :@!
the tricky part of the calculation of the import offsets, the positions each import shall be inserted at, is the differentiation of different cases: is the target file empty, does it contain imports only, does it contain imports and extensions .. my code was covered with ugly nested, not understandable if-statements. to come up with this mess, I used the Strategy Pattern. the gof book says that it should be applied, if "different algorithms will be appropriate at different times". my base strategy class handles the common operations for the movement of an extension: remove the extension from the source file, update imports in all other files etc. it contains an abstract method called "createTargetFileChanges", which has to be overridden by subclasses implementing a different insertion strategy. according to the target file's state, an appropriate strategy is chosen. the code is much clearer now and new cases can be handled (added) easier.
A screencast showing the implemented features in action can be found here (.avi, 24.2 mb). the ui looks a little bit inconsistent and unhandy .. this is my next implementation step.
I could not work that much the last days, since I got my admission for the master program at the hasso-plattner-institute for software systems engineering (YESSSS!) and I had to do a lot of administrative stuff .. get rid of my old flat, leave my old university.
I planned to submit a paper about the modeling tool and distributed model simulation environment for information retrieval processes developed during my bachelor thesis to the mdsd today conference, but due to the upcoming gsoc deadline I will not have the time for writing one :(.
So, during the next days I will focus my implementation efforts on the ui aspects of the oaw refactoring feature and finally I will test it using a real life oaw project.
stay tuned!
steven
here are news from the oaw code frontier. I finished implementing the move extension and rename resource feature. the move extension feature was trickier than I thought .. you not only have to delete the extension from the source file and insert it into the target file, you have to check which namespace and extensions are required to get the moved extension running within the target xtend file and you have to determine where to insert each import. I had a lot of MalformedTreeExceptions meaning that the insertions of new imports overlap or the inserted extension is not inside the document range :@!
the tricky part of the calculation of the import offsets, the positions each import shall be inserted at, is the differentiation of different cases: is the target file empty, does it contain imports only, does it contain imports and extensions .. my code was covered with ugly nested, not understandable if-statements. to come up with this mess, I used the Strategy Pattern. the gof book says that it should be applied, if "different algorithms will be appropriate at different times". my base strategy class handles the common operations for the movement of an extension: remove the extension from the source file, update imports in all other files etc. it contains an abstract method called "createTargetFileChanges", which has to be overridden by subclasses implementing a different insertion strategy. according to the target file's state, an appropriate strategy is chosen. the code is much clearer now and new cases can be handled (added) easier.
A screencast showing the implemented features in action can be found here (.avi, 24.2 mb). the ui looks a little bit inconsistent and unhandy .. this is my next implementation step.
I could not work that much the last days, since I got my admission for the master program at the hasso-plattner-institute for software systems engineering (YESSSS!) and I had to do a lot of administrative stuff .. get rid of my old flat, leave my old university.
I planned to submit a paper about the modeling tool and distributed model simulation environment for information retrieval processes developed during my bachelor thesis to the mdsd today conference, but due to the upcoming gsoc deadline I will not have the time for writing one :(.
So, during the next days I will focus my implementation efforts on the ui aspects of the oaw refactoring feature and finally I will test it using a real life oaw project.
stay tuned!
steven
Donnerstag, 24. Juli 2008
Google Summer of Code (GSoC) 2008
Recently I am taking part in the GSoC. My job is to implement a refacoring feature for the MDA/MDD generator framework openArchitectureWare.
As you can see at the project's wiki site, I am almost finished implementing the required features.
I implemented a protoypic eclipse integration using the Language Toolkit (LTK) first. This was (and still is :)) a prototype, since I wanted to focus my efforts on the algorithms the whole refactoring is based on. The UI sugar comes later ;).
The implementation was easier than I thought. I became aquainted with the oAW source quickly, although it is commented very very raley :D. Very helpful were the Eclipse Type Hierarchy and Call Hierarchy. The Call Hierarchy is your perfect buddy for figuring out, how an API works.
A screencast showing the refactorings Rename Extension and Rename DEFINE can be found here (.flv 22.6 mb). Note that it is in german .. it was not meant to be published .. just a little status report for my gsoc mentor peter .. but if you cannot wait to see the refacorings in action, go for it! I will publish another screen cast with even more cool features the coming days.
I planned to finish the implementation of the refactoring algorithms by the end of this week.
Right now I am working on the Move Extension feature.
If this feature is implemented, I will take some days to clean up the code and make the abstractions clearer. Then I will start working on the user experience .. precondition checking, meaningful dialogs etc.
As you can see at the project's wiki site, I am almost finished implementing the required features.
I implemented a protoypic eclipse integration using the Language Toolkit (LTK) first. This was (and still is :)) a prototype, since I wanted to focus my efforts on the algorithms the whole refactoring is based on. The UI sugar comes later ;).
The implementation was easier than I thought. I became aquainted with the oAW source quickly, although it is commented very very raley :D. Very helpful were the Eclipse Type Hierarchy and Call Hierarchy. The Call Hierarchy is your perfect buddy for figuring out, how an API works.
A screencast showing the refactorings Rename Extension and Rename DEFINE can be found here (.flv 22.6 mb). Note that it is in german .. it was not meant to be published .. just a little status report for my gsoc mentor peter .. but if you cannot wait to see the refacorings in action, go for it! I will publish another screen cast with even more cool features the coming days.
I planned to finish the implementation of the refactoring algorithms by the end of this week.
Right now I am working on the Move Extension feature.
If this feature is implemented, I will take some days to clean up the code and make the abstractions clearer. Then I will start working on the user experience .. precondition checking, meaningful dialogs etc.
Abonnieren
Posts (Atom)