escet issueshttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues2024-03-27T15:21:40Zhttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/717Release v3.0-RC12024-03-27T15:21:40ZDennis HendriksRelease v3.0-RC1v3.0Dennis HendriksDennis Hendriks2024-03-27https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/792CIF tutorial: 'Variable overview' is missing input variables2024-03-26T17:10:20ZDennis HendriksCIF tutorial: 'Variable overview' is missing input variablesThey come in a later lesson, but it would be good to refer to that, such that readers don't expect this list to be complete without them.They come in a later lesson, but it would be good to refer to that, such that readers don't expect this list to be complete without them.v3.0Dennis HendriksDennis Hendrikshttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/795Windows Defender SmartSreen window on first-time startup of ESCET2024-03-26T17:00:16ZMartijn GoordenWindows Defender SmartSreen window on first-time startup of ESCETWhen I was testing out the changes for !841, I run that version (downloaded from https://ci.eclipse.org/escet/job/ESCET%20build/job/MR-841/3/) on the Windows Server we are using within Rijkswaterstaat. With this new version, I got a Wind...When I was testing out the changes for !841, I run that version (downloaded from https://ci.eclipse.org/escet/job/ESCET%20build/job/MR-841/3/) on the Windows Server we are using within Rijkswaterstaat. With this new version, I got a Windows Defender SmartScreen window on the first-time startup of this ESCET version. See screenshot below. Only after clicking `More info` will there be the button `Run anyway` to start ESCET. After this first time, this window doesn't pop-up any longer.
![Screenshot_2024-03-26_at_11.38.08](/uploads/fd5a8705ed9797c364369805206e312a/Screenshot_2024-03-26_at_11.38.08.png)
I'm used to seeing such a screen on my MacBook, but this was the first time seeing it on a Windows machine. We are running Windows Server 2019 Standard, Version 1809.
Can another Windows user confirm whether they get this message with the latest ESCET version (maybe check for the upcoming release candidate)? If this is something new for Windows, we should include additional instructions on our download page.v3.0https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/782PLCgen: Improve documenting PLC transition code steps2024-03-26T11:11:38ZAlbert HofkampPLCgen: Improve documenting PLC transition code stepsCurrently the PLC code generator creates transition code without much comment. This means it may be difficult to follow what the code is computing.
To improve, the generator should create more comments in the transition code, with detai...Currently the PLC code generator creates transition code without much comment. This means it may be difficult to follow what the code is computing.
To improve, the generator should create more comments in the transition code, with details what is being done (or not done), and why (if applicable).
#774 is close to this, but addresses the more general problem of names and easy to understand (magic) numbers. This issue is about comments in/for the code rather than the code itself.
Addresses #679 #774v3.0Albert HofkampAlbert Hofkamphttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/791Use ESCET logo in relevant places2024-03-26T07:22:21ZDennis HendriksUse ESCET logo in relevant placesWe're close to having a logo in #777. Once we have it, we should use it in the appropriate places. For now, I foresee the following places:
- [x] ESCET website (!838)
- ESCET logo on ESCET home page.
- ESCET favicon for the ESCET st...We're close to having a logo in #777. Once we have it, we should use it in the appropriate places. For now, I foresee the following places:
- [x] ESCET website (!838)
- ESCET logo on ESCET home page.
- ESCET favicon for the ESCET static website pages (the yellow pages), like already there for CIF, etc.
- ESCET favicon for the ESCET general toolkit documentation and the development documentation, like already there for other docsets.
- Add icons in the site selector dropdown (the one from the top bar, on the very left enty of that bar, to select different websites ESCET/CIF/etc).
- [x] ESCET IDE (!840)
- Change the splash screen image.
- Change the about screen image.
- Change the welcome screen image.
- Change the icon of the ESCET perspective.
- Change the 'feature image'.
- Change the 'window images'.
- Add an executable icon (for Windows). We currently don't have one yet, and thus get the generic Eclipse icon.
- [x] Project website / PMI
- [x] Add the logo to https://projects.eclipse.org/projects/technology.escet. See also https://www.eclipse.org/projects/handbook/#promoting-project-logo.v3.0Dennis HendriksDennis Hendrikshttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/777Decide on a logo for Eclipse ESCET2024-03-21T12:48:50ZDennis HendriksDecide on a logo for Eclipse ESCETWhen we created Eclipse ESCET and were preparing the initial contribution, we also looked into a logo for Eclipse ESCET as a project. We had a professional designer (we knew here via one of the people involved in preparing the initial co...When we created Eclipse ESCET and were preparing the initial contribution, we also looked into a logo for Eclipse ESCET as a project. We had a professional designer (we knew here via one of the people involved in preparing the initial contribution) make a few first sketches for us. This resulted in 5 potential ideas for a logo. Some responses were given, preferences indicated, but somehow this stopped then. Probably we were too busy with other things.
I still think the project needs a logo. It helps in branding for recognition.
The goal of this issue is to discuss potential logos, and decide on one. It is not a goal of this issue to apply it everywhere that it could be applied in the codebase. I propose to do that in a follow-up issue, once we have the logo. It is a goal of this issue to decide on the logo, fully design it, and store it in the repo.
**The logo ideas from 2019**
The designer made the following logos (with the description we got with them, translated as directly as possible from Dutch to English):
1) "simple logo with only the C the eclipse symbol with a sort of arrow to toolbox"
2) "here you see a man with an eye (supervisor)
3) "a big eye (supervisor), and of course the eclipse symbol incorporated into it"
4) "a man embracing ESCET (the supervisor)"
5) "a toolbox"
<img src="/uploads/580a162f0ccf88152bea7848737d31cc/image.png" height="100px">
<img src="/uploads/c9308d66b5d3cf4d8375b40e7837632c/image.png" height="100px">
<img src="/uploads/1aabba092ec1f3a28da5211e05580103/image.png" height="100px">
<img src="/uploads/058e5ec9cb155bf3ca22921c2a2e60a8/image.png" height="100px">
<img src="/uploads/f2569312e6342383405ff44efdb59d22/image.png" height="100px">
They are worked out from the following sketches:
<img src="/uploads/0f21f1420e825159d6ece0c0eae0b23d/image.png" height="200px">
Some of the feedback we got from various people involved at that time (translated again from Dutch to English), although I'm not so sure it is all relevant:
* Person 1: Referring to logo 2: "I like this one."
* Person 2: Referring to logo 1: "I like the above left one: would consider letting both points of the C go more towards the upper and lower side of the T. Then you get there also the image of an eye.". Referring to logo 3: "I like the upper right one as well. Maybe the letters ESCET could be made a bit thicker? They are very narrow."
* Person 3: Referring to logo 1: "Somewhat nice, but not sure about hole/arrow.". Referring to logo 2: "Reasonable. But to narrow.". Referring to logo 3: "Boring. Mwoh". Referring to logo 4: "Looks like an alien. Mwoh.". Referring to logo 5: "nice idea". Also added an idea to combine logos 1 and 5: "front of the toolbox from 5 in a black rectangle like in 1?".
* Person 4: "My heat beats the most with design 1. Simple and powerful, with the Eclipse C and the breakline at the end, end also an explanation that the break points to the toolbox."
* Person 5: "I like number five at bottom right the most, as it is almost a real toolbox. Het would be a real toolbox if it were a bit less deep: the diagonal side where the 5 is indicated could be what shorter, I think. In the current form I find the logo to massive." "My second choice is number 1 at the top left. The C in the shape of the moon is beautiful, but I find the break between the E and T less nice. I could imagine that I would like it more if the E and the T were connected together."
* Person 6: "I'm attracted most to number 1 - I like simple and straight shapes."
* Person 7: "Logo 1 is quite decent. I could image it could be optimized a bit further, for instance removing the space between the E and T or letting the height of the C correspond to the height of the rectangle."
* Person 8: Referring to logo 1: "I like number 1 at the top right the best, Eclipse logos are quite rectangular so fits well. It is together with the toolbox at the bottom right a logo that feels like a single whole, in my opinion. The 'T' is however now very separate from the rest, and it would be better if both sides where closer together, so with a thin white line. Logo becomes more playful I think if the C is rotated clockwise around the center-point of the outermost circle (a bit less below sticking out at the bottom and more on the top). What could also be done is pulling the "Engineering" E more to the T, such that the 'hole' is next to the yellow part, maybe that gives possibilities, but then maybe the C disappears a bit. Eclipse itself also doesn't use the moon as a letter.". Referring to logo 3: "My second one is number 3, above right, but it is less a whole, the black block is too dominant.". Referring to logo 5: "I like the toolbox, the dark side is a bit dominant, the letters is what matters. The handles contain too much detail maybe, maybe 1 handle straight up from the middle? With a somewhat lower box the handle also becomes better visible.". Referring to logo 4: "The logo at the bottom left is very high, maybe if you use the yellow bow as a bowl for the letters? I don't associate the software with a man, the ESCET user behind the keyboard is the man, the software is more a hammer and a screwdriver (ie the toolbox).". Referring to logo 2: "The middle one is not recognizable if you don't know it is a man. Without that information it looks like the letters and some arbitrary lines through the letters. Would be better if the lines had a different color, but the lines and letters have little interaction with each other."
* Person 9: Referring to logos 1 and 3: "Logos 1 and 3 split off the T from the rest. I don't get it.". Referring to logos 1 and 5: "In logo 5 (and logo 1) the C is central and I don't think that is justified. I think the brackets should be as follows: E(((SC)E)T).". Referring to logos 2 and 4: "Therefore I have a preference for logo 2 or 4. I understand the depiction of logo 2 better than that of logo 4, although I wouldn't cross out ESCET (with the arms of the man/woman). Maybe place it higher through ESCET?"
Looking at it again, I don't really like any of these logos anymore. I'm going to veto 2, 3 and 4. Logos 1 and 5 have some potential though.
**New ideas for logos**
I've thought about the logos again a bit lately:
* I came up with some keywords that relate to Eclipse ESCET, and that could be incorporated in the logo, or could inspire it: synthesis, supervisor, coordinator, controller, correct-by-construction, efficient/speed, high-quality, engineering, automation, toolkit, tools, project.
* I have a strong preference for a modern, professional looking logo, that is simple and without too much frills.
* Ideally, the logo works well also at smaller scales. For instance, as an icon. Even at 16x16 pixels.
* I looked a bit on the Internet, and I made some things myself. I made variations on some of the designs from 2019, and made some new ones as well.
* I'm not sure I reached the best result yet, but I hope they can serve as inspiration, and help to start the discussion/search.
I came to the following so far:
* 1) Variations of logo 1 from 2019
<img src="/uploads/f1eb1ab9098ef057d1ff7cb291e407f9/image.png" height="400px">
The problem is that they are not square, so difficult to use as an icon.
* 5) Variations of logo 5 from 2019
<img src="/uploads/db2e49deed30502e75e730384def8a97/image.png" height="400px">
Most of them feel too complex to me.
* 6) I tried to make some simpler, modern icons/logos:
<img src="/uploads/a8112a13190b5c0e18b4960d9d25f371/image.png" height="400px">
I think this is more going in the right direction. A square logo, with 'Eclipse ESCET' besides it to form the logo.
* 7) Some random ideas for just the name with some edited 'E' and 'S' characters.
<img src="/uploads/aa4efc53eb2696b75d0a4d9a05412ad7/image.png" height="170px">
Not really nice as a logo, I think.
* 8) Some random ideas around the project (yellow) being a combination of Chi, CIF and ToolDef (with their respective website colors):
<img src="/uploads/f4b9314c5c740b9d9e0f749b91659c27/image.png" height="400px">
Probably all a bit too abstract.
* 9) Some even more wild ideas:
<img src="/uploads/5f83e124c6e10ee37c3bd8725ca2e8ae/image.png" height="220px">
Not really sure about these.
* 10) Some ideas around speed/efficiency:
<img src="/uploads/1bf2a150c21b47b774479188fccab54c/image.png" height="200px">
Not really sure about these.
* 11) And some final other random ideas:
<img src="/uploads/f4336ea7c36ad7c61df97b68b9c13b98/image.png" height="200px">
Let me know what you think. Are there ones that you like? Do you have better ideas?v3.0Dennis HendriksDennis Hendrikshttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/787Assignments on edges crash on wrapping expressions2024-03-18T21:13:57ZFerdie ReijnenAssignments on edges crash on wrapping expressionsConsider the following example:
```
automaton def A():
event e;
disc bool b;
location:
edge e do a1.b := true;
end
a1 : A();
```
This crashes because `checkUniqueAsgn` does not handle wrapping expressions.
One so...Consider the following example:
```
automaton def A():
event e;
disc bool b;
location:
edge e do a1.b := true;
end
a1 : A();
```
This crashes because `checkUniqueAsgn` does not handle wrapping expressions.
One solution may be to unwrap the expression in `checkUniqueAsgn`. While this may lead to false positives, referencing variables outside the parent automaton isn't allowed anyway. However, that introduces a second problem:
```
automaton def A():
event e;
disc bool b;
location:
edge e do a1.b := true;
end
a1 : A();
a2 : A();
```
Here, automaton `a2` has an update that refences `a1.b`. The type checker will not pick up on this. I don't see an easy way to solve this.
A second solution may be to type check unique (local) assignments during post checking. This will also be helpful for checking assignments on svgIn declarations. However, function scope checking also uses `checkUniqueAsgn`. I'd rather not move that check to postchecking as well.v3.0Ferdie ReijnenFerdie Reijnenhttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/681PLCgen: pre-check "continuous var as timer" gives bad error reports2024-03-14T13:50:04ZAlbert HofkampPLCgen: pre-check "continuous var as timer" gives bad error reportsUsing `tests/cif2plc/formal_finvoke_none_std.cif` as a test, I get the following reports:
``` text
--------------------------------------------------------------------------
(1/4) Continuous variable has a value that cannot be evaluated ...Using `tests/cif2plc/formal_finvoke_none_std.cif` as a test, I get the following reports:
``` text
--------------------------------------------------------------------------
(1/4) Continuous variable has a value that cannot be evaluated statically.
--------------------------------------------------------------------------
* In location "aut.l1":
- edge do r := a + c + -1.0 goto l2;
^
----------------------------------------------------------------------------------------
(2/4) Continuous variable is initialized to, assigned, or compared to, a negative value.
----------------------------------------------------------------------------------------
* In algebraic variable "a":
- alg real a = c + -1.0;
^
----------------------------------------------------------------------------------------------------------------------------------------
(3/4) Continuous variable value is not compared as "variable <= ..." or "... >= variable", nor assigned in a single-variable assignment.
----------------------------------------------------------------------------------------------------------------------------------------
* In algebraic variable "a":
- alg real a = c + -1.0;
^
* In location "aut.l1":
- edge do r := a + c + -1.0 goto l2;
^
4/4 (omitted) Warnings about using tau events.
```
We do not want the above uses of continuous variables currently, and as such getting an error report is ok.
The messages however seem weird, at least in the first and second case.v3.0Albert HofkampAlbert Hofkamphttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/779Disable formatting of single-line comments2024-03-12T14:18:56ZDennis HendriksDisable formatting of single-line commentsFrom https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/741#note_1799658:
>>>
Disable formatting of single line comments. Add Checkstyle check to ensure a space after `//`.
>>>
This will allow ASCII pictures, indented bullet lists...From https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/741#note_1799658:
>>>
Disable formatting of single line comments. Add Checkstyle check to ensure a space after `//`.
>>>
This will allow ASCII pictures, indented bullet lists, and so on.
Addresses #741v3.0Dennis HendriksDennis Hendrikshttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/781PLCgen reduce duplicated tests2024-03-12T14:17:01ZAlbert HofkampPLCgen reduce duplicated testsThe PLC targets are very similar in behavior:
- In tests designed to terminate before any code is generated, all targets rely on the same code.
- Some targets are very similar, even to the point that their output is literally the same.
...The PLC targets are very similar in behavior:
- In tests designed to terminate before any code is generated, all targets rely on the same code.
- Some targets are very similar, even to the point that their output is literally the same.
As such it seems less useful to run all tests for all targets.
Addresses #679v3.0Albert HofkampAlbert Hofkamphttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/776Website version switcher: show all preview releases after last release2024-02-21T07:53:40ZDennis HendriksWebsite version switcher: show all preview releases after last releaseCurrently, it shows in the version switcher only the preview releases after the currently shown one, but it is better if it shows all the ones after the last non-preview release. So, the nightly website then also shows the v3.0-M1 that w...Currently, it shows in the version switcher only the preview releases after the currently shown one, but it is better if it shows all the ones after the last non-preview release. So, the nightly website then also shows the v3.0-M1 that we just deployed, as it is after the current last release v2.0.v3.0Dennis HendriksDennis Hendrikshttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/775Deployment fails on adding new website version to '.versions' file2024-02-21T07:47:10ZDennis HendriksDeployment fails on adding new website version to '.versions' fileIn #437, we added switching of website versions. The deployment adds new website versions to a `.versions` file. This fails, as the `grep` may return a non-zero exit code if the new version is not yet present, making the `Jenkinsfile` st...In #437, we added switching of website versions. The deployment adds new website versions to a `.versions` file. This fails, as the `grep` may return a non-zero exit code if the new version is not yet present, making the `Jenkinsfile` stop.
For v3.0-M1 deployment, I'll update the website manually. But, we should fix the `Jenkinsfile` so that is works properly for future releases. For nightlies, it is not a problem, because `nightly` is already in the `.versions` file.v3.0Dennis HendriksDennis Hendrikshttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/755Inconsistent line length for different XML editors in ESCET dev env2024-02-21T07:47:10ZDennis HendriksInconsistent line length for different XML editors in ESCET dev envWe have a line length of 120 for `org.eclipse.wst.xml.core`, but there is now also `org.eclipse.wildwebdeveloper.xml` with its own line length, defaulting to 80. We should have consistent line length for these two XML editors that are bo...We have a line length of 120 for `org.eclipse.wst.xml.core`, but there is now also `org.eclipse.wildwebdeveloper.xml` with its own line length, defaulting to 80. We should have consistent line length for these two XML editors that are both used in the ESCET development environment.
Disclaimer: Note that this issue is not about whether we want to have a maximum line length or not. We are discussing that in #741, so let's not discuss that here. Until we decide we don't want a line limit, and if we ever do, we we will have a line limit until then. So, for now it needs to be consistent.v3.0Dennis HendriksDennis Hendrikshttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/716Release v3.0-M12024-02-20T12:35:09ZDennis HendriksRelease v3.0-M1v3.0Dennis HendriksDennis Hendriks2024-02-15https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/437Make it possible/easy for users to switch to different versions of the ESCET ...2024-02-20T11:00:11ZDennis HendriksMake it possible/easy for users to switch to different versions of the ESCET website**The problem**
Currently, our standard visible website is at `https://eclipse.dev/escet`. Version-specific websites are at, e.g., `https://eclipse.dev/escet/v0.7`. There are no links from the standard visible website to the version-spe...**The problem**
Currently, our standard visible website is at `https://eclipse.dev/escet`. Version-specific websites are at, e.g., `https://eclipse.dev/escet/v0.7`. There are no links from the standard visible website to the version-specific websites, so users are likely unaware of them.
**Proposed solution**
The first solution will consist of:
* The list of versions is stored in a file:
* This file will be updated whenever a new release is done, or when an older website (M/RC version) is removed.
* This updating will be integrated into the website manipulation scripts.
* Web pages will load the file through JavaScript, and update the page dynamically, such that we don't have to regenerate old websites once the list changes.
* Add a page `https://eclips.dev/escet/versions.html` that contains links to the various website versions. It will take you to the root page of that version (no deeper linking).
* For the fixed website pages:
* Allow switching to some of the more recent versions (at least latest release, milestone, RC and nightly), or go the page with all versions.
* The full list is already long and will only grow, so limiting the list that is shown seems like a good idea.
* We have only 12 fixed website pages, and they have been quite stable so far, so this should be easy to do.
* Only new website versions will get this new feature. Old versions won't get it, so we won't change already deployed websites.
* The links will be to the root of the other website versions, as the first websites (v0.1 - v0.3) didn't have the current fixed pages to allow for deeper linking. So, from the current CIF website, going to a nightly will take you to the ESCET home page of the nightly website.
* Add a link to the 'versions page' on the download page.
Possible things to be considered later:
* Deeper linking when switching to a different website version, for newer releases that have the same pages as the current pages. This requires knowledge of what pages there are for which version. Also, the 'other' versions can change over time. One solution could be to query live whether the deeper pages exist or not, making it dynamic and always up-to-date.
* Version switching from AsciiDoc-generated webpages.v3.0Dennis HendriksDennis Hendrikshttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/714CIF state annotations: ensure all state annotations within an automaton are d...2024-02-18T12:50:24ZDennis HendriksCIF state annotations: ensure all state annotations within an automaton are different**UPDATE**: This constraint got removed again in #756.
**Original description**
From https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/712#note_1519430:
>>>
One thing I realized is that we allow duplicate `@state` annota...**UPDATE**: This constraint got removed again in #756.
**Original description**
From https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/712#note_1519430:
>>>
One thing I realized is that we allow duplicate `@state` annotations. Probably both between different locations and within one location, I am guessing. Not sure that's a problem to be reported.
>>>
From https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/712#note_1520244:
>>>
I hadn't considered that yet. But, checking that means evaluating all arguments, making an argument name to value map, and comparing those maps for all state annotations, using value equality. And all the while, all these maps need to be kept in memory. That does sound expensive (CPU and memory wise). I think I'll skip that for now. If we ever find that useful, we can always add it later.
>>>
From https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/712#note_1521531:
>>>
I realized you just need a set of state annotations with a nice equality hashing function, similar to what #542 did. Doesn't need to be done now, I'd say.
>>>v3.0Dennis HendriksDennis Hendrikshttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/756Remove unique state annotations within an automaton constraint2024-02-18T12:49:37ZDennis HendriksRemove unique state annotations within an automaton constraintWe added this constrain in #714, but it turns out that this constraint is violated in practice. For instance, event-based automaton projection may produce models that violate this constraint. After minimization, I think the constraint sh...We added this constrain in #714, but it turns out that this constraint is violated in practice. For instance, event-based automaton projection may produce models that violate this constraint. After minimization, I think the constraint should hold again. But, the result of projection should be a valid model. Hence, I think we should remove the constraint.v3.0Dennis HendriksDennis Hendrikshttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/759Improve build output compare script2024-02-13T15:09:40ZDennis HendriksImprove build output compare script* Needs to be updated for `nightly` releases.
* If plugins get built in a different order, the output is difficult to compare. Sort the output of the plugins alphabetically.* Needs to be updated for `nightly` releases.
* If plugins get built in a different order, the output is difficult to compare. Sort the output of the plugins alphabetically.v3.0Dennis HendriksDennis Hendrikshttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/773CIF examples ToolDef scripts have bad indentation2024-02-09T13:09:39ZDennis HendriksCIF examples ToolDef scripts have bad indentationFor instance:
```
// Synthesize supervisor.
cifsupsynth("button_lamp_timer_plants_reqs.cif",
"-o generated_files/button_lamp_timer_sup.cif");
```
Note how the 3rd line is indented by one space too many. Like this has been ...For instance:
```
// Synthesize supervisor.
cifsupsynth("button_lamp_timer_plants_reqs.cif",
"-o generated_files/button_lamp_timer_sup.cif");
```
Note how the 3rd line is indented by one space too many. Like this has been there since the initial contribution. Before ESCET, we had `cif3supsynth` and we dropped the version number of CIF. Hence, the `3` got removed, but the other lines were not updated to match.v3.0Dennis HendriksDennis Hendrikshttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/772button_lamp_timer CIF example is broken2024-02-09T13:09:39ZDennis Hendriksbutton_lamp_timer CIF example is brokenRunning `button_lamp_timer_genplc.tooldef` fails:
```
ERROR: PLC code generation failed for CIF file "generated_files/button_lamp_timer_merged_hw.cif".
CAUSE: CIF PLC code generator failed due to unsatisfied preconditions:
----------...Running `button_lamp_timer_genplc.tooldef` fails:
```
ERROR: PLC code generation failed for CIF file "generated_files/button_lamp_timer_merged_hw.cif".
CAUSE: CIF PLC code generator failed due to unsatisfied preconditions:
-------------------------------
(1/2) A string literal is used.
-------------------------------
* In location "sup.s1":
- @state(Button = "Released", Lamp = "Off", Timer = "Idle", Cycle = "WaitForButtonPush")
^ ^ ^ ^
* In location "sup.s10":
- @state(Button = "Pushed", Lamp = "Off", Timer = "Idle", Cycle = "WaitForButtonPush")
^ ^ ^ ^
* In location "sup.s2":
- @state(Button = "Pushed", Lamp = "Off", Timer = "Idle", Cycle = "TurnLampOn")
^ ^ ^ ^
* In location "sup.s3":
- @state(Button = "Pushed", Lamp = "On", Timer = "Idle", Cycle = "StartTimer")
^ ^ ^ ^
* In location "sup.s4":
- @state(Button = "Released", Lamp = "Off", Timer = "Idle", Cycle = "TurnLampOn")
^ ^ ^ ^
* In location "sup.s5":
- @state(Button = "Released", Lamp = "On", Timer = "Idle", Cycle = "StartTimer")
^ ^ ^ ^
* In location "sup.s6":
- @state(Button = "Pushed", Lamp = "On", Timer = "Running", Cycle = "WaitForTimeout")
^ ^ ^ ^
* In location "sup.s7":
- @state(Button = "Released", Lamp = "On", Timer = "Running", Cycle = "WaitForTimeout")
^ ^ ^ ^
* In location "sup.s8":
- @state(Button = "Pushed", Lamp = "On", Timer = "Idle", Cycle = "TurnLampOff")
^ ^ ^ ^
* In location "sup.s9":
- @state(Button = "Released", Lamp = "On", Timer = "Idle", Cycle = "TurnLampOff")
^ ^ ^ ^
----------------------------
(2/2) A string type is used.
----------------------------
* In location "sup.s1":
- @state(Button = "Released", Lamp = "Off", Timer = "Idle", Cycle = "WaitForButtonPush")
^ ^ ^ ^
* In location "sup.s10":
- @state(Button = "Pushed", Lamp = "Off", Timer = "Idle", Cycle = "WaitForButtonPush")
^ ^ ^ ^
* In location "sup.s2":
- @state(Button = "Pushed", Lamp = "Off", Timer = "Idle", Cycle = "TurnLampOn")
^ ^ ^ ^
* In location "sup.s3":
- @state(Button = "Pushed", Lamp = "On", Timer = "Idle", Cycle = "StartTimer")
^ ^ ^ ^
* In location "sup.s4":
- @state(Button = "Released", Lamp = "Off", Timer = "Idle", Cycle = "TurnLampOn")
^ ^ ^ ^
* In location "sup.s5":
- @state(Button = "Released", Lamp = "On", Timer = "Idle", Cycle = "StartTimer")
^ ^ ^ ^
* In location "sup.s6":
- @state(Button = "Pushed", Lamp = "On", Timer = "Running", Cycle = "WaitForTimeout")
^ ^ ^ ^
* In location "sup.s7":
- @state(Button = "Released", Lamp = "On", Timer = "Running", Cycle = "WaitForTimeout")
^ ^ ^ ^
* In location "sup.s8":
- @state(Button = "Pushed", Lamp = "On", Timer = "Idle", Cycle = "TurnLampOff")
^ ^ ^ ^
* In location "sup.s9":
- @state(Button = "Released", Lamp = "On", Timer = "Idle", Cycle = "TurnLampOff")
^ ^ ^ ^
```v3.0Dennis HendriksDennis Hendriks