gts-morpher / gts_morpher Goto Github PK

Node identifiers are not correctly renames when collided. In the attached example, two Observer objects are added (of qualified classes left__Observer and right__Observer), but their ids are not changed (both o).

pls_repeated_ids_bug.zip

Should add a validation that sanity checks any interface_of statements to ensure the use of @Interface annotations is sensible. For example, where a reference is annotated as @Interface, it makes sense to expect that the classes at either end are also annotated in this way...

Currently, auto-completion is effectively a brute-force search, which can become quite expensive. Should explore whether search-based approaches such as https://www.sciencedirect.com/science/article/pii/S0164121214001484 or work from sub-graph matching (e.g., https://github.com/ciaranm/glasgow-subgraph-solver) can help improve this.

I frequently use Pair as the key for a cache or similar lookup. Unfortunately, Pair doesn't actually implement hashCode and equals in a useful manner, so doesn't really work as a cache key. Need to replace with proper objects.

Currently, this uses node names, which is wrong. Node names should only be used to resolve references from inside a .gts file. Instead, we should use Henshin's mappings.

To avoid problems with dangling references I added a new removal rule, but now it wouldn't amalgamate the gts.

pls_link_deletion_bug.zip

I'm not sure whether this is an issue or a misinterpretation, but in either case it should result in a clarification in the documentation or in an implementation fix. For me, a virtual identity should be interpreted as the maximal identity (the preserve part) found in the interface part of the source rule. However, as this example shows, it expects the rule to be an extension.

The example breaks the counter example in an Observer GTS, to be able to have different types of observers, and a Counter subclass to count element instances.

pls_maps_to_id_rules_bug.zip

If a rule has a variable, this is currently not copied into the woven rule.

The model is wrong, the counter should have a top element which get mapped to the top element of the target model. However, with this definition the completion takes the initialization rule to all remaining rules, which then get joined in one single rule.

pls_joined_rules_bug.zip

If a complete morphism is marked as auto-complete, we issue a warning. When weaving as part of the build process, any GTS weaving off of such a morphism is ignored. Instead, the warning should be disregarded.

Allow users to provide an inclusion hint when claiming unique auto-completability. This requires source and target metamodel and rules to be the same up to some filtering (currently only interface_of) and will auto-complete by object identity.

weave should export the completion morphisms when exporting the GTS so that models can be transformed from the original meta-models to the amalgamated meta-model. Could, potentially, even generate the required Henshin transformation directly?

Paco will, hopefully, look at some examples of what Shift and implication mean for flat PACs/NACs and (perhaps) simple OCL expressions and then we can decide which of these to implement in the tool first.

By mistake, I was using the name (TaintablePLS) of of one of the GTS being amalgamated as name of the new GTS.

pls_internal_error_name_clash_bug.zip

The use of the dontLabelNonKernelElements weaving tag breaks the tool.

pls_head_counter_dontLabelNonKernelElements.zip

see http://www.xpect-tests.org/

Currently blocked by an e-Motions issue

Can I have attributes in interfaces?
I can mark them explicitly in the ecore model, but they cannot be mapped, right?

vs.

Rather than having to say gts, it would be good to allow people to say xdsml as an acknowledgement that that's really what the GTS are here.

The tool currently only supports Henshin-based GTSs. We should add a pivot layer to enable support for arbitrary GTSs. I have made some start on this already, but had to move it out for now as the EMF/Xtext wrangling got too much and distracted from the main purpose of the tool.

The exploration/discussion has provided some insights into how to get this done, though. The core idea is to do something similar to what Ed Willinks did for his OCL Pivot model: this is a separate model in a separate resource. The URI for this resource is of the form *.x.oclas where x is an extension specific to a particular language. A special resource factory creates resources for oclas files and these translate on first load. Otherwise, they're pretty much normal resources. The only thing that remains to do then is to get Xtext to load the oclas resources. I was originally thinking of fiddling with how Xtext finds resources and to create virtual resources for all resources to be wrapped. I now think there's actually a much easier way by asking the user to explicitly import the pivot resource into their morphism specification.

Links

• This thread on the Xtext forum has the discussion of some of my ideas
• Branch feature/behaviour_mapping_resource_factory_approach has the latest state of my developments in this direction (not currently functional and not supporting the latest tool features)

Related to #21 and #23, but I expect there may be wider implications. Need to make sure that this is covered well with tests.

It might be interesting to look into Henshin units amalgamation. I don't see how to put them together in general, but there must be some notion of compatibility between application strategies that we may explore. Even if no general method, if there are units only in the system being instantiated, by including the units as such in the resulting gts may be useful as a starting point to complete by hand.

A possible new name might be GTSMorpher, perhaps.

• Rename repository
• Refactor language name
• Change file extension (incl. in documentation)
• Change package names

There can be a lot of auto-completions to generate for some partial morphism specifications. This can make the process of generating auto-completions long and can end up blocking up Eclipse completely.

We already use a progress monitor, but currently aren't checking for cancellation requests (and, in particular, we're not using it at all in the code that actually calculates all completions). It would also be good to change the actual calculation code to something that doesn't require calculating all completions before we can start exporting them, but rather something that provides an iterator from which we can extract as few or as many completions as we are interested in (though this may be better as a separate issue).

There seem to be some minor glitches where the readme file isn't fully up-to-date

This may make the various derivation rules clearer. Xsemantics is available here.

Based on files etc provided by Robert Heinrich. See https://github.kcl.ac.uk/gts-families/kamp for details

After 4 consecutive amalgamations of the counter and pls models to get counters on heads, handles, hammers and observers, there are two Observer classes, one left__Observer and one right_Observer.

pls_unresolved_name_clash_bug.zip

Currently, a weave clause requires one of the morphisms to be an interface_of morphism. For full support of the theory, we should allow both to be full morphisms.

Details of progress in PR #13.