Concrete syntax blackbox modules

[eclipse-qvt-oml-bot]

| --- | --- | | Bugzilla Link | 427237 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | Feb 03, 2014 04:12 EDT | | Modified | May 25, 2015 12:38 EDT | | Version | 3.4 | | Reporter | Christopher Gerking |

Description

After enabling concrete syntax blackbox operations for bug 289982, another issue are entire blackbox modules (i.e. modules with isBlackbox=true). For operational transformations, the blackbox flag "indicates that the whole transformation is opaque: no entry operation and no mapping operations are defined." My interpretation is that such a transformation has only a signature and does not declare any operations at all. Hence, such a transformation basically enables import via "access" from another transformation.

The job is now to come up with an idea how to map an operational transformation to the Java level, especially how to represent model extents in Java.

What is the meaning of isBlackbox=true for a Library? Since I see no reasonable meaning, shouldn't the isBlackbox attribute be moved to OperationalTransformation?

[eclipse-qvt-oml-bot]

By Christopher Gerking on Mar 18, 2014 06:14

I have a patch available that enables blackboxing entire transformations in terms of Java methods (using model extents and config properties as parameters).

The problem is that the 'blackbox' qualifier seems to be ignored by the parser or somewhere else. Thus, there is never a transformation with isBlackbox=true in the AST. Sergey, can you help here?

[eclipse-qvt-oml-bot]

By Sergey Boyko on Mar 18, 2014 06:38

