relational-rags issueshttps://git-st.inf.tu-dresden.de/jastadd/relational-rags/-/issues2022-07-27T13:07:44+02:00https://git-st.inf.tu-dresden.de/jastadd/relational-rags/-/issues/34Array types not supported2022-07-27T13:07:44+02:00René SchöneArray types not supportedsee https://git-st.inf.tu-dresden.de/jastadd/relast-preprocessor/-/issues/12see https://git-st.inf.tu-dresden.de/jastadd/relast-preprocessor/-/issues/12https://git-st.inf.tu-dresden.de/jastadd/relational-rags/-/issues/33Move pages to mkdocs2022-03-11T09:39:48+01:00René SchöneMove pages to mkdocshttps://git-st.inf.tu-dresden.de/jastadd/relational-rags/-/issues/32Update to current gradle (7.4)2022-02-17T17:45:19+01:00Johannes MeyUpdate to current gradle (7.4)Johannes MeyJohannes Meyhttps://git-st.inf.tu-dresden.de/jastadd/relational-rags/-/issues/31Resolving of References in NTAs2022-02-11T09:58:14+01:00Johannes MeyResolving of References in NTAs## Problem
Unresolved references in NTAs are not resolved when calling `treeResolveAll()`, because this method traverses using the `getChild()` method.
## Discussion
For NTAs specified in the grammar with `/SomeNTA/`, this can be solv...## Problem
Unresolved references in NTAs are not resolved when calling `treeResolveAll()`, because this method traverses using the `getChild()` method.
## Discussion
For NTAs specified in the grammar with `/SomeNTA/`, this can be solved by generating specific `treeResolveAll()` methods for the nonterminals containing such NTAs.
For NTAs specified in an aspect, this is hard to solve, because we don't know about these NTAs at all in the relast preprocessor.
However, this points to another problem. While `getChild()` is marked as `low-level`, it is still used in some cases. Thus, resolving should be triggered there instead of in the high-level getters.
Finally, since @johannes.mey is preparing a complete overhaul of the resolution mechanism with the goal of not having *any* resolver logic in the final generated classes, all of this discussion might be obsolete.Johannes MeyJohannes Meyhttps://git-st.inf.tu-dresden.de/jastadd/relational-rags/-/issues/30Behaviour of treeCopy2021-02-03T09:33:21+01:00Johannes MeyBehaviour of treeCopyWhen copying a tree with relations, these relations still point in the old tree. This may be desired in some cases, but not in all (e.g., when a copy of an entire AST should be done).
There should be a concept of how to handle this.When copying a tree with relations, these relations still point in the old tree. This may be desired in some cases, but not in all (e.g., when a copy of an entire AST should be done).
There should be a concept of how to handle this.Johannes MeyJohannes Meyhttps://git-st.inf.tu-dresden.de/jastadd/relational-rags/-/issues/29Reordering of children does not work2023-03-06T13:33:15+01:00René SchöneReordering of children does not workGiven the following grammar, ...
```
Nameable ::= <Name> ;
A : Nameable ::= B MyC:C ;
SubA : A ::= MyC:C B ;
B;
C;
```
... the following (wrong) constructor is being generated:
```
public SubA.SubA(String Name, B B, C MyC, C MyC, B B)...Given the following grammar, ...
```
Nameable ::= <Name> ;
A : Nameable ::= B MyC:C ;
SubA : A ::= MyC:C B ;
B;
C;
```
... the following (wrong) constructor is being generated:
```
public SubA.SubA(String Name, B B, C MyC, C MyC, B B)
```
The problem is located in the attribute `componentsTransitive` in `backend/Analysis.jrag`https://git-st.inf.tu-dresden.de/jastadd/relational-rags/-/issues/26Creation of jar in CI fails2023-03-06T13:36:59+01:00René SchöneCreation of jar in CI failsLast words of the job `jar` are always
```
Uploading artifacts...
WARNING: /builds/jastadd/*/build/libs/*relast*.jar: no matching files
ERROR: No files to upload
Job succeeded
```Last words of the job `jar` are always
```
Uploading artifacts...
WARNING: /builds/jastadd/*/build/libs/*relast*.jar: no matching files
ERROR: No files to upload
Job succeeded
```https://git-st.inf.tu-dresden.de/jastadd/relational-rags/-/issues/22Interfaces or Multiple Types as Relation Endpoints2020-01-11T23:27:22+01:00Johannes MeyInterfaces or Multiple Types as Relation Endpoints
> :warning: this issue is still work in progress!
In some cases, a relation endpoint may not be one type, but a collection of types with a common interface. This is currently not possible, since interfaces are not defined in the gramma...
> :warning: this issue is still work in progress!
In some cases, a relation endpoint may not be one type, but a collection of types with a common interface. This is currently not possible, since interfaces are not defined in the grammar but in aspects.
This is mainly because the support for interfaces is part of the AOP-features not directly related to the grammar, so there is no support to add ast children to interfaces.
### Occurrence
Interfaces could be used in two places:
1. A nonterminal type implements an interface.
2. A nonterminal has a child with the type of an interface.
**Proposed Design Decision**: Only support variant 1. Variant 2 would probably require changes to JastAdd itself, while the first variant can be compiled down to plain JastAdd grammar and inter-type specifications.
## Lightweight: Union Types
- anonymous syntax proposal:
- `rel {TypeA,TypeB}.monitors* <-> {TypeB,TypeC}.monitoredBy*` or `rel (TypeA | TypeB).monitors* <-> (TypeB | TypeC).monitoredBy*`
- would generate interface like `UnionTypeATypeB` and `UnionTypeBTypeC`
- named syntax proposal:
- `interface Monitor;`, `interface Monitored;`
- `TypeA implements Monitor;`, `TypeB implements Monitor;`, `TypeB implements Monitored;`, `TypeC implements Monitored;`
- `rel Monitor.monitors* <-> Monitored.monitoredBy*`
- generated code:
- interface does only contains two methods for each type that implements it: `abstract boolean isTypeX();` and `abstract TypeX asTypeX();`
- maybe default implementations of Java could be used in the generated interface to reduce code length
- the correct implementation of these methods must be added to all implementing types
- discussion:
- :heavy_plus_sign: lightweight, not much implementation required
- :heavy_minus_sign: since the interface contains no other methods, the "cast" methods (or actual casts) are always required when navigating them
- cannot simply be used to in situations where Java interfaces were used
## Heavyweight: "Interfaces Types"
### Syntax
An interface declaration has the same structure as a type declaration with the following differences:
- It has exactly one modifier, `interface`.
- That means that it must not have a modifier `abstract`; the abstract modifier indicates that the type can not be instantiated, which is always true for an interface by definition.
- It may contain supertypes, but these supertypes may only be interfaces as well.
- supertypes are a comma-separated list in the place that previously contained one superclass
- This entails separate inheritance hierarchies for interfaces and types; mixing them would break the "natural" mapping to Java concepts.
Types can implement zero or more interfaces:
- (classic) types may contain supertypes are a comma-separated list in the place that previously contained one superclass
- only one of the supertypes can be a class, the others must be interfaces
Examples:
```
interface Named ::= <Name>;
interface Typed ::= ;
interface ElementContainer ::= Element*;
interface NamedElementContainer : ElementContainer,Named ::= ;
abstract ModelElement : Named ::= ;
Class : ModelElement,NamedElementContainer,Typed ::= /* children */ ;
```Johannes MeyJohannes Meyhttps://git-st.inf.tu-dresden.de/jastadd/relational-rags/-/issues/17Incomplete deserialization of inherited children and relations2020-01-10T14:06:00+01:00Johannes MeyIncomplete deserialization of inherited children and relationsInherited children are not deserialized if not the highest deserialization method in the class hierarchy is used. The intended reuse works in the Train case, but not in general. Also, the tests should be extended!Inherited children are not deserialized if not the highest deserialization method in the class hierarchy is used. The intended reuse works in the Train case, but not in general. Also, the tests should be extended!Johannes MeyJohannes Meyhttps://git-st.inf.tu-dresden.de/jastadd/relational-rags/-/issues/16Create getNumX for list relations2020-01-10T14:04:57+01:00Johannes MeyCreate getNumX for list relationsat least for the JastAdd-like API, this would align the interface a little more.at least for the JastAdd-like API, this would align the interface a little more.Johannes MeyJohannes Meyhttps://git-st.inf.tu-dresden.de/jastadd/relational-rags/-/issues/14Remove does not work if references have not yet been resolved2020-01-10T14:09:39+01:00Johannes MeyRemove does not work if references have not yet been resolvedThe field access must be replaced by a list accessor, otherwise the following remove operation fails, because the object is not in the list (only an unresolved reference to it).The field access must be replaced by a list accessor, otherwise the following remove operation fails, because the object is not in the list (only an unresolved reference to it).Johannes MeyJohannes Meyhttps://git-st.inf.tu-dresden.de/jastadd/relational-rags/-/issues/13Serialization of custom token types2020-01-10T14:05:43+01:00JesperSerialization of custom token typesIt would be nice if the serializer could support serialization of tokens using custom data types, for example:
```
Car ::= <Engine:Engine>;
```
Where the `Engine` is not a subtype of `ASTNode`.
## Gson
One way of supporting automatic...It would be nice if the serializer could support serialization of tokens using custom data types, for example:
```
Car ::= <Engine:Engine>;
```
Where the `Engine` is not a subtype of `ASTNode`.
## Gson
One way of supporting automatic serialization would be to use Google's gson library to serialize the token object (`Gson.toJson(object)`). This way many simple object structures could be automatically serialized.
For example, if the engine object looks like this:
`{ "valves": 16, "volume": "5L" }`
we would have to add the object type so that the deserializer knows what to do with the token:
`{ "type": "my.package.Engine", "value": { ... } }`
When deserializing, reflection can be used to find the class `my.package.Engine` and then the object is deserialized by using `Gson.fromJson(json, class)` where `class` is the class object for `my.package.Engine`.
Here is a small demonstration of serializing a simple object with gson:
```java
import com.google.gson.*;
import java.util.*;
public class Test {
public static void main(String[] args) {
Beta beta = new Beta("X");
beta.children = new Beta[] { new Beta("Y"), new Beta("Z") };
Gson gson = new Gson();
String json = gson.toJson(beta);
System.out.println(json);
Beta unparsed = gson.fromJson(json, Beta.class);
System.out.println(gson.toJson(beta));
System.out.println(gson.toJson(new Date()));
}
}
class Beta {
String name;
Beta[] children = new Beta[0];
Beta(String name) {
this.name = name;
}
}
```
This gives the following output:
```
{"name":"X","children":[{"name":"Y","children":[]},{"name":"Z","children":[]}]}
{"name":"X","children":[{"name":"Y","children":[]},{"name":"Z","children":[]}]}
"Mar 20, 2019 2:19:20 PM"
```
## Jackson
I tried to implement the same approach as above using Jackson instead of Gson but it seems that Jackson requires the user to implement custom serialization methods on all the objects that will be serialized.
```java
import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.core.JsonProcessingException;
import java.util.*;
import java.io.*;
public class Test {
public static void main(String[] args) throws JsonProcessingException, IOException {
Beta beta = new Beta("X");
beta.children = new Beta[] { new Beta("Y"), new Beta("Z") };
ObjectMapper mapper = new ObjectMapper();
String json = mapper.writeValueAsString(beta);
System.out.println(json);
Beta unparsed = mapper.readValue(json, Beta.class);
System.out.println(mapper.writeValueAsString(beta));
System.out.println(mapper.writeValueAsString(new Date()));
}
}
class Beta {
String name;
Beta[] children = new Beta[0];
Beta(String name) {
this.name = name;
}
}
```
```
Exception in thread "main" com.fasterxml.jackson.databind.exc.InvalidDefinitionException: No serializer found for class Beta and no properties discovered to create BeanSerializer (to avoid exception, disable SerializationFeature.FAIL_ON_EMPTY_BEANS)
```https://git-st.inf.tu-dresden.de/jastadd/relational-rags/-/issues/10Node removal with bidirectional references2020-01-10T14:09:25+01:00Johannes MeyNode removal with bidirectional referencesWhen removing a node, remove all bidirectional references to the node.
Otherwise, removing a node is unnecessarily complicated.When removing a node, remove all bidirectional references to the node.
Otherwise, removing a node is unnecessarily complicated.Johannes MeyJohannes Meyhttps://git-st.inf.tu-dresden.de/jastadd/relational-rags/-/issues/7Create set(int i, X o) and add(int i, X o) for relations with multiplicities2020-01-10T14:08:53+01:00Johannes MeyCreate set(int i, X o) and add(int i, X o) for relations with multiplicities`add()` with a postition is important for parsers, `set()` should be supported for completeness.`add()` with a postition is important for parsers, `set()` should be supported for completeness.Johannes MeyJohannes Meyhttps://git-st.inf.tu-dresden.de/jastadd/relational-rags/-/issues/3treeCopy and intrinsic references2020-01-10T14:10:29+01:00Johannes MeytreeCopy and intrinsic referencesUsually, `treeCopy()` is used to copy subtrees. The copying process copies terminal values directly, and, since intrinsic references are treated as terminal values, it also copies those directly.
There are two cases to consider:
* the i...Usually, `treeCopy()` is used to copy subtrees. The copying process copies terminal values directly, and, since intrinsic references are treated as terminal values, it also copies those directly.
There are two cases to consider:
* the intrinsic reference points outside of the copied fragment. In this case, the value of the intrinsic reference can be copied.
* the intrinsic reference points to a non-terminal in the subtree to be copied. In this case, the value of the reference should probably point to the copy of the old target.
Proposed change: treeCopy() has to be modified for all nonterminal types containing intrinsic references.Johannes MeyJohannes Mey