escet merge requestshttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests2022-09-30T13:03:49Zhttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/378#390 develop to master for v0.72022-09-30T13:03:49ZDennis Hendriks#390 develop to master for v0.7Addresses #390Addresses #390v0.7https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/377#390 Update release notes for v0.7.2022-09-30T12:36:51ZDennis Hendriks#390 Update release notes for v0.7.Addresses #390Addresses #390v0.7https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/375#392 develop to master for v0.7-RC12022-09-28T11:54:46ZDennis Hendriks#392 develop to master for v0.7-RC1Addresses #392Addresses #392v0.7https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/373#416 Add tests for CIF common checks2022-10-09T15:47:26ZDennis Hendriks#416 Add tests for CIF common checksNotes:
* The CIF common checks are not application framework applications, but more like library functionality. I therefore added an application specifically for testing. Then I just used the integration test framework as usual.
* I name...Notes:
* The CIF common checks are not application framework applications, but more like library functionality. I therefore added an application specifically for testing. Then I just used the integration test framework as usual.
* I named the tests after the check class that they use, to allow the test application to be reused for all them.
* The expression and type checks are parameterized. Hence, I created in the test plugin some derived classes. They essentially test per level (based on the number of '_' characters in the enum values). This allows testing for instance `PLUS` vs `PLUS_INT` vs `PLUS_INT_RANGED`. It doesn't test all 'logic paths', as `PLUS_INT_RANGED` and `PLUS_INT_RANGELESS` are still tested together. But we get quite some coverage this way.
I recommend reviewing the total changes, rather than the individual commits.
Closes #416v0.7https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/372#425 Update release process documentation2022-09-26T12:31:31ZDennis Hendriks#425 Update release process documentationCloses #425Closes #425v0.7https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/371#392 Update release notes for v0.7-RC1.2022-09-28T10:14:27ZDennis Hendriks#392 Update release notes for v0.7-RC1.Addresses #392Addresses #392v0.7https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/370#419 Added Oisterwijksebaan bridge real-world CIF synthesis example2022-09-29T11:16:31ZDennis Hendriks#419 Added Oisterwijksebaan bridge real-world CIF synthesis exampleAdapted/improved from https://github.com/ffhreijnen/OBB.
Closes #419Adapted/improved from https://github.com/ffhreijnen/OBB.
Closes #419v0.7https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/368#398 Various CIF check violation reporting improvements2022-09-23T06:38:53ZDennis Hendriks#398 Various CIF check violation reporting improvementsI opted to create a new merge request, rather than updating !350, as due to renaming all checks, there were heavy conflicts.
While implementing the design discussed at https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/350#...I opted to create a new merge request, rather than updating !350, as due to renaming all checks, there were heavy conflicts.
While implementing the design discussed at https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/350#note_959716, it quickly became more complicated than expected.
The messages may depend on whether the violation is reported on the object itself, or an ancestor of that object.
For instance, for a named location, it will report on the object itself, and it 'is urgent', while for a nameless location, it will be reported on the parent automaton, which 'has an urgent location'.
I then added a second replacement pattern, allowing for conditional replacement, explained it in the JavaDoc, etc.
This became a monster, and was completely non-extensible.
I therefore opted for a more extensive design, allowing for arbitrary trees of messages, and which is easily extensible.
Summary of the changes:
* `CifViolation` and `CifViolations` now allow reporting violations on both 'Specification' objects and 'null' values. This allows checks to just report violations on components, and not have to worry about whether they happen to be a `Specification`.
* `CifViolations` normalizes `Specification` objects to `null`, to have a single unique representation for specifications. This simplifies some of the other changes.
* `CifViolation` and `CifViolations` now allow reporting on non-named object. If the object is not named, they will automatically find the closest named ancestor and use that instead. The checks no longer have to find that closest named ancestor themselves anymore.
* Improved the JavaDoc with violation reporting instructions.
* Introduced message trees (type `CifCheckViolationMessage`) to build up more complex messages. `LiteralMessage` is for literal text. `ReportObjectTypeDescriptionMessage` implements the `{type-of-reported-object}` placeholder that we discussed at https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/350#note_959716. It uses the new `CifTextUtils.getTypeDescriptionForNamedObject` method. `IfReportOnSelfMessage` and `IfReportOnAncestorMessage` allow for conditional messages for when reporting on the object itself, or an ancestor. `SequenceMessage` allows concatenating messages, but should rarely be needed directly, as `CifViolations.add` has a varargs parameter for messages, so for the top level of the messages, it adds the `SequenceMessage` wrapper automatically.
* `CifViolation` can no longer decide from its field alone whether it will produce the same message as another `CifViolation` instance. Hence, `CifPreconditionChecker` removes duplicate messages now.
* I also fixed and improved some violation messages.
Closes #398v0.7https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/367#347 Add dark theme support for/to SeText-based text editors2022-09-23T07:08:51ZDennis Hendriks#347 Add dark theme support for/to SeText-based text editorsAbout the design of the text editor light/dark theme support:
* The idea is that the SeText base text editor gets most of the logic, keeping the effort needed to support different themes in the specific text editors to a minimum.
* Each ...About the design of the text editor light/dark theme support:
* The idea is that the SeText base text editor gets most of the logic, keeping the effort needed to support different themes in the specific text editors to a minimum.
* Each text editor defines a `...TextEditorStyleNames`, an enum with named styles. The `TextEditorTheme` interface allows mapping named styles to concrete `Style` instances, and thus allows defining multiple themes. Each text editor defines a `...TextEditorLightTheme` and `...TextEditorDarkTheme` for their `...TextEditorStyleNames`. The text editors previously used to define `...Styles` with the named styles and concrete styles directly coupled. This is thus split to `...TextEditorStyleNames` and `...TextEditorLightTheme`.
* The light themes for all text editors still use the same styles. The one exception is that their `DEFAULT` styles are now all black, rather than some off-black slightly-brownish color. I have no clue why we ever defined that color.
* I invented new dark theme color schemes. I tried to use similar colors as for the light theme, to keep the colors recognizable (e.g., CIF controllable/uncontrollable event colors). Obviously black-like colors becomes white-like colors, etc. I spent quite a bit of time to ensure the colors are distinct from each other, but also have enough contrast with the editor background, and have a bit of a consistent feel in terms of brightness etc.
* Each text editor gets a preference page in the Eclipse Preferences window. There you can configure the editor to use a dark or light theme. But by default an automatic theme is configured that uses a dark or light theme depending on the current Eclipse theme. This way, it should work out of the box in most cases, and users won't have to configure these settings.
* I hooked into the preference system to monitor for changes to our own text editor preferences, as well as the Eclipse theme preferences. If any of these settings change, all open text editors automatically get rethemed to match the new settings.
* The common/shared Eclipse theme functionality is in the application framework. This allows reusing it for #417. I would have rather put it in `org.eclipse.escet.common.eclipse.ui`, but that creates dependency cycles when using the functionality in the application framework.
* I opted for using internal Eclipse APIs to access `ThemeEngine.THEME_PLUGIN_ID` and `ThemeEngine.E4_DARK_THEME_ID`, which contain the name of the plugin that defines some of the theming preferences, and the name of the Eclipse built-in dark theme. I could have opted to just hardcode the strings by copying them. However, this way we get compile issues if the plugin is renamed or so, which means we are less likely to have broken dark theme support upon changes to Eclipse itself.
* I could not find a general way to reliably detect whether the current Eclipse theme is a light or dark theme. I therefore opted to support only the built-in Eclipse themes for the automatic mode. As a consequence, if a user installs some custom dark theme, it does not get detected as a dark theme, and will thus be detected as a light theme, with our text editors also going to light theme mode. I'm not sure whether there is a better way to do this. Maybe we could check some background color of the current theme instead. But that seems more complicated. I doubt many users install custom themes, and if they do, they can also explicitly configure our text editors to use a light or dark theme, rather than using the automatic mode. So, for now this seemed sufficient.
* The CIF to yEd conversion uses the CIF text editor light theme, for backward compatibility.
The changes in the branch seem big, but a lot of it is just changed test output, or similar changes in various text editor plugins. I propose to review not per commit, but instead the final resulting changes, in this order:
* The new general Eclipse theme functionality in the `o.e.e.common.app.framework` plugin.
* Changes and additions in the `o.e.e.setext.texteditorbase` plugin.
* Changes to the Chi, CIF, SeText and ToolDef text editor plugins, which are all very similar.
* Changes to CIF to yEd plugin.
* Changes to CIF to yEd test output.
Closes #347v0.7https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/366#391 develop to master for v0.7-M12022-09-04T11:34:09ZDennis Hendriks#391 develop to master for v0.7-M1Addresses #391Addresses #391v0.7https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/365#391 Updated release notes for v0.7-M1.2022-09-04T11:00:02ZDennis Hendriks#391 Updated release notes for v0.7-M1.Addresses #391Addresses #391v0.7https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/364#411 Enable automatic reporting of new dependencies to Eclipse IP Team.2022-08-26T18:19:58ZDennis Hendriks#411 Enable automatic reporting of new dependencies to Eclipse IP Team.Closes #411
Note that are is no real way to test this, as we don't want to submit fake requests to the Eclipse Foundation IP team. We'll test it the first time we use it. But it should work, as the Eclipse LSAT team also used it.Closes #411
Note that are is no real way to test this, as we don't want to submit fake requests to the Eclipse Foundation IP team. We'll test it the first time we use it. But it should work, as the Eclipse LSAT team also used it.v0.7https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/363#412 Remove feature url/version from category.xml + update dev docs.2022-08-26T18:20:39ZDennis Hendriks#412 Remove feature url/version from category.xml + update dev docs.Closes #412Closes #412v0.7https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/362#297 #405 CIF event-based language equivalence check generates incorrect coun...2022-09-04T10:51:11ZFerdie Reijnen#297 #405 CIF event-based language equivalence check generates incorrect counterexamplesCloses #297 #405Closes #297 #405v0.7https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/361#402 Double dash in branch-names are interpreted as CJK ideographs2022-08-22T12:09:16ZFerdie Reijnen#402 Double dash in branch-names are interpreted as CJK ideographsCloses #402Closes #402v0.7https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/359#404 Event-based synthesis analysis tool has wrong conclusion2022-08-19T17:51:35ZFerdie Reijnen#404 Event-based synthesis analysis tool has wrong conclusionCloses #404Closes #404v0.7https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/358#403 Rename checker classes to simplify finding them2022-08-22T12:07:18ZAlbert Hofkamp#403 Rename checker classes to simplify finding themCloses #403Closes #403v0.7Albert HofkampAlbert Hofkamphttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/356#401 Be more careful in ignoring 'target' directories2022-08-11T04:59:09ZAlbert Hofkamp#401 Be more careful in ignoring 'target' directoriesCloses #401Closes #401v0.7Albert HofkampAlbert Hofkamphttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/355#364 CIF data-based synthesis performance test models: sudoku2022-08-10T19:46:21ZFerdie Reijnen#364 CIF data-based synthesis performance test models: sudokuAddresses #364Addresses #364v0.7https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/354#364 CIF data-based synthesis performance test models: bridge2022-08-10T07:51:40ZFerdie Reijnen#364 CIF data-based synthesis performance test models: bridgeAddresses #364Addresses #364v0.7