escet merge requestshttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests2023-01-18T06:23:03Zhttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/349#368 Implement cif2dmm2023-01-18T06:23:03ZAlbert Hofkamp#368 Implement cif2dmmRewritten from scratch. Extracts CIF object relations from a specification, in particular from plants and input variables to invariants and requirement automata, through shared events, and accessed locations and variables.
As the theory...Rewritten from scratch. Extracts CIF object relations from a specification, in particular from plants and input variables to invariants and requirement automata, through shared events, and accessed locations and variables.
As the theory isn't developed beyond normal automata, much of the implementation was guided by the spirit of the math and the previous attempt. As such, it would be helpful if @mgoorden7u4 could have a look at it.
Some notes about the submitted files:
- Code is in `oee.cif.multilevel` as that it is part of that application.
- The pre-checker should only check for `cif2dmm` requirements, not sure abut "locations references must be to plant locations".
- While it is no doubt a sane rule, I am not sure it is strictly a requirement. Other code simply ignores all requirement automata locations, which has the same doubts of course.
- The pre-checker is not collecting problems, it simply throws on the first found problem. The reason for that is that this checker needs to be integrated in the multilevel application eventually together with eg datasynthesis pre-conditions. Also, At the time of writing a more modular prechecker was being created, it seemed a waste of time to finish this
- `Cif2Dmm` is the main program of the sub-routine, and is also the result (the 4 DMM variables at the top).
- It collects references by searching through parts of the specification using the the `Collector` class.
- The `FoundObjects` class stores the all relevant CIF elements (events, locations, variables) in an array to obtain a unique index for each element, and keeps `BitSet`s of "referenced and possibly shared" references to such elements from "referring" elements (automata and invariants).
- All kinds of objects are all thrown into one heap, as code is working with the bitsets.
- Once the relations are found, constructing product systems is simple in `FoundObjects.partitionPlantsToProductSystems()`.
- And then it is time to construct the DMMs from the bitsets. I opted for splitting the relations so the rows and columns of a DMM have only one kind of CIF element. I didn't bother removing empty rows or columns, not sure if that is needed.
Closes #368Albert HofkampAlbert Hofkamphttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/350#398 Various checks for CIF checker crash for violations in the root of the s...2022-09-11T18:09:55ZFerdie Reijnen#398 Various checks for CIF checker crash for violations in the root of the specificationCloses #398Closes #398v0.7https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/352Draft: #382 Make plcgen0 accessible in ESCET.2022-08-11T10:50:09ZAlbert HofkampDraft: #382 Make plcgen0 accessible in ESCET.Making previous art available for testing and reference.
An improved version is being created in #397.
## Restrictions:
``` text
// 1. no external functions
// 2. no tau events
// 3. no types: Set, Func, Comp...Making previous art available for testing and reference.
An improved version is being created in #397.
## Restrictions:
``` text
// 1. no external functions
// 2. no tau events
// 3. no types: Set, Func, CompParamWrap, CompInstWrap, ComponentDef, Dist, Dict, Void.
// 4. no automaton reference (or self) child isn't allowed
// 5. no exprs: slice, tau, event, set, time, self, component, compParamWrap, compInstWrap, dict
// 6. no urgent locations/edges
// 7. must have trivially true initial location and expressions.
// 8. no empty lists/arrays
// 9. no variable length lists
// 10. no continue function statement (from FuncGen.java:186, even though funcs are not allowed)
// 11. no function parameter names that are are keywords, including EN and ENO. (from renameNames:393)
// 12. no string projection
// 13. no multiple initial values
// 14. no stdLibFuncs: ACOSH ASINH ATANH BERNOULLI BETA BINOMIAL CEIL CONSTANT COSH DELETE EMPTY ERLANG EXPONENTIAL FLOOR FORMAT GAMMA GEOMETRIC LOG_NORMAL NORMAL POISSON POP RANDOM ROUND SCALE SIGN SINH SIZE TANH TRIANGLE UNIFORM WEIBULL
// 15. no unary expression SAMPLE
// 16. no binary expression ELEMENT_OF SUBSET
// 17. no internal functions with cyclic dependencies (there should not be functions)
// 18. no an event must have at least one non-monitoring automaton. (-> finite response)
// 19. no list/array of empty tuples
// 20. no constants may not use functions (both internal and stdlib).
```
CIF code that will cause crashes/incorrect PLC code:
``` text
- Using tuples in updates creates incorrect PLC code, eg "edge a do x:=(1,2);"
- Events that are declared within an automaton but not used anywhere result in an AssertionError.
- Multi-assignments result in a java.lang.NullPointerException. eg "edge a do (x,y) := (y,x);"
```
## Using the generator:
- Make an empty IO table named `empty.csv`.
- Make a `.tooldef` file with the following text:
``` tooldef
// Defines the 'plcgen0 tool.
tool int plcgen0(list string args = [], string stdin = "-", string stdout = "-", string stderr = "-",
bool appendOut = false, bool appendErr = false, bool errToOut = false, bool ignoreNonZeroExitCode = false):
return app("org.eclipse.escet.cif.plcgen0", "org.eclipse.escet.cif.plcgen0.app.PlcGen2App", args, stdin, stdout, stderr,
appendOut, appendErr, errToOut, ignoreNonZeroExitCode);
end
// Run the plcgen0 program.
// - Replace "abb" by "siemens-7-1500" to get siemens output, (Other targets will likely fail.)
// - Replace "model.cif" by the name of the cif model to convert,
// - stdout and stderr settings may be omitted to get the output at the console.
plcgen0(["--io-table=empty.csv", "--target-type=abb", "model.cif"], stdout="out_file", stderr="err_file");
// For a non-empty IO table, the following fields are required for each line in the .CSV file:
// - PLC address,
// - PLC typename,
// - Full path to CIF input-variable or output location/disc-variable/alg-variable
//
// For example for "input bool input1" and "alg bool output1 = ..." in the root of the specification, the following is accepted.
// %I1,BOOLEAN,input1
// %Q2,BOOLEAN,output1
```
- Adjust the `plcgen0` line to your liking, `plcgen0(["-h"]);` will dump the accepted options.https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/357Draft: #382 (take 2) Make plcgen0 accessible in ESCET.2023-12-22T13:44:51ZAlbert HofkampDraft: #382 (take 2) Make plcgen0 accessible in ESCET.Making previous art available for testing and reference.
**This branch should not be merged**.
An improved version is being created in #397.
## Restrictions:
``` text
// 1. no external functions
// 2. no tau events
...Making previous art available for testing and reference.
**This branch should not be merged**.
An improved version is being created in #397.
## Restrictions:
``` text
// 1. no external functions
// 2. no tau events
// 3. no types: Set, Func, CompParamWrap, CompInstWrap, ComponentDef, Dist, Dict, Void.
// 4. no automaton reference (or self) child isn't allowed
// 5. no exprs: slice, tau, event, set, time, self, component, compParamWrap, compInstWrap, dict
// 6. no urgent locations/edges
// 7. must have trivially true initial location and expressions.
// 8. no empty lists/arrays
// 9. no variable length lists
// 10. no continue function statement (from FuncGen.java:186, even though funcs are not allowed)
// 11. no function parameter names that are are keywords, including EN and ENO. (from renameNames:393)
// 12. no string projection
// 13. no multiple initial values
// 14. no stdLibFuncs: ACOSH ASINH ATANH BERNOULLI BETA BINOMIAL CEIL CONSTANT COSH DELETE EMPTY ERLANG EXPONENTIAL FLOOR FORMAT GAMMA GEOMETRIC LOG_NORMAL NORMAL POISSON POP RANDOM ROUND SCALE SIGN SINH SIZE TANH TRIANGLE UNIFORM WEIBULL
// 15. no unary expression SAMPLE
// 16. no binary expression ELEMENT_OF SUBSET
// 17. no internal functions with cyclic dependencies (there should not be functions)
// 18. no an event must have at least one non-monitoring automaton. (-> finite response)
// 19. no list/array of empty tuples
// 20. no constants may not use functions (both internal and stdlib).
```
CIF code that will cause crashes/incorrect PLC code:
``` text
- Using tuples in updates creates incorrect PLC code, eg "edge a do x:=(1,2);"
- Events that are declared within an automaton but not used anywhere result in an AssertionError.
- Multi-assignments result in a java.lang.NullPointerException. eg "edge a do (x,y) := (y,x);"
```
## Using the generator:
- Make an empty IO table named `empty.csv`.
- Make a `.tooldef` file with the following text:
``` tooldef
// Defines the 'plcgen0 tool.
tool int plcgen0(list string args = [], string stdin = "-", string stdout = "-", string stderr = "-",
bool appendOut = false, bool appendErr = false, bool errToOut = false, bool ignoreNonZeroExitCode = false):
return app("org.eclipse.escet.cif.plcgen0", "org.eclipse.escet.cif.plcgen0.app.PlcGen2App", args, stdin, stdout, stderr,
appendOut, appendErr, errToOut, ignoreNonZeroExitCode);
end
// Run the plcgen0 program.
// - Replace "abb" by "siemens-7-1500" to get siemens output, (Other targets will likely fail.)
// - Replace "model.cif" by the name of the cif model to convert,
// - stdout and stderr settings may be added to get the output at the console.
plcgen0(["--io-table-name=empty.csv", "--target-type=abb", "model.cif"]);
// With output redirection: plcgen0(["--io-table-name=empty.csv", "--target-type=abb", "model.cif"], stdout="out_file", stderr="err_file");
// For a non-empty IO table, the following fields are required for each line in the .CSV file:
// - PLC address,
// - PLC typename,
// - Full path to CIF input-variable or output location/disc-variable/alg-variable
//
// For example for "input bool input1" and "alg bool output1 = ..." in the root of the specification, the following is accepted.
// %I1,BOOLEAN,input1
// %Q2,BOOLEAN,output1
```
- Adjust the `plcgen0` line to your liking, `plcgen0(["-h"]);` will dump the accepted options.v3.0Albert HofkampAlbert Hofkamphttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/360#402 Double dash in branch-names are interpreted as CJK ideographs2022-08-19T19:57:57ZFerdie Reijnen#402 Double dash in branch-names are interpreted as CJK ideographsCloses #402Closes #402v0.7https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/381#431 Test building fork merge request with changed Jenkinsfile.2022-10-02T12:19:43ZDennis Hendriks#431 Test building fork merge request with changed Jenkinsfile.Addresses #431Addresses #431v0.8https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/399#424 Generalize allowed invariants check.2022-12-07T12:19:19ZAlbert Hofkamp#424 Generalize allowed invariants check.Addresses #424
Just supervisor kind checking for invariants wasn't sufficient for cif2plc, so generalized the invariants check to place, supervisor kind and invariant kind.Addresses #424
Just supervisor kind checking for invariants wasn't sufficient for cif2plc, so generalized the invariants check to place, supervisor kind and invariant kind.Albert HofkampAlbert Hofkamphttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/406#431contributions for non-commiters cannot be merged2022-11-10T15:02:43ZPawel Stankiewicz#431contributions for non-commiters cannot be mergedDo not merge. This is just dummy test to see gitlab - jenkins interactions.
Signed-off-by: Pawel Stankiewicz <pawel.stankiewicz@eclipse-foundation.org>Do not merge. This is just dummy test to see gitlab - jenkins interactions.
Signed-off-by: Pawel Stankiewicz <pawel.stankiewicz@eclipse-foundation.org>https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/408#431 contributions for non-commiters cannot be merged, test22023-02-13T21:30:10ZPawel Stankiewicz#431 contributions for non-commiters cannot be merged, test2Do not merge. This is just dummy test to see gitlab - jenkins interactions.
Signed-off-by: Pawel Stankiewicz <pawel.stankiewicz@eclipse-foundation.org>Do not merge. This is just dummy test to see gitlab - jenkins interactions.
Signed-off-by: Pawel Stankiewicz <pawel.stankiewicz@eclipse-foundation.org>https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/431#359 Attempt to upgrade to Tycho 32022-12-04T16:35:19ZDennis Hendriks#359 Attempt to upgrade to Tycho 3I'm creating this merge request only to preserve the effort this branch. I'll close this merge request immediately, as we can't actually upgrade to Tycho 3. When we upgrade to Tycho 4, we should look at this merge request again.
Address...I'm creating this merge request only to preserve the effort this branch. I'll close this merge request immediately, as we can't actually upgrade to Tycho 3. When we upgrade to Tycho 4, we should look at this merge request again.
Addresses #359v0.8https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/454Draft: #360 Integrate license check into the build2023-08-19T10:03:56ZDennis HendriksDraft: #360 Integrate license check into the build- Also check third party dependencies licenses during build.
- Kept the separate check, for nightly checks.
- Draft status for now, as the build produces [a lot of warnings](https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/360#not...- Also check third party dependencies licenses during build.
- Kept the separate check, for nightly checks.
- Draft status for now, as the build produces [a lot of warnings](https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/360#note_1058843) due to a Dash license check tool [issue](https://github.com/eclipse/dash-licenses/issues/199).
Closes #360https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/462Draft: #488 Search engine indexes old versions2023-01-05T11:42:52ZFerdie ReijnenDraft: #488 Search engine indexes old versionsAddresses #488.Addresses #488.https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/464Draft: #454 New output for CIF checks2023-02-21T19:00:44ZDennis HendriksDraft: #454 New output for CIF checks* This merge request is not ready by any means. It serves to allow discussion on this attempt at new output.
* I had to move all CIF checks to a new plugin to prevent a cyclic dependency.
* The design for checks is much simpler, as there...* This merge request is not ready by any means. It serves to allow discussion on this attempt at new output.
* I had to move all CIF checks to a new plugin to prevent a cyclic dependency.
* The design for checks is much simpler, as there are no message classes anymore. Just (formatted) strings.
* I got rid of reporting on ancestors or named objects, requiring `PositionObject` objects with a position. It turns out not all expressions and types have a position, even after re-parsing. I haven't looked into why that is yet. Let's see what we want as output first.
* No more reporting on `null` specifications. Just supply the `Specification` object instead. Typically, this is used in `preprocessSpecification` or `postprocessSpecification`, which have that already anyway. Can use `CifScopeUtils.getSpecification` otherwise.
* For the new output, I opted to first categorize by message, and then sort per line, and then for all violations on the same line report them with the text of the line and markers.
Addresses #454v0.9https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/471Testing EF issue 2178. Do not merge.2023-01-09T18:47:49ZPawel Stankiewiczpawel.stankiewicz@huawei.comTesting EF issue 2178. Do not merge.Signed-off-by: Paweł Stankiewicz <pawel.stankiewicz@huawei.com>Signed-off-by: Paweł Stankiewicz <pawel.stankiewicz@huawei.com>https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/472Draft: #378 CIF data-based synthesis variable ordering and reordering in one go.2023-03-12T11:23:27ZDennis HendriksDraft: #378 CIF data-based synthesis variable ordering and reordering in one go.* The main idea is that the initial variable order and subsequent algorithms applied to it, are now one configuration, and they are applied in one go. This is a step in #378, towards also adding a new option that can create more complex ...* The main idea is that the initial variable order and subsequent algorithms applied to it, are now one configuration, and they are applied in one go. This is a step in #378, towards also adding a new option that can create more complex such configurations, but that can be applied in the same way.
* Probably easiest to review per commit, but there is some shuffling involved that in hindsight I could have maybe done in more separate commits.
* The variable ordering helper is now always created from the model order. This may change the variable order. For the test models, I checked each change manually, and found it to be different but equivalent. I'm running the benchmark models now, to see if/how it affects them. I'll post a separate comment about it. But the merge request can be reviewed already.
* Some other smaller changes, see commit messages of separate commits.
Addresses #378v0.9https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/512#534 Fail build on files not formatted according to the ESCET formatter profile2024-01-17T10:17:01ZDennis Hendriks#534 Fail build on files not formatted according to the ESCET formatter profile- Best to review per commit.
Closes #534- Best to review per commit.
Closes #534https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/541#480 develop to master for v0.9-RC12023-03-28T06:11:48ZDennis Hendriks#480 develop to master for v0.9-RC1Addresses #480Addresses #480v0.9https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/555#567 Unable to run CIF simulation in stand-alone mode using ./bin/cifsim2023-04-23T19:11:49ZPatrick van Berkel#567 Unable to run CIF simulation in stand-alone mode using ./bin/cifsimThis pull request implements a possible solution to the braking dependency to the Eclipse Workbench environment and workspace location for stand-alone application which implement dark mode.
### Support Dark mode
To be able to run the s...This pull request implements a possible solution to the braking dependency to the Eclipse Workbench environment and workspace location for stand-alone application which implement dark mode.
### Support Dark mode
To be able to run the stand-alone application it need to be able to do this without relying on the Eclipse theming facility. This however causes some issues because the OS mode (Dark or Light) also affects the color display by SWT. This means the stand-alone application still needs to change its colors based on the OS mode. For MacOS and Linux this can be solved as SWT supports the `org.eclipse.swt.widgets.Display#isSystemDarkTheme()` method. On Windows, however, this does not work as I would expect. SWT will only show Light theme even when it detects Windows is set to Dark Mode.
In more detailed words. See [SWT OS.setTheme()](https://github.com/eclipse-platform/eclipse.platform.swt/blob/master/bundles/org.eclipse.swt/Eclipse%20SWT%20PI/win32/org/eclipse/swt/internal/win32/OS.java#L2235):
``` c
// eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT PI/win32/org/eclipse/swt/internal/win32/OS.java
/*
* On Windows, there is no OS API for dark theme yet, and this method only
* configures various tweaks. Some of these tweaks have drawbacks. The tweaks
* are configured with defaults that fit Eclipse. Non-Eclipse applications are
* expected to configure individual tweaks instead of calling this method.
* Please see <code>Display#setData()</code> and documentation for string keys
* used there.
*/
```
One solution could be to introduce platform specific code in `EclipseThemeUtils` class.
``` java
import org.eclipse.swt.widgets.Display;
public static boolean isDarkThemeInUse() {
if (PlatformUI.getWorkbench()) {
// Running inside Eclipse UI.
IThemeEngine themeEngine = PlatformUI.getWorkbench().getService(IThemeEngine.class);
ITheme theme = themeEngine.getActiveTheme();
return theme != null && theme.getId().equals(ThemeEngine.E4_DARK_THEME_ID);
} else if (System.getProperty("os.name").contains("Windows")) {
// Running stand-alone on windows
return false;
} else {
// Running stand-alone on MacOS or Linux
return Display.isSystemDarkTheme();
}
}
```
An other solution which does not require platform specific code is to dynamically detect the mode based on the background color of the parent widget and determine if is dark or light.
This makes the code more independent from both the system mode and the Eclipse theme itself. The cost is a additional argument in all the color selection code in ESCET applications which need to able to run in stand-alone mode.
This second option in implemented in this Pull Request.
### Support running without a workspace
As described in the issue the addition of support for the Dark theme also introduced a dependency to the workspace location when running in stand-alone mode. The scripts which execute the stand-alone applications do, however not specify a workspace location.
One way to solve this is to add the -data argument to the scripts. A possible location could be the most recent workspace location used by the eclipse application, which is stored in "`{eclipse dir}./configuration/.settings/org.eclipse.ui.ide.prefs`". This file is not present after initial initialization, which means selecting a default location.
An others solution is to prevent remove the runtime dependency on this workspace location. In the current implementation the stand-alone application needs to know the workspace location to determine the theme related preference stored by Eclipse. This preference is used to detect runtime changes to the Eclipse theme. In the current implementation the stand-alone applications do not rely on the theme selected by Eclipse as it does not use it's `ThemeEngine` to apply a theme to SWT.
As such changes to this Eclipse preferences are not of interest when an ESCET application is running in stand-alone mode. This runtime dependency can be removed by disabling the subscription to the changes of this preference when workspace is not defined.
``` java
private void register() {
if (EclipseThemeUtils.isPlatformIntstanceSet()) { // preferences not available.
EclipseThemeUtils.getEclipseThemePreferences().addPreferenceChangeListener(this);
}
}
```
This second option in implemented in this Pull Request.
### Startup error for all `eventbased` stand-alone application.
While testing I found that all `cif.eventbased` applications fail when running in stand-alone mode.
```
> bin/cifsynthanalys -h
!ENTRY org.eclipse.osgi 4 0 2023-04-14 08:53:16.917
!MESSAGE Application error
!STACK 1
OSGi bundle "org.eclipse.escet.cif.eventbased.apps" not found.
```
I found-out that this is caused an invalid plugin name in the stand-alone startup scripts. These scripts currently seem to name the package (`org.eclipse.escet.cif.eventbased.apps`) instead of the plugin (`org.eclipse.escet.cif.eventbased`).
This Pull Request changed this for the following `./bin/*` scripts.
```
cifabstr, cifctrlchk, cifdfamin, ciflngeqv, cifncchk, cifnfadfa, cifobschk, cifprod, cifproj, cifsupsynth, cifsynthanalys, ciftrim, ciftrimchk
```
### Eclipse cifsynthanaly closing immediately.
Currently the Synthesis Analysis Application end immediately after the creation of the UI causing the application and UI to close.
As the UI thread `ControlEditor` does not expose the Thread is use its method called `isAvailable()` to monitor the GUI.
``` java
while (editor.isAvailable()) {
ThreadUtils.sleep(500);
}
```
# Code demonstrating issues with Dynamic retheming in SWT:
[TestDynamicChangesToSWTSettings.java](/uploads/41b756a9ff87e4e77d3241b23244ae52/TestDynamicChangesToSWTSettings.java)v0.10https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/562#418 PLCgen: add default initial values to the converted state variable decla...2023-04-30T07:46:58ZAlbert Hofkamp#418 PLCgen: add default initial values to the converted state variable declarations.Short patch, can be read by individual commit, which looks like the better approach for reviewing.
Addresses #418Short patch, can be read by individual commit, which looks like the better approach for reviewing.
Addresses #418v0.10Albert HofkampAlbert Hofkamphttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/595Draft: #520 Add algorithm by Fei et al. (2014) to compute edge dependency sets2023-05-29T14:40:45ZDennis HendriksDraft: #520 Add algorithm by Fei et al. (2014) to compute edge dependency sets* This merge quest is based on a somewhat outdated version of !587, and includes the changes of that older version of !587 as well. The relevant commits are f6612fc387e8fabd2b49fab6e7cf1319b22d3f78 and later. If we want to keep this merg...* This merge quest is based on a somewhat outdated version of !587, and includes the changes of that older version of !587 as well. The relevant commits are f6612fc387e8fabd2b49fab6e7cf1319b22d3f78 and later. If we want to keep this merge request and merge it, I'll recreate it based on the latest version, and then I'll also clean up the history. However, I propose not to ever merge it, see below.
* Getting a working solution:
* I tried to implement the algorithm from Fei et al. (2014) that I summarized [here](https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/520#note_1114569).
* I found that it has [a bug](https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/520#note_1140352) that I fixed, at the cost of significantly larger dependency sets, which will reduce the performance of the workset algorithm. But, correctness is more important than performance.
* The `FeiEdgeDependencySetCreator` now includes various additions compared to the orginal algorithm of Fei et al. (2014), to fix the bug, but also to account for various features of the CIF language that we support in data-based synthesis, but that were not in the EFAs as defined by Fei et al.
* This modified algorithm works for our entire regression test set, where I temporarily enabled the workset algorithm for all tests. Thus, I'm not aware of any issues in this implementation.
* But it has become complex:
* The `FeiEdgeDependencySetCreator` has 576 lines.
* Several parts of the algorithm now have long sections with comments that explain why certain modifications of the algorithm are needed. It is not exactly simple anymore.
* The order in which various concepts are considered needs to be exactly right, or things go wrong. I made mistakes several times while working on it. I can't be sure there are more issues in it.
* Getting the dependencies right, such that they work for our regression tests required quite some trial and error. I can't be sure it works for all models, only that it works for the ones in the current regression test set.
* Fundamentally, what I don't like about the algorithm is that it tries to compute when things can follow. However, as the bug showed, this is both difficult to determine statically. It requires that sufficient dependencies are found and unioned together. But how do we now that we didn't miss some dependency that only in some rare situations is needed. Guaranteeing that we don't have an under-approximation seems practically impossible.
* It seems the whole algorithm is now useless:
* The unit tests were adapted in a separate commit after the fix, to show how much the depencies increase. In fact, all unit tests now have the full/maximal dependency set.
* Similarly, for all integration tests, the dependency sets are full/maximal dependency sets.
* Thus, we could just as well use `AllEdgesEdgeDependencySetCreator`, which gives the same dependency sets, which much simpler code.
* I created a merge request for two reasons:
* I think it is good to keep this attempt archived. However, in the current state I don't propose to merge it.
* @ahofkamp is working on something similar, for the PLC code generator, in #595. It may be useful to be aware of all this, to take it into account there as well.
* I've come up with an alternative, see #602.
Addresses #520v0.10