escet merge requestshttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests2023-05-25T10:50:13Zhttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/589#592 Unify cif2plc and plcgen model classes2023-05-25T10:50:13ZAlbert Hofkamp#592 Unify cif2plc and plcgen model classes- Added `PlcTarget` to the writers for access to the model text generator.
- Removed `PlcValue` class.
- Renamed `OutputTypeWriter` to `Writer` class.
The other copied classes seem fine for now (see #592 for a list). Likely the target-s...- Added `PlcTarget` to the writers for access to the model text generator.
- Removed `PlcValue` class.
- Renamed `OutputTypeWriter` to `Writer` class.
The other copied classes seem fine for now (see #592 for a list). Likely the target-specific writers need more work eventually but that seems a bit premature for now.
Addresses #592
Note: "Organize imports" made the following change:
``` diff
index 74a08bd98..59dcc73c9 100644
--- a/cif/org.eclipse.escet.cif.plcgen/src/org/eclipse/escet/cif/plcgen/model/functions/PlcSemanticFuncDescription.java
+++ b/cif/org.eclipse.escet.cif.plcgen/src/org/eclipse/escet/cif/plcgen/model/functions/PlcSemanticFuncDescription.java
@@ -13,8 +13,6 @@
package org.eclipse.escet.cif.plcgen.model.functions;
-import org.eclipse.escet.cif.plcgen.model.functions.PlcBasicFuncDescription.ExprBinding;
-
/** Function description extended with the semantic operation being performed in a function application. */
public class PlcSemanticFuncDescription extends PlcBasicFuncDescription {
/** The semantic operation performed by the function application. */
```
It's needed to avoid a warning in JavaDoc, but it's apparently thus not recognized in for that in the JDT.v0.10Albert HofkampAlbert Hofkamphttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/588#596 PLCgen: add transition generator skeleton2023-05-25T10:25:28ZAlbert Hofkamp#596 PLCgen: add transition generator skeletonAdds a skeleton for the transition generator, mostly to create a common ground to extend further.
Addresses #596Adds a skeleton for the transition generator, mostly to create a common ground to extend further.
Addresses #596v0.10Albert HofkampAlbert Hofkamphttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/587#520 Add workset algorithm to data-based synthesis2023-05-30T18:50:19ZDennis Hendriks#520 Add workset algorithm to data-based synthesis* This adds the workset algorithm. Its 2 key ingredients, the edge selection heuristic and edge/event dependency sets, will be improved in later merge requests. See also the step by step plain in #520.
* Best to review per commit.
* I al...* This adds the workset algorithm. Its 2 key ingredients, the edge selection heuristic and edge/event dependency sets, will be improved in later merge requests. See also the step by step plain in #520.
* Best to review per commit.
* I also tested it by running the benchmarks with and without the workset algorithm, and running all tests with the workset algorithm. This didn't reveal any issues.
Addresses #520v0.10https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/586#554 develop to master for v0.10-M12023-05-17T07:17:47ZDennis Hendriks#554 develop to master for v0.10-M1Addresses #554Addresses #554v0.10https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/585#554 Updated release notes for v0.10-M1.2023-05-17T06:55:42ZDennis Hendriks#554 Updated release notes for v0.10-M1.Addresses #554Addresses #554v0.10https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/584#594 Extend `ExprGenerator` with local and temporary variable support.2023-05-16T08:31:30ZAlbert Hofkamp#594 Extend `ExprGenerator` with local and temporary variable support.Small but useful step in expression code generation from last week before the statement copy bug was found.
Closes #594Small but useful step in expression code generation from last week before the statement copy bug was found.
Closes #594v0.10Albert HofkampAlbert Hofkamphttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/583#586 Add edge granularity option.2023-05-16T21:06:09ZDennis Hendriks#586 Add edge granularity option.- Best to review per commit.
Closes #586- Best to review per commit.
Closes #586v0.10https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/582#585 Add warning for exploring CIF specifications with requirements2023-05-15T07:10:45ZDennis Hendriks#585 Add warning for exploring CIF specifications with requirementsCloses #585Closes #585v0.10https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/580#588 Copy `cif2plc` classes to `plcgen`2023-05-15T12:35:28ZAlbert Hofkamp#588 Copy `cif2plc` classes to `plcgen`Copying all used cif2plc classes to plcgen to make the latter independent of the former.
Closes #588Copying all used cif2plc classes to plcgen to make the latter independent of the former.
Closes #588v0.10Albert HofkampAlbert Hofkamphttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/579#582 Ensure single point of responsibility in generating names and artefacts ...2023-05-12T07:30:31ZAlbert Hofkamp#582 Ensure single point of responsibility in generating names and artefacts in the main programChanges:
1. Make it simpler to access any generator from any generator (that is, discard the non-cyclic dependencies restriction between them).
2. Give the `PlcCodeStorage` ownership of the expression generator to use for generating cod...Changes:
1. Make it simpler to access any generator from any generator (that is, discard the non-cyclic dependencies restriction between them).
2. Give the `PlcCodeStorage` ownership of the expression generator to use for generating code for its main program.
3. Replace the hard-coded variable names in the main program by generated local names to ensure uniqueness.
With respect to the first change, rather than the discussed 3rd option in the issue (explicitly distributing generator links from the target during setup), I opted for the simpler form of storing the links in the active target and allow any generator to retrieve them as needed.
Closes #582v0.10Albert HofkampAlbert Hofkamphttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/578#583 Generalize controller-check cycle finder2023-05-17T08:02:41ZAlbert Hofkamp#583 Generalize controller-check cycle finderI need a simple cycle finder (a simple cycle is a cyclic sequence of nodes that does not cross itself) for sequencing, and decided to generalize the cycle finder in the finite response controller check.
It's not the fastest thing but at ...I need a simple cycle finder (a simple cycle is a cyclic sequence of nodes that does not cross itself) for sequencing, and decided to generalize the cycle finder in the finite response controller check.
It's not the fastest thing but at least it's simple and stable (giving the same results under permutation of the vertices).
Reading by each commit individually is best.
It starts by duplicating the cycle finder and stripping the comments from the generic version, and then slowly refactoring towards a proper generic cycle finder for directed graphs and its controller check application. The second to last commit moves event expansion of an edge from before the search to after detecting a cycle, which can be a big performance gain. The final commit move the generic class to `common.java`.
Closes #583v0.10Albert HofkampAlbert Hofkamphttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/577#580 Data-based synth updates conversion: reverse unchanged vars order.2023-05-08T19:19:52ZDennis Hendriks#580 Data-based synth updates conversion: reverse unchanged vars order.* This improves the performance of synthesis, or rather the conversion of the CIF model to the synthesis representation. See #580 for an explanation why this is the case.
* I'll add benchmarking results in a separate comment.
Closes #580* This improves the performance of synthesis, or rather the conversion of the CIF model to the synthesis representation. See #580 for an explanation why this is the case.
* I'll add benchmarking results in a separate comment.
Closes #580v0.10https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/576#548 Allow omitting 'else' for CIF switch expressions more liberally2023-05-08T21:49:40ZDennis Hendriks#548 Allow omitting 'else' for CIF switch expressions more liberally* Switch expression type checking for switches over non-automata is now similar to the checking for automata.
* Fixed `CifValueUtils.hasSingleValue` JavaDoc.
* Fixed `ErrMsg` constraint comment to allow 'chk.bash' to succeed.
Best to re...* Switch expression type checking for switches over non-automata is now similar to the checking for automata.
* Fixed `CifValueUtils.hasSingleValue` JavaDoc.
* Fixed `ErrMsg` constraint comment to allow 'chk.bash' to succeed.
Best to review per commit.
Closes #548v0.10https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/574#577 Change eclipse.org to eclipse.dev2023-05-08T19:17:10ZDennis Hendriks#577 Change eclipse.org to eclipse.dev* Changed `eclipse.org` to `eclipse.dev`, where relevant. I didn't update the namespace URIs of the metamodels, to ensure models stay backwards compatible. Since `eclipse.org` stays registered to the Eclipse Foundation, I don't think we ...* Changed `eclipse.org` to `eclipse.dev`, where relevant. I didn't update the namespace URIs of the metamodels, to ensure models stay backwards compatible. Since `eclipse.org` stays registered to the Eclipse Foundation, I don't think we need to change this.
* Changed `www.eclipse.dev` to `eclipse.dev`. The non-www variant is now the canonical URL, so removed all `www.` parts for `www.eclipse.dev/escet`. This also fixes bugs, as for `www.eclipse.org/escet/<version>` and now `www.eclipse.dev/escet/<version>`, `<version>` was not replaced for URLs with `www.`. For more robustness, now also `www.` URLs are rewritten.
* Removed an outdated comment in CIF documentation sources.
Most easily reviewed per commit, to see similar changes together.
Addresses #577v0.10https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/573#418 Initialize state variables2023-05-10T05:02:48ZAlbert Hofkamp#418 Initialize state variablesGenerate initialization code of state variables.
Reading by commit works, although it may not even be needed.
Fixes #418Generate initialization code of state variables.
Reading by commit works, although it may not even be needed.
Fixes #418v0.10Albert HofkampAlbert Hofkamphttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/571#578 Added a new 'Tool invocation' option to the ToolDef interpreter2023-05-02T13:56:05ZDennis Hendriks#578 Added a new 'Tool invocation' option to the ToolDef interpreter* Also improved/fixed the documentation of ToolDef interpreter.
* Probably best to review per commit.
Closes #578* Also improved/fixed the documentation of ToolDef interpreter.
* Probably best to review per commit.
Closes #578v0.10https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/567#523 Optimize enforcement of state plant invariants like state requirement in...2023-06-22T19:54:29ZDennis Hendriks#523 Optimize enforcement of state plant invariants like state requirement invariantsIt seems for the test models we have, the change actually makes things worse. Then again, we had something similar for state requirement invariants, if I remember correctly. The test models are simply too small and too few to reach any r...It seems for the test models we have, the change actually makes things worse. Then again, we had something similar for state requirement invariants, if I remember correctly. The test models are simply too small and too few to reach any real conclusion. And for real-world models, for state requirement invariants, it did actually improve performance, a lot. So, here we just do the same for state plant invariants. We currently don't have enough test or real-world models to conclude what is best either way.
Closes #523v0.10https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/566#553 Event-based synthesis: warn if no requirement automata.2023-04-28T17:59:57ZDennis Hendriks#553 Event-based synthesis: warn if no requirement automata.- Also fixed a JavaDoc.
- Also added some section comments.
- Also removed an inconsistent empty source code line.
Closes #553- Also fixed a JavaDoc.
- Also added some section comments.
- Also removed an inconsistent empty source code line.
Closes #553v0.10https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/563#571 ToolDef readlines/writefile improvements2023-04-28T12:24:26ZDennis Hendriks#571 ToolDef readlines/writefile improvements* `readlines`/`writefile`: use try-with-resources.
* `readlines`: use UTF-8 encoding, to match `writefile`. Also, we always use UTF-8, rather than the default (platform) encoding, and especially ToolDef should be platform-independent.
* ...* `readlines`/`writefile`: use try-with-resources.
* `readlines`: use UTF-8 encoding, to match `writefile`. Also, we always use UTF-8, rather than the default (platform) encoding, and especially ToolDef should be platform-independent.
* `writefile`: different way of handling new lines.
* Added new optional `newline` argument.
* Default of `newline` is `platform`, for backward compatibility.
* Allows `preserve` for writing `text` to write raw `text`.
* Allows custom specific new lines to be used as well.
* No `preserve` when writing `lines` as then may be get mixed new lines.
* Extended ToolDef documentation for the `readlines`/`writefile` tools.
Closes #571v0.10https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/560#399 #468 #221 Upgrade to Eclipse 2023-03 with in-place upgrade2023-05-30T18:55:39ZDennis Hendriks#399 #468 #221 Upgrade to Eclipse 2023-03 with in-place upgradeGeneral info on merge request:
* This upgrades from Eclipse 2022-06 to 2023-03. See the individual commits for details. Best reviewed per commit.
* You can set up a new development environment from scratch, but you can also in-place upgr...General info on merge request:
* This upgrades from Eclipse 2022-06 to 2023-03. See the individual commits for details. Best reviewed per commit.
* You can set up a new development environment from scratch, but you can also in-place upgrade your existing development environment now. See the `dependency-upgrades.asciidoc` file for the instructions. **It would be nice if you could all try that out**, so that we can mature the instructions listed there.
In this particular instance, you need to remove the 'Tycho Project Configurators' manually, if you have them still in your development environment. See the step-by-step instructions for details.
Some issues I had while trying out the in-place update. I was trying things out and did not use the step-by-step instructions as they are now, so hopefully you will not encounter them, but it **would be good if you could try**, to see how 'stable' and in-place update is in practice:
* When pressing 'Ctrl+Shift+T' for 'Open Type' I at some point had two commands associated to it. I restored all default keybindings to resolve this.
* Using the 'Open Type' dialog and choosing a class from the JDK led to errors like: `Type 'java.lang.String' could not be found in '.org.eclipse.jdt.core.external.folders/.link23/jre/lib/jrt-fs.jar'. Make sure all workspace resources are refreshed.`. A workspace refresh and full clean/rebuild did not resolve this. I solved it by removing all projects from my workspace and re-importing them.
* Commiting the provisioning operation (for P2 or target platform) by Oomph would fail with `java.lang.ClassCastException: class org.bouncycastle.openpgp.PGPPublicKey cannot be cast to class org.bouncycastle.openpgp.PGPPublicKey (org.bouncycastle.openpgp.PGPPublicKey is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @685f5d0d; org.bouncycastle.openpgp.PGPPublicKey is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @4e2f2438)`.
I resolved this by updating the Oomph version in my development environment: 'Help' -> 'Check for updates...', which only listed Oomph updates, and then 'Next' -> 'Next', accepting all licenses, 'Finish', 'Select all' -> 'Trust selected' -> 'Restart Now'.
Important further details on the changes, some of which affect our way of working into the future:
* I got rid of the Apache XML serializer specific version pinning that was needed for the previous Eclipse version. However, I also got rid of that dependency altogether later on (see next point).
* I had quite some issues with getting Apache Xalan, Apache Xerces and Apache XML resolver to work properly. They were complaining about missing `Import-Package` dependencies.
The packages were JDK packages, so should always be present. I spent hours on this, but didn't manage.
Then I realized that (probably about a decade ago) I introduced them as the XML functionality of the JDK itself at that time wasn't working.
But we use much newer JDKs now, so these dependencies are no longer needed. I thus reduced the dependencies and no longer needed code/comments related to them.
This also fixes issues with saving SVG files from the SVG viewer/visualizer to paths with characters that get encoded as special characters in URLs, such as spaces.
This issue is unresolved for Apache Xalan, but my tests show that the JDK implementation handles this properly.
* I added the Eclipse PDE runtime (with 'Plug-in Registry' view) to the product, to enable debugging of dependency problems.
* The version of `org.apache.commons.lang3` got updated, deprecating its `StringEscapeUtils`. The class essentially got moved to `org.apache.commons.text`, but that is not available on Orbit, nor in the Eclipse 2023-03 update site.
Eclipse Platform and its projects are now using dependencies directly from Maven Central, if they are available there, and have proper OSGi metadata in their manifest (see [here](https://www.eclipse.org/lists/cross-project-issues-dev/msg19288.html), [here](https://www.eclipse.org/eclipse/news/4.25/pde.php#default-3rd-party-bundles) and [here](https://github.com/eclipse-platform/eclipse.platform.common/blob/master/bundles/org.eclipse.platform.doc.isv/porting/4.25/incompatibilities.html)).
In fact, they plan to no longer update or add such dependencies to Orbit at all, in the future (see [here](https://www.eclipse.org/lists/cross-project-issues-dev/msg19616.html)).
Hence, it makes sense that if we need additional dependencies, that we go the same route.
Eclipse PDE and Eclipse Tycho both support target platforms with Maven targets.
However, Oomph does not.
We therefore can no longer generate our target platform using Oomph, and have to switch to a manually crafted target platform.
This has the additional benefit that there will be less unneeded 'crap' in the target platform.
I implemented this change, removing target platform generation from the Oomph setup, and I manually cleaned up the target platform.
It is still possible to let Oomph reactive the target platform, after having edited it. This works in the same way as previous we generated a new target platform using Oomph. The Oomph task has a slightly different name, but is named in such a way that it is clear which one to use.
You can also just open the target platform file and pressing the 'Reload Target Platform' button at the top-right of the 'Definition' tab.
* Since our previous Eclipse upgrade, I get a lot of info-level items in the 'Problems' view when opening XML-based files that don't link to their schema. I configured Wild Web Developer's XML tools to ignore such 'issues'.
* We have M2E settings in our development environment configuration (set by Oomph) to ignore missing M2E lifecycle mappings. However, I still got some, and thus explicitly ignored them in `pom.xml` files.
* The Eclipse JDT compiler tool is no longer provided as a plug-in fragment, but is now provided as a regular plugin. Hence, we don't need special configuration for it anymore for our Maven build. See also [here](https://www.eclipse.org/eclipse/news/4.27/jdt.php#ecj-separated-from-core).
* When upgrading to Eclipse 2022-06, we had to ensure all projects have a project-specific encoding, or projects would get a warning. How, this can be configured to be ignored (see [here](https://www.eclipse.org/eclipse/news/4.25/platform.php#specify-project-encoding-severity) and [here](https://github.com/eclipse-platform/eclipse.platform.resources/issues/166)). We already configure the global encoding in the Eclipse ESCET product, so there is no need for project-specific encodings. Especially for projects of the user, this was annoying. Also, the changes we previously made to ensure the CIF examples and benchmarks had no such warnings (see !331, comment 828762), are no longer needed, and I thus reverted them.
* The development environment now contains Maven 3.8.7, but the Eclipse Foundation Jenkins servers only have 3.8.6, so they don't match, but hopefully that is not a big deal.
Other issues resolved by upgrading to a newer Eclipse version:
* The SVG viewer/visualizer 'Save as' dialog now properly starts in the right initial proposed directory. This fixes #221.
* We can now use records in our Java code without getting warnings about JavaDocs.
Remaining issues:
* We now require PGP signing, for the dependencies we take directly from Maven Central. This requires a PGP key that we have to request from the Eclipse IT team, so I'll do this in a separate isuse.
Closes #399 #468 #221v0.10