Trex-devel July 2006

trex-devel@informatik.uni-goettingen.de

4 participants
11 discussions

TRex 0.5.3 release candidate
by Helmut Neukirchen 19 Jul '06

19 Jul '06

Dear TRex developers, we are all eager on Step 10. of "How to release a new release of TRex?" from the developer's HOWTOs. Hence, we have just put our release candidate for TRex 0.5.3 on the nightly update site: http://www.trex.informatik.uni-goettingen.de/nightly/ Furthermore, we have now installers for a stand-alone TRex product: http://www.trex.informatik.uni-goettingen.de/nightly/trex_windows-latest.exe http://www.trex.informatik.uni-goettingen.de/nightly/trex_linux-latest.sh Please install it and play with it. We intend to release TRex 0.5.3 tomorrow morning. Hence, report any bugs until tomorrow 8:00 CET. Helmut -- Helmut Neukirchen mailto:neukirchen@informatik.uni-goettingen.de Institute for Informatics http://www.swe.informatik.uni-goettingen.de University of Göttingen, Lotzestr. 16-18 phone: +49 551 39 14695 D-37083 Göttingen, Germany fax: +49 551 39 14415

1 0

RE: [Trex-devel] Some explanation
by Kristóf Szabados (IJ/ETH) 18 Jul '06

18 Jul '06

