This is my take on simplifying project information like version etc that are currently hardcoded and spread among multiple files (i.e. version is in Main.java and in gradle.properties). This PR introduces genBuildInfo task that generates BuildInfo.java file with information read from gradle.properties (like version) and also compile time details like current stamp, branch name or last commit hash (this info is also added to About scroller in this PR), so at the end of the day the only source of project information to maintain would be gradle.properties. I also did minor gradle cleanup.

@R3dst0ne @mbaillif @davidhutchens @maehne

BLOCKED_BY #888

I've recently had to use Logisim for my university class, but I've run into a couple problems trying to use the .dmg installer - the same "This application is damaged and can't be opened" that came up in #475, #476, and #499. I've looked into it, and found that macOS's Gatekeeper is restricting the app because the "code has no resources but signature indicates they must be present" (according to codesign/spctl). I'll try to build the .app locally and see if it has the same problem, but it seems like something in the package might have to be re-signed.

I added a few operators and other functions that should make generating HDL's easier.

• comparison operators ==, !=, <, >, <=, >=
• logic operators:
  • shift left/rightboth logic- and arithmetical
  • rotate left/right
• arithmetic operators: +/-
• control structure if, else, else if

Before I spend time on introducing these to each HDL generator, what are your opinions on these additions?

DEPENDS_ON #1098

In #983 short versions for each option get introduced. @maehne (here) and I (here) are not sure if this is a good idea. As mentioned in my comment:

It is better to have no short version than a misleading one.

Currently, there are a view where the letters don't make sense.

I propose to only add short versions for: -h, --help -v, --version -p, --plain -e, --empty -t, --template -g, --gates -c, --clear-prefs (-s, --substitute & -l, --load or --locale are fine for me as well.)

@MarcinOrlowski @BFH-ktt1 @davidhutchens @zdimension @maehne What are your opinions?

• #983

"The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough - often that I'm generating by hand the expansions of some macro that I need to write."

Java is a verbose language and prefers explicit code to syntactic sugar. Lombok provides annotations that allow generating boilerplate code for things such as member getters/setters.

It can work as a Gradle plugin and doesn't affect the build for the user.

Pros:

• less boilerplate

Cons:

• code may be less readable

Any yeas or nays?

I found these outdated references to Logisim-evolution.

• [ ] sourceforge download old version
• [x] Wikipedia FR old version Number, reference to old GitHub URL
• [x] Wikipedia DE old version Number, reference to old GitHub URL
• [x] Wikipedia EN reference to old GitHub URL

This PR replaces old argument parsing with Apache's commons-cli based.

• Completely rewritten command line argument parser:
  • All options have both short and long version now,
  • All long arguments require -- prefix i.e. --version,
  • All long arguments require single - as prefix i.e. -v,
  • -clearprefs is now --clear-prefs or -cp,
  • -clearprops option is remove (use --clear-prefs instead),
  • -geom is now --geometry,
  • -nosplash is now --no-splash or `-ns,
  • -sub is now --substitute or -s,
  • -testvector is now --test-vector or -tv.
  • removed -questa

NOTE: this is exact port of what we had in develop/ and I got a feeling certain options are no longer needed or whatever, so please do the check and let me know.

Tracing ticket #981

Fixes #981 Fixes #963

DEPENDS_ON #977

It might be a good idea to implement some kind of mechanism that enforces the synchronization of all the properties files. As you can see in #759 they were quite out of sync.

Hey guys,

I'm trying to run logisim evolution on my laptop which has a 4k monitor, and the menu items look really really small..

how can I make them look bigger without down scaling the resolution please ??

thanks in advance for your help

I created (experimental kind of) nightly builder that is expected to be run daily (cron) and create new builds if there's any activity on develop branch during last 24 hours. For now it builds *.deb, shadow jar and source jar. Once it is stable we can add more packages.

With the autoex of the .jar file the display UTF8 is not recognized under windows (test with W10 and Java 8 and version 2.14.6) this gives a nasty effect with accented letters.

I notice that the files of definition of texts are sometimes in ANSI and sometimes in UTF8 Which is the future vision for this coding ?, It seems to me that UTF stands out

temporary solution: create a shortcut and place this command in the target field: javaw.exe" -Dfile.encoding=UTF8 -jar "E:\Users\Public\LogisimEvolution\logisim-evolution.jar"

or create a .bat file with this line: start javaw -Dfile.encoding=UTF8 -jar E:\Users\Public\LogisimEvolutionlogisim-evolution.jar

Change the file path of the .jar file as needed

Dear All, please help

/Users/peter/workspace/logisim-evolution>./gradlew build
<<======-------> 47% EXECUTING [8s]
> Task :checkstyleMain FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':checkstyleMain'.
> Expected file collection to contain exactly one file, however, it contains no files.

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 11s
13 actionable tasks: 9 executed, 4 up-to-date

Build in netbeans also failed

Hi My name is Peter, system architect from www.quantr.foundation, we are team of 7 in Hong Kong working on RISC-V cpu. We have huge passion on low-level stuff. We want to create a verilog converter, to convert verilog into logisim and simulate it, mainly for education purpose. We have our own verilog parser built by antlr. We have used it to build our own verilog preprocessor https://www.quantr.foundation/project/?project=Verilog%20Compiler and debugger https://www.youtube.com/watch?v=cPjEUe2uY8I . That prove we are serious.

Now we want to find partners, especially on consulting roles.

1. We want to know how to translate verilog into ray logic, only compose by d-latch and gates.
2. We don't know how to import thing to logicism, need some guidance on hacking the logicsim

thanks Peter

Since having an outdated official Snap package (Neither stable nor nightly are up-to-date) is in no way beneficial. I propose removing the links to it until this gets fixed.

As soon as it gets updated to the current version (3.8.0), I will add the links again.

If this PR gets accepted, I will create another one for the develop branch.

Discussed in https://github.com/logisim-evolution/logisim-evolution/discussions/1608

It would be nice if timing diagrams recorded in Logisim-evolution could be exported in WaveDrom format. This would facilitate documentation, as the format can be easily edited to annotate, e.g., relations between different signals.