emoflon/emoflon-ibex

Shared, eMoflon-specific component for incremental unidirectional and bidirectional graph transformations

emoflon-ibex's Issues

Attributes (4): Extend example to contain an attribute CSP

the CSP should contain eq, some other library constraints, and at least one user-defined attribute constraint.

Sync with Democles

Hi Greg,

I'm now slowly working on synchronisation...

Currently, I have the problem that I seem to be receiving multiple events for essentially the same match. Every time the handleEvent method is invoked, the MatchEvent is different but its DataFrame retrieved via event.getMatching() is exactly the same object.

Any ideas why this is happening? Is such behaviour expected or is something wrong?

The resource set seems to be perfectly ok, and the matches I am receiving make sense as well, just that I'm getting multiple events for the same match.

Cheers and thanks,
Tony

One event per match is not really suitable for MODELGEN

Incremental pattern matcher throws exactly one Event for each match. This is not suitable for MODELGEN as we can apply the same TGG rule only once on the same context.

A possible strategy would be to apply a rule immediately several times on the same context, perhaps with a random number generated within an intervall. We need to decide what would be useful and what do we want to provide. Then we should implement the strategy to avoid the problem described above.

add a README to our github project :)

Implement type specific eq constraints

... like eq_string, eq_int, eq_double, eq_boolean.... The generic eq constraint as we had so far does not suit well to the rest.

TODO is:

• Remove Eq.java
• remove the eq decleration when generating AttrCondDefLibrary.tgg
• Implement java classes of new type-specific constraints (like Eq_string.java)
• ensure that the new constraints are generated into AttrCondDefLibrary.tgg
• fix our only test project

Block ignore rule matches

if a rule is ignored, e.g., in forward direction (it does not translate any source element), then its FWD matches must be blocked. The most simple strategy would be to generate check(false) into the respective pattern so that everything else is handled uniquely.

Use helpful constants for strings generated in Application.java

Would be very nice to generate constants that one can just adjust at the beginning of the file for all the strings generated in Application.java

Generate Green Patterns (xtend code) for FWD, BWD, CC...

... and later Modelgen.

In order to handle brute force and normal algorithm in a unified manner, please do not create EMF-edges in these patterns but just Edge-Objects. A procedure will then iterate over (chosen) edges and will invoke eSet.

Note that Source and Target of correpsondences are not edges anymore (as opposed to the old implementation). So you can directly set the source and target of a correpsondence in the xtend code.

Find a TGG example attached
ibex test.zip

Forbid "_" as suffix or prefix for object variables in the editor

... as pattern matcher and our backend use the prefix and suffix convention with "_" for different purposes.

TODO is to write a validation rule.

Design and implement support for refinements

There are plans to support refinements by pattern invocation. I see two alternatives here:

Alternative 1: Additional restrictions on refinements: no overriding of nodes in refining rules but only enlarging the rule pattern is allowed. Then the refined rule is simply a subpattern of the refining rule.

Alternative 2: pattern invocation only on parts that are not overridden. This requires a detection of what is reused in the refining rule and what is being overridden.

Alternative 1 is easier to support (and I would prefer it) but backward compatibility is again an issue due to additional restrictions

Create PSF with working sets and set of projects

So we can use the normal eMoflon infrastructure to check out and build the workspace

Attributes (3): Handle in-place attribute constraints and assignments in our compiler

Extend the TGG compiler as follows: (i) in each operationalisation, attribute assignments might have to be converted to constraints (if green becomes black). (ii) for in-place attribute constraints and assignments, corresponding parts of Viatra queries should be generated. This should be possible as only constants (EDataTypes) are allowed on the right hand part of the expression.

DEC - handle multiple entry points

Currently what we do when we generate DECs is to search for a possible dangling edge.
Given that we found such, we check if there is some other rule application that is still able to translate it given that we apply the current rule.
The problem is now that there is not necessarily just one possible candidate edge in another rule but possibly many of them.
The question is now what to do with them.
The current approach just takes one of these candidates and checks for them which might not be so clever in case that src- or trg-nodes also have attribute constraints that have to be fulfilled.

Can this be shortened? Looks awful in code...

org.emoflon.ibex.tgg.operational.csp.constraints.factories.UserDefinedRuntimeTGGAttrConstraintFactory

