764 Taste shd01 maxime high major always assigned open none TASTE-IV/DV 1524642113 1638439912 none public

Can't reuse functions due to namespace conflicts

1 I created a container function, with some functions inside, to use as a generic block for a redundant subsystem. When I import this block into a project for the second time, TASTE renames all the contained functions to default names (e.g. Function6). This is tedious as I have to rename all the functions by hand to something unique, and then create new behavioural code. I can't have a single source for the implementation. What I would really like is a clean facility to be able to reuse or duplicate modules, perhaps by creating libraries. For the time being, I could get by with a hierarchical namespace, i.e. where names are only required to be unique within a function. I've made this a major severity report as I think it is an impediment to serious use of TASTE in systems modelling. 669 Taste maxime gmamais normal feature have not tried assigned open none ASN.1 Compiler v4 1504172221 1531224564 none public

Improvements of asn1scc (WUT)

1 In order to iterate on this - and define priorities, I summarize here the list of issues reported by WUT: 1. Missing/Incomplete documentation (we have no real end-user documentation of the compiler (apart from the ACN part).) 2. Management of errors : * [*DONE*] Lack of automatic constraints check in Decode functions (Add call to isConstraintValid after decoding) * Usage of assert in asn1scc generated functions * [*DONE*] Returning of unnamed / undefined error codes 3. Misleading initialisation of a kind attribute for ASN.1 CHOICE construction (Some confusion with the NONE choice) 4. Bitstream structure issues (arious issues, such as the meaning of the "count" field which is different for encoding and decoding) 5. Not sufficient model consistency checks 6. Ambiguity in the definition of the required buffer sizes for encoding ("+1 for zero-sized type" is not documented) 7. Quality of the asn1scc-generated test suite 411 Taste ttsiodras gmamais normal feature N/A feedback reopened none ASN.1 Compiler 1422264667 1530779748 none public

Improve rename policy for enumerants

1 Improve the so-called “rename policy” for enumerants of CHOICE / ENUMERATED types – thus providing consistency between C/Ada. 699 Taste miguel_munoz maxime normal minor have not tried assigned open none General 1509026956 1516722115 none All public

Native encoding not checked between nodes of different architecture

1 The editors and code generation allow that an interface with parameters set to native encoding is deployed between nodes that have a different architecture (e.g. x86 and leon). The information contained in the models should be sufficient to detect this condition, and report an error. Otherwise, at runtime, this will produce garbage data or possibly a crash. 82 Taste maxime normal feature N/A new open none PolyORB-HI-All 1294829115 1297107122 none public

Add runtime configuration for communication drivers

1 Add a mean to configure network configuration from the user code. For example, the IP address and port number could be determined dynamically rather than being fixed in the AADL code. Expected benefit: allow users to build native client-server applications with minimal effort Specifying the possibility for a driver to be reconfigured at runtime should be a feature of the ASN.1 model of the driver configuration. Eg. Available-devices ::= ENUMERATED { eth0, eth1 } Ethernet ::= SEQUENCE { default-device Available-devices, port INTEGER (0..65535), ip IA5String (SIZE (3..11)), reconfigurable BOOLEAN } Then when the user sets the Ethernet values in the Deployment view he would write: { default-device eth0, port 80, ip "192.168.1.1", reconfigurable true } In addition to Send and Receive, the driver should in turn contain some form of reconfiguration API, of course.