Hello Benjamin, > -----Original Message----- > From: trex-devel-bounces(a)informatik.uni-goettingen.de > [mailto:trex-devel-bounces@informatik.uni-goettingen.de] On > Behalf Of Benjamin Zeiss > Sent: 2006. július 18. 13:23 > To: TRex Development Mailing-List > Subject: Re: [Trex-devel] Some explanation > > Hello Kristof, > > Kristóf Szabados (IJ/ETH) wrote: > > > No I was thingink on creating the nodes of the tree by > hand. I think > > > it will become a problem later on if we will have use > > > getchild().getchild() and if that's not working than it's > siblings > > > kind of programming. In a long term it should be better > to program > > > like > get_the_base_template().iterate_over_the_formal_parameters_until(). > > > Well this is not a good example (long name, wrong > structure), but it > > > demonstrates how much easyer it is to maintain a code > written that > > > way, compared to the other general tree handling. (This is also a > > > working method proven by TITAN, it is somewhere between the fully > > > general parsing of ANTLR and the hand crafted parsers of > gcc, JDT, > > > CDT and other commercial compilers). > > Yes, a class based data model for the source would certainly > be nice and easier to use. Implementing this later on is > indeed not that simple. > However, i can imagine that it is possible to introducing a > data-model facade based on the LocationAST that is doing > something like that. That way, new code could use this facade > and old code can be rewritten to use it as time permits. > However, i also believe that the current AST approach can > make some things easier. For example, i would imagine that > the reference finder algorithm could not be realized in such > a generic way that easily. But these things always depend on > details in the implementation and design. Well I never said it is easy. I know it takes a lot of time just to hand create the classes. Actually we are planning to support other languages, and lots of deviations (ericsson creates lots of change requests for the standard), so we must know what paths we are able to choose. For us it might be much better to spend lots of time in the beginning to create the foundations, than to correct mistakes later on. But if we create our own AST structure, it might become incompatible with your refactoring features. > > > There is also an other problem of Trex's huge memory requirement. > > > For the SIP protocol's files (which I assume you have) > TITAN's peak > > > memory usage only reaches 23 MB in the 3 seconds of parsing, > > > semantic checkin, code generation, and runnable generation, while > > > Trex uses more than 100 MBs for quite a few seconds to make the > > > parsing, and metric analyzis (0.5.2 and the memory usage > is constant > > > because of the nature of the problem). > > The metric analysis is definately expensive performance wise. > The latest builds offer the possibility to disable it through > the project property page. The parser speed and memory > footprint can probably still be tuned a lot - that is > correct, but it has not been the focus of our work in > Göttingen. For a really good solution, i would expect it > makes sense to go the JDT route and have a lightweight AST > for IDE stuff and a non-lightweight AST for possible > compilation and so on. Also, note that we currently analyze a > project very naively, i.e. we don't analyze dependencies > between TTCN-3 modules, but we load all TTCN-3 files in a > project. Hence, loading times are high the first time on > startup and unnecessary files may get loaded. Well I was also talking about loading all the modules at once. I understand that the basic idea was a refactoring tool, and that for reseach the tool is already quite good. But here I have seen projects containing >10 MB of source code. If the tool won't be able to handle this ammount well, then people naturally won't use it ( I too dont like to wait for the appearance of the letter I just now typed). The parsing speed is only one issue, we can help on that a lot with "rare" parsing (like only at the end of words, or re-parsing only in the context of the change). Memory is an other issue, I understand that Java has it's limitations, but as soon as we reach the limits of phisical memory, virtual memory kicks in, decreasing the performance considerably (you should know that we are of course working on encrypted drives for security reasons and that is slowing down things a bit). We were already thingink on allowing the user to choose from fast but not so precise and slow but precise ways of parsing / AST handling, but this will also need some further thoughts. > > > There is also an other problem > > > that works for Trex's huge memory usage, if a file was > edited, than > > > a new tree is built while keeping the old tree . I > understand that > > > on this way you can support content assistant on > non-correct files, > > > but this doubles the memory needed temporarily, it might > be better > > > to re-parse only a sub tree (but I also understand that > that would > > > be quite a lot of work). > > Also true. It is probably not as hard as you think. At least > i have some rough ideas how i would try to approach it and > this would involve maybe a few days to realize. > > We basically knew about all these problems, but you should > keep in mind that the TRex is the result of few persons who > have worked on it or are still working on it only for their > bachelor and master's thesises. I understand that, TITAN also started as a master's thesises of our lead designer. > Also it may currently seem > like we are working on TRex full-time, but actually we aren't > ;-) The things you mention are problematic for productive > industrial use, but they are not as important for research. > Hence, these things are somewhere on our list, but they have > no immediate priority. We would expect that those things get > addressed by those who need them improved and we would > certainly assist if there are any questions. Otherwise, they > will be addressed when our time permits, but this may not be > very soon. You should not forget that we wrote everything > from scratch in maybe a year or less with mostly only one or > two persons implementing at a time. Therefore, it shouldn't > be a surprise that we cannot offer a product which is ready > for commercial use. Well we understand that we will have to put in considerable ammount of "resources" to make it commercial quality. Right now we are just deciding if we should do that actualy, and if so than how. > -- > Benjamin Zeiss > _______________________________________________ > Trex-devel mailing list > Trex-devel(a)informatik.uni-goettingen.de > https://user.informatik.uni-goettingen.de/mailman/listinfo/trex-devel > Kristof

1 0

Some explanation
by Kristóf Szabados (IJ/ETH) 18 Jul '06

18 Jul '06

Hello, Please don't take my questions and problems with the design of Trex as an offense. As we will have to decide about millions of hours of work, we have to know what paths are available for us. The questions / problems regarding the memory usage, and tree structure are one of the most important issues in my view, because they will serve as the basis for later developements. Kristof

2 1

RE: [Trex-devel] Multi page editor
by Kristóf Szabados (IJ/ETH) 18 Jul '06

18 Jul '06

