Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor tty #1546 #1581

Open
wants to merge 15 commits into
base: main
Choose a base branch
from
Open

Conversation

dtowell
Copy link
Contributor

@dtowell dtowell commented Nov 5, 2022

This refactors startup and verifies command-line parameter combinations to prevent unexpected results when options are allowed but later ignored. It also moves all non-GUI operations into TtyInterface.

There are now exactly 3 modes of startup:

  • help/version (print and exit)
  • Graphic User Interface
  • TTY which includes: FPGA, test-vector, test-circuit, file resave, and analysis modes.

Possible backward compatibility breaking changes:

  • some exit codes were changed to be more consistent (but not testing results)
  • some options are no longer accepted, if they were being silently ignored
  • circuit substitutions are not allowed in GUI mode

Also many tests were added. Addition tests are sorely needed but are very hard to write since they require mocking constructors. Much of the code needs to be refactored to use dependency injection to allow more unit testing.

Some option inconsistencies remain. For example. sometimes options include the .circ file as a required parameter and sometime it is required but not an option parameter. Issues and other PRs will be created to discuss individual items.

move tests to TtyInterface from Startup
single point of truth for "is GUI?"
refactor Startup, TtyInterface, GuiInterface
Startup mostly only parses arguments
TtyInterface handles all CLI operations
GuiInterace starts up GUI
some tests for Startup
introduce Task enum
simplified startup vars
regroup arg handling
Copy link
Member

@MarcinOrlowski MarcinOrlowski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just checked the code, will yet have to run it etc but please also add relevant CHANGELOG entries.
You also mentioned some options are no longer accepted, if they were being silently ignored - please be more specific.

src/main/java/com/cburch/logisim/Main.java Outdated Show resolved Hide resolved
src/main/java/com/cburch/logisim/gui/start/Startup.java Outdated Show resolved Hide resolved
src/main/java/com/cburch/logisim/gui/test/TestBench.java Outdated Show resolved Hide resolved
src/test/java/com/cburch/logisim/StartupTest.java Outdated Show resolved Hide resolved
src/test/java/com/cburch/logisim/TtyInterfaceTest.java Outdated Show resolved Hide resolved
src/test/java/com/cburch/logisim/TtyInterfaceTest.java Outdated Show resolved Hide resolved
src/test/java/com/cburch/logisim/TtyInterfaceTest.java Outdated Show resolved Hide resolved
Copy link
Member

@maehne maehne left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @dtowell for all your work and @MarcinOrlowski for your review! It goes for me into the right direction.

@dtowell: Do you consider this PR still a draft or being in a shape for integration into develop?

}
logger.error(S.get("invalidLocaleError"));
logger.error(S.get("invalidLocaleOptionsHeader"));
for (final var o : opts) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally, I don't have problems with single letter names for local variables - especially if the context in which they are used/valid is small. I agree that argument names, member variables, constants, and other identifiers, which are visible in larger scopes should have longer meaningful names. E.g., I see on object S used all over the place in this file and others of this PR, which is IMHO not good practice.

@maehne
Copy link
Member

maehne commented Nov 6, 2022

@dtowell: Sorry, saw your comment in issue #1546 too late, which answers my question above, whether you consider this PR ready for review/merging.

@MarcinOrlowski
Copy link
Member

@dtowell Please click "Resolve conversation" buttons for each change request you consider handled (in any way). It's appreciated if you add a comment (even like "Done") for changes you made as requested. If you disagree (and change is not made, please comment with your reasoning so we can proceed). You may keep non changed requests opened so it will be easier for a reviewer to jump in and either close by himself (if you made a point) or keep the discussion going. Thanks.

@dtowell
Copy link
Contributor Author

dtowell commented Nov 16, 2022

@MarcinOrlowski ok, thanks for explaining

Copy link
Member

@maehne maehne left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me! Thanks @dtowell and sorry for the delay due to a busy autumn term!

Since the changes are quite substantial, I think it should get reviewed by someone else as well.

@maehne
Copy link
Member

maehne commented Jan 27, 2023

@MarcinOrlowski: What is open from your side before this PR can be merged?

@maehne
Copy link
Member

maehne commented Jan 27, 2023

@dtowell: There are some conflicts in the localisation strings, which need to be resolved. Could you please have a look? Easiest should be to either rebase this PR on develop or merging develop into your branch.

@irdkwmnsb irdkwmnsb mentioned this pull request Oct 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants