Trex-devel

trex-devel@informatik.uni-goettingen.de

50 discussions

0.5.2 endgame, JIRA usage
by Helmut Neukirchen 24 May '06

24 May '06

Dear all, I think we may start some sort of "endgame" for the 0.5.2 TRex release. All TRex related issues are fixed, now. (Some off them still need to be closed). I think we should manually test the current build by just using TRex and report and fix any regressions. My current plan is to release TRex on Monday (which allows us to burn CDs for T3UC and SAM). Concerning JIRA, I experienced that it is probably good to have two different persons mark an issue as fixed and as closed. (It gives the bug fixer some feedback and involves some review by the issue closer.) I already changed the Wiki documentention on JIRA for developers. Furthermore, I came to the conclusion that we should use the issue type "Task" only for issues which should not appear in the release notes (i.e. the release note template will be modified to suppress tasks). Hence is "tasks" for Web site improvements, refactorings which would confuse the end user. (On the other hand there may be refactorings, e.g. performance tunings, which may be of interest for the end user; this would then be an issue type of "improvement".) Finally, I like to welcome Marting Bisanz as developer. He is working as a Master student on TRex and already contributed bug fixes. As part of his research, he will investigate pattern-based smell detection. Any feedback is welcome, 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

2 1

TRex Outline View Slow
by Dominic Evans 23 May '06

23 May '06

Hi, TRex can be slow to initialise on a large (individual) TTCN-3 file that contains many elements (~10000 templates) as the outline view is slow to be created. It may only be possible to fix this with a design change. Currently the outline view is merely given the root node by the analyzer and it builds the tree for the outline by parsing through this looking for suitable elements. As we already go through the tree in TTCN3Analyzer, it may be better to build the list of basic elements to display there and give these directly to the outline to display (it can still work out nested elements itself). However, it may simply be that the SWT tree is slow to display large numbers of elements. Thoughts / comments? Regards, Dominic

2 2

JIRA 'Release Notes'
by Dominic Evans 19 May '06

19 May '06

Hi, Just a minor comment on JIRA-generated release notes. http://www.trex.informatik.uni-goettingen.de/jira/secure/ReleaseNote.jspa?p… If, as a user, I received this along with a new version of the tool, I would be unsure whether this first list was bugs that were fixed in this release or bugs that still remained in this release. Bugs Fixed, Improvements and New Features would be better choices. I don't know if it is possible to change this in JIRA configs, but if not I would recommend manually changing them before using this information in a new release announcement. Regards, Dominic

2 8

Nightly build working again, Developer's Corner documentation added
by Helmut Neukirchen 18 May '06

18 May '06