> -----Original Message----- > From: trex-devel-bounces(a)informatik.uni-goettingen.de > [mailto:trex-devel-bounces@informatik.uni-goettingen.de] On > Behalf Of Helmut Neukirchen > Sent: 2006. július 18. 10:32 > To: TRex Development Mailing-List > Subject: Re: [Trex-devel] Multi page editor > > Kristóf Szabados (IJ/ETH) wrote: > > Hello, > > > > Original author? > > On > http://www.trex.informatik.uni-goettingen.de/trac/wiki/Documen > tation#PublicationsonTRex > the history of our TTCN-3 Eclipse is plug-in described (in > reverse order). > Well I missed that part. > > Well I just wanted to know why some of design decisions > were done the > > way they were. Like MultiPageEditor, it might bring some > extra effort > > to manage the different pages, and might intruduce some not > foreseen errors. > > In this particular case, I am not aware of problems > introduced by MultiPageEditor. (However, if you like to > invest efforts, we have no objections to remove the MultiPageEditor.) > > > Like using ANTLR to build the classes for the AST > automatically. That > > particular decision seems to allow early releases, but will > become a > > huge problem onwards (right now for me it seems to be a not > so solid > > foundation). > > ANTLR is a proven compiler construction tool (e.g. used in > the TestingTech TTworkbench and TTthree compiler). But we are > always interested in suggestions for improvement. What is you > suggestion in this case? > > Do you suggest to hand-craft a TTCN-3 parser instead? (A > hand-crafted parser may support e.g. content assist or > fault-tolerant parsing better, but hand-crafting a parser for > the huge TTCN-3 grammar would mean a lot of > efforts.) > No I was thingink on creating the nodes of the tree by hand. I think it will become a problem later on if we will have use getchild().getchild() and if that's not working than it's siblings kind of programming. In a long term it should be better to program like get_the_base_template().iterate_over_the_formal_parameters_until(). Well this is not a good example (long name, wrong structure), but it demonstrates how much easyer it is to maintain a code written that way, compared to the other general tree handling. (This is also a working method proven by TITAN, it is somewhere between the fully general parsing of ANTLR and the hand crafted parsers of gcc, JDT, CDT and other commercial compilers). > Best regards, > Helmut > -- > Helmut Neukirchen > mailto:neukirchen@informatik.uni-goettingen.de > Institute for Informatics > http://www.swe.informatik.uni-goettingen.de > University of Göttingen, Lotzestr. 16-18 phone: +49 > 551 39 14695 > D-37083 Göttingen, Germany fax: +49 > 551 39 14415 > _______________________________________________ > Trex-devel mailing list > Trex-devel(a)informatik.uni-goettingen.de > https://user.informatik.uni-goettingen.de/mailman/listinfo/trex-devel > These are issues I have to know how you wan't to handle. As we might have to work together, I have to know what directions you want to follow. There is also an other problem of Trex's huge memory requirement. For the SIP protocol's files (which I assume you have) TITAN's peak memory usage only reaches 23 MB in the 3 seconds of parsing, semantic checkin, code generation, and runnable generation, while Trex uses more than 100 MBs for quite a few seconds to make the parsing, and metric analyzis (0.5.2 and the memory usage is constant because of the nature of the problem). There is also an other problem that works for Trex's huge memory usage, if a file was edited, than a new tree is built while keeping the old tree . I understand that on this way you can support content assistant on non-correct files, but this doubles the memory needed temporarily, it might be better to re-parse only a sub tree (but I also understand that that would be quite a lot of work). Best regards, Kristof

1 0

RE: [Trex-devel] Multi page editor
by Kristóf Szabados (IJ/ETH) 18 Jul '06

18 Jul '06

Hello, Original author? Well I just wanted to know why some of design decisions were done the way they were. Like MultiPageEditor, it might bring some extra effort to manage the different pages, and might intruduce some not foreseen errors. Like using ANTLR to build the classes for the AST automatically. That particular decision seems to allow early releases, but will become a huge problem onwards (right now for me it seems to be a not so solid foundation). > -----Original Message----- > From: trex-devel-bounces(a)informatik.uni-goettingen.de > [mailto:trex-devel-bounces@informatik.uni-goettingen.de] On > Behalf Of Benjamin Zeiss > Sent: 2006. július 18. 10:06 > To: TRex Development Mailing-List > Subject: Re: [Trex-devel] Multi page editor > > Hello, > > Kristóf Szabados (IJ/ETH) wrote: > > Is there any reason for using a MultiPageEditor? > > Are you planning to show different aspects of TTCN3 code in it? > > The reason is probably that the original author who wrote the > editor originally used the ANTLR plugin as reference. So the > answer is that there is indeed no particular reason for using > the multi-page editor and we are currently not planning any > other pages. It could be potentially useful if anyone would > implement a different TTCN-3 presentation format such as TFT though. > > -- > Benjamin Zeiss > _______________________________________________ > Trex-devel mailing list > Trex-devel(a)informatik.uni-goettingen.de > https://user.informatik.uni-goettingen.de/mailman/listinfo/trex-devel >

