Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
I played a little with
@in3otd , Thank you for testing. See my three last commits for suggested improvements.
Added unified dialogs using
Implemented diagrams update after each simulation and switching to DataDisplay after Simulation dialog is closed.
You should have full access to Travis.
The restart is a small round button on the right, under the settings button.
Edit: that info was perhaps only for the pro part of Travis?! Not sure.
skimming through the code..
for example in
over an over again. could you please introduce classes
and change your code to
in case the different backend require a different treatment? leaving all of this to somebody who might want to add a 4th simulator would be a bit unfair...
@felix-salfelder , All your suggested classes are already implemented. There is
Main circuit SPICE-netlist is generated in either
As alternative it's possible to implement our own netlist preparation algorithm in
So, there are strong reasons to pass information about simulators in
no. the simulator classes are missing a common base class. currently
a pointer to the schematic should never be leaked to the simulator backend, rather (structurally) the netlister should look like
this way, only the relevant parts are passed. for a full examle, consider the
EDIT: i'm referring to the
no. the current implementation on the qucs side is filled with spice and xyce specific code. the bools i am pointing out is just one example, but a good starting point.
this is not what i suggest. the netlister should be freed from simulator specific code (sure!). the simulator (or language) specific code should be implemented seperately.
yes, but you should pass a pointer to the derived class of the simulator (or language dialect), not bools.
Allowed to use Xyce-Parallel comand-line patterns. This allows to construct user command to run user builds of Xyce-parallel (See https://groups.google.com/forum/#!topic/xyce-users/X2OYGeOAXEM for details). New "Simulator settings" look like this:
This dialog serves for all external simulators. Later will be added unified simulation dialog (based on
But I think it should be done not at this point. It's not time for deep integration of external simulators. Maybe this should be done after 1-2 releases.
all simulators currently are external (or what does "external" mean?) the dialogs should work for all of them, including the current (qucsator).
no. all simulators should be treated alike, from the beginning. QUCS will never recover from merging the proposed patchbomb, because every change/sanitation will then require a deep dive into all three simulator backends. nobody will want to do that (unless for money maybe).
really, we should do one thing after another, and merge small chunks in short intervals. i have started this. see #315 and #316. next, we should let the user choose and configure simulators somehow (EDIT: please consider #317).
I took a look at it. As far I can understand, you intend to reimplement Qucs netlist builder located in
At first, I will not rewrite my code from the scratch. Almost 8 months of work will be lost. I have many positive responses for my patchset. It is operational. Only small bugs can remain. It was even tested in production. And I think it's bad idea to begin all from the scratch.
How many time will take implementation of you suggestions? #316 and #315 are only the first steps on a long way. Fullscale SPICE support in Qucs will be needed already this Autumn. There is no doubt, you are more skilled programmer than I am. But where was you last winter, when there was no "patchbomb"? I didn't close my code,
Now let's consider your code. Your solution is beautiful, but not all netlist builder could be implemented in such straightforward manner as for Qucsator and Verilog-A. Every simulator have differences. These differences ore often not obvious. Also, there is need to emulate at list the bases of Qucs equations system and postprocessors for SPICE-based simulators.
You intend to refactor
Now bools are widely used inside
I think we should use my existing
thanks for considering the code
there's no reimplementation involved. I moved some lines of code from
this does not seem to be necessary. i think it's OK to import the code to the components (where it does not belong) and call it from a plugin. cleanup later.
does reordering the commits and some sanitation qualify as "rewrite from scratch"?
this is none of my business, i am trying to help sorting out a contribution that will arguably damage the project in the long run. the original author intentionally did NOT use SPICE behavioural modelling semantics for a very good reason. as I explained in another post, this is not even necessary to dotf
I was writing my phd (and working on gnucap-adms etc.). i am not sorry, should I?
this is exactly the reason why the simulator specific code should be separated from each other. calling ngnutmeg from there does not interfere the least.
in a first pass you could even use
as I said, no reimplementation is required. what we need is some preparatory work that is independent of your branch (also watch out for my other comments) then rebase your branch on top of that.
there are easy changes that will reduce future headache a whole lot
other things are misleading but don't really break things, for example you add
even with the functionality in the wrong place (which i think is a good compromise), writing the Xyce and Spice language classes is a matter of hours.
a command line option to create netlists has already been implemented in #316. here you can select the language by name, which is much better extensible.
PS: we should work on merging this patchbomb, rather than increasing its size even more. by writing "we" i am implicitly offering help.
Recently we discussed the future of Qucs and Qucs-S with @felix-salfelder and decided to backport the codebase of Qucs-S to new modular architecutre (PRs #316, #458, and #589 ). The development and releases preparation of Qucs-S will be continued until the new architecture of Qucs will be fully operational.