Comments (12)
Dear Logisim developpers,
I am working on a FSM editor/analyzer/simulator/HDL codegen for logisim to be used in our
computer design classes. The current implementation (alpha stage) is hosted on a fork of the project (https://github.com/sderrien/logisim-evolution).
In its current status, the editor can be used to visually specify/edit FSM models that can then be natively simulated by logisim.
I initially planned to deliver it as a jar plugin, but I have unsuccesfull doing so because of library/jar dependencies from my plugin to third parties (EMF/Xtext). As a consequence, it is currently implemented as native library within logisim (see readme.md on my fork)
Any feedback is welcome.
Regards,
Steven
from logisim-evolution.
from logisim-evolution.
Hi sderrien,
Thank you for your message. This feature seems to be very interesting.
We will take a look at your feature.
from logisim-evolution.
Hi sderrien,
I tried to compile your fork with ant and eclipse and was not able to build a jar to test (one of the reasons of my current beta version as pull request). What is the status for the moment on this feature?
from logisim-evolution.
I played around a bit with the FSM editor and had a good impression. Even without modification, I managed to modify the FSM (adding/removing states, inputs, outputs). The error messages could be improved to indicate more clearly what is the problem and how it may be fixed (e.g., when wanting to change the encoding of the states, you also need to think to adjust the corresponding global setting of the FSM). I would very much like to see it integrated into our develop
branch for the next release.
from logisim-evolution.
Hi,
I would very much like to see it integrated into our develop branch for the next release.
I tried to merge my version with the master branch but I am really lost with the new kotlin/gradle build system which I could not make work.
The main issue I have is that I need to work with 3 distinct source folder (I use xtend+xtext which transpiled into java source code), and I could not figure out how to modify the gradle build file.
At this point I can only get it to work directly from Eclipse, or as a separate logisim jar plugin, which has to be explicitely loaded through the menu.
Any help would be appreciated,
Regards,
Steven
from logisim-evolution.
Thanks @sderrien for your effort to integrate your code with our develop
branch. We are also still in the process to familiarise ourselves more with the new Kotlin/Gradle build system for Logisim-evolution.
Does your current dev-with-fsm
branch already contain all the necessary sources?
Could you more precisely describe your additional dependencies (emf, xtend, xtext)? Which version of them you need and how do you use them in your FSM editor? These dependencies will be needed to get referenced in the build.gradle.kts
file -- most probably in the plugins
and dependencies
sections. I found that there are dedicated plugins for emf, xtend, and xtext. The plugins and dependencies are automatically downloaded and managed by Gradle so we ideally should not need any binary/JAR artefacts in the source repository.
We also need to know which additional steps you do to build Logisim-evolution with your FSM editor extension.
from logisim-evolution.
I forgot to mention that for the dependencies
section, you can look up the necessary artefact IDs on search.maven.org. On the page of each artefact are the clearly stated the line to add to build.gradle.kts
.
from logisim-evolution.
@sderrien: I had a closer look to your Logisim-evolution repository to checkout your enhancements. After going through your commit history, I compared your master branch to the state in commit 65e5259. Integrating your enhancements into the official Logisim-evolution repository will require some effort as a simple git rebase
or git merge
won't do due to the migration from ant
to gradle
and the therefore done restructuring of our repository. Cherry picking of your modifications one by one with clean-ups after each step seems also to be not a good option due it will be very time consuming and pull in quite some binary artefacts from 3rd-party dependencies and generated implementation files, which we should try to keep out from versioning.
Therefore, the best option for me seems to be to squash your modifications into single commits per feature/topic (support for the different FPGA boards, new Logisim simulation components, the FSM editor). Based from the current develop branch, a branch for each feature/topic should be created. Then, we need to copy in the modified/added files to implement that feature/topic. These files can be probably best identified from comparing your master branch to the state in commit 65e5259. This sorting would be ideally done by you as you are the most familiar with the done modifications. Before adding the modifications to the commit, all modified hunks in already existing files need to be reviewed carefully so that we don't add regressions by removing our fixes and enhancements done in the official Logisim-evolution repository since 65e5259, but only consider the hunks, which actually implement the enhancement. We also need to keep out from the commits out-dated files required by the removed ant
build system as well as any binary artefacts from 3rd-party dependencies and auto-generated files. Once the implementation files for the feature are committed to the, we can open a pull request to review/test the changes. Any modifications necessary to take into account the feature during building with gradle
, pulling-in the required 3rd-party dependencies, etc. will become additional commits in the branch. Once the feature/topic is working in this branch, we can merge it into the develop
branch and we can continue with the next feature/topic.
What do you think?
from logisim-evolution.
Hello Torsten,
Yes I agree, with what you propose. So far, here are the features I believe should be integrated.
-
to my opinion, the FSM editor is the most valuable add-on, but there are a few issues to solve from the build side (see below)
-
The additional DE0-CV board model is also interesting, but I somewhat hacked the current board model so as to be able to add external interface combining both inputs and output ports (the goal was to be able to interface with a 4x4 keypad). So a direct integration may not be straightforward and need some discussion.
-
I introduced several additional components, (keypad, Instruction Set Simulator for a toy NIOS-II/RISC-V CPU, etc.). These are really specific to my course, so we should see whether they are worth being integrated to the main branch.
As mentioned above, there are a few issues that need to be solved on the graddle build side, before I can commit all/part of these changes.
To make it short, most of the .java files commited on my fork are actually generated by either xtend (in the xtend-gen folder) or by xtext/ecore (in the src-gen folder). These folder can only be used to store generated file as they are cleared before every build (this is not under my control). We must therefore find a way to register these additional java source folders in the gradle build (something I was not able to do for the moment). Once I know how to handle this, I should be able to follow your guidelines.
Regards,
Steven
PS : note that there seem to be an effort by xtend/xtext people to support graddle builds, but I am still not sure how to use them, and there are a lot of mismatch between groovy/kotlin way of specifying things. which got me lost.
from logisim-evolution.
@sderrien: Thanks for your feedback! Based on it, we could first look to integrate the FSM editor. Could you add to a new branch forked from our develop
branch just the source files related to it without any generated files and binary 3rd-party dependencies? Then, we could have a look to add the necessary steps to the gradle
Kotlin build scripts. There it would help if you could sketch out which files need to be processed by which tool to create all generated files that need later to get compiled/copied into the final Logisim-evolution JAR archive. You could add this information to this ticket or, even better, to a pull request to add the FSM editor. It is not a problem that this pull request is initially not yet ready for merging. It will just serve us as a place to document our progress with the integration of your tool. I don't know to which extend I will be able to help as I also just started using gradle/Kotlin and I am not really familiar with Xtext and Xtend either.
Regarding the new support for the DE0-CV FPGA board and the additional components, we are open for reviewing these contributions with you to decide together what makes sense to get integrated in the official version.
from logisim-evolution.
Hello Torsten,
The pull request has been submitted
Regards
from logisim-evolution.
Related Issues (20)
- Nightly build failed for Mac HOT 6
- User interface is too bright HOT 1
- No X11 DISPLAY variable was set - Wayland HOT 2
- Simulation halted by internal error when generating timing diagram HOT 4
- Debian build and Linux release value HOT 4
- Splitter as Input / Output sub circuit port HOT 1
- Remember camera position for each circuit HOT 1
- "Unconnected" State don't get propagated to Subcircuit HOT 1
- wire pointing south in certain cases causes error
- How can I solve this "short-circuit" issue? I'm trying to connect the output of a register to an extender and a multiplexer HOT 1
- the .jar file is not working. HOT 2
- Improper byte-enable behaviour on RAM module HOT 5
- 【bug】 when open specified folder as export, logisim crashes HOT 5
- How do I download the latest changes? HOT 3
- Ideas for the 3.9.0 update HOT 3
- ShiftRegister strange behaviour when Appearence attribute is set to "Classic Logisim" HOT 4
- RAM does not extern loaded content if placed in a subcircuit. HOT 5
- Eliminate the onerous naming restrictions. HOT 1
- Wrong commit tagged for 3.9.0 release
- Remove unused branches master and rc3.8.0 HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from logisim-evolution.