find out what takes so long in builder

my impression is that we build multiple times. This can be investigated with profiling where the number of method invocations are counted

Currently unable to build FamiliesToPersonsDeterministic in branch startingWithTests

Due to a concurrent modification exception. I think this has something to do with the fact that I have a TGG rule only in one domain (an ignore rule).

Generate type check patterns for green elements

this won't be trivial as the current code generation for (negative) pattern invokations is not really designed for that

Attributes (6): Solve CSP and set values

Extend handling of "green" parts of patterns (ask @erhanleblebici exactly which class does this) to first of all solve the CSP of the rule and then use the determined attribute values in the green parts.

Solving the CSP means:

1. Sorting the constraints (ask @anthonyanjorin which classes can be taken from eMoflon).
2. Generating some code to solve the constraints in this order (code generation is probably the easiest here as we have to access and use user implemented constraints in the workspace).
3. Green pattern handling then takes a "csp object" of some kind with the solution, and uses these values to create the required structure.

Visualisation Framework for Ibex

Reengineer and reimplement visualisations for all relevant models in ibex. Perhaps even for .ecore, .vql and anything else we want to work productively with.

It would be nice to use this as a first bootstrap with ibex for ibex, and make first experiences how the new framework performs in a deployed context.

Ensure that each parameter in a pattern signature is referenced in the pattern body at least once

there will be compilation errors otherwise

Extend TGG vis to cover inline attribute conditions / CSPs

With CSPs note that constraints can be quite long. I would either reduce this to a fixed length with ... at the ending, or perhaps add line breaks automatically.

import for ibex.runtime is missing in MANIFEST of a fresh integration project created via wizard

Allow CSPs with Enums

Editor Tasks:

• specifying user-defined CSPs with Enum Parameters. For example

#userDefined myCustomCSP(a: EString, b: MyEnumType)

• using Enum-Literals as Constants when invoking such CSPs in TGG rules. For example

myCustomCPS(foo.name, enum::MyEnumType::MyLiteral)

Compiler Tasks:
Make sure that such CSPs in the editor are transformed to the TGG model and considered in TGG compiler analogously to all other CSPs

Our CDtoDoc example in the repostiroy already provides a source metamodel with enum.

Attributes (2): Extend Editor-TGG to Internal-TGG transformation to handle in-place attribute constraints and assignments

Extend the transformation so that all in-place attributes and constraints are transformed to our internal TGG model.

Use Gurobi Java-API directly for ILP solving

...as the currently used java-LP doesn't work for Mac

OR invocation in Democles

Is it possible to have a pattern construct in democles where the invocations are combined using OR instead of AND? As far as I know, I could implement it myself, although I'm not sure if that would be unproblematic. The question is if such a construct already exists.

Refactoring: Avoid static methods

for example in utils such as ManipulationUtil. In general, avoiding static methods entirely is a good idea to simplify the code. In ManipulationUtil, for example, introducing state set by the constructor could significantly reduce the number of arguments that have to be passed into all the methods.

Design and implement support for NACs

emoflon.ibex currently doesn't support NACs. There are some open decisions before starting the implementation work:

• Do we only support NACs with one node/edge as it was the case before? Or we support complex NACs that go beyond single nodes/edges? Do we plan to support nested NACs?

• If we support complex (and perhaps nested NACs): How should the textual syntax look like? What about backward compatibility?

My impression so far: it won't make any difference for pattern matcher between complex and one node/edge NACs (both are realized via negative pattern invocations). I'm rather concerned about the design and the backward compatibility of textual syntax if we allow complex NACs.
Nested NACs seem to me too ambitious for the first version, but clearly feasible with regard to pattern matching.

Avoid generating code to speed up build times

