Dear all,
currently, we have the following issues for 0.5.3 open:
TTC-137 Add more complex tests for inline template parameter TTC-142 Allow merge refactoring to leave originals as delegates TTC-138 Add tests for all refactoring using templates involving record of/set of/type record length TTC-98 Create tests for ASTUtil utility functions. TTC-46 Refactoring: Undo across all effected files? TTC-96 Add tests for Merge Template refactoring
I like to take some load from Dominic and thus have question concerning assignment of the following issues:
TTC-142 is currently assigned to Dominic: Do you intend to work on it or shall I investigate it (and you possibly implement it lateron)? TTC-98 is currently assigned to Dominic: Do you intend to implement the tests? TTC-46 is currently assigned to Dominic: Do you intend to tackle it or shall we assign it to Martin?
For the remaing ones (adding more JUnit tests), I feel responsible. (Even though I am currently a bit busy.)
Furthermore, all developers are invited to close those bugs marked as fixed by other ones (or respectively re-open if necessary).
Best regards, Helmut
On Wed, Jun 21, 2006 at 12:45:07PM +0200, Helmut Neukirchen wrote:
Dear all,
currently, we have the following issues for 0.5.3 open:
TTC-137 Add more complex tests for inline template parameter TTC-142 Allow merge refactoring to leave originals as delegates TTC-138 Add tests for all refactoring using templates involving record of/set of/type record length TTC-98 Create tests for ASTUtil utility functions. TTC-46 Refactoring: Undo across all effected files? TTC-96 Add tests for Merge Template refactoring
I like to take some load from Dominic and thus have question concerning assignment of the following issues:
TTC-142 is currently assigned to Dominic: Do you intend to work on it or shall I investigate it (and you possibly implement it lateron)? TTC-98 is currently assigned to Dominic: Do you intend to implement the tests? TTC-46 is currently assigned to Dominic: Do you intend to tackle it or shall we assign it to Martin?
Unfortunately I have been taken off TRex development at the moment, as other high priority tasks have come in, and so I won't be able to work on TRex for the near future. However, in response to your questions:
TTC-142: this would be relatively simple to implement as it merely requires that when the appropriate wizard checkbox has been ticked the removeTemplate method is switched for a refactoring that replaces the templatebody with a reference to the new template (instead of removing the declaration). However, as this is more of an enhancement rather than a bugfix I suggest delaying it until 0.6.0.
TTC-98: as mentioned above I won't be able to do these for the moment. However, I do not consider them mission critical, so they can probably be pushed back to 0.6.0 also.
TTC-46: I did spend a few days looking at this but was unable to find why our refactoring undoes were not being grouped into a single undo entry. I examined the CDT source (whose rename refactoring was built up exactly the same as ours) and spoke with CDT developers whose main response was '...it just works - the undo comes for free, we didn't do anything...'. I'm not sure whether it may require changes to TTCN3Editor or some seemingly un-related class in order to acquire the grouping. Feel free to re-assign to Martin, I will be interested to hear about any progress.
Best regards, Dominic
Dominic Evans wrote:
Unfortunately I have been taken off TRex development at the moment, as other high priority tasks have come in, and so I won't be able to work on TRex for the near future. However, in response to your questions:
Thanks for your response. Hopefully, it will be decided to put you back into TRex development in future!
All the best, Helmut
Dear TRex developers,
since the manual compilation of the TRex ANTLR grammars was bugging everyone, i took the liberty to make an internal branch of AntlrEclipse (that i call the 5.0 branch just to differentiate from the official 4.0 line). This branch introduces the following major changes to the plugin:
- integration of an antlr pretty printer - intelligent compilation order of antlr grammars
so as you might guess, compiling the trex grammars through the context menu is hopefully not necessary anymore and should be handled by our intelligent antlr grammar dependency respecting builder.
the subversion repository of this branch can be found here:
http://www.trex.informatik.uni-goettingen.de/svn/antlreclipse/
and the most recent and currently (hopefully) working build can be downloaded at
http://www.trex.informatik.uni-goettingen.de/antlreclipse/
just download the two jar files and place them in your eclipse plugins directory without deleting any old ones. this should upgrade your antlreclipse version to 5.02.
then update your svn trunk working copy. the antlreclipse natures have been reenabled and the TTCN3ParserTokenTypes.txt have been removed from the controlflowanalysis and sizemetrics plugin, because they are automatically copied from the originating parser. hence, for developers working on these plugins or having these checked out _must_ use this updated antlreclipse version from now on. otherwise, the grammars won't compile properly anymore.
although the sourcecode is publicly accessible, i prefer to keep this branch internal to TRex developers at the moment as i'm not sure how the antlreclipse authors feel about a branch. hence, there won't be any announcements outside the TRex community.
please feel free to ask any questions!
there were still a few small bugs in 5.02 which could prevent an automatic build. please download 5.03 from the same location.
Benjamin Zeiss wrote:
Dear TRex developers,
since the manual compilation of the TRex ANTLR grammars was bugging everyone, i took the liberty to make an internal branch of AntlrEclipse (that i call the 5.0 branch just to differentiate from the official 4.0 line). This branch introduces the following major changes to the plugin:
- integration of an antlr pretty printer
- intelligent compilation order of antlr grammars
so as you might guess, compiling the trex grammars through the context menu is hopefully not necessary anymore and should be handled by our intelligent antlr grammar dependency respecting builder.
the subversion repository of this branch can be found here:
http://www.trex.informatik.uni-goettingen.de/svn/antlreclipse/
and the most recent and currently (hopefully) working build can be downloaded at
http://www.trex.informatik.uni-goettingen.de/antlreclipse/
just download the two jar files and place them in your eclipse plugins directory without deleting any old ones. this should upgrade your antlreclipse version to 5.02.
then update your svn trunk working copy. the antlreclipse natures have been reenabled and the TTCN3ParserTokenTypes.txt have been removed from the controlflowanalysis and sizemetrics plugin, because they are automatically copied from the originating parser. hence, for developers working on these plugins or having these checked out _must_ use this updated antlreclipse version from now on. otherwise, the grammars won't compile properly anymore.
although the sourcecode is publicly accessible, i prefer to keep this branch internal to TRex developers at the moment as i'm not sure how the antlreclipse authors feel about a branch. hence, there won't be any announcements outside the TRex community.
please feel free to ask any questions!
On Mon, Jul 03, 2006 at 05:41:39PM +0200, Benjamin Zeiss wrote:
Dear TRex developers,
since the manual compilation of the TRex ANTLR grammars was bugging everyone, i took the liberty to make an internal branch of AntlrEclipse (that i call the 5.0 branch just to differentiate from the official 4.0 line). This branch introduces the following major changes to the plugin:
- integration of an antlr pretty printer
- intelligent compilation order of antlr grammars
so as you might guess, compiling the trex grammars through the context menu is hopefully not necessary anymore and should be handled by our intelligent antlr grammar dependency respecting builder.
Very good. Might I also suggest that you consider prepending an @SuppressWarnings to each class that is generated from the antlr grammar? Considering that the majority of warnings are due to the antlr code generator rather than any mistake in the grammar and hence can be safely ignored.
although the sourcecode is publicly accessible, i prefer to keep this branch internal to TRex developers at the moment as i'm not sure how the antlreclipse authors feel about a branch. hence, there won't be any announcements outside the TRex community.
I would suggest (you probably have already done this) contacting the antlreclipse developers and recommending they include your improvements in future releases.
Best regards, Dominic
Hello Dominic,
Dominic Evans wrote:
Very good. Might I also suggest that you consider prepending an @SuppressWarnings to each class that is generated from the antlr grammar? Considering that the majority of warnings are due to the antlr code generator rather than any mistake in the grammar and hence can be safely ignored.
good idea! i'll look into that.
although the sourcecode is publicly accessible, i prefer to keep this branch internal to TRex developers at the moment as i'm not sure how the antlreclipse authors feel about a branch. hence, there won't be any announcements outside the TRex community.
I would suggest (you probably have already done this) contacting the antlreclipse developers and recommending they include your improvements in future releases.
yes. i contacted one antlreclipse developer a while back when i did the pretty printer integration, but i didn't hear anything from him since then. i fear that antlreclipse isn't actively developed or maintained anymore. i'll try again though. i don't expect too much from it though. last time his concern was preserving eclipse 3.0 compatibility.
Hello,
i just wanted to let everybody know about a few radical changes that i implemented. First, the reconciler is basically completely different. I basically figured out that we used it not exactly how it was supposed to be used (e.g. analyting in setDocument). As a result, i removed all the job stuff since everything is now analyzed in a seperate thread automatically. I realized that somehow the analysis was taking longer than necessary as different threads were probably waiting for each other to finish.
Next, i removed superflous analysis steps (e.g. analyzing the editor file again although a complete analysis has just been done). This means, that big test suites can be browsed a lot quicker once they have been analyzed.
The whole metrics and refactoring rule analysis step has been moved from the reconciler to a dedicated TRex metrics and refactoring rule builder. This builder is essentially triggered like a compiler. It is triggered once programatically when the initial analysis is finished and afterwards on each saved change if "build automatically" is enabled (it is enabled by default). This builder is related to a new TRex nature which must be enabled for all TRex projects. For this reason, the new project wizard has been changed to automatically add the TRex nature and the refactoring builder on project creation. So there is an actual difference now when the "TRex New Project"-wizard is used for project creation. Projects with TRex nature are decorated with a ttcn-3 icon.
Each project with a TRex nature contains a "TRex settings" property page. In this page, the metrics and refactoring rule detection builder can be enabled or disabled.
trex-devel@informatik.uni-goettingen.de
-
Benjamin Zeiss -
Dominic Evans -
Helmut Neukirchen