TASTE bugtrack - Issues

0000764: Can't reuse functions due to namespace conflicts

Thu, 02 Dec 2021 10:11:52 +0000

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.

0000669: Improvements of asn1scc (WUT)

Tue, 10 Jul 2018 12:09:24 +0000

In order to iterate on this - and define priorities, I summarize here the list of issues reported by WUT:

Missing/Incomplete documentation (we have no real end-user documentation of the compiler (apart from the ACN part).)
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

Misleading initialisation of a kind attribute for ASN.1 CHOICE construction (Some confusion with the NONE choice)
Bitstream structure issues (arious issues, such as the meaning of the "count" field which is different for encoding and decoding)
Not sufficient model consistency checks
Ambiguity in the definition of the required buffer sizes for encoding ("+1 for zero-sized type" is not documented)
Quality of the asn1scc-generated test suite

0000411: Improve rename policy for enumerants

Thu, 05 Jul 2018 08:35:48 +0000

Improve the so-called “rename policy” for enumerants of CHOICE / ENUMERATED types – thus providing consistency between C/Ada.

0000699: Native encoding not checked between nodes of different architecture

Tue, 23 Jan 2018 15:41:55 +0000

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.

0000082: Add runtime configuration for communication drivers

Mon, 07 Feb 2011 19:32:02 +0000

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.