titan.EclipsePlug-ins issueshttps://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues2021-05-04T09:17:30Zhttps://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/400CFG file macro multiplication2021-05-04T09:15:19ZEclipse WebmasterCFG file macro multiplication## Submitted by Arpad Lovassy
Assigned to **Arpad Lovassy**
**[Link to original bug (#571311)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=571311)**
## Description
Implementing macro multiplication in the CFG file in t...## Submitted by Arpad Lovassy
Assigned to **Arpad Lovassy**
**[Link to original bug (#571311)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=571311)**
## Description
Implementing macro multiplication in the CFG file in the [DEFINE] section
Example:
[DEFINE]
DEF_1 := 10.0
DEF_2 :=
2.0
DEF_3 := 1.5
MUL_1 := ${DEF_1}*${DEF_2}
MUL_2 := ${DEF_1}*${DEF_2}*${DEF_3}
MUL_3 := ${DEF_1}*3*${DEF_2}*${DEF_3}
MUL_4 := ${DEF_1}*-1.0e2*${DEF_2}*${DEF_3}Arpad LovassyArpad Lovassyhttps://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/389Invalid error marker for port arrays in log2str2021-06-07T15:09:59ZEclipse WebmasterInvalid error marker for port arrays in log2str## Submitted by Anton Vikstrom
**[Link to original bug (#569624)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569624)**
## Description
Titan Designer plug-in (version "7/CAX 105 7730 R2A (7.2.pl0)", but this page would n...## Submitted by Anton Vikstrom
**[Link to original bug (#569624)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569624)**
## Description
Titan Designer plug-in (version "7/CAX 105 7730 R2A (7.2.pl0)", but this page would not allow me to select higher than 7.1.0) shows an invalid error marker:
“Refence to a value or template was expected instead of port”
when a port array is used in log2str. Titan transforms this without problem to a string so that port name can be used in the log, so this code is valid.
Minimal example:
~~~
import from IPL4asp_PortType all;
type component Minimal_CT
{
port IPL4asp_PT array_PT[1]
port IPL4asp_PT single_PT
}
testcase tc_log_port()
runs on Minimal_CT
{
setverdict(pass);
// No error markers:
log(single_PT);
log(log2str("Port named :", single_PT));
var charstring vl_logstring_1 := log2str("Port named :", single_PT);
// Error markers on all:
log(array_PT[0]);
log(log2str("Port named :", array_PT[0]));
var charstring vl_logstring_2 := log2str("Port named :", array_PT[0]);
}
~~~
Version: 7.1.0Miklos MagyariMiklos Magyarihttps://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 Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/384Generating code for semantically erroneous modules might be an idea to invest...2021-05-06T16:37:29ZEclipse WebmasterGenerating code for semantically erroneous modules might be an idea to investigate## Submitted by Kristof Szabados
**[Link to original bug (#569218)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569218)**
## Description
Right now when the C side of Titan encounter a syntactic or semantic issue in the c...## Submitted by Kristof Szabados
**[Link to original bug (#569218)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569218)**
## Description
Right now when the C side of Titan encounter a syntactic or semantic issue in the code, there is no code generation.
On the Java side there is no code generation for the module containing the issue.
But it might be worth to investigate if it would be beneficial to generate code also for such modules.
It might not be obvious at first, but if the issue to fix is not big ... this would mean that all other modules could already be generated (even if the Java compiler will also report error).
This way once the issue is finally fix in TTCN-3 code ... only a small amount of generated Java code might still need to be compiled.
Which could lead to the user perceiving the build time, to be even faster than now.
Version: 7.1.0https://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/383add support for debugging the Java Native Main Controller2022-06-30T12:41:33ZEclipse Webmasteradd support for debugging the Java Native Main Controller## Submitted by Kristof Szabados
**[Link to original bug (#569217)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569217)**
## Description
One of the main features missing from the first implementation of the Java Native M...## Submitted by Kristof Szabados
**[Link to original bug (#569217)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569217)**
## Description
One of the main features missing from the first implementation of the Java Native Main Controller is the support for debugging commands present in mctr_cli.
All of them can be supported, they just could not yet fit into the timeframe.
Supporting them, would enable to user, to debug how their tests are executing, while they are executing. Check where the flow of execution is at any point in time in the code.
Check the actual value of variables.
Step through their code step-by-step, carefully monitoring the system to find bugs.
Version: 7.1.0https://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/382Extend the Java native Main Controller to visualize the connections in the ru...2021-05-06T17:06:32ZEclipse WebmasterExtend the Java native Main Controller to visualize the connections in the running test setup dynamically## Submitted by Kristof Szabados
**[Link to original bug (#569216)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569216)**
## Description
With the new Java Native Main Controller in Eclipse, some never before seen feature...## Submitted by Kristof Szabados
**[Link to original bug (#569216)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569216)**
## Description
With the new Java Native Main Controller in Eclipse, some never before seen features could become possible.
For example visualizing the structure of the test system as it is executing.
The testers could follow how many HC -s and PTC -s are active in the system at any point in time.
How they are connected (could be drawn as a graph with the HCs and PTCs being the nodes, connections the edges).
Enabling the testers to have a never before seen level of understanding on how their tests are behaving during execution.
Version: 7.1.0https://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/381improve the granularity of parallel semantic checking to module internal parts2021-05-06T17:05:51ZEclipse Webmasterimprove the granularity of parallel semantic checking to module internal parts## Submitted by Kristof Szabados
**[Link to original bug (#569213)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569213)**
## Description
We have enabled parallel semantic analysis in the Titan plugins recently.
Which gre...## Submitted by Kristof Szabados
**[Link to original bug (#569213)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569213)**
## Description
We have enabled parallel semantic analysis in the Titan plugins recently.
Which greatly improves semantic checking and code quality checking times on modern (multi-core, multi-thread) processors.
The main reason behind this is simply the fact that in sequential execution the time of the complete duration of the analysis is the sum of the duration of analyzing single modules, while in parallel mode the number could be much smaller (in case there would be no dependencies between the modules it would be the maximum).
The logical step in this direction is to reduce the granularity of elements that are processed in parallel, to take more efficient care of the available processing power.
The idea here is that currently the limiting factor is the large imbalance in the module sizes that can appear in some project.
It could happen, that the project contains a large type description module with several hundred thousand lines of TTCN-3 code + several small TTCN-3 modules which only contain a few tests.
In such case the large module will have a dominating effect on the processing time, thanks to the over time being closely related to the max of the individual processing times (in case of dependencies there is still addition).
By improving the granularity and being able to analyze in parallel part of modules, this limitation would also be lifted.
In this case the large module itself could be processed in parallel on all available hardware cores/threads at the same time.
Bringing the overall utilization of the hardware closer to maximum, and processing time as low as possible.
Version: 7.1.0https://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/380Adding "special" support for intra JVM communication between PTC -s running o...2022-03-07T16:28:10ZEclipse WebmasterAdding "special" support for intra JVM communication between PTC -s running on the same machine## Submitted by Kristof Szabados
**[Link to original bug (#569210)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569210)**
## Description
On the C side there is a feature called "unix domain sockets", that is not directly...## Submitted by Kristof Szabados
**[Link to original bug (#569210)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569210)**
## Description
On the C side there is a feature called "unix domain sockets", that is not directly available from Java.
This feature lets unix processes exchange network messages without the messages ever touching the network cards, if they are located in the same machine.
While Java is not able to use this feature ... thanks to the architecture of how PTC -s are started on Titan's Java side, it might be possible to create a similar alternative.
For PTC -s running inside the same JVM it might be possible to realize, that they are inside the same JVM (as we have an outside view on the setup during execution) and could create connections between them, that exchange message without sending them out to the network cards.
This could create some measurable performance for inter-PTC communication (when they are on the same JVM).
And actually might also be useful in practice:
- in the case of smaller tests, all PTC -s might be running on the same machine/JVM for cost reasons.
- in case of larger, more distributed test scenarios, where there are many PTC -s running in parallel ... there is a good chance that some of them will be on the same machine (user can also affect this intentionally), leting us reduce the overhead of internal communications significantly.
Version: 7.1.0https://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/379code comments should also be checked2022-04-12T08:23:38ZEclipse Webmastercode comments should also be checked## Submitted by Kristof Szabados
**[Link to original bug (#569209)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569209)**
## Description
Right now Titan is only checking the TTCN-3 and ASN.1 code itself, but not the code...## Submitted by Kristof Szabados
**[Link to original bug (#569209)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569209)**
## Description
Right now Titan is only checking the TTCN-3 and ASN.1 code itself, but not the code comments within such file for quality.
This can create issues, where for example:
- [x] the documentation of a function lists different formal parameters than the function has.
- [ ] the documentation is full of grammatical errors.
- [ ] the documentation might not actually belong to where it is currently placed
Titan should check for such anomalies.
It should be possible to check the the formal parameters listed in the documentation against the actual formal parameters using the semantic database present in the Eclipse plugins.
Also eclipse does offer grammatical checking for comments ... a functionality that might also be callable from the Designer plugin itself.
And with some NLP it might also be possible to detect if the documentation is describing something completely different from the function where it is located.
Version: 7.1.0https://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/378new refactoring feature: detect constructs that could be classes and extract ...2021-05-06T17:01:18ZEclipse Webmasternew refactoring feature: detect constructs that could be classes and extract such classes out of them## Submitted by Kristof Szabados
**[Link to original bug (#569207)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569207)**
## Description
Now that Object Orientation is becoming supported by both the TTCN-3 standard and T...## Submitted by Kristof Szabados
**[Link to original bug (#569207)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569207)**
## Description
Now that Object Orientation is becoming supported by both the TTCN-3 standard and Titan users will have an interesting problem:
They might wish to turn their existing code base object-oriented ... but there is just too much code to do this by hand.
Titan could offer a new refactoring solution, that can detect constructs that resemble class/object like behavior and try to extract classes out of them.
For example when a component has only a few fields, each of which is private, only read/written from functions running directly on the component ... that is mot probably an indication, that the developers of the code wanted to use a class ... but that was not possible.
In such situations, it might be possible to automatically create a class with the needed members and functions + remove the extracted members from the component and remove the extracted functions for the code.
Version: 7.1.0https://gitlab.eclipse.org/eclipse/titan/titan.EclipsePlug-ins/-/issues/377much simpler test execution workflow for cloud environments on the Java side2021-05-06T16:59:41ZEclipse Webmastermuch simpler test execution workflow for cloud environments on the Java side## Submitted by Kristof Szabados
**[Link to original bug (#569206)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569206)**
## Description
Now that the Java side has both a native Java Main Controller, and can build native...## Submitted by Kristof Szabados
**[Link to original bug (#569206)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569206)**
## Description
Now that the Java side has both a native Java Main Controller, and can build native Java Host Controllers too, an interesting new opportunity is appearing to make test execution simpler.
It is possible to create a launching way, where the user only has to specify the cloud he wishes to use for the execution.
What can be done in such a situation:
- Titan is building the code, it knows if single mode execution is enough, or parallel mode execution is needed for a test.
- Titan could also have an informed guess on how many HC -s will be needed.
- As on the Java side Titan generates platform independent Java eecutables ... these could easily distributed in the could environment.
- From where the distributed HC -s could connect back the native Java MC for execution coordination.
And for the user this way of execution would be the most simple one possible.
He just has to select what to execute and in which cloud to use (could have a default setting on workbench level) ... and could start the execution.
Version: 7.1.0