Re: [escet-dev] Eclipse ESCET v0.2 plans

[Dennis Hendriks <dh_tue@xxxxxxxxxxx>]

Hi all,

I've created a whole bunch of issues in GitLab for the v0.2 release.

> I have 3 fixes for the CIF simulator, 2 of them based on old issues. Will dig up the details next week.

I think you can add these directly to GitLab without discussing here. Note that I created several issues for known bugs as well, so maybe it is now already there.

> I also have written a railroad diagram generator (a nice constraint solver puzzle) that can be added under the assumption I get permission.

Please add a GitLab issue for this as well, once you know.

Permission from whom?

> As for other things, I'll discuss that with Pascal.

OK, let us know here on the list what your ideas are. Depending on how much it is and what it is, this may also influence the discussion regarding the release date for v0.2. We should have this discussion after the scope of the release is clear.

> One thing that's going to come up often is author of the contributions. Obviously, for code that I wrote, it's simple. For code and patches written by PhD students, it may be simple too but let's discuss that to be sure. My idea here is, that they wrote that code while being employed by the university, so the university owns that code. The university also has a general agreement with Eclipse, and I commit under the same agreement that would be sufficient?

I don't know. I think we should ask the Eclipse Foundation legal team about this, just to be sure. Could you ask this question to license@xxxxxxxxxxx with CC to this list?

> Is there stuff on the todo list of the initial contribution that fell off, which may be useful to do?

Yes, there is. I put most of it in GitLab issues for v0.2. There are some issues in the old issue system that have only a title without details, no example models to show the issue, not enough details for me to understand what it is about, and/or I'm not sure it is still relevant. It concerns:

• Crash on linearize-merge (java.lang.AssertionError)
• Wrong behavior for complex initialization with multiple (algebraic) dependencies
• Fix list-subtraction: Manual states list-subtraction exists, type-checker doesn't know about the case. Likely, the entire operation is missing in all tools.
  
• Give access to local variables in mcrl2: While mcrl2 can query shared variables (from variable processes), it currently has no access to non-shared variables.
  
• Enable querying current state in mcrl2: The state of an automaton is translated to a location pointer LP for each automaton, but mcrl2 has no access to it, which means it cannot verify properties involving automata states.
  
• Event stepping and value queries are not mutually exclusive in mcrl2: The idea for mcrl2 is to either: 1) Perform an event in the system, or 2) Query current variable values. Currently, these two options are not mutually exclusive, meaning mcrl2 computes state transitions with all combinations of the above options.
  
• In java code, algebraic variable defined in states of an automaton may get accessed before the initial location of that automaton is initialized.
  
• Language equivalence check is sometimes wrong or weird: 4cm30, section 2.5.2
  
• Improve performance of the state explorer in case of getting statistics of the state space: If the only purpose of running the program is to count locations, the output just takes space and time without being used. If one also wants to count edges, it's a different story, likely you can't avoid creating the output in that case. In general, the current implementation isn't really designed for counting only, perhaps other points can be improved as well (like more sharing of data values in the explored data set).
  

Some of the other things that remain are quite a bit of work. I propose to delay them till a next release. We can't do everything at once after all. This includes:

• ToolDef reference manual and user manual
• CIF reference manual, synthesis manual and showcases
• Adopt semantic versioning and API analysis
• Replacing all LaTeX documentation/images including generators

The remaining issues appear to me to be either obsolete or random ideas that we could always recreate should they become relevant (again).

Dennis

---

Van: escet-dev <escet-dev-bounces@xxxxxxxxxxx> namens Hofkamp, Albert <A.T.Hofkamp@xxxxxx>
Verzonden: dinsdag 6 april 2021 10:11
Aan: escet developer discussions <escet-dev@xxxxxxxxxxx>
Onderwerp: Re: [escet-dev] Eclipse ESCET v0.2 plans

 

Is there stuff on the todo list of the initial contribution that fell off, which may be useful to do?

At least there is documentation that needs to be written iirc.

Albert

---

From: Hofkamp, Albert <A.T.Hofkamp@xxxxxx>
Sent: Sunday, April 4, 2021 09:47
To: escet developer discussions <escet-dev@xxxxxxxxxxx>
Subject: Re: [escet-dev] Eclipse ESCET v0.2 plans

 

I have 3 fixes for the CIF simulator, 2 of them based on old issues. Will dig up the details next week.

I also have written a railroad diagram generator (a nice constraint solver puzzle) that can be added under the assumption I get permission.

As for other things, I 'll discuss that with Pascal.

One thing that's going to come up often is author of the contributions. Obviously, for code that I wrote, it's simple. For code and patches written by PhD students, it may be simple too but let's discuss that to be sure.

My idea here is, that they wrote that code while being employed by the university, so the university owns that code. The university also has a general agreement with Eclipse, and I commit under the same agreement that would be sufficient?

Albert

---

From: escet-dev <escet-dev-bounces@xxxxxxxxxxx> on behalf of Beek, Bert van <D.A.v.Beek@xxxxxx>
Sent: Friday, April 2, 2021 15:07
To: escet developer discussions <escet-dev@xxxxxxxxxxx>
Subject: Re: [escet-dev] Eclipse ESCET v0.2 plans

 

Hi Dennis,

I have been thinking about this already before you send us this email, but your suggestions cover my ideas for the full 100% and even add more, so I really have nothing more to add. Thanks!

Bert

> On 1 Apr 2021, at 17:41, Dennis Hendriks <dh_tue@xxxxxxxxxxx> wrote:
>
> Hi all,
>
> We've released our first release v0.1. I think we should look at the next steps, i.e. release v0.2. I propose to first identify the big parts that we want to work on for this release.
>
> To kick off the discussion, I'll indicate my ideas here:
>
> Dependencies, product, build, etc:
>        • Include JDK in product again, using JustJ Java releases. Less installation steps. All users have the same Java version.
>        • Update to Eclipse 2021-03. To keep current and to enable using JustJ.
>        • Update to latest Java LTS release (currently Java 11). There are no JustJ releases for Java 8. Also Java 8 is (mostly) end of life.
>        • Use the new Eclipse CBI macOS notarization service, add entitlements, package as .dmg file.
>        • Customize welcome screen, with links to help, examples, different tools, web links, changelog, etc.
>        • Crash report should indicate where to report issues.
>        • Add test code coverage reports to build.
>
> Website/documentation:
>        • Generate multiple HTML pages instead of a single HTML page. More stable URLs, not so long pages, etc.
>        • Website landing pages separate from AsciiDoc-generated documentation. Landing page should be attractive and allow easy navigation, etc.
>        • Improve documentation style, enable syntax highlighting, etc.
>        • Reconsider project metadata and project home page, also in relation to the website. Reduce text there and refer to (various parts of) the website instead.
>
> Other:
>        • Address known bugs and performance issues. This includes some of the issues in the old TU/e issue tracker, and some new ones I encountered myself more recently.
>        • Make it easier to use/call CIF functionality from code. E.g. separate CIF applications from their functionality, helper functions to allow running code even if not invoked from application framework context, etc.
>
> Let me know what you think of these ideas. Also, I'm curious what you want to have in and work on for the next release.
>
> Dennis
> _______________________________________________
> escet-dev mailing list
> escet-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://eur02.safelinks.protection.outlook.com/?url="">

_______________________________________________
escet-dev mailing list
escet-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://eur02.safelinks.protection.outlook.com/?url="">