Viatra can be used without generating code from the .vql files
For our use case we do not require this generated code and should avoid this completely (I'm not quite sure how to do this yet).

If build times are still intolerable, we should also avoid generating any .xtend files and just generate Java code directly.

Redesign the naming of pattern variables for attributes

Currently, pattern variables for attributes are named like:
node.name + "_" + attrExpr.attribute.name in PatternTemplate.xtend

Two things are to do:

1. Extract this naming to a helper method (see, for example, EdgePatternNaming.java) as we can only control our name conventions if we centralize them.

2. change the naming such that it is more unlikely to come to clashes.
   @anthonyanjorin how can we avoid name clashes between TGG rule variables and our internal variables? Internal variables are things like edge wrappers, protocol nodes, attribute variables in patterns. What do you think about adding _emoflonIbex suffix everywhere and forbidding this to use in TGG rules?

Think of what to do for empty patterns

A solution would be to generate check(true);

Democles Demo

Hi @gervarro,

after spending a few hours trying to understand the trainbenchmark (and getting the incr. PM to run for my example based on it) I've basically given up.

I've started a minimal example here: https://github.com/eMoflon/emoflon-ibex/tree/democlesTrial and have added some todos for you.

Basically, all I want to understand for the moment is the initialisation code required to get the incremental pattern matcher up and running with minimal effort. All I need for the moment is to be able to then react to the matches found.

In the project there are trivial source, target and correspondence metamodels under /model. Under /instance there is a trivial input model basically consisting of exactly one source element.

I have also specified a very simple pattern that should match for exactly this source element, i.e., in this example a match should be found and I want to react to it by applying a forward rule (and creating the corresponding target element).

Thanks for your help!
Tony

Improvements of pattern vis

1. Local variables
2. Parameter passing for pattern invocation
3. or patterns

Rename projects to ibex...

Remove ibex.tgg.core.runtime from project dependencies added by new project wizard

Generate java classes to run the transformation

probably separate classes for FWD, BWD, CC, Modelgen, FWD_Synch, BWD_Synch

Create imports in generated pattern files

For every pattern parameter that is an EClass, go up to its containing EPackage, and collect an import for it in a set (to avoid duplicates). Maintain a unique label to access the package such as "pkg_i" with index variable i.

Generate for all collected imports import statements of the form:
import <package_i uri> as pkg_i

The type can then be referred to in the pattern as pkg_i::TypeName (this is a bit verbose but avoids the problem of having types of the same name).

Automate Package registration

For imports in the TGG editor of the form "platform:/resource//.ecore"
we can automatically generate code performing the registration of the ecore file as follows:

Resource r = resourceSet.getResource(URI.createFileURI("../<project>/<pathToEcore>.ecore"));
EPackage p = (EPackage)r.getContents().get(0);
Registry.eINSTANCE.put(r.getURI().toString(), p);
Registry.eINSTANCE.put(p.getNSURI(), p);
Registry.eINSTANCE.put("platform:/resource/<project>/<pathToEcore>.ecore", p);

For all other imports we should generate a TODO for the user:

//TODO: Register EPackage for dependency: <import>

Creating a new project leads to the following error

The constructor FWD(TGG, Resource, Resource, Resource, Resource) is undefinedin the generated Application.java.

Attributes (1): Extend current TGG example in our repo to include simple "in-place" attribute assignments and constraints

Extend our current CDToDoc TGG with in-place attribute constraints, e.g., name == "foo" in a node, and attribute assignments, e.g., name := "foo" in a node.

Everything should still work, but these in-place attribute constraints and assignments will simply be ignored.

Modify CSPs to use variables field instead of parameters

Clean up code and old implementation (of MOSL builders etc)

This code should be simplified and restructured (still from the master's thesis!)

Attributes (5): Extend Editor-TGG to internal TGG transformation to cover CSPs

Extend the trafo so CSPs are also produced in our internal TGG models.

Use package aliases (dep_i) in generated patterns

otherwise name clashes between source and target classes will be a problem in generated patterns

Documentation: Write a brief JavaDoc for each class...

with an explanation of the primary responsibilities of the class (and other classes it collaborates closely with).

Migrate all Test tggs to ibex

We should soon start trying to migrate Test tggs to ibex (so we can avoid regressions).

Even though we are still missing refinements and NACs, some tggs might already work as soon as we have implemented CSPs...

I also suggest we use the new benchmarx framework for our tests.

the new DEC concept

Correspondence metamodel is not imported properly in pattern files

at least not for this example: https://github.com/eMoflon/emoflon-ibex/files/572503/ibex.test.zip

Attributes (7): Generate stubs for user-defined attribute constraints

Generated stubs for user-defined attribute constraints according to required conventions (name and location).

The ibex builder must make the project a valid Viatra project

... by adding the required nature, builder, and the runtime plugin dependency.