titan.EclipsePlug-ins issueshttps://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues2022-11-17T14:20:31Zhttps://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/505Imrovement on logging of sensitive data2022-11-17T14:20:31ZAdam KnappImrovement on logging of sensitive data## Summary
Our customers complain that they could find some sensitive data are printed in TTCN log. (such as k, op, opc…)
So we want to check whether Titan team could support a new function to protect these sensitive data in logs.
## ...## Summary
Our customers complain that they could find some sensitive data are printed in TTCN log. (such as k, op, opc…)
So we want to check whether Titan team could support a new function to protect these sensitive data in logs.
## What is the expected correct behavior?
No sensitive data is written to logs
## Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console output, logs, and code, as it's very hard to read otherwise.)
## Possible fixes
We have a proposal for this function:
To fulfil generic product security requirement, Titan could provide log API to filter out sensitive contents before output to log file.
Sensitive contents can be described by e.g. regular expression patterns.
The API could be set in whole process level since typhon framework is used by AAT and AAT can’t change typhon code directly.
Example imlementation:
```
type record UserData{
charstring username,
octetstring secret_key
} with {
extension (secret_key) “sensitive_data”
}
type octetstring OPc with {extension “sensitive_data” }
If
FileMask:=LOG_ALL
Then the log would contain
{ username := “User1”, secret_key=<redacted>}
If
FileMask:=LOG_ALL | SENSITIVE
Then the log would contain
{ username := “User1”, secret_key=’11223344’O}
```
## Titan version
8.2
## Platform details (OS type and version)
All
/cc @aknappqwthttps://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/490Add TTCN3 specific search2022-06-23T09:38:04ZMiklos MagyariAdd TTCN3 specific searchThere are a couple of possible search options available in the plugin (even Java search), but there is no TTCN3 specific search.
It would be nice to add a search option that could filter search results according to the TTCN3 language sta...There are a couple of possible search options available in the plugin (even Java search), but there is no TTCN3 specific search.
It would be nice to add a search option that could filter search results according to the TTCN3 language standard, eg. showing hits only for testcases or altsteps etc.https://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/485Errors/warnings with an invalid location should be reported to the console2022-05-05T09:24:46ZMiklos MagyariErrors/warnings with an invalid location should be reported to the consoleSometimes errors and warnings are related to objects that has no valid location (an example is an implicit class constructor generated by the compiler).
As these markers are invisible, they can be easily missed, making debugging more dif...Sometimes errors and warnings are related to objects that has no valid location (an example is an implicit class constructor generated by the compiler).
As these markers are invisible, they can be easily missed, making debugging more difficult.
It would be useful to send problems with invalid location to the console so they could be spotted.Miklos MagyariMiklos Magyarihttps://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/478Syntax highlight based on semantic information in Designer - phase 22022-11-16T14:08:14ZAdam KnappSyntax highlight based on semantic information in Designer - phase 2Currently the syntax highlight in the Designer is purely based on keywords matching on literals and regular expression matching on comments.
As we now have a semantic database, that is always up-to-date, it would be much better for the ...Currently the syntax highlight in the Designer is purely based on keywords matching on literals and regular expression matching on comments.
As we now have a semantic database, that is always up-to-date, it would be much better for the user if we could use the information from this database to enhance the visual presentation of source code.
For example display the names of constants with bold blue letters and the names of variables with light blue letters. Formal parameters could also use a different hue, to make pop more easily inside functions/altstep/testcases. etc...
Tasks:
- [x] Fix syntax highlight in doc comments when using only the `<` sign, try e.g. `a < b`
- [ ] Refactor doc comment parser to parse comments (especially @status) in an earlier phase
- [ ] Deprecated highlight only works on the ID after the doc comment
- [ ] Add more semantic highlight items
- [ ] enumerated
- [ ] class
- [ ] unused definitions
- [ ] Improve color/style defaults, these are almost random now
- [ ] Dynamically change the example text in the preview window of the syntax coloring pref. page (currently only TTCN-3 example text is shown that is not relevant for ASN.1 and configuration editors)
- [ ] Preference to individually enable/disable semantic highlighting typeshttps://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/438Collecting possible checkers for TTCN-3 OOP2021-08-02T11:42:31ZAdam KnappCollecting possible checkers for TTCN-3 OOPGenerally a lot of code checkers are available in different tools that focus on OOP. A comprehensive list of such checkers should be compiled taking into consideration the properties of OOP in the TTCN-3 standard.Generally a lot of code checkers are available in different tools that focus on OOP. A comprehensive list of such checkers should be compiled taking into consideration the properties of OOP in the TTCN-3 standard.https://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/433Custom encoding name with spaces is not compiled2021-11-02T08:02:35ZAdam KnappCustom encoding name with spaces is not compiled## Summary
Copy of titan.core#563
Originates from the forum: https://www.eclipse.org/forums/index.php/t/1108162/
It is requested to allow the space character in custom encoding names. At the moment, the custom encodings defined by the...## Summary
Copy of titan.core#563
Originates from the forum: https://www.eclipse.org/forums/index.php/t/1108162/
It is requested to allow the space character in custom encoding names. At the moment, the custom encodings defined by the following regex are allowed: `[A-Za-z][A-Za-z0-9_]*`
The standard allows different characters as well, this is a limitation of the compiler.
Both code analysis and Java code generation have to be checked and improved.Miklos MagyariMiklos Magyarihttps://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/425Improve code completion2021-08-02T19:30:35ZMiklos MagyariImprove code completionThe IDE usability could be improved with more sophisticated code completion. The following could be implemented:
- support styled code completion proposals (implemented in [https://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/...The IDE usability could be improved with more sophisticated code completion. The following could be implemented:
- support styled code completion proposals (implemented in [https://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/commit/0b24a24f397e43c164cba61a6bb88536e199f958](https://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/commit/0b24a24f397e43c164cba61a6bb88536e199f958))
- function parameters (initially implemented in [https://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/commit/fca9874f20b0c9075c3905eacc4c48ebf44b06a9](https://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/commit/fca9874f20b0c9075c3905eacc4c48ebf44b06a9))
- class members (initially implemented in [https://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/commit/d3d7d290a15c7498cc56076783a65e8ac07af6bd](https://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/commit/d3d7d290a15c7498cc56076783a65e8ac07af6bd))
- function and class member completion for nested classes (implemented in [https://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/commit/37946a166da70e9692ae13c377cce8003e6a0660](https://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/commit/37946a166da70e9692ae13c377cce8003e6a0660))
- const/var type suggestions
- many more context sensitive suggestionsMiklos MagyariMiklos Magyarihttps://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/415Support "Conjunction" (Java side)2021-11-02T07:57:24ZAdam KnappSupport "Conjunction" (Java side)Add support for "Conjunction", as defined in "Advanced Matching", ES 203 022, 5.3.1 (https://www.etsi.org/deliver/etsi_es/203000_203099/203022/01.04.01_60/es_203022v010401p.pdf#page=13)
`conjunct "(" { (TemplateInstance | all from Templ...Add support for "Conjunction", as defined in "Advanced Matching", ES 203 022, 5.3.1 (https://www.etsi.org/deliver/etsi_es/203000_203099/203022/01.04.01_60/es_203022v010401p.pdf#page=13)
`conjunct "(" { (TemplateInstance | all from TemplateInstance)[","] } ")"`
Main implementation tasks:
- [x] parser/lexer
- [x] semantic checks
- [ ] runtime and code generationAdam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/414Support "Implication" (Java side)2021-11-02T07:57:07ZAdam KnappSupport "Implication" (Java side)Add support for "Implication", as defined in the "Advanced Matching", ES 203 022, 5.3.2 (https://www.etsi.org/deliver/etsi_es/203000_203099/203022/01.04.01_60/es_203022v010401p.pdf#page=14)
`TemplateInstance implies TemplateInstance`
M...Add support for "Implication", as defined in the "Advanced Matching", ES 203 022, 5.3.2 (https://www.etsi.org/deliver/etsi_es/203000_203099/203022/01.04.01_60/es_203022v010401p.pdf#page=14)
`TemplateInstance implies TemplateInstance`
Main implementation tasks:
- [x] parser/lexer
- [x] semantic checks
- [ ] runtime and code generationAdam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/413Support dynamic matching (Java side)2021-11-02T07:56:29ZAdam KnappSupport dynamic matching (Java side)Support Dynamic Matching, as specified in "Advanced Matching", ES 203 022, 5.1 (https://www.etsi.org/deliver/etsi_es/203000_203099/203022/01.04.01_60/es_203022v010401p.pdf#page=8)
`@dynamic (StatementBlock | FunctionRef)`
Main implemen...Support Dynamic Matching, as specified in "Advanced Matching", ES 203 022, 5.1 (https://www.etsi.org/deliver/etsi_es/203000_203099/203022/01.04.01_60/es_203022v010401p.pdf#page=8)
`@dynamic (StatementBlock | FunctionRef)`
Main implementation tasks:
- [x] parser/lexer
- [x] semantic checks
- [ ] runtime and code generationAdam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/401Unix domain sockets will be available in Java 162021-05-04T09:17:30ZEclipse WebmasterUnix domain sockets will be available in Java 16## Submitted by Kristof Szabados
**[Link to original bug (#571791)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=571791)**
## Description
I know Java 16 is still far in the future for Titan, but this feature needs to be k...## Submitted by Kristof Szabados
**[Link to original bug (#571791)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=571791)**
## Description
I know Java 16 is still far in the future for Titan, but this feature needs to be kept in mind.
Unix domain sockets were accepted into Java 16: https://openjdk.java.net/jeps/380
When rewriting the C runtime to the Java runtime there was one feature that could not be converted ... Unix domain sockets.
The core of this feature is, that when different processes communicate with each other via sockets and happen to be running on the same machine ... when using unix domain sockets the sent messages do not need to go through the network card, they can be directed within the operating system ... saving a lot on unnecessary performance overhead.
If the Java runtime of Titan could use this feature .. it might be able to beat the C runtime's performance nowadays ;)
+ with newer processors having more and more cores (leading to actually fewer machines needed to generate a given load), the chances of processes running on the same machine should increase, ever-increasing the usefulness of this feature.https://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/398User/style guide should be written to notify users of how parallelism changes...2021-06-07T15:06:59ZEclipse WebmasterUser/style guide should be written to notify users of how parallelism changes the optimal software structure (as now they build Technical Debt into their systems).## Submitted by Kristof Szabados
**[Link to original bug (#570599)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=570599)**
## Description
While the Designer plugin was mainly doing its analysis in a single-threaded way, t...## Submitted by Kristof Szabados
**[Link to original bug (#570599)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=570599)**
## Description
While the Designer plugin was mainly doing its analysis in a single-threaded way, the traditional way of organizing code to minimize duplication was kind of optimal.
But since this semantic checking was made massively parallel, and both the C and Java side build processes also use massive parallelism (+now hardware with several CPU cores became the norm) this has changed.
When a single thread is processing the source code it makes sense to minimize the size of the source code, by merging otherwise duplicated elements into central modules. Creating "Types" modules is a good example: by moving all of the types from the test system into a single module, all types based code duplication can be eliminated, code size reduced ... thus leading to faster analysis and build times.
With massive parallelism, this changes.
In this structure moving all types into a single module still eliminates code duplication, but also creates a central point:
- whose processing can not be parallelized
- on which most other modules will depend on ... aka. their analysis has to wait.
Effectively making analysis and build processes take longer than necessary.
In a parallel architecture, it is better to allow some level of code duplication, in order to speed up the process, if that means that several threads can work on the code at the same time. As in such a case the amount of work to be done can be better distributed ... aka. the more CPU cores are involved the faster the build will finish overall.
(please note, this does mean that there will be more work done overall, but the system could still finish faster).
Example:
Let's have a system where theoretically 3 independent features use overlapping types.
types1 <- feature1
types2 <- feature2
types3 <- feature3
When the types are merged into a single module that decreases the overall work to be done but also forces single-threaded processing. In such a setup, the processing of the code related to the features can not start until the processing of the central types module is no finished.
In a setup like this:
types <- feature1
types <- feature2
types <- feature3
The code of types has to be processed first (utilizing only a single core) and only after it can the parallel processing of the features start.
However, if these types modules are kept separate, they can be analyzed in parallel from the beginning. please note, that this benefit comes at least 2 places:
- if the types only overlap and are not perfect copies, each individual module will be shorter, than the merged one. Decreasing the amount of work needed to be processed individually.
- Being able to utilize 3 cores to process 3 (smaller) files in parallel, should always result in reaching the end of processing earlier.
This should be communicated to the users.
As right now, if they still follow program structuring methods that were optimal earlier, they are creating suboptimal systems, that slow down their development.
Version: 7.2.0Adam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/396try out TornadoVM2021-05-06T16:14:41ZEclipse Webmastertry out TornadoVM## Submitted by Kristof Szabados
**[Link to original bug (#569694)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569694)**
## Description
I have recently run into an interesting new tool called TornadoVM.
The developers c...## Submitted by Kristof Szabados
**[Link to original bug (#569694)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569694)**
## Description
I have recently run into an interesting new tool called TornadoVM.
The developers claim that it is just like a normal Java VM, but is able to automatically translate the code to graphic cards ... enabling large parformance improvements.
more information: https://jjfumero.github.io/files/Joker2019-TornadoVM_JuanFumero.pdf
I believe Titan should try it out, to see if the Java side could benefit from this.
Right now the Java side is faster than the C side for normal testing scenarios.
But if the encoder/decoder functions could be run on graphic cards (automatically if present), that could boost the Java side to be the primary platform for performance testing scenarios too.
Version: 7.2.0https://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/395merge project types once the Java side is good enough2021-05-06T16:15:34ZEclipse Webmastermerge project types once the Java side is good enough## Submitted by Kristof Szabados
**[Link to original bug (#569683)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569683)**
## Description
Currently we have in Titan 2 different project types.
One builds using C/C++, the o...## Submitted by Kristof Szabados
**[Link to original bug (#569683)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569683)**
## Description
Currently we have in Titan 2 different project types.
One builds using C/C++, the other using Java.
Please remember to merge them later into a single one, as that would make it easier for our users to use our tools.
Right now it they are kept separately for 2 reasons:
- the Java side was until recently in prototype stage and we wished to keep it separated from the C side for this reason.
- this made the development of the Java side easier, as we could gradually build it up, without having to worry about all the feature we could not yet support.
Version: 7.2.0https://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/394Improve logviewer's testcase extraction performance2021-05-06T16:16:37ZEclipse WebmasterImprove logviewer's testcase extraction performance## Submitted by Kristof Szabados
**[Link to original bug (#569674)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569674)**
## Description
When I by accident generated a large log file, with the results of 100.000+ testcas...## Submitted by Kristof Szabados
**[Link to original bug (#569674)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569674)**
## Description
When I by accident generated a large log file, with the results of 100.000+ testcases it became apparent that the LogViewer plugin has some performance problems in relation to extracting the list of testcases.
In this case:
- it took several seconds (should be faster)
- the screen went white (should not be done in a display thread)
- displaying the list of testcases cluttered the navigator view (maybe some other form of organizing could be better for such large lists)
Version: 7.1.0https://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/393The code smell checker detecting shorthand notations will need to be updated ...2021-05-06T16:17:30ZEclipse WebmasterThe code smell checker detecting shorthand notations will need to be updated once @nodefault is supported## Submitted by Kristof Szabados
**[Link to original bug (#569673)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569673)**
## Description
The TTF committee working on the TTCN-3 core standard has accepted the proposal for...## Submitted by Kristof Szabados
**[Link to original bug (#569673)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569673)**
## Description
The TTF committee working on the TTCN-3 core standard has accepted the proposal for the @nodefault feature also for interleave -s (CR 7991).
Using the @nodefault modifier testers can use shorthand notations without the risk of activating the activated defaults.
The very reason for which we have a code smell detector in Titanium.
This means, that once this feature is accepted into the standard and implemented in the Designer plugin (semantic checking of TTCN-3 code) ... this code smell spotter will also need to be updated.
Otherwise:
- it would mark correct shorthand statements too as erroneous (false positive detection)
- propose a sub-optimal correction for the issue.
Version: 7.1.0https://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/392Enable separation of modules which are parsed and modules which are checked2021-05-06T16:20:03ZEclipse WebmasterEnable separation of modules which are parsed and modules which are checked## Submitted by Anton Vikstrom
**[Link to original bug (#569630)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569630)**
## Description
(I am using Titan Designer Plugin 7/CAX 105 7730 R2A (7.2.pl0) but I could only selec...## Submitted by Anton Vikstrom
**[Link to original bug (#569630)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569630)**
## Description
(I am using Titan Designer Plugin 7/CAX 105 7730 R2A (7.2.pl0) but I could only select 7.1 in the menu.)
Our project is using ttcn3 modules from TCC_Releases. Our code depends on these modules, but they are not part of the project.
In the "Resources" tab, I can select which parts should be excluded or included in my project. As far as I can tell, if I turn on the on-the-fly checker, all modules in the project will get checked.
If I include the TCC_Releases modules in the project, I get reported Problems (errors/warnings) for these modules, which I do not want.
If I exclude the TCC_Releases modules from the project, they will not get parsed by the plug-in (it does not find modules outside of the project), so any imports will show up as broken.
I would like to be able to have the plug-in still parse all of the code (to allow for semantic check and jump-to-definition etc) but configure the on-the-fly checker to not report problems in all of the code. (For example, tell checker to only check or not check certain directories.)
Version: 7.1.0https://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/391Enable deactivation of warning: “Cases not covered for the following fields”2021-05-06T16:20:56ZEclipse WebmasterEnable deactivation of warning: “Cases not covered for the following fields”## Submitted by Anton Vikstrom
**[Link to original bug (#569629)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569629)**
## Description
I cannot find any way to deactivate the warning “Cases not covered for the following ...## Submitted by Anton Vikstrom
**[Link to original bug (#569629)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569629)**
## Description
I cannot find any way to deactivate the warning “Cases not covered for the following fields” (I can filter it away in Problems view, which is what I am doing now.)
I would like to have the ability to deactivate this warning, the same way as I can control other on-the-fly checker warnings.
I am using Titan Designer plugin version "7/CAX 105 7730 R2A (7.2.pl0)" but I could only select 7.1 in the menu on this page.
Version: 7.1.0https://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/388Add support for headless build and export of Titan Java projects2021-11-03T10:19:52ZEclipse WebmasterAdd support for headless build and export of Titan Java projects## Submitted by Kristof Szabados
**[Link to original bug (#569457)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569457)**
## Description
Currently it is possible to perform some general operations of the Titan plugins fr...## Submitted by Kristof Szabados
**[Link to original bug (#569457)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569457)**
## Description
Currently it is possible to perform some general operations of the Titan plugins from command line, via headless operations.
This includes:
- clearing workspaces
- importing projects from .prj and .tpd files
- invoking the build command of projects
- exporting Titanium code smell information of projects, into excel and CSV files (and the data for SonarQube).
- exporting Titanium metric measurements of projects.
- exporting project structures as detected by Titanium, into .dot and .net formats.
With compiling via Java code now being supported and becoming evermore feature rich, the need for 1 more headless action is growing.
Exporting the built code into a jar file.
Currently we are able to invoke the build process from headless mode.
But when the build process is over, we are left with .class files in the working directory of the project.
To be more useful, we would need to have .jar files for execution.
Eclipse already offers a feature to export the resources (of a Java project) into a jar file as a wizard on the user interface.
This new headless application would need to invoke that functionality programmatically.
Version: 7.1.0Adam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/386Java plug-ins: automatic execution of regression tests from Java command line2021-11-03T10:20:12ZEclipse WebmasterJava plug-ins: automatic execution of regression tests from Java command line## Submitted by Elemer Lelik
**[Link to original bug (#569244)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569244)**
## Description
Version: 7.1.0## Submitted by Elemer Lelik
**[Link to original bug (#569244)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569244)**
## Description
Version: 7.1.0Adam KnappAdam Knapp