escet issueshttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues2023-09-01T15:15:33Zhttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/643Reduced unneeded double quotes in DMMs2023-09-01T15:15:33ZDennis HendriksReduced unneeded double quotes in DMMsFor instance:
```
Plant groups:
"","PG1","PG2"
"I","1","0"
"P","0","1"
```
This does not need any double quotes, even to be RFC-4180 compliant. The extra double quotes don't exactly make it easier to read. In some cases, they are neede...For instance:
```
Plant groups:
"","PG1","PG2"
"I","1","0"
"P","0","1"
```
This does not need any double quotes, even to be RFC-4180 compliant. The extra double quotes don't exactly make it easier to read. In some cases, they are needed: "Fields containing line breaks (CRLF), double quotes, and commas should be enclosed in double-quotes".
I think it would be nice to remove the unneeded double quotes, by making `org.eclipse.escet.common.dsm.Dmm.toString(boolean)` a bit smarter.https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/607Make the sequencing algorithm functionality usable for sequencing DSMs at use...2023-08-08T17:38:55ZAlbert HofkampMake the sequencing algorithm functionality usable for sequencing DSMs at user level#601 adds a sequencing algorithm to the `oee.common.dsm` project as library functionality for sequencing a graph, usable from Java. We need this for sequencing events in `plcgen` (see #397).
However, sequencing DSMs is much more versati...#601 adds a sequencing algorithm to the `oee.common.dsm` project as library functionality for sequencing a graph, usable from Java. We need this for sequencing events in `plcgen` (see #397).
However, sequencing DSMs is much more versatile than that. They can create order in any system that you can express as a graph of related things.
Especially in the early stages where writing a full application is too much, being able to try some sequencing can be very insightful.
For this purpose, it would be useful to open up the sequencing functionality to users at a higher level, for example through CSV files which are often used to store DSMs.https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/472Split libraries from application framework applications2024-01-05T14:34:44ZAlbert HofkampSplit libraries from application framework applicationsAnother but different attempt at #43 and a bit of #307 .
In #43 the direction is to keep it compatible with a framework application. I am not sure that is the right direction. For example, if some code uses an option to steer behavior, ...Another but different attempt at #43 and a bit of #307 .
In #43 the direction is to keep it compatible with a framework application. I am not sure that is the right direction. For example, if some code uses an option to steer behavior, do we really want to inject an option value into the option before we can call the library function we want? It seems weird. Also you don't get control for output processing. As we stack applications on top of each other, output of the inner-most applications may not make much sense for a user any more.
In #307 the aim is to reduce the number of classes/packages needed by the generated scanners/parsers. Important, but not relevant here, as Junit runs in Eclipse, so we have everything already.
----
Usecase: So I had the idea to write small CIF specifications as test specifications in Junit. The idea worked until the parser(?) wanted to output something, probably a warning or error. Then it found it was not a framework application and crashed.
I looked at `AppEnvData` and concluded we store
1. The application.
2. Output stream state.
3. Option values.
4. System properties.
for a framework application.
So here, I try to aim for creating a library. It should be as much as possible independent of the framework, and free of external support code that is not core of the library functionality. On the other hand, connecting to a framework application should be easy if so desired.
At first sight, of the stored `AppEnvData` information, only output stream state and the option values seem truly relevant.
* For output stream state, I think we want to keep the current `out/iout/dout/doout` idea, except they cannot be static methods. For example, in my Junit tests, I may want to ignore output, or just verify I have no errors or check I have certain errors or output.
* Option values are a nuisance from a library point of view. You typically want to provide a path as a string to the library if it needs reading or writing a file. You want to supply a numeric value directly. Using an option for that is a silly work-around, it may also interfere if the library is used in a larger application that uses the same options for other purposes.
Thus, I was thinking a library should have a configuration object for interfacing with the world. Probably a good idea is to keep it read-only for the library, but that can be decided locally. It should contain at least
* Settings to configure the library behavior, for as far as these are not supplied through a function call to it.
* Output stream state.
The settings are just fields in the configuration object. We may want to make a static convenience method that constructs such an object from option values for example, but it should be possible to create it in other ways too.
About the streams, I am thinking a class with the current `out/iout/dout/doout` idea for all streams, but no back-end. That back-end should be a new object connected to the former class. In this way you can have different ways of handling output. You could have a back-end that ignores output, or stores it, or checks nothing is written, or passes it on to a framework entry point. Sort of a pipeline of output stream processing to configure them.
I am also wondering if this should be done separately for each stream. Currently, operations on standard output, debug output, and error/warning output all seems the same. Splitting in 3-4 objects reduces code duplication. You could also write a streams merger that takes 2 or more streams and combines them. Note that if you use more than one library, the output streams at some point must be merged (or processed at least). Merge back-ends could be used there too.
Obviously, output streams can be stored inside the config object.
----
The configuration object is likely needed at many places in the library code. Not sure that would be easily fixable, I assume not.
As the library has no static entry or exit points, this object must be made available by passing it into the relevant classes. I would say the best spot is in the constructor, making it a read-only field available to all (depending on the design of the library code of course).
I don't think you can avoid it. I am not even sure you should want to avoid it. Our applications are mostly one input, one output. They are all connected with the world by `AppEnvData`. Many applications use the same option values (at the very least CIF file input and output). All applications use the same output stream.
If you write a larger applications with multiple libraries, at some point you will get conflicting needs for the same option values or output streams.
So while the config object adds some clutter to instantiation, I think it's an acceptable cost to making the code independent. In a sense it may not even be that bad, it basically makes the current implicit connections explicit. We already have all kinds of connections between pieces of code, but we don't see them. For example, in `plcgen` I imported and call some `cif2plc` code. There is no list of externally used input available.
----
No doubt I have forgotten a few important parts in the configuration. Termination requests is one, perhaps GUI is another. For 'simple' functionality like parsing/type-checking this is mostly not needed. They look asif it should be simple to add them to the configuration object, but likely we want to postpone that until we have more confidence in the approach?
Thoughts?
More ideas:
* Maybe make the object configuration an interface? Would be more flexible in combining libraries perhaps?
Decided naming conventions:
* Settings/input class:
* If only settings: `*Settings`.
* If settings and input data: `*Input`.
* If only input data: `*Input`.https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/406Remove trailing whitespace for StreamOutputComponent2023-08-24T11:49:43ZDennis HendriksRemove trailing whitespace for StreamOutputComponentFrom https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/351#note_981056:
>>>
* I saw trailing whitespace in the expected test output. I'm wonder, should we prevent that in this application itself? Or should we change `Strea...From https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/351#note_981056:
>>>
* I saw trailing whitespace in the expected test output. I'm wonder, should we prevent that in this application itself? Or should we change `StreamOutputComponent` (in a separate issue), to right-trim outputted lines? But then, if for instance ToolDef script explicitly prints trailing whitespace, that is then also removed, which may not be desired? What do you think?
>>>
From https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/351#note_982603:
>>>
Wrt trailing whitespace, I noticed it too and somewhat managed to avoid it, but indeed it's out of scope here.
The underlying cause is that we don't collect text of a line until we have a EOL. Instead we simply stream characters directly to the output. For indenting you then don't have a choice to delay sending indenting spaces.
The advantage of the current solution is its simplicity and its directness, you immediately see everything printed rather than having to wait until the entire line is written by the application.
To fix trailing whitespace, collecting text until getting an EOL and then right-trim could work. Obviously that breaks "directness" to some extent. That gets annoying in some extreme cases, eg in Unix `./program | tee file` writes output in 64K blocks to the screen due to buffering in the pipe (`./program | tee file | more` mostly fixes it again :p )
I am not sure we actually ever need trailing whitespace in output. To keep that door open we could add a `raw_out()` function or so.
Another option is to keep a count of "missing indentation spaces". Indenting the text then simply changes that value. Printing anything (perhaps including spaces but that's another design decision) would cause a flush of "count" indentation spaces before the new printed characters. Note that here you do have the option to distinguish between indentation spaces and printed spaces.
>>>
Things to consider:
* `StreamOutputComponent` does print per line. It has code like `out.println(Strings.spaces(indent * 4) + msg);`. If `msg` is empty, then only the indentation is printed, which become trailing whitespace. We could easily fix that, if `msg` is empty.
* If `msg` is not empty, we could also right trim that. But we'd have to check where it is used, whether that has side effects, is really desired, etc. So that may require more discussion first.https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/307Improve decoupling of generated parsers and scanners from frontend code.2022-12-10T13:17:07ZAlbert HofkampImprove decoupling of generated parsers and scanners from frontend code.Somewhat related to #43 .
I am trying to add CIF as frontend to JPlag, and I thought it would be a good idea to use the existing CIF grammar.
Jplag is a stand-alone plain Java program, and parsing a CIF file is just tokenizing the input...Somewhat related to #43 .
I am trying to add CIF as frontend to JPlag, and I thought it would be a good idea to use the existing CIF grammar.
Jplag is a stand-alone plain Java program, and parsing a CIF file is just tokenizing the input file, and firing callbacks for recognized production rules, so my first guess was this should be easy.
So I took the grammar, changed the result-types of the rules, and generated the scanner, parser and hooks file.
Then I had a look at the import tree, and ended up with (see the bottom of the description).
Some is expected, eg `setext.runtime`, and `ESCET.common.java`, but it drags in a lot of `FRAMEWORK`, EMF code for Position, right upto and including code from `eclipse.swt`, `eclipse.ui`, `eclipse.core`.
This seems silly for an empty scanner and parser that is to be embedded in a plain Java program. Not sure what to do here, I started thinking about introducing an interface class to seperate higher level code from the core code, but not sure.
Ideas? Thoughts?
Should I just start hacking the generated code and make it incompatible with the generator?
<details><summary>[[Dot file with the recursive dependencies, unfold for details.]]</summary>
<pre>
// ESCET = org.eclipse.escet
// FRAMEWORK = org.eclipse.escet.app.framework
digraph C {
"ROOT" -> "de.jplag.cif.CifParserHooks";
"ROOT" -> "de.jplag.cif.CifParser";
"ROOT" -> "de.jplag.cif.CifScanner";
"de.jplag.cif.CifParserHooks" -> "ESCET.setext.runtime.Token";
"de.jplag.cif.CifParserHooks" -> "de.jplag.cif.StructToken.CifToken";
"de.jplag.cif.CifParserHooks" -> "ESCET.setext.runtime.Parser";
"de.jplag.cif.CifParserHooks" -> "ESCET.common.java.Assert";
"de.jplag.cif.CifParserHooks" -> "ESCET.common.java.Lists";
"de.jplag.cif.CifParser" -> "ESCET.setext.runtime.Token";
"de.jplag.cif.CifParser" -> "ESCET.common.java.Strings";
"de.jplag.cif.CifParser" -> "ESCET.setext.runtime.ParserHooksBase";
"de.jplag.cif.CifParser" -> "ESCET.setext.runtime.Parser";
"de.jplag.cif.CifScanner" -> "ESCET.setext.runtime.Scanner";
"de.jplag.cif.CifScanner" -> "ESCET.setext.runtime.Token";
"ESCET.setext.runtime.Token" -> "ESCET.common.java.Strings";
"ESCET.setext.runtime.Token" -> "ESCET.common.position.metamodel.position.Position";
"ESCET.setext.runtime.Scanner" -> "ESCET.common.java.Strings";
"ESCET.setext.runtime.Scanner" -> "ESCET.setext.runtime.exceptions.SyntaxException";
"ESCET.setext.runtime.Scanner" -> "ESCET.common.position.metamodel.position.Position";
"ESCET.setext.runtime.Scanner" -> "ESCET.setext.runtime.exceptions.ScanException";
"ESCET.setext.runtime.Scanner" -> "FRAMEWORK.output.OutputProvider";
"ESCET.setext.runtime.Scanner" -> "ESCET.common.position.metamodel.position.PositionFactory";
"ESCET.setext.runtime.Scanner" -> "ESCET.common.java.Lists";
"ESCET.setext.runtime.exceptions.ScanException" -> "ESCET.common.java.Strings";
"ESCET.setext.runtime.exceptions.ScanException" -> "ESCET.common.position.metamodel.position.Position";
"ESCET.common.position.metamodel.position.PositionFactory" -> "org.eclipse.emf.ecore.EFactory";
"ESCET.common.position.metamodel.position.Position" -> "org.eclipse.emf.ecore.EObject";
"FRAMEWORK.output.OutputProvider" -> "ESCET.common.java.Strings";
"FRAMEWORK.output.OutputProvider" -> "FRAMEWORK.Application";
"FRAMEWORK.output.OutputProvider" -> "FRAMEWORK.AppEnv";
"FRAMEWORK.output.OutputProvider" -> "ESCET.common.java.Assert";
"FRAMEWORK.output.OutputProvider" -> "ESCET.common.java.Lists";
"ESCET.common.java.Strings" -> "org.apache.commons.lang.StringEscapeUtils";
"ESCET.common.java.Strings" -> "ESCET.common.java.Lists";
"ESCET.common.java.Strings" -> "org.apache.commons.lang.StringUtils";
"ESCET.setext.runtime.exceptions.SyntaxException" -> "FRAMEWORK.exceptions.ApplicationException";
"ESCET.setext.runtime.exceptions.SyntaxException" -> "ESCET.common.position.metamodel.position.Position";
"ESCET.setext.runtime.exceptions.SyntaxException" -> "ESCET.common.java.Assert";
"ESCET.common.java.Assert" -> "ESCET.common.java.Strings";
"FRAMEWORK.AppEnv" -> "FRAMEWORK.output.StreamOutputComponent";
"FRAMEWORK.AppEnv" -> "FRAMEWORK.exceptions.DependencyException";
"FRAMEWORK.AppEnv" -> "FRAMEWORK.options.DevModeOption";
"FRAMEWORK.AppEnv" -> "FRAMEWORK.output.OutputModeOption";
"FRAMEWORK.AppEnv" -> "FRAMEWORK.output.OutputProvider";
"FRAMEWORK.AppEnv" -> "ESCET.common.java.Assert";
"FRAMEWORK.AppEnv" -> "FRAMEWORK.output.OutputMode";
"FRAMEWORK.AppEnv" -> "FRAMEWORK.options.Options";
"FRAMEWORK.AppEnv" -> "FRAMEWORK.output.IOutputComponent";
"FRAMEWORK.AppEnv" -> "FRAMEWORK.io.AppStreams";
"FRAMEWORK.Application" -> "FRAMEWORK.management.AppStatus";
"FRAMEWORK.Application" -> "FRAMEWORK.options.OptionDialogOption";
"FRAMEWORK.Application" -> "FRAMEWORK.options.GuiMode";
"FRAMEWORK.Application" -> "FRAMEWORK.options.OptionDialog";
"FRAMEWORK.Application" -> "FRAMEWORK.options.LicenseOption";
"FRAMEWORK.Application" -> "FRAMEWORK.output.IOutputComponent";
"FRAMEWORK.Application" -> "FRAMEWORK.io.AppStream";
"FRAMEWORK.Application" -> "FRAMEWORK.options.OptionValue";
"FRAMEWORK.Application" -> "FRAMEWORK.output.StreamOutputComponent";
"FRAMEWORK.Application" -> "org.eclipse.core.resources.IFile";
"FRAMEWORK.Application" -> "FRAMEWORK.options.DevModeOption";
"FRAMEWORK.Application" -> "FRAMEWORK.options.GuiOption";
"FRAMEWORK.Application" -> "org.eclipse.ui.PlatformUI";
"FRAMEWORK.Application" -> "FRAMEWORK.output.OutputModeOption";
"FRAMEWORK.Application" -> "org.eclipse.core.resources.ResourcesPlugin";
"FRAMEWORK.Application" -> "ESCET.common.java.Pair";
"FRAMEWORK.Application" -> "FRAMEWORK.management.AppManager";
"FRAMEWORK.Application" -> "org.osgi.framework.FrameworkUtil";
"FRAMEWORK.Application" -> "FRAMEWORK.options.OptionCategory";
"FRAMEWORK.Application" -> "org.eclipse.core.resources.IResource";
"FRAMEWORK.Application" -> "FRAMEWORK.exceptions.EndUserException";
"FRAMEWORK.Application" -> "FRAMEWORK.output.OutputProvider";
"FRAMEWORK.Application" -> "FRAMEWORK.options.Options";
"FRAMEWORK.Application" -> "ESCET.common.java.Lists";
"FRAMEWORK.Application" -> "FRAMEWORK.io.AppStreams";
"FRAMEWORK.Application" -> "ESCET.common.java.Strings";
"FRAMEWORK.Application" -> "org.eclipse.core.runtime.Platform";
"FRAMEWORK.Application" -> "org.eclipse.core.runtime.CoreException";
"FRAMEWORK.Application" -> "FRAMEWORK.options.HelpOption";
"FRAMEWORK.Application" -> "FRAMEWORK.options.Option";
"FRAMEWORK.Application" -> "FRAMEWORK.exceptions.ApplicationException";
"FRAMEWORK.Application" -> "org.osgi.framework.Bundle";
"FRAMEWORK.io.AppStream" -> "org.apache.commons.lang.ArrayUtils";
"FRAMEWORK.io.AppStream" -> "ESCET.common.java.Strings";
"FRAMEWORK.io.AppStream" -> "FRAMEWORK.exceptions.InputOutputException";
"FRAMEWORK.options.OptionDialog" -> "FRAMEWORK.AppEnvData";
"FRAMEWORK.options.OptionDialog" -> "org.eclipse.swt.widgets.Composite";
"FRAMEWORK.options.OptionDialog" -> "FRAMEWORK.AppEnv";
"FRAMEWORK.options.OptionDialog" -> "org.eclipse.swt.events.SelectionEvent";
"FRAMEWORK.options.OptionDialog" -> "org.eclipse.swt.events.SelectionAdapter";
"FRAMEWORK.options.OptionDialog" -> "org.eclipse.jface.resource.JFaceResources";
"FRAMEWORK.options.OptionDialog" -> "FRAMEWORK.SWTUtils";
"FRAMEWORK.options.OptionDialog" -> "org.eclipse.swt.widgets.Display";
"FRAMEWORK.options.OptionDialog" -> "org.eclipse.swt.layout.FormLayout";
"FRAMEWORK.options.OptionDialog" -> "org.eclipse.swt.widgets.Event";
"FRAMEWORK.options.OptionDialog" -> "org.eclipse.swt.layout.FormAttachment";
"FRAMEWORK.options.OptionDialog" -> "org.eclipse.swt.widgets.Listener";
"FRAMEWORK.options.OptionDialog" -> "org.eclipse.swt.widgets.Shell";
"FRAMEWORK.options.OptionDialog" -> "FRAMEWORK.io.MemAppStream";
"FRAMEWORK.options.OptionDialog" -> "org.eclipse.swt.widgets.TreeItem";
"FRAMEWORK.options.OptionDialog" -> "ESCET.common.java.Maps";
"FRAMEWORK.options.OptionDialog" -> "org.eclipse.swt.custom.SashForm";
"FRAMEWORK.options.OptionDialog" -> "org.eclipse.swt.graphics.Rectangle";
"FRAMEWORK.options.OptionDialog" -> "ESCET.common.java.Sets";
"FRAMEWORK.options.OptionDialog" -> "org.eclipse.swt.custom.ScrolledComposite";
"FRAMEWORK.options.OptionDialog" -> "ESCET.common.java.Lists";
"FRAMEWORK.options.OptionDialog" -> "org.eclipse.swt.widgets.Text";
"FRAMEWORK.options.OptionDialog" -> "org.eclipse.swt.layout.FormData";
"FRAMEWORK.options.OptionDialog" -> "org.eclipse.swt.widgets.Tree";
"FRAMEWORK.options.OptionDialog" -> "org.eclipse.swt.widgets.Control";
"FRAMEWORK.options.OptionDialog" -> "org.eclipse.swt.SWT";
"FRAMEWORK.options.OptionDialog" -> "org.eclipse.swt.widgets.Label";
"FRAMEWORK.options.OptionDialog" -> "ESCET.common.java.Assert";
"FRAMEWORK.options.OptionDialog" -> "FRAMEWORK.exceptions.ApplicationException";
"FRAMEWORK.options.OptionDialog" -> "org.eclipse.swt.widgets.Button";
"FRAMEWORK.output.StreamOutputComponent" -> "ESCET.common.java.Strings";
"FRAMEWORK.output.StreamOutputComponent" -> "FRAMEWORK.io.StdAppStream";
"FRAMEWORK.output.StreamOutputComponent" -> "FRAMEWORK.io.AppStream";
"FRAMEWORK.management.AppManager" -> "FRAMEWORK.Application";
"FRAMEWORK.management.AppManager" -> "ESCET.common.java.Lists";
"FRAMEWORK.management.AppManager" -> "ESCET.common.java.Maps";
"FRAMEWORK.options.OptionCategory" -> "ESCET.common.java.Strings";
"FRAMEWORK.options.OptionCategory" -> "FRAMEWORK.AppEnv";
"FRAMEWORK.options.OptionCategory" -> "org.apache.commons.lang.StringUtils";
"FRAMEWORK.options.OptionCategory" -> "ESCET.common.java.Sets";
"FRAMEWORK.options.OptionCategory" -> "ESCET.common.java.Assert";
"FRAMEWORK.options.OptionCategory" -> "ESCET.common.java.Lists";
"FRAMEWORK.options.Options" -> "ESCET.common.java.Strings";
"FRAMEWORK.options.Options" -> "FRAMEWORK.exceptions.InvalidOptionException";
"FRAMEWORK.options.Options" -> "FRAMEWORK.Application";
"FRAMEWORK.options.Options" -> "FRAMEWORK.AppEnv";
"FRAMEWORK.options.Options" -> "ESCET.common.java.Maps";
"FRAMEWORK.options.Options" -> "ESCET.common.java.Assert";
"FRAMEWORK.options.Options" -> "FRAMEWORK.exceptions.ApplicationException";
"FRAMEWORK.options.HelpOption" -> "ESCET.common.java.Strings";
"FRAMEWORK.options.HelpOption" -> "FRAMEWORK.Application";
"FRAMEWORK.options.HelpOption" -> "FRAMEWORK.AppEnv";
"FRAMEWORK.options.HelpOption" -> "ESCET.common.java.Assert";
"FRAMEWORK.options.HelpOption" -> "ESCET.common.java.Lists";
"FRAMEWORK.options.HelpOption" -> "org.apache.commons.io.IOUtils";
"FRAMEWORK.options.HelpOption" -> "FRAMEWORK.io.AppStream";
"FRAMEWORK.options.Option" -> "FRAMEWORK.exceptions.InvalidOptionException";
"FRAMEWORK.options.Option" -> "ESCET.common.java.Strings";
"FRAMEWORK.options.Option" -> "ESCET.common.java.Assert";
"FRAMEWORK.options.Option" -> "FRAMEWORK.exceptions.ApplicationException";
"FRAMEWORK.options.Option" -> "org.eclipse.swt.widgets.Composite";
"FRAMEWORK.management.AppStatus" -> "FRAMEWORK.Application";
"FRAMEWORK.management.AppStatus" -> "FRAMEWORK.AppEnvData";
"FRAMEWORK.options.OptionDialogOption" -> "org.eclipse.swt.widgets.Composite";
"FRAMEWORK.options.LicenseOption" -> "FRAMEWORK.Application";
"FRAMEWORK.options.LicenseOption" -> "FRAMEWORK.AppEnv";
"FRAMEWORK.output.OutputModeOption" -> "FRAMEWORK.options.Options";
"FRAMEWORK.output.OutputModeOption" -> "FRAMEWORK.options.EnumOption";
"ESCET.common.java.Pair" -> "ESCET.common.java.Strings";
"FRAMEWORK.options.EnumOption" -> "FRAMEWORK.exceptions.InvalidOptionException";
"FRAMEWORK.options.EnumOption" -> "org.apache.commons.lang.ArrayUtils";
"FRAMEWORK.options.EnumOption" -> "org.eclipse.swt.widgets.Composite";
"FRAMEWORK.options.EnumOption" -> "org.eclipse.swt.SWT";
"FRAMEWORK.options.EnumOption" -> "org.eclipse.swt.widgets.Button";
"FRAMEWORK.options.EnumOption" -> "ESCET.common.java.Sets";
"FRAMEWORK.options.EnumOption" -> "ESCET.common.java.Assert";
"FRAMEWORK.options.EnumOption" -> "org.eclipse.swt.widgets.Group";
"ESCET.common.java.Sets" -> "ESCET.common.java.Strings";
"ESCET.common.java.Sets" -> "org.apache.commons.lang.StringUtils";
"ESCET.common.java.Sets" -> "ESCET.common.java.Lists";
"FRAMEWORK.exceptions.InvalidOptionException" -> "ESCET.common.java.Assert";
"FRAMEWORK.AppEnvData" -> "ESCET.common.java.Strings";
"FRAMEWORK.AppEnvData" -> "FRAMEWORK.management.AppStatus";
"FRAMEWORK.AppEnvData" -> "FRAMEWORK.exceptions.DependencyException";
"FRAMEWORK.AppEnvData" -> "FRAMEWORK.console.Console";
"FRAMEWORK.AppEnvData" -> "FRAMEWORK.options.GuiMode";
"FRAMEWORK.AppEnvData" -> "FRAMEWORK.output.OutputProvider";
"FRAMEWORK.AppEnvData" -> "FRAMEWORK.options.Options";
"FRAMEWORK.AppEnvData" -> "FRAMEWORK.output.IOutputComponent";
"FRAMEWORK.AppEnvData" -> "FRAMEWORK.management.AppManager";
"FRAMEWORK.AppEnvData" -> "FRAMEWORK.io.AppStreams";
"FRAMEWORK.console.Console" -> "org.eclipse.swt.graphics.Color";
"FRAMEWORK.console.Console" -> "FRAMEWORK.Application";
"FRAMEWORK.console.Console" -> "FRAMEWORK.io.EclipseConsoleAppStream";
"FRAMEWORK.console.Console" -> "org.eclipse.ui.console.IOConsoleInputStream";
"FRAMEWORK.console.Console" -> "org.eclipse.ui.console.ConsolePlugin";
"FRAMEWORK.console.Console" -> "org.eclipse.ui.console.IConsoleManager";
"FRAMEWORK.console.Console" -> "org.eclipse.ui.console.IOConsole";
"FRAMEWORK.console.Console" -> "org.eclipse.ui.console.IOConsoleOutputStream";
"FRAMEWORK.console.Console" -> "org.eclipse.swt.widgets.Display";
"FRAMEWORK.console.Console" -> "org.eclipse.ui.console.IConsole";
"FRAMEWORK.console.Console" -> "FRAMEWORK.io.AppStream";
"FRAMEWORK.console.Console" -> "FRAMEWORK.io.AppStreams";
"FRAMEWORK.io.EclipseConsoleAppStream" -> "ESCET.common.java.Strings";
"FRAMEWORK.io.EclipseConsoleAppStream" -> "FRAMEWORK.exceptions.InputOutputException";
"FRAMEWORK.io.EclipseConsoleAppStream" -> "org.eclipse.ui.console.IOConsoleOutputStream";
"FRAMEWORK.io.StdAppStream" -> "ESCET.common.java.Strings";
"FRAMEWORK.io.StdAppStream" -> "FRAMEWORK.exceptions.InputOutputException";
"FRAMEWORK.SWTUtils" -> "org.eclipse.swt.graphics.Rectangle";
"FRAMEWORK.SWTUtils" -> "org.eclipse.swt.widgets.Shell";
"FRAMEWORK.SWTUtils" -> "org.eclipse.swt.widgets.Display";
"FRAMEWORK.SWTUtils" -> "org.eclipse.swt.SWT";
"FRAMEWORK.SWTUtils" -> "org.eclipse.swt.widgets.Monitor";
"ESCET.setext.runtime.Parser" -> "FRAMEWORK.Paths";
"ESCET.setext.runtime.Parser" -> "ESCET.common.java.Strings";
"ESCET.setext.runtime.Parser" -> "org.apache.commons.lang.StringUtils";
"ESCET.setext.runtime.Parser" -> "ESCET.setext.runtime.exceptions.SyntaxException";
"ESCET.setext.runtime.Parser" -> "FRAMEWORK.exceptions.InputOutputException";
"ESCET.setext.runtime.Parser" -> "ESCET.common.position.metamodel.position.Position";
"ESCET.setext.runtime.Parser" -> "FRAMEWORK.exceptions.InvalidInputException";
"ESCET.setext.runtime.Parser" -> "ESCET.common.java.Pair";
"ESCET.setext.runtime.Parser" -> "FRAMEWORK.output.OutputProvider";
"ESCET.setext.runtime.Parser" -> "ESCET.common.java.Assert";
"ESCET.setext.runtime.Parser" -> "ESCET.common.java.Sets";
"ESCET.setext.runtime.Parser" -> "ESCET.common.java.Lists";
"ESCET.setext.runtime.Parser" -> "ESCET.setext.runtime.exceptions.ParseException";
"FRAMEWORK.Paths" -> "ESCET.common.java.Strings";
"FRAMEWORK.Paths" -> "org.eclipse.emf.ecore.resource.impl.URIHandlerImpl";
"FRAMEWORK.Paths" -> "org.eclipse.emf.ecore.resource.URIHandler";
"FRAMEWORK.Paths" -> "FRAMEWORK.exceptions.InvalidInputException";
"FRAMEWORK.Paths" -> "org.eclipse.emf.common.util.URI";
"FRAMEWORK.Paths" -> "ESCET.common.java.Assert";
"FRAMEWORK.Paths" -> "ESCET.common.java.Lists";
"FRAMEWORK.Paths" -> "org.apache.commons.lang.SystemUtils";
"FRAMEWORK.Paths" -> "org.apache.commons.lang.StringUtils";
"ESCET.setext.runtime.exceptions.ParseException" -> "ESCET.common.java.Strings";
"ESCET.setext.runtime.exceptions.ParseException" -> "ESCET.common.position.metamodel.position.Position";
"ESCET.setext.runtime.exceptions.ParseException" -> "ESCET.common.java.Assert";
}</pre>
</details>https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/287Use of app.framework.options.EnumOption.getDialogText2022-01-21T08:39:44ZAlbert HofkampUse of app.framework.options.EnumOption.getDialogTextWe have
``` java
/**
* Returns the text to use for the radio button for the given option value, in the option dialog.
*
* <p>
* For options that are not shown in the option dialog, just return a dummy value ({@code null} for instance...We have
``` java
/**
* Returns the text to use for the radio button for the given option value, in the option dialog.
*
* <p>
* For options that are not shown in the option dialog, just return a dummy value ({@code null} for instance).
* </p>
*
* <p>
* Example text: {@code "Abc solver"}.
* </p>
*
* @param value The option value.
* @return The text to use for the radio button.
*/
protected abstract String getDialogText(T value);
```
It suggests that a text should be provided for a given enum value without limitations.
In the interest of keeping command-line and GUI related, one would likely want to use the same values at both spots.
The command-line version however does hard-coded resolving of option values against the text of the enum value with some rewriting. There is no room for picking a nice name there other than by changing the enum value name.
So in my view, the current `getDialogText` is practically useless, and in fact counter-productive as you have to manually keep names in sync between enum value names and names provided by implementing the `getDialogText`. function.
I can see two paths to fix this. One path is to discard the above function and do a reverse rewriting to get the text-name. The other path is to discard the current resolve mechanism, and replace it by using text returned by this function instead.https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/42Improve EMF resources performance when using platform paths2022-01-13T12:50:30ZDennis HendriksImprove EMF resources performance when using platform paths`CifResource` (and probably resources for other languages) uses `StreamCodeBox(AppStream)`, which flushes per line. This is inefficient in EMF for platform resource paths, which use `PlatformResourceOutputStream`, where this adds lots of...`CifResource` (and probably resources for other languages) uses `StreamCodeBox(AppStream)`, which flushes per line. This is inefficient in EMF for platform resource paths, which use `PlatformResourceOutputStream`, where this adds lots of overhead per flush. This is not a problem when using e.g. a `FileOutputStream`. Writing files that should take a few milliseconds may then take minutes, so this is a serious performance issue.
We should forgo line-based flushing for writing CIF models, etc. It is not necessary for writing them, as they are typically not written to the command line but to files.
Implementation suggestions:
* Rename `StreamCodeBox` to `AppStreamCodeBox`.
* Make `OutputStreamCodeBox` with similar functionality, but optional line-based flushing.