2 1

Multi page editor
by Kristóf Szabados (IJ/ETH) 18 Jul '06

18 Jul '06

Hello! Is there any reason for using a MultiPageEditor? Are you planning to show different aspects of TTCN3 code in it? Kristof

2 1

TRex Nightly Update Site
by Dominic Evans 17 Jul '06

17 Jul '06

Hi, I wanted to quickly try out the latest TRex nightly but it seems the nightly update site isn't working / has missing files? Unable to retrieve remote reference "http://www.trex.informatik.uni-goettingen.de/nightly/features/org.eclipse.p…". [Server returned HTTP response code: "404 Not Found" for URL: Regards, Dominic

3 11

Intent to release TRex 0.5.3 in near future
by Helmut Neukirchen 17 Jul '06

17 Jul '06

Dear TRex developers, we intend to release TRex 0.5.3 in the next few days (Tuesday or Wednesday). Currently, the following issues are open: Task TTC-164 UNRESOLVED [AntlrEclipse5] Clean checkout does not work with branched ANTLR plug-in Critical Open Task TTC-137 UNRESOLVED Add more complex tests for inline template parameter Minor Open Task TTC-138 UNRESOLVED Add tests for all refactoring using templates involving record of/set of/type record length Minor Open Task TTC-96 UNRESOLVED Add tests for Merge Template refactoring Minor Reopened We like to add some more JUnit test for merge templates, but in principle, we are satisfied with the current status. Hence, we will defer any open issues which we cannot solve in the next few days. If you have any objections or comments, please let us now. Helmut -- Helmut Neukirchen mailto:neukirchen@informatik.uni-goettingen.de Institute for Informatics http://www.swe.informatik.uni-goettingen.de University Goettingen, Lotzestr. 16-18 phone: +49 551 39 14695 D-37083 Goettingen, Germany fax: +49 551 39 14415

1 0

Changing commit logs
by Helmut Neukirchen 14 Jul '06

14 Jul '06

Dear developers, since we had recently a few occasions where the log comment of an SVN commit contained a wrong JIRA bug ID and thus ought to be changed, I configured SVN in a way that the maintainers are able to change commit logs. (Since commit logs themselves are not versioned, I did not allow everybody to change them.) Hence, if you require important changes (wrong bug IDs, but not just misspelled words) to commit logs, contact Benjamin or me. I have already corrected all commit logs which were wrong according to a comment in JIRA. Best regards, Helmut -- Helmut Neukirchen mailto:neukirchen@informatik.uni-goettingen.de Institute for Informatics http://www.swe.informatik.uni-goettingen.de University of Göttingen, Lotzestr. 16-18 phone: +49 551 39 14695 D-37083 Göttingen, Germany fax: +49 551 39 14415

1 0

Mailing list archives are now world readable
by Helmut Neukirchen 07 Jul '06

07 Jul '06

Dear TRex developers, we just realized that the archives of the TRex mailing lists were only readable from within our CS department. We have changed it, hence anyone who just recently joined this mailing list should now also be able to browse older mails. Best regards, Helmut -- Helmut Neukirchen mailto:neukirchen@informatik.uni-goettingen.de Institute for Informatics http://www.swe.informatik.uni-goettingen.de University Goettingen, Lotzestr. 16-18 phone: +49 551 39 14695 D-37083 Goettingen, Germany fax: +49 551 39 14415

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Trex-devel July 2006