eMoflon / emoflon-ibex-democles

Incremental unidirectional and bidirectional graph transformations with the Democles pattern matching engine
GNU General Public License v3.0
1 stars 2 forks source link

Problems with deletion and Democles #52

Open anthonyanjorin opened 6 years ago

anthonyanjorin commented 6 years ago

Hi Greg,

to continue our work on deletion, I have marked a further problematic test testsuite.ibex.ClassInhHier2DB_MA.sync.SyncForward.testDeleteIntermediateSuperClass_FWD() with "FIXME Greg".

You can simply remove the @Ignore for this test and run it to reproduce the exception. I've been unable to understand why the deletion from our side should be in anyway wrong.

Cheers and thanks, Tony

anthonyanjorin commented 6 years ago

In the same test class there is another problematic tests that only passes if assertions are switched off: testsuite.ibex.ClassInhHier2DB_MA.sync.SyncForward.testDeleteClassThatHadAttributes_FWD()

Note: you might have to update Ibex first for the test to fail (I restructured the pattern network a bit).

patrickrobrecht commented 6 years ago

The test case testsuite.ibex.ClassInhHier2DB_MA.sync.SyncForward.testDeleteIntermediateSuperClass_FWD() seems to work with the latest version. Seems that this was fixed when changing the order of deletion.

patrickrobrecht commented 6 years ago

Currently the following tests are ignored with errors during deletion:

gervarro commented 6 years ago

Hi,

could you please fix the deployable version of the IBeX engine (i.e., project builder)? I got the following error message:

Errors running builder 'Xtext Project Builder' on project 'SheRememberedCaterpillarsGraphTransformation'.
org.eclipse.xtext.xbase.lib.CollectionLiterals.newArrayList()Ljava/util/ArrayList;
Errors running builder 'Xtext Project Builder' on project 'VHDLTGGCodeAdapter'.
org/moflon/core/utilities/EcoreUtils

EcoreUtils does not seem to exist in the deployable eMoflon Core module.

Bests, Greg

anthonyanjorin commented 6 years ago

Hi Greg,

IBeX uses emoflon::core from the snapshot UpdateSite not stable.

Please try to update core from: https://emoflon.org/emoflon-core-updatesite/snapshot/updatesite/

Cheers, Tony

gervarro commented 6 years ago

Hi Tony,

I was unable to install the emoflon::core from the snapshot on Eclipse Neon. I fixed the problematic version constraints. Could you please rebuild the update site?

Many thanks and bests, Greg

anthonyanjorin commented 6 years ago

Hi Greg,

just deployed.

Cheers, Tony

gervarro commented 6 years ago

Hi Tony,

I am somewhat frustrated because I cannot get the test workspace running (with the obvious consequence that I cannot fix these issues).

Bests, Greg

anthonyanjorin commented 6 years ago

Hi Greg,

it sounds as though:

  1. You should take a fresh, empty test workspace and import the latest PSF for the test workspace after pulling the latest changes. I suggest this because, for example, the Algorithm project has been renamed to Algorithms some time ago.
  2. You should probably select all projects (especially TGG projects) and press our black build "hammer" to make sure that all projects are built. This is probably the reason why the .ecore file in the TGG project is missing.

I can't explain why the 2 GT projects aren't building, but if the other GT projects are ok, then it shouldn't be an XText problem. I hope it is also related to (1), i.e., perhaps some dependencies are missing from the workspace and still have to be imported (or you need to pull the latest changes).

@patrickrobrecht can try to see if all tests run under Eclipse Neon.

Please tell us if you're still stuck.

Cheers, Tony

patrickrobrecht commented 6 years ago

Hi Greg, hi Tony,

I got IBeX working under Eclipse Neon. The only thing I had to do in addition to our README was to update org.eclipse.emf.ecore to version 2.13 (I found version 2.12 installed) via the update site http://download.eclipse.org/modeling/emf/emf/updates/2.13milestones.