Dear TRex developers, Benjamin managed to make the trex.product and feature.xml platform independent, i.e. the installation of the nightly builds from the nightly build update site works again (it was broken for a few days, but the release update site was not affected.) (Solution: see "How to create a trex.product file which is platform independent?" on http://www.trex.informatik.uni-goettingen.de/trac/wiki/Developers#HOWTOs ) Furthermore, I have added some documentation at the Developer's Corner Wiki page. Most important for us are: http://www.trex.informatik.uni-goettingen.de/trac/wiki/JiraForDevelopers Summary: do not forget to close bugs and support using JIRA also for release management. http://www.trex.informatik.uni-goettingen.de/trac/wiki/CodingRules Summary: use SUN's Java coding rules and Eclipse default settings for formatting. Feedback is welcome (but please no lengthy discussion about coding rules: It's probably impossible to find a consensus. It's more important to actually have coding rules, not how they look like.) Bye, 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

TRex Bug Reporting
by Dominic Evans 16 May '06

16 May '06

Hi, I believe it is not evident from the current webpage where or how users should submit bug reports for TRex. Do you intend them to just mail problems to the trex-users mailing list or will they be expected to add them to the JIRA page themselves? We should make this clear somewhere. Incidentally it would now make sense to apply for the open source license for JIRA (rather than evaluation) now that the TRex webpage and source code are available. This is assuming you are happy with it (rather than bugzilla). Best regards, Dominic

2 3

[Fwd: Re: [Trex-devel] Website TOC Order]
by Benjamin Zeiss 12 May '06

12 May '06

we noticed this morning that the reply didn't go to the list. so here the answer for the sake of completeness. -------- Original Message -------- Subject: Re: [Trex-devel] Website TOC Order Date: Thu, 11 May 2006 18:43:10 +0200 From: Benjamin Zeiss <zeiss(a)cs.uni-goettingen.de> To: Dominic Evans <vnsd001(a)motorola.com> References: <20060511145705.GA3808(a)motorola.com> Hi Dominic, Dominic Evans wrote: > * Home > * TRex > o Documentation (ChangeLog could be linked within this node) > o Download (License could be linked within this node) > o Features > o Screencasts > o Screenshots > * Team (need better word for this) > o Contact (Mailing Lists could be linked within this node) > o Contributors > o Publications > * Links > > Any comments/thoughts? we just changed the structure a little. we think that changelogs are mostly viewed in conjunction with new releases or downloads. hence, the changelog is now located next to release announcements in the news and on the download page. then we think that publications is basically documentation and therefore combined the two pages. contact and contributors are also merged as "team". i hope you agree to these changes. we are not sure about the screenshots and screencasts. they could probably be merged too, but the nesting would be deeper in this case as the screenshots page is already pretty big. do you have any ideas concerning this? -- Benjamin Zeiss -- Benjamin Zeiss

1 0

Website TOC Order
by Dominic Evans 11 May '06

11 May '06

Hi, I wanted to open a dialogue regarding the ordering of items in the table of contents (http://www.trex.informatik.uni-goettingen.de/trac/wiki/TOC) on the website. Apologies if this isn't strictly 'TRex Development'. We currently have one big list: * Home o Features o Screenshots o Screencasts o Download o Change Log o License o Documentation o Publications o FAQ o Mailing Lists o Contributors o Contact o Links I don't think it is easy for the user to immediately spot what they want in this. I guess you have tried to order them in the order in which people might read them as chapters of a story, but without this appreciation the non-alphabetic ordering can seem a little random. I would suggest something like the following might be better to both reduce the number of items (pushing some categories down the line) and to allow for a more natural ordering. * Home * TRex o Documentation (ChangeLog could be linked within this node) o Download (License could be linked within this node) o Features o Screencasts o Screenshots * Team (need better word for this) o Contact (Mailing Lists could be linked within this node) o Contributors o Publications * Links Any comments/thoughts? Regards, Dominic

1 0

Re: findTransitiveReference
by Benjamin Zeiss 09 May '06

09 May '06

Hi Dominic, Dominic Evans wrote: > In Scope.java, findTransitiveReference seems to loop over all symbols, > resolving to assign Symbol symbol, and in the end returns just this one > symbol. A lot of time seems to be spent in this method. > > What is the purpose? To find the last TypeSymbol and resolve that? this method is supposed to handle transitive imported symbols if i remember correctly. for example: module foo { import from bar all; function test() { var foostring foostringVar := "test"; } } module bar { import from blah all; type foostring mystring; } module blah { type charstring foostring; } without transitive imports, foostring would not be resolvable in module foo, because foo imports only from bar and not from module blah. however, mystring is imported and it references foostring, so foostring is imported transitively. the currently implemented solution may be a little too simple, i admit. it basically works this way: if a symbol is not resolvable in a scope, the last step is to check each type symbol in the symbol table. if it has a referenced type with the same name as the symbol to be resolved, the symbol is resolved again using the scope of the type definition where it is referenced. there is a problem with this implementation: it doesn't resolve all transitive symbols. it was more or less a quick hack. for example: modules A-B-C (i.e. A imports from B, B imports from C): A can access transitively imported symbols from C with this implementation, but modules A-B-C-D: A can't access transitively imported symbols from D. that is, because module B is inspected for referenced types with matching names which only appear in module C. This is definately something that needs to be fixed at some point. However, i haven't seen any module that uses the feature this much and i guess a real fix would take a little time. for the moment (and a quick fix), it would probably be a speedup if each scope would have an additional hashmap which stores referenced type names as key and the corresponding type symbol as value. that way, the lookup is just O(1) and not O(n) for each scope. -- Benjamin Zeiss -- Benjamin Zeiss

2 5

Re: TTCN-3 Query
by Benjamin Zeiss 27 Apr '06

27 Apr '06

Hi Dominic, Dominic Evans wrote: > > A quick TTCN-3 query which one of you might be able to help with. > > Telelogic Tau seems to allow the 'char' type here: > > > > const char LF := int2char( 10 ); // line feed, '\n' > > const char CR := int2char( 13 ); // carriage return, '\r' > > > > But to parse successfully with TRex I found I needed to change char -> > > byte. Is this due to an extension to the TTCN-3 grammar implemented by > > Telelogic that automatically typedefs char to byte or am I missing > > something here? char is not a built-in type according to the specification. in fact, char seems to be a predefined function which is used in conjunction with universal charstrings to specify char quadruples. i don't think its a good idea to use it as an alias for byte. -- Benjamin Zeiss

3 6

core/ui split
by Benjamin Zeiss 23 Apr '06

23 Apr '06

Hi, i managed to do the core/ui split. i also put the refactoring stuff into separate plug-ins. so there should be 3 new plug-ins to checkout and import into your workspaces. -- Benjamin Zeiss

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Trex-devel