(In reply to Christopher Gerking from comment #1)

I have a patch available that enables blackboxing entire transformations in terms of Java methods (using model extents and config properties as parameters).

The problem is that the 'blackbox' qualifier seems to be ignored by the parser or somewhere else. Thus, there is never a transformation with isBlackbox=true in the AST. Sergey, can you help here?

Great! \ Of course, I'll fix the parser for 'blackbox' qualifier on transformations' declaration. Will be available soon (today or tomorrow).

[eclipse-qvt-oml-bot]

By Sergey Boyko on Mar 19, 2014 12:09

(In reply to Sergey Boyko from comment #2)

I'll fix the parser for 'blackbox' qualifier on transformations' declaration.

Implemented.\ Commit eb219eddfa114e3d13868bcdd75f1cea9d358b45

[eclipse-qvt-oml-bot]

By Christopher Gerking on Mar 21, 2014 11:27

Created attachment 241103 (attachment deleted)\ org.eclipse.m2m.qvt.oml patch

Patch that enables blackboxing of operational transformations via Java methods.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Mar 21, 2014 11:28

Created attachment 241104 Additional org.eclipse.m2m.qvt.oml.ocl patch

:notepad_spiral: org.eclipse.m2m.qvt.oml.ocl.patch

[eclipse-qvt-oml-bot]

By Christopher Gerking on Mar 21, 2014 11:36

Example: for an Ecore to Ecore transformation named 'trans' with one Integer config property, implement the following Java method:

@Operation(contextual = false, kind = Kind.TRANSFORMATION)\ public static void trans(ModelInstance in, ModelInstance out, Integer i) {\ // TODO implement transformation\ }

Unfortunately, it seems not possible to match the input/output models more precisely other than using class ModelInstance. In addition, access to ModelInstance is restricted from client plugins. Maybe we need a better approach here.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Mar 23, 2014 09:50

Created attachment 241144 (attachment deleted)\ org.eclipse.m2m.qvt.oml patch

[eclipse-qvt-oml-bot]

By Christopher Gerking on Mar 23, 2014 09:51

Created attachment 241145 org.eclipse.m2m.qvt.oml.runtime patch

:notepad_spiral: org.eclipse.m2m.qvt.oml.runtime.patch

[eclipse-qvt-oml-bot]

By Christopher Gerking on Mar 25, 2014 04:14

Created attachment 241206 org.eclipse.m2m.qvt.oml patch

:notepad_spiral: org.eclipse.m2m.qvt.oml.patch

[eclipse-qvt-oml-bot]

By Sergey Boyko on Apr 10, 2014 05:58

Pushed to master for M7.

commit 24150199e20f84e8f90df0205ad7c14400c2bc5e

[eclipse-qvt-oml-bot]

By Christopher Gerking on Oct 09, 2014 07:50

Doesn't seem to work when running QVTo from Java via TransformationExecutor due to an NPE in AbstractBlackboxProvider.getBlackboxCallHandler().

The reason is that InternalTransformationExecutor compiles with 'null' compiler options, which makes the compiler invoke setGenerateCompletionData(false) in QVTOCompiler.getDefaultOptions(). Therefore, the call to ASTBindingHelper.createModuleBinding() is skipped in QvtOperationalVisitorCS.visitModuleHeaders(). Finally, the QvtOperationalEvaluationVisitorImpl fails to obtain the moduleEnv in doVisitBlackboxOperation(), which results in the NPE mentioned above.

I'm not quite sure how to fix this, because I don't yet understand the purpose of "generate completion data".

[eclipse-qvt-oml-bot]

By Christopher Gerking on Oct 09, 2014 08:00

Sorry, this relates more to bug 289982.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Oct 24, 2014 10:13

(In reply to Christopher Gerking from comment #12)

Sorry, this relates more to bug 289982.

... but affects blackbox transformations as well.

Fixed and pushed to cgerking.\ Commit ID: efaaa503895ed51d048982dd417271722dbc6353

[eclipse-qvt-oml-bot]

By Sergey Boyko on Oct 31, 2014 13:02

(In reply to Christopher Gerking from comment #13)

(In reply to Christopher Gerking from comment #12)

Sorry, this relates more to bug 289982. ... but affects blackbox transformations as well.

Fixed and pushed to cgerking. Commit ID: efaaa503895ed51d048982dd417271722dbc6353

Hi Christopher,

I have a couple of questions to the patch:

1. You've introduced 'fLoadErrors' field in 'JavaBlackboxProvider' class.\ This results in that every call to '.loadCompilationUnit()' prints error to the log while current logic prints error only for the first pass. To me this looks too excessive.

2. In several places (in doVisitBlackboxOperation() and in createBlackboxTransformationHandler()) you changed obtaining the instance of 'QvtOperationalModuleEnv' to \ 'QvtOperationalModuleEnv moduleEnv = getOperationalEnv().getAdapter(QvtOperationalModuleEnv.class);'\ \ Of course, this will always result in non-null instance of 'QvtOperationalModuleEnv' since evaluation visitor always uses an instance of such an environment.

   However this instance is not the one which was used to load the BB library and in that sense it's incorrect. I suggest to restore the use of ASTBindingHelper to obtaining the correct environment. Conversely I propose to remove 'if(myCompilerOptions.isGenerateCompletionData())' check from visitModuleHeaders() function so that bindings will be always properly established.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Nov 01, 2014 06:49

(In reply to Sergey Boyko from comment #14)

1. You've introduced 'fLoadErrors' field in 'JavaBlackboxProvider' class. This results in that every call to '.loadCompilationUnit()' prints error to the log while current logic prints error only for the first pass. To me this looks too excessive.

The reason was that the new callapi test cases rely on existing transformation scripts. Hence, they caused loading of 'org.eclipse.m2m.tests.qvt.oml.bbox.InvalidLibrary' and therefore "stole" the expected compile error from the subsequent parser test case 'blackboxlib_annotation_java'. Consequently, the parser test failed when running the entire test suite, but succeeded when running in isolation because no previous compilation stole the error.

I think that importing an erroneous blackbox should always produce a compile error, not only on first attempt. Is there a way to ensure that, and at the same time avoid repetitive logging?\

2. In several places (in doVisitBlackboxOperation() and in createBlackboxTransformationHandler()) you changed obtaining the instance of 'QvtOperationalModuleEnv' to 'QvtOperationalModuleEnv moduleEnv = getOperationalEnv().getAdapter(QvtOperationalModuleEnv.class);'

   Of course, this will always result in non-null instance of 'QvtOperationalModuleEnv' since evaluation visitor always uses an instance of such an environment.

   However this instance is not the one which was used to load the BB library and in that sense it's incorrect. I suggest to restore the use of ASTBindingHelper to obtaining the correct environment. Conversely I propose to remove 'if(myCompilerOptions.isGenerateCompletionData())' check from visitModuleHeaders() function so that bindings will be always properly established.

I see, but I wonder why the incorrect solution doesn't lead to problems. Can we have an additional test case here?

[eclipse-qvt-oml-bot]

By Sergey Boyko on Nov 02, 2014 13:08

(In reply to Christopher Gerking from comment #15)

(In reply to Sergey Boyko from comment #14)

1. You've introduced 'fLoadErrors' field in 'JavaBlackboxProvider' class. This results in that every call to '.loadCompilationUnit()' prints error to the log while current logic prints error only for the first pass. To me this looks too excessive.

The reason was that the new callapi test cases rely on existing transformation scripts. Hence, they caused loading of 'org.eclipse.m2m.tests.qvt.oml.bbox.InvalidLibrary' and therefore "stole" the expected compile error from the subsequent parser test case 'blackboxlib_annotation_java'. Consequently, the parser test failed when running the entire test suite, but succeeded when running in isolation because no previous compilation stole the error.

I see. We can provide an "internal" method to clear cache of loaded libraries and utilize this method from unit tests.

I think that importing an erroneous blackbox should always produce a compile error, not only on first attempt. Is there a way to ensure that, and at the same time avoid repetitive logging?

I doubt that such way exists. At least I don't know about.

2. In several places (in doVisitBlackboxOperation() and in createBlackboxTransformationHandler()) you changed obtaining the instance of 'QvtOperationalModuleEnv' to 'QvtOperationalModuleEnv moduleEnv = getOperationalEnv().getAdapter(QvtOperationalModuleEnv.class);'

   Of course, this will always result in non-null instance of 'QvtOperationalModuleEnv' since evaluation visitor always uses an instance of such an environment.

   However this instance is not the one which was used to load the BB library and in that sense it's incorrect. I suggest to restore the use of ASTBindingHelper to obtaining the correct environment. Conversely I propose to remove 'if(myCompilerOptions.isGenerateCompletionData())' check from visitModuleHeaders() function so that bindings will be always properly established.

I see, but I wonder why the incorrect solution doesn't lead to problems. Can we have an additional test case here?

You have already added missed test cases. \ I mean that untested branches (when isGenerateCompletionData() returns 'false') is called during standalone execution. When the compiler is launched from Eclipse then isGenerateCompletionData() returns 'true'.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Nov 05, 2014 05:04

(In reply to Sergey Boyko from comment #16)

You have already added missed test cases.

Which now succeed given my "incorrect" solution. I'm referring to a different test demonstrating that my solution is incorrect.

[eclipse-qvt-oml-bot]

By Sergey Boyko on Nov 25, 2014 08:55

(In reply to Christopher Gerking from comment #13)\

Fixed and pushed to cgerking. Commit ID: efaaa503895ed51d048982dd417271722dbc6353

Cherry-picked to master for M4.\ Commit id: aba87c8d8f495ec6dd4b9c02ca892825aa007241