Some little fixes in our testsuite (removing specific version numbers from dependency declarations) can be found here: https://github.com/eMoflon/emoflon-ibex-tests/pull/84

anthonyanjorin commented 6 years ago

Thanks, Patrick! I’ve merged your fix.

gervarro commented 6 years ago

Hi,

Currently the following tests are ignored with errors during deletion:

testsuite.ibex.ClassInhHier2DB_MA.sync.SyncForward.testDeleteClassThatHadAttributes_FWD()
testsuite.ibex.ClassInhHier2DB_MA.sync.AlternatingSync.testCreateSubClassDeleteSubTable (non-deterministic, failed only in 1 of 21 executions!)
testsuite.ibex.ClassInhHier2DB_MA.sync.AlternatingSync.testCreateSuperClassDeleteSuperTable (non-deterministic!)

The first test case was always green after several runs. Does it still fail? Is it also a non-deterministic case?

I checked the third case. When edges are deleted at the following phase (i.e., revoke nodes and edges in the source and target model): https://github.com/eMoflon/emoflon-ibex/blob/aad699ea5159b968ad0a8073e87cc2a9e42991ad/org.emoflon.ibex.tgg.core.runtime/src/org/emoflon/ibex/tgg/operational/defaults/IbexRedInterpreter.java#L36, non-containment edges are deleted in an arbitrary order, however, only the deletion of regular edges (all edges - containment edges - container edges (i.e., bidirectional edge whose opposite is a containment edge)) would be correct. (Container edges should be ignored completely.) Deletion of a container edge (e.g., ClazzImpl(name: SC1) -- package -> ClassPackageImpl(name: P), sc1.setPackage(null)) already triggers the deletion of the contained class (i.e., SC1). If a regular edge (like superClass) is deleted afterwards, the notification processing engine reports failure due to a dangling node.

This deletion order is now OK:

  1. ClassPackageImpl(name: P) -- classes -> ClazzImpl(name: SC1) (containment edge, ignored)
  2. ClazzImpl(name: C1) -- subClass -> ClazzImpl(name: SC1) (regular edge, deleted)
  3. ClazzImpl(name: SC1) -- superClass -> ClazzImpl(name: C1) (regular edge, deleted)
  4. ClazzImpl(name: SC1) -- package -> ClassPackageImpl(name: P) (container edge, triggers the deletion of the above containment edge as well)

This deletion order fails in the current version:

  1. ClassPackageImpl(name: P) -- classes -> ClazzImpl(name: SC1) (containment edge, ignored)
  2. ClazzImpl(name: SC1) -- package -> ClassPackageImpl(name: P) (container edge, triggers the deletion of the above containment edge as well, consequently, SC1 is a dangling node from now on)
  3. ClazzImpl(name: C1) -- subClass -> ClazzImpl(name: SC1) (regular edge, deleted)
  4. ClazzImpl(name: SC1) -- superClass -> ClazzImpl(name: C1) (regular edge, deleted, throws RuntimeException)

I guess that this issue causes the non-deterministic bug in all the three cases.

Bests, Greg

patrickrobrecht commented 6 years ago

Hi Greg,

thanks for your feedback. I was able to implement a bugfix (https://github.com/eMoflon/emoflon-ibex/pull/358) which fixes the two test cases

testsuite.ibex.ClassInhHier2DB_MA.sync.AlternatingSync.testCreateSubClassDeleteSubTable
testsuite.ibex.ClassInhHier2DB_MA.sync.AlternatingSync.testCreateSuperClassDeleteSuperTable

by deleting container edges at the end just as containment edges.

Update: Even with the bugfix testsuite.ibex.ClassInhHier2DB_MA.sync.SyncForward.testDeleteClassThatHadAttributes_FWD fails all the time with an java.lang.AssertionError at org.gervarro.democles.runtime.HistoryBasedIteratorHandler.lookupNextFrame(HistoryBasedIteratorHandler.java:136). Any idea about that?