Cannot save new file/or open exiting files (Rodin 3.4)

[bmaderbacher]

Problem

I created a new project in a fresh Rodin installation and added a new context to it.
As an example I used the array context from http://wiki.event-b.org/index.php/TextEditor_EBNF.
When I try to safe I get the error message displayed below.
I get the a similar error on opening an exiting context or machine file, created with the rodin editor.

Environment:

• Rodin 3.4 for linux (rodin-3.4.0.201802230927-6980ca1-linux.gtk.x86_64)
• OpenJDK 8 (8.u162)
• Camille nightly (3.2.0.201803161304)
• no additional plugins

Error message:

Save Failed Couldn't add in target because its parent hasn't been merged yet: MERGING LEFT DELETE org.eclipse.emf.compare.internal.spec.ReferenceChangeSpec{reference=BinaryOperator.left,value=IdentifierExpression@71135794 n,parentMatch=org.eclipse.emf.compare.internal.spec.MatchSpec{left=<null>,right=BelongPredicate@35451ba6 http://emf.eventb.org/models/core/formulas::BelongPredicate::array.axm1._OuTcwDHhEeiosJ6emmGu5g,origin=<null>,#differences=2,#submatches=0},match of value=org.eclipse.emf.compare.internal.spec.MatchSpec{left=<null>,right=IdentifierExpression@71135794 n,origin=<null>,#differences=0,#submatches=0}}

This project looks really nice and I hope someone can help me to get it to run.
If you need additional information I'll be happy to provide them.
Yours,
Benedikt

[wysiib]

Apparently, something changed in the EMF Synchronisation Framework between Rodin 3.3 and Rodin 3.4. So far, I do not no what changed exactly.

[weetmuts]

Camille is such a great editor that I cannot work in Rodin without it. This means that this bug blocks me from upgrading to Rodin 3.4.... If there is something I can do to help out, please let me know.

[leuschel]

Hi Frederik, thanks for your message and offer. I also cannot use Camille with Rodin 3.4, which is also a major issue for me using Rodin: my productivity in the other editors feels to be an order of magnitude lower (a few years back I timed myself in writing the same model twice, once with Camille and once without. I cannot remember the concrete figures, but there was a substantial difference). Sebastian (or Jens): have you any idea what needs to be done for Camille to work with Rodin 3.4? Best regards, Michael

…

On 9 Apr 2018, at 04:25, Fredrik Öhrström ***@***.***> wrote: Camille is such a greate editor that I cannot work in Rodin without it. This means that this bug blocks me from upgrading to Rodin 3.4.... If there is something I can do to help out, please let me know. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#26 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABqVpqDj8ZOzEL3zpnT14LxsnKg-5aUIks5tmxrmgaJpZM4S9Ud->.

[wysiib]

I think we need to figure out how to upgrade our EMF merge procedure. The error message states, that there is a problem in the order of merging: a child element is to be merged before its parent has been merged with the other side. Essentially, there are two possible reasons: the elements to be merged are in the wrong order (i.e. we have to reorder the merges-to-be-done in a list); or the child elements causing the exception are not to be merged at all (i.e. we removed the parents from the list of merges, but failed to remove the children as well).

Both issues werent checked with the old version of the EMF framework, so I guess the merge was broken since the Rodin 3 upgrade. The latest release of EMF only makes it obvious.

The code merging two EMF instances is neither long nor complicated. However, I have no idea how to properly do the merge instead.

@weetmuts: I would be willing to support you as much as I can if you try to fix the bug. Have you ever worked with Eclipse / Rodin plugins or the EMF framework?

[weetmuts]

If you could explain which part of the Camille code is responsible for the merge. Like filename and function names, that would help a lot. I have already built Rodin and Camille. //Fredrik Den ons 11 apr. 2018 16:02Sebastian Krings <[email protected]> skrev:

…

I think we need to figure out how to upgrade our EMF merge procedure. The error message states, that there is a problem in the order of merging: a child element is to be merged before its parent has been merged with the other side. Essentially, there are two possible reasons: the elements to be merged are in the wrong order (i.e. we have to reorder the merges-to-be-done in a list); or the child elements causing the exception are not to be merged at all (i.e. we removed the parents from the list of merges, but failed to remove the children as well). Both issues werent checked with the old version of the EMF framework, so I guess the merge was broken since the Rodin 3 upgrade. The latest release of EMF only makes it obvious. The code merging two EMF instances is neither long nor complicated. However, I have no idea how to properly do the merge instead. @weetmuts <https://github.com/weetmuts>: I would be willing to support you as much as I can if you try to fix the bug. Have you ever worked with Eclipse / Rodin plugins or the EMF framework? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#26 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFn2tzVa9O3tanR6660bgZ8JyWbMNk9bks5tngzygaJpZM4S9Ud-> .

[cfsnook]

I just had a quick try of Camille in Rodin 3.4. The problem looks like it might be only with elements that have formula : expressions and predicates. Adding variables, events, parameters all works.. invariants, guards, actions cannot be saved. Maybe something to do with the merging of formulas or formulas meta-model?

[cfsnook]

Maybe it is trying to convert the EMF model of the formula to a string before the parent EMF element (invariant, guard etc) has been merged/created. (Only Camille uses an EMF model for the formula, it has to be reduced to a string (predicate/expression) when Camille saves).

[wysiib]

@weetmuts Let me see if I (and maybe @cfsnook) can get you up to speed on Camille and EMF:
The important classes related to load / save and merge (of elements unknown to Camille and the model as edited in Camille) all controlling classes reside in org.eventb.texttools.diffmerge. As I recall, the process of merging and storing a model from Camille into the Rodin database works as follows:

• camille/org.eventb.texttools/src/org/eventb/texttools/PersistenceHelper.java

  Line 241 in 99fe674

  public static void mergeRootElement(final Resource resource,

  is the method were the merge starts. Essentially, upon save, we merge a machine or a context. The method identifies the relevant root elements to be merged.

• camille/org.eventb.texttools/src/org/eventb/texttools/PersistenceHelper.java

  Line 163 in 99fe674

  private static void mergeComponents(

  is called for the child elements. Here, we create a number of objects supposed to controll how EMF's internal merge algorithms work. Details below.

• camille/org.eventb.texttools/src/org/eventb/texttools/PersistenceHelper.java

  Line 216 in 99fe674

  bm.copyAllRightToLeft(differences, null);

  We call copyAllRightToLeft, moving all identified and merged changes from Camilles current state of model / context to the database.

Diff and merge are controlled by several classes:

• camille/org.eventb.texttools/src/org/eventb/texttools/diffmerge/EventBEObjectMatcher.java

  Line 24 in 99fe674

  public class EventBEObjectMatcher implements IEObjectMatcher {

  the EObjectMatcher tries to identifies pairs of elements to be merged, i.e., the guard g_1 of operations o_1 has to be merged with its corresponding counterpart g_n of o_1's current state in the database. This accounts for introductions of new guards, etc.

• camille/org.eventb.texttools/src/org/eventb/texttools/diffmerge/EventBMerger.java

  Line 12 in 99fe674

  public class EventBMerger extends AbstractMerger {

  controlls how the lists of extended machines or seen contexts is merged. In particular, changes in the order of seen contexts are not supposed to change what is stored in the Rodin database. This should be the only (???) special case - as soon as corresponding elements are identified, Camille relies on the default merging proceedures of EMF.

However, two thing have to be kept in mind even if only default merging proceedures are used: the order of merges is important. As you can see in the PersistenceHelper, merges are stored in a list and processed accordingly.
Furthermore, Camille can always choose to discard an identified corresponding pair. This happens for instance, if Camille does not not about the element (e.g. IUML state machines). In that case Camille cannot provide any new content, the merge is always with the empty element and Camille will overwrite what was there. This is the case for bug #27.

The question remains, whether currently Camille tries to merge and save things it should just ignore, or whether we need to merge and save even more in order to provide the missing elements.

Let me know if I can help you further or if you have any other questions regarding Camille.

[bodeveix]

I have looked at this problem and it seems to be fixed even if the fix is not very clean. I have modified PersistenceHelper to call directly the EventBMerger and to catch potential exceptions when applying a diff: this update avoids exceptions on Save. Finally, no exceptions seem to occur thanks to the EventBMerger update. In EventBMerger, I have used the AttributeChangeMerger and ReferenceChangeMerger of the library. I have also tried to merge the location information. Line information seems correct but sub-expressions are not well marked. I think it would need to find the index of the change in a multi-valued attribute.
It seems the isMergedFor method could simply return true. I have kept a part of the previous code. It was supposed to avoid erasing information not managed by camille, but it seems there is nothing to do for that.
Another problem I have tried to fix is that saving does not always launch workspace update. Adding
resource.setModified(true); resource.eSetDeliver(true);
in PersistenceHelper seems to reduce the occurrences of the problem.

I attach the two updated files and the .jar that can be used to replace the one in Rodin 3.4 (with identical version number).

I have not looked at the interactions between Camille and other tools (iUML-B for example)...

Note that I have not made extensive tests. Thus, use it at your own risk...

PersistenceHelper.java.zip
EventBMerger.java.zip
org.eventb.texttools.zip

[leuschel]

Many thanks for your efforts! The fix seems to work on my Rodin 3.4 installation. I have pushed the changes to the github repository. Unfortunately building has failed on Travis: $ gem install travis-custom-deploy YAML safe loading is not available. Please upgrade psych to a version that supports safe loading (>= 2.0). ERROR: Error installing travis-custom-deploy: The last version of net-ssh (>= 2.6.5) to support your Ruby & RubyGems was 4.2.0. Try installing it with `gem install net-ssh -v 4.2.0` and then running the current command again net-ssh requires Ruby version >= 2.2.6. The current ruby version is 2.0.0. The command "gem install travis-custom-deploy" failed and exited with 1 during . Greetings, Michael

[leuschel]

Your changes have now been successfully integrated into Camille and are available from the Camille update site. Concerning the workspace update: I sometimes have the problem that saving a changed model works in the sense that e.g. other editors like the Rodin Editor see the changes, but the POs are not updated. Sometimes it is very hard or even impossible, even using clean, to get Rodin to update the POs. This looks more like a Rodin bug than a Camille issue.

…

On 2 Nov 2018, at 11:44, bodeveix ***@***.***> wrote: Another problem I have tried to fix is that saving does not always launch workspace update. Adding resource.setModified(true); resource.eSetDeliver(true); in PersistenceHelper seems to reduce the occurrences of the problem.

[cfsnook]

Just a comment re:
" I have kept a part of the previous code. It was supposed to avoid erasing information not managed by camille, but it seems there is nothing to do for that."
This is important for me... Camille does not load iUML-B diagrammatic models as text so without this code it would see my diagrams as something to be deleted when it came to merge.

[bodeveix]

I have made a small test with UML-B: I create a iUML-B project, build a diagram, generate the Event-B model and load it with Camille: I don't see any problem. Do you expect another scenario?

[cfsnook]

Thanks.. did you try saving a change that you made in Camille?

[bodeveix]

Yes, I can save the changes as for any Event-B model. If I close and re-open the Event-B model, I see the changes. I get the same behaviour as with the Rodin editor.

[cfsnook]

I think maybe you tried the old UML-B (which should not be affected by Camille because it just regenerates the whole Event-B project and overwrites anything you edit with Camille).

iUML-B is different because it stores the state-machine model inside the machine that Camille is editing.
I just tried it with iUML-B state-machines and Camille did not preserve eOpposite references in a state-machine transition.
i.e. it preserved all the elements in the state-machine and the references from state to their incoming and outgoing transitions but the transition lost its references to source and target states and became invalid.
However, I think we have seen this before so it may have been the case before your edits.

NewProject_201811032126.tar.gz

[bodeveix]

I have made new changes to make Camille compatible with the new Rodin core. The iUML-B statemachine diagram problem is also solved. I attach the new project sources files. I have incremented the version number.
org.eventb.texteditor.src.zip

[bodeveix]

I have noticed an error linked to the object comparator. As a consequence, values deleted in Camille from multi-valued references (for example "sees") were not delete in the model. I attach the new project source file.
org.eventb.texteditor.src.zip