ETSI's Bug Tracker - Part 01: TTCN-3 Core Language |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0000415 | Part 01: TTCN-3 Core Language | New Feature | public | 24-11-2006 14:33 | 24-04-2008 20:03 |
|
| Reporter | Stephan Schulz | |
| Assigned To | Ina Schieferdecker | |
| Priority | high | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | fixed | |
| Platform | | OS | | OS Version | |
| Product Version | v3.1.1 (published 2005-06) | |
| Target Version | v3.4.1 (published 2008-09) | Fixed in Version | v3.4.1 (published 2008-09) | |
| Clause Reference(s) | - |
| Source (company - Author) | dr. György Réthy, Ericsson |
|
| Summary | 0000415: Definition IDs |
| Description | In real test activities - especially in basic and function tests - logging and information being logged is one of the most important features. It is of utmost importance to effectively debug the TTCN-3 code, to be absolutely aware of what is happening during test execution and to effectively debug the SUT behaviour. For this reason users are often writing functions that are using TTCN-3 user logs to output the specific information they need. However, some information they want to log is changing dynamically during TTCN-3 code development (e.g. line number of the code generating the actual user log event), while others could be written manually but this is inefficient, inconvenient and is a potential source of errors.
The purpose of the feature is to introduce special TTCN-3 tokens beginning with a special ASCII character that is not used elsewhere in TTCN-3. The leading character shall be followed by an identifier from a predefined set.
The special tokens shall be substituted with a literal charstring values based on the rules below.
The tokens can appear anywhere in the TTCN-3 code where charstring literals are allowed (in expressions, log() statements, etc.). However, if the given token is not applicable in the corresponding context the compiler shall report an error. Substitution is not performed if the special token is given within a charstring value.
List of predefined identifiers:
Identifier Returns Applicable (type)
%moduleId name of the actual TTCN-3 module everywhere (compile time)
%fileName name of the actual TTCN-3 source file everywhere (compile time)
%lineNumber act. line no. in source code everywhere (compile time)
%definitionId name of function/altstep in functions& altsteps (compile time)
%testcaseId name of the testcase everywhere (runtime)
|
| Steps To Reproduce | |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | |
| Attached Files |  CR415-DefinitionIDs-Resolution.doc (125,440) 21-04-2008 15:45
http://oldforge.etsi.org/mantis/file_download.php?file_id=1422&type=bug
CR415-DefinitionIDs-Resolution-V2.doc (126,464) 22-04-2008 11:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=1426&type=bug
CR415-DefinitionIDs-Resolution-V3.doc (125,952) 22-04-2008 18:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=1435&type=bug
CR415-DefinitionIDs-Resolution-V4.doc (133,120) 24-04-2008 19:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=1456&type=bug |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 24-11-2006 14:33 | Stephan Schulz | New Issue | |
| 24-11-2006 14:33 | Stephan Schulz | Clause Reference(s) | => - |
| 24-11-2006 14:33 | Stephan Schulz | Source (company - Author) | => dr. György Réthy, Ericsson |
| 24-11-2006 15:03 | Stephan Schulz | Note Added: 0000331 | |
| 15-06-2007 19:13 | Stephan Schulz | Status | new => assigned |
| 15-06-2007 19:13 | Stephan Schulz | Assigned To | => Ina Schieferdecker |
| 13-10-2007 19:28 | Ina Schieferdecker | Assigned To | Ina Schieferdecker => Jens Grabowski |
| 17-10-2007 16:05 | Ina Schieferdecker | Note Added: 0003669 | |
| 18-10-2007 12:06 | Ina Schieferdecker | Target Version | => Edition 4.1.1 (not yet published) |
| 21-04-2008 15:45 | Jens Grabowski | Note Added: 0005477 | |
| 21-04-2008 15:45 | Jens Grabowski | File Added: CR415-DefinitionIDs-Resolution.doc | |
| 21-04-2008 15:46 | Jens Grabowski | Assigned To | Jens Grabowski => Gyorgy Rethy |
| 21-04-2008 19:57 | Gyorgy Rethy | Note Added: 0005483 | |
| 21-04-2008 19:59 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jens Grabowski |
| 22-04-2008 11:35 | Jens Grabowski | Note Added: 0005489 | |
| 22-04-2008 11:35 | Jens Grabowski | File Added: CR415-DefinitionIDs-Resolution-V2.doc | |
| 22-04-2008 11:36 | Jens Grabowski | Assigned To | Jens Grabowski => Gyorgy Rethy |
| 22-04-2008 11:37 | Jens Grabowski | Note Added: 0005490 | |
| 22-04-2008 16:29 | Gyorgy Rethy | Note Added: 0005499 | |
| 22-04-2008 16:30 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Thomas Deiß |
| 22-04-2008 18:41 | Thomas Deiß | File Added: CR415-DefinitionIDs-Resolution-V3.doc | |
| 22-04-2008 18:43 | Thomas Deiß | Note Added: 0005507 | |
| 22-04-2008 18:43 | Thomas Deiß | Assigned To | Thomas Deiß => Ina Schieferdecker |
| 23-04-2008 11:50 | Ina Schieferdecker | Target Version | Edition 4.1.1 (not yet published) => Edition 3.4.1 (not yet published) |
| 24-04-2008 19:52 | Ina Schieferdecker | File Added: CR415-DefinitionIDs-Resolution-V4.doc | |
| 24-04-2008 20:03 | Ina Schieferdecker | Status | assigned => closed |
| 24-04-2008 20:03 | Ina Schieferdecker | Resolution | open => fixed |
| 24-04-2008 20:03 | Ina Schieferdecker | Fixed in Version | => Edition 3.4.1 (not yet published) |
|
Notes |
|
|
|
|
The metainformation name should be generalize to allow user-defined metainfo names. |
|
|
|
|
|
candidate for a library - deferred to 2008 |
|
|
|
|
|
The attached proposal for resolution considers Definition IDs as preprocessor macros. This means a preprocessor can add the missing information before compilation. Runtime information can not be retrieved with this view. This means, that for example, the testcase ID or a call hierarchie of functions cannot be retrieved by this mechanism. |
|
|
|
|
a) Let __SCOPE__ returns "control" or "<modulename>.control" in control part; think about a logging function that may be called from a function or from a control part by passing __SCOPE__ as an actual parameer. It would be more logical is logs "control", than just the name of the module the control part is within.
b) Do we need double underscore? Wouldn't it be enough just one, like _SCOPE_?
c) Would be better to call them something else as "preprocessor macros", though I do not have a good proposal just now. |
|
|
|
|
Answer to <module name>.control:
changed in new proposal
Answer to double underscore question:
No, we do not need a double underscore, but a double underscore is used for the same preprocessing macros in C. Therefore, I have chosen the same notation.
Answer to name:
I changed to preprocessing macro and explained the meaning of this term. in the beginning of the proposed new annex. |
|
|
|
|
|
I forgot: We have to decide if the new annex should become normative or informative. |
|
|
|
|
|
I propose to make it a new mandatory annex (otherwise user cannot count on using it in test suites) - causes that references to shifted informative annexes shall be checked and corrected. |
|
|
|
|
__SCOPE__: <modulename>.control -> control
The reason to have this more consistent with the other scope units (except the module itself), crosschecked with Gyorgy and Jens.
Otherwise, fine for me. |
|